作为一款重要的容器编排工具，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声明，此前步骤将如下所示：

现在当我们将应用镜像推送至谷歌容器注册表时，系统即会使用当前版本的Unix时间戳作为其标签。

原文标题：Continuous Deployment of Docker Apps to Kubernetes