작성한 질문수 7

2

옙 맞습니다~ 중앙관리와 중복으로 반복되는 코드를 관리하기 위함입니다.

특히 예를 들자면 과거에는 terraform 0.X 시절에는 상위/하위 호환이 완전히 되지 않았습니다.

그래서 어느 누군가가 0.0.1 버전만 올리고 apply 를 한다면, 모든 사람이 업그레이드를 해야하고,

모든 파일의 해당 버전 부분을 고쳤어야 했습니다~

그런식으로 관리 편의성으로 이런식으로 만들었습니다. 물론, 과거부터 사용한 코드이기 때문에,

지금은 local variable을 비슷한 방식으로 사용한다거나, tag 같이 hard-coded 한 작업을 더 효율화 할 수 있는 여지는 있습니다~

2

제 짧은 식견으로 답변드리자면, chad님의 추론이 맞다고 봅니다.

같은 계정 내의 리소스를 다른 리소스가 활용할 때는 outputs과 remote_state를 활용해서 재사용을 할 수 있지만 다른 계정일 경우에는 ARN을 참조해서 사용해야할 경우가 생깁니다. 매번 ARN을 콘솔 또는 CLI를 통해 확인하는 것은 매우 비효율적이므로 resource 생성한 후 반복적으로 활용할 것으로 예상되는 ARN 또는 특정 값은 global 변수로 중앙 관리하는 것이 효율적입니다.

또한 제 짧은 식견으로 sg, route53, lb, global과 같이 var_*로 분리한 이유를 추론해보자면 다음과 같습니다.

첫 번 째, 하나의 파일로 변수를 관리할 경우 해당 파일의 크기가 너무 커져 가독성이 떨어집니다. 수십개가 아닌 수백, 수천, 수십만개의 리소스를 관리한다고 가정하였을 때를 고려하고 디렉토리 및 파일 구조를 설계하는 것이 바람직하다고 봅니다.

두 번 째, 만약 Atlantis(https://www.runatlantis.io/)와 같은 Pull Request를 통해 Terraform 워크플로우를 자동화할 수 있는 오픈소스 셀프호스팅 도구를 사용할 경우에 불필요한 Plan을 하지 않도록 하기 위함입니다.
가령, var_lb.tf, var_route53 와 같이 분리된 변수 파일이 아닌 variables.tf를 Atlantis가 추적하도록 설정했다고 가정해봅시다. 해당 변수 파일을 모든 resource에서 참조하고 있고, LB와 관련된 변수를 변경하였을 경우에도 route53, sg 등 그외의 resource들에 대해 의도하지 않은 terraform plan 커맨드가 실행됩니다.

처음부터 고려하기엔 힘들 수 있습니다만, 많은 리소스를 구축, 운영/관리한다고 가정하고 설계하는 습관을 들인다면 어떻게 해야 효율적으로 관리포인트를 줄일지 설계할 수 있는 역량을 기를 수 있을 것입니다.



답변이 도움이 되시길 바랍니다!

저도 초/중급자이니 함께 공부해나가요!!! 🙂

1

병찬님, 의견 감사합니다. 많은 도움이 되었습니다!
주영님, 답변 감사합니다~ 과거 이야기까지 들을 수 있어서 너무 유익하네요!..

금요일 잘 마무리하시고 두 분 다 즐거운 주말 되세요~