正確的方式來更新服務器上的文件，無需停機

我認爲這個方法來更新服務器的文件，而無需停機時間：正確的方式來更新服務器上的文件，無需停機

上傳新文件，新文件夾，例如to/www/v1/
在httpd.conf中，將DocumentRoot更新爲指向新文件夾
重新啓動apache。

這是否有任何缺點？有沒有更好的辦法？

當文件在重新啓動的正確時刻被訪問時，是否會出現任何競態條件錯誤？

來源

2015-11-20 Code

最好的辦法是通過GIT管理你的代碼。然後你可以這樣做：git pull（PS：你可能會在apache重新啓動時發生宕機） – KiwiJuicer

它立即更新服務器上的文件 – KiwiJuicer

你是不對的。如果git服務器位於遠程服務器上呢？ :) – vitozev

最好的解決方案是爲服務器的高可用性設置負載平衡器（例如HAProxy）。

否則，你將永遠有停機時間。想想以下情況：resetarting了Apache，數據庫更新，資產更新，更新過程中的意外錯誤等

來源

2015-11-20 09:42:08 vitozev

有將總是工作沒有單一的辦法 - 即使你準備和部署新的服務器，然後改變負載平衡器指向新機器。有人可能剛從原始服務器請求了一個頁面，然後在新機器上從該站點的新副本中獲取部分頁面。然而在實踐中這不太可能引起大問題。

在大型網站上，如果需求複雜，事情會變得更加困難 - 並且需要付出代價。大多數網站有更簡單的要求。即使是數據庫遷移計劃也可能會造成最小的中斷 - 但也會很複雜，必須按計劃的停機時間解決。由於在同一臺機器（或少數機器）上的站點副本之間的切換很容易（有效地移動Apache或Nginx DocumentRoot）一種易於使用的技術（並且不需要多臺機器和一臺機器負載均衡器實現）是這樣的：

雖然該網站仍然在磁盤上的當前位置運行愉快...
檢查出來，在一個新的目錄編制工廠的一個完全獨立的副本
運行任何所需的composer install或資產提取/準備需要
更改舊網站和新網站之間的符號鏈接。

實際上，這是Capistrano（和其他類似的工具）所做的。該基目錄佈局是這樣的：

base-directory 
    releases 
     20151010-0925/ 
      vendor/ (composer-installed files) 
      web/index.php 
     20151120-1007/ 
      vendor/ (composer-installed files) 
      web/index.php 
    current (symlink to ../releases/20151010-0925/) 
    shared/ (files shared between releases)

在部署該網站的新版本 - 創建一個新的完全釋放形成的，然後它完成時，改變「電流」符號鏈接。

在這個實例中的Apache文檔根將指向.../base/current/web/去到符號鏈接到網站的基地。

如果在任何時候部署失敗，您可以簡單地中止它，並可以選擇刪除您嘗試部署的發佈版本，而不是更改符號鏈接。

我已經將這種技術從簡單的單頁面HTML/CSS網站用於運行數千個併發用戶的三機羣集。

來源

2015-11-20 10:24:12

正確的方式來更新服務器上的文件，無需停機

回答

相關問題