容器部署前有以下幾種方式來指向Registry API
後建立映像檔
Container Registry的進化版
,可讓貴機構集中管理容器映像檔和語言套件如:Maven和Npm)
。Artifact Registry與Google Cloud的工具和執行階段完全整合,並支援原生構件通訊協定,因此您可以輕鬆將其與持續整合/持續推送軟體更新工具相互整合,進而設定自動化管道。
想試試通往此隧道Artifact Registry
Artifact已啟用
設計、開發並安全地管理程式碼,還能在功能完善且
可擴充的私人Git存放區輕鬆協作
。此外也能連線至Cloud Build、App Engine和Pub/Sub等其他Google Cloud工具,以及Cloud Monitoring、Cloud Logging等作業套件產品,以擴展Git工作流程
。
想試試通往此隧道Cloud Source Repositories
Cloud Source Repositories已啟用
透過Cloud Build工具來持續建立,測試及部署,就像是Jenkins
,重點是整合Google GKE自家服務,從映像打包到部署只需有極短秒級到分鐘的時間就可以完成任務,非常高效。
Cloud Build以啟用
GKE支援的應用程式部署格式為Docker
,初次見面來點輕鬆的,以下透過精靈的方式快速體驗在容器叢集環境非常輕易的部署Nginx網頁應用服務
初始我們就透過現有的Nginx容器來作部署示範,如果在上述的Registry或是他也有支援第三方的映像倉庫也可以做指定。環境變數再依據個人需求來做調整,此範例預設值保持空白即可
可以自訂我們的應用程式名稱,另外預設佈建出來的叢集NameSpace就叫Default
,標籤可以再做增訂
K8s部署要能順利全靠YAML描述檔
的輸入,這已經是系統貼心的範本可以直接套用,而實際上此檔內容可以大大的學問,可以自行Copy出來做進一步深入的研究或是拿來重新編修成適合自己的再部署到您自己的環境試試
最後到了部署落地階段,因為我只有一組叢集故沒有選擇權,相信未來的生產環境需求一定只會更為豐富,叢集與地理區域就自行選擇部署的位置,選擇完成就部署即可
建立部署作業階段進行中
部署完畢其實真的時間只有短短幾分鐘,如果開始有負載執行此監視畫面就可以看到變化
詳細資訊也更清楚檢視此容器被安置的叢集環境的狀態,時間與相關資源等..不過部署出來的服務還是需要出來露面的才有意義,右上角有公開就是它
有沒有跟我們前幾篇常用的-P 80:80
這樣的指令很類似,Port對外暴露的連接埠
,目標連接埠則是Pod本身,沒有特別設置因為預設網站走80
,最後是通訊協定如果UDP就自行決定
。服務類型當然是要嘗試負載平衡以及對應的服務名,沒有問題就點選公開
建立負載平衡服務以及對外綁定的Public IP
有建立服務以及公開服務則就會在此頁籤看到其狀態已經是OK,幾個Pod並放置在哪個叢集內
,但最重要的一環就是已經產生的端點IP
,實際來測試一下Nginx是否真的有輸出提供網頁服務
測試無誤,這次的簡易上手部署成功,也算是給需要沒有接觸過的朋友們一點信心包含我自己