2024. 4. 7. 10:19ㆍDocker
This chapter covers
- Choosing a project distribution method
- Using hosted infrastructure
- Running and using your own registry
- Understanding manual image distribution workflows
- Distributing image sources
여러분이 작성했거나, 커스터마이징했거나, 인터넷에서 가져온 소프트웨어 이미지가 있을 것입니다.
그러나 아무도 그 이미지를 설치할 수 없다면 무슨 소용이 있을까요?
Docker는 이미지 배포 기능을 제공하기 때문에 다른 컨테이너 관리 도구와 다릅니다.
이미지를 세상에 배포할 수 있는 몇 가지 방법이 있습니다.
이 장에서는 이러한 배포 방식에 대해 탐구하고, 자신의 프로젝트에 맞는 하나 이상의 방법을 선택하거나 사용할 수 있는 프레임워크를 제공합니다.
호스팅 레지스트리는 자동 빌드 도구와 함께 public 및 private registry를 제공합니다.
반대로, 개인 레지스트리를 실행하면 이미지 배포 인프라를 숨기고 커스터마이징할 수 있습니다.
배포 워크플로를 더 무겁게 커스터마이징하려면 Docker 이미지 배포 기능을 포기하고 자체 시스템을 구축해야 할 수도 있습니다.
일부 시스템은 아예 이미지를 배포 단위로 사용하는 방식을 버리고, 대신 이미지의 소스 파일을 배포할 수도 있습니다.
이 장에서는 이미지를 세상에 배포하거나 직장에서만 사용할 수 있는 방법을 선택하고 사용하는 방법을 배웁니다.
9.1 Choosing a distribution method
배포 방법을 선택하는 데 있어 가장 어려운 점은 자신의 상황에 적합한 방법을 선택하는 것입니다.
이를 돕기 위해, 이 장에서 소개하는 각 방법은 동일한 선택 기준으로 분석됩니다.
Docker로 소프트웨어를 배포할 때 알아야 할 첫 번째 사실은 보편적인 해결책은 존재하지 않는다는 것입니다.
배포 요구사항은 다양한 이유로 달라지며, 사용할 수 있는 방법도 여러 가지입니다.
모든 방법은 Docker 도구를 중심으로 이루어지기 때문에, 최소한의 노력으로 한 방법에서 다른 방법으로 마이그레이션할 수 있습니다.
가장 좋은 시작 방법은 전체 옵션 스펙트럼을 높은 수준에서 검토하는 것입니다.
9.1.1 A distribution spectrum
이미지 배포 스펙트럼은 다양한 수준의 유연성과 복잡성을 제공하는 여러 가지 방법을 제공합니다.
가장 유연성을 많이 제공하는 방법은 사용하기 가장 복잡할 수 있는 반면, 가장 간단한 방법은 일반적으로 제약이 가장 많습니다.
그림 9.1은 이러한 스펙트럼 전체를 보여줍니다.
스펙트럼에 포함된 방법은 Docker Hub와 같은 호스팅된 레지스트리부터 완전히 커스텀 배포 아키텍처 또는 소스 배포 방법까지 다양합니다. 이 중 일부 주제는 다른 것들보다 더 자세히 다룹니다. 특히, private registry에 초점을 맞추는데, 이는 유연성과 간단함 사이에서 가장 균형 잡힌 방법을 제공하기 때문입니다.
이러한 선택 스펙트럼은 사용할 수 있는 다양한 옵션을 보여주지만, 일관된 선택 기준이 있어야 어떤 방법을 사용할지 결정할 수 있습니다.
9.1.2 Selection criteria
이렇게 많은 옵션 중에서 자신의 요구에 맞는 최적의 배포 방법을 선택하는 것은 어려워 보일 수 있습니다.
이럴 때는 옵션을 이해하고, 선택 기준을 식별하며, 빠른 결정을 내리거나 대충 정착하려는 충동을 피해야 합니다.
다음에 제시된 선택 기준은 스펙트럼 전반의 차이점과 일반적인 비즈니스 우려를 기반으로 식별되었습니다.
결정을 내릴 때, 다음 요소가 각 상황에서 얼마나 중요한지 고려하세요:
- 비용(Cost)
- 가시성(Visibility)
- 전송 속도 또는 대역폭 오버헤드(Transport speed or bandwidth overhead)
- 지속 가능성 제어(Longevity control)
- 가용성 제어(Availability control)
- 접근 제어(Access control)
- 아티팩트 무결성(Artifact integrity)
- 아티팩트 기밀성(Artifact confidentiality)
- 필요한 전문 지식(Requisite expertise)
이 장의 나머지 부분에서는 각 배포 방법이 이러한 기준에 대해 어떻게 평가되는지 다룹니다.
Cost
비용(Cost)은 가장 명확한 기준이며, 배포 스펙트럼은 무료에서 매우 비싸거나 "복잡한" 수준까지 다양합니다.
일반적으로 비용이 낮을수록 좋지만, 비용은 대체로 가장 유연한 기준입니다.
예를 들어, 상황에 따라 아티팩트의 기밀성을 보장해야 한다면 대부분의 사람들은 비용을 기꺼이 감수할 것입니다.
Visibility
가시성(Visibility)은 배포 방법에서 두 번째로 명확한 기준입니다.
비공개 프로젝트나 내부 도구는 인가받지 않은 사람이 발견하기 어렵거나 불가능해야 합니다.
반대로, 공개 작업이나 오픈 소스 프로젝트는 채택을 촉진하기 위해 가능한 한 가시성을 높여야 합니다.
Transportation
전송 속도(Transportation speed)와 대역폭 오버헤드(Bandwidth overhead)는 그다음으로 유연한 기준입니다.
이미지 레이어, 동시 다운로드, 사전 빌드된 이미지를 활용하는 방법과 단일 이미지 파일(flat image files)이나
배포 시점에서 이미지를 빌드하는 방법에 따라 파일 크기와 이미지 설치 속도가 달라집니다.
전송 속도가 빠르거나 설치 대기 시간이 짧아야 하는 경우는 동기 요청을 서비스하기 위해 즉시 배포(Just-in-Time Deployment)를 사용하는 시스템에서 중요합니다.
반대로, 개발 환경이나 비동기 처리 시스템에서는 이러한 요구가 덜 중요합니다.
Longevity
지속 가능성 제어(Longevity control)는 기술적 문제보다는 비즈니스적인 우려입니다.
호스팅된 배포 방법은 다른 사람이나 회사의 비즈니스 문제에 영향을 받을 수 있습니다.
예를 들어, 호스팅된 레지스트리를 사용하는 옵션을 놓고 임원이 다음과 같은 질문을 할 수 있습니다:
"그들이 사업을 접거나 레지스트리 호스팅에서 방향을 전환하면 어떻게 되지?"
이 질문은 결국, 제3자의 비즈니스 요구가 우리의 요구보다 먼저 바뀔 가능성이 있나?"로 요약됩니다.
만약 이것이 당신에게 중요한 문제라면, 지속 가능성 제어가 중요할 것입니다.
Docker는 방법 간 전환을 간단하게 만들어주며, 전문 지식이나 비용과 같은 다른 기준이 이 문제보다 우선시될 수도 있습니다.
이러한 이유로 지속 가능성 제어는 비교적 유연한 기준 중 하나로 간주됩니다.
Availability
가용성 제어(Availability control)는 레지스트리의 가용성 문제를 해결할 수 있는 능력을 의미합니다.
호스팅된 솔루션은 가용성 제어를 제공하지 않습니다. 기업이 유료 고객에게 서비스 수준 계약(SLA)을 통해 가용성을 보장할 수는 있지만, 문제가 발생했을 때 이를 직접 해결할 방법은 없습니다. 반면, private 레지스트리나 커스텀 솔루션은 제어권과 책임을 모두 사용자의 손에 맡깁니다.
Integrity
아티팩트 무결성(Artifact integrity)과 기밀성(Confidentiality)은 배포 스펙트럼에서 덜 유연하고 더 기술적인 측면에 속합니다.
- 아티팩트 무결성은 파일과 이미지의 신뢰성과 일관성을 의미합니다.
- 무결성을 위반하는 사례:
- 중간자 공격(Man-in-the-middle attack): 공격자가 이미지 다운로드를 가로채고 내용을 자신만의 것으로 바꿔치기하는 경우.
- 악의적이거나 해킹된 레지스트리: 반환하는 페이로드(이미지 내용)에 대해 거짓말을 하는 경우.
CONFIDENTIALITY
아티팩트 기밀성(Artifact confidentiality)은 영업 비밀이나 독점 소프트웨어를 개발하는 회사에서 흔히 요구되는 사항입니다.
예를 들어, Docker를 사용해 암호화 자료를 배포하는 경우, 기밀성은 매우 중요한 문제가 됩니다.
아티팩트 무결성과 기밀성을 제공하는 기능은 배포 스펙트럼에 따라 다릅니다.
전반적으로, 디폴트로 제공되는 배포 보안 기능만으로는 가장 높은 수준의 기밀성이나 무결성을 제공하지 못합니다.
만약 이것이 주요 요구사항 중 하나라면, 정보 보안 전문가가 솔루션을 구현하고 검토해야 합니다.
EXPERTISE
배포 방법을 선택할 때 마지막으로 고려해야 할 것은 필요한 전문 지식 수준입니다.
호스팅된 방법을 사용하는 것은 간단하며, 도구에 대한 기계적인 이해만으로도 충분할 수 있습니다.
반면, 커스텀 이미지 또는 이미지 소스 배포 파이프라인을 구축하려면 관련 기술에 대한 전문 지식이 필요합니다.
만약 이러한 전문 지식이 없거나, 전문가의 도움을 받을 수 없다면, 더 복잡한 솔루션을 사용하는 것은 어려울 수 있습니다.
이 경우 추가 비용을 들여 부족한 부분을 해결할 수도 있습니다.
이 강력한 선택 기준을 바탕으로 다양한 배포 방법을 배우고 평가할 수 있습니다.
다음 섹션에서는 이 기준을 사용하여 각 방법을 Worst, Bad, Good, Better, Best로 평가합니다.
시작하기 가장 좋은 곳은 스펙트럼의 왼쪽 끝에 있는 호스팅된 레지스트리입니다.
9.2 Publishing with hosted registries
다시 말해, Docker 레지스트리는 Docker pull 커맨드로 접근할 수 있도록 저장소를 제공하는 서비스입니다.
이미지를 배포하는 가장 간단한 방법은 호스팅된 레지스트리를 사용하는 것입니다.
호스팅된 레지스트리는 제3자 벤더가 소유하고 운영하는 Docker 레지스트리 서비스입니다.
Docker Hub, Quay.io, Google Container Registry는 모두 호스팅된 레지스트리 제공자의 예입니다.
디폴트로 Docker는 Docker Hub에 이미지를 게시합니다.
Docker Hub 및 대부분의 다른 호스팅된 레지스트리는 공용(public) 및 개인(private) 레지스트리를 제공합니다(그림 9.2 참조).
이 책에서 사용된 예제 이미지는 Docker Hub와 Quay.io에 호스팅된 공용 저장소(public repositories)를 통해 배포됩니다.
이 섹션을 끝낼 때쯤, 여러분은 호스팅된 레지스트리를 사용해 자신만의 이미지를 게시하는 방법과
호스팅된 레지스트리가 선택 기준에 따라 어떻게 평가되는지 이해하게 될 것입니다.
9.2.1 Publishing with public repositories: “Hello World!” via Docker Hub
호스팅된 레지스트리에서 공용 저장소(public repositories)를 시작하는 가장 간단한 방법은
직접 소유한 저장소를 Docker Hub에 푸시(publish)하는 것입니다. 이를 위해 필요한 것은 Docker Hub 계정과 게시할 이미지뿐입니다. 아직 계정을 생성하지 않았다면, 지금 Docker Hub 계정에 가입하세요. 계정을 생성한 후, 게시할 이미지를 만들어야 합니다.
새로운 Dockerfile을 HelloWorld.df라는 이름으로 생성하고 다음 지침을 추가하세요:
FROM busybox:latest
CMD echo 'Hello World!'
Chapter 8장은 Dockerfile 커맨드를 다룹니다. 다시 말해, FROM 커맨드는 Docker 이미지 빌더에게 새 이미지를 만들 때 사용할 Base 이미지를 지정합니다. CMD 커맨드는 새 이미지의 디폴트 커맨드를 설정합니다. 이 이미지에서 생성된 컨테이너는 "Hello World!"를 표시하고 종료됩니다. 다음 커맨드를 사용하여 새 이미지를 빌드하세요:
docker image build \
-t <insert Docker Hub username>/hello-dockerfile \ <--- Insert your username
-f HelloWorld.df \
.
해당 커맨드(t 옵션 아규먼트)에서 Docker Hub의 username으로 반드시 대체하세요.
저장소에 접근하고 수정할 수 있는 권한은 Docker Hub에서의 저장소 이름의 username 부분을 기준으로 결정됩니다.
만약 자신의 username이 아닌 다른 이름으로 저장소를 생성하면, 해당 저장소를 게시할 수 없습니다.
Docker 커맨드라인 도구를 사용하여 Docker Hub에 이미지를 게시하려면,
클라이언트와 인증된 세션을 설정해야 합니다. 이를 위해 다음 커맨드를 사용하여 로그인하세요:
docker login
이 커맨드를 실행하면 사용자 이름, 이메일 주소, 비밀번호를 입력하라는 프롬프트가 표시됩니다.
각 항목은 --username, --email, --password 플래그를 사용하여 커맨드의 아규먼트로 전달할 수도 있습니다.
로그인하면, Docker 클라이언트는 인증된 다양한 레지스트리에 대한 자격 증명을 Map 형태로 유지합니다.
이 파일에는 username과 인증 토큰이 저장되며, 비밀번호는 저장되지 않습니다.
로그인한 후에는 호스팅된 레지스트리에 저장소를 푸시할 수 있습니다. 이를 위해 docker push 명령어를 사용하세요:
docker image push <insert Docker Hub username>/hello-dockerfile <--- Insert your username
해당 명령어를 실행하면 다음과 같은 출력이 생성됩니다:
The push refers to a repository
[dockerinaction/hello-dockerfile] (len: 1)
7f6d4eb1f937: Image already exists
8c2e06607696: Image successfully pushed
6ce2e90b0bc7: Image successfully pushed
cf2616975b4a: Image successfully pushed
Digest:
sha256:ef18de4b0ddf9ebd1cf5805fae1743181cbf3642f942cae8de7c5d4e375b1f20
이 커맨드 출력에는 업로드 상태와 결과적으로 생성된 리포지토리 내용의 다이제스트가 포함됩니다.
푸시 작업은 원격 레지스트리에 리포지토리를 생성하고, 새로운 레이어 각각을 업로드한 뒤, 적절한 태그를 생성합니다.
푸시 작업이 완료되면, 공용(public) 리포지토리는 전 세계에 공개됩니다.
이를 확인하려면 username과 새 리포지토리를 검색하세요.
예를 들어, 다음 커맨드를 사용해 dockerinaction 사용자가 소유한 예제를 찾을 수 있습니다:
Docker Hub를 사용하여 첫 번째 이미지를 배포한 후, 이 방법이 선택 기준에 어떻게 부합하는지 고려해야 합니다(테이블 9.1 참조).
| Criteria | Rating | Notes |
| Cost | Best | 호스팅된 레지스트리의 public 리포지토리들은 거의 항상 무료입니다. 이 가격을 능가하기는 어렵습니다. Docker를 처음 시작하거나 오픈 소스 소프트웨어를 게시할 때 특히 유용합니다. |
| Visibility | Best | 호스팅된 레지스트리는 소프트웨어 배포를 위한 잘 알려진 허브입니다. 프로젝트를 대중에게 널리 알리고 가시성을 높이고 싶다면, 호스팅된 레지스트리의 public 리포지토리가 명백한 배포 선택입니다. |
| Transport speed/size |
Better | Docker Hub와 같은 호스팅된 레지스트리는 레이어를 인식(layer-aware)*하며, 클라이언트가 이미 가지고 있지 않은 레이어만 전송하도록 Docker 클라이언트와 함께 작동합니다. 또한, 여러 리포지토리들을 전송해야 하는 풀(pull) 작업은 이러한 전송을 병렬로 수행합니다. 이러한 이유로, 호스팅된 리포지토리에서 이미지를 배포하는 속도는 빠르며, 전송되는 데이터(payload)는 최소화됩니다. |
| Longevity control | Good | 호스팅된 레지스트리에 대해 지속 가능성 제어는 불가능합니다. 그러나 모든 레지스트리는 Docker 레지스트리 API를 준수하므로, 한 호스트에서 다른 호스트로의 마이그레이션은 비용이 적게 드는 작업이 될 것입니다. |
| Availability control | Worst | 호스팅된 레지스트리에 대해서는 가용성 제어가 불가능합니다. |
| Access control | Better | public 리포지토리들은 읽기 접근에 대해 공개(public)되어 있습니다. 그러나 쓰기 접근은 호스트가 마련한 메커니즘에 의해 여전히 제어됩니다. Docker Hub의 public 리포지토리에 대한 쓰기 접근은 두 가지 방식으로 제어됩니다:
|
| Artifact integrity | Best | 현재 Docker 레지스트리 API의 버전인 V2는 내용 기반 이미지(Content-Addressable Images)를 제공합니다. V2 API를 통해 특정 암호화 서명을 가진 이미지를 요청할 수 있습니다. Docker 클라이언트는 서명을 다시 계산하고 요청된 서명과 비교하여 반환된 이미지의 무결성을 검증합니다. V2 레지스트리 API를 인식하지 못하는 구버전 Docker는 이 기능을 지원하지 않으며 V1을 사용합니다. 이 경우, 또는 서명이 알려지지 않은 다른 경우에는 호스트가 제공하는 인가 및 저장 데이터 보안 기능에 높은 신뢰를 두게 됩니다. |
| Confidentiality | Worst | 호스팅된 레지스트리와 public 리포지토리들은 평문 비밀(cleartext secrets)이나 민감한 코드를 저장하거나 배포하는 데 절대 적합하지 않습니다. 비밀 정보(secrets)에는 비밀번호, API 키, 인증서 등이 포함된다는 점을 기억하세요. 이러한 정보는 누구나 접근할 수 있게 됩니다. |
| Requisite experience |
Best | 호스팅된 레지스트리의 public 리포지토리를 사용하는 데는 Docker에 대한 최소한의 이해와 웹사이트를 통해 계정을 설정할 수 있는 능력만 필요합니다. 이 솔루션은 모든 Docker 사용자가 손쉽게 접근할 수 있습니다. |
호스팅된 레지스트리의 public 리포지토리는 오픈 소스 프로젝트 소유자나 Docker를 처음 시작하는 사람들에게 가장 적합한 선택입니다. 그러나 사람들은 여전히 인터넷에서 다운로드받아 실행하는 소프트웨어에 대해 회의적이므로, 소스를 공개하지 않는 public 리포지토리는 일부 사용자에게 신뢰를 얻기 어려울 수 있습니다. 호스팅된(신뢰할 수 있는) 빌드는 이 문제를 어느 정도 해결할 수 있습니다.
9.2.2 Private hosted repositories
Private repositories는 운영 및 제품 관점에서 Public repositories와 유사합니다.
대부분의 레지스트리 제공자는 두 옵션을 모두 제공하며, 웹사이트를 통해 이를 설정하는 방식의 차이는 최소화됩니다.
Docker 레지스트리 API는 두 리포지토리 유형을 구분하지 않으므로, 두 가지를 모두 제공하는 레지스트리 제공자는 일반적으로 웹사이트, 애플리케이션, 또는 API를 통해 private 레지스트리를 설정하도록 요구합니다.
private 리포지토리를 사용하는 도구는 public 리포지토리를 사용하는 도구와 동일하며, 한 가지 예외가 있습니다.
private 리포지토리에서 이미지를 설치하려면 docker image pull 또는 docker container run을 실행하기 전에
리포지토리가 호스팅된 레지스트리에서 인증해야 합니다. 이를 위해, 이미지를 업로드할 때와 마찬가지로 docker login 커맨드를 사용합니다.
다음 커맨드는 Docker Hub와 Quay.io에서 제공하는 레지스트리로 인증하라는 프롬프트를 표시합니다.
계정을 생성하고 인증한 후, 이 세 레지스트리에서 public 및 private 리포지토리에 대한 완전한 접근 권한을 얻을 수 있습니다.
login 하위 커맨드는 선택적으로 서버 아규먼트(server argument)를 받을 수 있습니다:
docker login
# Username: dockerinaction
# Password:
# Email: book@dockerinaction.com
# WARNING: login credentials saved in /Users/xxx/.dockercfg.
# Login Succeeded
docker login quay.io
# Username: dockerinaction
# Password:
# Email: book@dockerinaction.com
# WARNING: login credentials saved in /Users/xxx/.dockercfg.
# Login Succeeded
private 호스팅 리포지토리가 당신에게 적합한 배포 솔루션인지 결정하기 전에, 그들이 여러분의 선택 기준을 어떻게 충족할 수 있는지 고려하세요(테이블 9.2 참조).
Table 9.2 Performance of private hosted repositories
| Criteria | Rating | Notes |
| Cost | Good | private 리포지토리의 비용은 보통 필요한 리포지토리의 수에 따라 증가합니다. 요금제는 보통 5개의 리포지토리에 몇 달러에서 50개의 저장소에 약 50달러까지 다양합니다. 여기에는 저장 공간 비용과 월간 가상 서버 호스팅 비용이 주요 요인으로 작용합니다. 50개 이상의 리포지토리가 필요한 사용자나 조직은 자체 private 레지스트리를 운영하는 것이 더 적합할 수 있습니다. |
| Visibility | Best | private 리포지토리는 정의상 비공개입니다. 이들은 일반적으로 색인에서 제외되며, 리포지토리의 존재를 확인하기 전에 인증이 필요합니다. private 리포지토리는 자체 레지스트리를 운영하는 데 드는 부담을 피하려는 조직이나 소규모 개인 프로젝트에 적합한 도구입니다. 그러나 private 리포지토리는 상업용 소프트웨어의 가용성을 알리거나 오픈 소스 이미지를 배포하는 데는 적합하지 않습니다. |
| Transport speed/size |
Better | Docker Hub와 같은 모든 호스팅된 레지스트리는 이미지 전송에 사용되는 대역폭을 최소화하고, 클라이언트가 이미지의 레이어를 병렬로 전송할 수 있도록 합니다. 인터넷을 통해 파일을 전송할 때 발생할 수 있는 지연(latency)을 제외하면, 호스팅된 레지스트리는 항상 다른 비레지스트리(non-registry) 솔루션보다 뛰어난 성능을 보여야 합니다. |
| Longevity control | Good | 호스팅된 레지스트리에 대해 지속 가능성 제어는 불가능합니다. 그러나 모든 레지스트리는 Docker 레지스트리 API를 준수하므로, 한 호스트에서 다른 호스트로의 마이그레이션은 비용이 적게 드는 작업이 될 것입니다. |
| Availability control | Worst/Ok | 호스팅된 레지스트리는 가용성 제어를 제공하지 않습니다. 그러나 public 리포지토리와 달리, private 리포지토리를 사용하는 경우 유료 고객이 됩니다. 유료 고객은 더 강력한 SLA 보장이나 지원 인력에 대한 접근 권한을 가질 수 있습니다. |
| Access control | Better |
private 리포지토리에 대한 읽기 및 쓰기 접근 권한은 인가된 사용자로 제한됩니다.
|
| Artifact integrity | Best | 모든 호스팅된 레지스트리가 V2 레지스트리 API와 내용 기반 이미지(Content-Addressable Images)를 지원할 것으로 기대하는 것이 합리적입니다. |
| Confidentiality | Worst | 이 저장소들이 제공하는 비공개성에도 불구하고, 평문 비밀(cleartext secrets)이나 영업 비밀 코드를 저장하는 데는 절대 적합하지 않습니다. 레지스트리는 요청된 리소스에 대해 사용자 인증과 인가를 요구하지만, 이러한 메커니즘에는 여러 잠재적인 문제가 있을 수 있습니다. 예를 들어, 제공자가 취약한 자격 증명 저장 방식을 사용할 수 있고, 약한 인증서나 분실된 인증서를 가질 수 있으며, 아티팩트를 저장 상태에서 암호화하지 않을 가능성이 있습니다. 마지막으로, 비밀 자료가 레지스트리 제공자의 직원에게 접근 가능하지 않아야 합니다. |
| Requisite experience |
Best | public 리포지토리와 마찬가지로, 호스팅된 레지스트리에서 private 리포지토리를 사용하는 데는 Docker에 대한 최소한의 이해와 웹사이트를 통해 계정을 설정할 수 있는 능력만 있으면 됩니다. 이 솔루션은 모든 Docker 사용자가 쉽게 접근할 수 있습니다. |
개인 및 소규모 팀은 호스팅된 private 리포지토리에서 가장 큰 효용성을 발견할 것입니다.
저렴한 비용과 기본적인 인증 기능은 예산이 적은 프로젝트나 보안 요구사항이 최소한인 개인 프로젝트에 적합합니다.
반면, 더 높은 수준의 비밀 유지가 필요하고 적절한 예산을 보유한 대규모 기업이나 프로젝트는 자체 private 레지스트리를 운영하는 것이 더 적합할 수 있습니다.
9.3 Introducing private registries
가용성 제어, 지속 가능성 제어, 또는 비밀 유지가 필수 요구사항인 경우, private 레지스트리를 운영하는 것이 최선의 선택일 수 있습니다. 이렇게 하면 Docker의 pull 및 push 메커니즘과의 상호운용성을 유지하면서 환경에 대한 학습 곡선을 추가하지 않고도 제어권을 얻을 수 있습니다.
사람들은 호스팅된 레지스트리를 사용할 때와 동일한 방식으로 private 레지스트리와 상호작용할 수 있습니다.
Docker 이미지 레지스트리를 운영하기 위한 무료 및 상업적으로 지원되는 여러 소프트웨어 패키지가 제공됩니다.
만약 조직에서 운영 체제 또는 애플리케이션 소프트웨어 패키지를 위한 상업적 아티팩트 리포지토리를 사용 중이라면,
그 리포지토리는 아마도 Docker 이미지 레지스트리 API를 지원할 것입니다.
비프로덕션 이미지 레지스트리를 운영하기 위한 간단한 옵션은 Docker의 레지스트리 소프트웨어를 사용하는 것입니다.
Docker 레지스트리(Distribution)는 오픈 소스 소프트웨어로 제공되며, Apache 2 라이선스 하에 배포됩니다.
이 소프트웨어의 제공과 관대한 라이선스 덕분에 자체 레지스트리를 운영하는 엔지니어링 비용을 낮출 수 있습니다.
그림 9.3은 private 레지스트리가 배포 스펙트럼의 중간에 위치한다는 것을 보여줍니다.
private 레지스트리를 운영하는 것은 다음과 같은 특별한 인프라 사용 사례가 있는 경우 훌륭한 배포 방법이 될 수 있습니다:
- 지역별 이미지 캐시
- 지역성(Locality) 또는 가시성(Visibility)을 위한 팀별 이미지 배포
- 환경 또는 배포 단계별 이미지 풀 관리
- 이미지 승인을 위한 기업 프로세스
- 외부 이미지의 지속 가능성 제어
이것이 최선의 선택인지 결정하기 전에, 선택 기준에 따라 상세히 설명된 비용을 고려하세요(테이블 9.3 참조).
Table 9.3 Performance of private registries
| Criteria | Rating | Notes |
| Cost | Good | 최소한, private 레지스트리는 하드웨어 오버헤드(가상 또는 물리), 지원 비용, 그리고 실패 위험을 추가로 발생시킵니다. 그러나 이 커뮤니티는 오픈 소스 소프트웨어를 구축함으로써 private 레지스트리를 배포하는 데 필요한 대부분의 엔지니어링 작업을 이미 투자했습니다. 비용은 호스팅된 레지스트리와는 다른 차원에서 확장됩니다. 호스팅된 레지스트리의 비용이 리포지토리의 개수에 따라 증가하는 반면, private 레지스트리의 비용은 트랜잭션 비율과 스토리지 사용량에 따라 증가합니다. 예를 들어, 트랜잭션 비율이 높은 시스템을 구축하는 경우, 수요를 처리할 수 있도록 레지스트리 호스트 수를 확장해야 합니다. 마찬가지로, 작은 이미지를 일정 개수 제공하는 레지스트리는 동일한 개수의 큰 이미지를 제공하는 레지스트리보다 저장 비용이 낮습니다. |
| Visibility | Good | private 레지스트리는 사용자가 결정한 만큼 가시성이 높아질 수 있습니다. 그러나 사용자가 소유하고 전 세계에 공개한 레지스트리라 하더라도, Docker Hub와 같은 광고된 인기 레지스트리보다는 가시성이 낮을 것입니다. |
| Transport speed/size |
Best | 클라이언트와 레지스트리 간의 작업 지연(latency)은 두 노드 간의 네트워크 성능과 레지스트리의 부하에 따라 달라집니다. 이 변수들로 인해, private 레지스트리는 호스팅된 레지스트리보다 더 빠르거나 느릴 수 있습니다. 대규모 배포나 내부 인프라를 운영하는 대부분의 사람들은 private 레지스트리를 매력적으로 느낄 것입니다. private 레지스트리는 인터넷 또는 데이터센터 간 네트워크에 대한 의존성을 제거하고, 외부 네트워크 제약에 비례하여 지연을 개선합니다. 이 솔루션은 Docker 레지스트리를 사용하므로, 호스팅된 레지스트리 솔루션과 동일한 병렬 처리 이점을 공유합니다. |
| Longevity control | Best | 레지스트리 소유자로서 솔루션의 지속 가능성에 대해 완전한 제어권을 가질 수 있습니다. |
| Availability control | Best | 레지스트리 소유자로서 가용성에 대해 완전한 제어권을 가질 수 있습니다. |
| Access control | Good |
레지스트리 소프트웨어는 기본적으로 인증이나 인가 기능을 포함하지 않습니다.
그러나 이러한 기능을 구현하는 것은 최소한의 엔지니어링 작업으로 가능합니다. |
| Artifact integrity | Best | 레지스트리 API의 버전 2는 내용 기반 이미지(Content-Addressable Images)를 지원하며, 오픈 소스 소프트웨어는 플러그형 스토리지 백엔드를 지원합니다. 추가적인 무결성 보호를 위해, 네트워크에서 TLS 사용을 강제하고, 저장 시 암호화(encryption at rest)를 지원하는 백엔드 스토리지를 사용할 수 있습니다. |
| Confidentiality | Good | private 레지스트리는 영업 비밀이나 비밀 자료를 저장하는 데 적합한 스펙트럼 상의 첫 번째 솔루션입니다. 인증 및 인가 메커니즘을 직접 제어할 수 있으며, 네트워크 및 전송 중 보안 메커니즘도 제어할 수 있습니다. 가장 중요한 것은, 저장된 데이터를 보관 시 암호화(at-rest storage)로 제어할 수 있다는 점입니다. 시스템이 비밀 정보를 안전하게 유지하도록 구성할 수 있는 권한이 여러분에게 있습니다. |
| Requisite experience |
Good | 로컬 레지스트리를 시작하고 실행하는 데는 기본적인 Docker 경험만 필요합니다. 그러나 고가용성을 요구하는 프로덕션 환경의 private 레지스트리를 운영하고 유지 관리하려면 여러 기술에 대한 경험이 필요합니다. 필요한 기술 세트는 활용하려는 기능에 따라 다르지만, 일반적으로 다음과 같은 기술에 익숙해야 합니다:
여기에는 Artifactory나 Nexus와 같은 전통적인 아티팩트 저장소에서 GitLab과 같은 소프트웨어 전달 시스템에 이르기까지 다양한 옵션이 포함됩니다. |
호스팅된 레지스트리에서 개인 레지스트리로 전환할 때 가장 큰 트레이드오프(trade-off)는
유연성과 제어권을 얻는 대신, 솔루션을 구축하고 유지 관리하기 위해 더 깊고 폭넓은 엔지니어링 경험이 필요하다는 점입니다.
Docker 이미지 레지스트리는 종종 대량의 저장 공간을 소모하므로, 분석 시 이를 반드시 고려해야 합니다.
이 섹션의 나머지 부분에서는 가장 복잡한 레지스트리 배포 설계를 제외한 모든 구현에 필요한 내용을 다루고, 환경 내에서 커스터마이징 기회를 강조합니다.
9.3.1 Using the registry image
어떤 이유에서든 Docker 레지스트리 소프트웨어를 사용하는 것은 쉽습니다.
이 배포 소프트웨어는 Docker Hub의 registry라는 리포지토리에서 제공됩니다.
컨테이너에서 로컬 레지스트리를 시작하는 것은 다음 싱글 라인의 커맨드로 가능합니다:
$ docker run -d -p 5000:5000 \
> -v "$(pwd)"/data:/tmp/registry-dev \
> --restart=always --name local-registry registry:2
Docker Hub를 통해 배포되는 이 이미지는 클라이언트의 Docker 데몬이 실행되는 머신에서 비보안 액세스(insecure access)에 맞게 구성되어 있습니다. 레지스트리를 시작하면, 다른 레지스트리와 마찬가지로 docker pull, run, tag, push 커맨드를 사용하여 레지스트리를 사용할 수 있습니다. 이 경우, 레지스트리 위치는 localhost:5000입니다. 이제 시스템의 아키텍처는 그림 9.4에서 설명된 것과 일치해야 합니다.
외부 이미지 종속성에 대해 엄격한 버전 제어를 원하는 회사는 Docker Hub와 같은 외부 소스에서 이미지를 가져와 자체 레지스트리에 복사합니다. 이 작업은 작성자가 소스 이미지를 업데이트하거나 삭제할 때 중요한 이미지가 예기치 않게 변경되거나 사라지는 것을 방지하기 위해 수행할 수 있습니다. 새 레지스트리에서 작업하는 것이 어떤 느낌인지 이해하려면, Docker Hub에서 이미지를 가져와 새 레지스트리에 복사하는 워크플로를 고려해보세요:
docker image pull dockerinaction/ch9_registry_bound (1)
docker image ls -f "label=dia_excercise=ch9_registry_bound" (2)
docker image tag dockerinaction/ch9_registry_bound \
localhost:5000/dockerinaction/ch9_registry_bound
docker image push localhost:5000/dockerinaction/ch9_registry_bound (3)(1) Docker Hub에서 데모 이미지를 pull 합니다
(2) 레이블 필터를 사용하여 이미지가 검색 가능한지 확인합니다.
(3) 데모 이미지를 레지스트리에 push 합니다
이 네 가지 커맨드를 실행하면 Docker Hub에서 로컬 리포지토리로 예제 리포지토리를 복사합니다. 레지스트리를 시작한 것과 같은 위치에서 이러한 커맨드들을 실행하면 새로 만든 데이터 하위 디렉터리에 새 레지스트리 데이터가 들어 있음을 알 수 있습니다.
9.3.2 Consuming images from your registry
Docker 생태계와의 긴밀한 통합은 마치 소프트웨어가 이미 컴퓨터에 설치된 것처럼 느끼게 해줍니다. 로컬 레지스트리를 사용하는 등 인터넷 지연이 제거된 경우에는 분산된 구성 요소와 작업하는 것처럼 느껴지지 않을 수도 있습니다. 이러한 이유로 로컬 레포지토리에 데이터를 푸시하는 작업 자체는 그다지 흥미롭지 않을 수 있습니다.
다음 커맨드 세트는 여러분이 실제 레지스트리와 작업하고 있다는 것을 인상 깊게 보여줄 것입니다. 이 커맨드들은 Docker 데몬의 로컬 캐시에서 예제 레포지토리를 제거하고, 제거되었음을 보여준 뒤, personal 레지스트리에서 이를 다시 설치하는 과정을 시연할 것입니다.
$docker image rm \
> dockerinaction/ch9_registry_bound \
> localhost:5000/dockerinaction/ch9_registry_bound <--- Removes tagged reference
$ docker image ls -f "label=dia_excercise=ch9_registry_bound"
$ docker image pull localhost:5000/dockerinaction/ch9_registry_bound <--- Pulls from registry
again
$ docker image ls -f "label=dia_excercise=ch9_registry_bound" <--- Demonstrates that image
is back
$ docker container rm -vf local-registry <--- Cleans up local registry
이 레지스트리는 로컬에서 원하는 만큼 사용할 수 있지만, 디폹트로 보안이 설정되지 않은 구성은 원격 Docker 클라이언트가 레지스트리를 사용하는 것을 차단합니다(특히 보안이 설정되지 않은 접근을 허용하지 않는 한). 이는 프로덕션 환경에서 레지스트리를 배포하기 전에 해결해야 할 몇 안 되는 문제 중 하나입니다.
Docker 레지스트리를 사용하는 가장 유연한 배포 방법이 바로 이 방법입니다. 전송, 저장, 아티팩트 관리에 대해 더 높은 수준의 제어가 필요하다면, 수동 배포 시스템에서 이미지를 직접 다루는 것을 고려해야 합니다.
9.4 Manual image publishing and distribution
도커 이미지는 파일이며, 다른 파일과 마찬가지로 배포할 수 있습니다. 소프트웨어를 웹사이트, 파일 전송 프로토콜(FTP) 서버, 기업용 저장 네트워크, 또는 P2P 네트워크를 통해 제공하는 경우가 흔히 있습니다. 이러한 배포 채널 중 어떤 것이든 이미지 배포에 사용할 수 있습니다. 심지어 수신자가 명확한 경우 이메일이나 USB 드라이브를 사용하는 것도 가능합니다. 수동 이미지 배포 방법은 궁극적인 유연성을 제공하며, 예를 들어 이벤트에서 여러 사람에게 이미지를 동시에 배포하거나 보안이 필요한 에어갭 네트워크로 배포하는 등의 다양한 사용 사례를 지원합니다.
이미지를 파일로 다룰 때는 Docker를 사용하여 로컬 이미지를 관리하고 파일을 생성하는 것에만 집중합니다. 그 외의 모든 문제는 사용자가 직접 구현해야 합니다. 이러한 기능의 부재로 인해 수동 이미지 게시 및 배포는 유연성 면에서는 두 번째로 뛰어나지만, 가장 복잡한 배포 방법이 됩니다. 이 섹션에서는 그림 9.5의 스펙트럼에 표시된 맞춤형 이미지 배포 인프라를 다룹니다.
이미지를 파일로 다루는 모든 방법은 이미 다뤘습니다. 3장에서 이미지를 Docker에 로드하고 하드 드라이브에 저장하는 방법을 다뤘으며, 7장에서는 평탄화(flat)된 이미지로 전체 파일 시스템을 내보내고 가져오는 방법을 설명했습니다. 이러한 기술들은 그림 9.6에 표시된 것과 같은 배포 워크플로우를 구축하기 위한 기초가 됩니다.
이 워크플로우는 Docker를 사용하여 이미지를 생성하고 배포를 준비하는 과정을 일반화한 것입니다. docker image build를 사용하여 이미지를 생성하고, docker image save 또는 docker container export를 사용하여 이미지 파일을 생성하는 방법에 익숙해야 합니다. 이러한 작업은 각각 한 번의 커맨드로 수행할 수 있습니다.
이미지를 파일 형태로 만든 후에는 어떤 파일 전송 방법도 사용할 수 있습니다. 그림 9.6에 표시되지 않은 커스텀 구성 요소 중 하나는 이미지를 전송 수단에 업로드하는 메커니즘입니다. 이 메커니즘은 Dropbox와 같은 파일 공유 도구가 감시하는 폴더일 수도 있고, 주기적으로 실행되거나 새 파일에 반응하여 FTP나 HTTP를 사용해 파일을 원격 서버로 푸시하는 커스텀 코드일 수도 있습니다. 어떤 메커니즘이든, 이 일반적인 구성 요소를 통합하려면 일정한 노력이 필요합니다.
그림에는 또한 클라이언트가 이미지를 수집하고 배포된 이미지를 사용하여 컨테이너를 생성하는 과정도 나와 있습니다. 클라이언트는 이미지의 위치를 파악하고 원격 소스에서 이미지를 가져오는 프로세스나 메커니즘이 필요합니다. 클라이언트가 이미지 파일을 확보한 후에는 docker image load나 import 커맨드를 사용하여 전송을 완료할 수 있습니다.
수동 이미지 배포 방법은 배포 문제의 구체적인 내용을 알지 못하면 선택 기준에 따라 평가하기 어렵습니다. Docker가 아닌 배포 채널을 사용하면 완전한 제어권을 가지게 되어 특이한 요구 사항을 처리할 수 있습니다. 선택 기준에 따라 옵션을 어떻게 평가할지는 전적으로 사용자에게 달려 있습니다. 테이블 9.4는 수동 이미지 배포 방법이 선택 기준에 따라 어떻게 평가되는지 다룹니다.
Table 9.4 Performance of custom image distribution infrastructure
| Criteria | Rating | Notes |
| Cost | Good | 배포 비용은 대역폭, 저장 공간, 하드웨어 요구 사항에 의해 결정됩니다. 클라우드 스토리지와 같은 호스팅 배포 솔루션은 이러한 비용을 패키지로 묶어 제공하며, 일반적으로 사용량이 증가할수록 단위당 가격이 낮아집니다. 그러나 호스팅 솔루션은 인력 비용 및 기타 여러 가지 부가 혜택을 포함하기 때문에, 직접 소유한 메커니즘과 비교했을 때 비용이 더 높아질 수 있습니다. |
| Visibility | Bad | 대부분의 수동 배포 방법은 특수하며, public 또는 private 레지스트리보다 홍보하고 사용하는 데 더 많은 노력이 필요합니다. 예로는 인기 있는 웹사이트나 잘 알려진 파일 배포 허브를 사용하는 것이 포함될 수 있습니다. |
| Transport speed/size |
Good | 전송 속도는 전송 방식에 따라 달라지는 반면, 파일 크기는 레이어드 이미지(layered images)를 사용할지 평탄화된 이미지(flattened images)를 사용할지에 따라 결정됩니다. 레이어드 이미지는 이미지의 히스토리, 컨테이너 생성 메타데이터, 삭제되거나 덮어씌워진 오래된 파일들을 유지합니다. 반면, 평탄화된 이미지는 파일 시스템에 있는 현재 파일 집합만 포함합니다. |
| Longevity control | Bad | 독점 프로토콜, 도구, 또는 개방적이지 않거나 사용자가 제어할 수 없는 기술을 사용하는 경우 지속성 관리에 영향을 미칩니다. 예를 들어, Dropbox와 같은 호스팅된 파일 공유 서비스를 사용해 이미지 파일을 배포하면 지속성에 대한 제어권이 없습니다. 반면에, 친구와 USB 드라이브를 교환하는 방식은 두 사람이 USB 드라이브를 계속 사용하기로 결정한 기간 동안 지속됩니다. |
| Availability control | Best | 가용성 제어가 중요한 요소라면, 자신이 소유한 전송 메커니즘을 사용할 수 있습니다. |
| Access control | Bad |
필요한 접근 제어 기능을 갖춘 전송 방식을 사용하거나 파일 암호화를 사용할 수 있습니다. 예를 들어, 특정 Key로 이미지 파일을 암호화하는 시스템을 구축하면, 올바른 Key를 가진 사람만이 해당 이미지를 접근할 수 있도록 보장할 수 있습니다.
|
| Artifact integrity | Bad | 무결성 검증은 광범위한 배포를 위해 구현하기에 더 비용이 많이 드는 기능입니다. 최소한 암호화된 파일 서명을 광고하고, docker image save와 load를 사용하여 이미지와 레이어 서명을 유지하는 아카이브를 생성하기 위한 신뢰할 수 있는 커뮤니케이션 채널이 필요합니다. |
| Confidentiality | Good | 저렴한 암호화 도구를 사용하여 콘텐츠 비밀성을 구현할 수 있습니다. 콘텐츠 비밀성뿐만 아니라 교환 자체의 비밀성(메타 비밀성)이 필요한 경우, 호스팅 도구를 피하고 HTTPS, SFTP, SSH, 또는 오프라인과 같은 비밀성을 제공하는 전송 방식을 사용하는 것이 좋습니다. |
| Requisite experience |
Good | 호스팅 도구는 일반적으로 사용의 용이성을 위해 설계되어 있으며, 워크플로우에 통합하는 데 필요한 경험 수준이 낮습니다. 하지만 대부분의 경우, 소유한 간단한 도구를 동일하게 쉽게 사용할 수 있습니다. |
수동 배포에도 동일한 기준이 적용되지만, 특정 전송 방법의 컨텍스트 없이 이를 논의하는 것은 어렵습니다.
9.4.1 A sample distribution infrastructure using FTP
생략...
9.5 Image source-distribution workflows
이미지 대신 이미지 소스를 배포할 경우, Docker 배포 워크플로우를 모두 생략하고 Docker 이미지 빌더에만 의존하게 됩니다. 수동 이미지 게시 및 배포와 마찬가지로, 소스 배포 워크플로우는 특정 구현의 컨텍스트에서 선택 기준에 따라 평가되어야 합니다.
GitHub의 Git과 같은 호스팅 소스 제어 시스템을 사용하는 것과 rsync와 같은 파일 백업 도구를 사용하는 것은 매우 다른 특성을 가집니다. 어느 정도 소스 배포 워크플로우는 수동 이미지 게시 및 배포 워크플로우의 문제를 포괄하는 상위 집합(super set)을 갖고 있습니다. 워크플로우를 구축해야 하지만, docker save, load, export, import 명령의 도움 없이 이루어져야 합니다. Producers는 소스를 어떻게 패키징할지 결정해야 하며, consumers는 그 소스가 어떻게 패키징되었는지와 이미지 빌드 방법을 이해해야 합니다. 이러한 확장된 인터페이스로 인해 소스 배포 워크플로우는 가장 유연하면서도 잠재적으로 가장 복잡한 배포 방법이 됩니다. 그림 9.8은 소스 배포가 스펙트럼의 가장 복잡한 끝에 위치해 있음을 보여줍니다.
이미지 소스 배포는 가장 복잡해질 가능성이 높음에도 불구하고 가장 일반적인 방법 중 하나입니다. 인기 있는 버전 관리 소프트웨어는 소스 배포의 확장된 인터페이스로 인한 많은 복잡성을 처리해줍니다.
9.5.1 Distributing a project with Dockerfile on GitHub
Dockerfile과 GitHub을 사용하여 이미지 소스를 배포할 경우, 이미지 컨슈머는 GitHub 리포지토리를 직접 클론한 후 docker image build를 사용하여 로컬에서 이미지를 빌드합니다. 소스 배포를 통해 게시자는 Docker Hub나 다른 Docker 레지스트리에 계정을 등록하지 않아도 이미지를 배포할 수 있습니다.
프로듀서가 기존 프로젝트, Dockerfile, GitHub 리포지토리를 보유하고 있다고 가정하면, 그들의 배포 워크플로우는 다음과 같이 진행됩니다:
git init
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git add Dockerfile
# git add *whatever other files you need for the image*
git commit -m "first commit"
git remote add origin https://github.com/<your username>/<your repo>.git
git push -u origin master
한편, 컨슈머는 다음과 같은 일반적인 커맨드 세트를 사용하게 됩니다:
git clone https://github.com/<your username>/<your repo>.git
cd <your-repo>
docker image build -t <your username>/<your repo> .이 모든 단계는 일반적인 Git 또는 GitHub 사용자가 익숙하게 사용하는 것이며, 테이블 9.6에 나와 있습니다.
Table 9.6 Performance of image source distribution via GitHub
| Criteria | Rating | Notes |
| Cost | Best |
Public GitHub 리포지토리를 사용하는 경우 비용이 발생하지 않습니다.
|
| Visibility | Best | GitHub는 오픈 소스 도구를 위한 매우 가시성이 높은 플랫폼입니다. 뛰어난 소셜 및 검색 기능을 제공하여 프로젝트를 쉽게 발견할 수 있도록 합니다. |
| Transport speed/size |
Good | 이미지 소스를 배포함으로써 다른 레지스트리를 베이스 레이어로 활용할 수 있습니다. 이를 통해 전송 및 저장 부담을 줄일 수 있습니다. GitHub는 또한 콘텐츠 전송 네트워크(CDN)를 제공하며, 이를 통해 전 세계 클라이언트가 GitHub의 프로젝트에 낮은 네트워크 지연으로 접근할 수 있도록 합니다. |
| Longevity control | Bad | Git은 인기 있는 도구로 당분간 사용될 가능성이 높지만, GitHub 또는 다른 호스팅 버전 관리 제공업체와 통합할 경우 지속성에 대한 제어권을 포기하게 됩니다. |
| Availability control | Worst | GitHub 또는 다른 호스팅된 버전 관리 제공업체에 의존하면 가용성에 대한 제어권이 없어집니다. |
| Access control | Good |
GitHub 또는 다른 호스팅된 버전 관리 제공업체는 private 리포지토리를 위한 접근 제어 도구를 제공합니다.
|
| Artifact integrity | Good | 이 솔루션은 빌드 프로세스의 일부로 생성된 이미지나 클라이언트 머신에 클론된 소스에 대해 무결성을 제공하지 않습니다. 하지만 무결성은 버전 관리 시스템의 핵심 목적입니다. 무결성 문제는 명확히 드러날 것이며, 표준 Git 프로세스를 통해 쉽게 복구할 수 있습니다. |
| Confidentiality | Worst | public 프로젝트는 소스 비밀성을 제공하지 않습니다. |
| Requisite experience |
Good | 이미지 프로듀서와 컨슈머는 Dockerfile, Docker 빌더, 그리고 Git 도구에 익숙해야 합니다. |
이미지 소스 배포는 모든 Docker 배포 도구와 분리되어 있습니다. 이미지 빌더에만 의존함으로써 사용할 수 있는 어떤 배포 도구 세트도 자유롭게 채택할 수 있습니다. 만약 특정 배포 또는 소스 제어 도구 세트에 종속되어 있다면, 이것이 여러분의 기준을 충족할 수 있는 유일한 옵션일 수 있습니다.
Summary
이 장에서는 다양한 소프트웨어 배포 메커니즘과 각 메커니즘에서 Docker가 기여하는 가치를 다루었습니다. 최근 배포 채널을 구현했거나 현재 구현 중인 독자는 자신들의 솔루션에 대한 추가적인 통찰을 얻을 수 있습니다. 다른 독자들은 이용 가능한 선택지에 대해 더 많이 배울 것입니다. 어떤 경우든 다음과 같은 통찰을 얻었는지 확인하는 것이 중요합니다:
- 다양한 선택지를 통해 자신의 옵션 범위를 이해할 수 있습니다.
- 배포 옵션을 평가하고 어떤 방법을 사용할지 결정하기 위해 일관된 선택 기준을 사용하는 것이 좋습니다.
- 호스팅된 Public 레포지토리는 뛰어난 프로젝트 가시성을 제공하며 무료이고, 채택하는 데 많은 경험이 필요하지 않습니다.
- 자동화된 빌드에서 생성된 이미지는 신뢰할 수 있는 제3자가 빌드하기 때문에 컨슈머가 더 높은 신뢰를 갖게 됩니다.
- 호스팅된 Private 레포지토리는 소규모 팀에게 비용 효율적이며, 만족스러운 접근 제어를 제공합니다.
- 자체 레지스트리를 운영하면 Docker 배포 기능을 포기하지 않고도 특수한 사용 사례에 적합한 인프라를 구축할 수 있습니다.
- 이미지를 파일로 배포하는 것은 어떤 파일 공유 시스템으로도 가능합니다.
- 이미지 소스 배포는 유연하지만 복잡성은 사용자가 설정한 만큼만 복잡합니다. 인기 있는 소스 배포 도구와 패턴을 사용하면 간단하게 유지할 수 있습니다.
'Docker' 카테고리의 다른 글
| 11 Services with Docker and Compose (0) | 2024.04.07 |
|---|---|
| 10 Image pipelines (0) | 2024.04.07 |
| 8 Building images automatically with Dockerfiles (0) | 2024.04.04 |
| 7 Packaging software in images (0) | 2024.04.03 |
| 6 Limiting risk with resource controls (0) | 2024.04.03 |