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

  • 앞서 빌드한 무작위 숫자 애플리케이션은 닷넷 SDK로 되었지만 별도 설치 없이 애플리케이션을 빌드했다.
  • 이렇듯 의존 모듈이 별도로 필요하지 않다는 점은 컨테이너에서 수행하는 CI의 주된 장점이다.
  • 그리고 도커 허브, 깃허브 액션스, 애저 데브옵스 등 주요 매니지드 빌드 서비스가 이를 지원한다.
  • 이러한 서비스를 사용하면, 여러 가지 도구를 설치해야 하는 빌드 서버도 필요 없어지고 모든 개발자가 개발 도구를 최신 버전으로 유지할 필요도 사라진다.
  • 거기다 빌드 스크립트도 간결하게 유지할 수 있고 빌드 서비스를 교체하는 것도 간단하다.

이 책에서는 CI 파이프라인을 실행하기 위해 젠킨스를 사용하는데, 젠킨스 CI 작업은 소스 코드 저장소에 포함된 간단한 텍스트 파일로 설정이 가능하다.

예제 11-5 Jenkinsfile에 정의된 CI 작업의 빌드 단계

# Jenkinsfile에 정의된 빌드 단계
# 작업 디렉터리를 변경하고 두 개의 셸 명령을 실행한다
# 첫 번째 명령은 스크립트 파일을 만들고 두 번째 명령에서 스크립트를 실행한다
stage('Build') {
  steps {
    dir('ch11/exercises') {
      sh 'chmod +x ./ci/01-build.bat'
      sh './ci/01-build.bat'
    }
  }
}

# 다음은 01-build.bat 스크립트의 내용이다
docker-compose -f docker-compose.yml -f docker-compose-build.yml build --pull
  • pull 옵션이 추가된 것만 빼면, 우리가 로컬 컴퓨터에서 이미지를 빌드할 때 사용했던 docker-compose build 명령과 하나도 다를 바가 없다.
  • 빌드 단계는 스크립트를 실행하는 간단한 내용이다.
  • 스크립트 파일의 확장자가 bat이므로 리눅스 컨테이너는 물론 윈도 컨테이너에 실행된 젠킨스에서도 문제없이 실행된다.
  • 스크립트를 실행하면 도커 컴포즈가 실행되고 도커 및 도커 컴포즈에서 출력하는 내용은 모두 빌드 로그에 저장된다.

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

실습 젠킨스 UI에서 빌드 로그를 볼 수 있다. 웹 브라우저에서 http://localhost:8080/job/diamol을 입력해 작업 페이지에 접근한 뒤 파이프라인 뷰에서 작업 #2의 두 번째 단계를 선택한 다음, Logs를 클릭하라. 빌드 단계별 로그를 눌러 내용을 펼쳐 보면 눈에 익은 도커 빌드 출력을 볼 수 있다.

  • 빌드 파이프라인의 각 단계는, 배치 스크립트를 실행하고 여기서 실행된 도커 컴포즈가 실질적인 작업을 담당하는 비슷한 패턴을 따른다.
  • 상업용으로 제공되는 파이프라인 작성 문법 대신 일반적인 스크립트로 작성해 파이프라인에서 호출하는 이런 패턴은 빌드 서비스를 갈아타기에도 유리하다.
  • 깃랩이나 깃허브 액션으로 빌드 서비스를 변경하더라도 파이프라인 스크립트만 추가하면 동일하게 동작하기 때문이다.

젠킨스 빌드의 모든 단계는 컨테이너에서 실행된다. * 검증 단계: * 00-verify.bat 스크립트를 실행한다. * 이 스크립트는 도커 및 도커 컴포즈의 버전을 출력하는 내용을 담고 있다. * 빌드에 필요한 의존 모듈인 도커의 버전 정보를 빌드 파이프라인 로그 맨 처음에 출력하면 유용할 때가 많다. * 빌드 단계: * 앞서 본 01-build.bat 스크립트를 실행한다. * 이는 도커 컴포즈를 실행해 이미지를 빌드하는 역할을 한다. * Jenkinsfile에 환경 변수 REGISTRY가 정의돼 있으므 로 빌드되는 이미지는 로컬 레지스트리 도메인이 포함된 태그를 갖는다. * 테스트 단계: * 02-test. * bat 스크립트를 실행한다. * 이 스크립트는 도커 컴포즈로 빌드된 애플리케이션을 실행하고 컨테이너 목록을 출력한 다음 애플리케이션을 다시 종료한다. * 간단해 보이지만, 컨테이너가 이상 없이 실행됨을 확인할 수 있다. * 실제 프로젝트라면 애플리케이션을 실행한 뒤 다른 컨테이너에서 E2E 테스트를 진행할 것이다. * 푸시 단계: * 03-push.bat 스크립트를 실행한다. * 도커 컴포즈를 실행해 빌드된 이미지를 레지스트리에 푸시하는 스크립트다. * 이미지 태그는 로컬 레지스트리 도메인을 포함 하므로 빌드 및 테스트 단계가 성공했다면 이미지가 레지스트리에 푸시된다.

CI 파이프라인의 각 단계는 순서대로 실행된다. 중간에 실패한 단계가 있으면 해당 작업은 그대로 종료된다. 다시 말하면, 빌드와 테스트 단계를 통과해 릴리스 후보가 될 수 있는 이미지만 레지스트리에 푸시된다는 뜻이다.

실습 젠킨스에서 첫 빌드에 성공했다(빌드 번호 1은 소스 코드가 없어 실패하고 빌드 번호 2가 성공했다). 로컬 레지스트리 컨테이너의 REST API에서 무작위 숫자 애플리 케이션 이미지의 v2 태그가 있는지 확인하라.

# 엔드포인트 catalog에서 모든 이미지 리포지터리의 목록을 확인한다
➜ curl http://registry.local:5000/v2/_catalog

# 엔드포인트 tags에서는 단일 리포지터리의 태그 목록을 확인한다
➜ curl http://registry.local:5000/v2/diamol/ch11-numbers-api/tags/list
➜ curl http://registry.local:5000/v2/diamol/ch11-numbers-web/tags/list
  • 이 파이프라인은 비교적 간단한 CI 파이프라인이지만, 주요 베스트 프랙티스와 필수적인 CI 작업 단계가 모두 포함돼 있다.
  • 이 파이프라인의 핵심은 복잡한 일을 스크립트를 통해 도키에 맡기라는 것이다.
  • 이것만 지킨다면, 어떤 CI 서버를 사용하더라도 기존의 스크립트를 그대로 옮겨 파이프라인을 정의하면 된다.

links

social