Trình bày cơ sở hạ tầng dưới dạng mã ở định dạng văn bản có thể lặp lại là cách thực hành đơn giản và tốt nhất cho các hệ thống không yêu cầu phải sử dụng chuột. Thực hành này có một tên - , và cho đến nay có hai công cụ phổ biến để triển khai nó, đặc biệt là trong AWS: и .
So sánh trải nghiệm với Terraform và CloudFormation
Trước khi đến (anh ấy ) Tôi đã làm việc và sử dụng Terraform trong ba năm. Ở nơi mới, tôi cũng đã sử dụng Terraform bằng tất cả khả năng của mình và sau đó công ty đã đẩy mạnh quá trình chuyển đổi sang mọi thứ giống như Amazon, bao gồm cả CloudFormation. Tôi đã siêng năng phát triển các phương pháp hay nhất cho cả hai và đã sử dụng cả hai công cụ trong các quy trình làm việc rất phức tạp trên toàn tổ chức. Sau đó, sau khi cân nhắc kỹ lưỡng tác động của việc di chuyển từ Terraform sang CloudFormation, tôi tin rằng Terraform có lẽ là lựa chọn tốt nhất cho tổ chức.
địa hình khủng khiếp
Phần mềm thử nghiệm
Terraform thậm chí còn chưa phát hành phiên bản 1.0, đó là lý do chính đáng để không sử dụng nó. Nó đã thay đổi rất nhiều kể từ lần đầu tiên tôi thử nó, nhưng hồi đó terraform apply thường bị hỏng sau vài lần cập nhật hoặc đơn giản là sau vài năm sử dụng. Tôi sẽ nói rằng “mọi thứ giờ đã khác rồi”, nhưng… dường như mọi người đều nói vậy, phải không? Có những thay đổi không tương thích với các phiên bản trước, mặc dù chúng phù hợp và thậm chí có cảm giác như cú pháp và tính trừu tượng của kho tài nguyên hiện là thứ chúng ta cần. Nhạc cụ có vẻ đã thực sự tốt hơn, nhưng... :-0
Mặt khác, AWS đã làm rất tốt việc duy trì khả năng tương thích ngược. Điều này có thể là do các dịch vụ của họ thường được kiểm tra kỹ lưỡng trong tổ chức và chỉ sau đó được đổi tên mới được xuất bản. Vì vậy, “họ đã cố gắng hết sức” là một cách nói nhẹ nhàng. Việc duy trì khả năng tương thích ngược với các API cho một hệ thống đa dạng và phức tạp như AWS là điều cực kỳ khó khăn. Bất kỳ ai đã từng phải duy trì các API công khai được sử dụng rộng rãi đều nên hiểu việc thực hiện điều đó khó khăn như thế nào trong nhiều năm như vậy. Nhưng trong trí nhớ của tôi, hoạt động của CloudFormation chưa bao giờ thay đổi trong nhiều năm qua.
Gặp chân... là viên đạn
Theo như tôi biết, hãy xóa tài nguyên người ngoài cuộc Không thể thực hiện được ngăn xếp CloudFormation từ ngăn xếp CF của bạn. Điều này cũng đúng với Terraform. Nó cho phép bạn nhập tài nguyên hiện có vào ngăn xếp của mình. Chức năng có thể nói là tuyệt vời, nhưng đi kèm với sức mạnh to lớn là trách nhiệm lớn lao. Bạn chỉ cần thêm tài nguyên vào ngăn xếp và trong khi làm việc với ngăn xếp của mình, bạn không thể xóa hoặc thay đổi tài nguyên này. Một ngày nọ nó phản tác dụng. Một ngày nọ trên Twitch, ai đó đã vô tình nhập nhóm bảo mật AWS của người khác vào ngăn xếp Terraform của riêng họ trong khi không có ý đồ xấu nào. Tôi đã nhập một số lệnh và... nhóm bảo mật (cùng với lưu lượng truy cập đến) biến mất.
địa hình tuyệt vời
Phục hồi từ trạng thái không đầy đủ
Đôi khi CloudFormation không chuyển đổi hoàn toàn từ trạng thái này sang trạng thái khác. Đồng thời, anh ta sẽ cố gắng quay lại cái trước đó. Thật đáng tiếc là điều này không phải lúc nào cũng khả thi. Việc gỡ lỗi những gì xảy ra sau đó có thể khá đáng sợ - bạn không bao giờ biết liệu CloudFormation có vui mừng khi bị hack hay không - thậm chí chỉ để sửa nó. Có thể quay lại trạng thái trước đó hay không, anh thực sự không biết phải xác định thế nào và mặc định treo hàng giờ chờ đợi một phép màu.
Mặt khác, Terraform có xu hướng phục hồi sau các quá trình chuyển đổi thất bại một cách duyên dáng hơn nhiều và cung cấp các công cụ sửa lỗi nâng cao.
Thay đổi rõ ràng hơn về trạng thái tài liệu
“Được rồi, bộ cân bằng tải, bạn đang thay đổi. Nhưng bằng cách nào?"
— người kỹ sư lo lắng, sẵn sàng nhấn nút “chấp nhận”.
Đôi khi tôi cần thực hiện một số thao tác với bộ cân bằng tải trong ngăn xếp CloudFormation, chẳng hạn như thêm số cổng hoặc thay đổi nhóm bảo mật. ClouFormation hiển thị các thay đổi kém. Tôi, bằng mọi cách, kiểm tra kỹ tệp yaml mười lần để đảm bảo rằng tôi không xóa bất kỳ thứ gì cần thiết và không thêm bất kỳ thứ gì không cần thiết.
Terraform minh bạch hơn nhiều về vấn đề này. Đôi khi anh ấy thậm chí còn quá minh bạch (đọc là: nhàm chán). May mắn thay, phiên bản mới nhất bao gồm tính năng hiển thị các thay đổi được cải thiện để giờ đây bạn có thể biết chính xác những gì đang thay đổi.
Tính linh hoạt
Viết phần mềm ngược.
Nói một cách thẳng thắn, đặc điểm quan trọng nhất của phần mềm tồn tại lâu dài là khả năng thích ứng với sự thay đổi. Viết ngược bất kỳ phần mềm nào. Tôi thường mắc sai lầm khi sử dụng một dịch vụ “đơn giản” và sau đó bắt đầu nhồi nhét mọi thứ vào một ngăn xếp CloudFormation hoặc Terraform duy nhất. Và tất nhiên, nhiều tháng sau, người ta phát hiện ra rằng tôi đã hiểu sai mọi thứ, và dịch vụ này thực sự không hề đơn giản! Và bây giờ tôi cần bằng cách nào đó chia một ngăn xếp lớn thành các thành phần nhỏ. Khi bạn làm việc với CloudFormation, điều này chỉ có thể được thực hiện bằng cách trước tiên tạo lại ngăn xếp hiện có và tôi không làm điều này với cơ sở dữ liệu của mình. Mặt khác, Terraform cho phép phân tích ngăn xếp và chia nó thành các phần nhỏ hơn dễ hiểu hơn.
Các mô-đun trong git
Chia sẻ mã Terraform trên nhiều ngăn xếp dễ dàng hơn nhiều so với chia sẻ mã CloudFormation. Với Terraform, bạn có thể đặt mã của mình vào kho lưu trữ git và truy cập mã đó bằng cách sử dụng kiểm soát phiên bản ngữ nghĩa. Bất kỳ ai có quyền truy cập vào kho lưu trữ này đều có thể sử dụng lại mã được chia sẻ. CloudFormation tương đương với S3, nhưng nó không có cùng lợi ích và không có lý do gì chúng ta nên từ bỏ git để chuyển sang S3.
Tổ chức đã phát triển và khả năng chia sẻ các ngăn xếp chung đã đạt đến mức quan trọng. Terraform làm cho việc này trở nên dễ dàng và tự nhiên, trong khi CloudFormation sẽ khiến bạn phải vượt qua nhiều thử thách trước khi bạn có thể làm được điều gì đó như thế này.
Hoạt động dưới dạng mã
“Hãy viết kịch bản cho nó và được thôi.”
—một kỹ sư 3 năm trước khi phát minh ra xe đạp Terraform.
Khi nói đến phát triển phần mềm, Go hay chương trình Java không chỉ là mã.
Mã dưới dạng mã
Ngoài ra còn có cơ sở hạ tầng mà nó hoạt động.
Cơ sở hạ tầng như Mã
Nhưng cô ấy đến từ đâu? Làm thế nào để theo dõi nó? Mã của bạn tồn tại ở đâu? Nhà phát triển có cần quyền truy cập không?
Hoạt động dưới dạng mã
Trở thành nhà phát triển phần mềm không chỉ có nghĩa là viết mã.
AWS không phải là duy nhất: bạn có thể sử dụng các nhà cung cấp khác. SignalFx, PagerDuty hoặc Github. Có thể bạn có máy chủ Jenkins nội bộ cho CI/CD hoặc bảng điều khiển Grafana nội bộ để theo dõi. Infra as Code được chọn vì nhiều lý do khác nhau và mỗi lý do đều quan trọng như nhau đối với mọi thứ liên quan đến phần mềm.
Khi tôi làm việc tại Twitch, chúng tôi đã tăng tốc các dịch vụ bên trong hệ thống nhúng và AWS hỗn hợp của Amazon. Chúng tôi đã phát triển và hỗ trợ nhiều dịch vụ vi mô, làm tăng chi phí hoạt động. Các cuộc thảo luận đã diễn ra như thế này:
- Я: Chết tiệt, có quá nhiều cử chỉ để ép xung một microservice. Tôi sẽ phải sử dụng rác này để tạo tài khoản AWS (chúng tôi đã truy cập 2 tài khoản trên dịch vụ vi mô), sau đó là cái này để thiết lập cảnh báo, cái này cho kho lưu trữ mã và cái này cho danh sách email, rồi cái này...
- Chỉ huy: Hãy viết kịch bản cho nó và được thôi.
- Я: Được rồi, nhưng bản thân kịch bản sẽ thay đổi. Chúng tôi sẽ cần một cách để kiểm tra xem tất cả các gizmos tích hợp sẵn của Amazon này đã được cập nhật chưa.
- Chỉ huy: Nghe hay đấy. Và chúng tôi sẽ viết một kịch bản cho việc này.
- Я: Tuyệt vời! Và script có thể vẫn cần thiết lập thông số. Liệu anh ấy có chấp nhận chúng không?
- Chỉ huy: Hãy để anh ấy đi đâu anh ấy đi!
- Я: Quá trình này có thể thay đổi và khả năng tương thích ngược sẽ bị mất. Một số loại kiểm soát phiên bản ngữ nghĩa sẽ được yêu cầu.
- Chỉ huy: Ý tưởng tuyệt vời!
- Я: Công cụ có thể được thay đổi thủ công, bên trong giao diện người dùng. Chúng ta sẽ cần một cách để kiểm tra và khắc phục điều này.
…3 năm sau:
- Chỉ huy: Và chúng tôi có địa hình.
Ý nghĩa của câu chuyện là: ngay cả khi bạn tìm hiểu mọi thứ trên Amazon, bạn vẫn đang sử dụng nội dung nào đó không phải từ AWS và các dịch vụ này có trạng thái sử dụng ngôn ngữ cấu hình để duy trì trạng thái đó được đồng bộ hóa.
CloudFormation lambda và mô-đun git terraform
lambda là giải pháp của CloudFormation cho vấn đề logic tùy chỉnh. Với lambda bạn có thể hoặc . Cách tiếp cận này đưa ra những sự phức tạp bổ sung không có trong phiên bản ngữ nghĩa của các mô-đun git của Terraform. Đối với tôi, vấn đề cấp bách nhất là quản lý quyền cho tất cả các lambda người dùng này (và đây là hàng tá tài khoản AWS). Một vấn đề quan trọng khác là vấn đề “cái gì có trước, con gà hay quả trứng?”: nó liên quan đến mã lambda. Bản thân chức năng này là cơ sở hạ tầng và mã, và bản thân nó cần được giám sát và cập nhật. Cái đinh cuối cùng trong quan tài là khó khăn trong việc cập nhật các thay đổi mã lambda về mặt ngữ nghĩa; chúng tôi cũng phải đảm bảo rằng các hành động ngăn xếp không có lệnh trực tiếp sẽ không thay đổi giữa các lần chạy.
Tôi nhớ có lần tôi muốn tạo một bản triển khai canary cho môi trường Elastic Beanstalk bằng bộ cân bằng tải cổ điển. Điều dễ dàng nhất có thể làm là thực hiện triển khai thứ hai cho EB bên cạnh môi trường sản xuất, tiến thêm một bước nữa: kết hợp nhóm triển khai canary tự động mở rộng quy mô với triển khai LB vào môi trường sản xuất. Và vì Terraform sử dụng , điều này sẽ yêu cầu thêm 4 dòng mã trong Terraform. Khi tôi hỏi liệu có giải pháp nào có thể so sánh được trong CloudFormation hay không, họ đã chỉ cho tôi toàn bộ kho lưu trữ git với quy trình triển khai và mọi thứ, tất cả chỉ vì mục đích mà 4 dòng mã Terraform kém cỏi có thể làm được.
Nó phát hiện sự trôi dạt tốt hơn
Đảm bảo thực tế phù hợp với mong đợi.
là một tính năng hoạt động dưới dạng mã rất mạnh mẽ vì nó giúp đảm bảo rằng thực tế phù hợp với mong đợi. Nó có sẵn với cả CloudFormation và Terraform. Nhưng khi khối lượng sản xuất tăng lên, việc tìm kiếm sự trôi dạt trong CloudFormation ngày càng tạo ra nhiều phát hiện sai hơn.
Với Terraform, bạn có các móc vòng đời tiên tiến hơn nhiều để phát hiện sự trôi dạt. Ví dụ bạn nhập lệnh trực tiếp trong định nghĩa nhiệm vụ ECS nếu bạn muốn bỏ qua các thay đổi đối với định nghĩa nhiệm vụ cụ thể mà không bỏ qua các thay đổi đối với toàn bộ quá trình triển khai ECS của mình.
CDK và tương lai của CloudFormation
CloudFormation khó quản lý ở quy mô lớn, đa cơ sở hạ tầng. Nhiều khó khăn trong số này đã được nhận ra và công cụ này cần những thứ như , một khung để xác định cơ sở hạ tầng đám mây bằng mã và chạy nó thông qua AWS CloudFormation. Sẽ rất thú vị để xem tương lai của aws-cdk sẽ như thế nào, nhưng nó sẽ gặp khó khăn khi cạnh tranh với các thế mạnh khác của Terraform; để cập nhật CloudFormation, cần phải có những thay đổi toàn cầu.
Để Terraform không làm bạn thất vọng
Đây là “cơ sở hạ tầng dưới dạng mã” chứ không phải “dưới dạng văn bản”.
Ấn tượng đầu tiên của tôi về Terraform khá tệ. Tôi nghĩ rằng tôi chỉ không hiểu cách tiếp cận. Hầu như tất cả các kỹ sư đều vô tình coi đó là một định dạng văn bản cần được chuyển đổi thành cơ sở hạ tầng mong muốn. ĐỪNG LÀM THEO CÁCH NÀY.
Sự thật hiển nhiên về phát triển phần mềm tốt cũng áp dụng cho Terraform.
Tôi đã thấy nhiều phương pháp được áp dụng để tạo mã tốt lại bị bỏ qua trong Terraform. Bạn đã học nhiều năm để trở thành một lập trình viên giỏi. Đừng từ bỏ trải nghiệm này chỉ vì bạn đang làm việc với Terraform. Sự thật hiển nhiên về phát triển phần mềm tốt áp dụng cho Terraform.
Làm thế nào mã có thể không được ghi lại?
Tôi đã thấy các ngăn xếp Terraform khổng lồ hoàn toàn không có tài liệu. Làm cách nào bạn có thể viết mã trên các trang - hoàn toàn không có tài liệu? Thêm tài liệu giải thích mã Terraform (nhấn mạnh vào từ "code"), tại sao phần này lại quan trọng và bạn làm gì.
Làm cách nào chúng tôi có thể triển khai các dịch vụ từng là một hàm main() lớn?
Tôi đã thấy các ngăn xếp Terraform rất phức tạp được trình bày dưới dạng một mô-đun duy nhất. Tại sao chúng ta không triển khai phần mềm theo cách này? Tại sao chúng ta chia các hàm lớn thành các hàm nhỏ hơn? Câu trả lời tương tự áp dụng cho Terraform. Nếu mô-đun của bạn quá lớn, bạn cần chia nó thành các mô-đun nhỏ hơn.
Công ty của bạn không sử dụng thư viện phải không?
Tôi đã thấy cách các kỹ sư thực hiện một dự án mới bằng cách sử dụng Terraform, sao chép một cách ngu ngốc những phần lớn từ các dự án khác vào dự án của họ, rồi mày mò chúng cho đến khi nó bắt đầu hoạt động. Bạn có làm việc như thế này với mã “chiến đấu” trong công ty của mình không? Chúng tôi không chỉ sử dụng thư viện. Đúng, nhưng về nguyên tắc chúng ta sẽ ở đâu nếu không có thư viện dùng chung?!
Bạn không sử dụng PEP8 hay gofmt phải không?
Hầu hết các ngôn ngữ đều có sơ đồ định dạng tiêu chuẩn, được chấp nhận. Trong Python đây là PEP8. Trong Go - gofmt. Terraform có cái riêng của nó: terraform fmt. Hãy tận hưởng nó vì sức khỏe của bạn!
Bạn sẽ sử dụng React mà không biết JavaScript?
Các mô-đun Terraform có thể đơn giản hóa một số phần của cơ sở hạ tầng phức tạp mà bạn tạo, nhưng điều này không có nghĩa là bạn không thể sửa đổi nó. Bạn muốn sử dụng Terraform một cách chính xác mà không cần hiểu rõ về tài nguyên? Bạn sẽ phải chịu số phận: thời gian sẽ trôi qua và bạn sẽ không bao giờ thành thạo Terraform.
Bạn đang mã hóa bằng singletons hay nội dung phụ thuộc?
Tính năng chèn phụ thuộc là một phương pháp hay nhất được công nhận để phát triển phần mềm và được ưu tiên hơn so với các ứng dụng đơn lẻ. Điều này hữu ích như thế nào trong Terraform? Tôi đã thấy các mô-đun Terraform phụ thuộc vào trạng thái từ xa. Thay vì viết các mô-đun truy xuất trạng thái từ xa, hãy viết một mô-đun lấy tham số. Và sau đó chuyển các tham số này cho mô-đun.
Thư viện của bạn làm tốt 10 điều hay chỉ một điều tuyệt vời?
Thư viện hoạt động tốt nhất là những thư viện tập trung vào một nhiệm vụ mà họ làm rất tốt. Thay vì viết các mô-đun Terraform lớn để cố gắng thực hiện mọi thứ cùng một lúc, hãy xây dựng các phần trong đó có thể làm tốt một việc. Và sau đó kết hợp chúng khi cần thiết.
Làm cách nào để bạn thực hiện các thay đổi đối với thư viện mà không có khả năng tương thích ngược?
Một mô-đun Terraform phổ biến, giống như một thư viện thông thường, cần bằng cách nào đó truyền đạt các thay đổi cho người dùng mà không tương thích ngược. Thật khó chịu khi những thay đổi này xảy ra trong thư viện và cũng thật khó chịu khi những thay đổi không tương thích ngược được thực hiện trong các mô-đun Terraform. Nên sử dụng thẻ git và semver khi sử dụng mô-đun Terraform.
Dịch vụ sản xuất của bạn đang chạy trên máy tính xách tay hay trong trung tâm dữ liệu?
Hashicorp có các công cụ như để chạy địa hình của bạn. Các dịch vụ tập trung này giúp bạn dễ dàng quản lý, kiểm tra và phê duyệt các thay đổi về địa hình.
Bạn không viết bài kiểm tra à?
Các kỹ sư nhận ra rằng code cần phải được kiểm thử nhưng bản thân họ lại thường quên việc kiểm thử khi làm việc với Terraform. Đối với cơ sở hạ tầng, điều này đầy rẫy những khoảnh khắc nguy hiểm. Lời khuyên của tôi là hãy “kiểm tra” hoặc “tạo ví dụ” bằng cách sử dụng các mô-đun có thể được triển khai chính xác để kiểm tra trong CI/CD.
Terraform và microservice
Sự sống còn của các công ty dịch vụ vi mô phụ thuộc vào tốc độ, sự đổi mới và sự gián đoạn của các quy trình làm việc vi dịch vụ mới.
Khía cạnh tiêu cực phổ biến nhất liên quan đến kiến trúc microservice và không thể loại bỏ được, là liên quan đến công việc chứ không phải mã. Nếu bạn nghĩ Terraform chỉ là một cách để tự động hóa phần cơ sở hạ tầng của kiến trúc vi dịch vụ thì bạn đang bỏ lỡ những lợi ích thực sự của hệ thống. Giờ thì đã rồi .
Nguồn: www.habr.com