Mô hình máy chủ bất biến với Docker / Ansible so với Ansible, Puppet và Foreman trong AWS?


9

Chúng tôi đang chạy vào một cuộc tranh cãi thú vị và rơi vào hai phe. Tôi quan tâm đến bất kỳ vấn đề cụ thể nào với ý tưởng hoặc vấn đề mà chúng tôi có thể thiếu. Thực sự, bất cứ điều gì có thể giúp chúng tôi đưa ra quyết định hoặc chỉ ra những điều chúng tôi không hạch toán. Tôi biết điều này theo quy tắc "không có ý kiến" một chút chặt chẽ nhưng tôi hy vọng nó vẫn là một câu hỏi chấp nhận được. Xin lỗi về chiều dài là tốt, có một chút sắc thái.

1) Một bên (của tôi - tôi không phải không có thành kiến) thấy mô hình máy chủ bất biến rất thú vị cho các hệ thống đám mây. Cuối cùng, chúng tôi đã chuyển mẫu tất cả các thành phần cơ sở hạ tầng của mình sang Docker. Các ứng dụng tùy chỉnh của chúng tôi xây dựng thông qua Jenkins trực tiếp thành hình ảnh Docker triển khai đến Docker Registry cục bộ. Sau đó, chúng tôi đã tạo ra một tập hợp lớn các vai trò Ansible và một playbook có khả năng tiếp cận với một máy chủ trống, cài đặt Docker và sau đó bảo Docker cài đặt tất cả các container khi cần. Sau một vài phút, toàn bộ ứng dụng và tất cả các cơ sở hạ tầng hỗ trợ của nó được nối dây và hoạt động - ghi nhật ký, giám sát, tạo / dân số cơ sở, v.v. Máy hoàn thành là một môi trường QA hoặc dev khép kín với một bản sao chính xác của ứng dụng. Kế hoạch của chúng tôi để mở rộng quy mô này sẽ là tạo Playbook mới để xây dựng các máy chủ AWS mới từ một AMI cơ sở đáng tin cậy (có thể là một hình ảnh rất trần trụi), triển khai ứng dụng sản xuất để xử lý quản lý và phát hành cấu hình và thường không bao giờ chỉnh sửa máy chủ nữa - chỉ cần làm cho họ một lần nữa Tôi không quan tâm đến việc có được những gì tôi mô tả làm việc trong thực tế - chỉ khi đó là một mô hình hợp lý.

2) Trại khác muốn sử dụng Puppet để xử lý quản lý cấu hình, Ansible để triển khai các ứng dụng tùy chỉnh của chúng tôi là tarball được tạo từ quá trình xây dựng của chúng tôi, Foreman để xử lý toàn bộ quá trình kích hoạt và quản lý quy trình và Katello để thực hiện một số lượng cơ sở quản lý hình ảnh. Các bản phát hành sẽ liên quan đến việc thay đổi cấu hình rối khi cần thiết và Ansible triển khai các thành phần được cập nhật với một số lượng phối hợp Foreman. Máy chủ sẽ được xây dựng một cách hợp lý nhanh chóng nếu chúng ta cần những cái mới nhưng mục đích không phải là biến chúng thành một phần của quy trình chuẩn. Điều này gần với mô hình máy chủ phượng hơn mặc dù có tuổi thọ cao.

Vì vậy, câu hỏi của tôi thực sự đi đến vấn đề này: mô hình máy chủ bất biến với các công cụ như tôi đã mô tả ở trên có thực sự như thực tế như nó xuất hiện không? Tôi thích ý tưởng rằng quy trình dàn dựng của chúng tôi thực sự có thể xây dựng toàn bộ bản sao của các ứng dụng trực tiếp, hãy để QA đập nó, sau đó chỉ cần lật bộ lưu trữ cơ sở dữ liệu và một số cài đặt DNS để làm cho nó hoạt động.

Hay mô hình máy chủ bất biến thất bại trong thực tế? Chúng tôi có nhiều kinh nghiệm với cả môi trường AWS và đám mây nên điều đó không thực sự đáng lo ngại - vấn đề là làm thế nào để có được một ứng dụng hợp lý tinh vi được triển khai một cách đáng tin cậy trong tương lai. Điều này được quan tâm đặc biệt vì chúng tôi phát hành khá thường xuyên.

Chúng tôi có Ansible làm hầu hết mọi thứ cần thiết ngoại trừ thực sự tạo máy chủ EC2 cho chúng tôi và điều đó không khó. Tôi đang gặp khó khăn để hiểu lý do tại sao bạn thực sự CẦN Puppet / Foreman / Katello trong mô hình này. Docker sạch sẽ và đơn giản hơn nhiều so với các kịch bản triển khai tùy chỉnh trong thực sự bất kỳ công cụ nào ngoài đó mà tôi có thể nói. Ansible dường như sử dụng đơn giản hơn nhiều so với Puppet khi bạn ngừng lo lắng về việc phải cấu hình chúng tại chỗ và chỉ cần xây dựng lại chúng với cấu hình mới. Tôi là người hâm mộ hiệu trưởng KISS - đặc biệt là tự động hóa nơi Luật Murphy hoạt động rầm rộ. Càng ít máy móc thì IMO càng tốt.

Bất kỳ suy nghĩ / ý kiến ​​hoặc đề xuất về cách tiếp cận sẽ được đánh giá rất cao!


Những thành kiến ​​của tôi phù hợp với bạn. Tôi đã sử dụng tất cả các hệ thống quản lý cấu hình chính trong nhiều tháng nếu không phải là nhiều năm tôi không thể tưởng tượng được việc sử dụng con rối cho một dự án mới trong thời gian này. Đầu bếp là một lựa chọn trưởng thành hơn nếu bạn muốn gắn bó với các hệ thống dựa trên ruby. Ansible dường như là giống tốt nhất trong những ngày này, nhưng muối cũng là một lựa chọn đúng đắn.
gà con

Con rối và ansible? Bạn sẽ có một khoảng thời gian tồi tệ.
dmourati

Docker mở ra khả năng sử dụng kubernetes, có nghĩa là tự động hóa, tự phục hồi, v.v. Trường container hiện đang trưởng thành và là lựa chọn rất tốt nếu ứng dụng của bạn có thể phù hợp với mô hình microservice
Droopy4096

Câu trả lời:


1

Trong công ty của chúng tôi, chúng tôi đã thực hiện thành công Puppet trên cơ sở hạ tầng di sản của khách hàng. Chúng tôi cũng đang sử dụng các container Docker để chạy một dịch vụ chuyên dụng (trên thực tế là một ứng dụng cũ được cắt và xoắn để phù hợp với các container).
Tôi không hài lòng với các container khi lần đầu tiên tôi nhìn chằm chằm vào chúng (vâng ... ứng dụng 30kb trở thành hình ảnh nặng 200 MB) nhưng khi tôi phải tạo lại toàn bộ môi trường sau một thảm họa nhỏ, tôi đã thay đổi quyết định. Tôi nghĩ Docker đã được phát minh chính xác cho việc này: triển khai nhanh và thường xuyên mà không phải lo lắng về cấu hình máy chủ. Nếu bạn thiết kế các thùng chứa chính xác, bạn có thể chuyển đổi giữa các nhà cung cấp đám mây, máy tính xách tay của nhà phát triển và trung tâm dữ liệu colocation một cách dễ dàng. Bởi vì tất cả những gì bạn cần là một hộp Linux vanilla với Docker daemon.

  • Trong kịch bản 1) bạn có mọi thứ ở một nơi (ý tôi là một vì với Docker bạn sẽ có mã AND cấu hình trong cùng một kho lưu trữ) dễ quản lý, đọc và triển khai.
  • Trong kịch bản 2), bạn phải lưu trữ các bộ phận cấu hình cho 3 công cụ (!) Khác nhau trong một mã repo và mã ứng dụng khác, điều này làm cho mọi thứ phức tạp hơn

Tôi cũng đã sử dụng Puppet trong dự án trước đây và kinh nghiệm của tôi cho đến nay là máy chủ bất biến có thể đạt được thay vì với Docker thay vì Puppet hoặc Chef. Tôi tin rằng các công cụ Quản lý cấu hình hữu ích hơn cho Nhà cung cấp đám mây hơn là nhóm phát triển.


0

Đây là 2 euro của tôi.

2 tùy chọn bạn đề xuất là các tùy chọn hợp lệ để đạt được (một số loại) bất biến.
Tôi nghĩ bạn nên chọn người mà bạn dễ tin tưởng hơn.
Tuy nhiên, từ những gì bạn viết có vẻ như chưa có sự đồng thuận nào.
Có lẽ một lựa chọn thứ ba là bắt buộc sau đó? ;)

Tuy nhiên, vì tính bất biến như vậy không phải là mục tiêu mà là phương tiện để đảm bảo các thuộc tính khác (không bị trôi cấu hình, ổn định tốt hơn, ...).
Tôi muốn nêu rõ mục tiêu của mình, đặt một số số liệu để xác thực chúng và thực hiện một số thử nghiệm bằng cách sử dụng 2 tùy chọn. Sau đó, bạn sẽ có một số số liệu để chọn một số liệu phù hợp nhất với doanh nghiệp của bạn.

Chúc may mắn!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.