Triển khai mã đến nhiều máy chủ ngoại vi

Chúng tôi có một tình huống trong đó chúng tôi có nhiều máy chủ cân bằng tải trỏ đến một cơ sở dữ liệu chung.

Trong hoạt động bình thường của mọi thứ, điều này hoạt động tốt và cung cấp dự phòng, khả năng mở rộng, vv

Tuy nhiên, chúng tôi đang tìm cách triển khai là một chút việc vặt.

Chúng tôi đang sử dụng các tính năng rộng rãi và đang cố gắng tự động hóa triển khai. Triển khai tại thời điểm này không đáng tin cậy lắm.

Trong một hình thức đơn giản, tập lệnh triển khai cho mỗi máy chủ có hai giai đoạn

1. Cập nhật tập tin

2. Hoàn nguyên các tính năng (sẽ quản lý các phụ thuộc, thay đổi cài đặt, v.v.)

Có cách thực hành tốt nhất nào để triển khai trên nhiều máy chủ mà không khiến chúng ở trạng thái không nhất quán không?

Theo như tôi có thể thấy nếu bạn triển khai bước 1 và 2 cho máy chủ A thì nó sẽ khiến máy chủ B bị hỏng, nếu bạn thử bước một trên cả hai máy chủ trước khi tiếp tục bước 2 thì cả hai sẽ bị hỏng trong một thời gian.

Có lẽ bạn nên tìm hiểu về Aegir , đây là hệ thống quản lý / triển khai trang web Drupal linh hoạt và mạnh mẽ nhất. Nó có thể quản lý 'nền tảng' trải rộng trên nhiều đầu web hoặc 'cụm', cũng như một loạt các cấu hình khác.

Tôi khuyên bạn nên đọc qua tài liệu cộng đồng của họ nói chung là khá tốt, cũng như đọc qua bài viết giới thiệu và tổng quan tuyệt vời của Mig5 và một số bài viết khác của anh ấy như bài viết này .

Bạn cũng có thể nhận được hỗ trợ tốt trong kênh #aegir IRC.

Sẽ có một chút thay đổi trong quy trình làm việc, điều này chắc chắn có thể mất một chút thời gian để bạn quay đầu lại, nhưng một khi bạn ở đó, bạn sẽ không nhìn lại.

Tại công ty của chúng tôi, chúng tôi duy trì RẤT NHIỀU trang web Drupal, thiết lập hiện tại của chúng tôi diễn ra như sau:

• Mỗi cơ sở mã đều có git repo của riêng nó
• Các tính năng mới có khả năng không đủ ổn định cho phiên bản tiếp theo có được nhánh tính năng của riêng chúng trong git

Ở trên tôi có thể nói là khá phổ biến đối với hầu hết các trang web Drupal.

Điều chúng tôi làm đặc biệt tại công ty của chúng tôi là gói debian các trang web để triển khai bằng lệnh drush tùy chỉnh - ' Bao bì Debian Drush '.

Bao bì Debian Drush cung cấp lệnh Drush để xây dựng các gói Debian của các trang web Drupal như một phương tiện để triển khai các trang web Drupal lên các máy chủ Debian hoặc Ubuntu.

Bao bì Debian Drush sử dụng hệ thống móc nối Drupal để xây dựng gói Debian phù hợp nhất với nhu cầu trang web của bạn. Các tính năng bao gồm:

• Cấu hình máy chủ ảo tự động cho máy chủ web Apache2 và Nginx
• Thiết lập cron trong /etc/cron.d
• Triển khai mã tự động với phân chia phân vùng cho các trang web / mặc định / tệp
• Cấu hình tự động thông qua công cụ cài đặt gỡ lỗi dpkg
• Quy trình triển khai tự động
• trình xử lý Git VCS tùy chỉnh để xây dựng các gói từ Git

Điều đó có nghĩa là gì?

Để xây dựng một bản phát hành:

cd /path/to/drupal-root
drush dh-make

Để triển khai một bản phát hành, đầu tiên SCP .deb cho tất cả các máy chủ web trong cụm. Sau đó, trên tất cả các máy chủ web chạy (bạn có thể sử dụng gói linux cssh để nhập lệnh cho tất cả các máy chủ trong cụm máy chủ cùng một lúc):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Trên một máy chủ web chạy:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Làm xong

Tất nhiên để khôi phục điều này bây giờ là tầm thường từ quan điểm cơ sở mã, chỉ cần cài đặt phiên bản trước của .deb cho tất cả các máy chủ web và khôi phục cơ sở dữ liệu.

Rất vui được trả lời bất kỳ câu hỏi nào về việc này

Phần nào của quá trình triển khai là một việc vặt / không đáng tin cậy?

Nếu đó là vấn đề "máy chủ cập nhật A thì B / không nhất quán", vậy còn việc đưa trang bảo trì trong thời gian bạn đẩy thì sao? Trang bảo trì lên, cập nhật mã trên cả hai đầu web, chạy update.php trên một trong số chúng, trang bảo trì xuống. Đó là kịch bản khá dễ dàng.

Một tùy chọn khác: tùy thuộc vào loại trang web bạn chạy, bạn có thể tạo "chế độ chỉ đọc" để đá tất cả người dùng ngoại tuyến và vô hiệu hóa đăng nhập / đăng ký. Sao chép DB của bạn sang DB thứ hai trên cùng một hộp db, sao chép giao diện người dùng của bạn vào một docroot mới, thực hiện các cập nhật của bạn ở đó, sau đó liên kết symroot của Apache với docroot front end mới. Quy trình làm việc giống như:

1. Chế độ chỉ đọc trên
2. CHỌN current_db VÀO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. cập nhật mã vào new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Chế độ chỉ đọc tắt.

Nó sẽ phụ thuộc vào những thay đổi bạn đang thực hiện, như Entendu gợi ý. Tỷ lệ cập nhật mã nào có thể chạy mà không gây ra lỗi nếu cơ sở dữ liệu chưa được cập nhật? Đối với mọi thứ không phụ thuộc vào cập nhật cơ sở dữ liệu (và có thể bạn có thể thay đổi quy trình phát triển một chút để làm cho điều này trở nên phổ biến hơn) thực sự không có gì đặc biệt để làm. Tôi giả sử bạn muốn thực hiện triển khai với thời gian chết tối thiểu, nếu không, điều này sẽ chỉ thực hiện một số thao tác đồng bộ cơ bản. Trong trường hợp này, sẽ luôn có một số cửa sổ thời gian với các hiệu ứng không mong muốn (ngay cả khi nó chỉ có trang web ở chế độ chỉ đọc) nhưng tôi nghĩ rằng nó có thể khá nhỏ trong hầu hết thời gian.

Bạn có thể thực hiện tối ưu hóa cơ bản như thiết lập thư mục "mới" trên mỗi máy chủ trước và sau đó chuyển đổi tất cả chúng để trỏ đến thư mục mới cùng một lúc (có thể sử dụng liên kết tượng trưng như trong câu trả lời của Entendu) để bạn có thể nhận được tất cả máy chủ chuyển sang tập tin mới trong vòng 5-10 giây.

Điều đó để lại vấn đề cập nhật cơ sở dữ liệu. Nếu chúng chỉ là loại phải được thực hiện từ một máy chủ, bạn có thể muốn đặt các máy chủ khác ở chế độ bảo trì hoặc điều chỉnh bộ cân bằng tải để không sử dụng chúng trong khi điều này xảy ra. Tất nhiên, nếu chúng không thể được thực hiện trong khi người dùng đang hoạt động trên trang web, bạn sẽ chỉ cần có mọi thứ trong chế độ bảo trì nhưng đối với các cập nhật đơn giản, đây có thể là điều bạn có thể làm trong khoảng 30 giây hoặc ít hơn.

Có thể có các tập lệnh triển khai khác nhau cho các loại thay đổi khác nhau, vì vậy bạn có thể chạy quy trình tối thiểu cần thiết cho dù đó chỉ là sao chép tệp, chạy cập nhật cơ sở dữ liệu nhỏ hoặc thực hiện thay đổi cơ sở dữ liệu lớn.

Nếu bạn có thể tối ưu hóa cập nhật tệp và cơ sở dữ liệu của mình và xem liệu có những thay đổi đơn giản nào bạn có thể thực hiện theo cách mọi thứ được phát triển, điều đó có thể đưa bạn đến gần hơn nhưng tôi không biết liệu có bất kỳ điều gì mới đối với bạn không :)

Aegir rất hữu ích trong việc quản lý một mạng lưới các trang web. Tôi đã sử dụng nó để triển khai và quản lý hơn 2000 trang web cho một khách hàng.

Câu hỏi của bạn cho thấy rằng bạn muốn quản lý một trang web có nhiều đầu web. Nếu đó là trường hợp Aegir có thể ít hữu ích hơn cho bạn. Thay vào đó, tôi khuyên bạn nên xem xét việc sử dụng một hệ thống tệp hỗ trợ kết nối mạng. Điều này không chỉ đảm bảo mã của bạn được giữ đồng bộ mà còn có nghĩa là tải lên của bạn có sẵn trên tất cả các nút.

Trong lịch sử mọi người đã sử dụng NFS cho phép hệ thống tệp của một máy chủ được chia sẻ với các nút khác. Thật không may, điều này giới thiệu một điểm thất bại duy nhất, bởi vì nếu máy chủ NFS bị khóa hoặc chết thì trang web của bạn không thể được phục vụ.

Nếu bạn sẵn sàng thỏa hiệp một chút về hiệu suất của io để ủng hộ một máy chủ đáng tin cậy hơn, thì tôi sẽ khuyên dùng GlusterFS . Tôi đã sử dụng trong một vài môi trường sản xuất. Nó không hoàn hảo nhưng tốt hơn NFS. Gluster cho phép webhead luôn đọc cục bộ và sau đó ghi được sao chép sang các nút khác.

Về mặt chiến lược triển khai của bạn, bạn nên có drush như công cụ đầu tiên trong danh sách của bạn. Với drush, bạn sẽ có thể tự động hóa các bước triển khai của mình. Bạn nên xem xét thêm Jenkins vào hỗn hợp để bạn có thể theo dõi các công việc triển khai của mình và xác định các mẫu nếu mọi thứ không thành công. Capistrano có thể hữu ích để tự động hóa các bước liên quan đến việc triển khai. Nếu bạn làm mọi thứ đúng cách, bạn có thể làm cho nó để người dùng của bạn thậm chí không bao giờ biết rằng bạn đã triển khai.