GitLab을 활용한 동적이고 확장 가능한 멀티 클라우드 배포 파이프라인 구축

Alex Cohen

Volterra의 솔루션 팀은 Volterra 플랫폼의 잠재적 가치를 보여주기 위해 다양한 활용 사례를 설계하고 관리합니다. 이러한 활용 사례는 고객이 Volterra를 처음으로 직접 경험할 때 활용할 수 있는 안내서로 제작되는 경우가 많습니다.

솔루션 팀은 사람의 개입을 최대한 줄이면서 내부에서 필요할 때마다 사용 사례를 배포할 수 있는 더 빠른 자동화 방식을 원했습니다. 배포 대상은 IaaS 플랫폼(AWS, Azure, GCP)과 프라이빗 데이터 센터 환경(VMware vSphere 및 Vagrant KVM)을 모두 사용하는 하이브리드 멀티 클라우드 환경이었습니다. 각 사용자가 가상화 플랫폼이나 IaaS 공급자별로 별도의 액세스 계정을 만들거나 추가 사용자 자격 증명을 관리할 필요 없이, 어떤 환경에서든 배포를 생성할 수 있는 단일 도구를 제공하여 이러한 환경의 관리를 간소화하고자 했습니다. 또한 이 도구는 여러 사용자와 배포를 동시에 지원할 수 있도록 확장 가능해야 했습니다.

요약하면, 우리가 해결하고자 했던 핵심 과제는 사용자 입력을 최소화하면서 하이브리드 멀티클라우드 환경으로 확장하고 여러 배포를 동시에 처리할 수 있는 자동화된 솔루션 사용 사례 배포 도구를 만드는 것이었습니다.

Altered-Carbon 프로젝트(AC)

이를 위해 저희는 Altered-Carbon이라는 프로젝트를 만들었으며, 흔히 AC로 줄여 부릅니다. AC 프로젝트는 20개가 넘는 다양한 Volterra 솔루션 사용 사례를 생성할 수 있는 동적 GitLab 파이프라인입니다. 파이프라인 자동화를 통해 단일 명령으로 실행되는 ‘버튼식 배포’를 구현하여, 사용자가 필요할 때 또는 매일 예약된 cron 작업을 통해 여러 사용 사례 클러스터를 손쉽게 배포할 수 있도록 했습니다.

참고로 AC에서는 각 배포를 STACK 이라고 하고, 각각의 고유한 사용 사례를 SLEEVE라고 합니다.

프로젝트 개발

AC 프로젝트 개발은 hello-cloud 사용 사례를 자동화하여 첫 번째 SLEEVE로 구현하는 것에서 시작했습니다. hello-cloud 사용 사례는 AWS와 Azure에 Volterra 사이트를 생성한 다음, 이 사이트들을 하나의 Volterra VK8s(가상 Kubernetes) 클러스터로 통합하고 VK8s를 사용해 두 사이트에 걸쳐 10개 파드로 구성된 애플리케이션을 배포합니다. 먼저 Volterra API를 활용하는 추가 Terraform 템플릿과 셸 스크립트를 만들어 CI/CD 파이프라인으로 관리할 수 있는 완전 자동화된 GitLab 워크플로를 구축했습니다. 그런 다음 이 배포 방법론을 재사용 가능하고 확장 가능하게 만드는 작업에 착수했습니다.

고유한 명명 규칙을 추가하는 것은 설계 과정에서 다음으로 해결해야 할 문제였습니다. 단일 Volterra 테넌트 환경에 사용 사례를 여러 번 배포할 수 있도록 하려면 각 STACK에서 생성되는 리소스에 고유한 이름을 지정하여 동일한 Volterra 테넌트 환경의 다른 STACK에 있는 리소스와 이름이 중복되지 않도록 해야 했습니다. 잠재적인 명명 규칙 충돌을 해결하기 위해 파이프라인 트리거에 사용자가 제공하는 고유한 환경 변수를 도입하기 시작했으며, 이는 프로젝트의 핵심 요소가 되었습니다. 환경 변수 STACK_NAME 을 도입하고 terraform에서 사용하여 특정 STACK과 관련된 모든 리소스의 이름에 사용자가 정의한 문자열을 포함하도록 했습니다. 커밋 시 트리거하는 대신, AC 파이프라인 작업의 트리거 조건은 GitLab 프로젝트 CI 트리거 토큰을 사용하는 GitLab 사용자 API 호출로 트리거될 때만 실행되도록 설정했습니다. 이를 통해 사람의 입력이나 외부 API 호출로 파이프라인을 제어할 수 있었습니다. 다음 예시와 유사한 API 호출을 사용하면 사용자는 단일 명령으로 리소스 충돌 없이 여러 배포를 생성하려는 목표를 달성할 수 있었습니다.

그런 다음 이 모델을 기반으로 추가 배포 옵션을 만들고자 했습니다. hello-cloud의 AWS 및 Azure 사이트 배포 역시 AC를 통해 각각 독립적으로 배포하려는 개별 사용 사례였습니다. 이 과정에서 GitLab과 관련된 첫 번째 주요 문제에 부딪혔습니다. GitLab CI/CD 파이프라인에서는 프로젝트 파이프라인의 모든 작업이 서로 연결되어 있습니다. 하지만 hello-cloud 배포에 필요한 많은 작업이 AWS 또는 Azure 사이트 배포에는 필요하지 않았기 때문에 이는 직관적이지 않았습니다. 본질적으로 우리가 원한 것은 하나의 GitLab 프로젝트 CI 파이프라인 안에 여러 개의 독립적인 파이프라인을 두고, 필요할 때 각각 별도의 CI 작업 세트로 온디맨드 실행할 수 있도록 하는 것이었습니다.

이 문제를 해결하기 위해 GitLab CI/CD의 only/except 옵션을 적용한 파이프라인 구조에 환경 변수 SLEEVE를 도입했습니다. 이를 통해 파이프라인 트리거에 제공된 SLEEVE 값에 따라 어떤 파이프라인에서든 트리거된 CI 작업을 제한할 수 있었습니다. 마침내 simple-aws, simple-azure, hello-cloud라는 초기 SLEEVE 옵션 3개를 마련했습니다. 각 SLEEVE는 사용자가 배포하려는 사용 사례를 정의하여 트리거된 파이프라인의 CI 작업을 제어했으며, STACK_NAME은 트리거된 파이프라인에서 생성되는 리소스의 이름을 지정했습니다. 두 환경 변수를 모두 포함한 다음 명령 구조는 오늘날에도 사용되는 가장 기본적인 AC 명령이 되었습니다:

다음 이미지는 SLEEVE 환경 변수를 변경할 때마다 AC 파이프라인의 각 실행에서 트리거되는 작업이 어떻게 달라지는지를 시각적으로 보여줍니다.

SLEEVE “simple-aws” 파이프라인:

SLEEVE “hello-cloud” 파이프라인:

또한 파이프라인 트리거에 환경 변수 DESTROY가 지정되면 실행되는 추가 작업도 도입했습니다. 이를 통해 AC가 생성한 리소스를 제거하는 역방향 옵션을 제공할 수 있습니다. 다음은 기존 STACK의 리소스를 제거하는 예시입니다:

그 밖의 환경 변수는 기본값과 함께 GitLab에 저장되었으며, 트리거 명령에 값을 추가하여 재정의할 수 있었습니다. 예를 들어 Volterra 테넌트 환경의 API URL은 VOLTERRATENANT 환경 변수에 저장되었습니다. 사용자가 API 명령에 VOLTERRATENANT 환경 변수를 추가하면 기본값이 재정의되고 배포 대상이 원하는 위치로 변경되었습니다. 솔루션 팀은 수십 개의 Volterra 테넌트 환경을 관리하며 당면한 작업에 따라 환경을 전환할 수 있어야 하므로, 이 기능은 내부 테스트 역량에 매우 중요한 것으로 입증되었습니다.

이러한 선택적 환경 변수를 사용하면 필요할 때 배포를 더욱 세밀하게 제어할 수 있는 한편, 추가적인 관리 부담을 원하지 않는 사용자에게는 더 간단한 기본 배포 옵션을 제공할 수 있었습니다. 또한 스테이징 환경과 프로덕션 환경의 배포를 손쉽게 전환할 수 있었으며, 이는 최대 규모의 AC 사용 고객에게 필수적인 기능이 되었습니다.

솔루션 사용 사례: 야간 회귀 테스트

앞서 언급했듯이 AC의 각 SLEEVE는 고객이 제품을 처음 접할 때 자주 사용하게 되는 Volterra 사용 사례를 나타냈습니다. 이러한 사용 사례가 정상적으로 작동하고 버그가 없도록 보장하는 것은 제품에 대한 좋은 첫인상을 심어 주는 데 핵심적이었습니다. AC가 만들어지기 전에는 사용 사례가 정상적으로 작동하며 최신 Volterra 소프트웨어 및 API 버전에 맞게 업데이트되어 있는지 확인하는 테스트에 많은 시간이 소요되었습니다. 각 사용 사례에서 수동으로 처리해야 하는 부분 때문에 회귀 테스트에 제약이 있었고, 테스트가 충분히 자주 수행되지 않았을 뿐만 아니라 인적 오류가 발생하기도 쉬웠습니다.

하지만 AC 자동화를 활용하면 매일 예약된 작업을 통해 SLEEVE로 특정 사용 사례의 배포를 실행한 다음, 배포가 완료되거나 실패한 후 생성된 리소스를 제거할 수 있었습니다. 이 방식은 스테이징 환경과 프로덕션 환경 모두에서 최근 변경 사항이 사용 사례 배포에 영향을 미쳤거나 Volterra 소프트웨어에 버그를 유발했는지 테스트하는 데 사용되었습니다. 이를 통해 사용 사례 가이드에서 발견된 버그를 수정하거나 Volterra 소프트웨어의 버그를 신속하게 포착하여 해결 티켓을 제출할 수 있었습니다.

서로 다른 SLEEVE를 사용해 여러 스택을 동시에 생성하도록 GitLab API 트리거 명령을 사용하는 예약 작업이 포함된 별도의 리포지토리와 파이프라인을 만들었습니다. 각 스모크 테스트 작업은 독립적인 AC 파이프라인을 통해 스택 생성을 트리거하는 것으로 시작했습니다. 그런 다음 스모크 테스트 작업은 파이프라인 트리거 호출의 stdout에서 파이프라인 ID를 가져오고, GitLab API를 사용해 자신이 트리거한 파이프라인의 상태를 모니터링했습니다. 파이프라인이 완료되면(성공 또는 실패 여부와 관계없이) 테스트 후 리소스를 제거하기 위해 자신이 생성한 동일한 STACK에서 삭제 파이프라인을 실행했습니다.

다음 이미지는 이 프로세스를 자세히 설명하고, 생성 및 삭제 명령을 실행할 때 AC에서 트리거되는 작업을 보여줍니다:

스모크 테스트 파이프라인이 실패했을 때, 문제를 재현하기 위해 AC 트리거에서 사용할 수 있는 환경 변수를 제공할 수 있었습니다. 이 정보를 기술 이슈 티켓에 포함함으로써 개발자들이 실패한 배포를 손쉽게 재현할 수 있었습니다. 이후 더 많은 SLEEVES가 완성됨에 따라 CI 파이프라인에 작업을 계속 추가하여 테스트 범위를 확대했습니다. 이러한 테스트의 가시성을 더욱 높이기 위해 Slack 연동을 추가했으며, 스모크 테스트 작업이 각 파이프라인 실행의 성공 또는 실패 메시지를 관련 링크 및 세부 정보와 함께 Altered-Carbon 및 Smoke-Test 프로젝트의 해당 CI 웹 페이지로 전송하도록 했습니다.

스택 기록 관리 및 파이프라인 웹 URL 탐색

AC가 발전하면서 솔루션 팀의 사용자가 추가되고 점점 더 많은 스택이 생성됨에 따라 프로젝트의 복잡성도 증가했습니다. 이로 인해 GitLab 파이프라인 웹 UI를 탐색할 때 근본적인 문제가 발생하기 시작했습니다. GitLab 파이프라인을 매우 비전통적인 방식으로 사용하고 있었기 때문에, 우리가 생성한 스택과 관련된 개별 파이프라인 실행을 추적하기가 GitLab 파이프라인 웹 UI에서 어려웠습니다.

GitOps 워크플로를 통해 배포를 관리하는 GitLab 파이프라인은 정적으로 정의된 클러스터 집합을 대상으로 사용할 때 가장 적합한 것으로 보입니다. 이 경우 GitLab 파이프라인을 실행할 때마다 항상 동일한 클러스터와 리소스에 영향을 미칩니다. 따라서 이러한 클러스터의 배포 이력은 GitLab 웹 UI에 표시되는 파이프라인 이력과 같습니다. 그러나 AC는 동적으로 작동하며 끊임없이 변화하는 리소스 집합을 처리합니다. 각 파이프라인 실행에서는 완전히 다른 작업 집합을 사용하여 서로 다른 가상화 공급자의 다양한 리소스 STACK을 관리할 수 있습니다. SLEEVE 및 STACK 규칙으로 인해 이러한 차이가 생기면서 어떤 파이프라인이 어떤 STACK에 해당하는지 파악하기가 매우 어려워졌습니다. 예를 들어 AC의 GitLab CI/CD 파이프라인 웹 UI를 살펴보겠습니다.

이 화면만으로는 각 파이프라인을 일일이 확인하지 않고서는 개별 파이프라인이 어떤 STACK 또는 SLEEVE를 변경하는지 알 수 없습니다. 하루에 수백 개의 파이프라인이 실행되는 경우, 특정 STACK을 생성하거나 삭제한 파이프라인 실행을 찾거나 해당 STACK의 구체적인 세부 정보를 확인하는 작업은 매우 번거로울 수 있습니다. 이 문제를 해결하기 위해 AC 개발 초기 단계에서 간단한 기록 관리 시스템을 추가했습니다. 모든 파이프라인이 실행되기 전에 stack-records라는 작업이 실행됩니다. 이 작업은 스택 생성 시 세부 정보를 수집하고 json 파일을 생성한 다음, tfstate 백업을 저장하는 데 사용하는 S3 스토리지 버킷에 업로드합니다. 아래는 스택 레코드의 예입니다:

stack-record.json 파일에는 다음과 같은 각 스택의 세부 정보가 포함됩니다:

• 사용된 Volterra 테넌트 환경.
• 어떤 SLEEVE가 사용되었는지.
• STACK이 현재 “apply” 상태로 실행 중인지, 아니면 “destroy” 상태로 리소스가 제거되었는지 여부.
• 스택을 생성한 GitLab 사용자.
• STACK을 변경할 권한이 있는 다른 사용자를 나열하는 작업 그룹입니다.
• 그리고 가장 중요한 것은, 해당 스택을 대상으로 실행된 각 파이프라인 실행의 웹 URL, 파이프라인을 트리거한 사용자, 파이프라인이 스택을 적용했는지 또는 삭제했는지 여부, 그리고 파이프라인이 트리거된 시점을 포함하는 pipelines 배열입니다.

이를 통해 각 스택과 연결된 모든 파이프라인 URL의 이력이 기록되었으며, 프로세스를 더욱 간소화하기 위해 S3 API 호출을 통해 이러한 파일에 액세스할 수 있는 간단한 CLI 스크립트도 만들었습니다. AC를 사용하는 사용자는 이 문서를 통해 스택의 이력을 추적하고, 스택 기록을 확인하여 해당 스택이 언제 변경되었는지 파악할 수 있었습니다.

스택 레코드를 통해 배포하는 파이프라인에 일정 수준의 사용자 제어 및 오류 감지 기능도 구현할 수 있었습니다. 예를 들어 AC가 만들어진 후 Volterra 소프트웨어가 변경되면서 Volterra 사이트 생성에 사용되는 사이트 클러스터 이름(STACKNAME 값에서 파생되는 값)을 17자로 제한해야 했습니다. 이에 따라 STACKNAME이 글자 수 제한을 위반하면 배포 단계를 실행하기 전에 파이프라인이 실패하도록 스택 레코드 작업에 검사 기능을 추가했습니다. 또한 AC에서 관리하는 특정 스택을 변경할 수 있는 사용자를 제한하는 사용자 권한 수준을 AC에 추가하는 등 여러 맞춤형 제어 기능도 도입했습니다.

• 관리자 수준 권한은 AC의 핵심 개발자 두 명에게 디버깅 목적으로 모든 스택을 생성하거나 삭제할 수 있는 권한을 부여합니다. - 소유자 또는 생성자 수준은 처음으로 STACK을 생성한 GitLab 사용자를 위한 권한입니다. 해당 사용자의 GitLab 이메일 값은 스택 레코드에 생성자로 기록되며, 이 사용자는 스택을 생성하거나 삭제할 수 있습니다.
• 그다음으로 작업 그룹 수준의 권한이 있습니다. GitLab 사용자 이메일을 스택 레코드의 작업 그룹 배열에 추가하면 생성자가 아닌 사용자에게도 STACK을 적용하거나 삭제할 수 있는 권한을 부여할 수 있습니다.
• 이러한 권한 수준 중 어느 것도 보유하지 않은 사용자는 스택을 변경할 수 없습니다. 해당 사용자가 권한이 없는 스택을 변경하려고 하면 리소스가 배포되기 전에 stack-records 작업이 실패합니다.

내부 사용 및 현재 테스트 범위

현재 AC는 솔루션 팀의 핵심 도구로 자리 잡아 회귀 테스트와 자동화의 대부분을 담당하고 있습니다. 주요 용도는 회귀 스모크 테스트, 확장성 테스트, 제품 과금 테스트, 그리고 제품 데모에 사용되는 간소화된 배포입니다.

자동화된 배포는 야간 회귀 테스트에서 가장 활발하게 활용되고 있습니다. 매일 밤 배포를 실행한 후 생성된 리소스를 제거하는 방식으로 각 SLEEVE를 프로덕션 및 스테이징 환경에서 테스트합니다. 변경 사항이 발생하면 이를 신속하게 감지하고 버그 보고서를 제출하여 가이드를 업데이트할 수 있습니다. 현재 테스트 범위는 다음과 같습니다:

• 보안 Kubernetes 게이트웨이.
• 웹 애플리케이션 보안.
• 표준 10개 파드로 구성된 “hipster-co” 애플리케이션과 더 가벼운 단일 파드 애플리케이션을 배포하는 네트워크 엣지 애플리케이션.
• Hello-Cloud.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant 전반의 CE 단일 노드 단일 네트워크 인터페이스 Volterra 사이트.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant 전반의 CE 단일 노드 이중 네트워크 인터페이스 Volterra 사이트.
• CE 단일 노드 단일 네트워크 인터페이스 Volterra 사이트 배포를 확장하고(GCP, VSphere 및 KVM 사용), Volterra의 확장 기능을 테스트하기 위해 여러 CE 단일 노드 단일 NIC 사이트를 생성했습니다.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant 전반에 걸친 CE 단일 노드 다중 네트워크 인터페이스 Volterra 사이트.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant 전반의 CE 다중 노드 단일 네트워크 인터페이스 Volterra 사이트.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant 전반의 다중 노드, 다중 네트워크 인터페이스 CE Volterra 사이트.

또한 Volterra 소프트웨어의 확장성을 테스트하기 위해 한 번에 최대 400개 사이트를 배포하는 프로세스를 자동화하는 특수 확장성 테스트 도구를 보유하고 있으며, GCP, vSphere 및 KVM을 사용해 테스트를 완료했습니다.

사용 사례를 신속하게 자동 배포함으로써 솔루션 팀원들은 다른 업무에 집중할 수 있어 내부 효율성이 향상됩니다. 솔루션 팀은 동영상 데모를 녹화하기 위해 AC를 사용하여 수십 개의 KVM, GCP 및 vSphere 사이트를 배포하는 경우가 많습니다. 이를 통해 기존 자동화를 기반으로 더 복잡한 인프라를 구축하는 데 사용할 Volterra 사이트를 만드는 시간을 절약할 수 있습니다. 또한 결제 정보를 기록하는 전용 Volterra 테넌트에 AWS, 웹 앱 보안, 보안 Kubernetes 게이트웨이 및 네트워크 에지 애플리케이션 사용 사례를 자동으로 배포하여 Volterra 플랫폼의 결제 기능을 테스트하는 일일 cron 작업에도 사용됩니다.

향후 계획 및 로드맵

AC를 활용한 결과는 이미 매우 성공적이며, 가까운 시일 내에 프로젝트에 추가할 기능과 개선 사항도 아직 많이 남아 있습니다.

이 프로젝트에서 가장 큰 변화는 더 다양한 사용 사례의 배포를 지원하기 위해 새로운 SLEEVE 옵션을 지속적으로 추가하고 있다는 점입니다. 새로운 SLEEVE가 추가될 때마다 야간 회귀 스모크 테스트에 새 작업을 추가하여 솔루션 배포 프로젝트의 테스트 범위를 확대합니다. 이전의 SLEEVE는 대부분 단일 노드 및 단일 네트워크 인터페이스 사용 사례에 중점을 두었지만, 최근에는 AWS, Azure, GCP, VMWare 및 KVM/Vagrant 플랫폼 전반에서 다중 노드 Volterra 사이트 클러스터와 다중 네트워크 인터페이스 사용 사례까지 SLEEVE 지원 범위를 확장했습니다.

또한 스택 기록 시스템을 개선하고자 합니다. AC 기록의 상세 수준을 높이고, 기록 저장소에 RDS 데이터베이스를 도입하여 검색 기능을 개선할 예정입니다. 이를 통해 AC 환경을 더 빠르게 검색하고, 스택 상태나 스택 생성자 등을 기준으로 스택을 조회하는 등 더욱 세분화된 검색 기능을 제공하는 것이 목표입니다. 이러한 기록을 활용해 AC로 생성된 배포를 더욱 효율적으로 시각화할 수 있는 맞춤형 UI를 구축하는 것도 로드맵에 포함되어 있습니다.

작성자 소개

Alex Cohen

Alex Cohen의 다른 블로그 게시물