- Infrastructure-as-Code (IaC)에 대해 공부하다가 테라폼에 알게 되었고 GCP kubernetes의 교육을 들으러 갔을 때 책을 쓰신 역자님을 만나 테라폼에 대해 궁금하게 되어 읽게 되었습니다.
- 이 책은 코드를 관리하는 모든 사람을 위한 것으로 시스템 관리자, 운영 엔지니어, 릴리스 엔지니어, 사이트 안전성 엔지니어, 데브옵스 엔지니어, 인프라 개발자, 풀스택 개발자, 엔지니어링 관리자 및 CTO가 포함됩니다. 이 책의 목표는 왜 테라폼을 사용하려 하는지, 워크플로에 어떻게 적용할 것인지, 그리고 어떤 모범 사례가 가장 잘 작동하는지에 대해 논의함으로써 테라폼을 제대로 운영할 수 있도록 하는 것입니다.
- 책을 읽으면서 코드형 인프라를 왜 사용하는지 알게 되었으며 테라폼에 대해 전반적인 내용에 대해 배웠습니다. 테라폼 코드 작성 방법부터 상태를 관리하는 방법, 모듈 만드는 방법, 프로덕션 수준의 테라폼 코드를 작성하고 테스트하는 방법, 배포 및 관리 예제를 실습 내용과 함께 배울 수 있어서 좋았습니다.
- 프로덕션 수준 인프라 체크 리스트
-
작업 설명 사용 가능한 도구 설치 소프트웨어 바이너리나 필요한 종속성을 설치 배시,셰프,앤서블,퍼핏 설정 포트 설정,TLS 인증서,서비스 디스커버리,리더,팔로워,복제 등의 소프트웨어 설정 배시,셰프,앤서블,퍼핏 프로비전 서버,로드 밸런서,네트워크,방화벽,IAM 권한 설정 등의 인프라 제공 테라폼, 클라우드포메이션 배포 인프라 상위의 서비스를 배포, 중단 시간 없이 업데이트 롤아웃 블루-그린,카나리 배포 등 테라폼,클라우드포메이션,쿠버네티스,ECS 고가용성 프로세서,서버,서비스,데이터 센터,리전 등의 장애에 대비 멀티데이터센터, 멀티리전, 복제, 오토스케일링, 로드 밸런싱 확장성 요청량에 따른 스케일 업/아웃,수평적 확장, 수직적 확장 오토스케일링,복제,샤딩,캐싱,분할 정복 성능 CPU,메모리,디스크,네트워크,GPU 용량 최적화,쿼리 튜닝,벤치마킹,테스트,프로파일링 다이나트레이스,밸그린드,비주얼VM,ab,제이미터 네트워킹 정적 혹은 동적 IP 설정, 포트, 서비스 디스커버리, 방화벽, DNS, SSH 접속, VPN 연결 VPC,방화벽,라우터,DNS regis-tars,OpenVPN 보안 TLS를 통한 통신 중 데이터 암호화, 디스크 암호화, 인증, 인가, 보안 관리, 서버 하드닝 ACM, Let's Encrypt,KMS,코그니토,볼트,CIS 성능 지표 가용성, 비즈니스,애플리케이션,서버,이벤트,추적,알림에 대한 메트릭 클라우드워치,DataDog,NewRelic,Honeycomb 로그 로그 순환, 중앙으로 로그 데이터 수집 클라우드 워치 Logs,ELk,Sumo 수모 로직, 페이퍼트레일 백업 및 복구 DB,캐시,기타 데이터를 일정에 따라 백업,리전별, 계정별 복제 RDS, ElastiCache, 복제 비용 최적화 적절한 인스턴스 유형 선택, 스팟 혹은 예약 인스턴스 사용, 오토스케일링, 사용하지 않는 리소스 정리 오토스케일링, 스팟 인스턴스, 예약 인스턴스 문서화 코드,아키텍처,모든 내용을 문서화, 장애 대응 내용 정리 README, wikis, 슬랙 테스트 인프라 코드를 테스트 자동화, 항상 테스트 후에 배포 테라테스트, 인스펙,서버스펙, 키친 테라폼
-
- 배포 워크플로 비교
-
애플리케이션 코드 인프라 코드 버전 관리 사용 git clone, 애프리케이션마다 리포지터리 하나, 브랜치 사용 git clone, 라이브와 모듈 리포지터리, 브랜치 미사용 코드를 로컬에서 실행 로컬호스트에서 실행, ruby web-server.rb, ruby web-server-test.rb 샌드박스 환경에서 실행, terraform apply, go test 코드 변경 코드 변경, ruby web-server.rb, ruby web-server-test.rb 코드 변경, terraform apply, go test, 테스트 단계 사용 코드 리뷰를 위해 변경 사항을 적용 풀 요청 적용, 코딩 가이드라인 수행 풀 요청 적용, 코딩 가이드라인 실행 자동화된 테스트 실행 CI 서버에서 테스트 수행, 단위 테스트, 통합 테스트, 종단 간 테스트, 정적 분석 CI 서버에서 테스트 수행, 단위 테스트, 통합 테스트, 종단 간 테스트, 정적 분석, terrafrom plan 병합과 릴리스 git tag, 버전이 지정된, 변경 불가능한 아티팩트 git tag, 태그와 함께 버전이 지정된,변경 불가능한 아티팩트를 저장하는 리포지터리 사용 배포 테라폼,쿠버네티스나 메소스 같은 오케스트레이션 도구, 스크립트를 이용한 배포,롤링 배포, 블루-그린,카나리 같은 다양한 배포 전략, CI 서버를 이용한 배포, CI 서버에서 제한된 권한 부여, 환경 전반에 걸쳐 불가능하고 버전이 지정된 승격 테라폼,아틀라스,테라폼 엔터프라이즈,테라그런트,스크립트를 이용한 배포,재시도,errored.tfstate가튼 제한적인 배포 전략, 에러 처리를 확실히 해야함, CI 서버를 이용한 배포, CI 서버에 관리자 권한 부여, 환경 전바에 걸쳐 변경 불가능하고 버전이 지정된 아티팩트 승격
-
- 테라폼은 해시코프사에서 만든 오픈 소스 도구. 테라폼은 간단한 선언적 언어를 사용하여 인프라를 코드로 정의함.(IaC) 몇 가지 명령을 사용하여 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드 플랫폼, 디지털오션 같은 다양한 퍼블릭 클라우드 공급자와 오픈스택, VM웨어 같은 프라이빗 클라우드와 가상화 플랫폼에서 해당 인프라를 배포 및 관리하게 함
- 데브옵스의 등장
- 수많은 운영팀들이 하드웨어에 많은 돈과 노력을 투자하는 대신 셰프(Chef), 퍼핏(Puppet), 테라폼(Terraform), 도커(Docker) 같은 도구를 사용하여 소프트웨어 작업에 더 많은 시간을 들이고 있음. 시스템 관리자가 서버를 설치하고 네트워크 케이블 설치 작업을 하는 대신에 코드를 작성하는 것
- 데브옵스는 소프트웨어를 효율적으로 전달하는 프로세스다.
- 지속적으로 코드를 통합하고 항상 배포 가능한 상태로 유지함
- 데브옵스의 4가지 핵심 가치는 문화, 자동화, 측정, 공유로 줄여서 CAMS라 함
- 코드형 인프라란?
- IaC란 코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것을 말함
- 데브옵스의 핵심은 서버, 데이터베이스, 네트워크, 로그 파일, 애플리케이션 구성, 문서, 자동화된 테스트, 배포 프로세스 등 거의 모든 것을 코드로 관리할 수 있다는 것
- 코드형 인프라 도구의 다섯 가지 범주
- 애드혹 스크립트
- 수행할 작업을 단계별로 나누고 배시, 루비, 파이썬 등 선호하는 언어를 사용하여 각 단계를 코드로 정의하고 작성된 스크립트를 서버에서 수동으로 실행하는 것
- 구성 관리 도구
- 셰프, 퍼핏, 앤서블, 솔트스택 등은 모두 구성 관리 도구로써 대상 서버에 소프트웨어를 설치하고 관리하도록 설계되어 있음. 애드혹 스크립트를 사용할 때와 다른 여러 가지 장점이 있음
- 코딩 규칙
- 앤서블은 문서화, 파일 레이아웃, 명확하게 이름 붙여진 매개 변수, 시크릿 관리 등을 포함하는 일관되고 예측 가능한 구조를 제공함
- 멱등성 : 실행 횟수에 관계없이 올바르게 동작하는 코드를 멱등성을 가진 코드
- 분산형 구조 : 애드혹 스크립트는 단일 로컬 머신에서만 실행되도록 설계됨. 앤서블과 같은 구성 관리 도구는 원격의 수많은 서버를 관리하기 위해 특별히 설계된 것
- 서버 템플릿 도구
- 구성 관리 도구의 대안으로 최근에 도커, 패커(Packer), 베이그런ㄷ트(Vagrant)와 같은 서버 템플릿 도구도 인기가 높아지고 있음.
- 여러 서버를 시작하고 각각 동일한 코드를 실행하여 서버를 구성하는 기존 방식과 다르게, 서버 템플릿 도구는 운영 체제, 소프트웨어, 파일 및 기타 필요한 모든 내용을 포함하고 있는 스냅숏으로 이미지를 생성함
- 가상 머신
- 호스트 시스템 및 다른 가상 머신 이미지와는 완전히 분리되어 개인 컴퓨터, QA 서버, 실제 운영 환경 등 모든 환경에서 정확히 동일한 방식으로 실행됨. 단점은 모든 하드웨어를 가상화하고 다른 VM과도 완전히 분리했기 때문에 VM마다 별도의 CPU, 메모리, 리소스가 할당되는 오버헤드가 발생하는 것
- 컨테이너
- 도커, 코어OS의 rkt 또는 크라이오와 같은 컨테이너 엔진을 실행하여 격리된 프로세스, 메모리, 마운트 지점, 네트워킹을 만듬. 호스트 시스템 및 다른 컨테이너와는 격리되어 개인 컴퓨터, QA 서버, 실제 운영 환경 등 모든 환경에서 정확히 동일하게 실행된다는 것이 장점.
- 단점은 단일 서버에서 실행되는 모든 컨테이너가 해당 서버의 OS 커널과 하드웨어를 공유하므로 VM을 사용하는 것만큼의 격리 및 보안 수준을 달성하기가 훨씬 어려울 수 있다는 것. 커널과 하드웨어가 공유되므로 밀리세컨드 단위로 부팅할 수 있으며, CPU 또는 메모리에 대한 오버헤드가 거의 없음
- 서버 템플릿 도구들의 목적은 약간씩 다름
- 패커는 일반적으로 프로덕션 AWS 계정에서 실행하는 AMI 처럼 프로덕션 서버에서 직접 실행하는 이미지를 생성하는 데 사용됨
- 베이그런트는 일반적으로 macOS나 Windows 랩톱에서 실행되는 버추얼박스 이미지와 같이 개발 컴퓨터에서 실행되는 이미지를 만드는 데 사용됨.
- 도커는 일반적으로 개별 응용 프로그램의 이미지를 만드는 데 사용됨
- 오케스트레이션 도구
- 실제 사용 환경에서 수행할 방법 필요함
- VM과 컨테이너를 하드웨어에 효율적으로 배포하기
- 롤링 배포, 블루-그린 배포, 카나리 배포 전략을 사용하여 기존의 VM이나 컨테이너를 효율적으로 업데이트하거나 롤백하기
- VM과 컨테이너의 상태를 모니터링하고 비정상적인 부분을 자동으로 대체하기(자동 복구)
- 발생하는 트래픽에 따라 VM과 컨테이너의 수를 늘리거나 줄이기(자동 확장)
- VM과 컨테이너의 트래픽을 분산하기(로드 밸런싱)
- 서로 다른 네트워크에 있더라도 VM과 컨테이너가 서로 식별하고 통신할 수 있게 하기(서비스 검색)
- 위 작업 들을 처리하기 위해 쿠버네티스, 마라톤/메소스, 아마존 엘라스틱 컨테이너 서비스, 도커 스웜, 그리고 노마드 같은 오케스트레이션 도구가 필요함
- 실제 사용 환경에서 수행할 방법 필요함
- 프로비전 도구
- 구성 관리, 서버 템플릿 및 오케스트레이션 도구가 각 서버에서 실행되는 코드를 정의한다면, 테라폼, 크라우드 포메이션, 오픈스택 하트와 같은 프로비전 도구는 서버 자체를 생성함
- 데이터베이스, 캐시, 로드 밸런서, 큐, 모니터링, 서브넷 구성, 방화벽 설정, 라우팅 규칙 설정, SSL(Secure Sockets Layer) 인증서 등 인프라에 관한 거의 모든 부분을 프로비저닝할 수 있음
- 애드혹 스크립트
- 코드형 인프라의 장점
- 자급식 배포(Self-service) : 인프라를 코드로 정의하면 전체 배포 프로세스를 자동화할 수 있으며 개발자는 필요할 때마다 자체적으로 배포를 진행할 수 있음
- 속도와 안정성(Speed and safety) : 자동화된 프로세스는 일관되고 반복 가능하며 수동으로 진행했을 때보다 오류가 적게 발생하기 때문에 더 안전함
- 문서화(Documentation) : 시스템 관리자 조직만 인프라에 관한 정보를 독점하는 것이 아니라 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있음
- 버전 관리 : 인프라의 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장할 수 있으므로 버전을 쉽게 관리할 수 있음
- 유효성 검증(Validation) : 인프라 상태가 코드로 정의되어 있으면 코드가 변경될 때마다 검증을 수행하고 일련의 자동화된 테스트를 실행할 수 있으며, 정적 분석(static analysis) 프로그램에 코드를 전달하여 오류 발생 위험을 줄일 수 있음
- 재사용성 : 인프라를 재사용 가능한 모듈로 패키징할 수 있으므로 모든 제품을 매번 처음부터 배포하는 대신 문서화되고 검증된 모듈로 일관되게 배포할 수 있음
- 테라폼의 작동 방식
- 해시 코프사가 GO 언어로 개발한 오픈 소스 도구. 운영 체제마다 바이너리 파일이 존재하는데 Go 코드는 하나의 바이너리 파일로 컴파일되며 terraform이라는 명령어로 실행할 수 있음
- 투명한 이식성은 예를 들어 AWS에서 생성한 서버, 데이터베이스, 로드 밸런서 등의 인프라를 애저나 구글 클라우드 같은 다른 클라우드 환경에서도 똑같이 생성할 수 있는가 하는 것
- 테라폼과 다른 코드형 인프라 도구 비교
- 절차적 언어 vs 선언적 언어
- 셰프와 앤서블은 원하는 최종 상태를 달성하는 방법을 단계별로 지정하는 절차적 스타일 코드를 권장함
- 테라폼, 클라우드포메이션, 솔트스택, 퍼핏, 오픈스택 히트는 모두 원하는 최종 상태를 지정하는 선언적 방식의 코드를 권장함
- 선언적 언어(declarative language)란 구현하려는 최종 상태를 지정하는 코드를 말하며 이때 코드형 인프라 자체는 그러한 최종 상태를 어떻게 구현할 것인지 계산하는 역할을 함
- 코드형 인프라 도구의 주요 문제
- 절차적 코드는 인프라의 마지막 상태 정보를 기록하고 있지 않음
- 절차적 코드 재사용 가능성ㅇ르 제한함
- 마스터 서버 유무
- 앤서블, 클라우드포메이션, 오픈스택 히트, 테라폼은 기본적으로 마스터가 없는 도구. 일부 서버는 마스터 서버에 의존할 수 있지만 이미 사용 중인 인프라의 일부이며 관리해야 할 추가적인 요소가 아님
- 에이전트 유무
- 앤서블, 클라우드포메이션, 오픈스택 히트, 테라폼은 추가적인 에이전트를 설치할 필요가 없음
- 커뮤니티 규모와 활성화
- 커뮤니티는 프로젝트에 참여하는 사람 수, 사용 가능한 플러그인 수, 통합 및 확장 프로그램 수, 블로그 게시물, 스택 오버플로우에 게시된 질문 같은 온라인 도움말을 찾는 방법 또는 직원이나 컨설턴트와 같이 여러분에게 도움을 줄 누군가를 쉽게 채용할 수 있는지 등에 영향을 줌
- 성숙한 기술 vs 최첨단 기술
- 테라폼은 이 표에 나온 코드형 인프라 도구들 중 가장 최근에 나온 것
- 여전히 1.0.0 이전의 버전이므로 안정적이지 않고 이전 버전과 호환되는 API를 보장하지 않으며, 대부분 사소한 것들이기는 해도 버그가 존재할 수 있음. 테라폼의 가장 큰 약점
- 절차적 언어 vs 선언적 언어
- 단일 웹 서버 배포
- 비지박스라는 도구로 포트 8080에서 웹 서버를 실행하여 해당 파일을 제공함. Busybox 명령을 nohub과 &로 래핑하여, 배시 스크립트가 종료되더라도 웹 서버가 백그라운드에 영구적으로 실행되도록 함
- <<-EOF 및 EOF는 테라폼의 히어닥(heredoc) 구문을 이용해 줄 바꿈 문자를 삽입하지 않고도 여러 줄로 된 코드를 작성할 수 있음
- CIDR 블록 0.0.0.0/0(어디에서든)에서 8080포트에 들어오는 TCP 요청을 승인하도록 지정함. CIDR 블록은 IP 주소 범위를 지정하는 간단한 방법. 10.0.0.0/24의 CIDR 블록은 10.0.0.0과 10.0.0.255 사이의 모든 IP 주소를 나타냄. CIDR 블록 0.0.0.0/0은 가능한 모든 IP 주소를 포함하는 IP 주소 범위이므로 이 보안 그룹은 모든 IP의 8080으로 들어오는 요청을 허용함
- 웹 서버 클러스터 배포
- 실제 운영 환경에서 서버가 하나뿐인 경우에는 이것이 단일 장애점이 될 수 있음. 하나뿐인 서버가 충돌하거나 트래픽 과부하가 발생하면 사용자는 사이트에 액세스 할 수 없게 됨
- 이를 해결하려면 단일 서버가 아니라 서버 클러스터를 구성해서 트래픽을 분산시키고, 트래픽 양에 따라 클러스터의 크기를 늘리거나 줄여야 함. 여러 대의 서버를 수동으로 관리하려면 손이 많이 감
- 오토스케일링 그룹(ASG)을 사용하여 해결할 수 있음. ASG는 EC2 인스턴스 클러스터 시작, 각 인스턴스 상태 모니터링, 실패한 인스턴스 교체, 로드에 따른 클러스터 사이즈 조정 등 많은 작업을 자동으로 처리함
- 로드밸런서 배포
- 각각 고유한 IP 주소를 가진 서버가 여러 개 있지만 사용자에게는 일반적으로 하나의 IP 주소를 제공해야 하기 때문. 이 문제를 해결하는 한 가지 방법은 로드밸런서를 배포하여 서버 전체에 트래픽을 분산시키고 모든 사용자에게 로드밸런서 IP(실제로는 DNS 이름)를 제공하는 것
- 가용성과 확장성이 뛰어난 로드 밸런서를 생성하는 데는 많은 작업이 필요함. 아마존 엘라스틱 로드 밸런서(ELB) 서비스를 사용하여 AWS가 이를 처리하도록 할 수 있음
-
terraform destory : 테라폼은 생성한 리소스를 추적하기 때문에 destroy 명령어를 실행해 간단히 정리할 수 있음 , destroy 명령어는 실행 취소(undo)를 할 수 없기 때문에 실제 운영 환경에서는 주의해서 실행해야 함
- 코드형 인프라의 장점은 리소스의 모든 정보가 코드로 캡처되므로 언제든지 terraform apply 명령어를 사용하여 모든 리소스를 다시 생성할 수 있다는 것. 인프라의 이력을 추적할 수 있도록 최신 변경 사항을 깃에 저장할 것을 권함
- 테라폼 상태란?
- 테라폼을 실행할 때마다 테라폼은 생성한 인프라에 대한 정보를 테라폼 상태 파일에 기록함
- 구성 파일(.tf)의 테라폼 리소스가 실제 리소스의 표현으로 매핑되는 내용을 기록하는 사용자 정의 JSON 형식이 포함되어 있음
- 다이나모DB : 아마존 분산형 키-값 저장소. 분산 잠금 시스템에 필요한 강력한 읽기 일관성 및 조건부 쓰기를 지원함
- 테라폼 백엔드의 단점
- 테라폼을 사용하여 테라폼 사앹를 저장할 S3 버킷을 만드는 것은 닭이 먼저인지 달걀이 먼저인지 묻는 것과 같음
- backend 블록에서는 변수나 참조를 사용할 수 없다는 점. S3 버킷 이름, 리전, 다이나모DB 테이블 이름 등을 모두 테라폼 모듈에 수동으로 복사해서 붙여넣어야 함
- 유일한 해결책은 부분 구성(partial configuration)의 장점을 이용하는 것. 테라폼 코드의 backend 구성에서 특정 매개 변수를 생략하고 대신 terraform init를 호출할 때 -backend-config 인수를 통해 매개 변수를 전달하는 것
- 테라폼은 몇 가지 단점을 보완해주는 오픈 소스 두구인 테라그런트(Terragrunt)를 사용하는 것. 테라그런트는 버킷, 이름, 리전, 다이나모DB 테이블 이름 같은 모든 기본 backend 구성을 반복하지 않도록 도와줌
- 테라폼 프로젝트의 파일 레이아웃
- stage : 테스트 환경과 같은 사전 프로덕션 워크로드 환경
- prod : 사용자용 맵 같은 프로덕션 워크로드 환경
- mgmt : 베스천 호스트, 젠킨스와 같은 데브옵스 도구 환경
- global : S3, IAM과 같이 모든 환경에서 사용되는 리소스를 배치할 수 있는 장소
- vpc : 해당 환경을 위한 네트워크 토폴로지
- services : 루비 온 레일즈 프런트엔드 또는 스칼라 백엔드와 같이 해당 환경에서 서비스되는 애플리케이션 또는 마이크로서비스, 각 맵은 자체 폴더에 위치하여 다른 모든 앱과 분리할 수 있음
- data-storage: MySQL 또는 레디스와 같은 해당 환경에서 실행할 데이터 저장소. 각 데이터 저장소는 자체 폴더에 상주하여 다른 모든 데이터 저장소와 분리할 수 있음
- variables.tf : 입력 변수
- outputs.tf : 출력 변수
- main.tf : 리소스
- terraform_remote_state 데이터 소스
- terraform_remote_state 데이터 소스를 사용하면 다른 테라폼 구성 세트에 완전한 읽기 전용 방식으로 저장된 테라폼 상태 파일을 가져올 수 있음
- 팀의 내부 테스트(스테이징)를 위한 환경이고 다른 하나는 실제 사용자가 액세스(프로덕션) 하기 위한 환경. 이론상 두 환경은 거의 동일하지만 비용을 절약하기 위해 스테이징 환경에서 좀 더 적은 서버 또는 더 작은 서버로 테스트할 수 있음
- 테라폼 코드를 적어도 2개 리포지터리에 분산하는 것
- 모듈 : 이 리포지터리는 재사용 가능한 모듈을 정의함. 각 모듈을 인프라의 특정 부분을 정의하는 청사진이라 생각
- 라이브(live) : 이 리포지터리는 스테이징, 프로덕션, 관리 등 각 환경에서 실행 중인 인프라를 정의함. 이것을 모듈 리포지터리의 청사진에서 구축한 집이라고 생각하기
- 모듈에서 코드형 인프라르 정의하면 이점
- 다양한 소프트웨어 엔지니어링 모범 사례를 인프라에 적용할 수 있음
- 코드 리뷰 및 자동화된 테스트를 통해 모듈의 각 변경 사항을 확인할 수 있음
- 각 모듈에 버전을 지정하여 배포할 수 있음.
- 다른 환경에서 다른 버전의 모듈을 안전하게 사용해보고 문제가 발생하면 이전 버전으로 롤백할 수 있음
- 반복문
- count 매개 변수 : 리소스를 반복
- for_each 표현식 : 리소스 내에서 및 인라인 블록을 반복
- for 표현식 : 리스트와 맵을 반복
- for 문자열 지시어 : 문자열 내에서 리스트와 맵을 반복
- for_each 표현식을 사용한 반복문 처리
- for_each 표현식을 사용하면 리스트, 집합, 맵을 사용하여 전체 리소스의 여러 복사본 또는 리소스 내 인라인 블록의 여러 복사본을 생성할 수 있음
- 프로덕션 수준의 인프라 구축은 어려움. 시간도 많이 걸리고 스트레스도 심한 일. 프로덕션 수준의 인프라란 서버, 데이터 저장소, 로드 밸런서, 보안 기능, 모니터링 및 경고 도구, 파이프라인 구축 및 비즈니스 운영에 필요한 기타 모든 기술을 의미함
- 프로덕션 수준의 인프라를 만드는 프로젝트에 소요되는 시간
- AWS 관계형 데이터베이스 서비스(RDS)를 사용하여 MySQL을 실행하는 등 제3자에 의해 완전 관리되는 서비스를 배포하려는 경우 해당 서비스를 프로덕션 환경에 준비하는 데 1~2주가 소요됨
- 모든 데이터를 RDS에 저장하는 것 같이 데이터를 로컬에 저장하지 않는 Node.js 앱 클러스터, 즉 상태 비저장 분산 앱을 AWS 오토스케일링 그룹에서 실행하려는 경우 프로덕션 환경 준비에 약 2~4주가 소요됨
- ASG 환경에서 실행되고 로컬 디스크에 데이터를 저장하는 아마존 엘라스틱서치 클러스터와 같은 자체 상태 저장 분산 앱을 실행하려는 경우 프로덕션 환경 준비에 약 2~4개월이 소요됨
- 모든 애플리케이션, 데이터 저장소, 로드 밸런서, 모니터링, 경고, 보안 등을 포함한 전체 아키텍처를 구축하려는 경우, 규모가 크게 증가해 약 6~36개월까지 소요됨. 소규모 회사는 일반적으로 6개월 정도, 대기업 경우 몇 년까지도 걸릴 수 있음
-
인프라 유형 예 예상 소요 시간 관리형 서비스 아마존 RDS 1~2주 스스로 관리하는 분산 시스템(상태 비저장) Node.js앱이 실행되는 클러스터 2~4주 스스로 관리하는 분산 시스템(상태 저장) 아마존 엘라스틱서치 2~4개월 전체 아키텍처 애플리케이션,데이터,로드 밸런서,모니터링 등 6~36개월
- 프로덕션 수준 인프라 구축에 오랜 시간이 걸리는 이유
- 데브옵스 작업에 오랜 시간이 걸리는 데는 3가지 주요 이유
- 데브옵스 산업이 여전히 석기 시대에 있기 때문. 아직 산업 초기 단계라는 의미
- 데브옵스가 특히 야크 털 깎기에 취약하기 때문. (원래 하고 싶었던 작업을 수행하기 전 해야 하는 하찮고, 겉으로 볼때는 관련이 없는 작업들을 말함)
- 본질적 복잡성은 인프라를 준비하기 위해 수행해야 하는 작업의 체크리스트가 너무 길기 때문
- 데브옵스 작업에 오랜 시간이 걸리는 데는 3가지 주요 이유
- 프로덕션 수준 인프라 체크 리스트
- 인프라를 프로덕션 환경에 배포하기 위해 고려해야 할 대부분의 주요 항목이 포함되어 있음
-
작업 설명 사용 가능한 도구 설치 소프트웨어 바이너리나 필요한 종속성을 설치 배시,셰프,앤서블,퍼핏 설정 포트 설정,TLS 인증서,서비스 디스커버리,리더,팔로워,복제 등의 소프트웨어 설정 배시,셰프,앤서블,퍼핏 프로비전 서버,로드 밸런서,네트워크,방화벽,IAM 권한 설정 등의 인프라 제공 테라폼, 클라우드포메이션 배포 인프라 상위의 서비스를 배포, 중단 시간 없이 업데이트 롤아웃 블루-그린,카나리 배포 등 테라폼,클라우드포메이션,쿠버네티스,ECS 고가용성 프로세서,서버,서비스,데이터 센터,리전 등의 장애에 대비 멀티데이터센터, 멀티리전, 복제, 오토스케일링, 로드 밸런싱 확장성 요청량에 따른 스케일 업/아웃,수평적 확장, 수직적 확장 오토스케일링,복제,샤딩,캐싱,분할 정복 성능 CPU,메모리,디스크,네트워크,GPU 용량 최적화,쿼리 튜닝,벤치마킹,테스트,프로파일링 다이나트레이스,밸그린드,비주얼VM,ab,제이미터 네트워킹 정적 혹은 동적 IP 설정, 포트, 서비스 디스커버리, 방화벽, DNS, SSH 접속, VPN 연결 VPC,방화벽,라우터,DNS regis-tars,OpenVPN 보안 TLS를 통한 통신 중 데이터 암호화, 디스크 암호화, 인증, 인가, 보안 관리, 서버 하드닝 ACM, Let's Encrypt,KMS,코그니토,볼트,CIS 성능 지표 가용성, 비즈니스,애플리케이션,서버,이벤트,추적,알림에 대한 메트릭 클라우드워치,DataDog,NewRelic,Honeycomb 로그 로그 순환, 중앙으로 로그 데이터 수집 클라우드 워치 Logs,ELk,Sumo 수모 로직, 페이퍼트레일 백업 및 복구 DB,캐시,기타 데이터를 일정에 따라 백업,리전별, 계정별 복제 RDS, ElastiCache, 복제 비용 최적화 적절한 인스턴스 유형 선택, 스팟 혹은 예약 인스턴스 사용, 오토스케일링, 사용하지 않는 리소스 정리 오토스케일링, 스팟 인스턴스, 예약 인스턴스 문서화 코드,아키텍처,모든 내용을 문서화, 장애 대응 내용 정리 README, wikis, 슬랙 테스트 인프라 코드를 테스트 자동화, 항상 테스트 후에 배포 테라테스트, 인스펙,서버스펙, 키친 테라폼
- 프로덕션 수준 인프라 모듈
- 대형 모듈의 단점
- 속도가 느림, 안전하지 않음, 위험성이 높음, 이해하기 어려움, 리뷰하기 어려움, 테스트하기 어려움
- 작업을 구현하기 위해 재사용 가능한 모듈을 구축하는 모범 사례
- 소형 모듈
- 합성 가능한 모듈
- 테스트 가능한 모듈
- 수동 테스트 장치
- 수동으로 terraform apply 및 terraform destroy를 실행하여 반복적으로 배포하거나 배포를 취소함으로써 코드가 예상대로 작동하는지 확인할 수 있음
- 자동화된 테스트 장치 : 테스트는 test 폴더로 이동하는 것이 좋음
- 실행 가능한 문서
- README.md를 포함한 이 예제를 버전 관리에 적용하면 팀의 다른 구성원이 이를 찾아서 모듈 작동 방식을 이해하고 코드를 작성하지 않고도 모듈을 교체할 수 있음.
- 나머지 팀원들을 가르칠 수 있는 방법이며 또한 자동화된 테스트를 추가하면 예제가 항상 예상대로 작동하는지 확인할 수 있음
- 모든 공급자 버전도 고정하는 것을 권장함. 주요 버전 번호를 고정하면 실수로 버전을 변경해 이전 버전과 호환되지 않은 문제가 발생하지 않음
- 수동 테스트 장치
- 릴리스 가능한 모듈
- 모듈을 작성하고 테스트한 후 다음 단계는 모듈을 릴리스하느 것. 시맨틱 버전 관리와 함께 깃 태그를 사용할 수 있음
- 테라폼 모듈 외의 것들
- 프로비저너
- 테라폼 프로비저너(provisioner)는 테라폼을 실행할 때 부트스트랩, 구성 관리 또는 정리 작업을 수행하기 위해 로컬 시스템이나 원격 시스템에서 스크립트를 실행하는데 사용됨
- 프로비저너에는 로컬 시스템에서 스크립트를 실행하는 local-exec, 원격 리소스에서 스크립트를 실행하는 remote-exec, 원격 리소스에서 셰프 클라이언트를 실행하는 chef 및 원격 리소스로 파일을 복사하는 file등이 있음
- 프로비저너
- 코드 스멜(code smell): 더 큰 문제를 일으킬 수 있는 코드의 특징을 의미함
- 대형 모듈의 단점
- 수동 테스트
- 기본 수동 테스트
- 테라폼 코드를 테스트할 때 로컬 호스트가 없음. 이는 테라폼 뿐만 아니라 대부분의 코드형 인프라 도구에 적용됨
- 테라폼으로 수동 테스트를 수행할 수 있는 유일한 방법은 AWS 같은 실제 환경에 배포하는 것. 다시 말해 terraform apply 및 terrafrom destroy를 수동으로 실행하는 것이 테라폼으로 수동 테스트를 수행하는 방법
- 테라폼으로 작업할 때 모든 개발자에게는 테스트를 위한 좋은 예제 콛그ㅏ 필요함. 테스트를 실행하기 위해 로컬 호스트와 동듷아게 사용할 수 있는, AWS 계정 같은 실제 배포 환경이 필요함. 수동 테스트 과정에서 많은 인프라를 구축 및 해제하고 많은 실수를 겪을 가능성이 있으므로 이 환경은 스테이징, 프로덕션과 같은 다른 안정된 환경과 완전히 격리되어야 함
- 모든 팀이 격리된 샌드박스 환경을 설정할 것을 권함.이 경우 개발자는 다른 샌드박스 환경에 영향을 줄 염려 없이 원하는 인프라를 구축하고 해체할 수 있음. 두 명의 개발자가 동일한 이름으로 로드 밸런서 생성을 시도하는 경우와 같이 여러 개발자 간 충돌 가능성을 줄이려면 각 개발자가 완전히 고립된 샌드박스 환경을 설정하는 것이 훌륭한 방법
- 테스트 후 정리
- cloud-nuke
- 클라우드 환경의 모든 리소스를 삭제할 수 있는 오픈 소스 도구
- 주요 기능은 특정 기간보다 오래된 모든 리소스를 삭제하는 것
-
cloud-nuke aws --older-than 48h
- Janitor Monkey
- 구성하는 일정에 따라 AWS 리소스를 정리하는 오픈 소스 도구이며 기본값은 주 1회. 리소스 정리 여부 및 삭제하기 며칠 전에 리소스 소유자에게 알림을 보내는 기능을 결정하는 구성 규칙도 지원함
- 제니터 몽키는 넷플릭스 시미안 아미 프로젝트의 일부이며 응용 프로그램 복원력을 테스트하기 위한 도구인 카오스 몽키도 포함함
- aws-nuke
- AWS 계정에서 모든 것을 삭제하는 데 사용하는 오픈 소스 도구. YAML 구성 파일을 사용하여 삭제할 계정 및 리소스를 aws-nuke로 지정함
- cloud-nuke
- 기본 수동 테스트
- 자동화된 테스트
- 단위 테스트
- 하나의 작은 코드 단위의 기능을 검증함. 단위의 정의는 다양하지만 범용 프로그래밍 언어에서는 보통 단일 함수 또는 클래스임
- 일반적으로 데이터베이스, 웹 서비스, 심지어 파일 시스템 같은 외부 종속성(데이터베이스 목에서 하드 코딩된 응답을 반환하는 등)은 코드가 다양한 시나리오를 처리하는지 테스트하기 위해 그러한 종속성의 동작을 세밀하게 제어할 수 있는 테스트 더블 또는 테스트 더블 중 목으로 대체됨
- 통합 테스트
- 여러 단위가 함께 올바르게 작동하는지 확인함.
- 범용 프로그래밍 언어에서 통합 테스트는 여러 함수 또는 클래스가 함께 올바르게 작동하는지 확인하는 코드로 구성됨
- 통합 테스트는 일반적으로 실제 종속성과 목을 조합하여 사용함
- 종단 간 테스트
- 앱, 데이터 저장소, 로드 밸런서 같은 전체 아키텍처를 실행하고 시스템이 전체적으로 작동하는지 확인하는 과정을 포함함
- 일반적으로 이러한 테스트는 웹 브라우저를 통해 제품과의 상호 작용을 자동화하기 위해 셀레니움을 사용하는것과 같이 최종 사용자의 관점에서 수행됨
- 종단 간 테스트는 일반적으로 프로덕션을 반영하는 아키텍처에서 목 없이 실제 시스템을 사용함. 이 때 프로덕션 비용 절감을 위해 적은 소규모 서버만 사용하는 경우가 많음
- 단위 테스트의 목적은 변경 사항에 대한 빠른 피드백을 얻고 다양한 순열ㅇ을 검증하여 코드의 기본 빌딩 블록(개별 단위)이 예상대로 작동하는지 확신할 수 있도록 빠른 테스트를 수행하는 것
- 모든 테스트는 테라테스트(Terratest)라는 오픈 소스 Go 라이브러리를 활용하기 위해 Go 언어로 작성함. 이 라이브러리는 AWS, 구글 클라우드, 쿠버네티스 같은 다양한 환경에 걸쳐 테라폼, 패커, 도커, 헬름 같은 코드형 인프라 도구 테스트를 지원함
- 테라테스트에는 인프라 코드를 훨씬 쉽게 테스트할 수 있는 수백 개의 도구가 내장되어 있음. 테스트 전략을 지원하기 위해 terraform apply, 동작에 대한 검증, 그리고 terraform destroy를 실행하는 부분에 적용할 수 있는 기능을 제공함
- 단위 테스트
- 종단 간 테스트
- 루비 웹 서버 예제에서 종단 간 테스트 앱 서버 배포, 종속된 모든 데이터 저장소, 셀레니움과 같은 도구를 사용하여 최종 사용자 관점인 웹 브라우저에서 테스트하는 과정으로 구성됨. 프로덕션을 모방하는 환경에 모든 것을 배포하고 최종 사용자의 관점에서 테스트함
- 다른 테스트 접근 방식
- 테스트 도구 벨트의 일부로 포함할 수 있는 다른 두 가지 범주의 테스트 접근 방식
- 정적 분석
- 테라폼 코드를 실행하지 않고도 분석할 수 있는 몇가지 도구가 있음
- terraform validate - 테라폼에 내장된 명령으로 테라폼 구문 및 유형을 확인하는데 사용할 수 있음
- tflint - 테라폼의 린트 도구로 테라폼 코드를 스캔하고 내장 규칙 집합을 기반으로 일반적인 오류와 잠재적 버그를 포착할 수 있음
- 해시코프 센티널 - 다양한 해시코프 도구에 규칙을 적용할 수 있는 코드형 정책 프레임워크
- 속성 테스트
- kitchen-terraform, rspec-terraform, serverspec, inspec, goss
- 이러한 도구의 대부분은 배포한 인프라가 어떤 사양을 준수하는지 확인하기 위해 간단한 도메인 특화 언어(Domain-Specific Language, DSL)를 제공함
- 이러한 테스트 도구의 장점은 도메인 특화 언어를 통해 간결하고 사용하기 쉬우며 인프라의 많은 속성을 검증할 수 있는 효율적이고 선언적인 방법을 제공한다는 것
- PCI 컴플라이언스, HIPAA 컴플라이언스와 같은 규정 준수와 관련된 요구 사항의 체크리스트를 시행하는 데 유용함. 단점은 속성 확인이 통과되어도 인프라가 작동하지 않을 수 있다는 것
- 정적 분석
- 테스트 도구 벨트의 일부로 포함할 수 있는 다른 두 가지 범주의 테스트 접근 방식
- 애플리케이션 코드 배포를 위한 워크플로
- 개발에서 프로덕션까지 테라폼 모듈 같은 인프라 코드를 가져오는 워크 플로
- 버전 관리 사용
- 모든 코드는 버전 관리 상태에 있어야 함
- 버전 관리 대상에는 마크다운으로 작성된 README 같은 문서, YAML로 작성된 구성 파일 같은 애플리케이션 구성, R스펙(RSpect)으로 작성된 테스트 코드 같은 사양, 제이유닛(JUnit)으로 작성된 자동화된 테스트 같은 테스트, 액티브 레코드(Active Record)로 작성된 스키마 마이그레이션 같은 데이터베이스 그리고 인프라가 포함됨
- 코드를 로컬에서 실행
- 중요한 점은 애플리케이션 코드에 대한 수동 및 자동화된 테스트를 모두 사용자 컴퓨터에서 완전히 로컬로 실행할 수 있다는 것
- 코드 변경
- 변경을 수행하고 수동 또는 자동화된 테스트를 재실행하여 변경 사항이 작동하는지 확인하고 다른 변경을 수행하고 테스트를 재실행하는 등의 반복적인 프로세스
- 코드 리뷰를 위해 변경 사항 반영
- 파브리케이터(Phabricator) 또는 리뷰보드(ReviewBoard) 같은 별도의 코드 리뷰를 도구를 사용하거나 깃허브를 사용하는 경우 풀 요청(pull request)을 생성할 수 있음
- 자동화된 테스트 실행
- 버전 관리 시스템에 푸시하는 모든 커밋에 대해 자동화된 테스트를 실행하도록 커밋 후크를 설정해야 함
- 젠킨스, 서클CI 또는 트래비스 CI와 같은 CI 서버를 사용하는 것
- 서클 CI가 브랜치의 코드에 단위 테스트,통합 테스트, 종단 간 테스트 그리고 synk라는 도구를 사용한 보안 취약성 검사 형태로 일부 정적 분석 검사를 실행했고 모든 것이 통과되었음을 알림
- 병합과 릴리스
- 팀 구성원은 코드 변경 사항을 리뷰하고 잠재적인 버그를 찾고 코딩 지침을 적용하고 기존 테스트가 통과했는지 확인하고 추가한 새로운 동작에 대한 테스트를 추가했는지 확인해야 함
- 모든 것이 잘되었다면 코드를 master 브랜치에 병합할 수 있음
- 애플리케이션을 패키징하는 배포하는 방법에 따라 아티팩트는 새로운 도커 이미지, AIM 같은 새로운 가상 머신 이미지, 새로운 .jar 파일, 새로운 .tar 파일 등이 될 수 있음. 어떤 형식을 선택하든 아티팩트가 변경 불가능하고 고유한 버전 번호를 가지고 있는지, 즉 이 아티팩트를 다른 모든 아티팩트와 구별할 수 있는지 확인함
- 배포
- 애플리케이션 코드는 애플리케이션의 유형, 패키징하는 방법, 실행 방법, 아키텍처, 사용 중인 도구 등에 따라 여러 가지 방법으로 배포할 수 있음. 배포 시에 고려해야 할 몇 가지 사항
- 배포 도구
- 애플리케이션을 패키지하는 방법과 실행 방법에 따라 애플리케이션을 배포하는 데 사용할 수 있는 다양한 도구
- 테라폼 : 테라폼을 사용하여 특정 유형의 애플리케이션을 배포할 수 있음
- 도커 오케스트레이션 도구
- 가장 인기 있는 애플리케이션인 쿠버네티스, 아파치 메소스, 해시코프, 노마드 및 아마존 ECS를 포함하여 도커화된 애플리케이션을 배포하고 관리하기 위해 설계된 여러 오케스트레이션 도구가 있음
- 애플리케이션을 도커 이미지로 패키징하는 경우 쿠버네티스에서 kubectl apply를 실행하고 배포할 도커 이미지 이름과 태그를 정의하는 YAML 파일로 전달하여 도커 이미지 버전을 배포할 수 있음
- 스크립트
- 테라폼 및 대부분의 오케스트레이션 도구는 제한된 배포 전략만 지원함
- 더 복잡한 요구 사항이 있는 경우 파이썬이나 루비 같은 범용 프로그래밍 언어, 앤서블이나 셰프 같은 구성 관리 도구 또는 캐피스트라노 같은 기타 서버 자동화 도구로 사용자 지정 스크립트를 작성해야 할 가능성이 높음. 이러한 종류의 스크립트를 작성할 때 실패 처리가 가장 까다로움
- 애플리케이션을 패키지하는 방법과 실행 방법에 따라 애플리케이션을 배포하는 데 사용할 수 있는 다양한 도구
- 배포 전략
- 교체를 통한 롤링 배포
- 앱의 이전 복사본 중 하나를 제거하고, 이를 교체할 새 사본을 배포함. 새 사본이 올라올 때까지 기다렸다가 상태 확인을 통과하면 새 복사본에 라이브 트래픽을 전송하기 시작함. 그리고 이전 복사본이 모두 교체될 때까지 프로세스를 반복함
- 교체 없는 롤링 배포
- 앱의 새 복사본 하나를 배포하고 새 복사본이 올라올 때까지 기다렸다가 상태 확인이 통과되면 새 복사본에 라이브 트래픽을 보내기 시작한 후 앱의 이전 복사본 배포를 취소함. 그리고 이전 복사본이 모두 교체될 때까지 프로세스를 반복함
- 블루-그린 배포
- 앱의 새 복사본이 5개를 배포하고 모든 복사본이 올라올 때까지 기다림. 그리고 상태 확인을 통과한 후 모든 라이브 트래픽을 새 복사본으로 이동한 다음 이전 복사본 배포를 취소함
- 카나리 배포
- 앱의 새 복사본 하나를 배포하고 복사본이 올라올 때까지 기다렸다가 상태 확인을 통과한 후 라이브 트래픽을 전송하기 시작한 다음 배포를 일시 중지함. 배포를 일시 중지하는 동안 카나리라고 불리는 앱의 새로운 복사본을 컨트롤이라고 불리는 이전의 사본 중 하나와 비교함.
- CPU 사용량, 메모리 사용량, 지연 시간, 처리량, 로그 오류율, HTTP 응답 코드 등 다양한 차원에 걸쳐 카나리아와 컨트롤을 비교할 수 있음
- 교체를 통한 롤링 배포
- 배포 서버
- 개발자 컴퓨턴가 아닌 CI 서버에서 배포를 실행해야 함. 배포 서버를 사용하면 이점
- 완전 자동화
- CI 서버에서 배포를 실행하려면 모든 배포 단계를 완전히 자동화해야 함
- 배포 프로세스가 코드로 정의되고 어떤 단계도 수동 오류로 인해 실수로 놓치지 않음. 빠르고 반복적으로 배포할 수 있음
- 일관된 환경에서 실행
- 서로 다른 운영 체제, 다른 버전의 테라폼을 사용하여 서로 다른 종속성 버전, 서로 다른 구성, 개발자가 실수로 버전 관리에 적용되지 않은 변경 사항을 배포한 경우와 같이 실제 배포되는 항목의 차이를 예로 들 수 있음
- 보다 나은 권한 관리
- CI 서버에서만 해당 권하을 부여할 수 있음
- 완전 자동화
- 개발자 컴퓨턴가 아닌 CI 서버에서 배포를 실행해야 함. 배포 서버를 사용하면 이점
- 환경 전반에 걸쳐 아티팩트 승격
- 개발,스테이징, 프로덕션 환경이 있는 경우 애플리케이션의 v0.0.4를 출시하려면
- 개발 환경에 앱 v0.0.4를 배포함
- 개발 환경에서 수동 및 자동 테스트를 실행함
- v0.0.4가 개발 환경에서 잘 작동하는 경우 1단계와 2단계를 반복하여 v0.0.4를 스테이징 환경에 배포함. 이를 아티팩트 승격(promoting artifacts)이라고 함
- v0.0.4가 스테이징 환경에서 잘 작동하는 경우 1단계와 2단계를 다시 반복하여 v0.0.4를 운영 환경을 승격함
- 문제가 발생하면 언제든지 이전 아티팩트 버전으로 롤백할 수 있음
- 개발,스테이징, 프로덕션 환경이 있는 경우 애플리케이션의 v0.0.4를 출시하려면
- 버전 관리 사용
- 개발에서 프로덕션까지 테라폼 모듈 같은 인프라 코드를 가져오는 워크 플로
- 인프라 코드 배포를 위한 워크플로
- 버전 관리 사용
- 인프라 코드 버전 관리에는 몇 가지 추가 요구 사항
- 라이브 리포지터리 및 모듈 리포지터리
- 테라폼의 황금 법칙
- 테라폼 코드의 상태를 확인하는 간단한 방법
- 라이브 리포지터리로 이동하여 임의로 여러 폴더를 선택하고 각 폴더에서 terraform plan 명령을 실행함. 출력이 항상 변경 사항 없음이면 이는 인프라 코드가 실제 배포된 환경과 일치한다는 것을 의미함
- 브런치 문제
- 인프라 코드 버전 관리에는 몇 가지 추가 요구 사항
- 코드 변경
- 변경할 때마다 terraform apply를 다시 실행하여 변경 사항을 배포하고 curl을 다시 실행하여 해당 변경 사항이 제대로 작동하는지 확인함
- 애플리케이션 코드와의 유일한 차이점은 일반적으로 인프라 코드 테스트에 더 오랜 시간이 걸린다는 것
- 코드 리뷰를 위해 변경 사항을 반영
- 문서화
- 서면 문서화
- 대부분의 테라폼 모듈에는 모듈의 기능, 모듈이 존재하는 이유, 모듈의 사용 방법, 수정 방법을 설명하는 README가 있어야 함
- 코드에 몰두해 어떻게 작성해야 하는지에 대한 세부 사항에서 길을 잃기 전에 무엇을 작성해야 하는지 그리고 왜 만들어야 하는지를 고려하기 때문
- 코드 문서화
- 코드 자체 내에서 주석을 문서화의 한 형태로 사용할 수 있음
- 코드의 기능을 설명하기 위해 주석을 사용하지 않길 바람. 코드 그 자체로 기능을 설명해야 함
- 주석은 코드가 어떻게 사용되어야 하는지 또는 코드가 특정 설계를 왜 선택했는지와 같이 코드로 표현할 수 없는 정보만을 제공해야 함
- 예제 코드
- 모든 테라폼 모듈은 해당 모듈을 어떻게 사용해야 하는지를 보여주는 예제 코드를 포함해야 함
- 올바른 사용 패턴을 강조하고 사용자가 코드를 작성할 필요가 없이 모듈을 사용해볼 수 있는 방법이며 모듈에 대한 자동화된 테스트를 추가하는 주요 방법
- 서면 문서화
- 자동화된 테스트
- 파일 레이아웃
- 팀은 테라폼 코드가 저장되는 위치 및 사용하는 파일 레이아웃에 대한 규칙을 정의해야 함. 테라폼의 파일 레이아웃은 테라폼 상태가 저장되는 방식도 결정함
- 스타일 가이드
- 모든 팀은 공백, 줄 바꿈, 들여쓰기, 중괄호, 변수 이름 지정 등을 포함하여 코드 스타일에 대한 일련의 규칙을 정해야 함
- 문서화
- 자동화된 테스트 실행
- 인프라 코드는 모든 커밋 후에 CI 서버에서 자동화된 테스트를 시작하는 커밋 훅을 가지고 있어야 하며 풀 요청에서 해당 테스트의 결과를 표시해야 함
- 병합과 릴리스
- 팀 구성원이 코드 변경과 plan 출력을 검토했고 모든 테스트를 통과했다면 변경 사항을 master 브랜치에 병합하고 코드를 릴리스할 수 있음
- 깃 태그를 사용하여 버전이 지정된 릴리스를 만들 수 있음
- 테라폼은 기본적으로 깃 리포지터리에서 다운로드한 코드 자체가 태그와 버전이 지정된 불변 아티팩트가 됨
- 배포
- 테라폼 코드를 배포하기 위한 몇 가지 주요 고려 사항
- 배포 도구
- 아틀란티스
- 아틀란티스 오픈 소스 도구는 풀 요청에 plan 출력을 추가할 수 있을 뿐만 아니라 풀 요청에 특별한 주석을 추가하여 terraform apply 명령을 시작할 수도 있음
- 이 도구는 테라폼 배포를 위한 편리한 웹 인터페이스를 제공하지만 버전 과리를 지원하지 않기 때문에 대규모 프로젝트의 유지 보수와 디버깅을 더 어렵게 만들 수 있다는 점을 유의해야 함
- 테라폼 엔터프라이즈
- 해시코프의 엔터프라이즈 제품은 변수, 시크릿, 액세스 권한 관리뿐만 아니라 terraform plan 및 terraform apply를 실행하는 데 사용할 수 있는 웹 UI를 제공함
- 테라 그런트
- 테라폼의 일부 공백을 메우는 테라폼용 오픈 소스 래퍼 도구
- 스크립트
- 테라폼 사용 방법을 사용자 정의하도록 파이썬, 루비, 배시와 같은 범용 프로그래밍으로 스크립트를 작성할 수 있음
- 아틀란티스
- 배포 전략
- 테라폼 자체는 어떤 배포 전략도 제공하지 않음. 롤링 배포 또는 블루-그린 배포에 대한 내장 지원이 없으며 대부분의 테라폼 변경 사항을 기능 전환할 수 있는 방법이 없음
- 배포 서버
- 모든 인프라 코드 변경은 개발자의 컴퓨터가 아닌 CI 서버에서 적용해야함
- 젠킨스, 서클CI, 테라폼 엔터프라이즈, 아틀란티스 또는 다른 안전한 자동화된 플랫폼에서 terraform 명령을 실행할 수 있음
- 환경 전반에서 아티팩트 승격
- 배포 도구
- 테라폼 코드를 배포하기 위한 몇 가지 주요 고려 사항
- 버전 관리 사용
- 배포 워크플로 비교
-
애플리케이션 코드 인프라 코드 버전 관리 사용 git clone, 애프리케이션마다 리포지터리 하나, 브랜치 사용 git clone, 라이브와 모듈 리포지터리, 브랜치 미사용 코드를 로컬에서 실행 로컬호스트에서 실행, ruby web-server.rb, ruby web-server-test.rb 샌드박스 환경에서 실행, terraform apply, go test 코드 변경 코드 변경, ruby web-server.rb, ruby web-server-test.rb 코드 변경, terraform apply, go test, 테스트 단계 사용 코드 리뷰를 위해 변경 사항을 적용 풀 요청 적용, 코딩 가이드라인 수행 풀 요청 적용, 코딩 가이드라인 실행 자동화된 테스트 실행 CI 서버에서 테스트 수행, 단위 테스트, 통합 테스트, 종단 간 테스트, 정적 분석 CI 서버에서 테스트 수행, 단위 테스트, 통합 테스트, 종단 간 테스트, 정적 분석, terrafrom plan 병합과 릴리스 git tag, 버전이 지정된, 변경 불가능한 아티팩트 git tag, 태그와 함께 버전이 지정된,변경 불가능한 아티팩트를 저장하는 리포지터리 사용 배포 테라폼,쿠버네티스나 메소스 같은 오케스트레이션 도구, 스크립트를 이용한 배포,롤링 배포, 블루-그린,카나리 같은 다양한 배포 전략, CI 서버를 이용한 배포, CI 서버에서 제한된 권한 부여, 환경 전반에 걸쳐 불가능하고 버전이 지정된 승격 테라폼,아틀라스,테라폼 엔터프라이즈,테라그런트,스크립트를 이용한 배포,재시도,errored.tfstate가튼 제한적인 배포 전략, 에러 처리를 확실히 해야함, CI 서버를 이용한 배포, CI 서버에 관리자 권한 부여, 환경 전바에 걸쳐 변경 불가능하고 버전이 지정된 아티팩트 승격
-