Tùy chọn cho tính khả dụng cao của Multisite với Puppet

Tôi duy trì hai trung tâm dữ liệu và khi nhiều cơ sở hạ tầng quan trọng của chúng tôi bắt đầu được kiểm soát thông qua con rối, điều quan trọng là công việc của con rối ở trang web thứ hai nếu trang web chính của chúng tôi thất bại.

Thậm chí tốt hơn là có một loại thiết lập hoạt động / hoạt động để các máy chủ tại trang web thứ hai không bỏ phiếu qua mạng WAN.

Có bất kỳ phương pháp tiêu chuẩn của con rối nhiều trang web có sẵn cao?

Con rối thực sự cho vay chính nó khá tốt cho môi trường đa chủ, với sự cẩn thận. Cái chính? Rất nhiều phần của Puppet muốn được tập trung. Cơ quan cấp chứng chỉ, kho lưu trữ và bảng điều khiển / dịch vụ báo cáo, cấu hình filebucketing và được lưu trữ - tất cả chúng đều hoạt động tốt nhất (hoặc đơn giản là yêu cầu) một thiết lập trong đó chỉ có một nơi để chúng nói chuyện.

Tuy nhiên, khá khả thi để có được nhiều bộ phận chuyển động làm việc trong môi trường đa chủ, nếu bạn ổn với việc mất một số chức năng một cách duyên dáng khi bạn mất trang web chính.

Hãy bắt đầu với chức năng cơ bản để có được một nút báo cáo cho chủ:

Mô-đun và biểu hiện

Phần này đơn giản. Phiên bản kiểm soát chúng. Nếu đó là hệ thống kiểm soát phiên bản phân tán, thì chỉ cần tập trung và đồng bộ hóa, và thay đổi luồng đẩy / kéo của bạn khi cần trong trang web chuyển đổi dự phòng. Nếu đó là Subversion, thì có lẽ bạn sẽ muốn svnsyncrepo đến trang web failover của bạn.

Cơ quan cấp chứng chỉ

Một tùy chọn ở đây là chỉ cần đồng bộ hóa các tệp thẩm quyền chứng chỉ giữa các thạc sĩ, để tất cả chia sẻ cùng một chứng chỉ gốc và có khả năng ký chứng chỉ. Điều này luôn luôn đánh tôi là "làm sai";

• Một chủ có thực sự thấy chứng chỉ của chính mình được trình bày trong máy khách xác thực cho một kết nối đến từ một chủ khác là hợp lệ không?
• Điều đó đáng tin cậy sẽ làm việc cho dịch vụ kiểm kê, bảng điều khiển, vv?
• Làm thế nào để bạn thêm tên alt DNS hợp lệ bổ sung xuống đường?

Tôi không thể thành thật nói rằng tôi đã thực hiện kiểm tra kỹ lưỡng tùy chọn này, vì nó có vẻ khủng khiếp. Tuy nhiên, có vẻ như Puppet Labs không tìm cách khuyến khích tùy chọn này, theo ghi chú ở đây .

Vì vậy, những gì để lại là có một chủ CA trung tâm. Tất cả các mối quan hệ tin cậy vẫn hoạt động khi CA ngừng hoạt động do tất cả các máy khách và chủ khác lưu trữ chứng chỉ CA và CRL (mặc dù chúng không làm mới CRL thường xuyên như vậy), nhưng bạn sẽ không thể ký chứng chỉ mới cho đến khi bạn có thể sao lưu trang chính hoặc khôi phục bản gốc CA từ bản sao lưu tại trang dự phòng.

Bạn sẽ chọn một chủ để hành động như CA và để tất cả các chủ khác vô hiệu hóa nó:

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

Sau đó, bạn sẽ muốn hệ thống trung tâm đó nhận được tất cả lưu lượng truy cập liên quan đến chứng chỉ. Có một vài lựa chọn cho việc này;

1. Sử dụng SRVhỗ trợ bản ghi mới trong 3.0 để trỏ tất cả các nút tác nhân đến đúng vị trí của CA -_x-puppet-ca._tcp.example.com
2. Thiết lập ca_servertùy chọn cấu hình trong puppet.conftất cả các tác nhân

3. Proxy tất cả lưu lượng truy cập cho các yêu cầu liên quan đến CA từ các đại lý đến chủ chính xác. Chẳng hạn, nếu bạn đang chạy tất cả các chủ của mình trong Apache thông qua Hành khách, thì hãy định cấu hình này cho những người không phải CA:

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

Và rằng nên làm điều đó.

Trước khi chúng tôi chuyển sang các dịch vụ phụ trợ, một lưu ý phụ;

Tên DNS cho chứng chỉ chính

Tôi nghĩ rằng điều này ngay tại đây là lý do thuyết phục nhất để chuyển sang 3.0. Giả sử bạn muốn trỏ một nút vào "bất kỳ tổng thể làm việc của ol".

Dưới 2.7, bạn cần một tên DNS chung giống như puppet.example.comvà tất cả các bậc thầy đều cần điều này trong chứng chỉ của họ. Điều đó có nghĩa là thiết lập dns_alt_namescấu hình của họ, cấp lại chứng chỉ mà họ đã có trước khi được định cấu hình là chủ, cấp lại chứng chỉ đó khi bạn cần thêm tên DNS mới vào danh sách (như nếu bạn muốn có nhiều tên DNS vào có đại lý thích chủ trong trang web của họ) .. xấu xí.

Với 3.0, bạn có thể sử dụng SRVhồ sơ. Cung cấp cho tất cả khách hàng của bạn này;

[main]
    use_srv_records = true
    srv_domain = example.com

Sau đó, không có certs đặc biệt cần thiết cho các bậc thầy - chỉ cần thêm một bản ghi mới vào SRVRR của bạn tại _x-puppet._tcp.example.comvà bạn đã thiết lập, đó là một bậc thầy sống trong nhóm. Tốt hơn nữa, bạn có thể dễ dàng làm cho logic lựa chọn tổng thể tinh vi hơn; "bất kỳ bậc thầy làm việc nào của ol, nhưng thích cái trong trang web của bạn" bằng cách thiết lập các bộ SRVhồ sơ khác nhau cho các trang web khác nhau; không dns_alt_namescần thiết

Báo cáo / Bảng điều khiển

Điều này hoạt động tốt nhất tập trung, nhưng nếu bạn có thể sống mà không có nó khi trang web chính của bạn ngừng hoạt động, thì không có vấn đề gì. Chỉ cần định cấu hình tất cả các chủ của bạn với vị trí chính xác để đặt báo cáo ..

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

..và bạn đã sẵn sàng. Việc không tải lên báo cáo là không nghiêm trọng đối với hoạt động chạy cấu hình; nó sẽ bị mất nếu bánh mì nướng của máy chủ bảng điều khiển.

Hàng tồn kho

Một điều tuyệt vời khác để dán vào bảng điều khiển của bạn là dịch vụ kiểm kê. Với facts_terminuscài đặt được restkhuyến nghị trong tài liệu, điều này thực sự sẽ phá vỡ cấu hình chạy khi dịch vụ kiểm kê trung tâm ngừng hoạt động. Mẹo ở đây là sử dụng inventory_serviceđầu cuối trên các bậc thầy không phải trung tâm, cho phép thất bại duyên dáng ..

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

Có máy chủ khoảng không quảng cáo trung tâm của bạn được đặt để lưu trữ dữ liệu khoảng không quảng cáo thông qua ActiveRecord hoặc PuppetDB và nó sẽ được cập nhật bất cứ khi nào có dịch vụ.

Vì vậy - nếu bạn ổn với môi trường quản lý cấu hình barebones đẹp, nơi bạn thậm chí không thể sử dụng CA để ký chứng nhận nút mới cho đến khi được khôi phục, thì điều này có thể hoạt động tốt - mặc dù nó thực sự tốt nếu một số thành phần này thân thiện hơn một chút để được phân phối .

Cách tiếp cận "con rối vô chủ" mà Ladadadada mô tả là cách tôi quen thuộc nhất (về cơ bản là những gì chúng tôi làm với radmind tại công ty của tôi). Tôi đoán chính xác hơn đó là "Nhiều chủ được đồng bộ hóa bởi một quy trình bên ngoài", trong đó bất kỳ máy chủ cụ thể nào cũng có thể (về mặt lý thuyết) phục vụ toàn bộ vũ trụ của chúng ta trong trường hợp khẩn cấp.

Trong trường hợp của chúng tôi vì bản chất của radmind, chúng tôi chỉ đơn giản rsynclà bản sao và tệp dữ liệu từ một chủ được phê duyệt đến máy chủ radmind của mỗi trang web từ xa và khách hàng lấy các bản cập nhật của họ từ máy chủ với tên máy chủ ngắn radmind(thông qua phép thuật resolv.confnày đánh giá radmind.[sitename].mycompany.com- luôn luôn là cục bộ máy chủ radmind. Nếu máy chủ cục bộ ngừng hoạt động, đủ dễ để ghi đè và trỏ đến bất kỳ máy chủ nào của trang web khác).

Loại quy trình rsync này có thể cũng hoạt động trong tình huống của bạn, nhưng có lẽ nó không tối ưu so với giải pháp dựa trên kiểm soát phiên bản.

Đối với con rối hoặc đầu bếp, một hệ thống dựa trên kiểm soát phiên bản có ý nghĩa hơn so với rsync đơn giản vì một số lý do - vấn đề lớn là bạn đang kiểm soát các kịch bản múa rối (chứ không phải toàn bộ hình ảnh hệ điều hành như bạn làm với radmind).
Vì các lợi ích bổ sung của quản lý dựa trên kiểm soát phiên bản, bạn có thể có nhiều người làm việc trên kho lưu trữ cùng một lúc (chiến thắng tuyệt vời cho sự song song), bạn sẽ nhận được lịch sử sửa đổi miễn phí và nếu ai đó phá vỡ môi trường Puppet, bạn sẽ dễ dàng quay lại (giả sử bạn ' Đang sử dụng gitbạn cũng có git blamenhững gì nó nói trên tin).
Phân nhánh và hợp nhất sáng tạo thậm chí cho phép bạn xử lý một bản nâng cấp hệ điều hành lớn hoặc chuyển đổi khác trong khung kiểm soát phiên bản - Một khi bạn đã làm đúng, chỉ cần chuyển sang nhánh mới và (hy vọng) việc đẩy sản xuất sẽ chỉ hoạt động.

Tôi đã thực hiện điều này ở đây có lẽ tôi sẽ tận dụng các móc nối trước và sau cam kết trong git để đảm bảo rằng các cấu hình con rối được cam kết là lành mạnh (phía trước của khách hàng) và đẩy chúng ra phần còn lại của vũ trụ nếu chúng là (bài đăng phía máy chủ - cũng có thể kích hoạt cập nhật môi trường nếu chính sách triển khai của bạn cho phép hành vi đó).

Về việc đưa lên các máy chủ con rối mới ở mỗi trang web, bạn chỉ cần kiểm tra môi trường con rối cho từng con rối từ xa và sử dụng công cụ hack giải quyết tên máy chủ mà tôi đã mô tả ở trên hoặc IP dịch vụ bất kỳ được chuyển hướng đến các hệ thống địa phương như Michuelnik đề xuất ( cái sau sẽ tiện nếu bạn muốn tự động chuyển đổi dự phòng nếu một người điều khiển rối của một trang web nổ tung) để đảm bảo mỗi trang web nhìn thấy người điều khiển rối "đúng" và không làm tắc các liên kết WAN của bạn đang cố cập nhật.

Mọi người tại Thanh toán Brain Tree rõ ràng đã kết hợp các giải pháp rsync và kiểm soát phiên bản cùng với một số tác vụ Capistrano tùy chỉnh - giải pháp của họ dường như được thực hiện một nửa theo nghĩa là vẫn dựa vào các yếu tố quy trình làm việc thủ công, nhưng nó có thể được điều chỉnh và tự động mà không cần quá nhiều công việc.
Người kiểm tra cưỡng chế hoang tưởng trong tôi rất thích noopbước kiểm tra sự tỉnh táo của họ - người ghét các quy trình thủ công trong tôi mong muốn một mức độ tự động hóa xung quanh nó ...