使用Google Cloud Build的Vapor 3的简单CD流水线— git push→Docker容器→GKE中可用的服务

我有一个用Swift 4.1编写的Vapor 3项目，我想创建一个简单的CD管道，以便在每次git push送到分支时（或当有新标签时），都将在Google Kubernetes Engine中构建并部署一个容器，其API可从http://[INGRESS_IP]/projectname/获得，GKE中已配置了一个群集，该群集已配置Istio 1.0作为服务网格和定义的路由。

Vapor 3 Web框架

您可以在https://vapor.codes/上查看有关Vapor 3的更多信息，以及在https://docs.vapor.codes/3.0/上提供的文档。这里特别令人感兴趣的是Swift 4.1与高性能Apple NIO非阻塞框架的结合。

如果要利用并行计算，多核体系结构和事件驱动的设计模式，则可能希望为项目采用非阻塞体系结构。

Vapor 3还带有一个异步库。您可以使用的越多，并行化就越多。

云构建

Google Cloud Build是启用CD管道的简单工具；在触发器方面，它支持推送到git分支和标签（与Google自己的代码仓库，GitHub和Bitbucket的Cloud Source Repository集成）。已经有很多可用的云构建器可以作为单个步骤添加到管道中（例如，docker，mvn，go，kubectl等）。

创建Dockerfile
配置Kubernetes部署和服务
配置Istio网关和虚拟服务
在cloudbuild.yaml配置管道
在Google Cloud Build中定义构建触发器（ 例如，推送，标记）

1.创建Dockerfile

我使用了两个阶段的多阶段Dockerfile：

在Swift 4.1容器映像上构建Vapor 3服务
编译后的文件将复制到干净的生产映像中，从而生成一个小容器。此示例使用ubuntu:16.04但有些人也使用alpine,显然有一些好处。我没有尝试过alpine版本，如果它对您有用，请分享您的配置文件和/或评论

  ＃Builder图像-构建代码 
  ＃================================================== ============== 
 来自swift：4.1作为构建者 
 运行apt-get -qq更新&& rm -r / var / lib / apt / lists / * 
  WORKDIR / app / 
 复制。  。＃1）复制Swift库 
  RUN mkdir -p / build / lib && cp -R /usr/lib/swift/linux/*.so / build / lib＃2）构建项目-调试模式 
  ＃运行swift build && mv`swift build --show-bin-path` / build / bin＃2）构建项目-生产 
 运行swift build --verbose -c release && mv`swift build -c release --show-bin-path` / build / bin 
  ＃生产图片 
  ＃================================================== ============== 
 来自ubuntu：16.04 
 运行apt-get -qq更新&& apt-get安装-y \ 
  libicu55 libxml2 libbsd0 libcurl3 libatomic1 \ 
  && rm -r / var / lib / apt / lists / * WORKDIR / app / 
 复制--from = builder / build / bin。 
 复制--from = builder / build / lib / * / usr / lib / EXPOSE 8888 
  CMD [“ ./Run"、"serv"、"--hostname"、"0.0.0.0"、"--port"、"8888”]

2. Kubernetes的部署和服务

以yaml的形式提供Kubernetes部署和服务的配置。

  --- 
  apiVersion：扩展程序/ v1beta1 
 种类：部署 
 元数据： 
 名称： 专案名称 
 标签： 
 应用程式：  项目名 
 规格： 
 复制品：1 
 选择器： 
  matchLabels： 
 应用程式：  项目名 
 模板： 
 元数据： 
 名称：  项目名 
 标签： 
 应用程式：  项目名 
 规格： 
 容器： 
  - 名称：  项目名 
 图片：eu.gcr.io/ [PROJECT_ID] /  项目名称： [TAG] 
  imagePullPolicy：始终 
 端口： 
  -containerPort：8888 
  --- 
  apiVersion：v1 
 种类：服务 
 元数据： 
 名称：  项目名 
 规格： 
 类型：ClusterIP 
 选择器： 
 应用程式：  项目名 
 端口： 
  -名称：http 
 端口：80 
  targetPort：8888

与kubectl apply -f ; 此外，如果您在群集中部署了Istio，则需要添加一些istioctl魔术以将容器注入侧边车： kubectl apply -f <(istioctl kube-inject -f deployment.yaml)

3. Istio配置文件

通过提供Gateway和VirtualService定义来设置到Istio入口服务的路由：

  --- 
  apiVersion：networking.istio.io/v1alpha3 
 种类：网关 
 元数据： 
 名称：  项目名  网关 
 规格： 
 选择器： 
  ＃使用istio默认控制器 
  istio：入口网关 
 服务器： 
  - 港口： 
 数：80 
 名称：http 
 协议：HTTP 
 主持人： 
  -“ *” 
  --- 
  apiVersion：networking.istio.io/v1alpha3 
 种类：VirtualService 
 元数据： 
 名称：  项目名 
 规格： 
 主持人： 
  -“ *” 
 网关： 
  --  项目名  网关 
  http： 
  - 比赛： 
  -uri： 
 字首： /  项目名   / 
 改写： 
  uri：“ /” 
 路线： 
  -目的地： 
  ＃Kubernetes服务的名称 
 主办：  项目名 
 港口： 
 数：80

这将使该项目的API可在以下位置获得： http://[INGRESS_IP]/projectname/

4.配置管道

在项目中添加cloudbuild.yaml配置文件。 Google Cloud Build使用此文件读取管道的定义。定义触发器时，您将需要提供它的路径。

 脚步： 
  ＃Docker构建 
  ＃================================================== ================ 
  -ID：docker-build-push 
 名称：gcr.io/cloud-builders/docker 
 入口点：bash 
  args： 
  - '-C' 
  -| 
  docker build -t“ eu.gcr.io/$PROJECT_ID/  项目名   ： $ SHORT_SHA “。 
  docker push“ eu.gcr.io/$PROJECT_ID/  项目名   ： $ SHORT_SHA “＃Kubernetes 
  ＃================================================== ================ 
  -id：kubectl-set-image 
 名称：gcr.io/cloud-builders/kubectl 
  args：['set'，'image'，'deployment /  项目名   '，'  项目名   = eu.gcr.io / $ PROJECT_ID /  项目名   ： $ SHORT_SHA '] 
  waitFor：['docker-build-push'] 
 环境： 
  -'CLOUDSDK_COMPUTE_ZONE = europe-west4-a' 
  -'CLOUDSDK_CONTAINER_CLUSTER = istio-1'＃机器类型-如果您需要更多火力，请更改此类型 
  ＃================================================== ================ 
 选项： 
  machineType：“ N1_HIGHCPU_8”

除了$SHORT_SHA 您还可以使用$TAG_NAME , $REVISION_ID （适用于触发的版本）， $COMMIT_SHA, 等。在这里，您可以发挥创造力。可以在Google Cloud Builder文档中找到这些定义。

5.创建一个构建触发器

通过选择与代码存储库（Cloud Source Repository，GitHub或Bitbucket）的集成来创建触发器。不幸的是，没有GitLab选项。设置是要在每次推送时执行还是在有新标记时执行，并提供cloudbuild.yaml.位置cloudbuild.yaml. 显然，Cloud Builder并没有强制将名称确切地命名为cloudbuild.yaml但是我猜想这样的惯例不符合惯例，因此您可以在定义多个触发器时更改或添加多个名称。

太棒了！您可以在Cloud Build→“ Build History”中观看实时触发的构建。在这里您还可以查看日志。

任何意见/反馈/更正始终受到欢迎。

谢谢。