26

我對Elastic Beanstalk的理解是,當您部署應用程序的新版本時,它將一次一個地部署到Amazon EC2實例(如果您有多個)。但是,即使至少有兩個實例,我的應用程序在部署時會上傳一個新的.war,這會導致很短的停機時間,就好像它正在同時更新它們一樣。有沒有一種方法可以確保沒有停機時間,並且一個實例在下次啓動之前完全更新並接受請求:以下是事件的外觀。請注意,此應用程序的負載爲零,因此只會隨着生產流量而變差。如何防止AWS Elastic Beanstalk部署新版本應用程序期間的宕機?

INFO 
Environment update completed successfully. 

INFO 
New application version was deployed to running EC2 instances. 

ERROR 
The application did not respond at the health check URL. 

INFO 
Waiting for 8 seconds while EC2 instances download the updated application version. 

INFO 
Deploying version SomethingMore to 2 instance(s). 

回答

19

Elastic Beanstalk實現這一目標,就需要擴大部署程序,以方便多個環境(見AWS Elastic Beanstalk Components):

的環境是部署到AWS版本資源。每個 環境只運行單個版本,但是可以在同一時間在許多環境中運行相同的 版本或不同版本。 [...]對於 有關創建的環境和資源的更多信息,請參閱Architectural Overview[重點礦山]

此功能可用於測試/調試有用單獨版本已經,但具體這使得環境的熱交換,以及,見Deploying Versions With Zero Downtime用於相應演練:

由於AWS當您更新您的應用程序版本時,Elastic Beanstalk將執行就地更新,您將遇到一些停機時間。 但是,可以通過爲您的環境替換CNAME 來避免此宕機。本節將引導您完成如何使用AWS管理控制檯,命令行 界面或API執行 CNAME交換。 [重點煤礦]

+0

謝謝,環境CNAME交換正是我正在尋找的。 – Peter 2012-07-17 23:09:18

+6

我在我的製作應用中試過了這個,並觀察到即使在交換CNAME並等待DNS TTL過期後,相當大一部分流量仍然會進入舊的豆稈環境。我懷疑這是因爲客戶端持有的DNS緩存比他們應該更長。如果不能依賴客戶端服從TTL,那麼這種CNAME交換技術似乎不是用Beanstalk進行ZDD部署的可靠方法。 – 2014-01-18 22:30:59

+0

@AaronIba這是一個非常好的觀察。你有沒有想出一些替代方法?我正在考慮簡單地覆蓋現有的應用程序版本並手動關閉現有的實例(ASG應該增加新的應用程序版本並提取更新的應用程序版本)。但這是手動/慢/繁瑣的過程,感覺像一個黑客。 – 2014-08-28 15:29:35

6

我知道這是一個老問題,但對谷歌搜索的人(比如我),彈性魔豆今日(2014年11月2日),滾動應用程序版本的部署。

http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html?sc_ichannel=em&sc_icountry=global&sc_icampaigntype=launch&sc_icampaign=em_125873140&sc_idetail=em_14124901705&ref_=pe_411040_125873140_8

這允許您更新船隊在您的新應用程序的一部分,以確保總有主機可供採取交通。

+0

這是否只適用如果您在負載均衡器後面運行多個實例?從它的描述來看,似乎單個實例仍然會下降。 – 2014-12-12 23:42:58

+1

是的,您需要Elastic Beanstalk環境中的多個實例來避免停機。儘管這是真的,如果您從一臺主機提供流量,並且更新了主機(即使它已就位),則可能會導致一些停機。 – zongweil 2014-12-13 00:10:07

+0

以上陳述根本不屬實。我使用nginx在單個主機上部署了零宕機時間。 (不在彈性beanstalk上。) – 2014-12-13 00:23:31

相關問題