Docker Image

 

개념

 

Container을 실행하기 위해 필요한 File, Binary, Library, 설정 등을 포함한 표준화된 Package

 

ex) PHP Application을 실행하기 위한 Image 

PHP Image
│
├─ PHP Runtime
├─ PHP Extension
├─ Library
├─ Application Code
└─ Configuration

 

---

 

특징

 

한 번 생성된 Image 자체의 내용을 직접 수정 하는 방식이 아니라, 변경이 필요하면 새로운 Image를 생성

=> Docker Image는 여러 Layer로 구성되며 각 Layer는 File System의 변경 내용을 나타냄 

= Container가 생성될 때는 Image위에 쓰기 가능한 Container Layer가 추가됨. 

따라서 실행 중 Container에서 발생한 변경이 원본 Image 자체를 수정하는 것은 아님. 

 

ex)

FROM php:8.3-fpm

WORKDIR /var/www/html

COPY . .

RUN docker-php-ext-install pdo_mysql

 

위와 같은 Dockerfile은 개념적으로 아래와 같이 구성됨

 

┌──────────────────────────────┐
│ RUN docker-php-ext-install...                              │
├──────────────────────────────┤
│ COPY . .                                                              │
├──────────────────────────────┤
│ WORKDIR /var/www/html                                   │
├──────────────────────────────┤
│ php:8.3-fpm                                                         │
└──────────────────────────────┘

 

 

[사용하는 이유]

 

재사용 

=> 같은 Layer를 여러 Image가 공유할 수 있기 때문에 동일한 내용을 매번 새로 저장하거나 가져올 필요를 줄일 수 있음 

 

ex) 두 Image가 동일한 Base Image를 사용한다면 공통 Layer을 다시 사용할 수 있다. 

             php:8.3-fpm
                  │
          ┌───────┴───────┐
          ↓                                       ↓
     Application A                     Application B

 

[ Build Cache]

 

Docker는 Image를 다시 Build할 때 이전 Build 결과를 그대로 사용할 수 있는지 확인 

=> 이미 동일한 Layer가 존재한다면 다시 만들 필요가 없기 때문에 Build 시간을 줄일 수 있다. 

 

특정 Layer가 변경되면?

해당 Layer의 Cache를 그대로 사용할 수 없다. 

=> 하나의 Layer에서 Cache가 무효화되면 그 뒤의 Layer도 다시 Build 됨.

ex) 

FROM php:8.3-fpm → Cache 사용

WORKDIR /var/www/html → Cache 사용

COPY . .    # Source Code 변경 → 다시 Build

RUN docker-php-ext-install pdo_mysql → 이후 Layer도 다시 Build

 

중요 : Dockerfile의 순서

자주 변경되지 않는 작업을 앞에, 자주 변경되는 작업을 뒤에 배치하는 것이 유리

 

---

 

Image와 Container의 관계

 

Image 자체는 실행 중인 Application이 아님. 

Image를 기반으로 Container를 생성하고, 그 Container 안에서 Process가 실행됨 

 

Container = Image의 실행 가능한 Instance

 

---

 

Docker Image는 어떻게 만들어지는가?

 

	설명	상세
Dockerfile	이미지 설계도  = Docker Image를 어떻게 만들 것인지 작성하는 설정 파일 (Image에 필요한 환경과 작업을 명령어 형태로 정의)	어떤 명령을 실행할지, 어떤 파일을 복사할지, 어떤 시작 명령을 사용할지 등
↓ —- (docker build)		- Dockerfile을 읽고 각 Instruction을 처리하면서 Image를 생성 => Image는 Dockerfile의 Build Instruction 결과가 순서대로 쌓인 Layer 구조
Image	실행 환경 포장본 (컨테이너를 만들기 위한 원본)	컨테이너 실행에 필요한 파일, 바이너리, 설정을 포함한 표준 패키지
↓ —- (docker run)
Container	실제 실행 상태 (실행체) = 이미지를 실행한 상태

 

 

---

 

Docker Image Tag

 

개념

하나의 Application에서도 여러 Version의 Image를 만들 수 있음. 

 

Tag = 이미지를 구분하기 위해 붙이는 식별자

 

Repository:Tag

 

- 생략시 : 일반적으로 latest가 사용됨 (latest도 하나의 Tag다, 이름이 latest인 Tag)

ex) my-app:1.0, my-app:1.1

 

사용법

Image Build시 바로 지정 가능 

docker build -t my-app:1.0 .

 

Registry / Repository / Tag 관계

Docker Registry            ← 등록소, 등록 시스템 
│
├─ my-app                 ← Repository
│   ├─ 1.0                ← Tag
│   ├─ 1.1
│   └─ 2.0
│
└─ another-app
    ├─ 1.0
    └─ 1.1

개념	역할
Registry	여러 Docker Image를 저장하고 제공
Repository	하나의 Image 이름 아래 관련 Image 관리
Tag	Repository 안에서 Version이나 Variant 구분

 

Image 이름 형태 

Registry / Namespace / Repository : Tag 

- Namespace = 소유자나 조직을 구분하기 위해 사용됨.

 

ex) docekr.io/myuser/my-app:1.0

 

---

 

Image를 Registry에 올리기

 

Docker Hub에 올리고 싶다면 먼저 Docker Hub에 사용할 Repository 이름 형태로 Image에 Tag를 붙인다.

=> Docker Image 이름을 통해 어느 Repository로 Image를 Push 할 것인지를 판단

 

EX]

Docker Hub계정이 myuser

docker tag my-app:1.0 myuser/my-app:1.0

#docker tag => Image를 새로 Build하거나 복사하는 게 아니라, 기존 Image에 Resgistry에서 사용할 새료운 이름을 추가

                               ┌─ my-app:1.0
같은 Image  ←───┤
                               └─ myuser/my-app:1.0

 

# 이제 Regisry에 Upload 가능
docker push myuser/my-app:1.0

 

---

 

다른 환경에서 Image 가져오기

 

docker pull myuser/my-app:1.0

 

Docker Hub
    │
    │ docker pull
    ▼
운영 Server

Local Images
└─ myuser/my-app:1.0

 

이후 docker run myuser/my-app:1.0으로 Container를 생성/실행 할 수 있음