Applications

Overview

ZCP v2의 가장 중요한 기능은 Multi Cluster 지원입니다. ZCP v1 에서는 각 클러스터 별로 ZCP 가 설치되어 해당 클러스터에만 어플리케이션을 배포하고, 로그를 수집하고, 모니터링 메트릭을 수집할 수 있었습니다. ZCP v2는 Control Plane 클러스터를 중심으로 여러 Data Plane 클러스터를 관리하고, 어플리케이션을 배포하고, 데이터를 수집하는 중앙 집중형으로 구성이 되어있습니다.

ZCP v2 의 Application (이하 ZCP Application. 일반적으로 말하는 Application 과 용어 구분하기 위함) 과 Deploy Group 은 단일 클러스터가 아닌 멀티 클러스터에 대한 CI/CD 를 위한 개념입니다. CI/CD란 결국 어플리케이션을 빌드하고, 자신이 원하는 환경에 빌드한 어플리케이션을 배포하는 과정을 지속적으로 수행할 수 있도록 자동화한 것입니다. 단일 클러스터를 대상으로 CI/CD 를 수행 할 경우 빌드 → 배포로 이어지는 프로세스가 한 번씩만 수행되어도 큰 문제가 없습니다. 하지만, 멀티 클러스터가 대상인 경우(배포 할 타겟 환경이 여러 곳인 경우) 빌드는 한번만 수행되고, 배포를 타겟만 바꿔가며 여러 번 실행할 수 있는 구성이 가능해야 합니다. ZCP v2 에서는 어플리케이션 빌드를 위한 ZCP Application과 원하는 클러스터에 배포를 하기 위한 Deploy Group 이란 개념을 만들어서 빌드와 배포의 과정을 분리했습니다.

일반적으로 Kubernetes 를 대상으로 하는 빌드/배포 파이프라인은 Source Checkout → Application Build → Docker Image Build & Push → Deploy 를 수행합니다. ZCP Application 은 이 과정 중 Source Checkout → Application Build → Docker Image Build & Push 를 담당합니다. 개발팀의 소스 코드를 체크아웃 받아 Kubernetes 에 배포 가능한 Docker Image 를 만들어내는 것이 목적이며, 별도의 스크립트 작성없이 최소한의 UI 설정만으로 빌드 파이프라인을 설정하고 수행 할 수 있도록 개발했습니다. 실제 작업을 수행하는 파이프라인의 엔진은 오픈소스 CI/CD framework 인 Tekton 을 사용합니다.

지원하는 도구

• 형상 관리 Tool : GIT

• 빌드 Tool : Maven, Gradle, NPM

ZCP Application 생성

ZCP Application 은 MSA 의 Application 과 1:1 Mapping 됩니다. MSA Application 당 하나의 ZCP Application 을 생성합니다.

ZCP Application 의 목표는 형상 관리 도구 안에 있는 소스 코드를 배포 가능한 Image 로 만드는 것이므로 생성하기 전에 Application 소스가 있는 Git 주소, Git 계정, Image 를 저장 할 Registry 주소, Registry 계정과 Docker Image 를 생성 할 Dockerfile 이 필요합니다.

Create Application

Create Application 버튼을 클릭합니다.

Source type 선택

현재는 표준 Git 만 지원합니다. ZCP 에서 지원하는 Gitea 나 Github, Gitlab 등 표준 Git 을 지원하는 Git server 는 모두 사용 가능합니다. 추후 다른 타입의 Source 가 추가될 수 있습니다.

기본 정보 입력

ZCP Application 의 기본 정보를 입력합니다.

• Name (필수) : ZCP Application 의 이름입니다. label 등 시스템 내부에서 사용됩니다.

• Display Name : 콘솔 화면에 표시 할 이름입니다. 입력하지 않으면 Name 이 표시됩니다.

• Description : ZCP Application 에 대한 설명입니다.

Source Repository 정보 입력

빌드 시 Checkout 받을 소스 코드의 Repository 정보를 입력합니다.

• Git Repository (필수) : Git Repository 의 Clone 주소입니다.

• Authentication (필수) : 인증 타입을 선택할 수 있습니다. 현재는 ID, Password 방식인 Basic Authentication 만 지원합니다.

• Secret (필수) : 계정 정보를 선택합니다. 계정 정보는 Secret 으로 관리되며 Project 내부에서 재사용이 가능합니다. 아래 절차대로 Secret 을 등록하고 선택합니다.

Secret 관리

1. Add 버튼을 클릭하면 신규 Secret 을 생성 할 Row 가 추가됩니다.

2. Secret Name 을 입력합니다. 소문자, 숫자, dash (-) 만 입력 가능합니다.

3. Source checkout 받을 Git 사용자 계정을 입력합니다. 해당 계정은 Repository 생성 권한이 있어야 합니다. Deploy Group 에서 배포를 수행 할 때 소스 코드와 분리 된 GitOps 용 Repository 가 필요한데, 여기서 입력하는 계정으로 GitOps Repository를 생성하고, GitOps 배포를 수행합니다.

4. Git Password 를 입력합니다.

5. 입력이 완료되면 Save 버튼을 클릭해 Secret 을 저장합니다.

동일한 화면에서 이미 생성 된 Secret 을 수정, 삭제할 수 있습니다.

생성 한 Secret 을 선택한 후 Test Connection 버튼을 클릭해 접속이 가능한지 확인합니다.

Container Image 정보 입력

빌드한 Container Image 를 저장 할 Image Registry 의 정보를 입력합니다.

• Image Build (필수) : Image Build 체크를 해제하면 Image 를 생성하지 않고 어플리케이션 빌드만 수행할 수 있습니다. 라이브러리를 생성해서 Nexus나 Artifactory 같은 Repository 에 push 할 수 있습니다.

• Image Repository (필수) : Container Image 를 업로드 할 Image Repository URL 을 입력합니다.

• Secret (필수) : Image 를 업로드 할 때 필요한 계정 정보를 입력합니다. Source Repository 와 동일하게 Secret 관리 화면을 통해 계정 정보를 등록하고 선택할 수 있습니다.

• Context : Image 빌드를 수행 할 때 파일 정보들을 읽어들일 Build Context 의 경로를 입력합니다. Build Context 에는 소스 코드 (또는 Artifact), 메타파일 등 Image 를 생성하기 위해 필요한 파일들이 존재해야 합니다. 입력하지 않을 경우 Source Repository 의 root 경로가 기본값으로 사용됩니다.

• Dockerfile : Image 빌드 할 때 필요한 Command 들을 정리한 Dockerfile 의 파일명을 입력합니다. 입력하지 않을 경우 기본값은 Dockerfile 입니다.

• Image build Argument : Image 빌드를 수행 할 때 key, value타입의 env나 파라미터를 추가 할 수 있습니다.

기본 정보를 입력한 후 Save 버튼을 클릭하면 ZCP Application 이 생성됩니다.

저장 한 후 ZCP Application 이 생성 된 목록 화면입니다.

테이블 각 항목의 의미는 다음과 같습니다.

파이프라인 설정하기

하나의 ZCP Application 은 여러 개의 빌드 파이프라인을 생성할 수 있습니다. 각 파이프라인 별로 서로 다른 Branch 를 사용하거나, 다른 빌드 Tool, 또는 빌드 Option 을 지정할 수 있습니다.

생성 된 ZCP Application 을 이름을 클릭하거나 Actions 컬럼의 Edit 버튼을 클릭하여 상세 화면으로 이동합니다.

상세 화면은 Overview, Basic Info, Build Pipeline 세 개의 탭으로 구성되어 있습니다.

Overview 탭에서는 각 파이프라인의 요약 정보와 마지막에 실행 된 빌드의 결과를 볼 수 있고, 우측 Actions 버튼으로 빌드를 실행하거나 지난 빌드 이력을 확인할 수 있습니다.

Basic Info 탭에서는 생성 시 입력한 기본 정보를 조회 / 변경할 수 있습니다.

Build Pipeline 탭에서는 실제로 빌드 수행에 필요한 빌드 파이프라인을 구성할 수 있습니다.

파이프라인 상세

파이프라인은 1개 이상 생성 가능하며, 각 파이프라인 별로 서로 다른 Branch, 빌드 툴, 빌드 파라미터 등을 지정할 수 있습니다.

하나의 파이프라인은 아래 화면처럼 구성이됩니다.

• Pipeline Name (필수) : 사용자가 파이프라인을 식별하기 위한 이름입니다.

• Branch (필수) : 파이프라인 실행 시 소스를 체크아웃 받을 브랜치 명입니다. 하나의 소스 Repository 에 여러 브랜치를 각각 별도의 파이프라인으로 지정해서 빌드 할 수 있습니다. 예를 들어 develop, staging, master 브랜치를 가진 어플리케이션을 각 브랜치 별로 별도의 파이프라인을 만들 수 있습니다.

• Build History Count (필수) : 빌드 시 history count를 지정하여 보관 할 빌드 이력 갯수를 설정할 수 있습니다.

• Build Tool (필수) : 빌드 할때 사용 할 빌드 도구를 선택합니다. 현재 지원하는 빌드 도구는 Maven 과 Gradle, NPM 입니다. 지원하지 않는 빌드 도구를 사용해야 하는 경우 (ant 등) Build Tool 항목을 None 으로 지정하고 Dockerfile 안에서 빌드를 실행하도록 해야 합니다.

  • Maven

    • Jdk Version : 빌드 할 JDK 의 버전을 지정합니다.

    • Maven Goals : Maven 명령어를 지정합니다. 보통 Artifact 를 생성하기 위해 package 라는 goal 을 사용합니다.

    • Mirror Url : Public 에 있는 Maven Repository 에 직접 접근할 수 없는 환경인 경우 Mirror 역할을 하는 Nexus 나 Artifactory 등을 사용합니다. Maven 빌드 시 사용 할 Mirror 의 경로를 지정할 수 있습니다. 이때 Mirror 는 public (ID, Password 없이 접근 가능) 이어야 합니다.

  • Gradle

    • Jdk Version : 빌드 할 JDK 의 버전을 지정합니다.

    • Gradle Task : Gradle 빌드 시 Artifact 를 생성하도록 사용 할 Gradle Task 명입니다. 일반적으로 buildNeeded 가 사용되며 Spring Boot 앱인 경우 BootJar 도 많이 사용합니다.

    • Gradle Properties : 빌드 시 사용되는 Property 값을 key=value 형태로 지정합니다. gradle.properties 파일의 값을 덮어 쓸 때도 사용됩니다.

    • Command line options : 빌드 실행 시 gradle 커맨드 뒤에 붙일 수 있는 옵션을 추가로 입력할 수 있습니다.

  • NPM

    • Node Version : 빌드 할 NPM의 버전을 지정합니다.

    • NPM task command exclude install : install command를 제외하고 실행할 command를 입력합니다.

    • INSTALL Y/N : npm install 여부를 설정합니다.

    • Context Path (package.json) : install시 참조되는 package.json의 경로를 지정합니다.

  • None

    • Build tool 을 None 으로 지정한 경우 Dockerfile 을 이용한 Container 빌드만 수행합니다.

• Dockerfile Path : Image 빌드 시 사용 할 Dockerfile 의 경로를 지정합니다. 파이프라인 별로 서로 다른 Dockerfile 을 사용할 수 있습니다. 지정하지 않는 경우 Basic Info 에서 지정한 Dockerfile 을 사용합니다. Basic Info 에서도 지정하지 않은 경우 Source Repository 루트의 Dockerfile 을 기본으로 사용합니다.

• Auto Tagging : Image 빌드하면서 생성 되는 Image 의 Tag 를 자동으로 생성할지 여부를 설정합니다. Yes 로 지정하면 빌드를 실행 할 때마다 자동으로 생성되는 빌드 번호를 Image 의 Tag 로 사용합니다. Yes 로 지정하지 않을 경우 빌드를 수행 할 때마다 사용자가 Image tag 를 직접 입력해야 합니다.

  • Tag Prefix : Auto Tagging 을 수행 할 때 Tag 명 앞에 붙일 Prefix 를 지정합니다. Auto Tagging 이 Yes 인 경우에만 설정이 필요합니다. 예를 들어, Tag Prefix 가 dev 인 경우 dev-1, dev-2 … 로 Tag 명이 자동으로 생성됩니다.

• Image Build Argument : Image 빌드를 수행 할 때 key, value타입의 env나 파라미터를 추가 할 수 있습니다.

정보를 모두 입력하고 Save 버튼을 클릭하면 파이프라인이 저장됩니다. 저장 후 Overview 탭으로 이동하면 파이프라인 목록을 확인할 수 있습니다.

각 항목의 의미는 다음과 같습니다.

빌드 실행하기

빌드는 ZCP Application 상세 화면 중 Overview 탭에서 실행할 수 있습니다.

실행하고자 하는 파이프라인의 Actions 컬럼의 Run 버튼을 클릭합니다. Auto Tagging 이 설정 된 파이프라인은 바로 로그 화면으로 넘어가고, Auto Tagging 이 설정되지 않은 파이프라인은 태그명 입력 팝업이 뜹니다.

Auto Tagging 이 설정되어있는 파이프라인은 바로 로그 화면으로 넘어갑니다.

(1) 빌드 정보 섹션입니다.

• Result : 빌드 실행 결과가 표시됩니다. 빌드 실행 중인 경우 Spinner 가 표시됩니다.

• Source : 빌드 시 사용 되는 소스 코드의 Repository URL 입니다.

• Artifact : 빌드의 결과물에 대한 정보입니다. 이번 빌드로 생성되는 Image 의 URL 입니다.

(2) 빌드 파이프라인의 실행 단계 섹션입니다. 상위 메뉴를 태스크, 서브 메뉴를 스텝 이라고 합니다. 빌드 파이프라인의 태스크는 3단계로 나뉩니다.

파이프라인의 빌드 툴을 설정하지 않은 경우 (None) Source Checkout, Image Build & Push 두 단계의 태스크만 수행이 됩니다.

각 스텝을 클릭하면 해당 스텝의 실행 로그를 확인할 수 있습니다.

(3) 로그 섹션입니다. 실행 중인 빌드의 로그를 실시간으로 표시합니다. 이미 실행이 완료된 지난 빌드의 로그도 확인할 수 있습니다.

(4) OK 버튼을 클릭하면 빌드 로그 팝업 화면이 닫힙니다.

빌드 이력 보기

파이프라인 별로 지난 빌드의 이력을 확인할 수 있습니다.

ZCP Application 의 Overview 탭에서 빌드 이력을 보고 싶은 파이프라인의 History 버튼을 클릭합니다.

지난 빌드의 실행 이력이 카드 UI 로 표시됩니다. build pipeline에서 설정한 build history count 갯수 만큼의 빌드 이력을 확인할 수 있습니다.

각 항목의 상세 내용은 아래와 같습니다.

(1) 빌드의 실행 결과 아이콘입니다. 빌드 성공, 빌드 실패, 실행 중 3가지 상태가 있습니다.

(2) 빌드 결과의 요약 정보입니다.

• Build No : 빌드 번호입니다. 빌드 번호는 빌드가 실행 될 때마다 자동으로 채번됩니다. 파이프라인 별로 빌드 번호를 따로 가지고 있습니다. 괄호 안의 내용은 빌드 결과입니다.

• Build Time : 빌드의 시작 시간과 빌드 종료 시간입니다. 우측에는 빌드의 전체 소요 시간이 표시됩니다.

• Image : 빌드의 실행 결과물인 Image 의 URL 입니다. Image Registry, project, repository, 태그 번호로 이루어져 있습니다.

• Branch : 빌드 수행 시 사용 된 소스 코드의 브랜치명입니다.

• User ID : 해당 빌드를 수행한 사용자의 ID 입니다.

(3) 빌드 로그 보기 버튼입니다.

빌드 중지하기

실행 중인 빌드 로그 화면 또는 빌드 이력 화면의 중지 버튼을 클릭하여 실행 중인 빌드를 즉시 중단 할 수 있습니다.