17-5 IaC 와 테라폼
IaC (Infrastructure as Code)
구성 관리 (Configuration Management)
- 구성 (또는 형상; configuration)은 의존성 때문에 코드에 못지 않게 소프트웨어 시스템에 큰 영향을 미침
- 따라서 구성 관리(또는 형상 관리)는 잦은 빌드, 통합, 릴리스로 이루어지는 CI/CD에 중요한 측면
- 이를 체계적으로 관리하고 자동화 할 수 있는 여러종류의 도구가 만들어지고 이용되어 왔음
IaC (Infrastructure as Code)
- 인프라스트럭쳐 (소프트웨어가 의도된 목적을 활용하기 위하여 이용하는 환경 구성) 를 생성, 변경, 관리
- 수작업에 의하는 것보다 안정성, 일관성, 재현 가능성을 향상시킬 수 있음
- 버전 관리, 재상용, 공유 등에 유리
프로그래밍에서와 유사하게 코드를 이용하여 인프라 리소스를 정의하고 조합하는 형태로 관리
- 다양한 형태의 리소스를 정의하고 조합하는 모듈들로 이루어짐
https://developer.hashicorp.com/terraform/tutorials/docker-get-started/infrastructure-as-code
Practitioner(사람)이 코드로 IaC 구성을 적어둔다음
우리가 목표로 하고있는 인프라스트럭쳐(이미지에서 맨 오른쪽에 해당) 만들거나 변경하거나 없애거나 하는 것들을 Plan하고 Apply합니다.
어떤 인프라스트럭쳐 종류를 관리하느냐에 따라서 Provider를 선택함.
GPT로 정리
Practitioner(사람)는 코드로 인프라(IaC)를 정의합니다.
이 코드는 우리가 원하는 최종 인프라 상태(Desired Infrastructure State)를 나타냅니다.
이를 기반으로 Terraform 같은 IaC 도구는 현재 상태와 코드 상태를 비교해:
어떤 리소스를 만들지(create)
어떤 리소스를 변경할지(update)
어떤 리소스를 삭제할지(delete)
를 판단하는 Plan 단계를 거칩니다.
그 후, 사용자가 Apply 명령을 내리면 실제 클라우드 상에서 인프라가 위 계획대로 적용됩니다.
Terraform에서 관리할 인프라의 종류(예: AWS, GCP, Azure, Kubernetes 등)에 따라 적절한 Provider를 선택하고 설정해야 합니다. Provider는 해당 플랫폼의 API와 연결되어 실제 리소스를 생성·수정·삭제할 수 있게 해줍니다.
테라폼 (Terraform)
클라우드 및 온프레미스 리소스의 구성, 변경, 버전 관리 등을 코드로 관리할수 있게하는 도구
- Hashicorp 사에서 제공하는 Iac 도구
- Hashicorp ko
설치 설치는 여기서
Linux: 패키지 매니저(apt) or 실행파일 다운 후 설치
MacOs: 패키지 매니저 (homebrew) OR 실팽 파일 다운 후 설치
Win: 실행 파일 다운 후 설치 // 시스템이 32비트의 옛날 컴퓨터면 386으로, 그 외에는 전부 AMD64 를 선택
설치 (win 기준으로)
- C 드라이브 경로를 사용하는 경우
- C 드라이브에 폴더 'terraform'을 생성합니다.
- 위 폴더에 다운받은 압축파일에서 나온 terraform.exe를 가져옵니다.
-
내 컴퓨터 속성 -> 고급 시스템 설정 -> 환경변수 path 편집 -> 새로 만들기 -> C:\terraform 등록
or -
"시스템 환경 변수 편집" 검색 -> 환경변수 -> 시스템 변수에서 변수'Path'클릭 후 편집 -> 새로 만들기 -> C:\terraform 등록
-
cmd에 terraform 입력해서 제대로 설치 되었는지 확인.
-
cmd에서 terraform version 입력해서 version만 확인도 가능.
(추가 작성중)
- .tf 파일 에러 해결중
CD 파이프라인 설계
지금까지 개발한 CI 파이프라인의 상태
- Code checkout -> build & test -> Packaging & Registry push 까지 완성
- Staging과 Acceptance test는 임시 상태 (목표하는 환경 구성 대신 docker 이용)
CD 파이프라인 완성을 위하여 남아 있는 일들 - 스테이징 환경과 프로덕션 환경 구성 <- Terraform IaC를 이용할 거임
- Acceptance test와 smoke test단계를 설정
- 추가로 고려하고자 하는 것들
- 빌드 버전 관리
파이프라인 개발 전략
스테이징 환경(과 프로덕션 환경) 구성 설계
- 현재 실습 환경에서는 몇 가지 제한점이 있음을 고려
로컬 환경에서 테스트
- Terraform CLI 를 이용하여 설계도니 기느으이 동작을 기초적으로 확인
Jenkins파이프라인에 통합
- Build agent의 구성 업데이트
- Pipeline script 테스트
- Jenkinsfile로 작성하고 code repository 정리
소프트웨어 배포 환경 유형
개발 환경
- 코드 개발에 적용 : 모든 개발자가 이용하는 공유 서버를 활용하거나 개발자마다 별도의 실행 환경을 활용
테스트 환경 - QA팀이 외부 시스템과의 상호작용을 포함한 통합 테스트에 적용 : 실제 서비스 운용 구성과 같지 않음
스테이징 환경 - 실제 서비스하기 직전에 최종 테스트에 적용: 서비스 운용환경 (프로덕션)을 가능한 한 그대로 복제
프로덕션 환경 - 최종 사용자를 대상으로서비스에 적용: 비지니스 요구사항에 따라 설계, 운용 및 진화
프로덕션 vs 스테이징
스테이징 환경은 프로덕션 환경을 가능한 한 그대로 모사하도록 설계되어야 함
- (가상화된)인프라의 논리적 구성뿐만 아니라 컴퓨팅 ㅣㄹ소스의 물리적/지리적 배치 등도 고려
- 생각해 볼만한 시나리오 : 상용 클라우드 서비스에 동일한 구성을 갖는 서로 다른 k8s 클러스터를 이용
우리의 실습에서는 제약점들이 존재
- 하나의 k8s 클러스터 (docker desktop환경)만 이용
- 테스트를 위해서 클러스터 외부로부터의 접근이 어려움(또는 불가)
실습을 위해서 채택하는 방법
- 하나의 클러스터 내에서 네임스페이스만 별도로 구성해보면서 프로덕션과 스테이징 환경이 분리된 상황에서는 어떻게 파이프라인을 구성할지를 사고 시뮬레이션
서로 다른 클러스터에의 (동일한 방식의) 접근
- 둘 이상의 클러스터에 대한 접근 방식을 각각 jenkins credentials로 설정하고 이를 스테이징과 프로덕션에 적용
배포 환경 준비 및 테스트
Terraform 작업을 위한 별도 디렉토리 생성
- ${PROJECT_ROOT}/iac
이 안에 스테이징과 프로덕션 환경 구성 작성 - 달라지는 부분을 별개 파일로 만들고 배포할 때 적용
각 환경 구성을 유지할 TF Cloud워크스페이스 설정 - Organizagion / Staging workspace / Producton workspace
- 잊지말고 Execution Mode -> Local 로 설정
