本文讲的是Kubernetes持续部署Docker Apps【编者的话】本文是Codeship系列文章（Continuous Deployment for Docker Apps to Kubernetes）的第二篇，介绍了Codeship的相关配置项。如果已经等不及了，你可以下载电子书《 》

这一系列文章中，我们介绍过了 。本篇我们开始集成Codeship到工作流中。

假设已经有了Kubernetes的Deployment（注意我们上篇文章中已经讨论了“Deployment”和Kubernetes中“Deployment”这两个概念的区别），现在我们该如何集成到我们自己的Codeship工作流中呢？最终答案取决于Kubernetes的部署模式，因为Kubernetes官方文档使用Google Cloud作为案例，我也会使用这个部署模式。

集成Codeship到Kubernetes

Codeship开发了相关 功能集成到他们的CI平台，方便用户认证与部署新的image到Google Cloud。

但是，在开始前，我们要使用Codeship CLI工具创建加密的环境文件，帮助我们更方便地认证到Google Cloud。 关于怎么创建环境文件，所以这里不会详细介绍。但是牢记要设置以下环境变量：

• a Google Cloud Key - GOOGLE_AUTH_JSON
• a Google Authentication Email – GOOGLE_AUTH_EMAIL
• a Google Project ID – GOOGLE_PROJECT_ID

一旦加密环境文件准备好（并且保存环境变量到 gc.env.encrypted ），下一步我们要在 codeship-services.yml 中定义Google Cloud服务。

注意需要定义两个服务，而不是一个。这是因为一个服务负责与Google Cloud交互（ google_cloud_deployment ），另一个服务负责
push Docker image到Google Cloud Registry（ gcr_dockercfg ）。我们已经 。

到这里我们已经解决了一半的难题。虽然它创建了必要的服务与Google Cloud交互，它却不能自动地部署新构建的image或者更新一个Kubernetes Deployment。

Push到Google Container Registry

感谢Codeship ，使得部署Docker image到远程的registry非常的平滑。使用 gcr_dockercfg 服务实现上面的功能，我们需要做的就是在 codeshipsteps.yml 添加Google Container Registry的URL作为目的地址。

下面非常重要，因为我们要部署应用镜像了，注意把下面的服务名替换成你自己的。

上面的参数名很好地说明它们的含义，它的基本思想是app image会被push到Google Container Registry，使用之前定义好的 gcr_dockercfg 服务实现认证。

虽然这里更新的image被push到registry，但是会有一个问题。我们没有定义image的tag，Codeship默认tag为 latest 。本身而言这还不是件糟糕的事，但是为了触发Kubernetes Deployment自动更新，我们要为每次push的image设置不同的tag。

Codeship提供了 image_tag 参数声明image的tag， 来帮助我们声明image的参数；但是，为了简化，我们使用当下的Unix时间戳，因为它是独一无二的，无法替代。

有了 image_tag ，之前的配置就变成下面这样了：

现在，当我们push app image到Google Container Registry时，image的tag会被标记为当下的Unix时间戳。

本篇文章到这里告一段落，记得检查新的教程。

原文连接：（翻译：adolphlwq）

=========================================
译者介绍

，博客地址：

原文发布时间为：2017-01-14

本文作者：

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Kubernetes持续部署Docker Apps