도커 교과서 11장 도커와 도커 컴포즈를 이용한 애플리케이션 빌드 및 테스트

11장 도커와 도커 컴포즈를 이용한 애플리케이션 빌드 및 테스트

11.1 도커를 이용한 지속적 통합 절차

• CI 절차는 코드로부터 시작하는 파이프라인이고, 일련의 단계를 밟아 테스트를 통과하고 즉시 배포 가능한 결과물을 내놓는다.
• 도커는 CI 절차의 일관성을 유지해 준다.
• CI 절차가 시작되면 도커는 이미지를 빌드한다.
• 해당 이미지는 빌드 및 테스트, 패키징, 배포를 위한 레지스트리 푸시까지 된 이미지다.
• CI 파이프라인의 각 단계는 도커 혹은 도커 컴포즈에 의해 실행되며 실제 과정은 컨테이너 내부에서 진행된다.
• 추가로, 도커 컴포즈로 전체 애플리케이션을 실행하고 트랙픽 발생 용 컨테이너를 이용해 엔드 투 엔드 테스트를 진행할 수도 있다.
• 이렇게 도커를 이용한 CI 를 구축할 경우 중앙 관리되는 형상 관리 시스템과, 도커 이미지 레지스트리, CI 자동화 서버가 필요하다

11.2 도커를 이용한 빌드 인트라스트럭처 구축

직접 인프라스트럭쳐 구축하기

• 직접 구축해서 사용하게 되면 보안 강화, 더 빠른 속도, 특정 서비스 장애 조치 등의 이점이 있다.
• 형상 관리 기능 Gogs, 이미지 배포 오픈 소스 도커 레지스트리, 자동화 서버 젠킨스 설치.

$ cd ./ch11/exercises/infrastructure

$ docker-compose -f docker-compose.yml -f docker-compose-linux.yml up -d

# 레지스트리의 도메인을 hosts 파일에 추가
$ echo $'\\n127.0.0.1 registry.local' | sudo tee -a /etc/hosts

$ docker ps

참고 diamol/gogs 이미지에 문제가 있다. gogs/gogs:latest 이미지로 변경해서 사용하면 정상 동작된다.

도커 CI를 도커 엔진과 연결하기

• 전체 CI 파이프라인이 도커 컨테이너를 통해 실행되므로 도커 API 를 통해 도커 엔진에 연결된다.
• 도커 CLI 는 도커 API 를 호출하는 방식으로 동작하기 때문에 다른 곳에 위치한 CLI 도 같은 도커 엔진에 접속할 수 있다.
• 이때 해당 도커 통신은 호스트 컴퓨터 안으로 국한된다.
• 호스트 컴퓨터 내부의 컨테이너에 대학 조작이 가능하다.
• 따라서, 보안 문제가 발생할 수 있으므로 신뢰할 수 있는 도커 이미지에만 적용해야 한다.

11.3 도커 컴포즈를 이용한 빌드 설정

이미지 태그에 환경변수 사용

services:
	numbers-api:
		image: ${REGISTRY:-docker.io}/diamol/ch11-numbers-api:v3-build-${BUILD_NUMBER:-local}
		networks:
			- app-net
	numbers-web:
		image: ${REGISTRY:-docker.io}/diamol/ch11-numbers-web:v3-build-${BUILD_NUMBER:-local}
		environment:
			- RngApi_Url=http://numbers-api/rng
		depends_on:
			- numbers-api
		networks:
			- app-net

• :- 는 해당 부분을 환경변수로 치환하되 정의되어 있지 않다면 기본 값으로 :- 이후에 정의된 값으로 치환하라는 뜻이다.
• ${REGISTRY:-[docker.io](<http://docker.io>) 는 환경 변수 REGISTRY 값을 사용하되 해당 환경 변수가 정의되어 있지 않다면 docker.io 를 사용하라는 의미다.

도커파일에서 빌드 인자와 이미지 레이블 지정하기

$ cd /ch11/exercises

$ docker compose -f docker-compose.yml -f docker-compose-build.yml build

$ docker image inspect -f '{{.Config.Labels}}' diamol/ch11-numbers-api:v3-build-local

• 컨테이너, 이미지, 네트워크, 볼륨 등 대부분의 도커 리소스에는 레이블을 부여할 수 있다.
• 레이블은 리소스에 대한 추가 데이터에 Key-Value 형태로 저장된다.
• CI 파이프라인을 통한 애플리케이션 빌드에서 발생하는 이슈를 파악하는데 이미지 레이블은 큰 도움이 된다.

FROM diamol/dotnet-aspnet

ARG BUILD_NUMBER=0
ARG BUILD_TAG=local

LABEL version="3.0"
LABEL build_number=${BUILD_NUMBER}
LABEL build_tag=${BUILD_TAG}
ENTRYPOINT ["dotnet", "Numbers.Api.dll"]

• ARG
  • 이미지 빌드 시점에만 유효한 Key-Value 정의.
  • ENV 인스트럭션과 거의 유사하지만, 이미지 빌드시에만 유효.
• LABEL
  • Dockerfile 스크립트에 정의된 Key-Value 를 빌드되는 이미지에 적용.

x-args: &args
	args:
		BUILD_NUMBER: ${BUILD_NUMBER:-0}
		BUILD_TAG: ${BUILD_TAG:-local}

services:
	numbers-api:
		build:
			context: numbers
			dockerfile: numbers-api/Dockerfile.v4
			<<: *args
	numbers-web:
		build:
			context: numbers
			dockerfile: numbers-web/Dockerfile.v4
			<<: *args

• context
  • 도커가 빌드 중에 작업할 디렉토리 경로
  • docker image build [Dockerfile PATH] . 을 사용할 경우 현재 디렉토리에서 빌드 되지만, context 를 이용하여 경로 지정 가능.
• dockerfile
  • Dockerfile 스크립트의 경로
  • 상대 경로일 경우 context 에 지정된 경로를 기준.
• args
  • 빌드 시 전달할 인자.
  • Dockerfile 에서 ARG 인스트럭션으로 정의된 키와 일치해야 한다.
• 어떤 방법으로 빌드를 수행하든 항상 같은 방식으로 수행되려면, Dockerfile 을 하나로 유지해야 한다.
• 컴포즈 파일에 기본값을 설정하면, 다른 환경에서 실행더라도 빌드 성공을 보장할 수 있다.

11.4 도커 외의 의존 모듈이 불필요한 CI 작업 만들기

• 컨테이너를 이용한 CI를 할 경우 별도의 의존모듈이 필요하지 않다는 장점이 있다.
• 많은 서비스들(Docker Hub, Github Actions, Azure DevOps)이 이를 제공하므로, 별도의 빌드 서버가 필요 없어지고, 모든 개발자가 개발 도구를 최신 버전으로 유지할 필요도 없다.
• 또한, 빌드 스크립트를 간결하게 유지할 수 있고, CI 파이프라인 구축을 하여 로컬 환경과 동일하게 빌드할 수 있다.

$ vi Jenkinsfile

stage('Build') {
	steps {
		dir('ch11/exercises') {
			sh 'chmod +x ./ci/01-build.bat'
			sh './ci/01-build.bat'
		}
	}
}

$ docker composes -f docker-compose.yml -f docker-compose-build.yml build --pull

• pull 옵션은 빌드에 필요한 이미지를 무조건 최신 버전으로 새로 내려받는 것이다.
• CI 파이프라인에서는 Dockerfile 에 지정된 이미지에 변경이 생경을 때 애플리케이션에 미치는 영향을 최대한 빨리 알 수 있으므로 해당 옵션이 중요하다.

Jenkins 빌드 단계

A. 검증단계

• 00-verify.bat 스크립트 실행.
• 해당 스크립트는 도커 및 도커 컴포즈의 버전을 출력.

B. 빌드 단계

• 01-build.bat 스크립트 실행.
• 도커 컴포즈를 실행해 이미지를 빌드하는 역할

C. 테스트 단계

• 02-test.bat 스크립트 실행
• 도커 컴포즈로 빌드된 애플리케이션을 실행. 컨테이너 목록 출력 후 애플리케이션 종료.

D. 푸시 단계

• 03-push.bat 스크립트 실행.
• 도커 컴포즈를 실행해 빌드된 이미지를 레지스트리에 푸시.

11.5 CI 파이프라인에 관계된 컨테이너

• 도커를 사용하면 애플리케이션 빌드 프로세스의 최상위 레이어가 항상 동일해진다.
• 이 점을 이용해 CI 파이프라인에 취약점 및 보안 검사, 디지털 서명 등을 추가할 수 있다.
• 도커에서는 해당 단계를 안전 소프트웨어 공급 체인이라고 하고, 배포할 소프트웨어의 안정성을 담보한다는 점에서 매우 중요하다.
• 운영 환경에서 CI 파이프라인을 무사히 통과했을 때만 추가되는 디지털 서명이 있는 이미지로만 컨테이너를 실행되게 설정할 수도 있다.