Đây là một ứng dụng PHP. Làm cách nào để giảm thiểu thời gian chết trong khi cập nhật toàn bộ cơ sở mã?
Đây là một ứng dụng PHP. Làm cách nào để giảm thiểu thời gian chết trong khi cập nhật toàn bộ cơ sở mã?
Câu trả lời:
Những gì chúng ta thường làm, tại nơi làm việc là:
/www/app-2009-09-01/www/application/www/app-2009-09-08/www/application, nhưng chỉ đến các nguồn mới:/www/app-2009-09-08Tất cả quá trình này được thực hiện thông qua một tập lệnh tự động (điều duy nhất không tự động là chúng tôi khởi chạy nó khi cần thiết). Điều này có nghĩa là :
Một ưu điểm khác của tiền lệ liên kết tượng trưng này là rất dễ "khôi phục" bản cập nhật nếu chúng tôi nhận thấy một lỗi nghiêm trọng chỉ sau khi đưa phiên bản mới của các nguồn vào sản xuất: chúng tôi chỉ cần chuyển lại các liên kết tượng trưng.
Tất nhiên, điều này không ngăn bạn thử nghiệm phiên bản mới trên máy chủ dàn dựng của bạn trước khi đưa nó vào sản xuất - nhưng, ai biết được ... Đôi khi, có một lỗi thực sự lớn mà không ai có thể nhìn thấy trong khi kiểm tra :-(
Chẳng hạn, vì không có kiểm tra tải được thực hiện thường xuyên trên máy dàn.
(Tôi đã thấy điều "rollback" đã sử dụng thứ gì đó như 4 hoặc 5 lần trong 3 năm - mỗi lần, nó đã lưu trong ngày - và các trang web ^^)
Đây là một ví dụ nhanh: giả sử tôi có Virtualhost này trong cấu hình Apache của mình:
<VirtualHost *>
ServerName example.com
DocumentRoot /www/application
<Directory /www/application>
# Whatever you might need here (this example is copy-pasted from a test server and test application ^^ )
Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch
AllowOverride All
php_value error_reporting 6135
php_value short_open_tag on
</Directory>
</VirtualHost>Khá "chuẩn" ... Điều duy nhất /www/applicationkhông phải là một thư mục thực sự: nó chỉ là một liên kết tượng trưng đến phiên bản hiện tại của các nguồn.
Điều đó có nghĩa là khi bạn đã đặt các nguồn vào máy chủ, nhưng chưa được chuyển đổi, bạn sẽ có một cái gì đó như thế này:
root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:08 application -> /www/app-2009-09-01Lưu ý rằng symlinc trỏ đến "phiên bản cũ"
Bây giờ, phiên bản mới đã được tải lên hoàn toàn vào máy chủ, hãy chuyển đổi:
root@shark:/www
# rm /www/application
root@shark:/www
# ln -s /www/app-2009-09-08 /www/applicationVà, bây giờ, các /www/applicationđiểm đến phiên bản mới của các nguồn:
root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:09 application -> /www/app-2009-09-08Và chúng ta phải khởi động lại Apache:
root@shark:/www
# /etc/init.d/apache2 restart
* Restarting web server apache2Ba bước " xóa liên kết; tạo liên kết mới; khởi động lại apache " cần được thực hiện nhanh chóng; tức là bởi một kịch bản tự động chứ không phải bởi một con người.
Sử dụng giải pháp này:
Và nếu sử dụng một số opcode-cache như APC với tùy chọn stat ở mức 0, điều đó có thể có nghĩa là thậm chí ít nguy cơ ngừng hoạt động hơn, tôi cho rằng.
Tất nhiên, đây là phiên bản "đơn giản" - ví dụ: nếu bạn có một số tệp được tải lên, bạn sẽ phải sử dụng một liên kết tượng trưng khác ở đâu đó hoặc Virtualhost khác hoặc bất cứ điều gì ...
Hy vọng điều này là rõ ràng hơn :-)
Bạn không thể lấy mã hiện có và di chuyển dự án vào một tệp php thử nghiệm riêng biệt và sử dụng mã đó trong khi bạn đang thực hiện các cập nhật của mình? Ý tôi là, bạn nên có một máy chủ thử nghiệm và một máy chủ sản xuất để khi bạn phải cập nhật, bạn không phải chịu bất kỳ thời gian chết nào.
Thiết lập máy chủ thứ hai với cơ sở mã được cập nhật và chuyển đổi chúng nhanh nhất có thể. :-)
Nếu không thể, hãy đảm bảo rằng cơ sở mã của bạn được chia thành hàng chục phần nhỏ hơn. Sau đó, thời gian chết sẽ được giới hạn chỉ một phụ một tại thời điểm đó. Các codeblocks nhỏ hơn dễ thay thế hơn và hầu hết sẽ tiếp tục chạy mà không gặp vấn đề gì. Tuy nhiên, chỉ cần thử điều này trên một môi trường thử nghiệm!
Trước hết, tôi thường sử dụng và thích một phương thức tương tự như phản hồi của Pascal MARTIN.
Một phương pháp khác mà tôi cũng thích là sử dụng SCM của mình để đẩy mã mới. Quá trình chính xác phụ thuộc vào loại SCM của bạn (git vs svn vs ...). Nếu bạn đang sử dụng svn, tôi muốn tạo một nhánh "trực tuyến" hoặc "sản xuất" mà tôi kiểm tra dưới dạng gốc tài liệu trên máy chủ. Sau đó, bất cứ khi nào tôi muốn đẩy mã mới từ một nhánh / thẻ / trung kế khác, tôi chỉ cần cam kết mã mới vào nhánh "trực tuyến" và chạy cập nhật svn trong thư mục gốc. Điều này cho phép khôi phục rất dễ dàng vì có một bản ghi sửa đổi hoàn chỉnh về những gì đã lên / xuống máy chủ và ai đã làm điều đó và khi nào. Bạn cũng có thể dễ dàng chạy nhánh "trực tuyến" đó trên hộp kiểm tra, cho phép bạn kiểm tra ứng dụng mà bạn sắp đẩy.
Quá trình này tương tự đối với git và các kiểu SCM khác, chỉ cần sửa đổi để tự nhiên hơn cho phong cách làm việc của họ.
Bạn muốn kéo / thăm dò ý kiến thay vì đẩy cập nhật? Chỉ cần có một công việc định kỳ hoặc khác, cơ chế thông minh hơn sẽ tự động chạy cập nhật svn.
Bổ sung: Bạn cũng có thể sử dụng quy trình này để sao lưu các tệp mà ứng dụng của bạn đã ghi vào đĩa. Chỉ cần có một công việc định kỳ hoặc một số cơ chế khác chạy svn commit. Bây giờ các tệp mà ứng dụng của bạn đã tạo được sao lưu trong SCM của bạn, bản sửa đổi được ghi lại, v.v. (ví dụ: nếu người dùng cập nhật tệp trên đĩa, nhưng muốn bạn hoàn nguyên nó, chỉ cần đẩy bản sửa đổi cũ).
Tôi cũng sử dụng một cách tiếp cận tương tự với Pascal MARTIN. Nhưng thay vì tải nhiều phiên bản ứng dụng của tôi lên máy chủ sản xuất, tôi giữ "bản dựng" phía sau tường lửa của mình, mỗi phiên bản trong một thư mục riêng có số ngày và bản dựng. Khi tôi muốn tải lên một phiên bản mới, tôi sử dụng một tập lệnh đơn giản bao gồm "rsync -avh --delay-Updates". Cờ "delay = Updates" sẽ tải mọi thứ (khác nhau) vào một thư mục tạm thời cho đến khi tất cả các bản cập nhật ở đó, và sau đó di chuyển mọi thứ cùng một lúc khi kết thúc chuyển đến đường dẫn thích hợp của chúng để ứng dụng sẽ không bao giờ nằm trong một nhà nước nửa cũ nửa mới. Nó có tác dụng tương tự như phương pháp trên, ngoại trừ tôi chỉ giữ một phiên bản của ứng dụng trên trang sản xuất (tốt nhất chỉ có các tệp thiết yếu duy nhất trên máy chủ sản xuất, IMO).