2022. 4. 17. 12:20ㆍDevOps/Docker & Kubernetes
Identifying Software
특정한 프로그램을 설치하기 위해서는 프로그램을 유일하게 식별할 수 있는 식별자가 필요합니다. 이 식별자는 프로그램의 이름, 사용하려고 하는 프로그램의 버전, 그리고 프로그램을 가져올 위치(Source)를 포함해야 합니다. (You would need a way to name the progam, specify the version that you want to use, and specify the source that you want to install it from.)
이전 포스팅에서 살펴보았듯, 도커는 이미지로부터 컨테이너를 생성합니다. 이 이미지는 컨테이너에서 사용 가능한 "파일"과 이미지의 정보를 가리키는 "메타데이터"로 구성됩니다. 이 메타데이터는 레이블, 환경변수, 실행 환경(컨텍스트), 그리고 이미지의 Command History를 포함합니다. 이 각각의 이미지는 독특한 식별자를 갖지만, 실제로 Semantic하진 않아서 사용자가 직접 사용하기에는 어려움이 있고, 이미지에 업데이트가 반영될 때마다 이 식별자가 변경되기 때문에 관리하기가 어렵습니다. (Unpredictable) 따라서 이 도커에서 이미지를 가져와 컨테이너를 실행하는 데에는 식별자가 아니라 "named repository"를 사용하게 됩니다.
What is a named repository?
named repository는 이미지들이 담긴 "Bucket"을 의미합니다. (URL과 비슷한 식별자의 기능을 합니다.) 레포지토리는 아래 그림과 같이 이미지가 저장되어 있는 Host의 이름(docker.io), 이미지를 소유하고 있는 유저의 어카운트(dockerinaction), 그리고 해당 이미지를 가리키는 짧은 이름(ch3_hello_registry)으로 구성됩니다.
이미지는 여러개의 버전이 있을 수 있기 때문에 각각의 레포지토리 안에 있는 이미지는 "태그"를 추가해서 유일하게 식별될 수 있습니다. 만약 새로운 버전의 "ch3_hello_registry"를 릴리스하고 싶을 경우, 기존 버전을 v1으로 태깅하고 새로운 버전을 v2로 태깅할 수 있습니다.
이렇게 "named repository"와 "tag"는 composite key 라는 유일한 식별자를 생성할 수 있으며(e.g nginx:latest) 이는 앞서서 언급한 복잡하고 예측하기 어려운 이미지 고유의 식별자를 대체할 수 있는 Semantic 한 방법을 제공합니다.
Using tags
태그는 이미지를 "유일하게"식별할 수 있도록 도와주는 동시에, 유용한 Alias를 생성하는 데에도 도움을 줍니다. 하나의 태그는 오직 "하나의 이미지"에만 붙을 수 있지만 하나의 이미지는 "여러 개의 태그"를 가질 수 있기 때문입니다.
[TIPS] When you’re looking for software to install, always pay careful attention to the tags offered in a repository. Many repositories publish multiple releases of their software, sometimes on multiple operating systems or in full or slim versions to support different use cases. Consult the repository's documentation for specifics of what the repository's tags mean and the image release practices.
Finding and Installing Software
앞서 named repository + tag의 조합으로 다운로드할 프로그램을 유일하게 식별할 수 있는 방법을 알아보았습니다. 이번에는 이 named repository를 "어디서, 어떻게" 가져올지에 대한 방법을 살펴보도록 하겠습니다.
이미지를 검색하는 가장 쉬운 방법은 "Index(Registry)"를 사용하는 것입니다. Index는 일종의 repository 검색 엔진을 의미하는 개념으로 하나의 Index안에 여러 repository들이 카탈로그 형식으로 저장되어 있습니다. 실제로 여러 public Docker Index가 존재하며, "docker"의 기본 Index는 "Docker Hub"입니다. 따라서 별도의 명령어를 통해 Index를 지정하지 않으면 기본적으로 Docker Hub 인덱스에서 해당 레포지토리를 검색하게 됩니다.
Working with Docker registries from the command line
도커 이미지를 만든 사용자는 Docker Hub와 같은 이미지 레지스트리에 다음 2가지 방법을 사용해서 배포할 수 있습니다.
- 사용자의 환경에서 이미지를 직접 build 한 이후에 Command Line을 사용해서 이미지를 Hub에 푸쉬합니다.
- Publicly Available 한 Docker file을 만들어서 CI / CD 파이프라인을 생성한 후에 이 파이프라인 시스템이 변경사항을 자동으로 빌드하여 Hub에 푸시하도록 합니다.
후자의 경우 실제로 규모가 있는 애플리케이션을 지속적으로 배포해야 하는 경우 DevOps 팀에서 자주 사용하는 방식으로 Gihub 등의 버전 관리 시스템에 새로운 변경사항이 푸시되면 이를 감지하여 파이프라인에서 Dockerfile을 Build 하고 빌드된 이미지를 Kubernetes와 같은 컨테이너 오케스트레이션 시스템 등을 사용해서 애플리케이션을 새로운 버전으로 실행하는 식으로 구성됩니다.
이 경우, 이미지는 외부에 public 하게 공개되면 안 되는 경우가 대부분이므로 private registry를 사용하게 되는데, 이 private registry에 repository를 생성하고 새로운 버전들을 릴리스하기 위해서는 docker login을 사용해서 권한을 증명해야 합니다.
Using alternative registries
AWS, GCP 등의 Cloud Provider의 서비스를 사용하면 여기서 Private Registry를 제공해주기 때문에 이를 사용해서 이미지를 관리할 수 있습니다. 이렇게 Alternative Registry를 사용할 겨우 사용 방법은 간단한데, 다음의 패턴만 지켜서 이미지를 가져오도록 설정해 주면 됩니다.
[REGISTRYHOST:PORT/][USERNAME/]NAME[:TAG]
Working with images as files
도커는. tar와 같은 파일로부터 도커 이미지를 Load 할 수 있는 "docker load" 커맨드를 제공합니다. 이 커맨드를 사용하면 다른 곳에서 얻은 압축파일을 도커 이미지로 올릴 수 있게 됩니다. 실제로 이를 테스트하기 위해 다음과 같은 순서로 docker load에 사용할 압축 파일을 생성해보겠습니다.
- docker pull busybox:latest
- Docker Hub로부터 busybox:latest 이미지를 가져옵니다. 이는 테스트할 도커 이미지를 로컬 머신으로 가져오기 위함입니다.
- docker save -o myfile.tar busybox:latest
- Docker Hub로부터 가져온 이미지를 myfile.tar라는 이름으로 저장합니다. (-o 플래그를 사용하면 로컬 저장소에 저장할 수 있습니다.)
- docker rmi busybox:latest
- 실제로 DockerHub에서 가져온 busybox:latest 이미지를 사용하는 것이 아니라 방금 저장한 myfile.tar로부터 busybox:latest를 불러올 것이기 때문에 방금 가져온 busybox:latest를 로컬 이미지 레지스트리에서 삭제합니다.
- docker load -i myfile.tar
- myfile.tar로부터 이미지를 가져옵니다. 실제로 실행하게 되면 아래와 같이 busybox:latest 이미지를 잘 가져오는 것을 확인할 수 있습니다.
Installling from a Dockerfile
(DockerFile은 이후 포스팅에서 더 자세하게 다룰 예정입니다). 도커 파일은 이미지를 실행하는데 필요한 모든 파일들을 담고 있는 것이 아닌 "이미지를 필드하기 위해서 거쳐야 하는 단계들"을 담고 있습니다. 따라서 도커파일은 이미지처럼 "실행"하는 것이 아니며 도커 파일을 사용하여 "실행하기 위한" 이미지를 "빌드"하는 것입니다. 따라서 이미지 자체를 저장하는 것보다는 적은 공간을 차지하지만, 실제로 빌드하는 단계가 필요하기 때문에 시간이 더 걸리게 됩니다.
# syntax=docker/dockerfile:1
FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py
'DevOps > Docker & Kubernetes' 카테고리의 다른 글
[Docker in Action] Working with storage and volumes (1) (0) | 2022.04.23 |
---|---|
[Docker in Action] Software installation simplified (2) (0) | 2022.04.17 |
[Docker in Action] Running Software in containers (2) (0) | 2022.04.10 |
[Docker in Action] Running Software in containers (1) (0) | 2022.04.09 |
[Docker in Action] Welcome to Docker (0) | 2022.04.05 |