감상

필수적이면서도 기본적인 내용이 많이 들어있어서 좋았다. 초반부터 너무 힘을 줘서 (= 모든 실습을 수행하면서) 읽어나가니, 5장이 끝날 때 완전 녹초가 되어 6장을 읽는 것이 많이 힘들었다. 그래서 6장부터는 조금 러프하게 (= 설렁설렁) 읽으니 그제서야 좀 할 만 했다.

기억할 만한 부분들

코드형 인프라(IaC)의 다섯 가지 카테고리

• Ad-hoc script : 서버에서 수동으로 실행
• Configuration management : chef, puppet, ansible, saltstack
  • idempotency
• Server template : docker, packer, vagrant
• Orchestration: k8s, marathon/mesos, eks, gke, aks(azure), docker-swarm, nomad
• Provision : terraform, cloudformation, openstack heat, plumni

why IaC

self-service (by developer), speed/safety, documentation, version control, validation, re-usability, happiness (less stress than manual)

imperative vs declarative

when current = 10
"add 5" vs "be 15"

Graphviz?

dependency visualization tool

(aws) alb components

• (X) aws_launch_configuration
• (A) aws_lb
• (B) aws_listener : depends on A
• (C) aws_lb_target_group : depends on A
• (D) aws_autoscaling_group : contains X, attach to C
• (E) aws_listener_rule : bind B with C

(틀렸을 수도 있음)

terraform backend

• S3 backend 를 만드는 부분은 수작업이 필요
• backend block 은 변수/참조 사용이 불가능함 --> backend.hcl 파일을 만들고 tf init -backend-config=backend.hcl 형태로 재사용하는 것을 권장

인프라 격리

• tf workspace < file structure (directory)

시크릿 값이 bash history 에 저장되지 않도록 조심

• 명령어 입력시 앞에 빈 칸을 넣으면 됨 (이렇게 해도 history 에 남도록 세팅되긴 함)

• pass 명령어 활용하는 방법이 더 안전함 (https://www.passwordstore.org/)

구문들

count, for_each, for, condition by count

테라폼의 주의사항

• count, for_each 을 사용 못하는 케이스가 존재 함
  • determined 한 값이 필요한 영역 : 예를 들면 random_integer + aws_instance:count = fail
• 무중단 배포가 쉽지 않음
• plan 이 성공해도 apply 실패할 수 있음
• 리팩터링이 힘듦 : 값을 입력하는 곳과 이 값을 레퍼런스로 사용하는 곳 사이의 거리가 아주 멀 수 있음
  • tf state mv <ORIGINAL_REF> <NEW_REF> 를 활용할 수 있음
  • 일부 매개 변수는 변경이 불가능함

프로덕션 수준의 인프라 체크리스트

• 설치 : binary, dependency
• 설정 : port, tls, service discovery, leader/follower, replication
• 프로비전 : server, lb, network, firewall, auth
• 배포
• 고가용성 (High Availability)
• 확장성
• 성능 : cpu, memory, disk, netowkr, query, benchmark, test, profiling
• 네트워킹
• 보안
• 메트릭
• 로그
• 백업/복구
• 비용 최적화
• 문서화
• 테스트

테스트

큰 그림

tf init 
tf apply 
tf output
curl -> expected output check
tf destroy

terratest

위 '큰 그림'을 자동화하는 golang lib

주의사항

모든 리소스의 네임스페이스를 항상 지정하라

요점

• 테라폼 코드를 로컬호스트에서 테스트 할 수 없음. 따라서 격리된 샌드박스 환경이 필요함
• 순수한 단위 테스트가 존재하지 않음. 따라서 격리된 샌드박스 환경이 필요함
• 샌드박스 환경을 정기적으로 정리할 것
• 모든 리소스의 네임스페이스를 관리할 것 (e.g., for parallel test)
• 모듈이 작아야 테스트하기 쉽고 빠르다.

팀에 IaC 도입하기

(우리 팀은 테라폼을 이미 도입했지만, 테라폼만의 얘기가 아니라고 생각하여 가져옴)

"개발자가 테라폼을 발견하고 테라폼이 할 수 있는 일에 영감을 받고 열정과 흥분으로 가득 차 사람들에게 테라폼을 보여주면 상사가 "안 돼"라고 말하는 경우를 자주 보았습니다. 물론 개발자는 좌절하고 낙담합니다. 왜 다른 사람들은 테라폼의 이점을 보지 못할까? 우리는 모든 것을 자동화할 수 있어! 많은 버그도 피할 수 있어! 이 기술 부채를 어떻게 해결하려는 걸까? 왜 이렇게 근시안적일까?"

문제는 이 개발자가 테라폼과 같은 코드형 인프라 도구를 채택함으로써 얻을 수 있는 이점은 알아도 모든 대가를 알지 못한다는 점입니다.

• 러닝 커브와 기회비용

상사 설득

여러분이 선호하는 기능을 나열하는 것은 효과적이지 않습니다. (...) 즉, 여러분의 제품이 고객에게 줄 수 있는 새로운 초능력을 보여줘야 합니다.

e.g., 테라폼은 선언적이예요 (X) / 테라폼은 인프라를 더 빨리 만들어줘요 (O)

• 상사와 대화하여 해당 분기 혹은 그 해의 가장 중요한 문제를 이해하려고 노력하라

점진적 도입

점진주의의 핵심은 단순히 작업을 일련의 작은 단계로 나누는 것만이 아니라 이후의 단계를 실행하지 않는다 하더라도 모든 단계가 고유한 가치를 가져다주는 방식으로 작업을 나누는 것입니다.

충분히 멀리보되, 모든 단계가 유의미하게 스텝을 만들어라. 즉, 애자일하라! (No bigbang)

팀에 학습시간 부여

테라폼의 황금률

"라이브 레포지토리 '마스터 브랜치'는 프로덕션에 '실제로 배포된 인프라'를 '1:1로' 표현해야 한다"

(마스터 브랜치의 함의 : 하나의 브랜치로 표현하라)

단일 브랜치에서 배포하라

• 서로 다른 브랜치에서 작업하면 backend lock 과 무관하게 두 개발자의 의도가 서로를 방해할 수 있음

apply 전에 plan 하라

개인적인 생각

• 코드를 보고 머리에 그림이 안들어온다면 graphviz 를 적극적으로 활용하자.
• 함부로 이름 바꾸지 말자 (무섭다)
• 테라폼 너무 어렵다 (모든게 코드라고 해도, 그 코드가 여러 레포에 있는데 이걸... 으악 💀)
• 상사의 생각을 읽자.