웹 개발 파이프라인 구축(5)

IaC와 테라폼

IaC(Infrastructure as Code)

구성관리 (Configuration Management)

• 구성(또는 형상; configuration)은 의존성 때문에 코드에 못지 않게 소프트웨어 시스템에 큰 영향을 미침
• 따라서 구성관리(또는 형상관리)는 잦은 빌드, 통합, 릴리스로 이루어지는 CI/CD에 중요한 측면
• 이를 체계적으로 관리하고 자동화 할 수 있는 여러 종류의 도구가 만들어지고 이용되어 왔음

IaC (Infastructure as Code)

• 인프라스트럭쳐 (소프트웨어가 의도된 목적을 활용하기 위하여 이용하는 환경 구성)을 생성, 변경, 관리
• 수작업에 의하는 것보다 안정성, 일관성, 재현 가능성을 향상시킬 수 있음
• 버전 관리, 재사용, 공유 등에 유리
• 프로그래밍에서와 유사하게 코드를 이용하여 인프라 리소스를 정의하고 조합하는 형태로 관리
  
  • 다양한 형태의 리소스를 정의하고 조합하는 모듈들로 이루어짐

테라폼 (Terraform)

Hashicorp사에서 제공하는 IaC도구

https://www.terraform.io/

Terraform by HashiCorp

Terraform 설치

Linux

• 패키지 매니저 (apt)를 이용하거나 실행 파일을 다운로드하여 설치

MacOS

• 패키지 매니저 (homebrew)를 이용하거나 실행 파일을 다운로드하여 설치

Windows

• 실행 파일을 다운로드하여 설치

요약

IaC (Infrastructure as Code)

• 일관성 있는 방법으로 재사용할 수 있는 코드를 통하여 인프라 구성에 대하여 버전 관리 및 공유가 가능해짐
• Terraform을 이용하여 인프라 구성 코드를 만들고 운용하는 방법을 실습
  • 인프라의 생성, 변경, 삭제 등의 작업을 선언적인 방법의 코드로 구성

Kubernetes + Terraform + Jenkins

인프라 상태의 정보 유지

Terraform은 IaC 설정 디레고리 안에 terraform.tfstate라는 파일을 만들어

이 구성이 관리하고 있는 인프라의 현재 상태를 유지하고 있음

• 인프라 구성의 선언에 변경이 발생하고 그것을 적용하면
  • 신규 생성, 삭제, 변경해야할 리소스를 인지할 수 잇는 것은 이것에 의존
• 그런데, CD 파이프라인에 적용하려면 이 상태 정보는 어디에 유지해야 할까?

Terraform Cloud

인프라 상태 정보 유지

• SCM (예: GitHub)에 저장하는 것은 바람직하지 않음
• Jenkins agent는 필요에 따라 생성되고 역할을 다하고 나면 사라지는 k8s 포드에 의해 실행되기 때문에 이 정보를 기록할 수 없음
• k8s persistent volume을 이용하는 방법도 적합하지 않음
• 보통은 이런것을 저장하기 위한 vault 서비스 이용

Terraform Cloud 서비스를 이용해 보자

• 준비: Terraform Cloud에 계정 (무료) 생성

https://app.terraform.io

https://app.terraform.io/session

Terraform Cloud 설정

Organization 신규생성

• User Settings > Organization 메뉴로 가서 찾을 수 있음

콘솔 로그인

• 명령어: terraform login
• 웹 화면으로 redirect 되고, 여기서 토큰 생성
• 이 토큰을 입력하여 로그인 완료
• 토큰은 비밀로 관리하고 잘 저장해 둘 것

간단한 CD 파이프라인

파이프라인 개발 전략

스테이징 환경(과 프로덕션 환경) 구성 설계

• 우리의 실습 환경에서는 몇 가지 제한점이 있음을 고려해야 함

로컬 환경에서 테스트

• Terraform CLI를 이용하여 설계된 기능의 동작을 기초적으로 확인

Jenkins 파이프 라인에 통합

• Build agent의 구성 업데이트
• Pipeline script 테스트
• Jenkinsfile로 작성하고 code repository 정리

소프트웨어 배포 환경 유형

개발 환경

🔸코드 개발에 적용

: 모든 개발자가 이용하는 공유 서버를 활용하거나 개발자마다 별도의 실행 환경을 활용

테스트 환경

🔸QA팀이 외부 시스템과의 상호작용을 포함한 통합 테스트에 적용

: 실제 서비스 운용 구성과 같이 않음

스테이징 환경

🔸실제 서비스하기 직전에 최종 테스트에 적용

: 서비스 운용 환경(프로덕션)을 가능한 한 그대로 복제

프로덕션 환경

🔸최종 사용자를 대상으로 서비스에 적용

: 비즈니스 요구사항에 따라 설계, 운용 및 진화

프로덕션 VS 스테이징

스테이징 환경은 프로덕션 환경을 가능한 한 그대로 모사하도록 설계되어야 함

• (가상화 됨) 인프라의 논리적 구성뿐만 아니라 컨퓨팅 리소스의 물리적/지리적 배치 등도 고려
• 생각해볼 만한 시나리오
• : 상용 클라우드 서비스에 동일한 구성을 갖는 서로 다른 k8s 클러스터를 이용

우리의 실습에서는 제약점들이 존재

• 하나의 k8s 클러스터 (docker desktop 환경)만 이용
• 테스트를 위해서 클러스터 외부로부터의 접근이 어려움 (또는 불가)

실습을 위해서 채택하는 방법

• 하나의 클러스터 내에서 네임스페이스만 별도로 구성해 보면서
• 프로덕션과 스테이징 환경이 분리된 상황에서는 어떻게 파이프라인을 구성할지를 사고 시뮬레이션

배포 환경 준비 및 테스트

Terraform 작업을 위한 별도 디렉토리 생성

• ${PROJECT_ROOT}/iac

이 안에 스테이징과 프로덕션 환경 구성 작성

• 달라지는 부분을 별개 파일로 만들고 배포할 때 적용

각 환경 구성을 유지할 TF Cloud 워크 스페이스 설정

• Organization: PRGMS_COURSE_CICD
• Staging workspace: calculator-dev
• Production workspace: calculator-prod
• ✨Execution Mode -> Local

파이프라인 테스트

새 Jenkins 아이템 (임시) 생성

• Pipeline script 적용
  • Checkout 단계에서 Jenkinsfile과 차이 있음을 주의

Build Now 적용해서 모든 단계 검토

결과 확인

• Console Output
• k8s 클러스터에 배포된 상태 - prod 네임스페이스 안의 deployment, pods, service
• curl 또는 브라우저에서 localhost:31000으로 접근 가능함 확인

CI / CD 파이프라인 완성

🔸Poll SCM 트리거 확인

🔸Pipeline script를 Jenkinsfile로 git commit && push

🔸빌드 및 테스트, 배포결과 확인

정리

웹 응용의 개발 이후에 벌어지는 일들 (과 이에 이용되는 도구들)

🔸Docker

- 응용을 컨테이너화 하여 독립적이고 통일된 환경에서 실행할 수 있도록 함

🔸Kubernetes

- 컨테이너화된 응용을 효과적이고 안정적으로 운용

🔸Terraform

- 응용이 실행될 인프라 리소스 구성과 의존 관계를 코드로 관리

🔸Jenkins

- 빌드, 테스트, 배포, 관리 등의 작업을 자동화하여 CI/CD 파이프라인 실행

비기능 테스트

시스템 운영에 심각한 위험을 초래할 수 있는 요소들을 테스트를 통하여 예방

• 매우 중요한 것이지만 자동화하여 파이프라인에 포함하기는 쉽지 않음

비기능 테스트의 종류

• 성능 테스트
  • 부하 테스트
  • 스트레스 테스트
  • 확장성 테스트
• 내구성 테스트
• 보안 테스트
• 유지보수 테스트
• 복구 테스트

데이터베이스 변경 관리

상태가 없는 웹 응용과는 달리 데이터베이스는 여러 복잡성을 초래

• 테스트 데이터 vs 프로덕션 데이터
• 데이터베이스의 규모와 시스템 성능
• 스키마 업데이트

마이그레이션 스크립트 등을 활용하여 안정성과 복구 가능성을 추구

릴리스 패턴 (Release Pattern)

프로덕션을 새로운 소프트웨어 버전으로 업데이트 할 때의 위험도를 낮추기 위한 전략

• 실제 서비스의 운영에서는 최종 릴리스에 수동 승인 절차를 갖추는 방식을 많이 채택

릴리스 패턴의 종류

• 롤링 업데이트 (rollig update)
• 블루-그린 배포 (blue-green deployment)
• 카나리아 릴리스 (canary release)

모니터링과 진단

모니터링 (Monitoring)

• 시스템 구성 인프라 내의 자원 상태와 활용도 등을 지속적으로 검사

진단 (Diagnosis)

• 잠재적 위험 요소를 조기 발견하고 대응책을 수립

알림 (Notification)

• 빌드의 성공/실패, 자원 활용의 변화 등에 대하여 (주로 데브옵스팀에) 자동 알림을 설정