Quản lý cấu hình cho 'nhiều máy chủ quản trị viên'

Chúng tôi đã thiết lập một máy chủ chạy cơ sở hạ tầng cho một hiệp hội nhỏ. Cho đến nay, chúng tôi đã cố gắng quản lý cấu hình với Ansible, nhưng đó không phải là một thành công lớn. Có lẽ chúng ta đang làm sai.

Về nguyên tắc, ý tưởng là máy chủ này sẽ bị bỏ lại một mình trong hầu hết thời gian, với việc mọi người thêm hoặc thay đổi mọi thứ một lần trong một mặt trăng xanh. Điều này làm cho điều quan trọng là bất cứ điều gì được cấu hình và chạy trên máy chủ đều được ghi lại rõ ràng và rõ ràng, vì những người không quản trị hệ thống thường bị ràng buộc để mất tổng quan (hãy để ý các chi tiết). Ngoài ra, theo thời gian, thành phần của nhóm người sẽ quản trị máy chủ này sẽ thay đổi (khi mọi người rời khỏi và tham gia 'ủy ban').

Chúng tôi bắt đầu với một bản cài đặt sạch sẽ, thêm các vai trò trong ansible bất cứ khi nào chúng tôi muốn thiết lập một cái gì đó (nginx, phpfpm, postfix, tường lửa, sftp, munin, ..). Có lẽ do thiếu kinh nghiệm của chúng tôi, tất nhiên chúng tôi không bao giờ có thể loại ra một tập hợp các nhiệm vụ có thể tìm thấy chính xác theo cách chúng tôi cần trong một lần, vì cấu hình là một quá trình thử và sai. Điều đó có nghĩa là trong thực tế, trước tiên chúng ta thường định cấu hình bất kỳ dịch vụ nào chúng ta muốn chạy trên máy chủ , sau đó chuyển sang các tác vụ có thể tìm thấy. Bạn có thể thấy nơi này sẽ đi. Mọi người quên sau đó kiểm tra nhiệm vụ, hoặc sợ làm như vậy có nguy cơ phá vỡ mọi thứ, hoặc tệ hơn: chúng ta quên hoặc bỏ bê để thêm mọi thứ vào ansible.

Ngày nay, chúng ta có rất ít niềm tin rằng cấu hình ansible thực sự phản ánh những gì được cấu hình trên máy chủ.

Hiện tại tôi thấy ba vấn đề chính:

• Thật khó để (đọc: chúng tôi không có cách nào tốt) để kiểm tra các nhiệm vụ khả thi mà không có nguy cơ phá vỡ mọi thứ.
• Nó bổ sung thêm công việc để tìm ra cấu hình mong muốn và sau đó tìm ra cách dịch nó sang các tác vụ có thể tìm thấy.
• (Lý tưởng nhất), chúng tôi không sử dụng nó thường xuyên đủ để xây dựng sự quen thuộc và thói quen.

Một cân nhắc quan trọng ở đây là đối với bất cứ điều gì chúng ta kết thúc, sẽ dễ dàng cho những người mới học các sợi dây mà không cần một tấn thực hành.

Có một sự thay thế khả thi nào vẫn cung cấp một số đảm bảo và kiểm tra (có thể so sánh với việc hợp nhất các tệp Ansible với một số master) mà "cấu hình mọi thứ và ghi lại những gì bạn đã làm" không cung cấp?

EDIT: Chúng tôi đã xem xét cam kết /etcgit. Có cách nào hợp lý để bảo vệ bí mật (khóa riêng, v.v.) theo cách đó, nhưng vẫn có kho lưu trữ cấu hình có sẵn bên ngoài máy chủ không?

Chỉ cần quay một VM kiểm tra / dàn mà bạn có thể sử dụng để xác nhận các thay đổi của mình. Phương pháp hiện tại của bạn để thực hiện các thay đổi theo cách thủ công trước tiên bị phá vỡ một cách vô vọng và cam chịu thất bại. Bạn và nhóm của bạn cần phải cam kết sử dụng CM đúng cách và một phần trong đó là có sẵn một hệ thống kiểm tra. Thậm chí chỉ cần một VM mơ hồ cục bộ là đủ.

Điều này không chỉ giúp kiểm tra các thay đổi mới mà còn đóng vai trò là giường thử nghiệm cho nhân viên mới (hoặc nhân viên lớn tuổi chưa sử dụng hệ thống trong một thời gian) để làm quen với thiết lập ansible của bạn.

Về việc giữ / etc / in git: không, đừng làm điều này. Thư mục đó chỉ là một phần rất nhỏ của những gì ansible đang thay đổi, và có git tại chỗ sẽ chỉ khuyến khích mọi người thực hiện thay đổi cục bộ.

Giữ playbooks ansible của bạn trong git. Xem xét việc hạn chế các quyền sao cho chỉ bạn mới có thể áp dụng các thay đổi có thể nhìn thấy đối với máy chủ trực tiếp. Những người khác có thể gửi yêu cầu kéo với những thay đổi của họ, mà bạn có thể xem xét và hợp nhất thành chủ nếu thích hợp.

Có lẽ do thiếu kinh nghiệm của chúng tôi, tất nhiên chúng tôi không bao giờ có thể loại ra một tập hợp các nhiệm vụ có thể tìm thấy chính xác theo cách chúng tôi cần trong một lần, vì cấu hình là một quá trình thử và sai. Điều đó có nghĩa là trong thực tế, trước tiên chúng ta thường định cấu hình bất kỳ dịch vụ nào chúng ta muốn chạy trên máy chủ, sau đó chuyển sang các tác vụ có thể tìm thấy.

Mặc dù có những vấn đề khác (như không có môi trường thử nghiệm), bạn có thể có một sự cải thiện lớn bằng cách không làm điều này .

Một trong những mục tiêu thiết kế lõi Ansible của là phải idempotent , có nghĩa là chạy playbook của bạn nhiều lần không nên thay đổi bất cứ điều gì (trừ khi bạn đã thay đổi lượt). Do đó, khi tôi định cấu hình một phần mềm mới, các bước của tôi là:

1. Thay đổi các nhiệm vụ Ansible.
2. Chạy vở kịch.
3. Kiểm tra hệ thống và nếu nó không đúng, quay lại bước 1.
4. Cam kết thay đổi của tôi.

Nếu bạn không nghĩ rằng bạn sẽ viết đúng thứ đầu tiên trong Ansible, hãy viết nó bằng mọi cách và lặp đi lặp lại cho đến khi nó đúng, giống như bất kỳ mã nào khác. Điều này làm giảm đáng kể cơ hội quên Ansiblize một số thay đổi bạn đã thực hiện, vì mọi thay đổi bạn đã thực hiện đã có trong Ansible tại một số điểm trong quá trình phát triển của bạn.

Ansible có thời gian tăng tốc trước khi bạn vượt quá mức năng suất trước đó, nhưng một khi bạn làm thì trạng thái hệ thống rất dễ đảm bảo. Thực tiễn của bạn dường như không đồng bộ với các mục tiêu cuối cùng của bạn. Bạn có thể làm việc hiệu quả với bộ công cụ CM, trong khi vẫn duy trì các thực hành kỹ thuật vững chắc, nhưng cần có thời gian để cấu trúc chính xác. Bạn về cơ bản là hiệu quả giao dịch và dễ thực hiện, cho sự ổn định và khả năng mở rộng doanh nghiệp. Theo cùng một cách chính xác, một lập trình viên chuyên nghiệp có kinh nghiệm không viết ra những bản hack xấu xí, hậu quả luôn lớn hơn lợi ích.

Đối với người mới bắt đầu, bạn có thể có quá nhiều đầu bếp, không có quyền sở hữu rõ ràng, nếu vậy mong đợi một thảm kịch chung. Mỗi ưu tiên kinh doanh sẽ thổi phồng mối quan tâm kỹ thuật hệ thống mọi lúc, trừ khi nó được sử dụng rộng rãi và những gì còn lại phản ánh trực tiếp vào kỹ sư có trách nhiệm.

Một bộ công cụ CM không có khả năng được thiết kế bởi quản trị viên, đây là điều tôi vừa mới nhận ra. Họ có thể sử dụng lại công việc hiện có hoặc POSSIBLY mở rộng dựa trên cơ sở hợp lý, nhưng ngay cả khi đó nó sẽ đòi hỏi một lượng thực thi nặng nề. Những gì một Kỹ sư có thể làm, chỉ đơn giản là KHÔNG phải những gì một quản trị viên có thể làm. Nhiều khái niệm trong Ansible gần giống như trong một cơ sở mã, bạn có thể dạy một con trăn quản trị và mong đợi kết quả có thẩm quyền không? Không, chắc chắn là không, tôi mong đợi một công việc hack, vì vậy bạn cần làm cho nhiệm vụ được cấu trúc đủ để một công việc hack có thể chịu được.

Vì vậy, bạn cần thiết lập mọi thứ để thành công, giải pháp kỹ sư cho các điểm quản trị không cần thiết. Giao dịch hệ thống cấp thấp phức tạp cho những thứ mà quản trị viên thực sự có thể làm thành công. Một bộ công cụ CM sẽ KHÔNG cứu bạn khỏi sự không phù hợp về kiến ​​trúc hoặc thiết kế.

Vì vậy, trật tự là tùy thuộc vào modifactaion, rõ ràng bởi vì việc thực hiện phụ thuộc vào đường dẫn nào ít gây gián đoạn nhất cho trạng thái hiện tại của bạn.

1. Di chuyển bất kỳ công việc liên quan đến công việc liên quan đến công việc hệ thống đến một rundeck chuyên dụng.

2. Tách các nhiệm vụ trên hộp, bạn có thể có hai hoặc nhiều hộp trong một ngay bây giờ.

3. Thực hiện lại CM của bạn theo cách có cấu trúc chặt chẽ hơn và tuân theo các thực tiễn có thể giải thích tốt hơn, các vở kịch đại diện cho các đối tượng KHÔNG phải là chức năng hoặc vai trò. Mỗi hệ thống nên được mô tả trong một lần chơi.