2021ironman 13th – DevOps – Day04 – Amazon ECS Anywhere 基礎說明與建置(下)

分享

先前將主機已經註冊上去了
那接下來就是進到『Task Definitions』開始來建立服務
點選『Create new Task Definition』

因為我們是要建立ECS Anywhere
點選『EXTERNAL』再來 Next Step

Task definition name 輸入服務名稱,我這邊只是先建立一個apache測試環境所以名稱直接用『apache』
Network mode 記得保持預設

輸入這個Task所需的記憶體及CPU數量
記憶體單位是M
CPU1024是代表1 vCPU

建立容器『Add container』

Container name 輸入名稱
Image 這邊看要抓取的 Image 位置及版本,我這個寫法因為沒有URL 所以會直接跟docker Hub拉
Port mappings 這個數值很重要 是外部要跟Container要對應的Port,看您包的Container是需要哪個Port就使用那個Port

點選『Create』進行建立

Task建立完成

Task 只是服務的樣態或者說是模組
建立完Task 就可以利用它來建立Service
進到Service分頁 並點選『Create』

Launch type 選擇 ECS anywhere 用的 EXTERNAL
Task Definition 選擇 Task並選擇版本
Service name 填寫這個服務的名稱

Number of tasks 因為目前只有註冊一台 所以選1

再來就點選『Next step』到下一分頁

這邊測試環境可以直接跳過直接點選『Next step』

只有一台暫時不需要擴展所以『Next step』

最後確認並點選『Create Service』建立服務

服務建立成功

回到Local主機上確認該主機IP

網頁測試

也可以在Local使用Docker指令確認運行狀態

Read more

雲端架構延遲問題:為什麼AP與DB不能放太遠?

雲端與地端的架構差異認知不足導致的性能陷阱 前言 許多企業在上雲初期,經常基於成本考量或錯誤認知,將應用程式伺服器(AP)與資料庫(DB)部署在不同區域。這種做法在地端環境中影響較小,但在雲端環境中卻會造成嚴重的性能問題。本文透過台北-東京的實際案例,說明距離對雲端架構的致命影響。 核心問題: * 地端思維:同個機房內不同區域延遲可忽略 * 雲端現實:跨區域延遲可達數十毫秒 * 結果:連線建立時間從毫秒級暴增到秒級 1. 地端 vs 雲端的延遲差異 1.1 地端環境的延遲特性 傳統地端機房: 同機房不同機櫃:RTT < 1ms 同城市不同機房:RTT < 5ms 同國家不同城市:RTT < 20ms 地端架構師的經驗: * AP和DB分別放在不同機櫃:幾乎無延遲影響 * 災備機房放在不同城市:RTT約10-15ms,可接受 * 習慣性認為「網路延遲不是問題」

By Albert Yu