推送到負載均衡器上的多個EC2實例

我正在嘗試找出一種將新提交推送到ELB（負載均衡器）後面的一組EC2服務器實例的好方法。每個實例都運行Nginx和PHP-FPM推送到負載均衡器上的多個EC2實例

我想執行下面的工作流程，但我不確定是否推出新版本給負載均衡器後面的所有實例的好方法。

開發是本地計算機上完成
一旦改變準備好了，我執行「混帳推起源大師」推的更改到位桶（其中我主持我所有的git回購）
後被推送到bitbucket，我希望新版本同時推送到所有EC2實例。
我想這樣做，而不必SSH登錄到每個實例（顯然）。

有沒有辦法配置遠程服務器接受遠程推送？有一個更好的方法嗎？

2012-12-13 Jonathan Coe

我是正確的假設你有擴大/縮小腳本活動？ – thatidiotguy

目前不是。目前，我真的只是使用負載均衡器進行故障轉移保護，並簡化了https配置。在未來，我想介紹自動縮放到系統，但目前它不是一個主要要求。 –

我問，因爲在您的服務器達到預定的壓力水平時，通過向上/向下縮放指定要加載哪個AMI。假設你制定了規則，總是有三臺服務器。如果您更改腳本以從新的AMI（包含您的新代碼的實例）啓動實例，則可以逐個刪除舊機器，並且新機器會提出新代碼。這是一個簡單的示例，說明如何在生產環境中向上/向下擴展您的服務器的新版本。 – thatidiotguy

選擇一個

將其推到一臺機器。
在它上面創建了一個git鉤子http://git-scm.com/book/en/Customizing-Git-Git-Hooks。
使鉤子在其他機器上運行。

唯一的問題，你必須保持機器列表運行更新。

另一個選項

有cron作業從您的帳戶到位桶拉。定期進行。

來源

2012-12-13 21:43:33

最好的辦法可能是實際使用AMI進行部署。

就我個人而言，我通常有一個暫存實例，可以將任何回購更改拖入。一旦我確認它以我想要的方式運行，我將從該實例創建一個AMI。

對於部署，我使用負載均衡器後面的自動調整組（不需要動態調整或任何其他）。在一個簡單的設置中，您在自動縮放組中具有固定數量的服務器（例如10個實例）。我會將與自動縮放組相關的AMI更改爲新的AMI，然後在自動縮放組中一次開始終止一些實例。所以，假設我有10個實例，並且我終止了兩個實例，將其減少到8個實例。自動調節組配置爲至少有10個實例，因此它將自動啓動兩個新的AMI實例。然後，您可以繼續以任何有效的負載級別移除實例，以免影響您的車隊性能。

很明顯，您可以手動執行此操作，即使沒有自動縮放組，也可以直接從ELB添加/刪除實例。

如果您希望完全自動化（例如，持續部署），那麼您可能想要使用諸如Jenkins這樣的構建系統，這將允許提交啓動構建，然後運行必要的AWS命令來製作AMI並進行部署。

來源

2012-12-14 16:52:11

這並不是真正的推薦方式，因爲即使是輕微的代碼更改也需要創建新的AMI。變更管理變得有點噩夢。建議的策略是使用基本AMI，然後使用「用戶數據」字段來引導配置過程。 – jamieb

@jamieb我想這實際上取決於您的部署方法以及您希望在引導過程中花費的時間。如果您經常部署更改，我會同意如果您手動執行所有操作（即不使用構建系統自動執行），此過程會變得有點麻煩。但是，如果您部署更頻繁，比手動執行此方法的時間並不多。 –

@jamieb現在，如果您有一個需要一段時間才能部署的大型代碼庫，這樣您的服務器才能運行，或者您在引導過程中對訂單有很大的依賴性，以至於您的cloudinit（或類似）腳本變得過於複雜或脆弱的，那麼部署一個準備好的AMI可能對你更有意義。在升級事件過程中，這可能也更重要，根據您的流量配置文件，實時響應ELB運行狀況檢查所需的時間可能很重要。 –

是的，我一直這樣做（實際上使用相同的應用程序堆棧）。

使用來自受信任來源（例如默認「Amazon Linux」）的基本AMI，或者展開自己的AMI。
作爲啓動配置的一部分，使用「用戶數據」字段在啓動時引導配置進程。這可以像運行yum install nginx php-fpm -y的shell腳本一樣簡單，並從S3存儲桶中複製文件，或者從您的存儲庫中執行操作。如果您需要更多靈活性，亞馬遜編寫的AMI還包含對cloud-init腳本的支持。如果您需要更強大的功能，您可以使用變更管理和協調工具，如Puppet,Chef或Salt（我個人最喜歡的）。
至於更新現有實例代碼：有兩個思想流派：
- 充分利用雲的，只是旋轉起來，在啓動抓取新的代碼實例的一個全新的艦隊。然後你翻轉負載平衡器指向新的機隊。這是瞬時的，如果出現問題，可以讓您快速恢復舊機隊。幾小時（或幾天）之後，您可以減少舊的實例。
- 您可以使用類似Fabric或Capistrano的工具對所有實例同時執行並行「推送」部署。這通常只是重新執行服務器在啓動時運行的相同腳本。 Salt和Puppet的MCollective也提供了類似的功能，可以與其基本的「拉」配置進行網格劃分。

來源

2012-12-14 21:10:08 jamieb

你能否詳細說明車隊的部分？我是一個新手。這是否意味着子網？或者你的意思是，記錄新的服務器，註銷舊的實例並註冊新的實例？ – MavWolverine

此工作的工具是Capistrano。

我使用名爲capistrano-ec2group的真棒寶石來將Capistrano角色映射到EC2安全組。

這意味着您只需要將EC2安全組（例如.app-web或app-db）應用於您的實例，以便capistrano知道要部署給他們的內容。

這意味着您不必在應用程序中維護服務器IP列表。

到您的工作流程的變化將是，而不是側重於對力推到位桶自動化部署，你會推後執行

cap deploy

如果你真的不想做的步驟，使別名：D

alias shipit=git push origin master && cap deploy

來源

2013-03-05 01:01:30

該解決方案建立在E_p的構思上。 E_p說，問題在於你需要在某個地方維護一個服務器列表，以便告訴每個服務器提供新的更新。如果是我，我只需在ec2中使用標籤來幫助識別一組服務器（例如「Role = WebServer」）。這樣，您可以使用ec2命令行界面列出實例，並在每個實例上運行pull命令。

for i in \ 
    `ec2din --filter "tag-value=WebServer" --region us-east-1 \ 
    | grep "running" \ 
    | cut -f17`\ 
; do ssh $i "cd /var/www/html && git pull origin"; done

注：我已經測試了獲取所有標記的情況下的IP地址，並通過ssh連接到它們的代碼，而不是具體的git pull命令。

您需要將amazon cli工具安裝在您希望運行的任何位置，以及爲嘗試更新的服務器安裝的ssh密鑰。不確定什麼bitbucket的功能，但我猜這個代碼將無法在那裏運行。您需要按照E_p的建議進行操作，並將更新推送到單獨的管理實例，並在您的後提交鉤子中包含此代碼，或，如果您想要保存我可以完成的頭痛問題並且只需在本地計算機上安裝CLI工具，並在您想部署更新時手動運行它。

感謝AdamK他爲這使得它容易從ec2din輸出提取IP地址和迭代結果的另一問題的回答：How can I kill all my EC2 instances from the command line?

EC2 CLI工具參考：http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/Welcome.html

來源

2014-01-10 05:37:50

聽起來像個好主意 - 這些命令還在起作用嗎？我還沒有使用cli工具，並希望確保它不是我造成的問題;-) –

是的，應該仍然工作正常。 aws文檔仍然引用「ec2-describe-instances」命令（ec2din是簡短版本）。 http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-DescribeInstances.html。如果您在使用上述命令時遇到問題，請嘗試將其分解爲其組成部分並查看問題所在。它的可能ec2din輸出已經稍微改變，所以「cut -f17」可能不得不改變爲別的東西來提取IP地址列。 –

實際上，在運行一些測試之後，出於某種原因，現在我必須在運行ec2din函數時指定區域。我已經更新了上面的例子。 –

推送到負載均衡器上的多個EC2實例

回答

相關問題