15.4.지속적 통합 파이프라인에 지속적 배포 추가하기

  • 지금의 파이프라인은 지속적 통합(Continuous Integration, CI) 단계까지 만들어진 상태다.
  • 애플리케이션 빌드
  • 애플리케이션 테스트
  • 레지스트리에 빌드 이미지 푸시
  • 지속적 배포(Continuous Deployment, CD) 단계를 추가한다.
  • 테스트 환경에 애플리케이션을 배포
  • 테스트 후 최종 배포 인가
  • 운영 환경에 배포
  • CI 빌드는 처음부터 끝까지 빌드용 서버의 도커 엔진 안에서만 진행될 수 있지만, 배포는 원격 도커 엔진에서 진행해야 할 필요가 있다.
  • CD 파이프라인에서도 우리가 실습한 것과 같이 원격 서버를 가리키는 호스트명 인자를 지정하고, 보안 인증 수단을 사용해 도커 및 도커 컴포즈로 명령을 내린다.
  • 대부분의 자동화 서버는 비밀값을 빌드 서버 내부에 저장해 파이프라인 작업에 사용한다.

실습 11장에서 만들었던 것과 비슷하게 로컬 Git 서버, 도커 레지스트리, 젠킨스 서버로 구성된 빌드 인프라스트럭처를 만들 것이다. 이들 구성 요소는 모두 컨테이너로 실행된다. 젠킨스 서버가 가동되면 로컬 컴퓨터에 있는 Play with Docker 내 도커 엔진에 대한 인증서 파일로 인증 수단을 만드는 스크립트가 실행된다. 따라서 CD 단계는 Play with Docker 내 도커 엔진을 대상으로 실행된다.

# 컴포즈 파일이 위치한 디렉터리로 이동한다
➜ cd ch15/exercises/infrastructure 

# 컨테이너를 실행한다
➜ docker-compose -f ./docker-compose.yml -f ./docker-compose-linux.yml up -d
  • 컨테이너가 실행되고 나면 웹 브라우저에서 http://localhost:8080/credentials에 접근해 젠킨스에 로그인한다.
  • 사용자명 diamol
  • 패스워드 diamol
  • 도커 인증 기관 및 클라이언트 접속 관련 인증서가 이미 젠킨스에 저장돼 있는 것을 볼 수 있다.
  • 이들 인증서는 로컬 컴퓨터에 있던 Play with Docker(PwD) 원격 접근 관련 인증서가 전달된 것으로, 파이프라인 작업에 사용된다.
  • 그림 15-12는 젠킨스 인증 수단에 추가된 인증서 목록의 스크린샷이다.

  • 젠킨스 서버는 자동화 스크립트 덕분에 바로 사용 가능하도록 설정이 완료돼 있다.
  • 그러나 Git 서버는 아래의 수작업 설정이 필요하다.
  • 웹 브라우저에서 http://localhost:3000에 접속
  • 설치 단계를 마무리하면 diamol 이라는 사용자가 생성된다.
  • diamol 이라는 이름으로 코드 저장소를 만든다.
  • 기억이 잘 나지 않는다면 11장 참고
  • 12장의 10초마다 한 번씩 현재 시간을 출력하는 timecheck 애플리케이션의 새 버전을 빌드
  • 이번 장의 예제 코드에 Play with Docker 내 도커 엔진의 도메인을 스크립트에 추가해야 한다.
  • 그 후 빌드를 실행시키면 CI 단계를 거쳐 빌드 서버(현재는 로컬)에서 Play with Docker 속 도커에 배포된다.

실습 ch15/exercises 디렉터리에서 파이프라인 정의 파일을 열어라. 윈도 컨테이너를 사용한다면 Jenkinsfile.windows, 리눅스 컨테이너를 사용한다면 Jenkinsfile을 열면 된다. enviroment 항목을 보면 도커 레지스트리 도메인과 사용자 인수 테스트 및 운영 환경의 도커 엔진에 관련된 변수를 볼 수 있다. pwd-domain 부분을 여러분의 Play with Docker 내 도커 엔진의 도메인으로 수정하라. 이때 :80과 같이 포트를 추가해야 한다. 그러면 80번 포트를 주시하다가 이 포트로 들어오는 트래픽을 Play with Docker 속 2376번 포트로 연결해 준다.

environment {
  REGISTRY = "registry.local:5000"
  UAT_ENGINE = "ip172-18-0-11-cj2vgeggftqg00c9qjo0-2376.direct.labs.play-with-docker.com:80"
  PROD_ENGINE = "ip172-18-0-11-cj2vgeggftqg00c9qjo0-2376.direct.labs.play-with-docker.com:80"
}

# 수정한 코드를 로컬 Git 서버에 푸시한다.
➜ git remote add ch15 http://localhost:3000/diamol/diamol.git

➜ git commit -a -m 'Play with Docker'의 도메인 정보를 추가함'
➜ git push ch15
# Gogs에서 로그인 정보를 요구할 것이다.
# Gogs에서 등록한 사용자 정보인 사용자명 diamol, 패스워드 diamol을 사용한다.
  • 웹 브라우저에서 http://localhost:8080/job/diamol 페이지에 접근해 Build Now 버튼을 클릭한다.
  • 이번 파이프라인도 기본적인 동작은 11장에서 본 것과 같다.
  • Git 서버에서 소스 코드를 내려 받음
  • 멀티 스테이지 빌드가 적용된 Dockerfile 스크립트로 애플리케이션을 빌드
  • 빌드된 애플리케이션에 테스트 진행
  • 이미지를 로컬 레지스트리에 푸시
  • 그리고 그 뒤로 새로 추가된 배포 단계가 이어진다.
  • 사용자 인수 테스트용 도커 엔진에 애플리케이션을 배포
  • 사람이 사용자 인수 테스트를 승인할 때까지 잠시 대기
  • 최종 배포 승인 결정을 내리기 위해 운영 환경과 유사한 환경에서 테스트
  • 최종 배포 승인 및 운영 환경 배포

CD 단계 스크립트 작성 * CD 단계는 CI 단계보다 복잡한 작업이 없다. * 각 단계마다 도커 명령 한 번으로 해당 단계를 실행하거나 오버라이드 파일을 병합하는 스크립트가 있다. * 원격 도커 환경이 스웜 클러스터라면 docker stack deploy 명령으로 이 부분을 더욱 쉽게 진행할 수 있다 * 이들 스크립트는 환경 변수에서 TLS 인증서 경로와 도커 호스트 도메인 이름을 참조하므로 이들 환경 변수가 파이프라인을 실행할 때 정의돼 있어야 한다. * 파이프라인에서 도커 명령행이 하는 일과 도커 컴포즈 명령행이 하는 일, 그리고 이 두 가지 일을 제어하는 일을 잘 분리해 두어야 한다. * 그래야 특정 자동화 서버에 대한 의존을 줄일 수 있고 나중에 자동화 서버를 전환할 때 도움이 된다.

예제 15-3 젠킨스에 저장된 인증 수단으로 스크립트 파일에 도커 TLS 인증서 전달하기

# Jenkinsfile의 사용자 인수 테스트 환경 배포 단계
stage('UAT') {
  steps {
    withCredentials(
      [file(credentialsId: 'docker-ca.pem', variable: 'ca'),
       file(credentialsId: 'docker-cert.pem', variable: 'cert'),
       file(credentialsId: 'docker-key.pem', variable: 'key')]) {                    
        dir('ch15/exercises') {
          sh 'chmod +x ./ci/04-uat.bat'
          sh './ci/04-uat.bat'
          echo "Deployed to UAT"
      }
    }
  }
}

# 도커 컴포즈 명령 하나로만 구성된 실제 스크립트
docker-compose \
  --host tcp://$UAT_ENGINE --tlsverify \
  --tlscacert $ca --tlscert $cert --tlskey $key \
  -p timecheck-uat -f docker-compose.yml -f docker-compose-uat.yml \
  up -d
  • 젠킨스가 저장된 인증 수단 중에서 TLS 인증서를 셸 스크립트에 제공한다.
  • 이 프로세스를 깃허브 액션스로 이전하려면 깃허브 저장소에 저장된 비밀값을 사용하면 될 뿐 빌드 스크립트 자체를 수정할 필요는 없다.

links

social