Làm cách nào để tự động cập nhật danh sách máy chủ ngược dòng nginx khi tên máy chủ aws ec2 thay đổi hoặc tăng?

Tôi muốn thiết lập autoscaling trong AWS. Tôi không muốn sử dụng đàn hồi tải cân bằng.

Autoscalling trong Amazon tạo ra các phiên bản EC2 liền mạch trong các đợt tăng nhu cầu để duy trì hiệu suất và tự động giảm trong thời gian tạm lắng nhu cầu để giảm thiểu chi phí.

Vì các phiên bản EC2 này được tạo tự động, tên máy chủ của chúng không được biết đến NGINX.

Tôi biết và đã thiết lập ngược dòng trong nginx tới 10 trường hợp EC2.

Tôi muốn có thể thêm / cập nhật / xóa tên máy chủ tự động vào cấu hình nginx ngược dòng của mình, khi tự động thêm / cập nhật / xóa các phiên bản EC2.

— Luis Lobo Borobia
nguồn

Bạn cần xóa "autoscaling" khỏi câu hỏi của bạn. Tự động hóa là một thuật ngữ AWS. Tôi nghĩ điều bạn muốn nói là bạn muốn tự động chia tỷ lệ (theo chiều ngang), bằng cách thêm nhiều nút ngược dòng vào nginx của bạn hoạt động như một LB và bạn đang hỏi cách tự động sửa đổi cấu hình nginx của mình khi các nút ngược dòng được thêm / xóa / sửa đổi. Nếu điều này là như vậy, xin vui lòng chỉnh sửa câu hỏi của bạn cho phù hợp.

— Talonx

tốt, thực sự, tôi biết autoscalling là gì, và tôi muốn nói điều đó. Tôi muốn trộn cả hai. Tôi sẽ cập nhật câu hỏi.

— Luis Lobo Borobia

Câu hỏi bây giờ rõ ràng hơn, trong ý định của nó. Tôi muốn bỏ phiếu để mở lại, nhưng tôi không thấy một tùy chọn - đoán tôi chưa có đủ đại diện.

— Talonx

Cảm ơn bạn @talonx Tôi hy vọng những người khác có thể nâng cao để tìm câu trả lời của tôi

— Luis Lobo Borobia

Tôi nghĩ rằng bạn có thể kết hợp các thông báo tự động hóa AWS (được gửi bằng SNS) - giả sử nó trả về tên máy chủ của phiên bản mới được tạo / kết thúc - và một trong các API nginx của bên thứ ba để cập nhật và tải lại cấu hình nginx của bạn. Xin lỗi vì mơ hồ - Tôi không rành lắm về API tự động hóa.

— Talonx

Câu trả lời:

Điều này có thể đạt được bằng cách sử dụng Amazon SDK (tôi gần như đã hoàn thành nó, sẽ đưa nó lên github), sử dụng dịch vụ SNS, EC2 và Autoscaling.

Tôi đã làm theo các bước dưới đây để đạt được điều này:

Kích hoạt thông báo HTTP và đăng ký máy chủ web của tôi.
Đã thêm móc vòng đời với nhịp tim 1 phút (để chờ 1 phút trước khi kết thúc) vào nhóm tự động hóa của tôi để kết thúc máy chủ
Tạo một tệp chỉ mục để phân tích thông điệp để phát hiện loại tin nhắn đó là gì (tức là Khởi chạy hoặc Chấm dứt)
Khi loại sự kiện được quyết định, tôi đã truy vấn EC2 để lấy ip riêng của cá thể
Trong trường hợp Khởi động, đợi cho đến khi tiêu đề 200 được nhận và sau đó thêm ip vào nginx config và tải lại
Trong trường hợp chấm dứt, hãy xóa IP khỏi cấu hình và tải lại nginx

Vui lòng tìm tập lệnh tại đây https://github.com/singhupendra/aws-autoscale

— Upendra
nguồn

Bất kỳ cơ hội bạn đăng điều này trên github? Tôi đang cố gắng làm điều tương tự và bất kỳ trợ giúp sẽ được đánh giá cao.

— Aaron

vui lòng sử dụng - github.com/singhupendra/aws-autoscale

— Upendra

Cảm ơn bạn @talonx, tôi đã thực hiện một số nghiên cứu, Amazon Autoscale có một api để truy vấn trạng thái nhóm tự động hóa hiện tại và liệt kê các thành viên của nó. Nó trả về id cá thể ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_Vquests.html#query-example ), sau đó bạn có thể sử dụng các công cụ mô tả để lấy tên máy chủ ( http: // docs .aws.amazon.com / AWSEC2 / mới nhất / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) và cuối cùng tạo lại tệp bao gồm ngược dòng. Tôi có thể cảm nhận các thông báo Tự động hóa để khởi chạy một quy trình thực hiện các tác vụ này.

Tôi vẫn không thực hiện nó nhưng đó là một cách để đi.

Người ta cũng có thể sử dụng Tự động định tuyến với SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotutions.html

— Luis Lobo Borobia
nguồn

Đây là cơ bản những gì tôi đã làm. Tôi đã viết một kịch bản ruby chạy mỗi N phút. Sử dụng SDK AWS, nó truy vấn các thành viên của ASG và sử dụng mẫu ERB, nó tạo ra một cấu hình mới. Nếu cấu hình mới khác với cấu hình hiện tại, nó sẽ sao chép nó vào vị trí và báo cho daemon (haproxy trong trường hợp của tôi) tải lại cấu hình của nó. Lưu ý rằng các cá thể vẫn còn trong ASG một chút sau khi chúng bị chấm dứt, vì vậy hãy đảm bảo cá thể.status ==: đang chạy. Cũng lưu ý rằng nếu phải mất N phút sau khi phiên bản được khởi chạy cho nó để phục vụ các yêu cầu thì đừng sử dụng ngay bây giờ> instance.launch_time + N.

— Mark Wagner

Cảm ơn bạn @MarkWagner. Có khả năng nào bạn có thể chia sẻ kịch bản đó ở đâu đó không? Gist, github? Cảm ơn!

— Luis Lobo Borobia

Bạn có gặp may mắn với kịch bản này không? Có một ví dụ trên github hoặc ở nơi khác?

— Aaron

Không nhưng ngay bây giờ nginx-plus (phiên bản trả phí) cho phép điều này nhiều hơn.

— Luis Lobo Borobia

Bản thân tôi chưa thực hiện điều này, nhưng tôi đang tìm cách sử dụng cấu hình lại nhanh chóng của NGiNX Plus . Tôi nghĩ rằng AMI hoặc quản lý cấu hình (Puppet, Salt hoặc tương tự) thiết lập một thể hiện của Auto Scaleing Group, có thể truy cập API điều chỉnh lại NGiNX (có lẽ, thông qua một tên miền Route53 nội bộ để không có IP cố định nào cần được sử dụng) và thêm chính nó vào cụm ngược dòng cho proxy ngược. Sau đó, kiểm tra sức khỏe tích hợp của NGiNX sau đó sẽ tiếp quản trường hợp [đã thêm] đó và thả nó trong trường hợp nó không khả dụng. Đây có vẻ là giải pháp sạch nhất và không có sự chậm trễ trong việc thêm cá thể, và hầu như không có bất kỳ sự chậm trễ nào trong việc loại bỏ nó vì NGiNX Plus có tính năng kiểm tra sức khỏe ngoài băng.

Cách tiếp cận này tránh cần phải thiết lập một hệ thống tự động phát hiện (Consul, Serf, hoặc như vậy) mà đối với các thiết lập nhỏ hơn thường có vẻ như quá nhiều cả về mặt thiết lập / quản trị cũng như các trường hợp EC2 cần thiết. Lãnh sự, ví dụ, yêu cầu tối thiểu ba trường hợp để ổn định. Serf có thể tự chạy trên các phiên bản ASG, nhưng vẫn còn chi phí duy trì và nếu ASG giảm xuống còn một hoặc hai trường hợp, bạn sẽ mất đại biểu.

Cuối cùng, điều này có thể được kết hợp với thông báo tự động về các thay đổi của nhóm tự động thay đổi, có lẽ trên (các) máy chủ NGiNX đang / được sử dụng để cân bằng tải. Một người nghe được kích hoạt bởi thông báo như vậy (đây có thể là những gì Upendra cũng đã đề cập) sau đó có thể ngay lập tức thêm phiên bản mới vào NGiNX thông qua API sửa đổi nhanh chóng. Bên cạnh chi phí NGiNX Plus, điều này khiến người ta tự hỏi tại sao mọi người sẽ sử dụng đàn hồi tải cân bằng với nhiều vấn đề của nó ngay từ đầu.

Sửa 2015/12/07: ngx_openresty 's cân bằng-by-lua ( xem thread GitHub này ) Mời một một giải pháp mã nguồn mở có thể cho nóng thêm / gỡ bỏ các máy chủ từ nhóm thượng nguồn nginx. Tôi chưa tự mình thử nghiệm điều này, nhưng muốn thêm một đề cập ở đây cho bất kỳ ai tình cờ thấy bài đăng này.

— Ville
nguồn