도커를 사용한 어플리케이션 개발은 크게 구현 – 단위테스트 – 어플리케이션 빌드 – 도커이미지 빌드 – 도커 레지스트리 등록에 이르는 과정을 반복하는 형태가 된다. 이러한 반복 과정을 수작업으로 진행하게 되면 실수가 발생하기 쉽고, 시간도 오래 걸릴 수 있기 때문에 CI/CD 서비스를 통해 이 과정들을 자동화를 하고 시간을 절약한다.
CI/CD(Continuous Integration/Continuous Delivery)에서 CI는 소프트웨어 개발을 할 때 테스트 단계에서만 테스트를 하는 것이 아니라 일상적으로 빌드와 테스트를 수행하여 실제 동작을 확인하는 사이클을 수행하면서 소프트웨어의 품질을 관리하는 것을 말하며 “지속적 통합”이라고 한다. 일반적으로 CI를 위한 전용 소프트웨어나 SaaS를 이용하여 자동화한다.
CD는 CI의 범위를 확장하여 통합 테스트를 위한 스테이징 환경에 배포, 그리고 정식 서비스 배포까지 자동화 도구를 사용하여 수행하는 것을 말하며 “지속적 배포”라고 한다. Blue/Green 배포, Canary 배포 등의 방법이 사용된다.
CI/CD 파이프라인(pipeline)은 새 버전의 소프트웨어를 제공하기 위해 수행해야 할 일련의 단계로서 DevOps 또는 SRE (Site Reliability Engineering) 방식을 통해 더 효과적으로 소프트웨어를 제공하는 데 초점을 맞춘 방법이다. CI/CD 파이프라인은 모니터링 및 자동화를 통해서 특히 통합 및 테스트 단계뿐만 아니라 전달 및 배포에 있어서 어플리케이션 개발 프로세스를 개선한다. CI/CD 파이프라인의 각 단계를 수동으로 실행할 수 있지만, CI/CD 파이프라인의 진정한 가치는 자동화를 통해 드러난다. (참조. Red Hat Devops, What is CI/CD?)
CI/CD 파이프라인은 파이프라인 스테이지(pipeline stage)라고 하는 개별 타스크 묶음으로 이루어져있다. 아래는 일반적인 파이프라인으로 요건에 따라 고유 파이프라인을 구성할 수도 있다.
- 빌드(Build) - 어플리케이션을 컴파일하는 단계
- 테스트(Test) - 코드를 테스트하는 단계. 이 단계를 자동화하여 시간과 노력를 줄일 수 있다.
- 릴리스(Release) - 어플리케이션을 리포지토리에 제공하는 단계
- 배포(Deploy) - 코드를 운영환경에 배포하는 단계
- 검증 및 컴플라이언스(Validation & compliance) - 빌드 검증 단계는 해당 조직의 필요에 따라 결정
이번 테스트에서는 GitHub의 샘플 어플리케이션 소스를 가지고 Oracle CI/CD 솔루션인 Wercker(Oracle이 2017년 인수) 어플리케이션을 만들고, 이를 도커 이미지로 OCI 레지스트리에 업로드한 다음, OKE 클러스터에 컨테이너로 이미지를 배포해 본다.
Wercker에 대해 간략히 살펴보면 스텝(Step), 파이프라인(Pipeline), 워크플로우(Workflow)의 구조로 어플리케이션을 빌드하고 배포한다. 리포지토리에서 가져온 소스를 Wercker 어플리케이션으로 만들고, 워크플로우로 실행한다. 워크플로우 안에는 빌드, 배포 등의 파이프라인으로 구성되면, 각 파이프라인에는 스텝으로 상세화되어 있어서 실행 상태를 확인할 수 있다.
참고 사이트: CI-CD simplified with Wercker + Kubernetes on Oracle Cloud Infrastructure
| 컴포넌트명 | 역할 |
| Step | 어플리케이션의 wercker.yml 파일에 정의된 특정 자동화 작업을 수행하기위한 Bash 스크립트 또는 컴파일된 바이너리. 수동으로 작성하거나 Steps Registry 통해 가져올 수 있음 |
| Pipeline | Wercker의 핵심 기능. 스텝과 작업에 대한 환경을 정의. 테스트, 빌드 및 배포를 정의. 스텝의 집합이며 각 스텝 작업 결과에 따라 pass 또는 fail. 여러개 파이프라인을 동시에 실행하도록 설정할 수 있어서 테스트를 병렬화하여 개발 시간을 단축시킬 수 있다. |
| Workflow | 파이프라인을 관리하기 위한 메커니즘. 워크플로우에서 소속 파이프라인을 직렬 또는 병렬로 연결하여 어플리케이션의 소스로부터 운영 배포까지 이르는 정교한 CI/CD 흐름을 만들 수 있다. |
Wercker 외에도 현재 많이 사용되는 Jenkins를 이용한 배포는 아래 샘플을 참조한다.
Wercker는 GitHub에 통합되어 있기 때문에 GitHub에서 새로운 코드를 작성이나 브랜치, 마스터에 대한 변경이 발생하여 커밋을 했을 때, Wercker가 이를 반영하여 컨테이너 이미지를 자동으로 빌드 할 수 있다.
마스터 커밋의 경우 Wercker는 파이프 라인을 실행하고 이미지를 빌드하고 이미지를 OCIR에 푸시 한 다음 컨테이너를 OKE의 인스턴스에 배포하고 실행중인 컨테이너, 파드를 교체하여 어플리케이션을 업데이트한다.
테스트 수행 전 확인할 사항이 있다. Wercker에서 OCI 레지스트리에 이미지를 Push할 때 지원되는 Region이 현재 Frankfurt(FRA), IAD(Ashburn), LHR(London), PHX(Phoenix)이다. 아래 내용 참조.
The registry field must be set to https://<region-code>.ocir.io/v2/, where <region-code> is one of fra, iad, lhr, or phx.
Wercker Documentation > Administration > Containers > Pushing Images
따라서 위 네개 Region 중 하나의 OCI 레지스트리를 사용할 수 있어야 한다. OCI 웹 콘솔의 Administration > Region Management에서 미리 해당 Region을 Subscribe해야 한다. (참고로 Region 사용 개수의 제약 때문에 Region Subscribe에 불가한 경우, subscribed-region-count에 대한 Service Limit 증가를 service limit increase를 통해 요청해야 한다)
먼저 GitHub에 로그인한 다음, 아래 샘플 어플리케이션 소스를 열고 오른쪽 상단의 Fork클릭한다.
샘플 어플리케이션은 Python 어플리케이션으로 HTTP GET 요청을 보낸 클라인언트의 IP 주소를 JSON 포맷으로 보여준다.
Wercker는 YML 포맷의 매니페스트 파일에 정의된 내용으로 도커 이미지를 빌드하고 배포하게된다.
자신의 GitHub 리포지토리로 Fork해 온 어플리케이션에서 매니페스트 파일 wercker.yml 파일을 열어 본다.
Wercker 어플리케이션은 wercker.xml 파일에 기술된 내용으로 도커 이미지를 생성하게 되는데, 이때 Wercker에 아래 환경 변수를 전달해야한다. wercker.xml 파일에는 변수만 설정하고, 실제 값은 이후 Wercker UI에서 지정할 것이다.
- DOCKER_USERNAME
- DOCKER_PASSWORD
- DOCKER_REPO
Wercker에서 도커 이미지를 빌드 할 때 마다 Git 커밋 값으로 이미지에 태그를 붙이게 된다. 이를 통해 어플리케이션의 변경 이력을 확인 할 수 있다.
이제 Wercker 웹 콘솔에서 Wercker 어플리케이션을 만들 차례이다. 아래 Wercker 웹 콘솔로 접속한다.
Wercker 웹 콘솔 접속 후, 로그인을 하면 나타나는 화면에서 “Create your first application”을 클릭한다.
Wercker 어플리케이션을 만드는 첫번째 단계로 SCM (Source Code Management)을 선택하는 것이다. 유저에는 로그인한 Wercker 유저를, SCM은 GitHub를 선택하고 하단의 “Next”를 클릭한다. SCM 선택에서 GitHub 선택 시, GitHub와 최초 연결인 경우,
두번째 단계로 앞서 GitHub에서 Fork했던 어플리케이션 소스 “wercker-oke-demo”를 선택 후, 하단의 “Next”를 클릭한다.
권고 사항인 디폴트 코드 체크아웃 옵션을 선택하고, 하단의 “Next”를 클릭한다.
앞서 선택한 내용들을 확인하고, 하단의 “Create”을 클릭한다.
Wercker 어플리케이션이 생성되었다.
이제 앞서 언급한 대로 wercker.xml 파일에 정의된 변수에 대한 환경 변수 값을 설정하여 Wercker에 전달할 것이다. 그리고 빌드를 통해 GitHub의 소스를 가져와서 이를 도커 이미지로 만들어 OCI 레지스트리에 Push해 볼 것이다.
먼저 Environment 탭을 클릭한다.
어플리케이션 환경 변수Key와 Vaule를 입력하고, 오른편의 “Add”를 클릭하여 다음 값을 입력하는 방식으로 wercker.yml 파일에서 정의한 아래 세개의 환경 변수를 생성한다. DOCKER_PASSWORD의 경우 Value 입력 후, “Protected”를 클릭하여 값을 마스킹 처리한다.
DOCKER_USERNAME 은 <tenancy name>/<username>을 입력한다.
DOCKER_REPO는 <region-code>.ocir.io/<tenancy name>/<registry name>을 입력한다. registry name은 OCI 레지스트리에 업로드될 레포지토리명이다. 여기서는 “werckerdemo”라고 입력했다.
- DOCKER_USERNAME: apackrsct01/oracleidentitycloudservice/young.kyun.jung@sampletest.com
- DOCKER_PASSWORD: 앞서 생성한 해당 유저의 인증 토큰
- DOCKER_REPO: iad.ocir.io/apackrsct01/werckerdemo
환경 변수를 모두 입력한 후 Runs 탭으로 이동한다.
Runs 탭 화면 맨 아래에 있는 “trigger a build now”를 클릭하여 어플리케이션 빌드와 OCIR로의 이미지 Push를 시작한다.
빌드와 OCIR로 Push가 완료되면 아래와 같은 화면을 볼 수 있다.
각 단계별 실행 내용을 화면을 펼쳐서 확인할 수 있다. 아래는 OCIR로 이미지 Push 단계의 실행 내용이다.
실제 OCI 레지스트리로 이미지가 Push되어 있는지 확인한다. OCI 레지스트리 화면으로 이동해 보면 앞서 지정한 “werckerdemo”라는 이름으로 레포지토리가 생성되어 있음을 알 수 있다.
글 순서
5. OCI 레지스트리에 이미지 업로드 & 다운로드 설정
여기에 정리한 내용은 오라클 제품을 다루고 있지만, 이는 개인적인 정리 및 테스트 결과일 뿐입니다. 오라클의 공식 문서는 오라클이 제공하는 매뉴얼과 기타 기술문서를 참조하셔야 합니다.
'Cloud > Oracle Cloud Infrastructure' 카테고리의 다른 글
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 8. OKE 모니터링 (0) | 2021.03.22 |
|---|---|
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 7. Wercker를 이용한 어플리케이션 배포 (0) | 2021.03.22 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 5. OCI 레지스트리에 이미지 업로드 & 다운로드 설정 (0) | 2021.03.22 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 4. OKE 클러스터에 샘플 웹서버 배포 (0) | 2021.03.17 |
| OCI를 이용한 쿠버네티스, Wercker 쉬운 샘플 - 3. OCI 쿠버네티스 배포, 사용 환경 설정 (0) | 2021.03.17 |
