微軟在前幾天的 Ignite 2021 宣佈推出了 Azure Container Apps，這是一個基於 Kubernetes 的無伺服器容器執行服務，可以更方便我們管理和部署容器服務，快速的玩了一下，把一些基本介紹和使用心得整理一下。
前言
微軟在前幾天的 Ignite 2021 宣佈推出了 Azure Container Apps，這是一個基於 Kubernetes 的無伺服器容器執行服務，可以更方便我們管理和部署容器服務，快速的玩了一下，把一些基本介紹和使用心得整理一下。
說明
簡介
基於 Kubernetes 為基礎的無伺服器服務，介於 Azure Kubernetes Service 和 Azure Container Instance 或 Web App for Container 之間，有著 Kubernetes 叢集的功能，又不像 Kubernetes 需要較有經驗的技術人員來撰寫 Yaml 檔案來部署或是透過指令來管理，可以簡單的透過 Azure Portal 就可以設定部署和擴展執行個體，可以降低開發管理需要熟悉 Kubernetes 管理和運作的管理成本。
部署上可以透過 Azure Container Registry 或是 Docker Hub 和其它私有 Registry 來部署，在自動化擴展上可以透過 HTTP 流量、事件驅動、 CPU 或記憶體和任何 KEDA 支援的 scaler，可以配合各種情境來使用。
也支援使用內建的 DNS 來搜尋同一虛擬網路內的 App 和傳遞訊息和流量，可以將流量鎖定在同一個執行環境內。
另外也提供容器的修訂 (Revisions)，可以有容器設定的版本控管，最多可以保留 100 個，透過不同的容器修訂更可以方便設定流量分流來輕鬆達到 A/B 測試或是藍綠部署。
在監控機制上也支援 Azure Log Analytics ，可以方便的監控和警示服務的狀態。
服務適用於 Api 端點部署、背景排程程式、事件驅動程式和微服務等情境，也完整的支援 Dapr 開源專案 (分散式應用程式執行環境，Distributed Application Runtime)，可以配合來更輕鬆的建立分散式應用程式。
建立
再來簡單說明建立服務流程，在 Azure Portal 上搜尋容器應用程式或 Container Apps，可以找到底下這一個服務，點選建立。
在建立的時候會需要建立一個 Container App environment，它會建立一個執行 App 的 Host 環境，並且設定 Azure Log Analytics 來監控程式。
基本上就設定名稱、資料忠心和選擇 Azure Log Analytics。
因為還在預覽階段，目前僅支援部分資料中心
在 App 的設定上，因為是初體驗，就直接使用範例的 Image 吧！而其它設定也因為是範例，直接設定好。
如果已經有自己的 Image 可以取消勾選 Use QuickStart image 就可以做更詳細的設定了，其中包含了 Image 來源、執行個體的資源 (CPU 和記憶體)、流量輸入設定等。
整個建立的流程相當簡單，需要設定的點也不多，以上步驟就可以快速建立好一個執行容器叢集的環境了。
架構說明
在架構上先有一個執行環境，在上面可以執行多個 Container App，每一個 App 又有自己的修訂，每個修訂類似於 Kubernetes 中的 Pod，裡面再去執行多個容器，在同一個環境內屬於同一個虛擬網路， App 間的資訊傳遞會透過內建的 DNS 來搜尋 App，並且將流量鎖定在同一個虛擬網路內。
在每個 APP 間透過內建的 DNS 可以連到同一環境的 App，而 FQDN 會如下的結構，按照容器應用程式名稱、環境唯一識別碼、資料中心名稱來組成網址。
功能介紹
在概觀可以取得這一個 App 的網址，其它在左邊也提供數個設定的功能。
秘密
可以設定一些秘密 (Secret)，將一些設定資訊儲存於這邊，方便容器執行時候使用，比如說連線字串，不會是直接放在我們打包的 Image 內，就可以透過此功能來設定和存取。
輸入
針對流量的輸入在建立完成之後可以在這邊重新調整設定。
持續部署
當然也支援各種自動化部署的設定，每次觸發部署都會產生新的修訂。
修訂管理
再來就是最重要的修訂管理了，他包含了可以設定每個修訂的流量分配、使用的 CPU 和記憶體、擴展的個數和自動化的條件等。
首先點進來之後可以看到多個修訂，以及設定流量分配和是否使用中。
點進去修訂之後可以在概觀取得特定的修訂執行的網址，組成會和 App 稍微不同，如果有需要連線到特定的修訂來確認功能是否正常就可以使用此網址，不然的話就是從 App 網址讓內建的流量分配自動幫我們將流量倒到正確的位置，另外副本個數就是目前執行的個體個數，因為最低設定為 0，在完全閒置的狀態中就會完全不產生執行個體，也就不會被收費了，針對費用議題會再後面做進一步的討論。
網址結構：https://修訂名稱.環境唯一識別碼.資料中心.azurecontainerapps.io
修訂設定的容器就會呈現目前的容器和設定的 CPU 和記憶體資源等。
調整則是設定的縮放個數和規則。
Dapr 則會呈現目前使用的相關設定，因為我們是用範例，並沒有啟用，所以就沒有更細部的設定了。
而不管是點選建立新修訂或是編輯與部署都會產生一個新的修訂。
而建立的話面就是針對上面提到的三個項目去做設定，就不詳細說明了。
費用
費用上會分做兩個部分，一個是請求一個是使用的資源。請求就比較單純，就是每次 HTTP 請求或是事件的次數，每個月前兩百萬次為免費額度。資源的用量費用就有分 vCPU 和記憶體運算秒數，此外還分閒置和使用中，前面有提到在每個修訂上面有執行個體的數量，如果為 0 的時候則是不收費用，但是如果設定最小值是 1 就要看當下是否有 HTTP 請求，有的話會算成使用中的費用，相反則為閒置中費用。
比較
針對 Azure 上面可以執行容器的服務我比較了一些功能項目，比較表如下，至於費用因為沒辦法有共同的情境來做比較，所以沒有列上去，此外文件上也沒有看到 Container Apps 的 vCPU 的等級為何，如果要和 AKS 比較也比較難選擇到一樣等級的 vCPU 來比較。
叢集我的認定是一個環境可以有多個服務可以同時執行，所以 Azure Container App 就算成可以支援，雖然不像 AKS 或 Virtual Machine 是可以直接設定 Nodes 或 Virtual Machine 個數。
Scale 主要認定也是在於執行個體可以設定數量或是自動擴展。
管理成本 VM 最高是因為包含容器執行環境以及 VM OS 都要自行管理，所以是最高，再來是 AKS ，雖然可以省略掉 VM 的管理，但是整個 AKS Nodes 管理和部署相對其它服務還是來的高一點，所以為中，剩下的因為都可以很方便的透過 Azure Portal 部署和使用，所以管理成本都相對的低。
至於彈性上當然是 VM 最高，想怎麼設定和安裝都可以，ACI 因為就只能單純部署單執行個體也沒太多額外功能可以使用，所以彈性為最低，其餘都有支援各種方式來部署，也可以很方便設定持續整合，所以都列為中。
| 服務 | 叢集 | Scale | 管理成本 | 彈性 |
| Azure Container Apps | 支援 | 可3 | 低 | 中 |
| Azure Kubernetes Service (AKS) | 支援 | 可 | 中 | 中 |
| Azure Container Instance (ACI) | 不支援1 | 否 | 低 | 低 |
| Web App for Container | 不支援 | 可 | 低 | 中 |
| Virtual Machine | 支援2 | 可4 | 高 | 高 |
- 可透過虛擬節點加入到 AKS 叢集內
- 需自行安裝多台 VM 來組合叢集
- 針對的是 App 執行的個體去擴展，不像 AKS 還有 Nodes 的擴展
- 取決於安裝的叢集設定，才會有支援自動擴展
結論
Azure Container Apps 的推出，對於 Azure 在執行容器上又多了一個更好用的服務，比起 AKS 更容易管理，又可以達到 AKS 叢集的效果，部署上也相對容易，而在安全性上又可以把 Apps 放在同一個執行環境，然後讓流量只在虛擬網路間傳遞，使用上它把 Azure 上面其它執行容器的服務優點都涵蓋了，在大部分的情境下應該可以達到不錯的使用效果，本文比較簡略的把服務介紹和說明整理了一下，因為服務比較新，還需要時間去測試和檢驗，歡迎大家一起討論對於這個服務的看法。
