Có vẻ như các nhà phát triển Terraform cung cấp các phương pháp thực hành tốt nhất khá thuận tiện để làm việc với cơ sở hạ tầng AWS. Chỉ có một sắc thái. Theo thời gian, số lượng môi trường tăng lên, mỗi môi trường đều có những tính năng riêng. Một bản sao gần như của ngăn xếp ứng dụng xuất hiện ở khu vực lân cận. Và mã Terraform cần được sao chép và chỉnh sửa cẩn thận theo yêu cầu mới hoặc làm thành bông tuyết.
Bài nói chuyện của tôi về các mẫu trong Terraform để chống lại sự hỗn loạn và thói quen thủ công trong các dự án lớn và dài hạn.
Video:
Tôi 40 tuổi, làm CNTT được 20 năm. Tôi đã làm việc cho Ixtens được 12 năm. Chúng tôi đang tham gia vào quá trình phát triển dựa trên thương mại điện tử. Và tôi đã thực hành DevOps được 5 năm.
Câu chuyện của tôi sẽ kể về trải nghiệm của tôi trong một dự án ở một công ty mà tôi sẽ không nói tên, ẩn sau một thỏa thuận không tiết lộ.
Các con số trên slide được chỉ định để hiểu quy mô của dự án. Và mọi điều tôi sắp nói tiếp theo đều liên quan đến Amazon.
Tôi đã tham gia dự án này cách đây 4 năm. Và việc tái cấu trúc cơ sở hạ tầng đang diễn ra sôi nổi vì dự án đã phát triển. Và những mẫu đã được sử dụng không còn phù hợp nữa. Và với tất cả sự phát triển theo kế hoạch của dự án, cần phải đưa ra một cái gì đó mới.
Cảm ơn Matvey, người hôm qua đã kể cho chúng tôi chuyện đã xảy ra ở Dodo Pizza. Đây là những gì đã xảy ra ở đây 4 năm trước.
Các nhà phát triển đã đến và bắt đầu tạo mã cơ sở hạ tầng.
Lý do rõ ràng nhất khiến điều này trở nên cần thiết là thời gian đưa sản phẩm ra thị trường. Cần phải đảm bảo rằng nhóm DevOps không gặp trở ngại trong quá trình triển khai. Và trong số những thứ khác, Terraform và Puppet đã được sử dụng ngay từ cấp độ đầu tiên.
Terraform là một dự án nguồn mở của HashiCorp. Và đối với những người thậm chí không biết đây là gì, hãy xem một số slide tiếp theo.
Cơ sở hạ tầng dưới dạng mã có nghĩa là chúng tôi có thể mô tả cơ sở hạ tầng của mình và yêu cầu một số robot đảm bảo rằng chúng tôi nhận được các tài nguyên mà chúng tôi đã mô tả.
Ví dụ: chúng ta cần một máy ảo. Chúng tôi sẽ mô tả và thêm một số tham số cần thiết.
Sau này, chúng tôi sẽ định cấu hình quyền truy cập vào Amazon trong bảng điều khiển. Và chúng tôi sẽ yêu cầu kế hoạch Terraform. Kế hoạch Terraform sẽ nói: “Được rồi, chúng tôi có thể làm những việc này cho tài nguyên của bạn.” Và ít nhất một tài nguyên sẽ được thêm vào. Và không có thay đổi nào được mong đợi.
Khi bạn hài lòng với mọi thứ, bạn có thể yêu cầu Terraform đăng ký và Terraform sẽ tạo một phiên bản cho bạn và bạn sẽ nhận được một máy ảo trên đám mây của mình.
Hơn nữa dự án của chúng tôi đang phát triển. Chúng tôi đang thêm một số thay đổi ở đó. Chúng tôi yêu cầu nhiều trường hợp hơn, chúng tôi thêm 53 mục.
Và chúng tôi lặp lại. Hãy lập kế hoạch. Chúng tôi thấy những thay đổi được lên kế hoạch. Chúng tôi áp dụng. Và đây là cách cơ sở hạ tầng của chúng tôi phát triển.
Terraform sử dụng thứ gọi là tệp trạng thái. Nghĩa là, tất cả các thay đổi đối với Amazon đều được lưu trong một tệp trong đó đối với mỗi tài nguyên mà bạn mô tả, sẽ có các tài nguyên tương ứng được tạo trong Amazon. Do đó, khi mô tả tài nguyên thay đổi, Terraform biết chính xác những gì cần thay đổi trên Amazon.
Các tệp trạng thái này ban đầu chỉ là các tệp. Và chúng tôi đã lưu trữ chúng trong Git, điều này cực kỳ bất tiện. Ai đó luôn quên cam kết thay đổi và nhiều xung đột nảy sinh.
Bây giờ có thể sử dụng phần phụ trợ, tức là Terraform được chỉ định trong nhóm nào và bằng khóa nào mà tệp trạng thái sẽ được lưu. Và chính Terraform sẽ đảm nhận việc lấy tập tin trạng thái này, thực hiện tất cả các phép thuật và đưa ra kết quả cuối cùng.
Cơ sở hạ tầng của chúng tôi đang phát triển. Đây là mã của chúng tôi. Và bây giờ chúng tôi không chỉ muốn tạo một máy ảo mà còn muốn có một môi trường thử nghiệm.
Terraform cho phép bạn tạo một thứ như một mô-đun, nghĩa là mô tả điều tương tự trong một số thư mục.
Và, ví dụ, trong quá trình thử nghiệm, hãy gọi mô-đun này và nhận được điều tương tự như thể chúng tôi đã thực thi ứng dụng Terraform trong chính mô-đun đó. Để thử nghiệm sẽ có mã này.
Đối với sản xuất, chúng tôi có thể gửi một số thay đổi ở đó, vì khi thử nghiệm, chúng tôi không cần các phiên bản lớn; trong sản xuất, các phiên bản lớn chỉ hữu ích.
Và sau đó tôi sẽ quay trở lại dự án. Đó là một nhiệm vụ khó khăn, cơ sở hạ tầng được quy hoạch rất lớn. Và cần phải bằng cách nào đó đặt tất cả mã sao cho thuận tiện cho tất cả mọi người: cho cả những người thực hiện bảo trì mã này và những người thực hiện thay đổi. Và theo kế hoạch, bất kỳ nhà phát triển nào cũng có thể sửa chữa cơ sở hạ tầng khi cần thiết cho phần nền tảng của mình.
Đây là cây thư mục được chính HashiCorp khuyên dùng nếu bạn có một dự án lớn và sẽ hợp lý hơn nếu chia toàn bộ cơ sở hạ tầng thành một số phần nhỏ và mô tả từng phần trong một thư mục riêng.
Với một thư viện tài nguyên phong phú, bạn có thể gọi những thứ tương tự trong quá trình thử nghiệm và sản xuất.
Trong trường hợp của chúng tôi, điều này không hoàn toàn phù hợp, bởi vì ngăn xếp thử nghiệm dành cho nhà phát triển hoặc để thử nghiệm phải được lấy bằng cách nào đó đơn giản hơn. Nhưng tôi không muốn xem qua các thư mục và áp dụng chúng theo trình tự cần thiết, đồng thời lo lắng rằng cơ sở dữ liệu sẽ tăng lên và sau đó phiên bản sử dụng cơ sở dữ liệu này sẽ tăng lên. Do đó, tất cả thử nghiệm đã được khởi chạy từ một thư mục. Các mô-đun tương tự đã được gọi ở đó, nhưng mọi thứ được thực hiện trong một lần chạy.
Terraform xử lý tất cả các phần phụ thuộc. Và nó luôn tạo các tài nguyên theo trình tự để bạn có thể lấy địa chỉ IP, chẳng hạn như từ một phiên bản mới được tạo và nhận địa chỉ IP này trong bản ghi Route53.
Ngoài ra, nền tảng này rất lớn. Và việc khởi chạy một ngăn xếp thử nghiệm, dù trong một giờ, thậm chí trong 8 giờ, cũng là một công việc khá tốn kém.
Và chúng tôi đã tự động hóa vấn đề này. Và công việc của Jenkins cho phép chúng tôi chạy ngăn xếp. Trong đó, cần phải khởi chạy yêu cầu kéo với những thay đổi mà nhà phát triển muốn kiểm tra, chỉ định tất cả các tùy chọn, thành phần và kích thước cần thiết. Nếu anh ấy muốn kiểm tra hiệu năng thì anh ấy có thể lấy nhiều phiên bản hơn. Nếu anh ta chỉ cần kiểm tra xem một số biểu mẫu có mở ra hay không thì anh ta có thể bắt đầu với mức lương tối thiểu. Và cũng cho biết liệu một cụm có cần thiết hay không, v.v.
Và sau đó Jenkins đã đẩy một tập lệnh shell, tập lệnh này đã sửa đổi một chút mã trong thư mục Terraform. Tôi đã xóa các tệp không cần thiết và thêm các tệp cần thiết. Và sau đó chỉ với một lần chạy Terraform, ngăn xếp đã được nâng lên.
Và còn có những bước khác mà tôi không muốn thực hiện.
Do để thử nghiệm, chúng tôi cần nhiều tùy chọn hơn một chút so với khi sản xuất, chúng tôi phải tạo bản sao của các mô-đun để trong những bản sao này, chúng tôi có thể thêm những tính năng chỉ cần cho thử nghiệm.
Và điều đó đã xảy ra khi tôi thử nghiệm những thay đổi mà cuối cùng sẽ được đưa vào sản xuất. Nhưng trên thực tế, một thứ đã được thử nghiệm và một thứ hơi khác đã được sử dụng trong sản xuất. Và có một điểm khác biệt nhỏ là trong quá trình sản xuất, mọi thay đổi đều được đội vận hành áp dụng. Và đôi khi hóa ra những thay đổi đáng lẽ phải đi từ thử nghiệm sang sản xuất vẫn ở một phiên bản khác.
Ngoài ra, có một vấn đề là một dịch vụ mới đã được thêm vào, dịch vụ này hơi khác so với một số dịch vụ hiện có. Và thay vì sửa đổi mô-đun hiện có, chúng tôi phải tạo một bản sao của mô-đun đó và thêm những thay đổi cần thiết.
Về cơ bản, Terraform không phải là ngôn ngữ thực. Đây là một tuyên bố. Nếu chúng ta cần khai báo điều gì đó thì chúng ta khai báo nó. Và tất cả đều hoạt động.
Tại một thời điểm nào đó, khi một trong những yêu cầu kéo của tôi đang được thảo luận, một đồng nghiệp của tôi nói rằng không cần thiết phải tạo bông tuyết. Tôi tự hỏi ý anh ấy là gì. Có một sự thật khoa học là trên thế giới không có hai bông tuyết giống hệt nhau, chúng đều có một chút khác biệt. Và ngay khi nghe điều này, tôi ngay lập tức cảm nhận được toàn bộ sức nặng của mã Terraform. Bởi vì khi cần chuyển từ phiên bản này sang phiên bản khác, Terraform yêu cầu phải phá vỡ chuỗi thay đổi, tức là mã không còn tương thích với phiên bản tiếp theo. Và chúng tôi đã phải thực hiện một yêu cầu kéo, bao gồm gần một nửa số tệp trong cơ sở hạ tầng, để đưa cơ sở hạ tầng lên phiên bản tiếp theo của Terraform.
Và sau khi một bông tuyết như vậy xuất hiện, toàn bộ mã Terraform mà chúng tôi đã biến thành một đống tuyết rất lớn.
Đối với một nhà phát triển bên ngoài nằm ngoài hoạt động, điều này không quan trọng lắm đối với anh ta, bởi vì anh ta đã thực hiện một yêu cầu kéo, tài nguyên của anh ta đã bắt đầu. Và chỉ vậy thôi, đó không còn là mối quan tâm của anh nữa. Và nhóm DevOps, người đảm bảo mọi thứ đều ổn, được yêu cầu thực hiện tất cả những thay đổi này. Và chi phí của những thay đổi này tăng lên rất rất nhiều với mỗi bông tuyết bổ sung.
Có một câu chuyện kể về việc một sinh viên tại một buổi hội thảo đã vẽ hai vòng tròn hoàn hảo bằng phấn trên bảng đen. Và giáo viên ngạc nhiên làm sao cậu ấy có thể vẽ trôi chảy như vậy mà không cần đến compa. Người sinh viên trả lời: “Rất đơn giản, tôi đã phục vụ trong quân đội hai năm để làm một chiếc máy xay thịt.”
Và trong bốn năm tôi tham gia vào dự án này, tôi đã làm Terraform được khoảng hai năm. Và tất nhiên, tôi có một số thủ thuật, một số lời khuyên về cách đơn giản hóa mã Terraform, làm việc với nó như một ngôn ngữ lập trình và giảm bớt gánh nặng cho các nhà phát triển, những người phải cập nhật mã này.
Điều đầu tiên tôi muốn bắt đầu là Symlinks. Terraform có rất nhiều mã lặp đi lặp lại. Ví dụ: cuộc gọi tới nhà cung cấp ở hầu hết mọi điểm mà chúng tôi tạo ra một phần cơ sở hạ tầng đều giống nhau. Và thật hợp lý khi đặt nó vào một thư mục riêng. Và bất cứ nơi nào nhà cung cấp được yêu cầu tạo Liên kết tượng trưng cho tệp này.
Ví dụ: trong quá trình sản xuất, bạn sử dụng vai trò giả định, cho phép bạn có được quyền truy cập vào một số tài khoản Amazon bên ngoài. Và sau khi thay đổi một tệp, tất cả những tệp còn lại trong cây tài nguyên sẽ có các quyền cần thiết để Terraform biết phân khúc Amazon nào sẽ truy cập.
Symlinks thất bại ở đâu? Như tôi đã nói, Terraform có các tập tin trạng thái. Và họ rất, rất tuyệt. Nhưng vấn đề là Terraform khởi tạo phần phụ trợ ngay từ đầu. Và anh ta không thể sử dụng bất kỳ biến nào trong các tham số này, chúng phải luôn được viết bằng văn bản.
Và kết quả là khi ai đó tạo một tài nguyên mới, anh ta sẽ sao chép một số mã từ các thư mục khác. Và anh ta có thể nhầm lẫn với chìa khóa hoặc với cái xô. Ví dụ: anh ấy tạo ra một thứ hộp cát từ hộp cát và sau đó đưa nó vào sản xuất. Và do đó, có thể thùng trong sản xuất sẽ được sử dụng từ hộp cát. Tất nhiên, họ sẽ tìm thấy nó một cách nhanh chóng. Bằng cách nào đó có thể khắc phục được điều này, tuy nhiên, điều đó thật lãng phí thời gian và ở một mức độ nào đó, cả tài nguyên.
Chúng ta có thể làm gì tiếp theo? Trước khi làm việc với Terraform, bạn cần khởi tạo nó. Khi khởi tạo, Terraform tải xuống tất cả các plugin. Tại một thời điểm nào đó, chúng tách từ nguyên khối sang kiến trúc vi dịch vụ hơn. Và bạn luôn cần thực hiện Terraform init để nó kéo lên tất cả các mô-đun, tất cả các plugin.
Và bạn có thể sử dụng tập lệnh shell, trước hết, tập lệnh này có thể lấy tất cả các biến. Tập lệnh shell không bị giới hạn dưới bất kỳ hình thức nào. Và thứ hai, những con đường. Nếu chúng ta luôn sử dụng đường dẫn trong kho lưu trữ làm khóa cho tệp trạng thái thì theo đó, lỗi ở đây sẽ được loại bỏ.
Tôi có thể lấy dữ liệu ở đâu? Tệp JSON. Terraform cho phép bạn viết cơ sở hạ tầng không chỉ bằng hcl (Ngôn ngữ cấu hình HashiCorp) mà còn bằng JSON.
JSON rất dễ đọc từ tập lệnh shell. Theo đó, bạn có thể đặt file cấu hình với Bucket ở một nơi nào đó. Và sử dụng nhóm này cả trong mã Terraform và trong tập lệnh shell để khởi tạo.
Tại sao việc có một thùng cho Terraform lại quan trọng? Bởi vì có một thứ gọi là tập tin trạng thái từ xa. Tức là, khi tôi huy động một số tài nguyên, để nói với Amazon: “Vui lòng tăng phiên bản”, tôi cần chỉ định rất nhiều tham số bắt buộc.
Và những mã định danh này được lưu trữ trong một số thư mục khác. Và tôi có thể đến và nói: “Terraform, vui lòng chạy đến tệp trạng thái của chính tài nguyên đó và lấy cho tôi những mã nhận dạng này.” Và do đó, có sự thống nhất nhất định giữa các khu vực hoặc môi trường khác nhau.
Không phải lúc nào cũng có thể sử dụng tệp trạng thái từ xa. Ví dụ: bạn đã tạo VPC bằng tay. Và đoạn mã Terraform tạo VPC tạo ra các VPC khác nhau đến mức sẽ mất rất nhiều thời gian và bạn sẽ phải điều chỉnh cái này với cái kia nên bạn có thể sử dụng thủ thuật sau.
Nghĩa là, tạo một mô-đun có vẻ như tạo ra một VPC và cung cấp cho bạn các mã nhận dạng, nhưng trên thực tế, chỉ có một tệp có các giá trị được mã hóa cứng có thể được sử dụng để tạo cùng một phiên bản.
Không phải lúc nào cũng cần lưu tệp trạng thái trên đám mây. Ví dụ: khi kiểm tra các mô-đun, bạn có thể sử dụng khởi tạo phụ trợ, trong đó tệp sẽ chỉ được lưu trên đĩa tại thời điểm kiểm tra.
Bây giờ một chút về thử nghiệm. Bạn có thể kiểm tra những gì trong Terraform? Có lẽ có rất nhiều điều có thể xảy ra nhưng tôi sẽ nói về 4 điều này.
HashiCorp hiểu rõ cách định dạng mã Terraform. Và Terraform fmt cho phép bạn định dạng mã bạn chỉnh sửa theo niềm tin này. Theo đó, các cuộc kiểm tra nhất thiết phải kiểm tra xem định dạng có tương ứng với những gì HashiCorp để lại hay không, để không cần thay đổi vị trí của dấu ngoặc, v.v.
Cái tiếp theo là xác thực Terraform. Nó không làm gì hơn ngoài việc kiểm tra cú pháp - than ôi, liệu tất cả các dấu ngoặc đơn có được ghép nối hay không. Điều gì quan trọng ở đây? Cơ sở hạ tầng của chúng tôi rất rộng lớn. Có rất nhiều ông bố khác nhau trong đó. Và trong mỗi bạn cần chạy xác thực Terraform.
Theo đó, để tăng tốc độ thử nghiệm, chúng tôi chạy song song nhiều quy trình bằng cách sử dụng song song.
Song song là một điều rất thú vị, hãy sử dụng nó.
Nhưng mỗi khi Terraform khởi chạy, nó lại đến HashiCorp và hỏi: “Phiên bản plugin mới nhất là gì? Và plugin mà tôi có trong bộ nhớ đệm – nó đúng hay sai?” Và điều này chậm lại ở mỗi bước.
Nếu bạn cho Terraform biết vị trí của các plugin, thì Terraform sẽ nói: “Được rồi, đây có lẽ là thứ mới nhất có ở đó. Tôi sẽ không đi đâu cả, tôi sẽ ngay lập tức bắt đầu xác thực mã Terraform của bạn.”
Để lấp đầy thư mục với các plugin cần thiết, chúng tôi có một mã Terraform rất đơn giản chỉ cần khởi tạo. Tất nhiên, ở đây, bạn cần chỉ định tất cả các nhà cung cấp bằng cách nào đó tham gia vào mã của bạn, nếu không Terraform sẽ nói: “Tôi không biết một nhà cung cấp nào đó vì nó không có trong bộ đệm”.
Tiếp theo là kế hoạch Terraform. Như tôi đã nói, sự phát triển có tính chu kỳ. Chúng tôi thực hiện thay đổi mã. Và sau đó bạn cần tìm hiểu những thay đổi nào được lên kế hoạch cho cơ sở hạ tầng.
Và khi cơ sở hạ tầng rất rất lớn, bạn có thể thay đổi một mô-đun, sửa một số môi trường thử nghiệm hoặc một số khu vực cụ thể và phá vỡ một số mô-đun lân cận. Do đó, kế hoạch Terraform nên được lập cho toàn bộ cơ sở hạ tầng và chỉ ra những thay đổi được lên kế hoạch.
Bạn có thể làm điều này một cách thông minh. Ví dụ: chúng tôi đã viết một tập lệnh Python để giải quyết các phần phụ thuộc. Và tùy thuộc vào những gì đã được thay đổi: mô-đun Terraform hay chỉ một thành phần cụ thể, nó sẽ lập kế hoạch cho tất cả các thư mục phụ thuộc.
Kế hoạch địa hình phải được thực hiện theo yêu cầu. Ít nhất đó là những gì chúng tôi làm.
Tất nhiên, việc kiểm tra mọi thay đổi, mọi cam kết là điều tốt, nhưng kế hoạch là một thứ khá tốn kém. Và trong một yêu cầu kéo, chúng ta nói: “Xin vui lòng đưa cho tôi kế hoạch.” Robot bắt đầu. Và gửi nhận xét hoặc đính kèm tất cả các kế hoạch được mong đợi từ những thay đổi của bạn.
Một kế hoạch là một điều khá tốn kém. Phải mất thời gian vì Terraform đến Amazon và hỏi, “Trường hợp này có còn tồn tại không? Thang đo tự động này có các thông số giống hệt nhau không?” Và để tăng tốc độ này, bạn có thể sử dụng tham số như Refresh=false. Điều này có nghĩa là Terraform sẽ tải trạng thái từ S3. Và nó sẽ tin rằng trạng thái sẽ khớp chính xác với những gì ở Amazon.
Kế hoạch Terraform như vậy diễn ra nhanh hơn nhiều, nhưng trạng thái phải tương ứng với cơ sở hạ tầng của bạn, tức là ở đâu đó, đôi khi quá trình làm mới Terraform phải bắt đầu. Làm mới Terraform thực hiện chính xác điều đó: trạng thái khớp với những gì có trong cơ sở hạ tầng thực tế.
Và chúng ta cần nói về sự an toàn. Đây là nơi chúng tôi phải bắt đầu. Nơi bạn chạy Terraform và Terraform chạy trên cơ sở hạ tầng của bạn đều có lỗ hổng. Tức là về cơ bản bạn đang thực thi mã. Và nếu yêu cầu kéo chứa một số loại mã độc hại thì nó có thể được thực thi trên cơ sở hạ tầng có quá nhiều quyền truy cập. Vì vậy hãy cẩn thận khi bạn chạy kế hoạch Terraform.
Điều tiếp theo tôi muốn nói đến là kiểm tra dữ liệu người dùng.
Dữ liệu người dùng là gì? Ở Amazon, khi tạo một phiên bản, chúng tôi có thể gửi một chữ cái nhất định với phiên bản đó - dữ liệu meta. Khi phiên bản khởi động, thông thường cloud init luôn xuất hiện trên các phiên bản này. Cloud init đọc lá thư này và nói: “OK, hôm nay tôi là người cân bằng tải.” Và theo những giao ước này, anh ta thực hiện một số hành động.
Tuy nhiên, thật không may, khi chúng tôi thực hiện kế hoạch Terraform và áp dụng Terraform, dữ liệu người dùng trông giống như một loại số hỗn độn. Tức là anh ta chỉ đơn giản gửi cho bạn hàm băm. Và tất cả những gì bạn có thể xem xét trong kế hoạch là liệu sẽ có bất kỳ thay đổi nào hay liệu hàm băm có giữ nguyên hay không.
Và nếu bạn không chú ý đến điều này, thì một số tệp văn bản bị hỏng có thể xuất hiện trên Amazon, trên cơ sở hạ tầng thực sự.
Ngoài ra, khi thực thi, bạn có thể chỉ định không phải toàn bộ cơ sở hạ tầng mà chỉ có mẫu. Và trong đoạn mã có nội dung: “Vui lòng hiển thị mẫu này trên màn hình của tôi.” Và kết quả là bạn có thể nhận được bản in dữ liệu của mình sẽ trông như thế nào trên Amazon.
Một tùy chọn khác là sử dụng mô-đun để tạo dữ liệu người dùng. Bạn sẽ áp dụng mô-đun này. Bạn nhận được tập tin trên đĩa. So sánh nó với tài liệu tham khảo. Và do đó, nếu ai đó quyết định sửa dữ liệu người dùng một chút, thì các bài kiểm tra của bạn sẽ cho biết: "OK, có một số thay đổi ở đây và ở đó - điều này là bình thường."
Điều tiếp theo tôi muốn nói đến là áp dụng Automate Terraform.
Tất nhiên, khá đáng sợ khi áp dụng Terraform ở chế độ tự động, bởi vì ai biết được những thay đổi nào đã xảy ra ở đó và mức độ tàn phá của chúng đối với cơ sở hạ tầng sống.
Đối với môi trường thử nghiệm, tất cả điều này là bình thường. Nghĩa là, công việc tạo ra môi trường thử nghiệm là điều mà tất cả các nhà phát triển cần có. Và một biểu thức như “mọi thứ đều hiệu quả với tôi” không phải là một meme hài hước, mà là bằng chứng cho thấy một người đã nhầm lẫn, nâng một ngăn xếp lên và chạy một số thử nghiệm trên ngăn xếp này. Và anh ấy đảm bảo rằng mọi thứ ở đó đều ổn và nói: "Được rồi, mã mà tôi phát hành đã được kiểm tra."
Trong môi trường sản xuất, hộp cát và các môi trường quan trọng hơn về mặt kinh doanh, bạn có thể sử dụng một phần một số tài nguyên khá an toàn vì điều đó không dẫn đến tử vong cho bất kỳ ai. Đó là: nhóm tự động chia tỷ lệ, nhóm bảo mật, vai trò, tuyến đường53 và danh sách ở đó có thể khá lớn. Nhưng hãy để ý xem điều gì đang diễn ra, đọc các báo cáo ứng dụng tự động.
Ví dụ: khi áp dụng là nguy hiểm hoặc đáng sợ, nếu đây là một số tài nguyên liên tục từ cơ sở dữ liệu thì sẽ nhận được báo cáo rằng có những thay đổi chưa được áp dụng trong một số phần của cơ sở hạ tầng. Và kỹ sư, dưới sự giám sát, bắt đầu công việc để áp dụng hoặc thực hiện công việc đó từ bảng điều khiển của mình.
Amazon có một thứ như Bảo vệ chấm dứt. Và trong một số trường hợp, nó có thể bảo vệ bạn khỏi những thay đổi không cần thiết đối với bạn. Tức là, Terraform đã đến Amazon và nói: “Tôi cần tiêu diệt phiên bản này để tạo một phiên bản khác”. Và Amazon nói: “Xin lỗi, không phải hôm nay. Chúng tôi có biện pháp bảo vệ Chấm dứt."
Và điều quan trọng nhất là tối ưu hóa mã. Khi làm việc với mã Terraform, chúng ta phải truyền một số lượng rất lớn tham số cho mô-đun. Đây là những thông số cần thiết để tạo ra một số loại tài nguyên. Và mã biến thành danh sách lớn các tham số cần được truyền từ mô-đun này sang mô-đun khác, từ mô-đun này sang mô-đun khác, đặc biệt nếu các mô-đun được lồng nhau.
Và nó rất khó đọc. Rất khó để xem xét điều này. Và rất thường xuyên, hóa ra một số thông số được xem xét và chúng không chính xác là những gì cần thiết. Và điều này tốn thời gian và tiền bạc để khắc phục sau này.
Vì vậy, tôi khuyên bạn nên sử dụng một thứ như một tham số phức tạp bao gồm một cây giá trị nhất định. Nghĩa là, bạn cần một số loại thư mục nơi bạn có tất cả các giá trị mà bạn muốn có trong một môi trường nào đó.
Và bằng cách gọi mô-đun này, bạn có thể nhận được một cây được tạo trong một mô-đun chung, nghĩa là trong một mô-đun chung hoạt động giống nhau cho toàn bộ cơ sở hạ tầng.
Trong mô-đun này, bạn có thể thực hiện một số phép tính bằng cách sử dụng tính năng gần đây như vậy trong Terraform dưới dạng tính năng cục bộ. Và sau đó, với một đầu ra, đưa ra một số tham số phức tạp, có thể bao gồm các hàm băm mảng, v.v.
Đây là nơi tất cả những phát hiện tốt nhất mà tôi đã kết thúc. Và tôi muốn kể một câu chuyện về Columbus. Khi anh đang kiếm tiền cho chuyến thám hiểm khám phá Ấn Độ (như anh nghĩ lúc đó), không ai tin anh và họ cho rằng điều đó là không thể. Sau đó anh ấy nói: Hãy chắc chắn rằng quả trứng không rơi. Tất cả các chủ ngân hàng, những người rất giàu có và có lẽ thông minh, đã cố gắng bằng cách nào đó đặt quả trứng vào, và nó cứ rơi. Sau đó Columbus lấy quả trứng và ấn nhẹ vào. Vỏ bị vò nát và quả trứng vẫn bất động. Họ nói: "Ồ, điều đó quá dễ dàng!" Và Columbus trả lời: “Đúng, nó quá đơn giản. Và khi tôi mở cửa Ấn Độ, mọi người sẽ sử dụng con đường thương mại này”.
Và những điều tôi vừa kể với bạn có lẽ là những điều khá đơn giản và tầm thường. Và khi bạn tìm hiểu về chúng và bắt đầu sử dụng chúng, mọi thứ sẽ theo thứ tự. Vì vậy hãy tận dụng lợi thế. Và nếu đây là những điều hoàn toàn bình thường đối với bạn thì ít nhất bạn cũng biết cách đặt quả trứng để nó không bị rơi.
Hãy tổng hợp:
- Cố gắng tránh những bông tuyết. Và càng ít bông tuyết thì bạn càng cần ít tài nguyên hơn để thực hiện bất kỳ thay đổi nào trên toàn bộ cơ sở hạ tầng rộng lớn của mình.
- Thay đổi liên tục. Nghĩa là, khi một số thay đổi xảy ra trong mã, bạn cần đưa cơ sở hạ tầng của mình tuân thủ những thay đổi này càng nhanh càng tốt. Sẽ không có trường hợp hai hoặc ba tháng sau ai đó đến xem xét Elaticsearch, lập kế hoạch Terraform và có một loạt thay đổi mà anh ta không ngờ tới. Và phải mất rất nhiều thời gian để sắp xếp mọi thứ trở lại trật tự.
- Kiểm tra và tự động hóa. Mã của bạn càng được bao phủ bởi các bài kiểm tra và tính năng thì bạn càng tự tin rằng mình đang làm mọi thứ một cách chính xác. Và việc giao hàng tự động sẽ tăng sự tự tin của bạn lên gấp nhiều lần.
- Mã cho môi trường thử nghiệm và sản xuất phải gần như giống nhau. Trên thực tế, bởi vì quá trình sản xuất vẫn còn một chút khác biệt và sẽ vẫn có một số sắc thái vượt ra ngoài môi trường thử nghiệm. Nhưng tuy nhiên, cộng hoặc trừ, điều này có thể được đảm bảo.
- Và nếu bạn có nhiều mã Terraform và mất nhiều thời gian để cập nhật mã này, thì không bao giờ là quá muộn để cấu trúc lại và làm cho nó ở trạng thái tốt.
- Cơ sở hạ tầng bất biến. AMI giao hàng đúng tiến độ.
- Cấu trúc cho Route53 khi bạn có nhiều mục nhập và bạn muốn chúng có thứ tự nhất quán.
- Chống lại giới hạn tỷ lệ API. Đây là lúc Amazon nói: "Vậy là xong, tôi không thể chấp nhận bất kỳ yêu cầu nào nữa, vui lòng đợi." Và một nửa văn phòng đang đợi cho đến khi có thể triển khai cơ sở hạ tầng của mình.
- Trường hợp tại chỗ. Amazon không phải là một sự kiện giá rẻ và các điểm cho phép bạn tiết kiệm khá nhiều. Và ở đó bạn có thể kể toàn bộ báo cáo về nó.
- Vai trò bảo mật và IAM.
- Tìm kiếm tài nguyên bị thất lạc, khi bạn gặp những trường hợp không rõ nguồn gốc ở Amazone thì chúng ăn tiền. Ngay cả khi các phiên bản có giá 100-150 USD mỗi tháng, thì đó vẫn là hơn 1 USD mỗi năm. Tìm kiếm các nguồn lực như vậy là một công việc kinh doanh có lợi nhuận.
- Và các trường hợp dành riêng.
Đó là tất cả đối với tôi. Terraform rất tuyệt, bạn sử dụng nó. Cảm ơn!
câu hỏi
Cảm ơn vì đã báo cáo! Tệp trạng thái của bạn nằm trong S3, nhưng làm cách nào để giải quyết vấn đề mà một số người có thể lấy tệp trạng thái này và cố gắng mở rộng?
Trước hết, chúng tôi không vội. Thứ hai, có những lá cờ trong đó chúng tôi báo cáo rằng chúng tôi đang làm việc trên một số đoạn mã. Đó là, mặc dù thực tế là cơ sở hạ tầng rất lớn, nhưng điều này không có nghĩa là ai đó thường xuyên sử dụng thứ gì đó. Và khi có một giai đoạn hoạt động thì đây là một vấn đề; chúng tôi đã lưu trữ các tệp trạng thái trong Git. Điều này rất quan trọng, nếu không ai đó sẽ tạo một tệp trạng thái và chúng tôi phải ghép chúng lại với nhau theo cách thủ công để mọi thứ tiếp tục. Bây giờ không có vấn đề như vậy. Nói chung, Terraform đã giải quyết được vấn đề này. Và nếu có điều gì đó liên tục thay đổi, thì bạn có thể sử dụng ổ khóa để ngăn chặn những gì bạn đã nói.
Bạn đang sử dụng nguồn mở hoặc doanh nghiệp?
Không có doanh nghiệp, tức là mọi thứ bạn có thể truy cập và tải xuống miễn phí.
Tên tôi là Stanislav. Tôi muốn thực hiện một bổ sung nhỏ. Bạn đã nói về một tính năng của Amazon cho phép bạn tạo một phiên bản không thể thực hiện được. Điều này cũng có trong chính Terraform; trong khối Life Second, bạn có thể chỉ định lệnh cấm thay đổi hoặc lệnh cấm phá hủy.
Thời gian bị hạn chế. Điểm tốt.
Tôi cũng muốn hỏi hai điều. Đầu tiên, bạn đã nói về việc thử nghiệm. Bạn có sử dụng bất kỳ công cụ kiểm tra nào không? Tôi đã nghe nói về plugin Test Kitchen. Có lẽ còn có điều gì đó nữa. Và tôi cũng muốn hỏi về Giá trị địa phương. Về cơ bản chúng khác với Biến đầu vào như thế nào? Và tại sao tôi không thể tham số hóa thứ gì đó chỉ thông qua Giá trị cục bộ? Tôi đã cố gắng tìm ra chủ đề này, nhưng không hiểu sao tôi không thể tự mình tìm ra được.
Chúng ta có thể nói chuyện chi tiết hơn bên ngoài căn phòng này. Các công cụ kiểm tra của chúng tôi hoàn toàn tự tạo. Không có gì ở đó để kiểm tra. Nói chung, có các tùy chọn khi kiểm tra tự động chọn cơ sở hạ tầng ở đâu đó, kiểm tra xem nó có ổn không, sau đó hủy mọi thứ với báo cáo rằng cơ sở hạ tầng của bạn vẫn ở trạng thái tốt. Chúng tôi không có điều này vì các ngăn xếp thử nghiệm được chạy hàng ngày. Và thế là đủ. Và nếu một cái gì đó bắt đầu vỡ, nó sẽ bắt đầu vỡ mà không cần chúng ta kiểm tra nó ở nơi nào khác.
Về Giá trị Địa phương, chúng ta hãy tiếp tục cuộc trò chuyện bên ngoài phòng.
Xin chào! Cảm ơn vì đã báo cáo! Rất nhiều thông tin. Bạn nói rằng bạn có rất nhiều mã giống nhau để mô tả cơ sở hạ tầng. Bạn đã cân nhắc việc tạo mã này chưa?
Câu hỏi hay, cảm ơn! Vấn đề là khi chúng tôi sử dụng cơ sở hạ tầng làm mã, chúng tôi giả định rằng chúng tôi xem mã và hiểu cơ sở hạ tầng nào nằm đằng sau mã đó. Nếu mã được tạo, thì chúng ta cần tưởng tượng mã nào sẽ được tạo để hiểu loại cơ sở hạ tầng nào sẽ ở đó. Hoặc là chúng ta tạo mã, cam kết mã và về cơ bản điều tương tự sẽ xảy ra. Vì vậy, chúng tôi đã đi theo con đường mà chúng tôi đã viết, chúng tôi đã hiểu được nó. Ngoài ra, máy phát điện xuất hiện muộn hơn một chút khi chúng tôi bắt đầu chế tạo chúng. Và đã quá muộn để thay đổi.
Bạn đã nghe nói gì về jsonnet chưa?
Không.
Hãy nhìn xem, đây là một điều rất tuyệt vời. Tôi thấy một trường hợp cụ thể mà bạn có thể áp dụng nó và tạo cấu trúc dữ liệu.
Máy phát điện rất tốt khi bạn có chúng, như trong câu chuyện đùa về chiếc máy cạo râu. Tức là lúc đầu khuôn mặt khác nhau nhưng sau đó ai cũng có khuôn mặt giống nhau. Các máy phát điện hoạt động rất tốt. Nhưng thật không may, khuôn mặt của chúng tôi hơi khác nhau. Đây là vấn đề.
Chỉ cần nhìn. Cảm ơn!
Tên tôi là Maxim, tôi đến từ Sberbank. Bạn đã nói một chút về cách bạn đang cố gắng đưa Terraform trở thành ngôn ngữ lập trình tương đương. Sử dụng Ansible có dễ dàng hơn không?
Đây là những điều rất khác nhau. Bạn có thể tạo tài nguyên trong Ansible và Puppet có thể tạo tài nguyên trong Amazon. Nhưng Terraform được mài giũa thẳng thắn.
Bạn chỉ có Amazon?
Không phải là chúng ta chỉ có Amazon. Chúng tôi gần như chỉ có Amazon. Nhưng tính năng chính là Terraform có khả năng ghi nhớ. Trong Ansible, nếu bạn nói: “Hãy cho tôi 5 trường hợp”, thì nó sẽ tăng lên và bạn nói: “Và bây giờ tôi cần 3”. Và Terraform sẽ nói: “Được rồi, tôi sẽ giết 2” và Ansible sẽ nói: “Được rồi, đây là 3 cho bạn.” Tổng số 8.
Xin chào! Cảm ơn báo cáo của bạn! Thật thú vị khi nghe về Terraform. Tôi muốn đưa ra ngay một nhận xét nhỏ về việc Terraform vẫn chưa có bản phát hành ổn định, vì vậy hãy hết sức thận trọng với Terraform.
Một chiếc thìa tốt cho bữa tối. Nghĩa là, nếu bạn cần một giải pháp, thì đôi khi bạn bỏ qua những gì không ổn định, v.v., nhưng nó hiệu quả và đã giúp ích cho chúng tôi.
Câu hỏi là thế này. Bạn dùng Remote backend, bạn dùng S 3. Tại sao bạn không dùng backend chính thức?
Chính thức?
Đám mây địa hình.
Anh ấy xuất hiện khi nào?
Khoảng 4 tháng trước.
Nếu nó xuất hiện cách đây 4 năm thì có lẽ tôi đã trả lời được câu hỏi của bạn.
Đã có chức năng và khóa tích hợp sẵn, bạn có thể lưu trữ tệp trạng thái. Hãy thử một lần. Nhưng tôi cũng chưa thử nó.
Chúng ta đang đi trên một đoàn tàu lớn đang di chuyển với tốc độ cao. Và bạn không thể chỉ lấy một vài chiếc ô tô và vứt chúng đi.
Bạn đã nói về bông tuyết, tại sao bạn không dùng cành cây? Tại sao nó không diễn ra theo cách đó?
Cách tiếp cận của chúng tôi là toàn bộ cơ sở hạ tầng nằm trong một kho lưu trữ. Terraform, Puppet, tất cả các tập lệnh có liên quan đến điều này, tất cả đều nằm trong một kho lưu trữ. Bằng cách này, chúng tôi có thể đảm bảo rằng các thay đổi gia tăng được thử nghiệm lần lượt. Nếu là một loạt các chi nhánh thì một dự án như vậy gần như không thể duy trì được. Sáu tháng trôi qua, họ khác nhau nhiều đến mức đó chỉ là một hình phạt nào đó. Đây là điều tôi muốn thoát khỏi trước khi tái cấu trúc.
Vì vậy, nó không hoạt động?
Điều này không có tác dụng gì cả.
Ở nhánh tôi cắt slide thư mục. Nghĩa là, nếu bạn làm điều đó cho mỗi ngăn xếp thử nghiệm, chẳng hạn như đội A có thư mục riêng, đội B có thư mục riêng, thì điều này cũng không hiệu quả. Chúng tôi đã tạo một mã môi trường thử nghiệm thống nhất đủ linh hoạt để phù hợp với tất cả mọi người. Tức là chúng tôi đã phục vụ một mã.
Xin chào! Tên tôi là Yura! Cảm ơn vì đã báo cáo! Câu hỏi về module. Bạn nói rằng bạn đang sử dụng các mô-đun. Bạn giải quyết vấn đề như thế nào nếu những thay đổi được thực hiện đối với một mô-đun không tương thích với thay đổi của người khác? Bạn bằng cách nào đó đang tạo phiên bản cho các mô-đun hoặc đang cố gắng tạo ra một chiếc wunderwaffle để đáp ứng hai yêu cầu?
Đây là một vấn đề đống tuyết lớn. Đây là những gì chúng ta phải gánh chịu khi một số thay đổi vô hại có thể phá vỡ một phần cơ sở hạ tầng. Và điều này sẽ chỉ được chú ý sau một thời gian dài.
Tức là nó vẫn chưa được giải quyết?
Bạn tạo ra các mô-đun phổ quát. Tránh những bông tuyết. Và mọi thứ sẽ ổn thỏa. Nửa sau của báo cáo nói về cách tránh điều này.
Xin chào! Cảm ơn vì đã báo cáo! Tôi muốn bạn làm rõ. Đằng sau hậu trường có một đống lớn mà tôi đến. Phân phối con rối và vai trò được tích hợp như thế nào?
Dữ liệu người dùng.
Tức là bạn chỉ cần nhổ tập tin ra và bằng cách nào đó thực thi nó?
Dữ liệu người dùng là một ghi chú, tức là khi chúng tôi tạo một bản sao của hình ảnh, Daemon xuất hiện ở đó và cố gắng tìm ra anh ta là ai, đọc ghi chú rằng anh ta là người cân bằng tải.
Nghĩa là, đây có phải là một loại quy trình riêng biệt nào đó được cho đi không?
Chúng tôi đã không phát minh ra nó. Chúng tôi sử dụng nó.
Xin chào! Tôi chỉ có một câu hỏi về Người dùng - dữ liệu. Bạn nói rằng có vấn đề ở đó, rằng ai đó có thể gửi thứ gì đó đến nhầm địa điểm. Có cách nào để lưu trữ dữ liệu người dùng trong cùng một Git để luôn rõ ràng dữ liệu Người dùng đề cập đến điều gì không?
Chúng tôi tạo dữ liệu người dùng từ mẫu. Đó là, một số lượng biến nhất định được sử dụng ở đó. Và Terraform tạo ra kết quả cuối cùng. Do đó, bạn không thể chỉ nhìn vào mẫu và nói điều gì sẽ xảy ra, bởi vì tất cả các vấn đề đều liên quan đến việc nhà phát triển cho rằng anh ta đang truyền một chuỗi vào biến này, nhưng một mảng lại được sử dụng ở đó. Và anh ấy - bam và tôi - thế này thế nọ, thế này thế kia, dòng tiếp theo, và mọi thứ tan vỡ. Nếu đây là một tài nguyên mới và một người nhặt nó lên và thấy có gì đó không hoạt động thì vấn đề sẽ nhanh chóng được giải quyết. Và nếu nhóm tự động chia tỷ lệ này được cập nhật thì tại một thời điểm nào đó, các phiên bản trong nhóm tự động chia tỷ lệ sẽ bắt đầu được thay thế. Và bang, có gì đó không ổn. Nó đau quá.
Hóa ra giải pháp duy nhất là kiểm tra?
Có, bạn thấy có vấn đề, bạn thêm các bước kiểm tra vào đó. Nghĩa là, đầu ra cũng có thể được kiểm tra. Có thể nó không thuận tiện lắm, nhưng bạn cũng có thể đặt một số dấu - kiểm tra xem Dữ liệu người dùng có được ghi ở đây hay không.
Tên tôi là Timur. Thật tuyệt khi có những báo cáo về cách tổ chức Terraform hợp lý.
Tôi thậm chí còn chưa bắt đầu.
Tôi nghĩ rằng có thể ở hội nghị tiếp theo sẽ có. Tôi có một câu hỏi đơn giản. Tại sao bạn mã hóa giá trị trong một mô-đun riêng biệt thay vì sử dụng tfvars, tức là tại sao mô-đun có giá trị tốt hơn tfvars?
Nghĩa là, tôi có nên viết ở đây (slide: Production/environment/settings.tf): domain = Variable, Domain vpcnetwork, Variable vpcnetwork và stvars – tôi có thể nhận được điều tương tự không?
Đó chính xác là những gì chúng tôi làm. Ví dụ: chúng tôi đề cập đến mô-đun nguồn cài đặt.
Về cơ bản, đây là những tfvars như vậy. Tfvars rất thuận tiện trong môi trường thử nghiệm. Tôi có tfvars cho các trường hợp lớn, cho các trường hợp nhỏ. Và tôi đã ném một tập tin vào thư mục. Và tôi đã có được điều mình muốn. Khi chúng tôi cắt giảm cơ sở hạ tầng, chúng tôi muốn có thể xem xét và hiểu ngay mọi thứ. Và vì vậy hóa ra bạn cần nhìn vào đây, sau đó nhìn vào tfvars.
Có thể có mọi thứ ở một nơi?
Có, tfvars là khi bạn có một mã. Và nó được sử dụng ở nhiều nơi khác nhau với các sắc thái khác nhau. Sau đó, bạn sẽ ném tfvars và nhận được sắc thái của mình. Và chúng tôi là cơ sở hạ tầng dưới dạng mã ở dạng thuần túy nhất. Tôi nhìn và hiểu.
Xin chào! Bạn đã gặp phải tình huống nhà cung cấp đám mây can thiệp vào những gì bạn đã tạo ra Terraform chưa? Giả sử chúng tôi chỉnh sửa siêu dữ liệu. Có phím ssh. Và Google liên tục đặt siêu dữ liệu và khóa của mình ở đó. Và Terraform luôn viết rằng nó có những thay đổi. Sau mỗi lần chạy, dù không có gì thay đổi, anh ấy vẫn luôn nói rằng sẽ cập nhật trường này ngay bây giờ.
Có chìa khóa, nhưng vâng, một phần cơ sở hạ tầng bị ảnh hưởng bởi thứ này, tức là Terraform không thể thay đổi bất cứ điều gì. Chúng ta cũng không thể thay đổi bất cứ điều gì bằng đôi tay của mình. Bây giờ chúng ta sẽ sống với nó.
Tức là bạn đã từng gặp trường hợp như thế này rồi mà chưa nghĩ ra cách nào, anh ấy làm như thế nào và tự mình làm?
Không may là đúng vậy.
Xin chào! Tên tôi là Starkov Stanislav. Thư. ru Nhóm. Bạn giải quyết vấn đề tạo thẻ trên..., chuyển nó vào bên trong như thế nào? Theo tôi hiểu thì thông qua User - data để chỉ định tên máy chủ, bật Puppet lên? Và phần thứ hai của câu hỏi. Bạn giải quyết vấn đề này ở SG như thế nào, tức là khi bạn tạo SG, hàng trăm trường hợp cùng loại, tên chính xác của chúng là gì?
Những trường hợp rất quan trọng đối với chúng tôi, chúng tôi đặt tên cho chúng thật đẹp. Những cái không cần thiết thì có lưu ý đây là nhóm autoscale. Và về mặt lý thuyết, bạn có thể đóng nó lại và mua một cái mới.
Về phần thẻ bài vấn đề, không có vấn đề như vậy, nhưng lại có nhiệm vụ như vậy. Và chúng tôi sử dụng thẻ rất nhiều, vì cơ sở hạ tầng rất lớn và đắt tiền. Và chúng tôi cần xem tiền sẽ đi đâu, vì vậy thẻ cho phép chúng tôi chia nhỏ những gì đã đi đâu. Và theo đó, việc tìm kiếm thứ gì đó có nghĩa là sẽ phải chi rất nhiều tiền ở đây.
Câu hỏi còn về cái gì nữa?
Khi SG tạo ra hàng trăm trường hợp, chúng có cần được phân biệt bằng cách nào đó không?
Không, đừng. Trong mỗi trường hợp đều có một nhân viên báo cáo rằng tôi gặp sự cố. Nếu một đại lý báo cáo, thì đại lý đó biết về anh ta và ít nhất địa chỉ IP của anh ta tồn tại. Bạn đã có thể chạy trốn. Thứ hai, chúng tôi sử dụng Consul for Discovery, nơi Kubernetes không có. Và Consul cũng hiển thị địa chỉ IP của cá thể.
Nghĩa là, bạn có đang tập trung cụ thể vào IP chứ không phải tên máy chủ không?
Không thể điều hướng theo tên máy chủ, tức là có rất nhiều tên máy chủ. Có các mã định danh cá thể - AE, v.v. Bạn có thể tìm thấy nó ở đâu đó, bạn có thể ném nó vào tìm kiếm.
Xin chào! Tôi nhận ra rằng Terraform là một thứ tốt, được thiết kế riêng cho đám mây.
Không chỉ.
Đây chính xác là câu hỏi khiến tôi quan tâm. Ví dụ: nếu bạn quyết định chuyển sang Bare Metal với tất cả các phiên bản của mình? Sẽ có bất kỳ vấn đề? Hay bạn vẫn sẽ phải sử dụng các sản phẩm khác, chẳng hạn như Ansible đã được đề cập ở đây?
Ansible là một chút về cái gì đó khác. Tức là Ansible đã hoạt động khi phiên bản đã bắt đầu. Và Terraform hoạt động trước khi phiên bản bắt đầu. Chuyển sang Bare Metal - không.
Không phải bây giờ, nhưng doanh nghiệp sẽ đến và nói: “Nào.”
Chuyển sang một đám mây khác – đúng vậy, nhưng ở đây có một thủ thuật hơi khác. Bạn cần viết mã Terraform theo cách để có thể chuyển sang một số đám mây khác mà tốn ít công sức hơn.
Ban đầu, nhiệm vụ được đặt ra là toàn bộ cơ sở hạ tầng của chúng tôi là bất khả tri, tức là bất kỳ đám mây nào cũng phải phù hợp, nhưng đến một lúc nào đó, doanh nghiệp đã từ bỏ và nói: “Được rồi, trong N năm tới, chúng tôi sẽ không đi đâu cả, chúng tôi có thể sử dụng dịch vụ từ Amazon"
Terraform cho phép bạn tạo các công việc Front-End, định cấu hình PagerDuty, data doc, v.v. Nó có rất nhiều đuôi. Anh ta thực tế có thể kiểm soát toàn bộ thế giới.
Cảm ơn vì đã báo cáo! Tôi cũng đã sử dụng Terraform được 4 năm rồi. Ở giai đoạn chuyển đổi suôn sẻ sang Terraform, sang cơ sở hạ tầng, sang mô tả khai báo, chúng tôi phải đối mặt với tình huống ai đó đang làm điều gì đó bằng tay và bạn đang cố gắng lập kế hoạch. Và tôi đã gặp một số lỗi ở đó. Làm thế nào để bạn đối phó với những vấn đề như vậy? Làm thế nào để bạn tìm thấy tài nguyên bị mất đã được liệt kê?
Chủ yếu bằng tay và mắt, nếu chúng ta thấy điều gì đó kỳ lạ trong báo cáo, thì chúng ta sẽ phân tích những gì đang xảy ra ở đó, hoặc đơn giản là chúng ta giết chết. Nói chung, yêu cầu kéo là một điều phổ biến.
Nếu có lỗi thì bạn có rollback lại không? Bạn đã thử làm điều này chưa?
Không, đây là quyết định của một người vào lúc anh ta thấy có vấn đề.
Nguồn: www.habr.com