Kubernetes 클러스터에 애플리케이션 배포하기 — 네이버 클라우드 플랫폼 Developer Tools (개발자 도구) 활용 실습

Published in

NAVER CLOUD PLATFORM

20 min readSep 11, 2023

DevOps의 중요도가 높아지면서 네이버 클라우드 플랫폼의 Developer Tools (개발자 도구)에 대한 관심이 높아지고 있습니다. 그러나 DevOps에 대한 체계적인 이해가 부족한 경우 환경을 구축할 때 서비스 간의 연관 관계와 특징을 파악하는 데 어려움을 겪을 수 있습니다.

네이버 클라우드 플랫폼 사용자 분들의 서비스 사용 진입 장벽을 낮추고 편리함을 알리기 위해 간단한 실습을 준비하였습니다. 네이버 클라우드 플랫폼 Developer Tools를 활용한 실습 과정을 소개합니다.

Developer Tools 소개

네이버 클라우드 플랫폼은 소프트웨어 개발 환경을 신속하고 안전하게 구축 및 배포할 수 있도록 Developer Tools 서비스를 제공합니다. 사용자는 SourceCommit, SourceBuild, SourceDeploy, SourcePipeline 4종의 서비스를 통해 개발 편의성을 높일 수 있습니다. 각 서비스는 아래의 목적으로 사용되며 DevOps의 전 과정을 지원합니다.

SourceCommit : 개발에 필요한 모든 형태의 파일을 안전하게 저장하고 관리할 수 있는 프라이빗 Git 리포지토리
SourceBuild : 다양한 언어의 소스 코드를 손쉽게 빌드하는 완전 관리형 병렬 빌드 서비스
SourceDeploy : 새로 작성됐거나 업데이트된 소스를 서버에 자동으로 배포하고 적용하는 자동화 배포 서비스
SourcePipeline : 리포지토리, 빌드, 배포 프로세스를 통합하여 소프트웨어 출시를 자동화하는 서비스

실습 소개

앞서 소개한 SourceCommit, SourceBuild, SourceDeploy, SourcePipeline 서비스를 이용한 실습을 진행합니다. (1) 예제 코드를 빌드하여 컨테이너 이미지를 생성하고 컨테이너 레지스트리에 저장하고 (2) 저장된 컨테이너 이미지를 Kubernetes 클러스터에 배포하고 애플리케이션이 올바르게 동작하는지 확인하면 (3) 해당 애플리케이션은 호출 시 파드의 IP 주소, 이름, 현재 시간, URI 정보를 반환하게 됩니다.

실습 진행을 위해 아래 서비스 리소스가 준비되어 있어야 합니다.

빌드를 위해 사용할 코드가 존재하는 프라이빗(퍼블릭) Github 리포지토리 → 예제 하단 첨부 참고 (Dockerfile, app.py, requirements.txt, flask-deployment.yaml, flask-service.yaml)
빌드 결과물이 직접 저장되는 Object Storage
빌드 결과물인 컨테이너 이미지를 저장하고 관리하는 Container Registry
빌드 결과물을 배포 할 Kubernetes Service

[프라이빗 Github 리포지토리 예제 (첨부)]

Dockerfile — 파일 다운로드
app.py — 파일 다운로드
requirements.txt — 파일 다운로드
flask-deployment.yaml — 파일 다운로드
flask-service.yaml — 파일 다운로드

SourceCommit을 이용하여 외부 리포지토리 복사 이후 커밋 진행하기

외부 리포지토리 복사

SourceCommit에서는 신규 리포지토리를 생성할 수도 있지만 기존의 리포지토리를 복사할 수도 있습니다. 이번에는 Github의 프라이빗 리포지토리를 복사하여 진행하겠습니다. 상단의 외부 리포지토리 복사 버튼을 눌러 리포지토리 복사를 진행합니다.

리포지토리 이름과 복사할 Git URL을 입력합니다. 퍼블릭 리포지토리 복사 시 다음 단계로 바로 진행할 수 있지만 Github의 프라이빗 리포지토리 복사 시 ID는 Github에는 아이디, Password에는 Personal access token 값 입력이 필요합니다.

모든 값을 입력한 다음 Git 연결 확인을 통해 정상적으로 연결이 되었는지 확인하고 리포지토리를 생성합니다.

서브 어카운트 권한 설정

생성한 리포지토리를 이용하기 위해서는 서브 어카운트의 계정 설정이 필요합니다. 실습에서는 “NCP_SOURCECOMMIT_MANAGER” 권한을 부여하여 모든 기능을 이용할 수 있도록 하였습니다.

사용할 서브 어카운트로 로그인 한 이후 [GIT 계정/GIT SSH 설정] 버튼을 클릭합니다. 패스워드를 설정한 다음 적용을 클릭합니다. 서브 어카운트 계정 명과 비밀번호로 리포지토리에 로그인할 수 있습니다.

로컬 복사 및 커밋 진행

SourceCommit은 HTTPS/SSH 방식의 클론을 제공하고 있습니다. GIT 계정 설정을 진행하였으므로 HTTPS로 클론을 진행하도록 하겠습니다. 리포지토리 내부에서 CLONE URL을 클릭합니다.

다음 명령어를 로컬에서 입력하여 리포지토리를 클론합니다. User 및 Password 는 이전에 설정한 정보로 입력합니다.

$ git clone https://devtools.ncloud.com/[address].git

클론이 완료되면 환경에 알맞은 내용으로 파일을 수정해야 합니다. 예를 들어 flask-deployment.yaml 파일의 경우 Deployment의 이미지를 알맞은 컨테이너 레지스트리 주소로 변경이 필요합니다.

커밋 이후 콘솔에서 내역을 확인할 수 있습니다. 신규로 생성한 커밋 이외에도 리포지토리 복사 이전의 커밋 내역의 조회가 가능합니다.

SourceBuild를 이용하여 빌드 프로젝트 생성 및 빌드 진행하기

SourceBuild를 이용하면 다양한 빌드 환경을 선택해서 빌드를 진행할 수 있습니다. 생성한 리포지토리를 대상으로 지정해 빌드를 진행한 다음 컨테이너 이미지를 생성한 다음 확인해 봅니다.

빌드 프로젝트 생성

SourceBuild 접근 이후 [빌드 프로젝트 생성] 버튼을 클릭하여 신규 프로젝트의 생성을 준비합니다.

빌드 프로젝트 이름을 정하고 설명을 작성합니다. 빌드 대상은 이전에 생성한 “devtools-example” 리포지토리로, 빌드 브랜치는 “master”로 지정합니다.

[이미지 6] 빌드 프로젝트 기본 설정하기 (빌드 대상, 리포지토리, 브랜치 지정)

다음 단계에서는 실제 빌드 환경을 설정합니다. 사용할 운영체제와 빌드 런타임은 기본 설정인 Ubuntu 16.04, base로 선택합니다. 도커 이미지 빌드를 진행할 예정이므로 ‘도커 이미지 빌드’ 설정을 진행합니다. 빌드 시 사용되는 도커 엔진 버전과 컴퓨팅 유형은 알맞은 버전으로 선택합니다.

빌드 시작 후 종료까지의 최대 대기 시간과 환경 변수는 별도 수정이 필요한 부분이 아니라 그대로 두고 진행하였습니다.

다음 단계에서는 빌드 명령어를 설정합니다. 도커 이미지 빌드를 진행하므로 빌드 전 명령어와 빌드 후 명령어에 빌드 상황을 알 수 있도록 간단한 명령어를 기입하면 좋습니다. 빌드 명령어에는 “/bin/sh”에서 실행 가능한 명령어만 수행이 가능합니다. 해당 쉘에 존재하지 않는 명령어를 입력하는 경우 빌드가 실패되므로 설정에 주의가 필요합니다.

도커 이미지 빌드 설정에는 Dockerfile 경로와 빌드를 통해 생성된 컨테이너 이미지가 저장되는 Container Registry, 이미지 명, 이미지 태그의 설정이 필요합니다. 이미지 태그는 # 을 통해 빌드 시마다 증가시킬 수 있으며 latest로 설정하여 두 개의 태그로 동시에 저장할 수 있습니다. 배포 파일의 이미지 태그를 latest로 작성하여 latest 설정을 활성화 하였습니다.

도커 이미지 빌드 시 ‘빌드 명령어 설정’ 단계에서 이미지 저장 설정이 진행되므로 업로드 설정을 별도로 진행하지 않아도 됩니다. 하지만 ‘일반 빌드’를 진행하는 경우 빌드 결과물의 저장이 필요합니다. 빌드 결과물을 저장할 경우, 설정한 Object Storage에 zip 파일로 압축되어 저장됩니다.

‘빌드 완료 후 이미지 업로드 설정’ 기능은 빌드 환경을 컨테이너 이미지로 저장하는 기능입니다. 기본 빌드 환경에 빌드를 위한 설정이 진행되는 경우 해당 설정을 유지하여 다음 빌드 시 빌드 시간을 단축시키기 위해 사용됩니다. 해당 기능은 도커 빌드를 통해 생성된 이미지의 저장 기능과는 별개의 기능입니다.

‘추가 상품 연동’ 단계에서는 Cloud Log Analytics (로그 분석 서비스) 또는 File Safer (보안 서비스)와 연동할 수 있으나, 본 케이스에서는 별도로 필요한 기능은 아니라 ‘연동 안함’으로 설정하였습니다.

다음 단계에서 최종적으로 설정을 확인한 다음 배포 프로젝트를 생성합니다.

빌드 진행

생성된 빌드 프로젝트 내부에서 [빌드 시작하기] 버튼을 클릭하면 빌드가 진행됩니다. 빌드 시작 이전 일회성으로 빌드 설정을 진행할 수 있는데, 계속 유지 되는 설정이 아니기에 추후 변경이 필요한 경우 빌드 프로젝트의 수정이 필요한 점은 참고해 주세요.

빌드 시작 시 빌드 로그를 조회하여 빌드 상황을 확인할 수 있습니다. 도커 빌드를 진행하였으므로 빌드 명령어 단계에서 설정한 Dockerfile에 따라 빌드가 진행됨을 알 수 있습니다. 베이스 이미지에서 Flask 패키지를 다운로드하고 작성한 app.py를 실행한 다음 설정한 컨테이너 레지스트리에 업로드하는 로그를 조회 가능합니다.

빌드 결과물 확인

빌드가 성공하였다면 콘솔 상의 Containers > Container Registry에서 빌드 결과물을 확인할 수 있습니다. 레지스트리를 선택한 다음 이미지 리스트로 이동하여 생성된 이미지를 확인합니다. Tag 란에서 첫 번째 태그(0.0.1)과 설정한 latest 태그가 생성된 것을 확인할 수 있습니다.

SourceDeploy를 이용하여 Kubernetes 클러스터에 빌드 결과물 배포하기

빌드를 통해 생성된 컨테이너 이미지는 SourceDeploy를 이용해 네이버 클라우드 플랫폼의 Kubernetes Service 클러스터에 배포할 수 있습니다. 배포 프로젝트를 생성하고 이미지를 배포하여 애플리케이션의 동작을 확인해 봅니다.

배포 프로젝트 생성

SourceDeploy 콘솔에서 [배포 프로젝트 생성] 버튼을 클릭하여 신규 배포 프로젝트를 생성합니다. 프로젝트 이름을 작성한 뒤 배포 환경을 설정합니다.

프로젝트 생성 시 여러 개의 배포 환경을 설정할 수 있습니다. 실제 환경에 직접 배포를 진행할 것이므로 real stage에 사용하고 있는 Kubernetes Service의 클러스터를 배포 타겟으로 지정합니다. 최종 확인 이후 프로젝트를 생성합니다.

배포 시나리오 생성

배포 프로젝트를 생성한 이후 배포 시나리오의 생성이 필요합니다. 프로젝트 선택 후 배포 시나리오 [생성] 을 클릭하여 시나리오를 생성합니다.

클러스터에 배포할 매니페스트 파일이 위치한 리포지토리를 선택하고 배포 파일 경로를 입력합니다. Kubernetes 클러스터에서 컨테이너 이미지를 실행하기 위한 Deployment와 외부에서 접근할 수 있도록 로드밸런서를 생성해주는 Service 파일을 추가하였습니다.

배포 전략은 Rolling (롤링), 블루/그린, Canary (카나리)를 제공합니다. 롤링 업데이트를 선택하여 애플리케이션이 점진적으로 업데이트 되도록 설정합니다. 최종 확인 이후 배포 시나리오의 생성을 완료합니다.

[이미지 19] 배포 시나리오 생성 > 배포 전략 설정하기 (Rolling 선택)

배포 진행

배포 시나리오 생성 이후 [배포 시작하기] 버튼을 클릭하여 배포를 진행합니다.

[이미지 20] 배포 시나리오 생성 > 배포 전략 설정하기 (Rolling 선택)

배포 진행 시 로그 및 상태를 확인해 배포 과정을 모니터링할 수 있습니다. Deployment와 Service의 배포가 완료되어 배포 완료 상태로 변경될 때까지 대기합니다.

배포가 정상적으로 진행되지 않은 경우 배포 로그를 조회하여 문제를 확인하거나 클러스터에 매니페스트를 직접 적용하여 정상적으로 수행이 되는지 확인이 필요합니다.

배포 결과 확인하기

배포가 완료되면 Load Balancer 콘솔에서 default-flask-* 라는 이름의 로드밸런서를 확인할 수 있습니다. 해당 로드밸런서는 app.py를 실행 중인 Flask 서버와 연결되어 있습니다.

로드밸런서에 접속하여 app.py에 기재된 파드의 아이피 주소, 파드 이름, 시간, URI 가 나타나는지 확인합니다. 접근되지 않는 경우 배포가 정상적으로 이루어지지 않은 것이므로 배포 이전 단계로 돌아가 상태의 확인이 필요합니다.

[이미지 23] 로드밸런서 접속 > 파드의 IP 주소, 이름, 시간, URI 확인

SourcePipeline을 이용하여 커밋 시 자동 배포되도록 구성하기

작업 환경에서 코드를 변경하고 커밋, 빌드, 배포를 수동으로 진행하면 인력이 낭비되고 일관성 있는 버전 교체가 어렵게 됩니다. CI/CD의 자동화를 위하여 SourcePipeline을 이용해 리포지토리에 신규 커밋 시 자동으로 빌드 및 배포가 진행되도록 파이프라인을 구성하도록 하겠습니다.

파이프라인 생성

SourcePipeline 콘솔에서 파이프라인 생성 버튼을 클릭하여 신규 파이프라인을 생성합니다.

파이프라인의 이름과 설명을 작성한 다음 파이프라인 구성을 시작합니다.

빌드 및 배포를 진행하는 아주 간단한 파이프라인을 구성합니다. 파이프라인은 ‘작업 구성’과 ‘트리거 설정’ 항목으로 나뉘어져 있습니다.

작업 추가를 눌러 SourceBuild 타입의 작업과 SourceDeploy 타입의 작업을 생성합니다. 각 작업은 이전에 생성한 프로젝트를 설정하면 됩니다.

이후 생성된 작업을 알맞은 순서로 배치합니다. SourceBuild 작업 이전에는 선행 작업이 없으므로 가장 먼저 배치하고 빌드 이후 배포가 진행되도록 SourceDeploy 작업을 배치합니다.

파이프라인이 자동으로 실행될 수 있도록 트리거를 구성합니다. Push, 파이프라인, 예약 트리거를 선택할 수 있으며 시나리오에서는 Push 트리거를 설정하였습니다. 아래 설정은 마스터 브랜치에 푸시 이벤트가 발생하는 경우 파이프라인이 실행되도록 하는 트리거 설정입니다.

[이미지 27] 파이프라인 자동 실행을 위한 트리거 (Trigger) 설정

모든 설정이 완료되면 확인 후 파이프라인을 생성합니다.

파이프라인 실행

생성된 파이프라인은 수동으로 실행하여 확인이 가능합니다. 다만 트리거를 설정하였으므로 리포지토리에 커밋을 진행하여 실제로 파이프라인이 실행되는지 확인합니다.

파이프라인에서 확인 시 트리거에 의해 작업이 실행 되었음을 알 수 있습니다.

이처럼 파이프라인을 구성해서 복잡한 빌드 및 배포 작업을 자동화하고 효율적으로 관리할 수 있습니다.

Developer Tools 편리하게 사용하기

앞의 과정에서 사용자 애플리케이션을 컨테이너 이미지로 만들고 Kubernetes 클러스터에 배포하는 실습을 진행하였습니다. Developer Tools 서비스는 DevOps 기본 기능 이외에도 사용자가 편리하게 사용할 수 있도록 다양한 기능을 제공하고 있습니다. 이 기능들 중 실제 환경에서 사용할 수 있는 기능을 소개합니다. 사용자는 해당 기능으로 좀 더 빠르고 쉽게 개발 환경을 구성할 수 있습니다.

Custom 이미지 사용하기

SourceDeploy 프로젝트 생성 이후 빌드 환경 구성 시 빌드 환경 이미지는 SourceBuild에서 관리되는 이미지, Container Registry의 이미지, Public Registry의 이미지를 사용할 수 있습니다. SourceBuild에서 관리되는 이미지에 적합한 빌드 환경 이미지가 없는 경우 사용자는 Public Registry에 위치한 컨테이너 이미지를 빌드 환경으로 사용할 수 있습니다.

예를 들어 python 빌드 환경으로 기본 제공되는 버전은 2.7, 3.5입니다. 상위 버전의 빌드 환경이 필요한 사용자는 SourceBuild에서 관리되는 이미지를 이용해 빌드를 진행할 수 없습니다.

이 때에 사용자는 자신의 Container Registry에 알맞은 python 이미지를 저장하여 사용할 수 있습니다. Container Registry를 사용하고 있지 않은 경우 Public Registry를 선택하여 Dockerhub에 존재하는 python 이미지를 사용할 수 있습니다.

Dockerhub에 존재하는 이미지의 경우 별도 표기 없이 이미지 명과 태그를 입력하면 사용할 수 있고, 이외 이미지는 레지스트리 주소를 포함하여 설정하면 사용 가능합니다.

이처럼 Custom 이미지를 사용하면 각자에게 알맞은 빌드 환경을 구성할 수 있습니다.

빌드 시간 단축하기

일반적으로 빌드를 진행할 때 많은 시간을 관련 패키지를 다운로드하는 데 소요하게 됩니다. 패키지는 구성 이후 변경되는 빈도가 낮으므로, 패키지가 설치된 기존 빌드 환경을 다음 빌드에서 사용하면 이후 빌드 시간을 단축할 수 있습니다.

기존 빌드 환경을 재사용할 수 있도록 SourceDeploy에서는 ‘빌드 완료 후 이미지 업로드’ 기능을 제공하고 있습니다. 빌드 환경 구성 시 해당 기능을 선택하고 빌드 이미지를 저장하면 빌드 시 사용한 빌드 환경이 컨테이너 이미지로 저장됩니다.

[이미지 32] SourceDeploy > 빌드 완료 후 이미지 업로드 기능

빌드 완료 후 저장된 빌드 환경은 지정한 Container Registry에 저장됩니다. 이후 빌드 시 Custom 이미지 사용 기능을 이용해 Container Registry의 이미지를 선택하면 저장된 빌드 환경을 사용할 수 있습니다. 예를 들어 python 빌드 프로젝트에서 requirements.txt를 통해 Flask 관련 패키지를 관리하는 상황이라면 최초 빌드 시 Flask 패키지를 다운로드하고 해당 환경을 저장할 수 있습니다.

저장된 환경을 사용하면 Flask 패키지가 이미 다운로드 되어있으므로 별도의 추가 작업을 진행하지 않아도 됩니다. 추후 변경 사항이 생기는 경우 다시 빌드 환경을 저장하여 사용하면 됩니다. 만일 저장된 빌드 환경에 문제가 발생하는 경우 이전 버전의 빌드 환경을 사용할 수 있으므로 편리하게 빌드 환경을 관리할 수 있습니다.

배포 승인 프로세스

SourcePipeline을 구성하면 SourceCommit에 커밋 발생 시 SourceBuild 프로젝트에서 빌드가 시작되고 SourceDeploy 프로젝트에서 빌드 결과물을 배포할 수 있습니다. 하지만 모든 빌드 결과물이 커밋 발생 시마다 배포된다면 문제가 발생할 수 있습니다. 이를 방지하기 위하여 SourceDeploy에서는 배포 승인 프로세스를 구성할 수 있습니다. 해당 기능은 SourceDeploy의 서브 어카운트 정책 구성을 통해 이용 가능합니다.

서브 어카운트 메뉴의 Policy 카테고리에 접근 이후 [+정책 생성] 버튼을 클릭합니다. SourceDeploy 서비스 선택 이후 변경 권한에서 [requestDeploy] 권한을 확인할 수 있습니다. 해당 권한은 프로젝트별로 부여할 수 있습니다. 원하는 프로젝트를 선택하여 관련 룰을 생성하고 서브 어카운트에 정책을 할당하여 줍니다.

[이미지 33] 서브 어카운트 > Policy (정책 설정) > SourceDeploy 권한 설정

이후 룰을 부여받은 서브 어카운트는 배포 프로젝트 접근 시 배포 시작이 아닌 ‘배포 승인 요청’으로 변경됩니다. [배포 승인 요청] 버튼 클릭 시 배포는 ‘배포 승인 대기 중’ 단계를 거치며 승인 권한을 가진 사용자가 승인하기 전까지 배포가 되지 않고 대기 상태로 남아있게 됩니다.

이처럼 배포 승인 프로세스를 도입하면 애플리케이션 개발 및 유지 보수 과정에서 안정성을 확보할 수 있으며, 일관성을 유지할 수 있습니다. 또한 안정적인 빌드 및 배포 프로젝트 운영을 위하여 사용자마다 알맞은 서브 어카운트 정책 부여 및 관리가 필요하다는 점도 꼭 기억해 주세요.

마치며

이번 실습을 통해 작은 프로젝트이지만 4종의 상품을 활용하여 DevOps의 전반적인 흐름을 체험하게 되었습니다. 꼭 제공하는 모든 상품을 사용하여 DevOps 환경을 구성해야 하는 것은 아닙니다. 중요한 것은 각 단계에서 가장 적합한 도구를 선택하고 그것들을 유기적으로 연결하여 상황에 알맞은 개발 환경을 구축하는 것입니다.

이번 실습의 경험을 바탕으로 실제 업무에서도 DevOps의 원리를 효과적으로 적용하여 성공적인 결과를 얻기를 기대합니다.