[17주차 Day4] 모니터링 도구 활용 실습
📚 Part 6 CD 파이프라인 구축
📁 IaC와 테라폼
📌 laC (Infrastructure as Code)
- 구성 관리 (Configuration Management)
- 구성 (또는 형상; configuration)은 의존성 때문에 코드에 못지 않게 소프트웨어 시스템에 큰 영향을 미침
- 따라서 구성 관리 (또는 형상 관리)는 잦은 빌드, 통합, 릴리스로 이루어지는 CI/CD에 중요한 측면
- 이를 체계적으로 관리하고 자동화할 수 있는 여러 종류의 도구가 만들어지고 이용되어 왔음
- laC (Infrastructure as Code)
- 인프라스트럭쳐 (소프트웨어가 의도된 목적을 활용하기 위하여 이용하는 환경 구성)를 생성, 변경, 관리
- 수작업에 의하는 것보다 안정성, 일관성, 재현 가능성을 향상시킬 수 있음
- 버전 관리, 재사용, 공유 등에 유리
- 프로그래밍에서와 유사하게 코드를 이용하여 인프라 리소스를 정의하고 조합하는 형태로 관리
- 다양한 형태의 리소스를 정의하고 조합하는 모듈들로 이루어짐
- Hashicorp 사에서 제공하는 IaC 도구
- Scope -> Author -> Initialize -> Plan -> Apply
📌 첫 번째 구성 설정을 작성
- 적당하나 위치에 빈 디렉토리를 만들고, 이 안에 오른쪽과 내용을 main.tf파일로 작성
- 중요한 부분: "provider"
- Terraform registry (kreuzwerker/docker)에서 설정을 가져옴
- 버전은 3.0.1 이후로 지정
- Docker 이미지를 지정하고 (nginx:latest)
- 이것을 이용한 컨테이너를 인프라로 생성
- http에 해당하는 포트 (80)를 열어
- 이것을 8000 포트로 노출
📌 인프라 상태의 정보 유지
- Terraform 은 laC 설정 디렉토리 안에 terraform.tfstate 라는 파일을 만들어 이 구성이 관리하고 있는 인프라의 현재 상태를 유지하고 있음
- 인프라 구성의 선언에 변경이 발생하 (고 그것을 적용하) 명 신규 생성, 삭제, 변경해야 할 리소스를 인지할 수 있는 것은 이것에 의존
- 그런데, CD 파이프라인에 적용하려면 이 상태 정보는 어디에 유지해야 할까?
- 인프라 상태 정보 유지
- SCM (예: GitHub)에 저장하는 것은 바람직하지 않음 (왜?)
- Jenkins agent 는 필요에 따라 생성되고 역할을 다하고 나면 사라지는 k8s 포드에 의해 실행되기 때문에 이 정보를 기록할 수 없음
- K8s persistent volume 을 이용하는 방법도 적합하지 않음 (왜?)
- 보통은 이런 것을 저장하기 위한 vault 서비스 이용
- Terraform Cloud 서비스를 이용해 보자
- Organization 신규 생성
- User Settings > Organization 메뉴로 가서 찾을 수 있음
- 이 강의에서는 PRGMS_COURSE_CICD 라는 이름을 가정
- 콘솔 로그인
- 명령어: terraform login
- 웹 화면으로 redirect 되고, 여기서 토큰 생성
- 이 토큰을 입력하여 로그인 완료
- 토큰은 비밀로 관리하고 잘 저장해둘 것
📁 간단한 CD 파이프라인
📌 CD 파이프라인 설계
- 지금까지 개발한 CI 파이프라인의 상태
- Code checkout → Build & test → Packaging & Registry push 까지 완성
- Staging 과 Acceptance test 는 임시 상태 (목표하는 환경 구성 대신 docker 이용)
- CD 파이프라인 완성을 위하여 남아 있는 일들
- 스테이징 환경과 프로덕션 환경 구성 Terraform laC를 이용하기로 함
- Acceptance test 와 smoke test 단계를 설정
- 추가로 고려하고자 하는 것들
📌 파이프라인 개발 전략
- 스테이징 환경 (과 프로덕션 환경) 구성 설계
- 우리의 실습 환경에서는 몇 가지 제한점이 있음을 고려해야 함
- 로컬 환경에서 테스트
- Terraform CLI를 이용하여 설계된 기능의 동작을 기초적으로 확인
- Jenkins 파이프라인에 통합
- Build agent 의 구성 업데이트
- Pipeline script 테스트
- Jenkinsfile 로 작성하고 code repository 정리
📌 소프트웨어 배포 환경 유형
- 개발 환경
- 코드 개발에 적용: 모든 개발자가 이용하는 공유 서버를 활용하거나 개발자마다 별도의 실행 환경을 활용
- 테스트 환경
- QA 팀이 외부 시스템과의 상호작용을 포함한 통합 테스트에 적용: 실제 서비스 운용 구성과 같지 않음
- 스테이징 환경
- 실제 서비스하기 직전에 최종 테스트에 적용: 서비스 운용 환경 (프로덕션)을 가능한 한 그대로 복제
- 프로덕션 환경
- 최종 사용자를 대상으로 서비스에 적용: 비즈니스 요구사항에 따라 설계, 운용 및 진화
📌 프로덕션 vs 스테이징
- 스테이징 환경은 프로덕션 환경을 가능한 한 그대로 모사하도록 설계되어야 함
- (가상화된) 인프라의 논리적 구성뿐만 아니라 컴퓨팅 리소스의 물리적/지리적 배치 등도 고려
- 생각해 볼만한 시나리오: 상용 클라우드 서비스에 동일한 구성을 갖는 서로 다른 k8s 클러스터를 이용
- 우리의 실습에서는 제약점들이 존재
- 하나의 k8s 클러스터 (docker desktop 환경) 만 이용
- 테스트를 위해서 클러스터 외부로부터의 접근이 어려움 (또는 불가)
- 실습을 위해서 채택하는 방법
- 하나의 클러스터 내에서 네임스페이스만 별도로 구성해 보면서
- 프로덕션과 스테이징 환경이 분리된 상황에서는 어떻게 파이프라인을 구성할지를 사고 시뮬레이션
📚 Part 7 Outro
📁 과목 마무리
📌 강의 (및 실습) 흐름
- 웹 응용의 개발 이후에 벌어지는 일들 (과 이에 이용되는 도구들)
- Docker - 응용을 컨테이너화하여 독립적이고 통일된 환경에서 실행할 수 있도록 함
- Kubernetes - 컨테이너화된 응용을 효과적이고 안정적으로 운용
- Terraform - 응용용이 실행될 인프라 리소스 구성과 의존 관계를 코드로 관리
- Jenkins - 빌드, 테스트, 배포, 관리 등의 작업을 자동화하여 CI/CD 파이프라인 실행
📌 비기능 테스트
- 시스템 운영에 심각한 위험을 초래할 수 있는 요소들을 테스트를 통하여 예방
- 매우 중요한 것이지만 자동화하여 파이프라인에 포함하기는 쉽지 않음
- 비기능 테스트의 종류
- 성능 테스트
- 내구성 테스트
- 보안 테스트
- 유지보수 테스트
- 복구 테스트
📌 데이터베이스 변경 관리
- 상태가 없는 웹 응용과는 달리 데이터베이스는 여러 복잡성을 초래
- 테스트 데이터 vs 프로덕션 데이터
- 데이터베이스의 규모와 시스템 성능
- 스키마 업데이트
- 마이그레이션 스크립트 등을 활용하여 안정성과 복구 가능성을 추구
📌 릴리스 패턴 (Release Pattern)
- 프로덕션을 새로운 소프트웨어 버전으로 업데이트 할 때의 위험도를 낮추기 위한 전략
- 실제 서비스의 운영에서는 최종 릴리스에 수동 승인 절차를 갖추는 방식을 많이 채택
- 릴리스 패턴의 종류
- 롤링 업데이트 (rolling update)
- 블루 - 그린 배포 (blue-green deployment)
- 카나리아 릴리스 (canary release)
📌 모니터링과 진단
- 모니터링 (Monitoring)
- 시스템 구성 인프라 내의 자원 상태와 활용도 등을 지속적으로 검사
- 진단 (Diagnosis)
- 잠재적 위험 요소를 조기 발견하고 대응책을 수립
- 알림 (Notification)
- 빌드의 성공/실패, 자원 활용의 변화 등에 대하여 (주로 데브옵스팀에) 자동 알림을 설정
