AWS ECS 503服務在部署時暫時不可用

Question

我正在為我的應用程序使用帶有應用程序負載均衡器的Amazon Web Services EC2容器服務。 當我部署新版本時，我得到503服務暫時不可用大約2分鍾。 它比我的應用程序的啟動時間多一點。 這意味着我現在無法進行零停機部署。

是否有設置在啟動時不使用新任務？ 或者我在這里缺少什么？

更新：

ALB的目標組的運行狀況檢查編號如下：

Healthy threshold:     5
Unhealthy threshold:   2
Timeout:               5 seconds
Interval:              30 seconds
Success codes:         200 OK

健康閾值是'在考慮健康的不健康目標之前所需的連續健康檢查成功次數'
不健康的閾值是“在考慮目標不健康之前所需的連續健康檢查失敗次數”。
超時是'沒有響應意味着健康檢查失敗的時間量，以秒為單位。'
間隔是'單個目標的健康檢查之間的大致時間'

更新2：所以，我的集群由兩個EC2實例組成，但如果需要可以擴展。 所需和最小計數為2.我為每個實例運行一個任務，因為我的應用程序需要特定的端口號。 在我部署之前（jenkins運行aws cli腳本）我將實例數設置為4.如果沒有這個，AWS就無法部署我的新任務（這是另一個需要解決的問題）。 網絡模式是橋梁。

Answer 1

因此，問題似乎在於任務定義中容器設置的端口映射。 在我使用80作為主機和8080作為容器端口之前。 我以為我需要使用這些，但主機端口實際上可以是任何值。 如果將其設置為0，則ECS將分配32768-61000范圍內的端口，因此可以將多個任務添加到一個實例。 為了實現這一點，我還需要更改我的安全組，讓流量從ALB流向這些端口上的實例。
因此，當ECS可以在同一個實例上運行多個任務時，50/200最小/最大健康百分比是有意義的，並且可以在不需要添加新實例的情況下部署新任務修訂。 這也確保了零停機時間的部署。

感謝所有提出要求或評論的人！

Answer 2

由於您使用的是AWS ECS，請問服務的“最低健康百分比”和“最高健康百分比”是多少？

確保您的“最大運行狀況百分比”為200，“最低運行狀況百分比”為50，以便在部署期間不會使所有服務都停止運行。

請查看這兩個術語的文檔定義：

最大百分比提供部署期間正在運行的任務數的上限，使您可以定義部署批處理大小。

最低運行百分比在部署期間提供運行任務數量的下限，使您無需使用其他群集容量即可進行部署。

“最小健康百分比”限制為50將確保在部署新版本的容器之前，只有一半的服務容器被殺死，即，如果服務的所需任務值是“2”而不是部署時只有舊版本的“1”容器才會被殺死，一旦部署了新版本，第二個舊容器將被殺死並部署一個新版本容器。 這將確保在任何給定時間都有處理請求的服務。

類似地，“最大健康百分比”的限制為200告訴ecs-agent，在部署期間的給定時間，服務的容器可以達到所需任務的最大值的兩倍。

如有任何進一步的問題，請告訴我。

Answer 3

使用您的設置，應用程序啟動應該花費超過30秒才能使2次健康檢查失敗並被標記為不健康（假設您的應用程序停機后立即進行首次檢查）。 並且至少需要2分鍾到3分鍾才能再次標記為健康狀態（在最佳情況下您的應用程序重新聯機后立即進行首次檢查，或者在最糟糕的情況下，在應用程序恢復之前立即進行首次檢查）。

因此，快速而骯臟的修復是增加不健康的閾值，以便在更新期間不會標記為不健康。 並且可能會降低健康閾值，以便更快地標記為健康。

但是如果你真的想要實現零停機時間，那么你應該使用你的應用程序的多個實例，並告訴AWS按照Manish Joshi的建議進行階段部署（這樣你的ELB背后總會有足夠健康的實例來保持你的網站運行）。

Answer 4

我如何解決這個問題是在應用程序根目錄中有一個平面文件，ALB將監視該文件以保持健康狀態。 在部署之前，腳本將在監視節點時刪除此文件，直到它注冊OutOfService 。

這樣，所有實時連接都會停止並耗盡。 此時，通過停止節點或應用程序進程來啟動部署。 部署之后，通過添加回該平面文件將節點添加回LB，並進行監視，直到它為此節點注冊Inservice ，然后再移動到第二個節點以完成上述相同步驟。

我的腳本如下所示

# Remove Health Check target
echo -e "\nDisabling the ELB Health Check target and waiting for OutOfService\n"
rm -f /home/$USER/$MYAPP/server/public/alive.html

# Loop until the Instance is Out Of Service
while true
do
        RESULT=$(aws elb describe-instance-health --load-balancer-name $ELB --region $REGION --instances $AMAZONID)
        if echo $RESULT | grep -qi OutOfService ; then
                echo "Instance is Deattached"
                break
        fi
        echo -n ". "
        sleep $INTERVAL
done

Answer 5

您正在談論Jenkins ，所以我會回答Jenkins主服務，但我的答案仍然適用於任何其他情況（即使它不是ECS的一個好例子， Jenkins主人不能正確擴展，所以那里可以只有一個實例）。

503糟糕的網關

我經常遇到與負載均衡器失敗的健康檢查相關的503網關錯誤（沒有健康的實例）。 查看負載均衡器監控選項卡 ，確保健康主機的數量始終高於0。

如果您正在進行HTTP運行狀況檢查 ，則只有在服務器正常啟動並運行時，它才必須返回代碼200 （有效代碼列表可在負載均衡器設置中配置）。 否則，負載均衡器可能會處置尚未完全運行的處理實例。

如果問題是你總是得到一個503壞網關 ，可能是因為你的實例需要很長時間才能回答（當服務正在初始化時），因此ECS會將它們視為關閉並在初始化完成之前關閉它們。 Jenkins第一次運行時經常出現這種情況。

為了避免最后一個問題，您可以考慮調整負載均衡器ping目標 （ 經典負載均衡器的 healthcheck目標 ，應用程序負載均衡器的 偵聽 器 ）：

• 使用應用程序負載均衡器 ，嘗試使用始終返回200的內容 （對於Jenkins，它可能是一個公共文件，例如/robots.txt）。
• 使用經典的負載均衡器 ，使用TCP端口測試而不是HTTP測試 。 如果您正確打開了端口，它將始終成功。

每個實例一個節點

如果您需要確保每個實例只有一個節點，則可以使用經典的負載均衡器 （它也可以很好地與ECS配合使用）。 使用經典的負載平衡器 ， ECS可確保每台服務器只運行一個實例。 這也是唯一可以訪問非HTTP端口的解決方案（例如Jenkins需要80，但奴隸也需要50000）。

但是，由於端口不是動態的經典負載均衡器，您必須進行一些端口映射，例如：

myloadbalancer.mydomain.com:80（負載均衡器的端口80） - >實例：8081（容器的外部端口） - > service：80（容器的內部端口）。

當然，每個服務需要一個負載均衡器。

詹金斯健康檢查

如果這是您想要啟動的Jenkins服務，您應該使用Jenkins Metrics插件來獲得良好的健康檢查URL 。

安裝它，並在全局選項中生成一個令牌並激活ping，你應該能夠找到如下所示的URL： http ： //myjenkins.domain.com/metrics/mytoken12b3ad1/ping

只有在服務器完全運行時，此URL才會回答HTTP代碼200 ，這對於負載均衡器僅在完全就緒時才激活它非常重要。

日志

最后，如果您想知道實例發生了什么以及它失敗的原因，您可以添加日志以查看容器在AWS Cloudwatch中的含義 。

只需在任務定義（容器配置）中添加：

日志配置： awslogs
awslogs-group： mycompany （將重新組合容器日志的Cloudwatch密鑰）
awslogs-region： us-east-1 （你的集群區域）
awslogs-stream-prefix： myservice （創建日志名稱的前綴）

它將為您提供有關容器初始化過程中發生的事情的更多信息，如果它只需要太長時間或者它是否失敗。

希望能幫助到你！！！