GitLab을 사용하여 동적이고 확장 가능한 멀티 클라우드 배포 파이프라인 만들기

Volterra의 솔루션 팀은 Volterra 플랫폼의 잠재적 가치를 보여주기 위해 많은 잠재적 사용 사례를 설계하고 유지 관리합니다. 이러한 사용 사례는 종종 고객이 Volterra를 처음 직접 체험하는 데 사용하는 교육 가이드로 만들어집니다.

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

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

변형 탄소 프로젝트(AC)

이를 위해 우리는 Altered-Carbon이라는 프로젝트를 만들었는데, 종종 AC로 줄여 부릅니다. AC 프로젝트는 20개 이상의 다양한 Volterra 솔루션 사용 사례를 만들 수 있는 동적 GitLab 파이프라인입니다. 파이프라인 자동화를 통해 단일 명령 "푸시 버튼 배포"를 만들어 사용자가 필요에 따라 또는 예약된 일일 크론 작업을 통해 여러 사용 사례 클러스터를 쉽게 배포할 수 있도록 했습니다.

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

프로젝트 개발

우리는 hello-cloud 사용 사례를 첫 번째 SLEEVE로 자동화하여 AC 프로젝트 개발을 시작했습니다. 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라는 3개의 SLEEVE 옵션을 선택했습니다. 각 SLEEVE는 사용자가 배포하고자 하는 사용 사례를 정의하고(따라서 트리거된 파이프라인에서 CI 작업을 제어함) 트리거된 파이프라인에서 생성된 리소스에 이름을 지정하기 위한 STACK_NAME을 정의합니다. 다음의 명령 구조는 두 가지 환경 변수를 모두 통합하여 오늘날에도 사용되는 가장 기본적인 AC 명령으로 사용되었습니다.

다음 이미지는 SLEEVE 환경 변수를 변경하면 AC 파이프라인의 각 실행에서 트리거되는 작업이 어떻게 변경되는지 시각화하여 보여줍니다.

SLEEVE "simple-aws" 파이프라인:

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

또한 파이프라인 트리거에서 환경 변수 DESTROY가 제공되는 경우 트리거되는 추가 작업도 도입했습니다. 이것은 AC에서 생성된 리소스를 제거하는 역방향 옵션을 제공합니다. 다음은 기존 STACK의 리소스를 제거하는 예입니다.

다른 환경 변수는 기본값으로 GitLab에 저장되었으며, 트리거 명령에 값을 추가하여 기본값을 재정의할 수 있습니다. 예를 들어, Volterra 테넌트 환경의 API URL은 VOLTERRA TENANT 환경 변수에 저장되었습니다. 사용자가 VOLTERRA TENANT 환경 변수를 API 명령에 추가하면 기본값이 재정의되고 배포가 원하는 위치로 리디렉션됩니다. 솔루션 팀이 수십 개의 Volterra 테넌트 환경을 관리하고 해당 작업에 따라 환경 간을 전환할 수 있는 기능이 필요하기 때문에 이는 내부 테스트 기능에 매우 중요한 것으로 입증되었습니다.

이러한 선택적 환경 변수는 필요할 때 배포에 대한 더 높은 수준의 제어를 추가하는 데 사용될 수 있지만, 추가적인 오버헤드를 관리하고 싶지 않은 사용자에게는 더 단순한 기본 배포 옵션을 허용합니다. 또한 이를 통해 스테이징 및 프로덕션 환경에서 배포를 쉽게 전환할 수 있었으며, 이는 가장 큰 AC 소비자에게 꼭 필요한 기능이었습니다.

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

앞서 언급했듯이 AC의 각 SLEEVE는 Volterra 사용 사례를 나타내며 이는 종종 고객이 제품과 처음 상호 작용하는 경우가 많습니다. 이러한 사용 사례가 기능적이고 버그가 없는지 확인하는 것은 제품에 대한 좋은 첫인상을 제공하는 데 중요했습니다. AC가 만들어지기 전에는 사용 사례를 테스트하여 Volterra 소프트웨어와 API의 최신 버전에서 제대로 작동하고 최신 상태인지 확인하는 작업이 많이 걸렸습니다. 각 사용 사례에 필요한 수동 부분으로 인해 회귀 테스트에 제한이 생겼고, 테스트가 충분히 자주 수행되지 않아 인적 오류가 발생하기 쉬웠습니다.

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

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

다음 이미지는 이 프로세스를 자세히 설명하고 AC에서 생성 및 파괴 명령에 대해 트리거하는 작업을 보여줍니다.

스모크 테스트 파이프라인이 실패했을 때, 우리는 문제를 재현하기 위해 AC 트리거에 사용할 수 있는 환경 변수를 제공할 수 있었습니다. 이는 기술적 문제 티켓에서 제공될 수 있으며, 이를 통해 개발자는 실패한 배포를 쉽게 다시 생성할 수 있습니다. 그런 다음 더 많은 SLEEVES가 완성됨에 따라 CI 파이프라인에 더 많은 작업을 추가하여 테스트 범위를 넓혔습니다. 테스트의 가시성을 더욱 개선하기 위해 Slack 통합을 추가하고 스모크 테스트 작업에서 각 파이프라인 실행의 성공 또는 실패 메시지를 Altered-Carbon 및 Smoke-Test 프로젝트의 해당 CI 웹 페이지에 대한 링크와 세부 정보와 함께 전송하도록 했습니다.

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

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

GitOps 워크플로를 통해 배포를 관리하는 GitLab 파이프라인은 정적으로 정의된 클러스터 집합에 대해 사용할 때 가장 적합한 것으로 보입니다. 이 경우, GitLab 파이프라인을 실행할 때마다 매번 동일한 클러스터와 리소스에 영향을 미칩니다. 이 경우 이러한 클러스터의 배포 내역은 GitLab 웹 UI에서 시각화된 파이프라인 내역입니다. 그러나 AC는 동적이며 끊임없이 변화하는 리소스 세트를 처리하는데, 각 파이프라인 실행은 완전히 다른 작업 세트를 활용하여 다른 가상화 공급자에서 다른 리소스 STACK을 관리할 수 있습니다. SLEEVE와 STACK 규칙으로 인해 발생한 이러한 차이는 어떤 파이프라인이 어떤 스택에 해당하는지 판단하기가 매우 어렵다는 것을 의미합니다. 예를 들어 AC에 대한 GitLab CI/CD 파이프라인 웹 UI를 살펴볼 수 있습니다.

이런 관점에서 보면 각 파이프라인을 개별적으로 살펴보지 않고는 어떤 파이프라인이 어떤 STACK이나 SLEEVE를 변경하는지 파악할 수 없습니다. 하루에 수백 개의 파이프라인을 실행한다면 특정 STACK을 생성하거나 파괴한 특정 파이프라인 실행을 찾거나 해당 STACK에 대한 특정 세부 정보를 찾는 것은 지루할 수 있습니다. 이 문제를 AC 개발 초기부터 해결하기 위해 우리는 간단한 기록 보관 시스템을 추가했습니다. 작업은 스택 레코드라는 파이프라인보다 먼저 실행됩니다. 이 작업은 스택 생성 시 해당 스택에 대한 세부 정보를 수집하고, tfstate 백업을 저장하는 데 사용되는 S3 스토리지 버킷에 업로드되는 JSON 파일을 생성합니다. 아래에서 스택 레코드의 예를 살펴보겠습니다.

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

• 어떤 Volterra 테넌트 환경이 사용되었습니까?
• 어떤 SLEEVE를 사용했나요?
• STACK이 현재 "적용" 상태에서 실행 중이거나 리소스가 "파기" 상태에서 제거된 경우입니다.
• 스택을 만든 GitLab 사용자입니다.
• STACK을 변경할 수 있는 권한이 있는 다른 사용자를 나열하는 작업 그룹입니다.
• 그리고 가장 중요한 것은 스택에 대해 실행되는 각 파이프라인 실행의 웹 URL, 파이프라인을 트리거한 사람, 파이프라인이 스택을 적용했는지 아니면 파괴했는지, 파이프라인이 트리거된 시기를 포함하는 파이프라인 배열입니다.

이를 통해 모든 스택과 연관된 모든 파이프라인 URL의 기록된 내역이 제공되었고, S3 API 호출을 통해 이러한 파일에 액세스할 수 있는 간단한 CLI 스크립트가 만들어져 프로세스가 더욱 간소화되었습니다. AC를 사용하는 사용자는 이러한 문서를 사용하여 스택의 내역을 추적하고 스택 레코드를 확인하여 스택이 변경된 시기를 확인할 수 있습니다.

스택 레코드를 통해 우리가 배포하는 파이프라인에 대한 특정 수준의 사용자 제어와 오류 포착을 구현할 수도 있었습니다. 예를 들어, AC를 만든 후 Volterra 소프트웨어에 가해진 변경 사항으로 인해 Volterra 사이트 생성에 사용되는 사이트 클러스터 이름(STACK NAME 값에서 파생된 값)을 17자로 제한해야 했습니다. 그래서 우리는 스택 이름이 문자 제한을 위반하는 경우 배포 단계를 실행하기 전에 파이프라인이 실패하도록 하는 검사를 스택 레코드 작업에 추가했습니다 . AC에서 사용자 권한 수준을 추가하여 AC가 제어하는 특정 스택을 변경할 수 있는 사용자를 제한하는 등 기타 사용자 지정 컨트롤이 추가되었습니다.

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

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

오늘날 AC는 대부분의 회귀 테스트와 자동화를 제공하는 솔루션 팀의 중심이 되었습니다. 주요 사용 사례로는 회귀 스모크 테스트, 확장 테스트, 제품 청구 테스트, 제품 데모에 사용되는 단순화된 배포 등이 있습니다.

자동 배포는 야간 회귀 테스트에서 가장 많은 소비자를 찾았습니다. 매일 밤 배포를 트리거한 다음 생성된 리소스를 해체하여 각 SLEEVES를 프로덕션 및 스테이징 환경에 대해 테스트합니다. 변경 사항이 발생하면 신속히 이를 감지하고 버그 보고서를 제출하여 가이드를 업데이트할 수 있습니다. 현재 테스트 범위에는 다음이 포함됩니다.

• 안전한 Kubernetes 게이트웨이.
• 웹 애플리케이션 보안.
• 표준 10개 포드 "hipster-co" 애플리케이션과 보다 가벼운 단일 포드 애플리케이션을 배포하는 네트워크 엣지 애플리케이션입니다.
• 안녕하세요-클라우드.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant에서 운영되는 CE 단일 노드 단일 네트워크 인터페이스 볼테라 사이트입니다.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant에서 운영되는 볼테라 사이트의 CE 단일 노드 이중 네트워크 인터페이스입니다.
• GCP, VSphere 및 KVM을 사용하여 CE 단일 노드 단일 네트워크 인터페이스 볼테라 사이트를 배포하고, Volterra 확장 기능을 테스트하기 위해 여러 개의 CE 단일 노드 단일 NIC 사이트를 생성했습니다.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant에서 운영되는 CE 단일 노드 다중 네트워크 인터페이스 볼테라 사이트입니다.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant에서 운영되는 볼테라 사이트의 CE 다중 노드 단일 네트워크 인터페이스입니다.
• AWS, GCP, Azure, VSphere 및 KVM/Vagrant에서 운영되는 CE 다중 노드 다중 네트워크 인터페이스 볼테라 사이트입니다.

또한 Volterra 소프트웨어의 확장 기능을 테스트하기 위해 최대 400개 사이트를 동시에 배포하는 프로세스를 자동화하는 전문적인 확장 테스트 슬리브도 있으며, GCP, vSphere 및 KVM을 사용하여 테스트되었습니다.

사용 사례의 신속한 자동 배포를 통해 솔루션 팀 구성원은 다른 작업에 집중할 수 있어 내부 효율성이 향상됩니다. 솔루션 팀은 종종 AC를 사용하여 수십 개의 KVM, GCP 및 vSphere 사이트를 배포하여 비디오 데모를 녹화하여 우리가 보다 복잡한 인프라를 구축하는 데 사용할 Volterra 사이트를 만드는 데 시간을 절약하고, 우리가 구축한 자동화를 기반으로 구축할 수 있습니다. 이는 Volterra 플랫폼의 청구 기능을 테스트하는 일일 크론 작업에도 사용되며, 청구 정보를 기록하는 전문 Volterra 테넌트에서 AWS 배포, 웹 앱 보안, 안전한 Kubernetes 게이트웨이 및 네트워크 엣지 애플리케이션 사용 사례를 자동화합니다.

미래 계획 및 로드맵

우리는 에어컨을 사용해 이미 매우 성공적인 결과를 얻고 있으며 가까운 미래에 이 프로젝트에 추가할 수 있는 기능과 개선 사항이 많이 있습니다.

이 프로젝트에서 가장 큰 추가 사항은 추가적인 사용 사례 배포를 처리하기 위해 새로운 SLEEVE 옵션이 지속적으로 추가된다는 것입니다. 새로운 SLEEVE가 추가될 때마다 솔루션 배포 프로젝트에 대한 적용 범위를 넓히기 위해 매일 밤 회귀 스모크 테스트에 새로운 작업을 추가합니다. 이전 슬리브는 대부분 단일 노드 및 단일 네트워크 인터페이스 사용 사례에 초점을 맞췄지만 최근에는 AWS, Azure, GCP, VMWare 및 KVM/Vagrant 플랫폼에서 다중 노드 Volterra 사이트 클러스터와 다중 네트워크 인터페이스 사용 사례로 SLEEVE 적용 범위를 확대했습니다.

또한 우리는 스택 기록 시스템을 개선하고자 노력하고 있습니다. 우리는 AC 기록의 세부 수준을 높이고, 기록을 위한 RDS 데이터베이스 저장소를 통합하여 향상된 검색 기능을 추가할 것입니다. 목표는 AC 환경에 대한 검색을 더 빠르게 제공하고 스택 상태, 스택 생성자 등에 따른 스택 조회와 같은 더 선택적인 검색 기능을 제공할 수 있게 하는 것입니다. 이러한 기록을 사용하여 AC를 사용하여 생성된 배포를 보다 효율적으로 시각화하는 사용자 지정 UI를 구성하는 것 또한 로드맵에 있습니다.