Outsider's Dev Story

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

Terraform 0.12로 테라폼 코드 업그레이드하기

지난 5월 Terraform 0.12가 공개됐다. Terraform 0.12는 HCL 문법이 개선되고 많은 부분이 개선되어서 나오기 전부터 많이 기다리고 있던 버전이다. 가장 크게는 값에 변수를 사용할 때 "${var.example}"처럼 String Interpolation 쓰듯이 써줘야 하는 부분이 그냥 var.example로 쓸 수 있게 되었다. "${var.example}"으로 쓰던게 익숙해 져서 지금은 괜찮은데 처음 Terraform 쓸 때는 왜 문법이 이런가 생각했던 기억이 난다. 0.12의 새 기능은 테라폼 0.12 베타 1 출시 및 개선된 HCL 문법 살펴보기에 잘 정리되어 있다.

리소스가 많진 않지만, 개인적으로 사용하는 AWS 인프라도 Terraform으로 관리하고 있는데 0.11을 계속 쓰고 있었다가 이번에 0.12로 업그레이드 하는 작업을 진행했다. 리소스가 많지 않아서 회사 프로젝트에 비할 바는 아니지만, 코드와 상태 간에 어긋난 부분이 없다면 업그레이드는 어렵지 않게 할 수 있을 것으로 보인다.

Terraform 0.12 업그레이드 사전 점검

Upgrading to Terraform v0.12 문서에 업그레이드 방법이 잘 나와 있다. 업그레이드가 가능한지 점검해 보고 업그레이드를 진행하려면 Terraform 0.11.14+와 Terraform 0.12.x가 모두 필요하다. 나 같은 경우는 Terraform CLI를 최신 버전인 0.12.x로 올리고 terraform 명령어로 사용할 수 있게 해두고 0.11.14+ 버전은 terraform11 명령어로 사용할 수 있게 설치해 두었다.(이 글에서도 terraform11라고 된 부분은 0.11.14+ 버전을 의미한다.)

Terraform 0.11.14부터 terraform 0.12checklist라는 명령어가 추가되었다. 이 명령어를 사용하면 현재 프로젝트를 Terraform의 업그레이드 명령어로 업그레이드 할 수 있는지가 나온다.

$ terraform11 0.12checklist
Looks good! We did not detect any problems that ought to be
addressed before upgrading to Terraform v0.12.

This tool is not perfect though, so please check the v0.12 upgrade
guide for additional guidance, and for next steps:
    https://www.terraform.io/upgrade-guides/0-12.html

업그레이드 전에 작업이 필요한 경우에는 아래와 같이 안내가 나온다.

$ terraform11 0.12checklist
After analyzing this configuration and working directory, we have identified some necessary steps that we recommend you take before upgrading to Terraform v0.12:

- [ ] Upgrade provider "aws" to version 2.27.0 or newer.

  No currently-installed version is compatible with Terraform 0.12. To upgrade, set the version constraint for this provider as follows and then run `terraform init`:

      version = "~> 2.27.0"

Taking these steps before upgrading to Terraform v0.12 will simplify the upgrade process by avoiding syntax errors and other compatibility problems.

이는 사용 중인 AWS 프로바이더가 버전이 맞지 않으니 0.12를 지원하는 버전을 지정한 다음 terraform init을 실행하라는 의미이다. 안내대로 진행한 다음에 다시 실행하면 업그레이드가 가능하다고 나온다.

Terraform 0.12 업그레이드

Terraform 0.12에는 0.12upgrade라는 명령어가 있어서 이를 사용하면 코드를 0.12에 맞게 바꾸어준다. 한꺼번에 변환해주기 때문에 버전을 올릴 때 노가다 작업을 줄이고 쉽게 올릴 수 있다.

$ terraform 0.12upgrade

This command will rewrite the configuration files in the given directory so
that they use the new syntax features from Terraform v0.12, and will identify
any constructs that may need to be adjusted for correct operation with
Terraform v0.12.

We recommend using this command in a clean version control work tree, so that
you can easily see the proposed changes as a diff against the latest commit.
If you have uncommited changes already present, we recommend aborting this
command and dealing with them before running this command again.

Would you like to upgrade the module in the current directory?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes

-----------------------------------------------------------------------------

Upgrade complete!

The configuration files were upgraded successfully. Use your version control
system to review the proposed changes, make any necessary adjustments, and
then commit.

yes를 입력하면 코드 변경이 진행된다. Git 등으로 형상 관리를 하고 있다면 여기서는 코드만 변경한 것이므로 변경이 잘못되었다고 생각하면 코드를 되돌리면 될 일이다. 이상이 없으면 terraform plan을 실행해서 문제가 없는지 확인하면 되고 AWS 프로바이더의 버전이 올라가면서 일부 속성의 기본값이 바뀌거나 하는 부분만 확인해보고 필요하다면 terraform apply하면 된다. 업그레이드를 진행하면 versions.tf 파일이 자동으로 생기며 terraform 블록에서 필수 버전을 0.12 이상으로 지정된다. 어차피 0.11에서는 아예 0.12의 tf 파일을 제대로 읽지 못하므로 버전 강제를 추가하는 것으로 보인다. 나 같은 경우는 필요 없게 느껴져서(혼자 사용하니까) 형상 관리에 추가하진 않았다.

업그레이드는 대부분 이상 없이 되었는데 모듈 쪽에서는 문제를 약간 겪었다. Terraform 모듈이 정의된 디렉터리에서는 실제 인프라와 연결되지 않기 때문에 프로바이더 정보 같은 것이 없고 실제 인프라와의 연결은 해당 모듈을 가져다 사용하는 쪽이다. 처음에는 이를 모르고 모듈 쪽 디렉터리에서 업그레이드를 시도했더니 다음과 같은 오류가 났다.

$ terraform 0.12upgrade

...

Would you like to upgrade the module in the current directory?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes

-----------------------------------------------------------------------------

Error: error resolving providers:

- provider.aws: no suitable version installed
  version requirements: "(any version)"
  versions installed: none

이는 모듈을 가져다 쓰는 곳에서, 즉 프로바이더가 정의된 곳에서 해당 모듈의 경로를 지정해서 업그레이드를 진행하면 된다.

$ terraform 0.12upgrade ../modules/vpc

...

Would you like to upgrade the module in ../modules/vpc?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes

-----------------------------------------------------------------------------

Upgrade complete!

The configuration files were upgraded successfully. Use your version control
system to review the proposed changes, make any necessary adjustments, and
then commit.


변경된 코드

개인 인프라의 소소한 리소스에서 0.12로 업그레이드 하면서 고친 부분을 정리했다.

  • 퍼스트 클래스 표현식이 도입되어 표현식에서 "${}"부분이 제거되었다.

    • "${var.priority}" -> var.priority
  • 원격 상태 참조에서 출력값에 outputs 속성이 추가되어 값을 가져올 때 outputs 부분을 추가했다.
  • "${data.terraform_remote_state.global.logs}" -> data.terraform_remote_state.global.outputs.logs
  • 이전 버전까지는 맵 속성(map attribute) 즉, 리소스에서 key = {}로 정의하는 형태와 중첩 블록 즉, 리소스 내에서 다른 리소스를 정의하는 key {}형태를 상호 교환해서 쓸 수도 있어서 구분이 모호했지만 0.12에서는 둘의 구분이 명확해졌다. 본문에서 키를 사용자가 임의로 쓸 수 있으면 =를 써야 하는 맵 속성이고 키가 미리 정해져 있으면 =없이 써야하는 중첩 블록이다. 이 부분을 규칙에 맞게 고쳐준다.

    • config { } -> config = { }
    • tags { } -> tags = { }
  • 리스트 변수도 []로 감싸줘야 하던 부분이 개선되어 문법에 맞게 리스트를 고쳐야 한다.(아마 이 부분은 0.12upgrade 명령어가 자동으로 고쳐주지 못하고(안의 값이 뭔지 모르므로...) 오류가 나서 직접 고쳤던 것 같다.)
    ["${module.side_effect_vpc.availability_zones}"] -> module.side_effect_vpc.availability_zones
2019/09/18 03:53 2019/09/18 03:53

기술 뉴스 #134 : 19-09-15

웹개발 관련

  • CSRF is (really) dead : CSRF(Cross-Site Request Forgery) 공격을 막으려고 폼에 임의의 랜덤 토큰을 사용하는 CSRF를 대신 SameSite 쿠키를 사용하면 된다는 글이다. 쿠키에 SameSite=Lax를 지정하면 브라우저가 CSRF 공격을 차단해 주기 때문에 서버에서 CSRF 설정을 할 필요가 없는데 Chrome 78부터는 이 값이 기본이 된다. SameSite에 대해서는 Cross-Site Request Forgery is dead!에 더 자세히 나와 있는데 SameSite=Strict로 지정하면 새로 여는 탭이나 링크를 따라갈 때도 브라우저가 모든 쿠키를 보내지 않아서 안전한 대신 로그인 등이 풀리는 문제가 있고 SameSite=Lax로 지정하면 GET, HEAD, OPTIONS, TRACE 같은 안전한 HTTP 메소드에서만 쿠키를 보내기 때문에 위험한 POST에서의 CSRF 공격을 막을 수 있다.(영어)
  • Babel, Mocha, Karma and Webpack with coverage in order : JavaScript 환경에서 번들링하는 Webpack과 트랜스파일하는 Babel에 테스트 프레임워크인 mocha와 이를 브라우저에서 실행하는 Karma의 각 역할과 연동하는 방법을 설명하는 글이다. 이를 다 조합해서 Istanbul로 커버리지를 측정하는 방법까지 설명하고 있다. JavaScript 환경이 특히 많은 도구로 처음 사용할 때 어려움을 겪는 경우가 많은데 각 도구의 목적과 연동 방법이 잘 설명된 글이다.(한국어)
  • How to learn D3.js : D3.js를 모듈별로 나누어서 어떻게 사용하는지 설명하는 글이다. 각 모듈의 크기를 시각적으로 보여주면서 중요한 부분부터 사용하는 방법을 차근차근 알려주어서 이해하기 좋다.(영어)
  • Google feedback on TypeScript 3.5 : Google에서 TypeScript로 작성된 코드를 3.5로 올리면서 겪은 문제를 정리한 이슈다. 기존에도 버전을 올릴 때 약간의 작업이 필요하다는 것을 알고 있었지만, 제너릭의 암묵적인 기본값, filter(Boolean), Set에서 특히 어려움이 있었기 때문에 차후 TypeScript 작업에 참고해 달라며 상세한 피드백을 올렸다.(영어)
  • Caniuse and MDN compatibility data collaboration : MDN의 브라우저 호환성 데이터와 Can I use의 데이터를 합쳐서 보여주기로 했다. Can I use는 10년 이상 되었고 MDN에서는 2년 전부터 브라우저 호환성 데이터를 모으기로 해서 10,000개 이상의 데이터 포인트를 가지게 되었지만 이제 둘의 데이터를 합쳐서 Can I Use에서 만개 이상의 데이터로 호환성 정보를 보여줄 수 있게 되었다.(영어)

그 밖의 개발 관련

  • 코드 리뷰 개발자 가이드 : Google에서 공개한 Code Review Developer Guide를 번역한 문서이다. 개발 조직내에서 코드리뷰를 어떻게 진행하는 게 좋고 리뷰할 때는 어떤 부분을 중점적으로 보고 리뷰의 속도는 왜 중요한지, 리뷰할 때 예의를 지키려면 어떻게 하는지 등 실용적인 얘기가 많아서 찬찬히 읽어보면 좋다.(한국어)
  • 병아리 개발자의 걸음마 한 발짝 (feat. 파일럿 프로젝트) : 우아한 형제들에 신입으로 들어가서 파일럿 프로젝트를 진행하면서 주 차별로 피드백 받은 내용을 정리한 글이다. 기능을 구현한 뒤에 리뷰를 받고 뭐가 문제였고 어떻게 수정했는지도 잘 나와 있고 팀의 다른 분들에게 피드백을 받으면서 하나씩 알아가는 과정이 잘 나와 있어서 재미있는 글이다.(한국어)
  • Running GitHub on Rails 6.0 : GitHub에서 Rails 6.0이 나오고 1.5주 만에 GitHub 내의 모든 트래픽이 Rails 6.0의 코드가 받도록 프로덕션 배포하면서 사용자에게 영향은 전혀 없었다고 한다. 6.0에서는 100개의 Pull Request를 올렸을 정도로 Rails 개발에 적극적으로 참여하고 있었고 기존 Rails 5.2 코드에서 작업하면서 6.0을 기다리는 것이 아니라 최신 Rails 코드를 매번 가져와서 5.2와 최신 코드 모두에서 빌드해서 문제를 미리 발견하고 기여할 수 있었다고 한다.(영어)
  • Announcing the Curl Cookbook : curl의 사용법을 다룬 쿡북으로 POST 요청, 쿠키 설정, UA 변경 등을 다루고 있다.(영어)
  • GitHub Pages builds now use the Checks API : GitHub에서 정적 페이지를 운영할 수 있는 Pages 기능이 Checks API를 사용하도록 개선되었다. 덕분에 이전에는 오류가 났을 때 오류가 난 이유를 찾기가 어려웠지만, 이제는 왜 오류가 났는지 상세 내용을 확인할 수 있게 되었다.(영어)

인프라 관련

  • Announcing Maesh, a Lightweight and Simpler Service Mesh Made by the Traefik Team : Traefik 팀에서 Kubernetes 클러스터에서 사용할 수 있는 서비스 메쉬인 Maesh를 공개했다. Traefik 위에 만들어져서 Traefik의 기능을 모두 쓸 수 있고 비침투적이라 설정한 팟에만 연결할 수 있고 HTTP/TCP 두 가지 모두를 사용할 수 있다.(영어)
  • Helm 3: Fun With the New Beta : 베타버전이 나온 Helm 3에서 어떤 부분이 달라졌는지 설명하는 글이다. 일단 서버 역할을 하던 Tiller가 사라지고 정보를 네임스페이스의 Secret에 저장해서 설치나 사용이 훨씬 간단해졌고 Lua 템플릿 대신 Go 템플릿이 사용할 예정이고 나중에 하위 호환성을 위해서 Lua 템플릿도 지원할 예정이지만 3.0에서는 Lua 템플릿을 지원하지 않을 예정이다.(영어)

볼만한 링크

  • DevOps didn’t exist when I started as a developer: How this one principle changed my career : 1994년부터 개발자로 일한 자신의 경험을 바탕으로 DevOps가 무엇인지 설명하는 글이다. 아주 과거에는 릴리스 프로세스가 아주 느렸고 Agile이 도입되면서 릴리스 프로세스가 빨라지기 시작했지만, 개발팀과 운영팀의 이해 차이로 문제가 되기 시작했고 이 간극을 줄이기 위해서 노력해온 결과 두 팀이 서로 간의 프로세스를 공유하면서 이를 해결해 나갔다고 하고 있다. 나중에 DevOps라는 말을 알게 되었지만, 이 과정이 DevOps라고 생각하고 CI/CD, 직책, 자동화가 DevOps가 아니라 개념이나 마인드셋, 컬쳐, 공유 등이 DevOps라고 설명하고 있다.(영어)
  • 영국 정부의 디지털 서비스 설계 10대 원칙 : 영국 정부의 디지털 서비스 설계 원칙인데 스타트업에서 참고해도 좋을 만큼 원칙이 잘 정리되어 있는 데다가 한국 정부 디지털 서비스의 품질은 아주 안 좋기 때문에 더욱 크게 와닿는다. "사용자에게 필요한 것에서 시작하라", "정부만 할 수 있는 것에 집중하라", "다양한 사용자를 감안하여 설계하라" 등 핵심 원칙과 그에 대한 설명이 요약되어 있다.(한국어)
  • 2019 kakaomobility Report : 카카오모빌리티에서 서비스 사용 데이터를 분석한 리포트를 발행했다. 이 데이터에는 음주단속 강화로 인한 오전 시간대 대리기사의 호출 증가, T 바이크로 평균 2km 정도를 이동, 다양화된 택시 서비스의 증가, 제주도의 인기 방문지 분석 등의 내용이 담겨있다. 전문이 담긴 PDF를 154페이지 분량이다.(한국어)

IT 업계 뉴스

프로젝트

  • Can I email : Can I use처럼 이메일 클라이언트가 지원하는 HTML, CSS 속성 등을 검색할 수 있는 서비스.
  • Leon Sans : 동적으로 폰트의 웨이트를 바꿀 수 있고 애니메이션을 추가할 수 있는 폰트.
  • Recursive Mono & Sans : 코딩과 UI에 맞춰져서 나온 폰트.
  • Kuma : Kong에서 만든 Envoy에 기반을 둔 서비스 메쉬.

버전 업데이트

2019/09/15 23:49 2019/09/15 23:49