Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #91 : 17-12-02

웹개발 관련

  • The Cost Of JavaScript : 웹 브라우저에서 JavaScript 파일을 처리하는 비용에 관해서 설명한 글이다. 보통 네트워크로 다운받는 시간 때문에 용량을 줄이는 데 용량문제는 네트워크뿐이 아니라 JavaScript 파일을 파싱하고 컴파일하는 데도 큰 비용이 들기 때문에 사용자가 최초로 웹페이지를 사용하는 시간을 지연시키고 실제로 얼마나 영향을 주는지를 여러 데이터를 통해 설명하고 있다. 이를 위해 용량을 다양한 방법으로 줄이는 것도 중요하지만 구글의 PRPL 패턴으로 최소한의 코드만 내려주고 이후는 동적 로딩을 했을 때의 장점을 비교해주고 있다.(영어)
  • React Pattern: Centralized PropTypes : React에서 타입을 관리하려는 방법으로 PropTypes가 있는데 이 부분을 각 컴포넌트에서 관리하면 코드도 많아지고 중복도 많아지므로 이를 중앙에서 관리했을 때의 장점과 사용방법을 설명하는 글이다.(영어)
  • How we adapted the Booking.com mobile site for the iPhone X notch. : Booking.com에서 웹사이트를 iPhone X에서도 잘 보이도록 수정한 과정을 설명하고 있다. iPhone X에서 늘어난 화면 영역을 기본적으로는 사용하지 않아서 사이트가 잘 보이지만 해당 영역까지 배경색이 적용되기를 원하면 viewportviewport-fit=cover를 추가해 주어야 하고 늘어난 영역인 safe-area에는 콘텐츠가 나타나지 않도록 env()constant() 함수를 CSS에 사용해야 한다.(영어)

그 밖의 프로그래밍 관련

  • Introducing security alerts on GitHub : GitHub이 저장소에서 사용하는 모듈의 보안취약점을 감지해서 알려주는 기능을 공개했다. 현재는 JavaScript와 Ruby만 지원한다.(영어)
  • Plan for dropping Python 2.7 support : NumPy에서 Python 2.7 지원 중단 계획을 공개했다. 2018년 12월 31일까지는 Python 2와 3을 모두 지원하고 2019년 1월부터는 Python 3만 지원하고 2019년 12월 31일까지 Python 2는 버그 수정만 이뤄질 예정이다.(영어)
  • Code together in real time with Teletype for Atom : Atom 에디터에서 간단히 현재 에디터를 공유하고 다른 개발자와 실시간으로 같이 개발할 수 있는 Teletype for Atom을 공개했다.(영어)
  • Why You Should Always Use Access Tokens to Secure an API : API를 사용할 때 인증 토큰과 관련해서 두 명세인 OpenID Connect와 OAuth 2.0이 각각 인증(Authentication)과 인가(Authorization)를 어떻게 담당하고 있는지 설명하고 구글에 인증해서 to-do 애플리케이션으로 Google 캘린더에 내용을 작성하는 예시를 통해 OpenID Connect와 OAuth 2.0의 토큰을 각각 어떻게 사용하는지 설명하고 있다. 인증/인가 관련 토큰을 처리할 때 도움이 될만한 글이다.(영어)
  • How much to build and how much to buy: powering chat and messaging apps : 메시징 애플리케이션을 만들어야 할 때 오픈소스 프로토콜, 오픈소스 프레임워크, IaaS, PaaS, 채팅 솔루션, SaaS 중에서 어느 정도까지 직접 구축하고 어디까지 구매를 할지를 정해야 하는데 각 선택권의 특징을 소개하고 있다. 인프라스트럭처, 보안, 확장성, 신뢰성 면에서 선택권 중에서 고를 때 어떤 부분을 고려해야 하는지 얘기하고 있는데 여기서는 메시징 애플리케이션을 가지고 설명하고 있지만 다른 솔루션을 구현할 때도 고민을 참고해 볼 요소가 많이 있다.(영어)
  • 정규표현식으로는 5일 걸리는 작업, 15분만에 끝내기 : Regex was taking 5 days to run. So I built a tool that did it in 15 minutes의 번역 글로 2만 개가 넘는 키워드를 문서에서 찾을 때 정규식으로 작업하니 5일이나 걸려서 Aho-Corasick 알고리즘과 Trie 자료구조를 이용한 Python 모듈을 만들어서 14분으로 처리시간을 줄인 과정을 설명하고 있다. 이 FlashText가 사용한 접근방식부터 어떤 상황에서 FlashText를 정규표현식 대신 사용하면 좋은지까지 명확하게 설명하고 있는 재밌는 글이다.(한국어)
  • React Native vs Real Native Apps : 페이스북 프로필, 할 일 목록, 페이지뷰, 지도 4개의 탭을 가진 간단한 앱을 Swift와 React Native로 둘 다 구현한 후 각 탭을 사용할 때 CPU, GPU, 메모리의 사용량을 비교했다. 둘 다 만들어 본 경험을 통해서 React Native와 Swift로 만든 네이티브 앱의 장단점을 잘 정리해 놓았다.(영어)
  • 2017 The State of Open Source Security : 보안 관련 회사인 Synk에서 설문 및 자사의 데이터를 기반으로 오픈소스에서 취약점이 발견되었을 때 이를 어떤 식으로 얼마나 걸려서 처리하고 이를 사용자에게 알려서 사용자는 업데이트하는지 얼마나 걸리는지를 분석해서 정리한 글이다. 찬찬히 읽어보면 꽤 재미있다.(영어)
  • 본격 macOS에 개발 환경 구축하기 : macOS에서 터미널을 더 잘 사용하기 위해서 환경 설정이나 테마, 기타 프로그램 설치하는 방법을 설명하는 글이다. 이 글 처음에 나오는 대로 이런 환경 설정을 여러 곳에 나누어져 있어서 찾기가 쉽지 않은데 한 글에 다 정리되어 있어서 따라 해보면서 설정을 비교해 보기 좋게 되어 있다.(한국어)

볼만한 링크

  • AWS re:Invent 2017 – Andy Jassy 기조 연설 및 주요 신규 서비스 발표 소식 : 11월 말에 열린 re:Invent에서 발표된 서비스를 정리한 글이고 둘째 날 공개된 서비스도 요약되어 있다.(한국어)
  • 초기리텐션을 획기적으로 높인 행동설계 이야기 : VCNC에서 비트윈 앱의 사용자 패턴을 분석해서 리텐션을 올린 얘기를 정리한 글이다. 릴리스한 지 얼마 안 된 앱도 아닌데 아주 크게 증가한 리텐션도 고무적이지만 사용자의 핵심액션을 분석해서 결정한 후 강제 유도 및 푸시를 통해서 단발성이 아닌 장기 리텐션으로 이어지게 하는 접근이 꽤 재미있다.(한국어)
  • 블록체인은 현재 어디쯤 와있나? : 체인파트너스의 표철민 대표가 블록체인의 현재 상황과 본인의 생각을 정리한 글이다. 기술적인 부분보다는 각 코인이 어떻게 성장하고 있고 ICO로 지금 IT 업계에 가상화폐가 어떻게 영향을 주고 있는지가 정리되어 있다. 가상화폐 쪽을 깊게 보고 있진 않아서 정부 정책이나 움직이는 방향에 대해서는 자세히 모르고 있었는데 생각을 정리하는데 꽤 도움이 된 글이다.(한국어)

IT 업계 뉴스

  • 미 연방통신위원회, 망 중립성 폐기 결정 : 지난 22일 미국 연방 통신위원회(FCC)에서 망 중립성을 폐기하기로 했다. 이는 12월 14일 표결을 통해 확정될 예정이지만 현재는 폐기가 될 가능성이 크다. IT 종사자로서 이런 폐기 결정은 너무 아쉽다.(한국어)

프로젝트

  • Luxon : JavaScript 날짜/시간 라이브러리
  • Lona : Airbnb에서 공개한 프로그램으로 크로스 플랫폼용 UI 코드와 스케치파일 등을 생성할 수 있다고 한다. 현재는 의견을 나뉘기 위한 Developer Preview 상태이다.
  • accessibilityjs : 웹브라우저에서 접근성 오류를 확인해 주는 라이브러리.
  • Infinitown : WebGL 데모용 페이지.
  • LogoFox : 브랜드명을 입력하면 로고를 자동으로 만들어주는 사이트.
  • crossplane : NGINX 설정 파일 파서.

버전 업데이트

2017/12/02 03:05 2017/12/02 03:05

Terraform 추천 사용패턴 #2

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


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

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

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

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

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

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

5. 가이드라인을 잡아라

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

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

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 코드를 작성하고 이러한 변수를 워크스페이스에 적절하게 설정해라. 워크스페이스마다 다른 브랜치를 사용하고 병합 전략으로 코드를 적용하는 경우 이미 작성해 놓은 코드에는 이 접근이 유용하지 않을 수 있지만, 기준이 되는 하나의 브랜치를 사용하는 모델이 가장 잘 동작한다고 생각한다.

VCS 브랜치의 변경사항이 master에 병합될 수 있고 그다음 스테이징 환경, UAT 환경, 최종적으로는 프로덕션 환경을 의미하는 워크스페이스에 코드 적용을 할 수 있다.


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를 사용할 수 있다.
2017/11/26 20:53 2017/11/26 20:53