作為一款重要的容器編排東西，Kubenetes Deployment可以或許為我們帶來精彩的陳設本領——但在實際操縱中，我們該如何將其整合至本身的Codeship事情流傍邊?這個問題的詳細謎底取決于您所利用的實際Kubernetes主機，而在本日的文章中，我們將選擇Google Cloud作為方針平臺舉辦探討。

將Codeship與Kubernetes相團結

Codeship自己已經在其CI Platform for Docker傍邊內置有部門Google Cloud集成機制，因此我們可以直接在Google Cloud上驗證并陳設新鏡像。

在動手舉辦之前，我們還需要操作Codeship的CLI東西建設一個加密情況文件，旨在舉辦面向Google Cloud的身份驗證。

該情況的變量應配置為如下形式：

Google Cloud Key: GOOGLE_AUTH_JSON.

Google Authentication Email: GOOGLE_AUTH_EMAIL.

Google Project ID: GOOGLE_PROJECT_ID.

在完成了加密情況文件的建設并將Google Cloud情況變量生存至gc.env.encrypted后，接下來我們需要在codeship-services.yml文件內界說Google Cloud處事。

請留意，這里界說了兩項處事而非一項。這是因為其一用于同Google Cloud各處事舉辦交互(google_cloud_deployment)，而其二則用于啟用將Docker鏡像推送至Google Cloud Registry(gcr_dockercfg)的成果。

然而到這里問題只辦理了一半。固然其已經建設了與Google Cloud互換所需要的處事，但并不能自動陳設新構建的鏡像可能更新Kubernetes Deployment。

谷歌容器注冊表推送

由于Codeship內置有推送機制，因此我們可以或許輕松將Docker鏡像陳設在長途注冊表內。操作前文中界說的gcr_dockercfg處事，我們只需要將谷歌容器注冊表URL作為目標地向codeshipsteps.yml文件中添加即可。

重要的是，由于我們需要陳設本身的應用鏡像，所以請務必確保將應用處事名稱替換為您本身但愿運行的應用處事名稱。

以上參數已經很是清晰，相信不必過多表明，其根基思路是操作之前界說的gcr_dockercfg處事舉辦身份驗證，東京主機 日本代理服務器，并將應用鏡像推送至谷歌容器注冊表傍邊。

固然此步調可以或許將更新鏡像推送至注冊表，但當前界說仍然存在問題。由于未配置Docker鏡像標簽，因此Codeship將把更新鏡像推送至latest標簽。盡量就今朝來看這并不會造成什么貧苦，但為了觸發Kubernetes Deployment的自動更新機制，我們還需要為各個推送配置差異標簽。

為了實現這一點，Codeship提供一條image_tag聲明，答允我們為需要推送的鏡像配置除latest以外的任何標簽。出于簡樸起見，這里我們直接利用Unix時間戳以擔保其惟一性與可反復性。

利用新的image_tag聲明，此前步調將如下所示：