LOADING

Follow me

Kubernetes持续部署Docker Apps【zoues.com】
一月 31, 2017|DockerPaaS

Kubernetes持续部署Docker Apps【zoues.com】

Kubernetes持续部署Docker Apps【zoues.com】

Kubernetes持续部署Docker Apps

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

集成Codeship到Kubernetes

Kubernetes持续部署Docker Apps

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

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

  • 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服务。

Kubernetes持续部署Docker Apps

注意需要定义两个服务,而不是一个。这是因为一个服务负责与Google Cloud交互(google_cloud_deployment),另一个服务负责
push Docker image到Google Cloud Registry(gcr_dockercfg)。我们已经为你提供了一个模板(https://github.com/codeship-library/gcr-dockercfg-generator)。

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

Push到Google Container Registry

Kubernetes持续部署Docker Apps

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

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

Kubernetes持续部署Docker Apps

上面的参数名很好地说明它们的含义,它的基本思想是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,Codeship有一个变量列表来帮助我们声明image的参数;但是,为了简化,我们使用当下的Unix时间戳,因为它是独一无二的,无法替代。

有了image_tag,之前的配置就变成下面这样了:

Kubernetes持续部署Docker Apps

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

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

本文为翻译文章,点击阅读原文链接即可查看原文。

Kubernetes持续部署Docker Apps

no comments
Share

发表评论