컨테이너를 만드는 바탕이 되는 읽기 전용 템플릿. 애플리케이션의 실행 파일, 라이브러리, 설정 등의 파일을 레이어로 나누어 겹치고, 시작할 명령 등의 설정을 붙인 것으로, OS의 커널은 포함하지 않는다. Dockerfile 등으로부터 만들어지며, 레지스트리에 보관하여 배포한다. 리포지토리 이름과 태그(예: web:1.4)로 지정하는 것 외에, 내용으로부터 계산한 다이제스트(sha256:…)로 고유하게 지정할 수 있다. 같은 레이어는 여러 이미지가 공유한다.
일본어 명칭: コンテナイメージ
컨테이너 이미지(Container Image)은(는) 클라우드와 컨테이너의 기초 등 1개 분야의 연습 문제 3개에 나와요.
분야: 클라우드와 컨테이너의 기초
Dockerfile의 명령 중 파일을 바꾸는 것(RUN, COPY 등)이 각각 하나의 레이어가 됩니다. 레이어는 내용으로부터 계산한 다이제스트로 식별되므로, 같은 베이스 이미지를 사용하는 이미지끼리는 그 레이어를 다운로드도 디스크도 한 번분으로 공유할 수 있습니다. 나중 레이어에서 파일을 삭제해도 앞 레이어의 내용은 이미지에 남으므로, 큰 임시 파일은 같은 명령 안에서 지우거나 멀티 스테이지 빌드로 최종 이미지에 넣지 않도록 합니다.
태그는 web:1.4나 latest처럼 사람이 붙이는 이름으로, 나중에 다른 이미지에 옮겨 붙일 수 있습니다. 다이제스트는 이미지의 내용으로부터 계산한 값으로, 내용이 1비트라도 다르면 바뀝니다. 운영 환경이나, 시험한 것과 같은 것을 확실하게 사용하고 싶은 상황에서는 다이제스트로 지정합니다.
실행에 불필요한 컴파일러나 패키지 관리 도구를 포함하지 않으면 이미지는 작아지고, 가져오기가 빨라지며, 취약점의 대상도 줄어듭니다. 멀티 스테이지 빌드로 빌드용 스테이지와 실행용 스테이지를 나누는 것이 대표적인 방법입니다. 비밀 값은 이미지에 넣지 않고 시작할 때 전달합니다.
정답: B. 이미지는 읽기 전용 템플릿이며, 하나의 이미지로부터 각각 쓰기 가능한 레이어를 가진 여러 컨테이너를 시작할 수 있다
이미지는 애플리케이션 실행에 필요한 파일과 설정을 묶은 읽기 전용 템플릿이고, 컨테이너는 이미지로부터 만들어진 실행 단위입니다. 컨테이너를 만들면 이미지의 레이어 위에 그 컨테이너 전용의 쓰기 가능한 레이어가 겹쳐집니다. 따라서 하나의 이미지로부터 다수의 컨테이너를 시작할 수 있고, 각 컨테이너에서의 변경은 다른 컨테이너나 이미지에 영향을 주지 않습니다. 변경을 이미지로 남기고 싶을 때는 Dockerfile을 고쳐 이미지를 다시 만드는 것이 일반적입니다.
정답: A. 새 ReplicaSet을 만들어 새 버전의 Pod를 늘리면서 이전 버전의 Pod를 줄인다. 이전 ReplicaSet은 롤백용으로 Pod가 0인 상태로 남는다
Deployment는 Pod 템플릿이 바뀌면 새 템플릿의 ReplicaSet을 만들고, 새 Pod가 준비된 것을 확인하면서 이전 ReplicaSet의 Pod를 조금씩 줄입니다. 그래서 업데이트하는 동안에도 일정 수의 Pod가 계속 요청을 처리합니다. 이전 ReplicaSet은 Pod가 0인 상태로 남겨지므로 kubectl rollout undo로 이전 버전으로 되돌릴 수 있습니다. 모든 Pod를 먼저 지운 다음 다시 만드는 방식은 Recreate로, 명시적으로 지정했을 때 사용됩니다.
이미지는 읽기 전용 템플릿이고, 컨테이너는 그로부터 만들어진 실행 중(또는 정지 중)인 실체입니다. 하나의 이미지로부터 다수의 컨테이너를 만들 수 있으며, 각 컨테이너에는 전용의 쓰기 가능한 레이어가 붙습니다. 프로그램 파일과 프로세스의 관계와 비슷합니다.
latest는 특별한 의미가 없는 보통의 태그입니다. 태그를 생략했을 때 사용되는 기본 이름일 뿐이며, 누군가 옮겨 붙이지 않는 한 새 버전을 가리킨다고 할 수 없습니다. 버전을 고정하고 싶을 때는 구체적인 태그나 다이제스트로 지정합니다.
컨테이너(Container) Kubernetes Pod CI/CD(지속적 통합·지속적 전달) 환경 변수(Environment Variable) 가용 영역(Availability Zone) 공동 책임 모델(Shared Responsibility Model) 관측 가능성(Observability) 블루-그린 배포(Blue-Green Deployment) 서버리스(Serverless)