Tôi cũng đang trong tình trạng di chuyển cơ sở hạ tầng AWS hiện có sang Terraform, vì vậy tôi sẽ cố gắng cập nhật câu trả lời khi tôi phát triển.
Tôi đã dựa rất nhiều vào các ví dụ Terraform chính thức và nhiều lần thử và sai để xác định các khu vực mà tôi không chắc chắn.
.tfstate các tập tin
Cấu hình Terraform có thể được sử dụng để cung cấp nhiều hộp trên cơ sở hạ tầng khác nhau, mỗi hộp có thể có một trạng thái khác nhau. Vì nó cũng có thể được điều hành bởi nhiều người, trạng thái này phải ở một vị trí tập trung (như S3) nhưng không git.
Điều này có thể được xác nhận khi nhìn vào Terraform .gitignore .
Kiểm soát nhà phát triển
Mục đích của chúng tôi là cung cấp nhiều quyền kiểm soát hơn đối với cơ sở hạ tầng cho các nhà phát triển trong khi vẫn duy trì kiểm tra đầy đủ (git log) và khả năng kiểm tra các thay đổi (yêu cầu kéo). Với ý nghĩ đó, quy trình làm việc cơ sở hạ tầng mới mà tôi đang hướng tới là:
- Nền tảng cơ bản của AMI thông thường bao gồm các mô-đun có thể tái sử dụng, ví dụ như con rối.
- Cơ sở hạ tầng cốt lõi do DevOps cung cấp bằng Terraform.
- Các nhà phát triển thay đổi cấu hình Terraform trong Git nếu cần (số lượng phiên bản; VPC mới; bổ sung khu vực / vùng khả dụng, v.v.).
- Cấu hình Git được đẩy và một yêu cầu kéo được gửi để được kiểm tra bởi một thành viên của nhóm DevOps.
- Nếu được chấp thuận, hãy gọi webhook tới CI để xây dựng và triển khai (không chắc chắn cách phân vùng nhiều môi trường tại thời điểm này)
Chỉnh sửa 1 - Cập nhật trạng thái hiện tại
Kể từ khi bắt đầu câu trả lời này, tôi đã viết rất nhiều mã TF và cảm thấy thoải mái hơn trong tình trạng của chúng tôi. Chúng tôi đã gặp phải những lỗi và hạn chế trong quá trình thực hiện nhưng tôi chấp nhận đây là đặc điểm của việc sử dụng phần mềm mới, thay đổi nhanh chóng.
Bố trí
Chúng tôi có một cơ sở hạ tầng AWS phức tạp với nhiều VPC, mỗi VPC có nhiều mạng con. Chìa khóa để dễ dàng quản lý điều này là xác định một phân loại linh hoạt bao gồm khu vực, môi trường, dịch vụ và chủ sở hữu mà chúng ta có thể sử dụng để tổ chức mã cơ sở hạ tầng của mình (cả địa hình và con rối).
Mô-đun
Bước tiếp theo là tạo một kho lưu trữ git duy nhất để lưu trữ các mô-đun địa hình của chúng tôi. Cấu trúc dir cấp cao nhất của chúng tôi cho các mô-đun trông như thế này:
tree -L 1 .
Kết quả:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Mỗi người đặt một số mặc định lành mạnh nhưng hiển thị chúng dưới dạng các biến có thể bị ghi đè bởi "keo" của chúng tôi.
Keo dán
Chúng tôi có một kho lưu trữ thứ hai với của chúng tôi glueđể sử dụng các mô-đun được đề cập ở trên. Nó được trình bày phù hợp với tài liệu phân loại của chúng tôi:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tf
Bên trong cấp độ khách hàng, chúng tôi có các .tftệp tài khoản AWS cụ thể cung cấp tài nguyên toàn cầu (như vai trò IAM); tiếp theo là cấp vùng với khóa công khai EC2 SSH; Cuối cùng trong môi trường của chúng tôi ( dev, stg,prod vv) là thiết lập VPC, tạo ví dụ của chúng tôi và nhìn chăm chú kết nối vv được lưu trữ.
Lưu ý phụ: Như bạn có thể thấy, tôi đang đi ngược lại lời khuyên của riêng tôi ở trên giữterraform.tfstate git. Đây là biện pháp tạm thời cho đến khi tôi chuyển sang S3 nhưng phù hợp với tôi vì tôi hiện là nhà phát triển duy nhất.
Bước tiếp theo
Đây vẫn là một quy trình thủ công và chưa có trong Jenkins nhưng chúng tôi đang chuyển một cơ sở hạ tầng khá lớn, phức tạp và cho đến nay rất tốt. Như tôi đã nói, ít lỗi nhưng sẽ tốt!
Chỉnh sửa 2 - Thay đổi
Đã gần một năm kể từ khi tôi viết câu trả lời đầu tiên này và trạng thái của cả Terraform và bản thân tôi đã thay đổi đáng kể. Bây giờ tôi đang ở một vị trí mới khi sử dụng Terraform để quản lý một cụm Azure và Terraform bây giờ là như vậy v0.10.7.
Tiểu bang
Mọi người đã nhiều lần nói với tôi rằng nhà nước không nên sử dụng Git - và họ đã đúng. Chúng tôi đã sử dụng điều này như một biện pháp tạm thời với một nhóm hai người dựa vào giao tiếp và kỷ luật của nhà phát triển. Với một nhóm lớn hơn, phân tán, chúng tôi hiện đang tận dụng hoàn toàn trạng thái từ xa trong S3 với khóa do DynamoDB cung cấp. Lý tưởng nhất là điều này sẽ được chuyển sang lãnh sự bây giờ là v1.0 để cắt các nhà cung cấp đám mây chéo.
Mô-đun
Trước đây chúng tôi đã tạo và sử dụng các mô-đun nội bộ. Điều này vẫn xảy ra nhưng với sự ra đời và phát triển của sổ đăng ký Terraform, chúng tôi cố gắng sử dụng chúng làm cơ sở ít nhất.
Cấu trúc tệp
Vị trí mới có cách phân loại đơn giản hơn nhiều chỉ với hai môi trường infx - devvà prod. Mỗi biến có các biến và kết quả đầu ra riêng, sử dụng lại các mô-đun của chúng tôi đã tạo ở trên. Nhà remote_statecung cấp cũng giúp chia sẻ kết quả đầu ra của các tài nguyên đã tạo giữa các môi trường. Kịch bản của chúng tôi là các miền phụ trong các nhóm tài nguyên Azure khác nhau đến một TLD được quản lý toàn cầu.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Lập kế hoạch
Một lần nữa với những thách thức bổ sung của một nhóm phân tán, giờ đây chúng tôi luôn lưu đầu ra của terraform planlệnh. Chúng tôi có thể kiểm tra và biết những gì sẽ được chạy mà không có rủi ro về một số thay đổi giữa planvàapply giai đoạn giai đoạn (mặc dù việc khóa giúp ích cho việc này). Hãy nhớ xóa tệp kế hoạch này vì nó có thể chứa các biến "bí mật" văn bản thuần túy.
Nhìn chung, chúng tôi rất hài lòng với Terraform và tiếp tục học hỏi và cải thiện với các tính năng mới được thêm vào.