作為一款重要的容器編排工具，Kubenetes Deployment能夠?yàn)槲覀儙?lái)出色的部署能力——但在實(shí)際操作中，我們?cè)撊绾螌⑵湔现磷约旱腃odeship工作流當(dāng)中?這個(gè)問(wèn)題的具體答案取決于您所使用的實(shí)際Kubernetes主機(jī)，而在今天的文章中，我們將選擇Google Cloud作為目標(biāo)平臺(tái)進(jìn)行探討。

將Codeship與Kubernetes相結(jié)合

Codeship本身已經(jīng)在其CI Platform for Docker當(dāng)中內(nèi)置有部分Google Cloud集成機(jī)制，因此我們可以直接在Google Cloud上驗(yàn)證并部署新鏡像。

在動(dòng)手進(jìn)行之前，我們還需要利用Codeship的CLI工具創(chuàng)建一個(gè)加密環(huán)境文件，旨在進(jìn)行面向Google Cloud的身份驗(yàn)證。

該環(huán)境的變量應(yīng)設(shè)置為如下形式：

Google Cloud Key: GOOGLE_AUTH_JSON.

Google Authentication Email: GOOGLE_AUTH_EMAIL.

Google Project ID: GOOGLE_PROJECT_ID.

在完成了加密環(huán)境文件的創(chuàng)建并將Google Cloud環(huán)境變量保存至gc.env.encrypted后，接下來(lái)我們需要在codeship-services.yml文件內(nèi)定義Google Cloud服務(wù)。

請(qǐng)注意，這里定義了兩項(xiàng)服務(wù)而非一項(xiàng)。這是因?yàn)槠湟挥糜谕珿oogle Cloud各服務(wù)進(jìn)行交互(google_cloud_deployment)，而其二則用于啟用將Docker鏡像推送至Google Cloud Registry(gcr_dockercfg)的功能。

然而到這里問(wèn)題只解決了一半。雖然其已經(jīng)創(chuàng)建了與Google Cloud交換所需要的服務(wù)，但并不能自動(dòng)部署新構(gòu)建的鏡像或者更新Kubernetes Deployment。

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

由于Codeship內(nèi)置有推送機(jī)制，因此我們能夠輕松將Docker鏡像部署在遠(yuǎn)程注冊(cè)表內(nèi)。利用前文中定義的gcr_dockercfg服務(wù)，我們只需要將谷歌容器注冊(cè)表URL作為目的地向codeshipsteps.yml文件中添加即可。

重要的是，由于我們需要部署自己的應(yīng)用鏡像，所以請(qǐng)務(wù)必確保將應(yīng)用服務(wù)名稱替換為您自己希望運(yùn)行的應(yīng)用服務(wù)名稱。

以上參數(shù)已經(jīng)非常清晰，相信不必過(guò)多解釋，其基本思路是利用之前定義的gcr_dockercfg服務(wù)進(jìn)行身份驗(yàn)證，并將應(yīng)用鏡像推送至谷歌容器注冊(cè)表當(dāng)中。

雖然此步驟能夠?qū)⒏络R像推送至注冊(cè)表，但當(dāng)前定義仍然存在問(wèn)題。由于未設(shè)置Docker鏡像標(biāo)簽，因此Codeship將把更新鏡像推送至latest標(biāo)簽。盡管就目前來(lái)看這并不會(huì)造成什么麻煩，但為了觸發(fā)Kubernetes Deployment的自動(dòng)更新機(jī)制，我們還需要為各個(gè)推送設(shè)置不同標(biāo)簽。

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

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

現(xiàn)在當(dāng)我們將應(yīng)用鏡像推送至谷歌容器注冊(cè)表時(shí)，系統(tǒng)即會(huì)使用當(dāng)前版本的Unix時(shí)間戳作為其標(biāo)簽。

原文標(biāo)題：Continuous Deployment of Docker Apps to Kubernetes