고객 플랫폼에서 지속적인 배포 구현

True Engineering에서는 고객 서버에 지속적으로 업데이트를 제공하기 위한 프로세스를 설정했으며 이 경험을 공유하고 싶습니다.

우선 우리는 고객을 위한 온라인 시스템을 개발하고 이를 자체 Kubernetes 클러스터에 배포했습니다. 이제 우리의 고부하 솔루션은 고객의 플랫폼으로 이동했으며, 이를 위해 완전 자동 지속적 배포 프로세스를 설정했습니다. 덕분에 우리는 제품 환경에 대한 변화를 전달하는 출시 기간을 단축했습니다.

이 문서에서는 CD(지속적 배포) 프로세스의 모든 단계 또는 고객 플랫폼에 대한 업데이트 제공에 대해 설명합니다.

1. 이 과정은 어떻게 시작되나요?
2. 고객의 Git 저장소와 동기화
3. 백엔드와 프론트엔드의 조립,
4. 테스트 환경에서 자동 애플리케이션 배포
5. Prod에 자동 배포

그 과정에서 설정 세부정보를 공유하겠습니다.

1. CD 시작

지속적인 배포는 개발자가 Git 리포지토리의 릴리스 분기에 변경 사항을 푸시하는 것으로 시작됩니다.

우리 애플리케이션은 마이크로서비스 아키텍처에서 실행되며 모든 구성 요소는 하나의 저장소에 저장됩니다. 덕분에 마이크로서비스 중 하나가 변경되더라도 모든 마이크로서비스가 수집되고 설치됩니다.

우리는 여러 가지 이유로 하나의 저장소를 통해 작업을 구성했습니다.

• 개발 용이성 - 애플리케이션이 활발히 개발 중이므로 모든 코드를 한 번에 작업할 수 있습니다.
• 단일 시스템으로서의 애플리케이션이 모든 테스트를 통과하고 고객의 프로덕션 환경에 제공되도록 보장하는 단일 CI/CD 파이프라인입니다.
• 버전의 혼란을 제거합니다. 마이크로서비스 버전 맵을 저장하고 Helm 스크립트에서 각 마이크로서비스에 대한 구성을 설명할 필요가 없습니다.

2. 고객 소스 코드의 Git 저장소와 동기화

변경 사항은 고객의 Git 저장소와 자동으로 동기화됩니다. 거기에서 분기를 업데이트한 후 시작되고 계속 배포되는 애플리케이션 어셈블리가 구성됩니다. 두 프로세스 모두 Git 저장소의 환경에서 시작됩니다.

개발 및 테스트를 위해서는 자체 환경이 필요하기 때문에 고객의 저장소와 직접 작업할 수 없습니다. 우리는 이러한 목적으로 Git 저장소를 사용합니다. 이는 Git 저장소와 동기화됩니다. 개발자가 저장소의 적절한 분기에 변경 사항을 게시하면 GitLab은 즉시 이러한 변경 사항을 고객에게 푸시합니다.

그런 다음 조립을 해야 합니다. 백엔드 및 프런트엔드 조립, 테스트 및 프로덕션 전달 등 여러 단계로 구성됩니다.

3. 백엔드와 프론트엔드 조립

백엔드와 프런트엔드 구축은 GitLab Runner 시스템에서 수행되는 두 가지 병렬 작업입니다. 원래 어셈블리 구성은 동일한 저장소에 있습니다.

GitLab에서 빌드하기 위한 YAML 스크립트 작성을 위한 튜토리얼.

GitLab Runner는 필요한 저장소에서 코드를 가져와서 Java 애플리케이션 빌드 명령으로 조합하여 Docker 레지스트리로 보냅니다. 여기에서는 백엔드와 프런트엔드를 조합하고 Docker 이미지를 얻어 고객 측 저장소에 저장합니다. 우리가 사용하는 Docker 이미지를 관리하기 위해 Gradle 플러그인.

이미지 버전을 Docker에 게시될 릴리스 버전과 동기화합니다. 원활한 작동을 위해 몇 가지 조정을 수행했습니다.

1. 테스트 환경과 프로덕션 환경 간에 컨테이너가 다시 빌드되지 않습니다. 동일한 컨테이너가 테스트 환경과 프로덕션 환경 모두에서 다시 빌드하지 않고도 모든 설정, 환경 변수 및 서비스와 작동할 수 있도록 매개변수화를 수행했습니다.

2. Helm을 통해 애플리케이션을 업데이트하려면 해당 버전을 지정해야 합니다. 우리는 백엔드, 프론트엔드를 구축하고 애플리케이션을 업데이트합니다. 이는 세 가지 다른 작업이므로 어디에서나 동일한 버전의 애플리케이션을 사용하는 것이 중요합니다. 이 작업에서는 K8S 클러스터 구성과 애플리케이션이 동일한 Git 저장소에 있으므로 Git 기록의 데이터를 사용합니다.

명령 실행 결과에서 애플리케이션 버전을 얻습니다.
git describe --tags --abbrev=7.

4. 테스트 환경(UAT)에 대한 모든 변경 사항 자동 배포

이 빌드 스크립트의 다음 단계는 K8S 클러스터를 자동으로 업데이트하는 것입니다. 이는 전체 애플리케이션이 빌드되고 모든 아티팩트가 Docker 레지스트리에 게시된 경우에 발생합니다. 이후 테스트 환경 업데이트가 시작됩니다.

클러스터 업데이트는 다음을 사용하여 시작됩니다. 투구 업데이트. 결과적으로 계획대로 진행되지 않은 경우 Helm은 모든 변경 사항을 자동으로 독립적으로 롤백합니다. 그의 작업은 통제될 필요가 없습니다.

우리는 어셈블리와 함께 K8S 클러스터 구성을 제공합니다. 따라서 다음 단계는 configMap, 배포, 서비스, 비밀 및 변경된 기타 K8S 구성을 업데이트하는 것입니다.

그런 다음 Helm은 테스트 환경에서 애플리케이션 자체의 RollOut 업데이트를 실행합니다. 애플리케이션이 프로덕션에 배포되기 전입니다. 이는 사용자가 테스트 환경에 포함된 비즈니스 기능을 수동으로 테스트할 수 있도록 하기 위한 것입니다.

5. Prod에 대한 모든 변경 사항 자동 배포

프로덕션 환경에 업데이트를 배포하려면 GitLab에서 버튼 하나만 클릭하면 됩니다. 그러면 컨테이너가 프로덕션 환경에 즉시 전달됩니다.

동일한 애플리케이션을 다시 구축하지 않고도 테스트 및 프로덕션 등 다양한 환경에서 작동할 수 있습니다. 애플리케이션에서 아무것도 변경하지 않고 동일한 아티팩트를 사용하고 매개변수를 외부에서 설정합니다.

애플리케이션 설정의 유연한 매개변수화는 애플리케이션이 실행될 환경에 따라 달라집니다. 모든 환경 설정을 외부로 이동했습니다. 모든 것은 K8S 구성 및 Helm 매개변수를 통해 매개변수화됩니다. Helm이 테스트 환경에 어셈블리를 배포하면 테스트 설정이 해당 어셈블리에 적용되고 제품 설정이 프로덕션 환경에 적용됩니다.

가장 어려웠던 점은 사용되는 모든 서비스와 환경에 의존하는 변수를 매개변수화하고 이를 Helm용 환경 변수 및 환경 매개변수의 설명-구성으로 변환하는 것이었습니다.

애플리케이션 설정은 환경 변수를 사용합니다. 해당 값은 Go 템플릿을 사용하여 템플릿화되는 K8S configmap을 사용하여 컨테이너에 설정됩니다. 예를 들어 환경 변수를 도메인 이름으로 설정하는 작업은 다음과 같이 수행할 수 있습니다.

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – 이 변수는 환경(prod, stage, UAT)의 이름을 저장합니다.
.Values.app.properties.app_external_domain – 이 변수에서는 .Values.yaml 파일에 원하는 도메인을 설정합니다.

애플리케이션을 업데이트할 때 Helm은 템플릿에서 configmap.yaml 파일을 생성하고 애플리케이션 업데이트가 시작되는 환경에 따라 APP_EXTERNAL_DOMAIN 값을 원하는 값으로 채웁니다. 이 변수는 이미 컨테이너에 설정되어 있습니다. 애플리케이션에서 액세스할 수 있으므로 각 애플리케이션 환경은 이 변수에 대해 서로 다른 값을 갖습니다.

비교적 최근에는 configMaps 작업을 포함하여 K8S 지원이 Spring Cloud에 나타났습니다. 스프링 클라우드 쿠버네티스. 프로젝트가 적극적으로 개발되고 급격하게 변화하는 동안 프로덕션에서는 사용할 수 없습니다. 그러나 우리는 상태를 적극적으로 모니터링하고 이를 DEV 구성에 사용합니다. 안정화되는 대로 환경 변수 사용에서 환경 변수 사용으로 전환하겠습니다.

전체로

따라서 지속적인 배포가 구성되어 작동합니다. 모든 업데이트는 한 번의 키 입력으로 발생합니다. 제품 환경에 대한 변경 사항은 자동으로 전달됩니다. 그리고 중요한 것은 업데이트가 시스템을 중지하지 않는다는 것입니다.

향후 계획: 자동 데이터베이스 마이그레이션

우리는 데이터베이스를 업그레이드하고 이러한 변경 사항을 롤백할 가능성을 고려했습니다. 결국 두 가지 서로 다른 버전의 애플리케이션이 동시에 실행되고 있습니다. 이전 버전은 실행 중이고 새 버전은 실행 중입니다. 그리고 새 버전이 작동한다고 확신하는 경우에만 이전 버전을 끌 것입니다. 데이터베이스 마이그레이션을 통해 두 버전의 애플리케이션 모두에서 작업할 수 있어야 합니다.

따라서 단순히 컬럼 이름이나 기타 데이터를 변경할 수는 없습니다. 그러나 새 열을 만들고 이전 열의 데이터를 해당 열에 복사한 다음, 데이터를 업데이트할 때 동시에 다른 열에 복사하고 업데이트하는 트리거를 작성할 수 있습니다. 그리고 새 버전의 애플리케이션이 성공적으로 배포된 후 출시 후 지원 기간이 지나면 불필요해진 이전 열과 트리거를 삭제할 수 있습니다.

새 버전의 애플리케이션이 제대로 작동하지 않으면 이전 버전의 데이터베이스를 포함하여 이전 버전으로 롤백할 수 있습니다. 간단히 말해서, 우리의 변경 사항을 통해 여러 버전의 애플리케이션을 동시에 작업할 수 있게 되었습니다.

K8S 작업을 통해 데이터베이스 마이그레이션을 자동화하고 이를 CD 프로세스에 통합할 계획입니다. 그리고 우리는 이 경험을 Habré에서 확실히 공유할 것입니다.

출처 : habr.com