Làm cách nào để cập nhật tệp cấu hình Nginx trên nhiều máy chủ giống hệt nhau cùng một lúc?


12

Chúng tôi đã có một nhóm máy chủ Nginx trên Amazon EC2, nơi chúng tôi thỉnh thoảng cần cập nhật các tệp cấu hình để thực hiện cài đặt mới.

Hiện tại chúng tôi có các cấu hình trong một AMI tùy chỉnh và nếu chúng tôi cần cập nhật, chúng tôi phải xây dựng lại các phiên bản AMI và sau đó là EC2. Chúng tôi đã có một số kịch bản trợ giúp, nhưng vẫn còn khá nhiều nỗ lực để làm điều đó. Có cách nào tốt hơn không?


3
ansible, saltstack để đặt tên một vài.
poige

Câu trả lời:


26

Có một số khái niệm mà bạn có thể tận dụng.

Chìa khóa thành công là tự động hóa

Tùy chọn đầu tiên là tiếp tục làm những gì bạn đang làm hiện tại, tức là xây dựng lại EC2 với mỗi thay đổi cấu hình . Chỉ trong một cách hoàn toàn tự động.

Vì hiện tại bạn đang thực hiện cập nhật cấu hình thông qua AMI, bạn tiến thêm một bước này và tạo một đường ống dẫn , khi thay đổi tệp cấu hình trong một số kho lưu trữ, sẽ:

  1. Tự động xây dựng một AMI mới - một trong những công cụ phổ biến nhất để làm điều đó là Packer
  2. Tự động xây dựng lại đội tàu Nginx của bạn - bạn đã có tất cả các máy chủ Nginx trong Nhóm tự động mở rộng với Bộ cân bằng tải ứng dụng ở phía trước. Nếu bạn không nên, nó sẽ giúp việc cập nhật đơn giản như cập nhật Cấu hình khởi chạy ASG và chờ các phiên bản được xây dựng lại từ AMI mới.

Tùy chọn thứ hai là giữ các cá thể tại chỗ và chỉ triển khai các tệp cấu hình , mà không xây dựng lại chúng. Nói chung, bạn có thể coi các tệp cấu hình là mã và triển khai thay đổi cấu hình của mình giống như cách bạn sẽ triển khai các bản phát hành mã. AWS có nhiều công cụ để giúp với điều đó.

  • AWS Elastic Beanstalk sử dụng Chef trong nội bộ và bạn có thể tạo kịch bản Nginx của mình cập nhật theo cách này.
  • Triển khai mã AWS , một công cụ triển khai hoàn toàn có thể tạo tập lệnh, tích hợp tốt với các phần khác của Bộ mã AWS :
    • Code Commit nơi bạn có thể giữ các tệp cấu hình Nginx của mình trong Git.
    • Đường ống mã có thể tự động kích hoạt triển khai bất cứ khi nào tệp cấu hình được cập nhật trong Code Commit.
  • Ansible hoặc Puppet là các công cụ không phải AWS phổ biến có thể giúp bạn giữ tất cả các máy chủ được cấu hình theo cùng một cách.

Khi bạn cảm thấy thoải mái với việc tự động hóa các cập nhật cấu hình Nginx này, bạn có thể muốn mở rộng tự động hóa sang phần còn lại của cơ sở hạ tầng.


Có một Tổng quan về whitepaper tuyệt vời về Tùy chọn triển khai trên AWS sẽ cung cấp cho bạn một cái nhìn tổng quan đẹp.

Tôi hy vọng điều đó sẽ giúp :)


Một thay thế cho Ansible hoặc Puppet là Salt, được thiết kế cho kiểu thiết lập chính / minion và sắp xếp tối ưu hóa cho các triển khai quy mô lớn hơn.
Araho

5

Lưu trữ cấu hình của bạn trên EFS và gắn EFS vào vị trí Cấu hình Nginx được mong đợi. Thay phiên đặt chúng trên Amazon S3 và thỉnh thoảng chạy đồng bộ hóa hoặc sử dụng s3fs (hãy cẩn thận s3fs có thể không đủ tốt để sử dụng sản xuất).

Khi bạn cần thay đổi cấu hình của mình, hãy tăng kích thước mong muốn của nhóm tự động của bạn lên gấp đôi những gì bạn cần để kích hoạt các phiên bản mới với cấu hình mới, sau đó quay lại những gì bạn cần sẽ loại bỏ các phiên bản cũ. Thay phiên chỉ cần làm một khởi động lại của các máy chủ.

Một tùy chọn khác là chỉ cần đẩy các cấu hình mới đến máy chủ của bạn bằng công cụ tự động hóa cơ bản, như triển khai mã AWS.

Các tùy chọn hoàn toàn tự động ở trên là tốt hơn về mặt kỹ thuật và sạch hơn, nhưng nếu bạn hiếm khi thay đổi cấu hình và muốn một giải pháp dễ dàng thì điều này có thể giúp ích.



1

Xây dựng lại các AMI hoặc tạo ra một đường ống triển khai đầy đủ như những người khác đề xuất chỉ để thay đổi tệp cấu hình có vẻ như là một quá mức cần thiết. Bạn nên sử dụng Ansible để đưa ra các thay đổi và giữ cho tất cả các nút của bạn được đồng bộ hóa. Có nhiều mô-đun Ansible có thể giúp bạn tự động hóa các tác vụ phổ biến.


Một lợi ích của cơ sở hạ tầng bất biến là bạn biết rằng bạn không có bất kỳ máy chủ "thú cưng" nào dễ hỏng và phải được bảo trì. Điều đó giúp bạn tự tin rằng bạn có thể tạo thêm máy chủ trong prod / DR / tests mà không gặp sự cố.
Tim
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.