지난 시간에는 인수 테스트와 도커 레지스트리를 다루었습니다. 이번 시간에는 IaC(Infrastructure as Code) 와 테라폼(Terraform) 을 활용해 CD 파이프라인까지 완성하는 과정을 정리했습니다.
1. IaC (Infrastructure as Code)
구성 관리 (Configuration Management)
소프트웨어 시스템에서 구성(Configuration) 은 의존성 때문에 코드에 못지않게 큰 영향을 미칩니다. 잦은 빌드, 통합, 릴리스로 이루어지는 CI/CD에서 구성 관리는 매우 중요한 요소입니다. 이를 체계적으로 관리하고 자동화하기 위해 다양한 도구들이 만들어지고 활용되고 있습니다.
IaC란?
IaC(Infrastructure as Code) 는 인프라를 코드로 정의하고 관리하는 방식입니다.
- 인프라를 생성, 변경, 관리합니다.
- 수작업보다 안정성, 일관성, 재현 가능성을 향상시킬 수 있습니다.
- 버전 관리, 재사용, 공유 등이 유리합니다.
프로그래밍에서와 유사하게 코드를 이용해 인프라 리소스를 정의하고 조합하는 형태로 관리한다는 것이 핵심입니다.
2. 테라폼 (Terraform)
테라폼 은 Hashicorp 사에서 제공하는 대표적인 IaC 도구입니다. 인프라 구성을 선언적인 방법의 코드로 작성하여 생성·변경·삭제 등의 작업을 수행합니다.
# 출력 포맷을 적용하는 outputs.tf 작성 후 적용
terraform apply --auto-approve테라폼은 IaC 설정 디렉토리 안에 terraform.tfstate 파일을 생성하여 현재 인프라 상태를 유지합니다. deployment.tf 를 수정하면 인프라 구성을 코드로 변경할 수 있습니다.
Kubernetes + Terraform + Jenkins
세 도구를 함께 활용하면 다음과 같은 역할을 수행합니다.
| 도구 | 역할 |
|---|---|
| Docker | 응용을 컨테이너화하여 독립적이고 통일된 환경에서 실행 |
| Kubernetes | 컨테이너화된 응용을 효과적이고 안정적으로 운용 |
| Terraform | 응용이 실행될 인프라 리소스 구성과 의존 관계를 코드로 관리 |
| Jenkins | 빌드·테스트·배포·관리 등의 작업을 자동화하여 CI/CD 파이프라인 실행 |
3. Terraform Cloud와 인프라 상태 정보 유지
terraform.tfstate 파일은 인프라의 현재 상태를 담고 있기 때문에 안전하게 보관해야 합니다. 그러나 다음과 같은 이유로 일반적인 저장 방식은 적합하지 않습니다.
- SCM에 저장하는 것은 바람직하지 않습니다. 민감한 정보가 포함될 수 있습니다.
- Jenkins Agent는 역할을 다하면 사라지는 k8s 포드로 실행되기 때문에 정보를 기록할 수 없습니다.
- k8s Persistent Volume을 이용하는 방법도 적합하지 않습니다.
이러한 상태 정보를 안전하게 보관하기 위해 Vault 서비스 를 활용합니다.
4. 소프트웨어 배포 환경 유형
소프트웨어는 목적에 따라 다음과 같이 네 가지 환경으로 나뉩니다.
| 환경 | 설명 |
|---|---|
| 개발 환경 | 코드 개발에 적용. 공유 서버 또는 개발자마다 별도의 실행 환경을 활용합니다 |
| 테스트 환경 | QA 팀이 외부 시스템과의 상호작용을 포함한 통합 테스트에 적용합니다 |
| 스테이징 환경 | 실제 서비스 직전 최종 테스트에 적용. 서비스 운용 환경을 가능한 그대로 복제합니다 |
| 프로덕션 환경 | 최종 사용자를 대상으로 서비스에 적용. 비즈니스 요구사항에 따라 설계·운용합니다 |
특히 스테이징 환경은 프로덕션 환경을 가능한 그대로 모사하도록 설계해야 합니다. 인프라의 논리적 구성뿐만 아니라 컴퓨팅 리소스의 물리적·지리적 배치까지 고려해야 합니다.
5. CD 파이프라인 완성
파이프라인 개발 전략
CD 파이프라인은 다음 순서로 개발합니다.
1. 스테이징 환경과 프로덕션 환경 구상 및 설계
2. 로컬 환경에서 테스트
3. Jenkins 파이프라인에 통합
- Build Agent 구성 업데이트
- Pipeline Script 테스트
- Jenkinsfile로 작성 후 코드 리포지토리 정리Pipeline Script 주요 수정 사항
pipeline {
agent any
stages {
stage('Package') { steps { /* 애플리케이션 빌드 */ } }
stage('Docker Build') { steps { /* 빌드 버전 태그 적용 이미지 빌드 */ } }
stage('Docker Push') { steps { /* 레지스트리에 이미지 푸시 */ } }
stage('Deploy to Staging') { steps { /* 스테이징 환경 배포 */ } }
stage('Acceptance Test') { steps { /* 인수 테스트 실행 */ } }
stage('Release') { steps { /* 프로덕션 배포 */ } }
stage('Smoke Test') { steps { /* 스모크 테스트 실행 */ } }
}
post {
always {
// 스테이징 환경 삭제 (terraform destroy)
}
}
}빌드 버전 관리는 Build Timestamp 플러그인을 활용합니다. 스테이징 환경은 테스트 완료 후 terraform destroy 로 자동 삭제하여 불필요한 리소스 낭비를 방지합니다.
6. 비기능 테스트
기능 테스트 외에도 시스템 운영에 심각한 위험을 초래할 수 있는 요소들을 검증하는 비기능 테스트가 필요합니다.
| 종류 | 세부 항목 |
|---|---|
| 성능 테스트 | 부하 테스트, 스트레스 테스트, 확장성 테스트 |
| 내구성 테스트 | 장시간 운영 시 안정성 검증 |
| 보안 테스트 | 취약점 및 침투 테스트 |
| 유지보수 테스트 | 운영 중 변경 용이성 검증 |
| 복구 테스트 | 장애 발생 시 복구 능력 검증 |
7. 데이터베이스 변경 관리
상태가 없는 웹 응용과 달리 데이터베이스는 여러 복잡성을 초래합니다.
- 테스트 데이터 vs 프로덕션 데이터 분리 문제
- 데이터베이스 규모와 시스템 성능 고려
- 스키마 업데이트 시 기존 데이터와의 호환성
이를 해결하기 위해 마이그레이션 스크립트 등을 활용하여 안정성과 복구 가능성을 추구합니다.
8. 릴리스 패턴
프로덕션을 새로운 소프트웨어 버전으로 업데이트할 때의 위험도를 낮추기 위한 전략입니다.
| 패턴 | 설명 |
|---|---|
| 롤링 업데이트 | 기존 인스턴스를 순차적으로 새 버전으로 교체합니다 |
| 블루-그린 배포 | 동일한 환경을 두 개 운영하여 트래픽을 전환하는 방식입니다 |
| 카나리아 릴리스 | 일부 사용자에게만 먼저 새 버전을 배포하여 위험을 최소화합니다 |
9. 모니터링과 진단
파이프라인이 완성된 이후에도 지속적인 운영 관리가 필요합니다.
- 모니터링 — 시스템 구성 인프라 내의 자원 상태와 활용도를 지속적으로 검사합니다.
- 진단 — 잠재적 위험 요소를 조기에 발견하고 대응책을 수립합니다.
- 알림 — 빌드 성공/실패, 자원 활용의 변화 등에 대해 자동 알림을 설정합니다.
