當實例位於ELB后面時，如何設置AWS維護頁面？

Question

當您要在ELB后面部署新版本的應用程序時，如何在AWS中建立維護頁面？ 我們希望在新的自動伸縮實例出現時讓ELB將流量路由到維護實例，並且只有在新實例完全啟動后才“翻轉”到新實例。 我們使用自動縮放功能來關閉現有實例，並關閉具有新代碼的新實例。

我們試圖避免的情況是讓ELB為新EC2實例提供流量，同時為維護頁面提供服務。 由於沒有啟用粘性會話，因此我們希望防止用戶在維護模式頁面和部署在EC2實例中的應用程序之間來回切換。 我們也不能只是擴大規模（例如從2個實例擴展到4個實例，然后又回到2個實例）以引入新實例，因為代碼更改可能涉及數據庫更改，這將破壞舊代碼的更改。

Answer 1

AWS上最簡單的方法是使用Route 53 （其DNS服務）。

您可以使用加權輪循功能。

“您可以使用WRR將服務器投入生產，執行A / B測試，或平衡大小不同的區域或數據中心之間的流量。”

AWS文檔中有關此功能的更多信息

編輯：Route 53最近添加了一項新功能，該功能允許DNS故障轉移到S3。 查看他們的文檔以了解更多詳細信息： http : //docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

Answer 2

我意識到這是一個古老的問題，但是在今天（2018年12月）面臨同樣的問題之后，似乎還有另一種方法可以解決此問題。

今年早些時候，AWS引入了對重定向和對Application Load Balancer的固定響應的支持。 簡而言之：

• 在控制台中找到您的ELB。
• 查看適當的偵聽器的規則。
• 為您的應用程序的主機名添加固定的503響應規則。
• （可選）提供text/plain text/html或text/html響應（即維護頁面HTML）。
• 保存更改。

一旦規則傳播到ELB（對我來說大約30秒），當您嘗試在瀏覽器中訪問主機時，系統將顯示503維護頁面。

部署完成后，只需刪除添加的規則。

Answer 3

Route53不是解決此問題的好方法。 在維護頁面顯示之前，DNS條目過期需要花費大量時間（然后在維護完成之后更新它們也需要花費相同的時間）。 我意識到在問這個問題時不存在Lambda和CodeDeploy觸發器，但是我想讓其他人知道可以使用Lambda為此創建相對干凈的解決方案，我在博客文章中對此進行了詳細介紹： http： //blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html

該解決方案的主要目的是為Lambda函數訂閱CodeDeploy事件，該事件在部署期間用一個在您的負載均衡器中提供靜態頁面的微型實例替換了ASG。

Answer 4

提出了另一個對我們有用的解決方案。 以下是獲得簡單的503 http響應的必需步驟：

1. 復制您的EB環境以創建另一個app-environment-maintenance ，例如，將其稱為app-environment-maintenance 。
2. 更改自動縮放的配置，並將最小和最大服務器都設置為零。 這不會花費您任何EC2服務器，並且環境將變成灰色並位於您的列表中。

3. 最后，您現在可以使用AWS CLI交換環境CNAME，以使您的主環境進入維護模式。 例如：

    aws elasticbeanstalk swap-environment-cnames \\ --profile "$awsProfile" \\ --region "$awsRegion" \\ --output text \\ --source-environment-name app-prod \\ --destination-environment-name app-prod-maintenance 

這會將您的app-prod環境轉換為維護模式。 如下所述，由於沒有任何正在運行的EC2實例，這將導致ELB拋出503，然后Cloudfront可以捕獲503並返回您的自定義503錯誤頁面。

---

使用Cloudfront的自定義錯誤頁面的獎金配置：

我們使用Cloudfront，就像許多人使用HTTPS一樣。Cloudfront包含錯誤頁面。 這是一個要求。

1. 使用錯誤頁面創建一個新的S3網站托管存儲桶。 考慮為響應代碼，503等創建單獨的文件。有關目錄要求和路由，請參閱＃6。
2. 將S3存儲桶添加到Cloudfront分發中。
3. 向您的Cloudfront發行版中為/error/*類的路由添加新行為。
4. 在Cloudfront中設置一個錯誤頁面以處理503響應代碼，並將其指向您的S3存儲桶路由，例如/error/503-error.html

現在，當您的ELB鎖定503時，將顯示您的自定義錯誤頁面。

就是這樣。 我知道有很多步驟可以獲取自定義錯誤頁面，並且我嘗試了很多建議的選項，包括Route53等。但是所有這些都與ELB和Cloudfront的工作方式等存在問題。

請注意，在為環境交換主機名后，傳播大約需要一分鍾左右的時間。

Answer 5

我們的部署過程首先運行cloudformation以啟動ec2微型實例（維護實例），該實例將預定義的靜態頁面從s3復制到ec2。 Cloudformation是隨附有micro ec2實例的elb一起提供的。 然后運行腳本（powershell或cli），以從elb離開的Maintenance實例中刪除Web實例（ec2）。

這樣，我們可以在部署過程中切換到維護實例。

在我們的案例中，我們有兩個彎頭，一個用於外部，另一個用於內部。 在此過程中，我們的內部Elb將不會更新，這是完成產品部署后煙霧測試的方式。 測試完成后，我們運行另一個腳本將Web實例附加到elb上，並刪除維護堆棧。

Answer 6

據我所知，我們處於上述答案不適用或不理想的情況。

我們有一個Rails應用程序，它在Puma上運行Ruby 2.3，並在64位Amazon Linux / 2.9.0上運行，它似乎帶有一個（經典）ELB。

因此，ALB 503處理不是一個選擇。

我們也有各種各樣的硬件客戶端，我永遠不信任DNS TTL，因此Route53很有風險。

看起來不錯的是該平台隨附的Nginx上的輔助端口。

我將其添加為.ebextensions/maintenance.config

files:
  "/etc/nginx/conf.d/maintenance.conf":
    content: |
      server {
        listen 81;
        server_name _ localhost;
        root /var/app/current/public/maintenance;
      }

container_commands:
  restart_nginx:
    command: service nginx restart

並將https://gist.github.com/pitch-gist/2999707的副本拖放到public/maintenance/index.html

現在要進行維護，我只需將我的ELB偵聽器切換到指向端口81而不是默認端口80即可。無需其他實例，s3存儲桶或等待客戶端使用新的DNS。

應用beantalk只需要大約15秒鍾左右的時間（可能主要是在等待后端的雲形成）。