對於在ALB後面的AWS ECS上運行的asp.net核心網站，Kestrel足夠了嗎？

我準備將ASP.NET Core MVC網站部署到生產環境。該應用程序將部署到AWS ECS（EC2容器服務）。建議不要將紅隼用於從互聯網提供流量，建議在前面放置一個反向代理服務器。我的問題是，AWS ALB夠好嗎？它執行SSL終止，負載均衡，並支持HTTP/2和WebSocket。對於在ALB後面的AWS ECS上運行的asp.net核心網站，Kestrel足夠了嗎？

我相信我放棄了壓縮（據我所知ALB或Kestrel都不支持它）。此設置缺少什麼？我應該看看額外的反向代理（haproxy/nginx）嗎？如果我不需要，那麼額外的複雜性就足夠了，我不想走這條路。

來源

2017-03-03 Erick T

你需要考慮一下這個解決方案，你將如何管理紅隼進程。推薦的Windows解決方案（在IIS後面運行）通過IIS核心模塊執行此操作。它在第一次請求時啓動kestrel並在其失敗時重新啓動 – Tom

在ECS的情況下，ALB/ECS負責啓動足夠的實例。 –

啊，好的，我錯過了集裝箱服務部分，我沒有用過。聽起來像這樣可以正常工作。我只是從ELB切換到NGINX，因爲我們需要對負載平衡進行更好的控制，但如果您的需求是基本的，ELB可以正常工作。 – Tom

如果你不需要壓縮（它有小的搜索引擎優勢），你很好去。

有幾件事情要注意你的紅隼的應用程序，我確定大家都知道放置時，它後面的referse代理：

請求URL的概念消失了：因爲代理轉發請求請求url始終是代理本身。
此外協議將永遠是http而不是https。
負載平衡器每次都在應用程序之間切換，所以現在可能會出現性能下降的情況（無法正常工作，但您沒有意識到）現在可能會崩潰。

ALB我可以想像的缺點可能是您無法控制負載均衡如何發生。如果這對你來說不是問題，那麼我認爲幾乎任何反向代理都適合你。（如果你喜歡，你甚至可以在nodejs中創建一個簡單的反向代理）。

來源

2017-03-03 06:19:12

謝謝。雖然壓縮很好，但它肯定不是一個硬性要求。我現在使用haproxy（用於本地IIS），而且它確實需要一些習慣。至於最後一點，在某些方面這是一個好處 - 如果您的網站是有狀態的，最好早點知道，而不是晚點。 –

對於在ALB後面的AWS ECS上運行的asp.net核心網站，Kestrel足夠了嗎？

回答

相關問題