이 글은 Terraform 추천 사용패턴 #1에서 이어진 글이다.

이 글은 HashiCorp에서 최근에 공개한 Terraform Recommended Practices를 번역한 글입니다. HashiCorp로부터 정식으로 번역 허락을 받고 번역해서 블로그에 올립니다. 좋은 도구와 함께 번역을 허락해 준 HashiCorp에 감사드립니다.

웹사이트에 올라온 글을 블로그에 올리려니 글이 길어서 아래 2개의 글로 나누어서 올립니다.

• Terraform 추천 사용패턴 #1
• Terraform 추천 사용패턴 #2
  
  
  
  

3편: 프로비저닝 사용패턴을 발전시키는 방법

이번 편에서는 수동 프로비저닝 단계에서 collaborative infrastructure as code 작업 흐름으로 넘어가는 데 필요한 과정을 설명한다. 운영 성숙도의 각 단계에서 조직이 다음 단계로 넘어갈 수 있도록 안내를 하고 최종적으로 추천하는 작업 흐름에 다다르게 될 것이다.

이번 편은 여러 페이지로 나누어져 있으므로 이미 구현한 단계의 안내는 건너뛰어도 된다. 2편에서 작성한 메모를 다시 보면서 운영 성숙도의 현재 단계에 관한 페이지부터 읽어봐라.

• 3.1편: 수동변경에서 반자동으로 바꾸는 방법
• 3.2편: 반자동에서 Infrastructure as Code로 바꾸는 방법
• 3.3편: Infrastructure as Code에서 Collaborative Infrastructure as Code로 바꾸는 방법
• 3.4편: Collaborative Infrastructure as Code로의 고급스러운 개선
  
  

3.1편: 수동변경에서 반자동으로 바꾸는 방법

인프라스트럭처를 (CLI나 GUI 도구를 이용해서) 수동으로 구축하면 인프라스트럭처를 감사(audit)하기 어렵고 재현하기도 어려우면 확장도 쉽지 않고 관련 지식을 공유하기도 어렵게 된다.

현재의 프로비저닝 사용패턴이 대부분 수동이라면 첫 목표는 인프라스트럭처 중에서 관리할 수 있는 작은 부분에 오픈소스 Terraform을 사용하기 시작하는 것이다. Terraform으로 작게 성공하고 나면 프로비저닝 성숙도에서 반자동 단계에 다다른 것이고 이제 Terraform의 사용을 늘리기 시작할 수 있다.

다음 과정으로 엔지니어링 팀의 개개인(또는 작은 그룹)이 Terraform에 익숙해지도록 할 수 있다.

1. Terraform 설치

Terraform OSS를 설치하려면 이 안내문서를 따라 해라.

2. 코드 작성

첫 Terraform 구성 파일을 작성해라.

3. 시작하기 문서 읽기

Terraform 시작하기 안내 문서의 남은 부분을 따라 해 봐라. 이 페이지에서는 리소스를 변경하고 제거하고 리소스 의존성을 사용해 보는 등을 따라 해 볼 수 있다.

4. 실제 인프라스트럭처 프로젝트 구현

작은 실제 프로젝트를 선택하고 이를 Terraform으로 구현해라. 조직에서 곧 시작할 프로젝트의 목록을 살펴보고 하나를 선정해서 Terraform의 개념을 증명해봐라. 아니면 기존에 존재하는 인프라스트럭처를 Terraform으로 다시 구현할 수도 있다.

프로젝트를 선택할 때의 핵심은 AWS에서 새로운 애플리케이션용 인프라스트럭처를 프로비저닝하듯이 제한된 범위와 명확한 경계를 가지는 것이다. 이러면 기능과 가능성 때문에 팀이 압도되는 문제를 방지할 수 있다. 어떤 선택을 해야 하는지 감을 잡기 위해 일부 예시 프로젝트를 살펴봐도 된다.(AWS 2계층 예시가 종종 좋은 시작점이 된다.)

여기서 목표는 Terraform으로 작더라도 신뢰할 수 있는 전문 지식의 핵심을 구축하고 조직 내 다른 사람들에게 그 장점을 보여주는 것이다.

다음

여기서 프로비저닝 사용패턴의 반자동 단계에 도달했다. 조직 내 한 명 이상이 Terraform 코드를 작성해서 리소스를 프로비저닝하고 수정할 수 있게 되었고 인프라스트럭처에서 작지만 의미 있는 일부를 코드로 관리하게 되었다. 이제 Terraform으로 인프라스트럭처를 작성하고 프로비저닝하는 것이 얼마나 쉬운지 팀의 다른 사람들에게 작은 데모를 보여주기 좋은 때이다.

다음은 더 완전한 infrastructure as code 작업으로 넘어갈 차례이다.

3.2편: 반자동에서 Infrastructure as Code로 바꾸는 방법

최소한 다음 두 가지 사용패턴을 함께 사용하는 것을 반자동 프로비저닝으로 정의한다.

• Terraform으로 Infrastructure as code
• 수동 CLI나 GUI 절차
• 스크립트

위 설명이 현재 프로비저닝 사용패턴을 의미한다면 다음 목표는 Terraform의 사용을 늘리고 수동 과정과 절차식 스크립트의 사용을 줄이는 것이다. infrastructure as code를 더 일관적이고 유용하게 만드는 기초 사용패턴을 적용해라.

Note: 인프라스트럭처에 infrastructure as code를 전혀 사용하고 있지 않다면 3.1편의 과정을 먼저 따라 해봐라.

1. 버전 관리의 사용

조직이 아직 VCS를 사용하지 않는다면 버전 관리 시스템(VCS)를 선택하고 적용해라.

최소한의 기능을 가진 Git/Mercurial/SVN 서버로 시작해도 되지만 코드 리뷰와 승인 기능을 지원하고 저장소 데이터에 접근하는 API가 있으며 저장소와 계정을 관리할 수 있는 더 튼튼한 협업 VCS 애플리케이션을 도입하기를 권장한다. Bitbucket, GitLab, GitHub이 이 영역에서 유명한 도구들이다.

이미 VCS 작업 흐름, 레이아웃, 접근 관리 사용패턴을 사용하고 있다면 아주 좋은 상태이다. 이를 사용하고 있지 않다면 이러한 결정을 하기 좋은 때이다.(이 조언이 시작점으로 좋다고 생각한다.) 누가 변경사항을 머지하고 어떤 상황에서 머지할 권한이 있는지 확실하게 계획해라. 이 코드가 전체 인프라스트럭처를 관리할 것이므로 이 코드의 무결성과 품질을 관리하는 것이 중요하다.

또한, 조직이 기대하는 바를 적어두고 이를 팀 내에 알려야 한다.

선택한 VCS 시스템에 Terraform Enterprise가 접근할 수 있는지 확인해라. 현재 Terraform Enterprise는 GitHub, GitLab, Atlassian Bitbucket(Server와 Cloud 버전 모두 지원)과의 통합을 지원한다.

2. VCS 저장소에 Terrafom 코드를 두어라

인프라스트럭처 코드를 버전 관리 밑으로 옮기자. 새로운 Terraform 코드는 모두 버전 관리하에 두어야 한다. 기본에 작성해서 버전 관리를 하지 않는 Terraform 코드가 있다면 이를 버전 관리 밑으로 이동시키고 조직 내의 모두가 어디서 코드를 볼 수 있는지 알게 하고 변경사항의 히스토리와 목적을 추적할 수 있게 해라.

3. 첫 모듈을 생성해라

Terraform 모듈은 재사용할 수 있는 구성단위다. 모듈을 사용하면 인프라스트럭처의 각 부분을 하나의 패키지처럼 관리할 수 있으므로 한 워크스페이스의 주요 구성에서 여러 번 정의하고 호출할 수 있다. Terraform 모듈을 사용하기 좋은 후보의 예시는 launch configuration, auto-scaling group, EC2 Elastic Load Balancer(ELB)등을 감싸서 하나의 auto-scaling group를 만드는 것이다. 이미 Terraform 모듈을 사용하고 있다면 추천 사용패턴을 읽어보고 개선할 수 있는 곳이 있는지 살펴봐라.

언제 모듈을 작성할지 고민할 때 아래 다이어그램을 참고해라.

4. 지식을 공유해라

Terraform 기술을 다른 팀에 전파하고 기존 인프라스트럭처 팀의 기술을 향상해라. 다음으로 내부 교육과 자발적인 학습을 고려해 볼 수 있다.

• 팀이 공식 HashiCorp 트레이닝에 가입한다.
• Terraform Up and Running: Writing Infrastructure as Code이나 Getting Started with Terraform같은 자료를 이용해 봐라. 조직 내에서 아무도 이전에 Terraform을 사용해 본 적이 없을 때 이 책은 특히 유용하다.
  
  

5. 가이드라인을 잡아라

Terraform 코드를 작성하는 가이드라인으로 쓸 수 있도록 표준 빌드 아키텍처를 만들어라. 모듈은 조직 간에 공유할 때 가장 잘 동작한다. 인프라스트럭처를 설계하는 방법에서 모두가 비슷한 기대를 하고 있을 때 모듈 공유는 더욱 효과적이다. IT 아키텍트는 조직의 요구사항에 맞춰 표준화된 빌드 아키텍처를 설계해야 한다. 이를 통해 고가용성, 탄력성, 재앙 복구를 염두에 둔 채 구축하도록 장려하고 여러 팀이 일관성을 맞출 수 있게 지원할 수 있다.

다음은 여러 클라우드 프로바이더의 좋은 빌드 패턴의 예시이다.

• AWS: Well Architected Frameworks와 Architecture Center.
• Azure: deploying Azure Reference Architectures와 Azure Architecture Center.
• GCP: Building scalable and resilient web applications.
• Oracle Public Cloud: Best Practices for Using Oracle Cloud.
  
  

6. Terraform을 구성 관리와 통합하기

조직에서 이미 구성 관리(configuration management) 도구를 사용하고 있다면 여기에 Terraform을 통합할 때이다. 리소스를 생성한 뒤 구성 관리 도구에 제어권을 넘길 때 Terraform의 provisioner을 사용할 수 있다. Terraform이 인프라스트럭처를 관리하고 다른 도구들이 사용자 데이터와 애플리케이션을 관리해야 한다.

구성 관리를 사용하지 않는다면 엄격하게 말해서 불변 인프라스트럭처를 사용하고 있다고 할 수가 없고 구성 관리 도구의 도입을 고려해봐야 한다. 이는 꽤 큰 작업이 될 수 있지만, 팀 사이에서 애플리케이션 구성을 더 제어 가능하고 이해하기 쉽고 반복할 수 있게 해서 infrastructure as code로 가는 하나의 목표를 이루는 데 도움이 된다.

이제 막 시작했다면 Chef cookbook을 생성하는 방법에 관한 튜토리얼을 시도해보고 로컬에서 Vagrant로 테스트해봐라. 조직에 어떤 구성 관리 도구가 적합한지 결정하는 방법에 대한 글도 추천한다.

7. 비밀정보(Secret) 관리

Terraform을 Vault나 다른 비밀정보 관리 도구와 통합해라. 서비스 프로바이더 자격증명 같은 비밀 정보는 비밀로 관리하면서 쉽게 사용할 수도 있어야 한다. 전용 비밀정보 관리 도구를 사용하는 것이 이 요구사항을 해결하는 가장 좋은 방법이다. HashiCorp의 Vault가 대부분은 가장 좋은 선택이라고 생각하지만 Terraform은 다른 비밀정보 관리 도구와도 잘 통합할 수 있다.

다음

여기서 조직 내에 VCS를 구성하고 Terraform으로 핵심 인프라스트럭처를 관리하고 재사용할 수 있는 Terraform 모듈을 최소 하나 가지게 되었다. 반 자동화된 사용사례와 비교해서 조직의 인프라스트럭처 구성이 훨씬 가시적이게 되었고 일관적인 언어와 작업 흐름을 사용하게 되었다.

Infrastructure as Code에서 Collaborative Infrastructure as Code로 바꾸는 방법

핵심 인프라스트럭처 관리에 버번으로 관리하는 Terraform 구성을 사용하면 많은 기술 복잡성과 비일관성을 제거할 수 있다. 이제 기본적인 부분은 관리할 수 있게 되었으므로 다른 문제에 집중할 수 있게 되었다.

다음 목표는 아래와 같다.

• Terraform 사용에 관한 일관적인 작업 흐름을 여러 팀에 적용한다.
• Terraform 코드를 직접 수정하는 핵심 엔지니어들 외에도 Terraform의 혜택을 확장한다.
• 사용자와 팀의 인프라스트럭처 프로비저닝 권한을 관리한다.

Terraform Enterprise(TFE)는 위와 같은 다음 단계의 문제를 해결하기 위해 만든 제품이다. 다음 편에서는 TFE를 가장 효과적으로 사용하는 방법을 설명한다.

Note: 아직 인프라스트럭처 상당 부분에 성숙한 Terraform 코드를 사용하고 있지 않다면 이전 편의 단계를 먼저 따라 해 봐라.

1. TFE 설치 및 회원 가입

Terraform Enterprise는 SaaS로 사용하거나 내부에 설치해서 사용할 수 있다. SaaS를 쓰기로 했다면 이 과정을 건너뛰어도 된다. 내부 설치 버전을 선택했다면 설치 가이드를 살펴봐라. Terraform은 TFE 서버의 URL을 출력해 줄 것이다.

2. TFE의 실행 환경 배우기

TFE에서 Terraform이 어떻게 동작하는지 이해해야 한다. Terraform OSS에서는 보통 파일 시스템에 코드를 두려고 외부 VCS 도구를 사용하면서 명령행으로 실행하거나 범용적인 CI 시스템에서 실행한다.

TFE는 다르게 동작한다. 워크스페이스가 VCS 저장소와 직접 연결되어 있고 TFE의 UI나 API로 실행하고 모니터링한다. 이 운영 모델에 익숙해지도록 다음 과정을 따라 해보자.

• Terraform Enterprise에서 Terraform 실행을 수행하고 구성하는 방법에 관한 문서를 읽어봐라.
• 개념을 증명할 용도로 워크스페이스를 만들고 이를 VCS 저장소에 있는 Terraform 코드와 연결하고 필요한 변수를 설정해라. 그 다음 해당 코드를 Terraform이 실행하도록 Terraform Enterprise를 사용해라.
  
  

3. 조직의 워크스페이스 구조를 설계해라

TFE에서 각 Terraform 구성은 특정 인프라스트럭처 컴포넌트를 관리해야 하고 해당 구성의 각 환경은 별도의 워크스페이스가 되어야 한다. 즉, Terraform 구성 * 환경 = 워크스페이스다. 워크스페이스 이름을 "networking-dev"처럼 지으면 관리하는 인프라스트럭처와 환경이 무엇인지 한눈에 알 수 있다.

"인프라스트럭처 컴포넌트"의 정의는 조직 구조에 따라 다르다. 특정 워크스페이스가 애플리케이션, 서비스, 관련 서비스의 그룹을 관리할 수도 있다. 한 엔지니어링 팀이 사용하는 인프라스트럭처를 프로비저닝할 수도 있고 전체 사업에서 공유하는 기반 인프라스트럭처를 프로비저닝할 수도 있다.

인프라스트럭처를 담당하는 부서들과 일치하도록 워크스페이스 구조를 만들어야 한다. 네트워크 같은 일부 컴포넌트는 중앙 IT 직업이 관리하는 기반 인프라스트럭처이고 어떤 컴포넌트는 애플리케이션에 국한되어 있으므로 이를 사용하는 엔지니어링 팀이 관리해야 한다. 그래서 최종적으로는 복합적인 형태가 될 것이다.

또한, 다음을 염두에 두어야 한다.

• 어떤 워크스페이스는 다른 워크스페이스가 사용해야 하는 출력 데이터를 발행한다.
• 구성 환경(app1-dev, app1-stage, app1-prod)을 만드는 워크스페이스는 제대로 검증된 코드를 보장하기 위해 순서대로 실행되어야 한다.

첫 번째 관계는 환경은 같지만, 컴포넌트는 다른 워크스페이스끼리의 관계이다. 이 관계는 워크스페이스 간의 의존성 그래프를 만들고 이 의존성을 이해하고 있어야 한다. 두 번째 관계는 컴포넌트는 같지만, 환경이 다른 워크스페이스끼리의 관계인데 이는 워크스페이스 간의 파이프라인을 만든다. TFE는 현재 이러한 의존성대로 동작하는 기능이 없지만 종속된(cascade) 갱신과 코드 적용 같은 기능이 곧 도입될 예정이다. 워크스페이스의 연결 관계를 이해하고 있다면 이 기능을 더 쉽게 사용할 수 있을 것이다.

4. 워크스페이스 생성

TFE에서 워크스페이스를 생성하고 VCS 저장소를 매핑해라. 각 워크스페이스는 연결된 버전 관리 시스템에서 Terraform 코드를 읽어온다. 각 워크스페이스에 저장소와 브랜치를 할당해야 한다.

특정 앱이나 서비스의 환경마다 같은 저장소와 브랜치를 사용하기를 권장한다. 변수를 통해 환경을 식별할 수 있도록 Terraform 코드를 작성하고 이러한 변수를 워크스페이스에 적절하게 설정해라. 워크스페이스마다 다른 브랜치를 사용하고 병합 전략으로 코드를 적용하는 경우 이미 작성해 놓은 코드에는 이 접근이 유용하지 않을 수 있지만, 기준이 되는 하나의 브랜치를 사용하는 모델이 가장 잘 동작한다고 생각한다.

5. 사용자와 팀 생성

동료들은 모두 자신의 TFE 사용자 계정을 생성하고 조직에 가입해야 한다. 그다음 이들을 적절한 팀에 추가할 수 있다.

TFE의 팀은 워크스페이스마다 권한을 부여할 수 있는 사용자 목록이다. 즉, TFE 팀은 어떤 인프라스트럭처를 누가 담당하는지에 대한 지식과 일치해야 한다. 회사 조직도와 항상 정확하게 일치하는 것은 아니므로 이에 관해 시간을 내서 고민해 보아야 하고 조직 내의 사람들과 얘기를 나누어 봐야 한다. 이때 다음을 염두에 두어라.

• 어떤 팀은 여러 워크스페이스에 관리자 권한이 필요하고 어떤 팀은 한두 개의 워크스페이스에만 권한이 필요하다.
• 팀이 사용하는 워크스페이스에 모두 같은 권한을 갖지 않을 수도 있다. 예를 들어 애플리케이션 개발자는 애플리케이션 개발환경과 스테이지 환경에 읽기/쓰기 접근 권한을 갖지만, 프로덕션 환경에서는 읽기 권한만 가질 수 있다.

collaborative infrastructure as code를 실천할 때 가장 어려운 부분 중 하나가 어떻게 책임을 위임할지에 대해 정확하고 완전한 지도를 관리하는 것이다.

6. 권한 할당

팀에 워크스페이스 소유권과 권한을 할당해라. 각 워크스페이스에는 다른 사용자나 팀에 부여할 수 있는 세 단계의 권한인 관리자, 읽기/쓰기, 읽기 전용 권한이 있다. 관리자는 효과적으로 워크스페이스를 소유하고 다른 사용자의 권한을 변경할 수 있다.

대부분의 워크스페이스는 다른 권한을 가진 여러 팀에 접근 권한을 줄 것이다.

워크스페이스	팀 권한
app1-dev	Team-eng-app1: Read/write Team-owners-app1: Admin Team-central-IT: Admin
app1-prod	Team-eng-app1: Read-only Team-owners-app1: Read/write Team-central-IT: Admin
networking-dev	Team-eng-networking: Read/write Team-owners-networking: Admin Team-central-IT: Admin
networking-prod	Team-eng-networking: Read-only Team-owners-networking: Read/write Team-central-IT: Admin

7. Terraform이 아닌 접근은 제한해라

클라우드 프로바이더 UI와 API 접근을 제한해라. Terraform Enterprise가 이제
이제 조직 내에서 인프라스트럭처를 프로비저닝하는 주요 인터페이스가 Terraform Enterprise이므로 TFE을 건너뛰는 대체 인터페이스는 모두 접근을 제한해야 한다. 대부분의 사용자는 조직이 합의한 Terraform 작업 흐름을 사용하지 않고 인프라스트럭처를 수동으로 변경할 수 없어야 한다.

아무도 Terraform을 건너뛸 수 없으므로 코드 리뷰 절차와 TFE 워크스페이스 권한이 누가 인프라스트럭처를 수정할 수 있는지에 대한 최종 기록이 된다. 이를 통해 인프라스트럭처와 관련된 모든 것을 더 인식할 수 있고 제어할 수 있게 만들 수 있다. Terraform Enterprise는 조직 내에서 어떤 인프라스트럭처라도 프로비저닝 할 때 배워야 하고, 안전해야 하고, 감사(audit)해야 하는 단 하나의 작업 흐름이다.

다음

여기서 Terraform Enterprise로 collaborative infrastructure as code를 성공적으로 적용했다. 이제 하나의 작업 흐름으로 여러 프로바이저에 걸쳐서 인프라스트럭처를 프로비저닝할 수 있고 접근 제어와 코드 적용 등 조직의 표준을 관리할 수 있는 공유 인터페이스를 갖게 되었다.

3.4편: Collaborative Infrastructure as Code로의 고급스러운 개선

이제 프로비저닝을 위한 협업 인터페이스와 작업 흐름을 갖게 되었고 사용패턴을 더욱 개선할 수 있는 단단한 틀을 만들었다.

아래 나오는 제안을 꼭 순서대로 해야 하는 것은 아니며 일부는 사업에 적합하지 않을 수도 있다. 다음 단계가 무엇인지 직접 찾아보려고 할 때 가능한 내용으로 아내 제안을 제공한다.

• TFE로 절차와 리소스를 더 이동시킨다. TFE를 성공적으로 적용하더라도 아직 수동 혹은 반자동 작업 흐름이나 절차가 남아 있으므로 이를 개선하기에 좋은 기회가 된다. 차후에 자동화를 할 대상을 찾기 위해 인프라스트럭처를 관리할 책임이 있는 모든 팀과 이를 위한 회의를 잡기를 제안한다. 2편의 질문에서 작성한 노트를 사용하거나 예전 변경 요청이나 장애 티켓을 참고해도 된다.
• HashiCorp Packer를 이미지 생성에 적용해라. Packer를 이용하면 머신 이미지를 유지보수 가능하며 반복 가능하게 만들 수 있고 Terraform의 사용을 증폭시킬 수 있다.
• 사업과 규제를 따르기 위해 Sentinel로 Terraform 구성에 정책을 적용해라.
• 감사(audit) 로그를 TFE에 설정해라. 내부에 설치한 Terraform Enterprise는 기본적으로 CloudWatch에 로그를 보낸다.
• 인프라스트럭처 모니터링과 성능 지표를 추가해라. 이를 통해 환경 간에 코드 적용을 더 안전하게 할 수 있고 애플리케이션의 성능을 보호할 수 있다. 이 영역에서 사용 가능한 도구가 많이 존재한다. 인프라스트럭처 자체와 사용자 관점에서의 애플리케이션 성능을 모두 모니터링하기를 추천한다.
• TFE API를 사용해라. 다양한 이벤트를 받아서 Terraform 실행을 시작하고 범용적인 CI/CD 도구와 통합할 때 TFE API를 사용할 수 있다.