미래를 위한 Terraform의 인프라에 대한 설명입니다. 안톤 바벤코 (2018)

많은 사람들이 일상 업무에서 Terraform을 알고 사용하고 있지만 이에 대한 모범 사례는 아직 형성되지 않았습니다. 각 팀은 고유한 접근 방식과 방법을 고안해야 합니다.

귀하의 인프라는 거의 확실하게 몇 가지 리소스 + 몇 명의 개발자로 간단하게 시작됩니다. 시간이 지남에 따라 모든 방향으로 성장합니다. 리소스를 Terraform 모듈로 그룹화하고, 코드를 폴더로 구성하는 방법 등 무엇이 잘못될 수 있는지 찾으십니까? (유명한 마지막 말)

시간이 흐르고 인프라가 새로운 애완동물처럼 느껴지지만, 그 이유는 무엇입니까? 인프라의 설명할 수 없는 변화에 대해 걱정하고, 인프라와 코드를 건드리는 것을 두려워합니다. 결과적으로 새로운 기능이 지연되거나 품질이 저하됩니다...

XNUMX년 동안 Github에서 AWS용 Terraform 커뮤니티 모듈 모음을 관리하고 프로덕션에서 Terraform을 장기적으로 유지 관리한 후 Anton Babenko는 자신의 경험을 공유할 준비가 되었습니다. 미래에 문제가 되지 않도록 TF 모듈을 작성하는 방법입니다.

강연이 끝나면 참가자들은 Terraform의 리소스 관리 원칙, Terraform의 모듈과 관련된 모범 사례, 인프라 관리와 관련된 몇 가지 지속적인 통합 원칙에 더 익숙해질 것입니다.

부인 성명: 이 보고서의 날짜는 2018년 2월로, 벌써 0.11년이 지났습니다. 보고서에서 논의된 Terraform 2 버전은 더 이상 지원되지 않습니다. 지난 2년 동안 많은 혁신, 개선 및 변경 사항이 포함된 XNUMX개의 새 릴리스가 출시되었습니다. 이에 주의하시고 문서를 확인하시기 바랍니다.

링크 :

• 테라폼 커뮤니티 모듈 + Terraform-aws-모듈
• antonbabenko/pre-commit-terraform — 자동 서식 지정 코드 및 문서
• 안톤바벤코/테라핀 — Terraform 모듈 생성기(WIP)
• antonbabenko/modules.tf-lambda — 시각적 다이어그램(WIP)의 Terraform 코드 생성기
• www.terraform-best-practices.com
• Medium.com/@anton.babenko (새 게시물은 내 개인 웹사이트 www.antonbabenko.com/에 있습니다.)
• @antonbabenko - Twitter 및 다양한 Slacks

제 이름은 안톤 바벤코입니다. 여러분 중 일부는 제가 작성한 코드를 사용했을 것입니다. 나는 통계에 접근할 수 있기 때문에 이제 그 어느 때보다 더 자신있게 이에 대해 이야기하겠습니다.

저는 Terraform에서 일하고 있으며 2015년부터 Terraform 및 Amazon과 관련된 수많은 오픈 소스 프로젝트에 적극적으로 참여하고 기여해 왔습니다.

그 이후로 나는 흥미로운 방식으로 표현하기에 충분한 코드를 작성했습니다. 그리고 나는 지금 이것에 대해 당신에게 말하려고 노력할 것입니다.

Terraform 작업의 복잡성과 세부 사항에 대해 이야기하겠습니다. 그러나 그것은 실제로 HighLoad의 주제가 아닙니다. 이제 그 이유를 이해하게 될 것입니다.

시간이 지나면서 나는 Terraform 모듈을 작성하기 시작했습니다. 사용자들이 질문을 작성했고, 제가 다시 작성했습니다. 그런 다음 사전 커밋 후크 등을 사용하여 코드 형식을 지정하는 다양한 유틸리티를 작성했습니다.

흥미로운 프로젝트가 많았습니다. 저는 컴퓨터가 저와 프로그래머를 위해 점점 더 많은 작업을 수행하는 것을 좋아하기 때문에 코드 생성을 좋아합니다. 그래서 현재 시각적 다이어그램에서 Terraform 코드 생성기를 작업하고 있습니다. 아마도 여러분 중 일부는 그것을 본 적이 있을 것입니다. 이것은 화살표가 있는 아름다운 상자입니다. 그리고 "내보내기" 버튼을 클릭해서 모두 코드로 얻을 수 있다면 정말 좋을 것 같아요.

저는 우크라이나 출신이에요. 나는 수년 동안 노르웨이에 살았습니다.

또한 본 보고서의 정보는 내 이름을 알고 소셜 네트워크에서 나를 찾아준 사람들로부터 수집되었습니다. 나는 거의 항상 같은 별명을 가지고 있습니다.

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

앞서 언급했듯이 저는 Terraform AWS 모듈의 주요 관리자입니다. 이 모듈은 가장 일반적인 작업(VPC, Autoscaling, RDS)을 위한 모듈을 호스팅하는 GitHub의 가장 큰 저장소 중 하나입니다.

그리고 지금 들은 것이 가장 기본적인 것입니다. Terraform이 무엇인지 이해하고 있는지 의심스러우면 다른 곳에서 시간을 보내는 것이 좋습니다. 여기에는 많은 기술 용어가 있을 것입니다. 그리고 나는 주저하지 않고 보고서의 수준이 최고라고 선언했습니다. 이는 많은 설명 없이도 가능한 모든 용어를 사용하여 말할 수 있다는 것을 의미합니다.

Terraform은 2014년에 인프라를 코드로 작성, 계획 및 관리할 수 있는 유틸리티로 등장했습니다. 여기서 핵심 개념은 "코드로서의 인프라"입니다.

내가 말했듯이 모든 문서는 다음과 같이 작성되었습니다. terraform.io. 대부분의 사람들이 이 사이트에 대해 알고 문서를 읽었기를 바랍니다. 그렇다면, 당신은 올바른 위치에 있습니다.

이는 먼저 몇 가지 변수를 정의하는 일반 Terraform 구성 파일의 모습입니다.

이 경우 "aws_region"을 정의합니다.

그런 다음 어떤 리소스를 만들고 싶은지 설명합니다.

종속성 및 공급자를 로드하기 위해 일부 명령, 특히 "terraform init"을 실행합니다.

그리고 지정된 구성이 우리가 생성한 리소스와 일치하는지 확인하기 위해 “terraform apply” 명령을 실행합니다. 이전에 아무것도 생성하지 않았으므로 Terraform에서는 이러한 리소스를 생성하라는 메시지를 표시합니다.

우리는 이것을 확인합니다. 따라서 우리는 seasnail이라는 버킷을 만듭니다.

유사한 유틸리티도 여러 개 있습니다. Amazon을 사용하는 많은 분들은 AWS CloudFormation이나 Google Cloud 배포 관리자 또는 Azure Resource Manager를 알고 계십니다. 각각은 퍼블릭 클라우드 제공자 내에서 리소스를 관리하기 위한 일종의 자체 구현을 가지고 있습니다. Terraform을 사용하면 100개 이상의 공급자를 관리할 수 있으므로 특히 유용합니다. (자세한 내용은 여기에)

Terraform이 처음부터 추구한 목표는 다음과 같습니다.

• Terraform은 리소스에 대한 단일 보기를 제공합니다.
• 모든 최신 플랫폼을 지원할 수 있습니다.
• 그리고 Terraform은 처음부터 인프라를 안전하고 예측 가능하게 변경할 수 있는 유틸리티로 설계되었습니다.

2014년에는 이러한 맥락에서 “예측 가능”이라는 단어가 매우 이상하게 들렸습니다.

Terraform은 범용 유틸리티입니다. API가 있으면 모든 것을 완벽하게 제어할 수 있습니다.

• 120개 이상의 제공업체를 이용하여 원하는 모든 것을 관리할 수 있습니다.
• 예를 들어 Terraform을 사용하여 GitHub 저장소에 대한 액세스를 설명할 수 있습니다.
• Jira에서 버그를 생성하고 닫을 수도 있습니다.
• New Relic 지표를 관리할 수 있습니다.
• 정말로 원한다면 드롭박스에서 파일을 생성할 수도 있습니다.

이는 모두 Go에서 설명할 수 있는 개방형 API가 있는 Terraform 공급자를 사용하여 달성됩니다.

이전 슬라이드에서 보여드린 것처럼 Terraform을 사용하기 시작했고, 사이트에서 일부 문서를 읽고, 비디오를 보고, main.tf를 작성하기 시작했다고 가정해 보겠습니다.

그리고 모든 것이 훌륭합니다. VPC를 생성하는 파일이 있습니다.

VPC를 생성하려면 대략 다음과 같은 12개 라인을 지정합니다. 생성하려는 지역과 사용할 IP 주소의 cidr_block을 설명합니다. 그게 다야.

당연히 프로젝트는 점진적으로 성장할 것입니다.

그리고 리소스, 데이터 소스, 새로운 공급자와 통합, 갑자기 Terraform을 사용하여 GitHub 계정의 사용자를 관리하려는 등 많은 새로운 항목을 추가하게 됩니다. 다른 것을 사용하고 싶을 수도 있습니다. DNS 공급자는 모든 것을 교차합니다. Terraform을 사용하면 이를 쉽게 수행할 수 있습니다.

다음 예를 살펴보겠습니다.

VPC의 리소스가 인터넷에 액세스할 수 있도록 하기 위해 internet_gateway를 점차적으로 추가합니다. 이것은 좋은 생각입니다.

결과는 다음과 같습니다.

main.tf의 상단 부분입니다.

main.tf의 하단 부분입니다.

그런 다음 서브넷을 추가합니다. NAT 게이트웨이, 경로, 라우팅 테이블 및 기타 여러 서브넷을 추가하려는 시점에는 38개 회선이 아니라 대략 200-300개 회선이 있게 됩니다.

즉, main.tf 파일이 점차 커지고 있습니다. 그리고 사람들은 모든 것을 하나의 파일에 저장하는 경우가 많습니다. 10-20Kb가 main.tf에 나타납니다. 10-20Kb가 텍스트 콘텐츠라고 상상해 보세요. 그리고 모든 것은 모든 것과 연결되어 있습니다. 점차적으로 작업하기가 어려워지고 있습니다. 10-20Kb가 좋은 사용자 사례이며 때로는 그 이상입니다. 그리고 사람들은 이것이 항상 나쁘다고 생각하지 않습니다.

코드형 인프라가 아닌 일반 프로그래밍에서와 마찬가지로 우리는 다양한 클래스, 패키지, 모듈, 그룹화를 사용하는 데 익숙합니다. Terraform을 사용하면 거의 동일한 작업을 수행할 수 있습니다.

• 코드가 늘어나고 있습니다.
• 리소스 간의 종속성도 증가하고 있습니다.

그리고 우리에게는 정말 큰 도움이 필요합니다. 우리는 더 이상 이렇게 살 수 없다는 것을 이해합니다. 우리의 코드는 거대해지고 있습니다. 물론 10-20Kb는 그다지 광대하지는 않지만 네트워크 스택에 대해서만 이야기하고 있습니다. 즉, 네트워크 리소스만 추가한 것입니다. 우리는 100Kb를 쉽게 엮을 수 있는 Application Load Balancer, 배포 ES 클러스터, Kubernetes 등에 대해 이야기하는 것이 아닙니다. 이 내용을 모두 적어 보면 Terraform이 Terraform 모듈을 제공한다는 사실을 곧 알게 될 것입니다.

Terraform 모듈은 그룹으로 관리되는 독립형 Terraform 구성입니다. 이것이 Terraform 모듈에 대해 알아야 할 전부입니다. 그들은 전혀 똑똑하지 않으며 무언가에 따라 복잡한 연결을 만드는 것을 허용하지 않습니다. 이 모든 것은 개발자의 어깨에 달려 있습니다. 즉, 이것은 이미 작성한 일종의 Terraform 구성입니다. 그리고 간단히 그룹이라고 부를 수도 있습니다.

그래서 우리는 10-20-30Kb의 코드를 어떻게 최적화할지 이해하려고 노력하고 있습니다. 우리는 일부 모듈을 사용해야 한다는 것을 점차 깨닫고 있습니다.

처음 접하는 모듈 유형은 리소스 모듈입니다. 그들은 귀하의 인프라가 무엇인지, 비즈니스가 무엇인지, 조건이 무엇인지, 어디에 있는지 이해하지 못합니다. 이것이 바로 제가 오픈 소스 커뮤니티와 함께 ​​관리하고 인프라의 초기 구성 요소로 제시하는 모듈입니다.

리소스 모듈의 예.

리소스 모듈을 호출할 때 해당 콘텐츠를 로드할 경로를 지정합니다.

다운로드하려는 버전을 나타냅니다.

우리는 거기에 많은 인수를 전달합니다. 그게 다야. 이것이 우리가 이 모듈을 사용할 때 알아야 할 전부입니다.

많은 사람들은 최신 버전을 사용하면 모든 것이 안정적일 것이라고 생각합니다. 하지만. 인프라의 버전이 지정되어야 하며, 이 구성 요소 또는 해당 구성 요소가 배포된 버전을 명확하게 대답해야 합니다.

이 모듈 내부에 있는 코드는 다음과 같습니다. 보안 그룹 모듈. 여기서 스크롤은 640번째 줄로 이동합니다. 가능한 모든 구성으로 Amazon에서 보안 그룹 리소스를 생성하는 것은 매우 간단한 작업입니다. 단순히 보안 그룹을 생성하고 여기에 전달할 규칙을 알려주는 것만으로는 충분하지 않습니다. 그것은 매우 간단할 것이다. Amazon에는 수백만 가지의 다양한 제한 사항이 있습니다. 예를 들어, 다음을 사용하는 경우 VPC 엔드포인트, 접두사 목록, 다양한 API 이 모든 것을 다른 모든 것과 결합하려고 하면 Terraform에서는 이를 허용하지 않습니다. 그리고 Amazon API도 이를 허용하지 않습니다. 따라서 우리는 이 모든 끔찍한 로직을 모듈에 숨기고 다음과 같은 사용자 코드를 제공해야 합니다.

사용자는 내부에서 어떻게 만들어지는지 알 필요가 없습니다.

리소스 모듈로 구성된 두 번째 유형의 모듈은 이미 귀하의 비즈니스에 더 적합한 문제를 해결하고 있습니다. 종종 이는 Terraform의 확장이며 회사 표준에 따라 태그에 대해 엄격한 값을 설정하는 장소입니다. Terraform에서 현재 사용을 허용하지 않는 기능을 여기에 추가할 수도 있습니다. 바로 지금입니다. 이제 버전 0.11은 곧 과거의 일이 될 것입니다. 그러나 여전히 전처리기, jsonnet, cookiecutter 및 기타 여러 가지가 본격적인 작업에 사용해야 하는 보조 메커니즘입니다.

다음에는 이에 대한 몇 가지 예를 보여 드리겠습니다.

인프라 모듈은 정확히 같은 방식으로 호출됩니다.

콘텐츠를 다운로드할 수 있는 출처가 표시됩니다.

여러 값이 전달되어 이 모듈에 전달됩니다.

다음으로 이 모듈 내에서는 VPC 또는 Application Load Balancer를 생성하거나 보안 그룹 또는 Elastic Container Service 클러스터를 생성하기 위해 여러 리소스 모듈이 호출됩니다.

모듈에는 두 가지 유형이 있습니다. 제가 이 보고서에 분류한 대부분의 정보는 문서에 기록되어 있지 않기 때문에 이를 이해하는 것이 중요합니다.

그리고 현재 Terraform의 문서에는 이러한 기능이 있고 사용할 수 있다고 나와 있기 때문에 상당히 문제가 많습니다. 하지만 그녀는 이러한 기능을 어떻게 사용하는지, 왜 사용하는 것이 더 좋은지는 말하지 않습니다. 그러므로 매우 많은 사람들이 함께 살 수 없는 글을 씁니다.

다음에는 이러한 모듈을 작성하는 방법을 살펴보겠습니다. 그런 다음 이를 호출하는 방법과 코드를 사용하여 작업하는 방법을 살펴보겠습니다.

Terraform 레지스트리 - https://registry.terraform.io/

팁 #0은 리소스 모듈을 작성하지 않는 것입니다. 이러한 모듈의 대부분은 이미 작성되었습니다. 앞서 말했듯이 이 모듈은 오픈 소스이고 비즈니스 로직을 전혀 포함하지 않으며 IP 주소, 비밀번호 등에 대한 하드코딩된 값이 없습니다. 모듈은 매우 유연합니다. 그리고 그것은 이미 작성되었을 가능성이 높습니다. Amazon의 리소스에 대한 모듈이 많이 있습니다. 약 650개. 그리고 대부분 품질이 좋습니다.

이 예에서는 누군가가 당신에게 와서 “나는 데이터베이스를 관리할 수 있기를 원합니다. 데이터베이스를 만들 수 있도록 모듈을 만드세요." 그 사람은 Amazon이나 Terraform의 구현 세부 사항을 모릅니다. 그는 단순히 "MSSQL을 관리하고 싶습니다"라고 말합니다. 즉, 모듈을 호출하고 거기에 엔진 유형을 전달하고 시간대를 표시한다는 의미입니다.

그리고 사람은 이 모듈 내에 두 개의 서로 다른 리소스를 생성할 것이라는 사실을 알아야 합니다. 하나는 MSSQL용이고 다른 하나는 다른 모든 리소스용입니다. Terraform 0.11에서는 시간대 값을 선택 사항으로 지정할 수 없기 때문입니다.

그리고 이 모듈을 종료하면 간단히 주소를 받을 수 있습니다. 그는 우리가 내부적으로 이 모든 것을 어떤 데이터베이스, 어떤 리소스에서 생성하고 있는지 알 수 없습니다. 이것은 은폐의 매우 중요한 요소입니다. 이는 오픈 소스에 공개된 모듈뿐만 아니라 프로젝트와 팀 내부에서 작성하게 될 모듈에도 적용됩니다.

이것은 두 번째 주장으로, 한동안 Terraform을 사용해 왔다면 매우 중요합니다. 회사의 모든 Terraform 모듈을 저장하는 저장소가 있습니다. 그리고 시간이 지남에 따라 이 프로젝트의 크기가 XNUMX~XNUMXMB로 커지는 것은 매우 정상적인 현상입니다. 이건 괜찮아.

그러나 문제는 Terraform이 이러한 모듈을 호출하는 방식입니다. 예를 들어, 각 개별 사용자를 생성하기 위해 모듈을 호출하는 경우 Terraform은 먼저 전체 저장소를 로드한 다음 해당 특정 모듈이 있는 폴더로 이동합니다. 이렇게 하면 매번 100MB를 다운로드하게 됩니다. 200명 또는 100명의 사용자를 관리하는 경우 200MB 또는 XNUMXMB를 다운로드한 다음 해당 폴더로 이동합니다. 따라서 당연히 "Terraform init"을 누를 때마다 많은 항목을 다운로드하고 싶지는 않을 것입니다.

https://github.com/mbtproject/mbt

이 문제에 대한 두 가지 해결책이 있습니다. 첫 번째는 상대 경로를 사용하는 것입니다. 이렇게 하면 폴더가 로컬(./)이라는 것을 코드에 표시할 수 있습니다. 그리고 무엇이든 시작하기 전에 이 저장소의 Git 복제를 로컬로 수행합니다. 이렇게 한번 하면 됩니다.

물론 단점도 많습니다. 예를 들어 버전 관리를 사용할 수 없습니다. 그리고 이것은 때로는 함께 살기가 어렵습니다.

두 번째 솔루션. 하위 모듈이 많고 이미 확립된 파이프라인이 있는 경우 MBT 프로젝트가 있습니다. 이를 통해 단일 저장소에서 다양한 패키지를 수집하여 S3에 업로드할 수 있습니다. 이것은 아주 좋은 방법입니다. 따라서 iam-user-1.0.0.zip 파일의 무게는 1Kb에 불과합니다. 왜냐하면 이 리소스를 생성하는 코드가 매우 작기 때문입니다. 그리고 그것은 훨씬 더 빠르게 작동할 것입니다.

모듈에서 사용할 수 없는 것에 대해 이야기해 봅시다.

모듈에서 이것이 왜 악한가? 최악의 상황은 사용자를 가정하는 것입니다. 사용자는 다른 사람들이 사용할 수 있는 공급자 인증 옵션이라고 가정합니다. 예를 들어, 우리는 모두 역할을 동화할 것입니다. 이는 Terraform이 이 역할을 맡는다는 것을 의미합니다. 그런 다음 이 역할을 사용하여 다른 작업을 수행합니다.

그리고 나쁜 점은 Vasya가 기본 환경 변수를 사용하여 한 가지 방법으로 Amazon에 연결하는 것을 좋아하고 Petya가 비밀 장소에 있는 공유 키를 사용하는 것을 좋아한다면 두 가지를 모두 지정할 수 없다는 것입니다. 테라폼. 그리고 그들이 고통을 겪지 않도록 모듈에서 이 블록을 표시할 필요가 없습니다. 이는 더 높은 수준에서 표시되어야 합니다. 즉, 리소스 모듈, 인프라 모듈 및 구성이 맨 위에 있습니다. 그리고 이것은 더 높은 곳에 표시되어야 합니다.

두 번째 악은 공급업체입니다. 여기서 악은 그다지 사소하지 않습니다. 왜냐하면 코드를 작성하고 그것이 당신에게 적합하다면, 그것이 작동한다면 왜 변경해야 하는지 생각할 수 있기 때문입니다.

문제는 먼저 이 프로비저너가 언제 시작될지 항상 제어할 수 없다는 것입니다. 둘째, aws ec2가 의미하는 바를 제어할 수 없습니다. 즉, 지금 우리가 Linux에 대해 이야기하고 있는지 아니면 Windows에 대해 이야기하고 있는지를 제어할 수 없습니다. 따라서 다른 운영 체제나 다른 사용자 사례에서 동일하게 작동하는 것을 작성할 수 없습니다.

공식 문서에도 나와 있는 가장 일반적인 예는 aws_instance를 작성하고 여러 인수를 지정하는 경우 거기에 프로비저너 "local-exec"를 지정하고 ansible-를 실행하면 아무런 문제가 없다는 것입니다. 플레이북 .

사실 그렇습니다. 아무 문제가 없습니다. 그러나 말 그대로 곧 이 로컬 실행 항목(예: launch_configuration)이 존재하지 않는다는 것을 알게 될 것입니다.

그리고 launch_configuration을 사용하고 한 인스턴스에서 자동 확장 그룹을 생성하려는 경우 launch_configuration에는 "프로비저너" 개념이 없습니다. "사용자 데이터"라는 개념이 있습니다.

따라서 보다 보편적인 솔루션은 사용자 데이터를 사용하는 것입니다. 그리고 인스턴스가 켜져 있을 때 인스턴스 자체에서 시작되거나 Auto Scaling 그룹이 이 launch_configuration을 사용할 때 동일한 사용자 데이터에서 시작됩니다.

프로비저너가 접착 구성 요소이기 때문에 계속 실행하려면 하나의 리소스가 생성될 때 그 순간 프로비저너, 즉 명령을 실행해야 합니다. 그러한 상황이 많이 있습니다.

그리고 이에 대한 가장 정확한 리소스를 null_resource라고 합니다. Null_resource는 실제로 생성되지 않는 더미 리소스입니다. 아무것도 건드리지 않고, API도, 자동 확장도 없습니다. 그러나 명령을 실행할 시기를 제어할 수 있습니다. 이 경우 생성 중에 명령이 실행됩니다.

링크 http://bit.ly/common-traits-in-terraform-modules

여러 가지 징후가 있습니다. 나는 모든 징후에 대해 자세히 설명하지는 않겠습니다. 이에 대한 기사가 있습니다. 그러나 Terraform으로 작업했거나 다른 사람의 모듈을 사용해 본 적이 있다면 오픈 소스에 있는 대부분의 코드와 마찬가지로 많은 모듈이 사람들이 자신의 필요에 따라 작성했다는 사실을 종종 알게 될 것입니다. 한 남자가 그것을 쓰고 그의 문제를 해결했습니다. GitHub에 넣어서 라이브로 두었습니다. 그것은 살아있지만 거기에 문서와 예제가 없으면 아무도 그것을 사용하지 않을 것입니다. 그리고 특정 작업보다 조금 더 많은 것을 해결할 수 있는 기능이 없다면 아무도 그것을 사용하지 않을 것입니다. 사용자를 잃는 방법은 너무 많습니다.

사람들이 사용할 수 있도록 글을 쓰고 싶다면 다음 표시를 따르는 것이 좋습니다.

이들은 :

• 문서 및 예제.
• 전체 기능.
• 합리적인 기본값.
• 코드를 정리하세요.
• 테스트.

테스트는 작성하기가 매우 어렵기 때문에 상황이 다릅니다. 나는 문서와 예제를 더 믿습니다.

그래서 우리는 모듈을 작성하는 방법을 살펴보았습니다. 두 가지 주장이 있습니다. 가장 중요한 첫 번째는 가능하면 글을 쓰지 않는 것입니다. 많은 사람들이 이미 이러한 작업을 수행했기 때문입니다. 둘째, 여전히 결정했다면 모듈과 프로비저너에서 공급자를 사용하지 마십시오.

이것은 문서의 회색 부분입니다. 당신은 이제 다음과 같이 생각할 수도 있습니다. “뭔가 불분명하다. 확신하지 못했어요." 하지만 XNUMX개월 뒤에 보자.

이제 이러한 모듈을 호출하는 방법에 대해 이야기해 보겠습니다.

우리는 시간이 지남에 따라 코드가 성장한다는 것을 알고 있습니다. 더 이상 하나의 파일이 없으며 이미 20개의 파일이 있습니다. 모두 하나의 폴더에 있습니다. 아니면 폴더가 XNUMX개일 수도 있습니다. 어쩌면 우리는 지역별, 일부 구성 요소별로 분류하기 시작했을 수도 있습니다. 그러면 우리는 이제 동기화와 오케스트레이션에 대한 몇 가지 기초를 갖게 되었음을 이해합니다. 즉, 네트워크 리소스를 변경한 경우 무엇을 해야 하는지, 나머지 리소스로 무엇을 해야 하는지, 이러한 종속성을 유발하는 방법 등을 이해해야 합니다.

두 가지 극단이 있습니다. 첫 번째 극단은 모두 하나입니다. 하나의 마스터 파일이 있습니다. 당분간 이는 Terraform 웹사이트의 공식 모범 사례였습니다.

그러나 지금은 더 이상 사용되지 않는 것으로 작성되어 제거되었습니다. 시간이 지남에 따라 Terraform 커뮤니티는 사람들이 프로젝트를 다양한 방식으로 사용하기 시작했기 때문에 이것이 모범 사례와는 거리가 멀다는 것을 깨달았습니다. 그리고 문제가 있습니다. 예를 들어 모든 종속성을 한 곳에 나열하는 경우입니다. "Terraform 계획"을 클릭하면 Terraform이 모든 리소스의 상태를 업데이트할 때까지 많은 시간이 소요될 수 있습니다.

많은 시간은 예를 들어 5분입니다. 어떤 사람들에게는 이것은 많은 시간입니다. 15분만에 끝나는 경우도 봤습니다. AWS API는 각 리소스의 상태에 무슨 일이 일어나고 있는지 파악하는 데 15분을 소비했습니다. 이것은 매우 넓은 지역입니다.

그리고 자연스럽게 한 곳에서 뭔가를 바꾸고 싶을 때 관련된 문제가 나타나게 되는데, 그 후 15분을 기다리면 몇 가지 변화의 캔버스가 나옵니다. 침을 뱉고 "예"라고 썼는데 뭔가 잘못되었습니다. 이것은 매우 실제적인 예입니다. Terraform은 문제로부터 사용자를 보호하려고 하지 않습니다. 즉, 원하는 것을 작성하십시오. 문제가 있을 것입니다 - 당신의 문제. Terraform 0.11은 어떤 식으로든 사용자를 돕기 위해 노력하지 않습니다. 0.12에는 다음과 같이 말할 수 있는 흥미로운 부분이 있습니다: "Vasya, 당신은 이것을 정말로 원합니다. 정신을 차릴 수 있습니까?"

두 번째 방법은 이 영역을 줄이는 것입니다. 즉, 한 곳에서 오는 전화가 다른 곳에서 연결되는 양이 줄어들 수 있습니다.

유일한 문제는 더 많은 코드를 작성해야 한다는 것입니다. 즉, 많은 수의 파일에서 변수를 설명하고 이를 업데이트해야 한다는 것입니다. 어떤 사람들은 그것을 좋아하지 않습니다. 이것은 나에게 정상입니다. 그리고 어떤 사람들은 “이걸 왜 여러 곳에 쓰는데, 다 한 곳에 모아 놓을까”라고 생각합니다. 이것은 가능하지만 이것은 두 번째 극단입니다.

이 모든 것을 한 곳에 사는 사람은 누구입니까? 하나, 둘, 셋, 즉 누군가가 사용하고 있습니다.

그리고 누가 하나의 특정 구성 요소, 하나의 블록 또는 하나의 인프라 모듈을 호출합니까? XNUMX~XNUMX명. 이것은 멋지다.

가장 일반적인 대답은 중간 어딘가에 있습니다. 프로젝트 규모가 크면 적합한 솔루션이 없고 모든 것이 제대로 작동하지 않는 상황이 발생하여 결과적으로 혼합되는 상황이 발생하는 경우가 많습니다. 둘 다 장점이 있다는 것을 이해하는 한, 이것에는 아무런 문제가 없습니다.

스택 VPC에서 변경된 사항이 있고 이러한 변경 사항을 EC2에 적용하려는 경우, 즉 새 서브넷이 있어서 Auto Scaling 그룹을 업데이트하려는 경우 이러한 종류의 종속성 오케스트레이션을 호출합니다. 몇 가지 해결책이 있습니다. 누가 무엇을 사용합니까?

어떤 해결책이 있는지 제안해 드릴 수 있습니다. Terraform을 사용하여 마법을 수행하거나 makefile을 사용하여 Terraform을 사용할 수 있습니다. 거기에서 변경된 사항이 있는지 확인하고 여기에서 실행할 수 있습니다.

이 결정이 마음에 드시나요? 이것이 멋진 해결책이라고 믿는 사람이 있습니까? 나는 미소를 짓는다. 분명히 의심이 스며들었다.

물론 집에서 이것을 시도하지 마십시오. Terraform은 Terraform에서 실행되도록 설계되지 않았습니다.

한 보고서에서 그들은 나에게 "아니요, 이것은 작동하지 않습니다"라고 말했습니다. 요점은 그것이 작동해서는 안된다는 것입니다. Terraform에서 Terraform을 시작한 다음 Terraform을 시작할 수 있으면 매우 인상적으로 보이지만 그렇게 해서는 안 됩니다. Terraform은 항상 매우 쉽게 시작되어야 합니다.

https://github.com/gruntwork-io/terragrunt/

한 곳에서 무언가 변경되었을 때 통화 조정이 필요한 경우 Terragrunt가 있습니다.

Terragrunt는 인프라 모듈에 대한 호출을 조정하고 조정할 수 있는 Terraform의 추가 기능인 유틸리티입니다.

일반적인 Terraform 구성 파일은 다음과 같습니다.

호출하려는 특정 모듈을 지정합니다.

모듈에는 어떤 종속성이 있습니까?

그리고 이 모듈은 어떤 인수를 허용합니까? 이것이 Terragrunt에 대해 알아야 할 전부입니다.

문서는 거기에 있으며 GitHub에는 1개의 별이 있습니다. 그러나 대부분의 경우 이것이 당신이 알아야 할 것입니다. 이는 Terraform을 이제 막 사용하기 시작한 회사에서 구현하기가 매우 쉽습니다.

오케스트레이션은 Terragrunt입니다. 다른 옵션이 있습니다.

이제 코드 작업 방법에 대해 이야기하겠습니다.

코드에 새로운 기능을 추가해야 하는 경우 대부분의 경우 이는 쉽습니다. 당신은 새로운 리소스를 작성하고 있으며 모든 것이 간단합니다.

예를 들어, 미리 생성한 리소스가 있고 AWS 계정을 개설한 후 Terraform에 대해 배웠고 이미 보유하고 있는 리소스를 사용하려는 경우 이러한 방식으로 모듈을 확장하는 것이 적절할 것입니다. 기존 리소스의 사용을 지원합니다.

그리고 블록 리소스를 활용한 새로운 리소스 생성을 지원했습니다.

출력 시 사용된 항목에 따라 항상 출력 ID를 반환합니다.

Terraform 0.11에서 두 번째로 중요한 문제는 목록 작업입니다.

어려운 점은 그러한 사용자 목록이 있다는 것입니다.

그리고 블록 리소스를 사용하여 이러한 사용자를 생성하면 모든 것이 잘 됩니다. 전체 목록을 살펴보고 각각에 대한 파일을 만듭니다. 모든 것이 괜찮습니다. 그리고 예를 들어 중간에 있는 user3을 여기에서 제거해야 하며, 그러면 인덱스가 변경되므로 그 이후에 생성된 모든 리소스가 다시 생성됩니다.

상태 저장 환경에서 목록 작업. 상태 저장 환경이란 무엇입니까? 이 리소스가 생성되면 새로운 가치가 생성되는 상황입니다. 예를 들어 AWS 액세스 키 또는 AWS 비밀 키입니다. 즉, 사용자를 생성하면 새 액세스 또는 비밀 키를 받습니다. 그리고 사용자를 삭제할 때마다 이 사용자는 새 키를 갖게 됩니다. 그러나 이것은 풍수가 아닙니다. 누군가가 팀을 떠날 때마다 새로운 사용자를 생성하면 사용자는 우리와 친구가 되고 싶어하지 않을 것이기 때문입니다.

이것이 해결책입니다. Jsonnet으로 작성된 코드입니다. Jsonnet은 Google의 템플릿 언어입니다.

이 명령을 사용하면 이 템플릿을 수락할 수 있으며 출력으로 템플릿에 따라 만들어진 json 파일이 반환됩니다.

템플릿은 다음과 같습니다.

Terraform을 사용하면 동일한 방식으로 HCL과 Json을 모두 사용할 수 있으므로 Json을 생성할 수 있는 능력이 있으면 이를 Terraform에 넣을 수 있습니다. 확장자가 .tf.json인 파일이 성공적으로 다운로드됩니다.

그런 다음 평소대로 terraform init, terramorm Apply를 사용하여 작업합니다. 그리고 우리는 두 명의 사용자를 만듭니다.

이제 우리는 누군가가 팀을 떠나도 두렵지 않습니다. json 파일만 편집하겠습니다. Vasya Pupkin은 떠났고 Petya Pyatochkin은 남았습니다. Petya Pyatochkin은 새 키를 받지 않습니다.

Terraform을 다른 도구와 통합하는 것은 실제로 Terraform의 작업이 아닙니다. Terraform은 리소스 생성을 위한 플랫폼으로 만들어졌으며 그게 전부입니다. 그리고 나중에 나오는 모든 것은 Terraform의 관심사가 아닙니다. 그리고 거기에 그것을 엮을 필요가 없습니다. 필요한 모든 것을 수행하는 Ansible이 있습니다.

그러나 Terraform을 확장하고 작업이 완료된 후 일부 명령을 호출하려는 상황이 발생합니다.

첫 번째 방법. 이 명령을 작성하는 출력을 생성합니다.

그런 다음 쉘 terraform 출력에서 ​​이 명령을 호출하고 원하는 값을 지정합니다. 따라서 명령은 대체된 모든 값으로 실행됩니다. 매우 편안합니다.

두 번째 방법. 이는 인프라 변경에 따라 null_resource를 사용하는 것입니다. 일부 리소스의 ID가 변경되는 즉시 동일한 local-exe를 호출할 수 있습니다.

당연히 이 모든 것이 서류상으로는 순조롭게 진행됩니다. 왜냐하면 Amazon은 다른 모든 공공 서비스 제공업체와 마찬가지로 자체적인 예외 사례를 많이 가지고 있기 때문입니다.

가장 일반적인 극단적인 경우는 AWS 계정을 개설할 때 어떤 리전을 사용하는지가 중요하다는 것입니다. 이 기능이 활성화되어 있습니까? 어쩌면 2013년 XNUMX월 이후에 열었을 수도 있습니다. 어쩌면 VPC 등에서 기본값을 사용하고 있을 수도 있습니다. 많은 제한 사항이 있습니다. 그리고 Amazon은 이를 문서 전체에 분산시켰습니다.

제가 피하라고 권장하는 몇 가지 사항이 있습니다.

시작하려면 Terraform 계획 또는 Terraform CLI 내에서 비밀이 아닌 모든 인수를 피하세요. 이 모든 것은 tfvars 파일이나 환경 변수에 넣을 수 있습니다.

하지만 이 마법 명령을 모두 외울 필요는 없습니다. Terraform 계획 – var를 선택하고 시작합니다. 첫 번째 변수는 var, 두 번째 변수는 var, 세 번째, 네 번째 변수입니다. 제가 가장 자주 사용하는 코드형 인프라의 가장 중요한 원칙은 코드를 보는 것만으로도 거기에 무엇이 배포되고, 어떤 상태로, 어떤 값으로 배포되는지 명확하게 이해해야 한다는 것입니다. 따라서 문서를 읽거나 Vasya에게 클러스터를 생성하는 데 사용한 매개변수를 물어볼 필요가 없습니다. 종종 환경과 일치하는 tfvars 확장자를 가진 파일을 열고 거기에 있는 모든 것을 살펴보기만 하면 됩니다.

또한 범위를 줄이기 위해 대상 인수를 사용하지 마십시오. 이를 위해 작은 인프라 모듈을 사용하는 것이 훨씬 쉽습니다.

또한 병렬성을 제한하거나 늘릴 필요가 없습니다. 150개의 리소스가 있고 Amazon 병렬 처리를 기본값 10에서 100으로 늘리고 싶다면 문제가 발생할 가능성이 높습니다. 아니면 지금은 잘 될지 모르지만 Amazon에서 전화를 너무 많이 걸고 있다고 말하면 문제가 발생할 수 있습니다.

Terraform은 이러한 문제의 대부분을 다시 시작하려고 시도하지만 거의 아무 성과도 얻지 못할 것입니다. Parallelism=1은 AWS API 또는 Terraform 공급자 내부에서 버그를 발견한 경우 사용하는 중요한 것입니다. 그런 다음 병렬 처리=1을 지정하고 Terraform이 한 호출, 두 번째 호출, 세 번째 호출을 완료할 때까지 기다려야 합니다. 그는 그것들을 하나씩 시작할 것입니다.

사람들은 종종 "Terraform 작업 공간이 나쁘다고 생각하는 이유는 무엇입니까?"라고 묻습니다. 어떤 인프라가 어떤 가치로 만들어졌는지 살펴보는 것이 코드형 인프라의 원리라고 생각합니다.

작업공간은 사용자가 만든 것이 아닙니다. 이는 사용자가 Terraform 작업공간 없이는 살 수 없는 문제를 GitHub에 썼다는 의미는 아닙니다. 아니, 이렇지 않아. Terraform Enterprise는 상용 솔루션입니다. HashiCorp의 Terraform은 작업 공간이 필요하다고 판단하여 이를 정리했습니다. 따로 폴더에 넣어두는 게 훨씬 편한 것 같아요. 그러면 파일이 조금 더 많아지지만 더 명확해집니다.

코드로 작업하는 방법? 사실 목록 작업이 유일한 고통입니다. 그리고 Terraform을 더 쉽게 활용하세요. 이것은 당신을 위해 모든 일을 훌륭하게 해 줄 일이 아닙니다. 문서에 기록된 모든 내용을 거기에 밀어넣을 필요는 없습니다.

보고서의 주제는 '미래를 위해'로 작성됐다. 이에 대해 아주 간략하게 이야기하겠습니다. 앞으로는 0.12가 곧 출시될 것이라는 의미입니다.

0.12는 정말 새로운 것입니다. 일반 프로그래밍에서 왔다면 왼쪽과 오른쪽이 동시에 계산되지 않고 상황에 따라 계산되는 모든 종류의 동적 블록, 루프, 올바른 및 조건부 비교 작업을 놓칠 수 있습니다. 당신은 그것을 많이 그리워하므로 0.12가 당신을 위해 해결해 줄 것입니다.

하지만! 기성 모듈과 타사 솔루션을 사용하여 점점 더 간단하게 작성한다면 기다릴 필요가 없으며 0.12가 와서 모든 것을 해결해 주기를 바랄 것입니다.

신고해 주셔서 감사합니다! 코드형 인프라(Infrastructure as Code)에 대해 말씀하셨고 문자 그대로 테스트에 대해 한 마디 말씀하셨습니다. 모듈에 테스트가 필요합니까? 이것은 누구의 책임입니까? 직접 작성해야 합니까, 아니면 모듈의 책임입니까?

내년에는 우리가 모든 것을 테스트하기로 결정했다는 보고서로 가득 차게 될 것입니다. 무엇을 테스트할 것인가가 가장 큰 문제입니다. 많은 종속성과 다양한 공급자의 제한 사항이 많이 있습니다. 당신과 내가 이야기할 때 당신이 “테스트가 필요해요”라고 말하면 나는 “무엇을 테스트할 건가요?”라고 묻습니다. 당신은 당신의 지역에서 테스트를 할 것이라고 말합니다. 그러면 내 지역에서는 이것이 작동하지 않는다고 말합니다. 즉, 우리는 이에 동의조차 할 수 없습니다. 기술적인 문제가 많다는 것은 말할 것도 없습니다. 즉, 이러한 테스트를 적절하게 작성하는 방법입니다.

저는 이 주제, 즉 귀하가 작성한 인프라를 기반으로 테스트를 자동으로 생성하는 방법을 적극적으로 연구하고 있습니다. 즉, 이 코드를 작성했다면 이를 실행해야 하며 이를 기반으로 테스트를 만들 수 있습니다.

테라테스트 Terraform에 대한 통합 테스트를 작성할 수 있는 가장 자주 언급되는 라이브러리 중 하나입니다. 유틸리티 중 하나입니다. 나는 rspec과 같은 DSL 유형을 선호합니다.

안톤, 신고해 주셔서 감사합니다! 내 이름은 발레리입니다. 조금 철학적인 질문을 해보자. 조건부로 프로비저닝이 있고 배포가 있습니다. 프로비저닝은 인프라를 생성하고 배포에서는 서버, 애플리케이션 등과 같은 유용한 것으로 채웁니다. 그리고 내 머릿속에는 Terraform이 프로비저닝에 더 적합하고 Ansible이 배포에 더 적합합니다. 왜냐하면 Ansible은 물리적 인프라에도 적합하기 때문입니다. nginx, Postgres를 설치할 수 있습니다. 그러나 동시에 Ansible은 예를 들어 Amazon 또는 Google 리소스의 프로비저닝을 허용하는 것으로 보입니다. 그러나 Terraform을 사용하면 해당 모듈을 사용하여 일부 소프트웨어를 배포할 수도 있습니다. 귀하의 관점에서 볼 때 Terraform과 Ansible 사이에 일종의 경계가 있습니까? 어디에서 무엇을 사용하는 것이 더 좋습니까? 아니면 예를 들어 Ansible이 이미 쓰레기라고 생각하시나요? 모든 것에 Terraform을 사용해야 한다고 생각하시나요?

좋은 질문이에요, 발레리. 저는 Terraform이 2014년 이후로 목적 면에서 변하지 않았다고 믿습니다. 인프라를 위해 만들어졌고 인프라를 위해 죽었습니다. 우리는 여전히 구성 관리 Ansible에 대한 필요성을 갖고 있었고 앞으로도 그럴 것입니다. 문제는 launch_configuration 내부에 사용자 데이터가 있다는 것입니다. 그리고 거기에서 Ansible 등을 끌어옵니다. 이것이 제가 가장 좋아하는 표준 구별입니다.

아름다운 인프라에 관해 이야기하고 있다면 이 이미지를 수집하는 Packer와 같은 유틸리티가 있습니다. 그런 다음 Terraform은 데이터 소스를 사용하여 이 이미지를 찾고 해당 launch_configuration을 업데이트합니다. 즉, 이러한 방식으로 파이프라인은 먼저 Tracker를 가져온 다음 Terraform을 가져오는 것입니다. 그리고 빌드가 발생하면 새로운 변경이 발생합니다.

안녕하세요! 신고해 주셔서 감사합니다! 제 이름은 RBS 회사 미샤입니다. 리소스를 생성할 때 프로비저너를 통해 Ansible을 호출할 수 있습니다. Ansible에는 동적 인벤토리라는 주제도 있습니다. 먼저 Terraform을 호출한 다음 Ansible을 호출하면 상태에서 리소스를 가져와 실행할 수 있습니다. 무엇이 더 좋나요?

사람들은 두 가지를 모두 성공적으로 사용합니다. AutoScaling 그룹에 대해 이야기하고 있지 않다면 Ansible의 동적 인벤토리가 편리한 것 같습니다. AutoScaling 그룹에는 이미 launch_configuration이라는 자체 툴킷이 있기 때문입니다. launch_configuration에는 새 리소스를 생성할 때 시작해야 하는 모든 항목을 기록합니다. 따라서 Amazon에서는 동적 인벤토리를 사용하고 Terraform ts 파일을 읽는 것이 과잉이라고 생각합니다. 그리고 "자동 확장 그룹"이라는 개념이 없는 다른 도구를 사용하는 경우(예: DigitalOcean 또는 자동 확장 그룹이 없는 다른 공급자를 사용하는 경우) 수동으로 API를 가져와서 IP 주소를 찾고, 생성해야 합니다. 동적 인벤토리 파일이며 Ansible은 이미 이를 탐색할 것입니다. 즉, Amazon에는 launch_configuration이 있고 다른 모든 것에는 동적 인벤토리가 있습니다.

출처 : habr.com