作為一款重要的容器編排東西，Kubenetes Deployment可以或許為我們帶來(lái)精彩的陳設(shè)本領(lǐng)——但在實(shí)際操縱中，我們?cè)撊绾螌⑵湔现帘旧淼腃odeship事情流傍邊?這個(gè)問題的詳細(xì)謎底取決于您所利用的實(shí)際Kubernetes主機(jī)，而在本日的文章中，我們將選擇Google Cloud作為方針平臺(tái)舉辦探討。

將Codeship與Kubernetes相團(tuán)結(jié)

Codeship自己已經(jīng)在其CI Platform for Docker傍邊內(nèi)置有部門Google Cloud集成機(jī)制，因此我們可以直接在Google Cloud上驗(yàn)證并陳設(shè)新鏡像。

在動(dòng)手舉辦之前，我們還需要操作Codeship的CLI東西建設(shè)一個(gè)加密情況文件，旨在舉辦面向Google Cloud的身份驗(yàn)證。

該情況的變量應(yīng)配置為如下形式：

Google Cloud Key: GOOGLE_AUTH_JSON.

Google Authentication Email: GOOGLE_AUTH_EMAIL.

Google Project ID: GOOGLE_PROJECT_ID.

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

請(qǐng)留意，這里界說(shuō)了兩項(xiàng)處事而非一項(xiàng)。這是因?yàn)槠湟挥糜谕珿oogle Cloud各處事舉辦交互(google_cloud_deployment)，而其二則用于啟用將Docker鏡像推送至Google Cloud Registry(gcr_dockercfg)的成果。

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

谷歌容器注冊(cè)表推送

由于Codeship內(nèi)置有推送機(jī)制，因此我們可以或許輕松將Docker鏡像陳設(shè)在長(zhǎng)途注冊(cè)表內(nèi)。操作前文中界說(shuō)的gcr_dockercfg處事，我們只需要將谷歌容器注冊(cè)表URL作為目標(biāo)地向codeshipsteps.yml文件中添加即可。

重要的是，由于我們需要陳設(shè)本身的應(yīng)用鏡像，所以請(qǐng)務(wù)必確保將應(yīng)用處事名稱替換為您本身但愿運(yùn)行的應(yīng)用處事名稱。

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

固然此步調(diào)可以或許將更新鏡像推送至注冊(cè)表，但當(dāng)前界說(shuō)仍然存在問題。由于未配置Docker鏡像標(biāo)簽，因此Codeship將把更新鏡像推送至latest標(biāo)簽。盡量就今朝來(lái)看這并不會(huì)造成什么貧苦，但為了觸發(fā)Kubernetes Deployment的自動(dòng)更新機(jī)制，我們還需要為各個(gè)推送配置差異標(biāo)簽。

為了實(shí)現(xiàn)這一點(diǎn)，Codeship提供一條image_tag聲明，答允我們?yōu)樾枰扑偷溺R像配置除latest以外的任何標(biāo)簽。出于簡(jiǎn)樸起見，這里我們直接利用Unix時(shí)間戳以擔(dān)保其惟一性與可反復(fù)性。

利用新的image_tag聲明，此前步調(diào)將如下所示：