Terraform에서 CloudFormation으로 전환하고 후회함

인프라를 반복 가능한 텍스트 형식의 코드로 표현하는 것은 쥐를 조작할 필요가 없는 시스템을 위한 간단한 모범 사례입니다. 이 관행에는 이름이 있습니다. 코드로서의 인프라, 그리고 지금까지 특히 AWS에서 이를 구현하는 데 널리 사용되는 두 가지 도구가 있습니다. 테라 폼 и 클라우드 포메이션.

Terraform 및 CloudFormation 경험 비교

오기 전에 씰룩 씰룩 움직이다 (일명 아마존 주니어) 나는 일했다 한 스타트업에서 Terraform을 XNUMX년 동안 사용했습니다. 새로운 곳에서도 저는 Terraform을 온 힘을 다해 사용했고 회사는 CloudFormation을 포함하여 Amazon과 같은 모든 것으로 전환을 추진했습니다. 저는 두 가지 모두에 대한 모범 사례를 부지런히 개발했으며 매우 복잡한 조직 전반의 워크플로에서 두 도구를 모두 사용해 왔습니다. 나중에 Terraform에서 CloudFormation으로의 마이그레이션이 미치는 영향을 신중하게 평가한 후 Terraform이 아마도 조직을 위한 최선의 선택일 것이라고 확신하게 되었습니다.

테라폼 끔찍한

베타 소프트웨어

Terraform은 아직 버전 1.0도 출시하지 않았으므로 사용하지 않는 것이 좋습니다. 처음 제가 직접 해봤을 때와 많이 달라졌는데, 그때는 terraform apply 여러 번의 업데이트 후에 또는 몇 년 동안 사용한 후에 고장이 나는 경우가 많습니다. 지금은 모든 것이 달라졌다고 말하고 싶지만... 다들 그렇게 말하는 것 같죠? 적절하기는 하지만 이전 버전과 호환되지 않는 변경 사항이 있으며 심지어 리소스 저장소의 구문과 추상화가 이제 우리에게 필요한 것처럼 느껴집니다. 악기가 정말 좋아진 것 같긴 한데... :-0

반면에 AWS는 이전 버전과의 호환성을 잘 유지해 왔습니다. 이는 아마도 해당 서비스가 조직 내에서 철저하게 테스트된 다음 이름이 변경되어 게시되는 경우가 많기 때문일 것입니다. 그래서 “그들은 열심히 노력했다”는 말은 절제된 표현입니다. AWS만큼 다양하고 복잡한 시스템에서 API와의 하위 호환성을 유지하는 것은 엄청나게 어렵습니다. 널리 사용되는 공용 API를 유지 관리해야 했던 사람이라면 오랜 세월 동안 그렇게 하는 것이 얼마나 어려운지 이해해야 합니다. 하지만 제 기억으로는 CloudFormation의 동작은 수년이 지나도 한 번도 변하지 않았습니다.

다리를 만나... 총알이야

내가 아는 한 리소스를 삭제하세요. 문외한 CF 스택의 CloudFormation 스택은 불가능합니다. Terraform에서도 마찬가지입니다. 기존 리소스를 스택으로 가져올 수 있습니다. 기능은 훌륭하다고 할 수 있지만 큰 힘에는 큰 책임이 따른다. 스택에 리소스를 추가하기만 하면 되며, 스택 작업 중에는 이 리소스를 삭제하거나 변경할 수 없습니다. 어느 날 그것은 역효과를 냈습니다. 어느 날 Twitch에서 누군가가 아무런 장난도 하지 않은 채 실수로 다른 사람의 AWS 보안 그룹을 자신의 Terraform 스택으로 가져왔습니다. 여러 명령을 입력했는데... 보안 그룹(수신 트래픽과 함께)이 사라졌습니다.

테라폼 그레이트

불완전한 상태에서 복구

때때로 CloudFormation이 한 상태에서 다른 상태로 완전히 전환되지 못하는 경우가 있습니다. 동시에 그는 이전 상태로 돌아가려고 노력할 것입니다. 이것이 항상 가능하지는 않다는 것이 유감입니다. 나중에 발생한 일을 디버깅하는 것은 상당히 무서울 수 있습니다. CloudFormation이 해킹당했다는 사실을 기뻐할지 여부는 알 수 없습니다. 단지 문제를 해결하기 위해서라도 마찬가지입니다. 이전 상태로 돌아갈 수 있는지 여부는 실제로 결정하는 방법을 모르고 기본적으로 몇 시간 동안 기적을 기다리며 매달립니다.

반면에 Terraform은 실패한 전환을 훨씬 더 적절하게 복구하는 경향이 있으며 고급 디버깅 도구를 제공합니다.

문서 상태에 대한 더 명확한 변경 사항

“좋아요, 로드 밸런서가 바뀌고 있어요. 그런데 어떻게요?"

—'수락' 버튼을 누를 준비가 된 불안한 엔지니어.

때로는 포트 번호 추가, 보안 그룹 변경 등 CloudFormation 스택의 로드 밸런서를 조작해야 하는 경우도 있습니다. ClouFormation은 변경 내용을 제대로 표시하지 않습니다. 나는 필요한 것을 지우지 않았는지 불필요한 것을 추가하지 않았는지 확인하기 위해 yaml 파일을 XNUMX번 다시 확인합니다.

이와 관련하여 Terraform은 훨씬 더 투명합니다. 때때로 그는 너무 투명하기도 합니다(읽기: 지루함). 다행히 최신 버전에는 개선된 변경 사항 표시 기능이 포함되어 있어 이제 변경 사항을 정확히 확인할 수 있습니다.

유연성

소프트웨어를 거꾸로 작성하세요.

직설적으로 말하면, 수명이 긴 소프트웨어의 가장 중요한 특징은 변화에 적응하는 능력입니다. 소프트웨어를 거꾸로 작성하십시오. 대부분의 경우 "간단한" 서비스를 사용하고 모든 것을 단일 CloudFormation 또는 Terraform 스택에 집어넣기 시작하여 실수를 저질렀습니다. 그리고 물론, 몇 달 후에 제가 모든 것을 잘못 이해했다는 사실이 드러났고, 실제로 서비스도 간단하지 않았습니다! 이제 어떻게든 큰 스택을 작은 구성 요소로 나누어야 합니다. CloudFormation으로 작업할 때 먼저 기존 스택을 다시 생성해야만 이 작업을 수행할 수 있으며, 저는 데이터베이스에서는 이 작업을 수행하지 않습니다. 반면에 Terraform을 사용하면 스택을 분해하고 더 이해하기 쉬운 작은 부분으로 나눌 수 있습니다.

Git의 모듈

여러 스택에서 Terraform 코드를 공유하는 것은 CloudFormation 코드를 공유하는 것보다 훨씬 쉽습니다. Terraform을 사용하면 코드를 git 저장소에 배치하고 의미 체계 버전 제어를 사용하여 코드에 액세스할 수 있습니다. 이 저장소에 액세스할 수 있는 사람은 누구나 공유 코드를 재사용할 수 있습니다. CloudFormation과 동등한 것은 S3이지만 동일한 이점이 없으며 S3를 위해 git을 포기해야 할 이유가 전혀 없습니다.

조직은 성장했고 공통 스택을 공유하는 능력은 중요한 수준에 도달했습니다. Terraform을 사용하면 이 모든 것이 쉽고 자연스러워지는 반면, CloudFormation을 사용하면 이와 같은 작업을 수행하기 전에 어려움을 겪을 수 있습니다.

코드로서의 작업

"대본을 쓰자. 알았어."

—Terraform 자전거를 발명하기 3년 전 엔지니어였습니다.

소프트웨어 개발에 있어 Go나 Java 프로그램은 단순한 코드가 아닙니다.

코드로서의 코드

그것이 작동하는 인프라도 있습니다.

코드로서의 인프라

그런데 그 사람은 어디서 왔나요? 어떻게 모니터링하나요? 귀하의 코드는 어디에 있습니까? 개발자에게 접근 권한이 필요한가요?

코드로서의 작업

소프트웨어 개발자가 된다는 것은 단순히 코드를 작성하는 것을 의미하지 않습니다.

AWS만이 유일한 것은 아닙니다. 아마도 다른 공급자를 이용할 수도 있습니다. SignalFx, PagerDuty 또는 Github. CI/CD용 내부 Jenkins 서버가 있거나 모니터링용 내부 Grafana 대시보드가 ​​있을 수 있습니다. Infra as Code는 다양한 이유로 선택되었으며 각각은 소프트웨어와 관련된 모든 것에 똑같이 중요합니다.

제가 Twitch에서 일할 때 Amazon의 혼합 임베디드 시스템과 AWS 시스템 내에서 서비스를 가속화했습니다. 우리는 많은 마이크로서비스를 대량 생산하고 지원하여 운영 비용을 늘렸습니다. 토론은 다음과 같이 진행되었습니다.

• Я: 젠장, 하나의 마이크로서비스를 오버클럭하려면 너무 많은 동작이 필요합니다. AWS 계정을 만들려면 이 쓰레기를 사용해야 할 것입니다(우리는 2개의 계정으로 이동했습니다) 마이크로서비스), 알림 설정용, 코드 저장소용, 이메일 목록용, 그리고…
• 선두: 스크립트를 작성해 보겠습니다.
• Я: 좋습니다. 하지만 스크립트 자체가 변경됩니다. 내장된 Amazon 장치가 모두 최신 상태인지 확인하는 방법이 필요합니다.
• 선두: 좋은 것 같아요. 그리고 이에 대한 스크립트를 작성하겠습니다.
• Я: 엄청난! 그리고 스크립트는 여전히 매개변수를 설정해야 할 것입니다. 그는 그것을 받아들일까요?
• 선두: 그가 가는 곳으로 데려가도록 해주세요!
• Я: 프로세스가 변경될 수 있으며 이전 버전과의 호환성이 손실됩니다. 일종의 의미론적 버전 제어가 필요합니다.
• 선두: 좋은 생각이에요!
• Я: 도구는 사용자 인터페이스 내에서 수동으로 변경할 수 있습니다. 이를 확인하고 수정할 수 있는 방법이 필요합니다.

...3년 후:

• 선두: 그리고 우리는 테라폼을 얻었습니다.

이야기의 교훈은 다음과 같습니다. 아마존의 모든 것에서 머리를 숙이세요, 여전히 AWS가 아닌 것을 사용하고 있으며 이러한 서비스에는 구성 언어를 사용하여 해당 상태를 동기화하는 상태가 있습니다.

CloudFormation 람다와 git 모듈 terraform

람다는 사용자 지정 논리 문제에 대한 CloudFormation의 솔루션입니다. 람다를 사용하면 다음과 같은 작업을 수행할 수 있습니다. 매크로 만들기 또는 사용자 리소스. 이 접근 방식은 Terraform의 git 모듈 의미 체계 버전 관리에는 없는 추가적인 복잡성을 야기합니다. 저에게 가장 시급한 문제는 이러한 모든 사용자 람다(그리고 수십 개의 AWS 계정)에 대한 권한을 관리하는 것이었습니다. 또 다른 중요한 문제는 "닭이 먼저냐, 달걀이 먼저냐"는 문제였습니다. 이 문제는 람다 코드와 관련이 있었습니다. 이 기능 자체가 인프라이자 코드이며, 그 자체로 모니터링과 업데이트가 필요합니다. 관의 마지막 못은 람다 코드 변경 사항을 의미론적으로 업데이트하는 것이 어렵다는 점이었습니다. 또한 직접적인 명령이 없는 스택 작업이 실행 간에 변경되지 않는지 확인해야 했습니다.

클래식 로드 밸런서를 사용하여 Elastic Beanstalk 환경을 위한 카나리아 배포를 생성하고 싶었던 기억이 납니다. 가장 쉬운 방법은 프로덕션 환경 옆에 EB에 대한 두 번째 배포를 만들고 한 단계 더 나아가 자동 확장 카나리아 배포 그룹과 배포 LB를 프로덕션 환경에 결합하는 것입니다. 그리고 Terraform이 사용하기 때문에 결론적으로 ASG 빈톡, 이를 위해서는 Terraform에 4줄의 추가 코드가 필요합니다. CloudFormation에 비슷한 솔루션이 있는지 물었을 때 그들은 배포 파이프라인과 모든 것이 포함된 전체 Git 저장소를 가리켰습니다. 이 모든 것은 열악한 Terraform 코드 4줄로 수행할 수 있는 작업을 위한 것이었습니다.

드리프트를 더 잘 감지합니다.

현실이 기대와 일치하는지 확인하세요.

드리프트 감지 현실이 기대와 일치하는지 확인하는 데 도움이 되기 때문에 코드 기능으로서의 매우 강력한 작업입니다. CloudFormation과 Terraform 모두에서 사용할 수 있습니다. 그러나 프로덕션 스택이 성장함에 따라 CloudFormation에서 드리프트를 검색하면 잘못된 감지가 점점 더 많이 발생했습니다.

Terraform을 사용하면 드리프트 감지를 위한 훨씬 더 발전된 수명 주기 후크를 사용할 수 있습니다. 예를 들어 다음 명령을 입력합니다. 무시_변경 전체 ECS 배포에 대한 변경 사항을 무시하지 않고 특정 작업 정의에 대한 변경 사항을 무시하려는 경우 ECS 작업 정의에서 직접.

CDK와 CloudFormation의 미래

CloudFormation은 대규모 인프라 간 규모에서 관리하기 어렵습니다. 이러한 어려움 중 많은 부분이 인식되고 도구에는 다음과 같은 것이 필요합니다. aws-cdk, 코드로 클라우드 인프라를 정의하고 AWS CloudFormation을 통해 실행하기 위한 프레임워크입니다. aws-cdk의 미래가 어떻게 될지 지켜보는 것은 흥미로울 것이지만 Terraform의 다른 강점과 경쟁하는 데 어려움을 겪을 것입니다. CloudFormation을 최신 상태로 유지하려면 전역 변경이 필요합니다.

Terraform이 실망하지 않도록

이것은 "텍스트"가 아닌 "코드로서의 인프라"입니다.

Terraform에 대한 나의 첫인상은 다소 나빴습니다. 나는 접근 방식을 이해하지 못했다고 생각합니다. 거의 모든 엔지니어는 이를 원하는 인프라로 변환해야 하는 텍스트 형식으로 무의식적으로 인식합니다. 이런 식으로 하지 마십시오.

좋은 소프트웨어 개발의 원칙은 Terraform에도 적용됩니다.

좋은 코드를 만들기 위해 채택된 많은 관행이 Terraform에서 무시되는 것을 보았습니다. 당신은 좋은 프로그래머가 되기 위해 수년간 공부했습니다. 단지 Terraform으로 작업하고 있다는 이유만으로 이 경험을 포기하지 마세요. 좋은 소프트웨어 개발의 원칙은 Terraform에도 적용됩니다.

코드를 어떻게 문서화할 수 없나요?

문서가 전혀 없는 거대한 Terraform 스택을 본 적이 있습니다. 문서가 전혀 없이 어떻게 페이지 단위로 코드를 작성할 수 있습니까? 설명하는 문서를 추가하세요. 암호 Terraform('코드'라는 단어 강조), 이 섹션이 중요한 이유 및 수행하는 작업

한때 하나의 큰 main() 기능이었던 서비스를 어떻게 배포할 수 있습니까?

저는 매우 복잡한 Terraform 스택이 단일 모듈로 제공되는 것을 보았습니다. 이런 방식으로 소프트웨어를 배포하면 어떨까요? 왜 큰 기능을 더 작은 기능으로 분할합니까? Terraform에도 동일한 답변이 적용됩니다. 모듈이 너무 크면 더 작은 모듈로 나누어야 합니다.

당신의 회사는 도서관을 사용하지 않습니까?

나는 엔지니어들이 Terraform을 사용하여 새 프로젝트를 시작하고 어리석게도 다른 프로젝트의 거대한 덩어리를 자신의 프로젝트에 복사하여 붙여 넣은 다음 작업이 시작될 때까지 수정하는 방법을 보았습니다. 당신의 회사에서는 "전투" 코드로 이런 일을 하시겠습니까? 우리는 도서관만 사용하는 것이 아닙니다. 예, 모든 것이 도서관일 필요는 없습니다. 하지만 원칙적으로 공유 라이브러리가 없다면 우리는 어디에 있습니까?!

PEP8이나 gofmt를 사용하고 있지 않습니까?

대부분의 언어에는 허용되는 표준 형식 체계가 있습니다. Python에서는 PEP8입니다. In Go - gofmt. Terraform에는 다음과 같은 고유한 기능이 있습니다. terraform fmt. 건강을 위해 즐겨보세요!

JavaScript를 모르고 React를 사용하시겠습니까?

Terraform 모듈은 생성하는 복잡한 인프라의 일부를 단순화할 수 있지만 이것이 전혀 다룰 수 없다는 의미는 아닙니다. 리소스를 이해하지 않고도 Terraform을 올바르게 사용하고 싶으십니까? 당신은 운명을 정했습니다. 시간은 흐르고 결코 Terraform을 마스터하지 못할 것입니다.

싱글톤이나 종속성 주입을 사용하여 코딩하고 있나요?

종속성 주입은 소프트웨어 개발에서 인정받는 모범 사례이며 싱글톤보다 선호됩니다. 이것이 Terraform에서 어떻게 유용합니까? 원격 상태에 의존하는 Terraform 모듈을 본 적이 있습니다. 원격 상태를 검색하는 모듈을 작성하는 대신 매개변수를 사용하는 모듈을 작성하세요. 그런 다음 이 매개변수를 모듈에 전달합니다.

귀하의 도서관은 열 가지 일을 잘 수행합니까, 아니면 한 가지 훌륭한 일을 수행합니까?

가장 잘 작동하는 라이브러리는 자신이 매우 잘 수행하는 하나의 작업에 집중하는 라이브러리입니다. 모든 것을 한 번에 수행하려고 하는 대규모 Terraform 모듈을 작성하는 대신 한 가지 작업을 잘 수행하는 부분을 빌드하세요. 그런 다음 필요에 따라 결합하십시오.

이전 버전과의 호환성 없이 어떻게 라이브러리를 변경합니까?

일반 라이브러리와 같은 일반적인 Terraform 모듈은 이전 버전과 호환되지 않으면서 어떻게든 사용자에게 변경 사항을 전달해야 합니다. 라이브러리에서 이러한 변경이 발생할 때 성가신 일이며, Terraform 모듈에서 이전 버전과 호환되지 않는 변경이 이루어질 때도 마찬가지로 성가신 일입니다. Terraform 모듈을 사용할 때는 git 태그와 semver를 사용하는 것이 좋습니다.

귀하의 프로덕션 서비스가 노트북에서 실행되고 있습니까, 아니면 데이터 센터에서 실행되고 있습니까?

Hashicorp에는 다음과 같은 도구가 있습니다. 테라폼 클라우드 테라폼을 실행합니다. 이러한 중앙 집중식 서비스를 사용하면 Terraform 변경 사항을 쉽게 관리, 감사, 승인할 수 있습니다.

테스트를 작성하지 않습니까?

엔지니어는 코드를 테스트해야 한다는 것을 인식하지만 Terraform으로 작업할 때 테스트를 잊어버리는 경우가 많습니다. 인프라의 경우 이는 위험한 순간으로 가득 차 있습니다. 제가 조언하는 것은 CI/CD 중에 테스트를 위해 올바르게 배포할 수 있는 모듈을 사용하여 스택을 "테스트"하거나 "예제 생성"하라는 것입니다.

Terraform 및 마이크로서비스

마이크로서비스 기업의 생사는 새로운 마이크로서비스 워크스택의 속도, 혁신, 중단에 달려 있습니다.

마이크로서비스 아키텍처와 관련되어 제거할 수 없는 가장 일반적인 부정적인 측면은 코드가 아닌 작업과 관련이 있습니다. Terraform을 마이크로서비스 아키텍처의 인프라 측면만 자동화하는 방법으로만 생각한다면 시스템의 진정한 이점을 놓치고 있는 것입니다. 이제는 이미 모든 것이 코드와 같아.

출처 : habr.com