혼돈과 수동 루틴에 대처하기 위한 Terraform의 패턴. 막심 코스트리킨(익스텐스)

Terraform 개발자는 AWS 인프라 작업에 매우 편리한 모범 사례를 제공하는 것 같습니다. 단지 뉘앙스가 있을 뿐입니다. 시간이 지남에 따라 각각 고유한 기능을 갖춘 환경의 수가 증가합니다. 애플리케이션 스택의 거의 복사본이 인접 지역에 나타납니다. 그리고 Terraform 코드는 새로운 요구 사항에 따라 주의 깊게 복사 및 편집되거나 눈송이로 만들어져야 합니다.

크고 긴 프로젝트의 혼란과 수동 루틴에 대처하기 위한 Terraform의 패턴에 대한 보고서입니다.

비디오 :

저는 40살이고 IT 업계에 종사한 지 20년이 되었습니다. 저는 Ixtens에서 12년 동안 근무했습니다. 우리는 전자상거래 중심의 개발에 참여하고 있습니다. 그리고 저는 5년 동안 DevOps 실무를 실천해 왔습니다.

내 이야기는 비공개 계약 뒤에 숨어 이름을 밝히지 않은 회사의 프로젝트에서 내가 겪은 경험에 관한 것입니다.

슬라이드의 숫자는 프로젝트의 규모를 이해하기 위해 표시되었습니다. 그리고 제가 다음에 말할 모든 것은 아마존과 관련이 있습니다.

저는 4년 전에 이 프로젝트에 참여했습니다. 그리고 프로젝트가 성장했기 때문에 인프라 리팩토링이 본격화되었습니다. 그리고 사용된 패턴은 더 이상 적합하지 않았습니다. 그리고 프로젝트의 모든 계획된 성장을 고려하여 새로운 것을 생각해 내는 것이 필요했습니다.

어제 Dodo Pizza에서 무슨 일이 일어났는지 알려준 Matvey에게 감사드립니다. 4년 전 이곳에서 일어난 일이다.

개발자들이 와서 인프라 코드를 만들기 시작했습니다.

이것이 필요한 가장 확실한 이유는 시장 출시 기간이었습니다. DevOps 팀이 롤아웃 중에 병목 현상이 발생하지 않는지 확인해야 했습니다. 무엇보다도 Terraform과 Puppet이 첫 번째 수준에서 사용되었습니다.

Terraform은 HashiCorp의 오픈 소스 프로젝트입니다. 이것이 무엇인지조차 모르는 분들을 위해 다음 슬라이드를 보여드리겠습니다.

코드형 인프라는 인프라를 설명하고 일부 로봇에게 설명된 리소스를 수신하는지 확인하도록 요청할 수 있음을 의미합니다.

예를 들어 가상 머신이 필요합니다. 몇 가지 필수 매개변수를 설명하고 추가하겠습니다.

그런 다음 콘솔에서 Amazon에 대한 액세스를 구성하겠습니다. 그리고 Terraform 계획을 요청하겠습니다. Terraform 계획은 "알겠습니다. 귀하의 리소스에 대해 이러한 작업을 수행할 수 있습니다."라고 말합니다. 그리고 최소한 하나의 리소스가 추가됩니다. 그리고 어떤 변화도 예상되지 않습니다.

모든 것이 만족스러우면 Terraform에 적용을 요청하면 Terraform이 인스턴스를 생성하고 클라우드에 가상 머신을 받게 됩니다.

또한 우리 프로젝트가 개발 중입니다. 우리는 거기에 몇 가지 변경 사항을 추가하고 있습니다. 더 많은 인스턴스를 요청하여 53개의 항목을 추가합니다.

그리고 우리는 반복합니다. 계획해주세요. 어떤 변화가 계획되어 있는지 확인합니다. 신청합니다. 이것이 바로 우리 인프라가 성장하는 방식입니다.

Terraform은 상태 파일이라는 것을 사용합니다. 즉, Amazon으로 이동하는 모든 변경 사항은 설명하는 각 리소스에 대해 Amazon에서 생성된 해당 리소스가 있는 파일에 저장됩니다. 따라서 리소스 설명이 변경되면 Terraform은 Amazon에서 변경해야 할 사항을 정확히 알고 있습니다.

이러한 상태 파일은 원래 파일이었습니다. 그리고 우리는 그것들을 Git에 저장했는데, 이는 매우 불편했습니다. 누군가는 항상 변경 사항을 적용하는 것을 잊어버렸고 많은 갈등이 발생했습니다.

이제 백엔드를 사용할 수 있습니다. 즉, Terraform은 상태 파일을 저장할 버킷과 키를 지정합니다. 그리고 Terraform 자체가 이 상태 파일을 가져오고 모든 마법을 수행하고 최종 결과를 다시 가져오는 작업을 처리합니다.

우리의 인프라는 성장하고 있습니다. 여기에 우리의 코드가 있습니다. 이제 우리는 가상 머신을 만드는 것뿐만 아니라 테스트 환경도 갖고 싶습니다.

Terraform을 사용하면 모듈과 같은 것을 생성할 수 있습니다. 즉, 일부 폴더에서 동일한 것을 설명할 수 있습니다.

예를 들어 테스트에서 이 모듈을 호출하면 모듈 자체에서 Terraform 적용을 실행한 것과 동일한 결과를 얻을 수 있습니다. 테스트를 위해 이 코드가 있습니다.

테스트에서는 대규모 인스턴스가 필요하지 않지만 프로덕션에서는 대규모 인스턴스가 유용하기 때문에 프로덕션의 경우 일부 변경 사항을 거기로 보낼 수 있습니다.

그리고 다시 프로젝트로 돌아오겠습니다. 어려운 작업이었고 계획된 인프라가 매우 컸습니다. 그리고 이 코드를 유지 관리하는 사람과 변경하는 사람 모두에게 편리하도록 모든 코드를 어떻게든 배치해야 했습니다. 그리고 모든 개발자가 플랫폼의 일부에 필요에 따라 인프라를 수정하고 수정할 수 있도록 계획되었습니다.

이는 대규모 프로젝트가 있는 경우 HashiCorp 자체에서 권장하는 디렉토리 트리이며 전체 인프라를 몇 개의 작은 조각으로 나누고 각 조각을 별도의 폴더에 설명하는 것이 합리적입니다.

광범위한 리소스 라이브러리를 보유하면 테스트 및 프로덕션에서 거의 동일한 것을 호출할 수 있습니다.

우리의 경우 개발자나 테스트를 위한 테스트 스택을 좀 더 간단하게 확보해야 했기 때문에 이는 완전히 적합하지 않았습니다. 하지만 폴더를 살펴보고 필요한 순서대로 적용하고 싶지 않았으며 데이터베이스가 상승하고 이 데이터베이스를 사용하는 인스턴스가 상승할 것이라고 걱정했습니다. 따라서 모든 테스트는 하나의 폴더에서 시작되었습니다. 동일한 모듈이 호출되었지만 모든 것이 한 번에 완료되었습니다.

Terraform은 모든 종속성을 관리합니다. 그리고 예를 들어 새로 생성된 인스턴스에서 IP 주소를 가져오고 Route53 레코드에서 이 IP 주소를 가져올 수 있도록 항상 순서대로 리소스를 생성합니다.

게다가 플랫폼도 매우 크다. 그리고 한 시간, 심지어 8시간 동안이라도 테스트 스택을 시작하는 것은 상당히 비용이 많이 드는 작업입니다.

그리고 우리는 이 문제를 자동화했습니다. 그리고 Jenkins 작업을 통해 스택을 실행할 수 있었습니다. 여기에서는 개발자가 테스트하려는 변경 사항이 포함된 풀 요청을 실행하고 필요한 모든 옵션, 구성 요소 및 차원을 지정해야 했습니다. 성능 테스트를 원할 경우 더 많은 인스턴스를 사용할 수 있습니다. 어떤 양식이 열리는지 확인해야 한다면 최저 임금으로 시작할 수 있습니다. 또한 클러스터가 필요한지 여부 등을 나타냅니다.

그런 다음 Jenkins는 Terraform 폴더의 코드를 약간 수정하는 쉘 스크립트를 푸시했습니다. 불필요한 파일을 제거하고 필요한 파일을 추가했습니다. 그런 다음 Terraform을 한 번 실행하면 스택이 늘어났습니다.

그리고 내가 들어가고 싶지 않은 다른 단계도 있었습니다.

테스트를 위해서는 프로덕션보다 약간 더 많은 옵션이 필요했기 때문에 모듈의 복사본을 만들어 이러한 복사본에 테스트에만 필요한 기능을 추가해야 했습니다.

그리고 테스트에서 결국 프로덕션에 적용될 변경 사항을 테스트하고 싶었습니다. 그러나 실제로 한 가지가 테스트되었으며 생산에는 약간 다른 것이 사용되었습니다. 그리고 프로덕션에서는 모든 변경 사항을 운영팀에서 적용하는 패턴에 약간의 차이가 있었습니다. 때로는 테스트에서 프로덕션으로 진행되어야 했던 변경 사항이 다른 버전에도 남아 있는 것으로 나타났습니다.

게다가 기존 서비스와 조금 다른 새로운 서비스가 추가되는 문제도 있었습니다. 그리고 기존 모듈을 수정하는 대신 복사본을 만들고 필요한 변경 사항을 추가해야 했습니다.

본질적으로 Terraform은 실제 언어가 아닙니다. 이것은 선언입니다. 무언가를 선언해야 한다면 선언합니다. 그리고 그것은 모두 작동합니다.

어느 시점에서 내 끌어오기 요청 중 하나가 논의되고 있을 때 동료 중 한 명이 눈송이를 만들 필요가 없다고 말했습니다. 나는 그가 무슨 뜻인지 궁금했다. 세상에는 동일한 눈송이가 두 개 없으며 모두 약간 다르다는 과학적 사실이 있습니다. 그리고 이 말을 듣자마자 나는 즉시 Terraform 코드의 전체 무게를 느꼈습니다. 버전 간에 이동해야 할 때 Terraform에서는 체인 변경이 필요했기 때문입니다. 즉, 코드가 더 이상 다음 버전과 호환되지 않습니다. 그리고 인프라를 다음 버전의 Terraform으로 가져오기 위해 인프라에 있는 파일의 거의 절반을 다루는 풀 요청을 해야 했습니다.

그리고 그러한 눈송이가 나타난 후, 우리가 사용했던 모든 Terraform 코드는 크고 큰 눈 더미로 변했습니다.

작업 외부에 있는 외부 개발자의 경우 이는 그에게 그다지 중요하지 않습니다. 왜냐하면 그가 끌어오기 요청을 하고 그의 리소스가 시작되었기 때문입니다. 그게 전부입니다. 더 이상 그의 관심사가 아닙니다. 그리고 모든 것이 정상인지 확인하는 DevOps 팀은 이러한 모든 변경 작업을 수행해야 합니다. 그리고 이러한 변경의 비용은 눈송이가 추가될 때마다 매우 많이 증가했습니다.

세미나에 참석한 한 학생이 칠판에 분필로 완벽한 원 두 개를 그리는 방법에 대한 이야기가 있습니다. 그리고 선생님은 그가 나침반 없이도 그토록 원활하게 그림을 그릴 수 있었던 것에 놀랐습니다. 학생은 이렇게 대답합니다. “아주 간단합니다. 저는 군대에서 고기 분쇄기를 돌리는 데 XNUMX년을 보냈습니다.”

그리고 제가 이 프로젝트에 참여한 XNUMX년 중 약 XNUMX년 동안 Terraform을 해왔습니다. 그리고 물론 Terraform 코드를 단순화하고 프로그래밍 언어처럼 작업하며 이 코드를 최신 상태로 유지해야 하는 개발자의 부담을 줄이는 방법에 대한 몇 가지 요령과 조언이 있습니다.

제가 가장 먼저 시작하고 싶은 것은 Symlink입니다. Terraform에는 반복적인 코드가 많이 있습니다. 예를 들어, 인프라를 생성하는 거의 모든 지점에서 공급자에 대한 호출은 동일합니다. 그리고 별도의 폴더에 넣는 것이 논리적입니다. 그리고 공급자가 이 파일에 대한 Symlink를 만들어야 하는 경우마다 마찬가지입니다.

예를 들어, 프로덕션에서는 일부 외부 Amazon 계정에 대한 액세스 권한을 얻을 수 있는 역할을 맡습니다. 하나의 파일을 변경하면 리소스 트리의 나머지 모든 파일은 Terraform이 액세스할 Amazon 세그먼트를 알 수 있도록 필요한 권한을 갖게 됩니다.

Symlink는 어디에서 실패합니까? 앞서 말했듯이 Terraform에는 상태 파일이 있습니다. 그리고 그들은 아주 아주 멋집니다. 하지만 문제는 Terraform이 맨 먼저 백엔드를 초기화한다는 것입니다. 그리고 이러한 매개변수에는 어떤 변수도 사용할 수 없으며 항상 텍스트로 작성해야 합니다.

결과적으로 누군가가 새로운 리소스를 만들 때 그는 다른 폴더에서 일부 코드를 복사합니다. 그리고 그는 열쇠나 양동이를 가지고 실수를 할 수도 있습니다. 예를 들어, 그는 샌드박스에서 샌드박스 물건을 만든 다음 프로덕션에서 만듭니다. 따라서 프로덕션 버킷이 샌드박스에서 사용될 수도 있습니다. 물론 금방 찾을 수 있을 것이다. 어떻게든 이 문제를 해결할 수는 있겠지만 그럼에도 불구하고 이는 시간 낭비이고 어느 정도 자원 낭비입니다.

다음에는 무엇을 할 수 있나요? Terraform을 사용하기 전에 초기화해야 합니다. 초기화 시 Terraform은 모든 플러그인을 다운로드합니다. 어느 시점에서 그들은 모놀리스에서 마이크로서비스 아키텍처로 분리되었습니다. 그리고 항상 Terraform init을 수행하여 모든 모듈과 플러그인을 불러와야 합니다.

그리고 먼저 모든 변수를 가져올 수 있는 쉘 스크립트를 사용할 수 있습니다. 쉘 스크립트는 어떤 식으로든 제한되지 않습니다. 둘째, 경로입니다. 저장소에 있는 경로를 항상 상태 파일의 키로 사용하면 그에 따라 여기서 오류가 제거됩니다.

데이터는 어디서 구할 수 있나요? JSON 파일. Terraform을 사용하면 hcl(HashiCorp 구성 언어)뿐만 아니라 JSON으로도 인프라를 작성할 수 있습니다.

JSON은 쉘 스크립트에서 쉽게 읽을 수 있습니다. 따라서 버킷과 함께 구성 파일을 어딘가에 넣을 수 있습니다. 그리고 초기화를 위해 Terraform 코드와 셸 스크립트 모두에서 이 버킷을 사용하세요.

Terraform용 버킷을 보유하는 것이 왜 중요한가요? 원격 상태 파일과 같은 것이 있기 때문입니다. 즉, 어떤 리소스를 올릴 때 Amazon에게 "인스턴스를 올려주세요"라고 알리기 위해서는 필수 파라미터를 많이 지정해야 합니다.

그리고 이러한 식별자는 다른 폴더에 저장됩니다. 그리고 저는 가서 이렇게 말할 수 있습니다. "Terraform, 바로 그 리소스의 상태 파일로 실행하여 이 식별자를 가져와주세요." 따라서 서로 다른 지역이나 환경 사이에 일정한 통일이 나타납니다.

원격 상태 파일을 사용하는 것이 항상 가능한 것은 아닙니다. 예를 들어 VPC를 직접 생성했습니다. 그리고 VPC를 생성하는 Terraform 코드는 서로 다른 VPC를 생성하므로 시간이 매우 오래 걸리고 서로 조정해야 하므로 다음 트릭을 사용할 수 있습니다.

즉, VPC를 만드는 것처럼 보이는 모듈을 만들어 말하자면 식별자를 제공하지만 실제로는 동일한 인스턴스를 생성하는 데 사용할 수 있는 값이 하드코딩된 파일에 불과합니다.

상태 파일을 항상 클라우드에 저장할 필요는 없습니다. 예를 들어, 모듈을 테스트할 때 백엔드 초기화를 사용할 수 있습니다. 여기서 파일은 테스트 시 디스크에 저장됩니다.

이제 테스트에 대해 조금 설명합니다. Terraform에서 무엇을 테스트할 수 있나요? 아마도 많은 것이 가능할 것입니다. 하지만 저는 이 4가지에 대해 이야기하겠습니다.

HashiCorp는 Terraform 코드의 형식을 어떻게 지정해야 하는지 이해하고 있습니다. 그리고 Terraform fmt를 사용하면 이러한 신념에 따라 편집하는 코드의 형식을 지정할 수 있습니다. 따라서 테스트에서는 반드시 HashiCorp가 물려준 서식과 일치하는지 확인해야 괄호 위치 등을 변경할 필요가 없습니다.

다음은 Terraform 유효성 검사입니다. 모든 괄호가 쌍을 이루는지 여부를 확인하는 것 이상의 작업을 수행합니다. 여기서 중요한 것은 무엇입니까? 우리의 인프라는 매우 광범위합니다. 그 안에는 다양한 아빠가 있습니다. 그리고 각각에서 Terraform 유효성 검사를 실행해야 합니다.

따라서 테스트 속도를 높이기 위해 병렬을 사용하여 여러 프로세스를 병렬로 실행합니다.

병렬은 매우 멋진 기능입니다. 사용하세요.

하지만 Terraform이 초기화될 때마다 HashiCorp로 이동하여 "최신 플러그인 버전은 무엇입니까?"라고 묻습니다. 그리고 캐시에 있는 플러그인은 올바른 것인가요, 아니면 잘못된 것인가요?” 그리고 이것은 모든 단계에서 속도가 느려졌습니다.

Terraform에 플러그인이 있는 위치를 알려주면 Terraform은 다음과 같이 말할 것입니다. “좋아요. 아마도 이것이 최신 버전일 것입니다. 아무데도 가지 않고 즉시 Terraform 코드 검증을 시작하겠습니다.”

필요한 플러그인으로 폴더를 채우기 위해 초기화만 하면 되는 매우 간단한 Terraform 코드가 있습니다. 물론 여기서는 코드에 참여하는 모든 공급자를 지정해야 합니다. 그렇지 않으면 Terraform에서 "특정 공급자가 캐시에 없기 때문에 모릅니다."라고 말할 것입니다.

다음은 Terraform 계획입니다. 앞서 말했듯이 개발은 순환적입니다. 우리는 코드를 변경합니다. 그런 다음 인프라에 어떤 변경이 계획되어 있는지 파악해야 합니다.

그리고 인프라가 매우 큰 경우 하나의 모듈을 변경하고 일부 테스트 환경이나 특정 지역을 수정하고 인접한 일부 모듈을 중단할 수 있습니다. 따라서 전체 인프라에 대한 Terraform 계획을 수립하고 어떤 변경이 계획되어 있는지 보여주어야 합니다.

이 작업을 현명하게 수행할 수 있습니다. 예를 들어 종속성을 해결하는 Python 스크립트를 작성했습니다. 그리고 변경된 내용(Terraform 모듈 또는 특정 구성 요소)에 따라 모든 종속 폴더에 대한 계획을 세웁니다.

Terraform 계획은 요청 시 작성해야 합니다. 적어도 그것이 우리가 하는 일입니다.

물론 모든 변경 사항, 모든 커밋에 대해 테스트를 수행하는 것은 좋지만 계획에는 비용이 많이 듭니다. 그리고 끌어오기 요청에서는 “계획을 알려주세요.”라고 말합니다. 로봇이 시작됩니다. 그리고 변경 사항에서 예상되는 모든 계획을 댓글로 보내거나 첨부하세요.

계획은 꽤 비싼 것입니다. Terraform이 Amazon에 가서 “이 인스턴스가 아직 존재합니까?”라고 묻기 때문에 시간이 걸립니다. 이 자동 크기 조정에는 정확히 동일한 매개 변수가 있습니까?” 그리고 속도를 높이려면 새로고침=false와 같은 매개변수를 사용할 수 있습니다. 이는 Terraform이 S3에서 상태를 다운로드한다는 의미입니다. 그리고 그 상태는 아마존의 상태와 정확히 일치할 것이라고 믿을 것입니다.

이러한 Terraform 계획은 훨씬 빠르게 진행되지만 상태는 인프라와 일치해야 합니다. 즉, 어딘가에서 Terraform 새로 고침을 시작해야 합니다. Terraform 새로 고침은 바로 이를 수행합니다. 즉, 상태가 실제 인프라의 내용과 일치합니다.

그리고 우리는 안전에 관해 이야기해야 합니다. 이것이 우리가 시작해야 했던 곳입니다. Terraform을 실행하고 인프라에서 Terraform을 실행하는 경우 취약점이 있습니다. 즉, 본질적으로 코드를 실행하고 있는 것입니다. 그리고 끌어오기 요청에 일종의 악성 코드가 포함되어 있으면 액세스 권한이 너무 많은 인프라에서 실행될 수 있습니다. 따라서 Terraform 계획을 실행할 때는 주의하세요.

다음으로 이야기하고 싶은 것은 사용자 데이터 테스트입니다.

사용자 데이터란 무엇입니까? Amazon에서는 인스턴스를 생성할 때 인스턴스와 함께 특정 문자, 즉 메타데이터를 보낼 수 있습니다. 인스턴스가 시작되면 일반적으로 이러한 인스턴스에 cloud init가 항상 존재합니다. Cloud init는 이 편지를 읽고 다음과 같이 말합니다. "좋아, 오늘은 내가 로드 밸런서입니다." 그리고 이러한 언약에 따라 그는 몇 가지 행동을 수행합니다.

하지만 안타깝게도 Terraform 계획과 Terraform을 적용하면 사용자 데이터가 이런 종류의 숫자처럼 보입니다. 즉, 그는 단순히 당신에게 해시를 보냅니다. 그리고 계획에서 볼 수 있는 것은 변경 사항이 있는지 또는 해시가 동일하게 유지되는지 여부뿐입니다.

그리고 이것에 주의를 기울이지 않으면 일부 손상된 텍스트 파일이 실제 인프라의 Amazon에 남게 될 수 있습니다.

또는 실행 시 전체 인프라가 아닌 템플릿만 지정할 수도 있습니다. 그리고 코드에는 "이 템플릿을 내 화면에 표시해 주세요."라고 말합니다. 결과적으로 Amazon에서 데이터가 어떻게 보이는지에 대한 인쇄물을 얻을 수 있습니다.

또 다른 옵션은 모듈을 사용하여 사용자 데이터를 생성하는 것입니다. 이 모듈을 적용하게 됩니다. 디스크에 있는 파일을 받습니다. 참고자료와 비교해 보세요. 따라서 어떤 사람이 사용자 데이터를 약간 수정하기로 결정하면 테스트에서는 "좋아, 여기 저기에 몇 가지 변경 사항이 있습니다. 이는 정상입니다."라고 말할 것입니다.

다음으로 이야기하고 싶은 것은 Terraform 적용 자동화입니다.

물론 자동 모드에서 Terraform을 적용하는 것은 상당히 무서운 일입니다. 어떤 변화가 왔는지, 생활 인프라에 얼마나 파괴적인 영향을 미칠 수 있는지 누가 알 수 있기 때문입니다.

테스트 환경에서는 이는 모두 정상입니다. 즉, 테스트 환경을 만들어주는 직업은 모든 개발자에게 필요한 직업이다. 그리고 "모든 것이 나를 위해 일했습니다"와 같은 표현은 재미있는 밈이 아니라 사람이 혼란스러워서 스택을 올리고 이 스택에 대해 몇 가지 테스트를 실행했다는 증거입니다. 그리고 그는 거기에서 모든 것이 괜찮은지 확인하고 이렇게 말했습니다. "좋아, 내가 공개하는 코드는 테스트되었습니다."

비즈니스에 더욱 중요한 프로덕션, 샌드박스 및 기타 환경에서는 누구도 사망하지 않기 때문에 일부 리소스를 부분적으로 매우 안전하게 사용할 수 있습니다. 여기에는 자동 크기 조정 그룹, 보안 그룹, 역할, Route53이 있으며 목록이 상당히 클 수 있습니다. 하지만 무슨 일이 일어나고 있는지 계속 주시하고 자동화된 애플리케이션 보고서를 읽어보세요.

적용하는 것이 위험하거나 무서운 경우(예: 데이터베이스의 일부 영구 리소스인 경우) 인프라의 일부에 적용되지 않은 변경 사항이 있다는 보고를 받습니다. 엔지니어는 감독하에 작업을 시작하거나 콘솔에서 작업을 수행합니다.

Amazon에는 Terminate 보호 기능이 있습니다. 그리고 어떤 경우에는 필요하지 않은 변경으로부터 보호할 수도 있습니다. 즉, Terraform은 Amazon에 가서 "다른 인스턴스를 만들려면 이 인스턴스를 종료해야 합니다."라고 말했습니다. 그리고 아마존은 “죄송합니다. 오늘은 아닙니다. 종료 보호 기능이 있습니다."

그리고 금상첨화는 코드 최적화입니다. Terraform 코드로 작업할 때 매우 많은 수의 매개변수를 모듈에 전달해야 합니다. 이는 일종의 리소스를 생성하는 데 필요한 매개변수입니다. 그리고 코드는 모듈에서 모듈로, 모듈에서 모듈로, 특히 모듈이 중첩된 경우 전달해야 하는 대규모 매개변수 목록으로 변합니다.

그리고 읽기가 매우 어렵습니다. 이것을 검토하는 것은 매우 어렵습니다. 그리고 일부 매개변수는 검토를 거치는데 정확히 필요한 매개변수가 아닌 것으로 밝혀지는 경우가 많습니다. 그리고 나중에 고치려면 시간과 비용이 듭니다.

따라서 특정 값 트리를 포함하는 복잡한 매개변수와 같은 것을 사용하는 것이 좋습니다. 즉, 어떤 환경에서 갖고 싶은 모든 값이 들어있는 일종의 폴더가 필요합니다.

그리고 이 모듈을 호출하면 하나의 공통 모듈, 즉 전체 인프라에 대해 동일하게 작동하는 공통 모듈에서 생성되는 트리를 얻을 수 있습니다.

이 모듈에서는 Terraform의 최신 기능을 로컬로 사용하여 몇 가지 계산을 수행할 수 있습니다. 그런 다음 하나의 출력으로 배열 해시 등을 포함할 수 있는 복잡한 매개변수를 제공합니다.

이것이 내가 찾은 모든 최고의 발견이 끝난 곳입니다. 그리고 저는 콜럼버스에 관한 이야기를 하고 싶습니다. 그가 인도를 발견하기 위한 탐험을 위해 돈을 찾고 있었을 때(당시 그가 생각했던 것처럼) 아무도 그의 말을 믿지 않았고 그것이 불가능하다고 생각했습니다. 그런 다음 그는 “계란이 떨어지지 않도록 조심하십시오”라고 말했습니다. 매우 부유하고 아마도 똑똑한 사람들인 모든 은행가들은 어떻게든 계란을 놓으려고 노력했지만 계란은 계속 떨어졌습니다. 그런 다음 콜럼버스는 계란을 가져다가 조금 눌렀습니다. 껍질은 구겨졌고 알은 움직이지 않았습니다. 그들은 "아, 그건 너무 쉽잖아!"라고 말했어요. 그러자 콜럼버스는 이렇게 대답했습니다. “그렇습니다. 너무 단순합니다. 그리고 내가 인도를 개방하면 모두가 이 무역로를 이용할 것입니다."

그리고 제가 방금 말씀드린 내용은 아마 아주 단순하고 사소한 것일 겁니다. 그리고 그것들에 대해 배우고 사용하기 시작하면 순서대로 진행됩니다. 그러니 이점을 활용하세요. 그리고 이것이 당신에게 완전히 정상적인 일이라면 적어도 당신은 계란이 떨어지지 않도록 계란을 놓는 방법을 알고 있습니다.

합시다.

• 눈송이를 피하십시오. 눈송이가 적을수록 대규모 인프라 전반에 걸쳐 변경을 수행하는 데 필요한 리소스도 줄어듭니다.
• 끊임없는 변화. 즉, 코드에 일부 변경 사항이 발생하면 가능한 한 빨리 인프라가 이러한 변경 사항을 준수하도록 해야 합니다. XNUMX~XNUMX개월 뒤에 누군가가 Elasticsearch를 보러 와서 Terraform 계획을 세웠는데, 예상하지 못한 변화가 잔뜩 일어나는 상황은 있어서는 안 됩니다. 그리고 모든 것을 다시 정리하는 데는 많은 시간이 걸립니다.
• 테스트 및 자동화. 코드가 테스트와 기능으로 더 많이 다루어질수록 모든 것을 올바르게 수행하고 있다는 확신이 커집니다. 그리고 자동 전달은 귀하의 신뢰도를 여러 배로 높여줄 것입니다.
• 테스트 환경과 프로덕션 환경의 코드는 거의 동일해야 합니다. 실제로 프로덕션은 여전히 ​​약간 다르며 테스트 환경을 넘어서는 약간의 뉘앙스가 여전히 있기 때문입니다. 그러나 그럼에도 불구하고, 이는 플러스 또는 마이너스로 보장될 수 있습니다.
• 그리고 Terraform 코드가 많고 이 코드를 최신 상태로 유지하는 데 많은 시간이 걸리는 경우 리팩토링하여 좋은 모양으로 만드는 것이 결코 늦지 않습니다.

• 불변의 인프라. 예정대로 AMI 배송.
• 항목이 많고 이를 일관된 순서로 유지하려는 경우 Route53의 구조입니다.
• API 비율 제한에 맞서 싸우고 있습니다. 이때 아마존은 “그렇습니다. 더 이상 요청을 받아들일 수 없습니다. 잠시만 기다려주세요.”라고 말합니다. 그리고 사무실의 절반은 인프라를 시작할 수 있을 때까지 기다리고 있습니다.
• 스팟 인스턴스. 아마존은 저렴한 이벤트가 아니며 스팟을 통해 상당히 많은 비용을 절약할 수 있습니다. 그리고 거기에서 그것에 대한 전체 보고서를 말할 수 있습니다.
• 보안 및 IAM 역할.
• 잃어버린 자원을 찾아 아마존에 출처를 알 수 없는 인스턴스가 있으면 돈을 먹습니다. 인스턴스 비용이 월 $100-150이더라도 연간 $1가 넘습니다. 그러한 자원을 찾는 것은 수익성 있는 사업입니다.
• 그리고 예약된 인스턴스.

그게 전부입니다. Terraform은 매우 훌륭합니다. 사용해보세요. 감사합니다!

질문

신고해 주셔서 감사합니다! 상태 파일은 S3에 있는데 여러 사람이 이 상태 파일을 가져와서 확장하려고 할 수 있는 문제를 어떻게 해결합니까?

우선, 우리는 서두르지 않습니다. 둘째, 우리가 일부 코드를 작업 중임을 보고하는 플래그가 있습니다. 즉, 인프라가 매우 크다는 사실에도 불구하고 누군가가 지속적으로 무언가를 사용하고 있다는 의미는 아닙니다. 그리고 활성 단계가 있을 때 이것이 문제가 되었는데, 상태 파일을 Git에 저장했습니다. 이것이 중요했습니다. 그렇지 않으면 누군가가 상태 파일을 만들고 모든 작업을 계속하려면 수동으로 모아야 했습니다. 이제는 그런 문제가 없습니다. 일반적으로 Terraform은 이 문제를 해결했습니다. 그리고 무언가가 지속적으로 변경되는 경우 잠금 장치를 사용하여 말한 내용을 방지할 수 있습니다.

오픈소스를 사용하시나요, 아니면 엔터프라이즈를 사용하시나요?

기업이 없습니다. 즉, 모든 것을 무료로 다운로드할 수 있습니다.

내 이름은 스타니슬라프입니다. 나는 작은 추가를하고 싶었습니다. 인스턴스를 종료할 수 없게 만드는 Amazon 기능에 대해 이야기하셨습니다. 이는 Terraform 자체에도 있으며 Life Second 블록에서 변경 금지 또는 파괴 금지를 지정할 수 있습니다.

시간이 제한되어 있었습니다. 좋은 지적.

나도 두 가지를 묻고 싶었다. 먼저 테스트에 관해 이야기하셨습니다. 테스트 도구를 사용하셨나요? Test Kitchen 플러그인에 대해 들었습니다. 아마도 뭔가가 더 있을 것입니다. 그리고 지역적 가치에 대해서도 묻고 싶습니다. 입력 변수와 근본적으로 어떻게 다른가요? 그리고 왜 로컬 값을 통해서만 매개변수화할 수 없나요? 이 주제를 알아 내려고 노력했지만 왠지 스스로 알아낼 수 없었습니다.

이 방 밖에서 더 자세한 이야기를 나눌 수 있습니다. 우리의 테스트 도구는 완전히 자체 제작되었습니다. 테스트할 것이 없습니다. 일반적으로 자동화된 테스트가 인프라를 어딘가에서 선택하고 정상인지 확인한 다음 인프라가 여전히 양호한 상태라는 보고서와 함께 모든 것을 파괴하는 옵션이 있습니다. 테스트 스택이 매일 실행되기 때문에 이것이 없습니다. 그리고 그것으로 충분합니다. 그리고 무언가가 깨지기 시작하면 우리가 다른 곳에서 확인하지 않아도 깨지기 시작할 것입니다.

지역적 가치에 관해서는 방 밖에서 대화를 계속합시다.

안녕하세요! 신고해 주셔서 감사합니다! 매우 유익합니다. 인프라를 설명하는 데 동일한 유형의 코드가 많이 있다고 말씀하셨습니다. 이 코드 생성을 고려해 보셨나요?

좋은 질문입니다. 감사합니다! 요점은 코드형 인프라를 사용할 때 코드를 보고 해당 코드 뒤에 어떤 인프라가 있는지 이해한다고 가정한다는 것입니다. 코드가 생성되면 어떤 종류의 인프라가 있을지 이해하기 위해 어떤 코드가 생성될지 상상해야 합니다. 코드를 생성하고 커밋하면 본질적으로 동일한 일이 발생합니다. 그래서 우리는 우리가 쓴 길을 따랐고, 그것을 얻었습니다. 게다가 발전기는 우리가 만들기 시작했을 때 조금 나중에 나타났습니다. 그리고 바꾸기에는 이미 너무 늦었습니다.

jsonnet에 대해 들어본 적이 있나요?

아니오.

보세요, 이건 정말 멋진 일이에요. 이를 적용하고 데이터 구조를 생성할 수 있는 구체적인 사례를 봅니다.

면도기에 대한 농담처럼 발전기는 가지고 있으면 좋습니다. 즉, 처음에는 얼굴이 다르지만 나중에는 모두가 같은 얼굴을 갖게 됩니다. 발전기는 아주 잘 작동합니다. 그런데 안타깝게도 우리의 얼굴은 조금 다릅니다. 이것은 문제예요.

그냥보세요. 감사합니다!

제 이름은 Maxim이고 Sberbank 출신입니다. Terraform을 프로그래밍 언어와 동등한 수준으로 가져오려는 방법에 대해 조금 이야기하셨습니다. Ansible을 사용하는 것이 더 쉽지 않나요?

이것들은 매우 다른 것입니다. Ansible에서 리소스를 생성할 수 있고, Puppet은 Amazon에서 리소스를 생성할 수 있습니다. 그러나 Terraform은 바로 날카롭게 만들어졌습니다.

아마존만 있나요?

아마존만 있는 것은 아닙니다. 거의 아마존만 있어요. 그러나 핵심 기능은 Terraform이 기억한다는 것입니다. Ansible에서 "5개의 인스턴스를 주세요"라고 말하면 인스턴스가 증가하고 "이제 3개가 필요합니다."라고 말합니다. 그러면 Terraform은 "좋아요, 2개를 죽이겠습니다"라고 말하고 Ansible은 "좋아요, 여기 3개를 주세요"라고 말합니다. 총 8개.

안녕하세요! 신고해 주셔서 감사합니다. Terraform에 대해 듣는 것은 매우 흥미로웠습니다. Terraform은 아직 안정적인 릴리스가 없기 때문에 Terraform을 매우 주의 깊게 다루어야 한다는 사실에 대해 즉시 작은 의견을 말씀드리고 싶습니다.

저녁 식사에 좋은 숟가락. 즉, 해결책이 필요하면 불안정한 것을 미루는 경우도 있는데, 효과가 있어서 도움이 됐다.

질문은 이것이다. 원격 백엔드를 사용하고 S 3를 사용합니다. 공식 백엔드를 사용하는 것은 어떻습니까?

공식적인?

테라폼 클라우드.

그 사람은 언제 나타났나요?

약 4 개월 전

4년 전에 나타났다면 아마도 귀하의 질문에 대답했을 것입니다.

이미 내장된 기능과 잠금 장치가 있으며 상태 파일을 저장할 수 있습니다. 시도 해봐. 그러나 나는 그것을 테스트하지 않았습니다.

우리는 빠른 속도로 움직이는 대형 열차를 타고 여행하고 있습니다. 그리고 차 몇 대를 가져다가 버릴 수도 없습니다.

눈송이에 관해 이야기했는데 왜 Branch를 사용하지 않았나요? 왜 그렇게 되지 않았나요?

우리의 접근 방식은 전체 인프라가 하나의 저장소에 있다는 것입니다. Terraform, Puppet, 이와 관련된 모든 스크립트는 모두 하나의 저장소에 있습니다. 이렇게 하면 점진적인 변경 사항이 차례로 테스트되는지 확인할 수 있습니다. 그것이 여러 가지 지점이라면 그러한 프로젝트를 유지하는 것이 거의 불가능할 것입니다. XNUMX개월이 지나고 너무 많이 갈라져 일종의 처벌에 불과합니다. 이것이 제가 리팩토링하기 전에 탈출하고 싶었던 것입니다.

그럼 작동하지 않나요?

이것은 전혀 작동하지 않습니다.

지점에서는 폴더 슬라이드를 잘라냈습니다. 즉, 예를 들어 팀 A에는 자체 폴더가 있고 팀 B에는 자체 폴더가 있는 것처럼 각 테스트 스택에 대해 이 작업을 수행하면 이 작업도 작동하지 않습니다. 우리는 모든 사람에게 적합할 만큼 유연한 통합 테스트 환경 코드를 만들었습니다. 즉, 우리는 하나의 코드를 제공했습니다.

안녕하세요! 내 이름은 유라예요! 신고해 주셔서 감사합니다! 모듈에 관한 질문입니다. 모듈을 사용하고 있다고 말합니다. 다른 사람의 변경 사항과 호환되지 않는 하나의 모듈이 변경된 경우 문제를 어떻게 해결합니까? 당신은 어떻게든 모듈의 버전을 관리하고 있거나 두 가지 요구 사항을 충족시키기 위해 wunderwaffle을 가져오려고 노력하고 있습니까?

이것은 큰 눈 더미 문제입니다. 무해한 변화로 인해 인프라의 일부가 손상될 수 있는 경우가 바로 이것이다. 그리고 이것은 오랜 시간이 흐른 후에야 눈에 띄게 될 것입니다.

즉, 아직 해결되지 않았습니까?

범용 모듈을 만듭니다. 눈송이를 피하십시오. 그리고 모든 것이 잘 될 것입니다. 보고서의 후반부는 이를 방지하는 방법에 관한 것입니다.

안녕하세요! 신고해 주셔서 감사합니다! 나는 명확히하고 싶습니다. 무대 뒤에는 내가 찾아온 큰 더미가 있었습니다. Puppet과 역할 분배는 어떻게 통합됩니까?

사용자 데이터.

즉, 그냥 파일을 뱉어내고 어떻게든 실행한다는 건가요?

사용자 데이터는 메모입니다. 즉, 이미지의 복제본을 만들 때 데몬이 그곳으로 올라가서 그가 누구인지 알아내려고 그가 로드 밸런서라는 메모를 읽습니다.

즉, 이것은 일종의 별도의 프로세스로 제공되는 것입니까?

우리는 그것을 발명하지 않았습니다. 우리는 그것을 사용합니다.

안녕하세요! 사용자 데이터에 관해 질문이 있습니다. 당신은 거기에 문제가 있고 누군가가 뭔가를 잘못된 곳으로 보낼 수도 있다고 말했습니다. 사용자 데이터가 무엇을 참조하는지 항상 명확하게 알 수 있도록 동일한 Git에 사용자 데이터를 저장할 수 있는 방법이 있나요?

우리는 템플릿에서 사용자 데이터를 생성합니다. 즉, 특정 수의 변수가 사용됩니다. 그리고 Terraform은 최종 결과를 생성합니다. 따라서 템플릿만 보고 무슨 일이 일어날지 말할 수는 없습니다. 모든 문제는 개발자가 이 변수에 문자열을 전달한다고 생각하는데 배열이 사용된다는 사실과 관련되어 있기 때문입니다. 그리고 그-bam과 나-그렇게, 다음 줄, 모든 것이 깨졌습니다. 이것이 새로운 리소스이고 사람이 그것을 집어들어 뭔가가 작동하지 않는 것을 발견하면 신속하게 해결됩니다. 그리고 이 자동 크기 조정 그룹이 업데이트되면 어느 시점에서 자동 크기 조정 그룹의 인스턴스가 교체되기 시작합니다. 그리고 쾅, 뭔가 작동하지 않습니다. 아파요.

유일한 해결책은 테스트하는 것임이 밝혀졌습니다.

예, 문제를 확인하고 거기에 테스트 단계를 추가합니다. 즉, 출력도 테스트할 수 있습니다. 그다지 편리하지 않을 수도 있지만 몇 가지 표시를 할 수도 있습니다. 사용자 데이터가 여기에 고정되어 있는지 확인하세요.

내 이름은 티무르입니다. Terraform을 올바르게 구성하는 방법에 대한 보고서가 있다는 것은 매우 멋진 일입니다.

나는 아직 시작도 하지 않았습니다.

아마도 다음 회의에는 있을 것이라고 생각합니다. 간단한 질문이 있습니다. tfvars를 사용하지 않고 별도의 모듈에 값을 하드코딩하는 이유, 즉 왜 tfvars보다 값이 좋은 모듈이 더 나은가요?

즉, 여기에 작성해야 합니까(슬라이드: Production/environment/settings.tf): domain = 변수, domain vpcnetwork, 변수 vpcnetwork 및 stvars – 동일한 내용을 얻을 수 있습니까?

그것이 바로 우리가 하는 일입니다. 예를 들어 설정 소스 모듈을 참조합니다.

본질적으로 이것은 그러한 tfvar입니다. Tfvars는 테스트 환경에서 매우 편리합니다. 나는 큰 인스턴스와 작은 인스턴스를 위한 tfvar를 가지고 있습니다. 그리고 파일 하나를 폴더에 던졌습니다. 그리고 나는 내가 원하는 것을 얻었습니다. 인프라를 삭감할 때 우리는 모든 것을 보고 즉시 이해할 수 있기를 원합니다. 그래서 여기를 살펴보고 tfvars를 살펴봐야 한다는 것이 밝혀졌습니다.

모든 것을 한곳에 모으는 것이 가능한가요?

예, tfvars는 코드가 하나인 경우입니다. 그리고 그것은 다양한 뉘앙스로 여러 곳에서 사용됩니다. 그런 다음 tfvar를 던져서 뉘앙스를 얻을 것입니다. 그리고 우리는 가장 순수한 형태의 코드형 인프라입니다. 보고 이해했습니다.

안녕하세요! 클라우드 제공업체가 귀하가 만든 Terraform을 방해하는 상황에 직면한 적이 있습니까? 메타데이터를 편집한다고 가정해 보겠습니다. SSH 키가 있습니다. 그리고 Google은 메타데이터와 키를 지속적으로 여기에 배치합니다. 그리고 Terraform은 항상 변경 사항이 있다고 씁니다. 실행할 때마다 아무 변화가 없더라도 그는 항상 이 필드를 지금 업데이트하겠다고 말합니다.

키를 사용하면 인프라의 일부가 이에 의해 영향을 받습니다. 즉, Terraform은 아무것도 변경할 수 없습니다. 우리 손으로도 아무것도 바꿀 수 없습니다. 우리는 지금은 그것과 함께 살 것입니다.

즉, 당신은 이런 일을 겪었지만 아무것도 생각해 내지 못했습니다. 그는 어떻게 그것을하고 스스로합니까?

불행히도 그렇습니다.

안녕하세요! 내 이름은 스타코프 스타니슬라프입니다. 우편. 루 그룹. 태그를 생성하는 문제를 어떻게 해결합니까? 내부로 어떻게 전달합니까? 제가 알기로는 사용자 - 데이터를 통해 호스트 이름을 지정하고 Puppet을 설정하시겠습니까? 그리고 질문의 두 번째 부분입니다. SG에서 이 문제를 어떻게 해결합니까? 즉, 동일한 유형의 수백 개의 인스턴스인 SG를 생성할 때 해당 인스턴스의 올바른 이름은 무엇입니까?

우리에게 매우 중요한 사례에는 아름답게 이름을 지정합니다. 필요하지 않은 것에는 자동 크기 조정 그룹이라는 메모가 있습니다. 그리고 이론적으로는 그것을 해결하고 새 것을 얻을 수 있습니다.

태그 문제는 그런 문제는 없는데 이런 작업이 있습니다. 그리고 인프라가 크고 비용이 많이 들기 때문에 태그를 매우 많이 사용합니다. 그리고 돈이 어디로 가는지 살펴봐야 하므로 태그를 사용하면 돈이 어디로 갔는지 분석할 수 있습니다. 따라서 여기에는 많은 돈을 의미하는 무언가를 찾는 데 소비됩니다.

또 어떤 질문이 있었나요?

SG가 수백 개의 인스턴스를 생성할 때 어떻게든 구별해야 합니까?

아니, 하지 마세요. 각 인스턴스에는 문제가 있음을 보고하는 에이전트가 있습니다. 에이전트가 보고하면 에이전트는 그에 대해 알고 최소한 그의 IP 주소가 존재합니다. 당신은 이미 도망칠 수 있습니다. 둘째, Kubernetes가 아닌 Discovery를 위해 Consul을 사용합니다. 그리고 Consul은 인스턴스의 IP 주소도 표시합니다.

즉, 호스트 이름이 아닌 IP에 특별히 초점을 맞추고 있습니까?

호스트 이름으로 탐색하는 것은 불가능합니다. 즉, 호스트 이름이 많습니다. 인스턴스 식별자(AE 등)가 있습니다. 어딘가에서 찾을 수 있으며 검색에 넣을 수 있습니다.

안녕하세요! 저는 클라우드에 맞춰진 Terraform이 좋은 것임을 깨달았습니다.

뿐만 아니라.

이것이 바로 제가 관심을 갖는 질문입니다. 예를 들어 모든 인스턴스를 Bare Metal로 일괄 이동하기로 결정했다면 어떻게 될까요? 문제가 있을까요? 아니면 여기에 언급된 것과 동일한 Ansible과 같은 다른 제품을 계속 사용해야 합니까?

Ansible은 조금 다른 것에 관한 것입니다. 즉, Ansible은 인스턴스가 시작될 때 이미 작동하고 있습니다. 그리고 Terraform은 인스턴스가 시작되기 전에 작동합니다. 베어메탈로 전환 - 아니요.

지금은 아니지만 비즈니스가 와서 "어서"라고 말할 것입니다.

다른 클라우드로 전환 – 예, 하지만 여기에는 약간 다른 트릭이 있습니다. 더 적은 노력으로 다른 클라우드로 전환할 수 있는 방식으로 Terraform 코드를 작성해야 합니다.

처음에는 전체 인프라가 불가지론적이라는 작업이 설정되었습니다. 즉, 모든 클라우드가 적합해야 하지만 어느 시점에서 비즈니스는 포기하고 다음과 같이 말했습니다. “좋아요, 앞으로 N년 안에 우리는 아무데도 가지 않을 것입니다. 서비스를 사용할 수 있습니다. 아마존에서 "

Terraform을 사용하면 프런트 엔드 작업을 생성하고 PagerDuty, 데이터 문서 등을 구성할 수 있습니다. 꼬리가 많습니다. 그는 사실상 전 세계를 통제할 수 있다.

신고해 주셔서 감사합니다! 저도 Terraform을 4년째 사용하고 있습니다. Terraform으로, 인프라로, 선언적 설명으로 순조롭게 전환하는 단계에서 우리는 누군가가 직접 뭔가를 하고 있고, 여러분은 계획을 세우려고 하는 상황에 직면했습니다. 그리고 거기에 일종의 오류가 발생했습니다. 그러한 문제를 어떻게 처리합니까? 목록에 있는 분실된 자원을 어떻게 찾나요?

주로 손과 눈으로 보고서에서 이상한 점을 발견하면 그곳에서 무슨 일이 일어나고 있는지 분석하거나 단순히 죽입니다. 일반적으로 풀 요청은 흔한 일입니다.

오류가 있으면 롤백되나요? 이 작업을 시도해 보셨나요?

아니요, 이것은 사람이 문제를 본 순간의 결정입니다.

출처 : habr.com