在容器上构建持续部署及最佳实践初探

2019 年 11 月 8 日
筆記

要想理解持续集成和持续部署，先要了解它的部分组成，以及各个组成部分之间的关系。下面这张图是我见过的最简洁、清晰的持续部署和集成的关系图。

持续部署：

如图所示，开发的流程是这样的：
程序员从源码库（Source Control）中下载源代码，编写程序，完成后提交代码到源码库，持续集成（Continuous Integration）工具从源码库中下载源代码，编译源代码，然后提交到运行库（Repository），然后持续交付（Continuous Delivery）工具从运行库（Repository）中下载代码，生成发布版本，并发布到不同的运行环境（例如DEV，QA，UAT， PROD）。

图中，左边的部分是持续集成，它主要跟开发和程序员有关；右边的部分是持续部署，它主要跟测试和运维有关。持续交付（Continuous Delivery）又叫持续部署（Continuous Deployment），它们如果细分的话还是有一点区别的，但我们这里不分得那么细，统称为持续部署。本文侧重讲解持续部署。

持续集成和部署有下面几个主要参与者：

源代码库：负责存储源代码，常用的有Git和SVN。
持续集成与部署工具：负责自动编译和打包以及把可运行程序存储到可运行库。比较流行的有Jenkins，GitLab，Travis CI，CircleCI 等
库管理器(Repository Manager)：也就是图中的Repository，我们又叫运行库，负责管理程序组件。最常用的是Nexus。它是一个私有库，它的作用是管理程序组件。

库管理器有两个职能：

管理第三方库：应用程序常常要用到很多第三方库，并且不同的技术栈需要的库不同，它们经常是存放在第三方公共库里，管理起来不是很方便。一般公司会建立一个私有管理库，来集中统一管理各种第三方软件，例如它既可以做为Maven库（Java），也可以做为镜像库（Docker），还可以做为NPM库（JavaScript），来保证公司软件的规范性。
管理内部程序的交付：所有公司在各种环境（例如DEV，QA，UAT， PROD）发布的程序都由它来管理，并赋予统一的版本号，这样任何交付都有据可查，同时便利于程序回滚。

持续部署步骤：

各个公司对持续部署（Continuous Deployment）的要求不同，它的步骤也不相同，但主要包括下面几个步骤：

下载源码：从源代码库（例如github）中下载源代码。
编译代码：编译语言都需要有这一步
测试：对程序进行测试。
生成镜像：这里包含两个步骤，一个是创建镜像，另一个是存储镜像到镜像库。
部署镜像： 把生成的镜像部署到容器上

上面的流程是广义的持续部署流程，狭义的流程是从库管理器中检索可运行程序，这样就省去了下载源码和编译代码环节，改由直接从库管理器中下载可执行程序。但由于并不是每个公司都有单独的库管理器，这里就采用了广义的持续部署流程，这样对每个公司都适用。

持续部署实例：

下面我们通过一个具体的实例来展示如何完成持续部署。我们用Jenkins来做为持续部署工具，用它部署一个Go程序到k8s环境。

我们的流程基本是上面讲的狭义流程，但由于没有Nexus，我们稍微变通了一下，改由从源码库直接下载源程序，步骤如下：

下载源码：从github下载源代码到Jenkins的运行环境
测试：这一步暂时没有实际内容
生成镜像：创建镜像，并上传到Docker hub。
部署镜像：将生成的镜像部署到k8s

在创建Jenkins项目之前，先要做些准备工作：

建立Docker Hub账户

需要在Docker Hub上创建账户和镜像库，这样才能上传镜像。具体过程这里就不详细讲解了，请查阅相关资料。

在Jenkins上创建凭证（Credentials）

需要设置访问Docker hub的用户和口令，以后在Jenkins脚本里可以通过变量的方式进行引用，这样口令就不会以明码的方式出现在程序里。

用管理员账户登录 Jenkins主页面后，找到 Manage Jenkins-》Credentials-》System -》Global Credentials -》Add Credentials，如下图所示输入你的Docker Hub的用户名和口令。“ID”是后面你要在脚本里引用的。

创建预装Docker和k8s的Jenkins镜像

Jenkins的默认容器里面没有Docker和k8s，因此我们需要在Jenkins镜像的基础上重新创建新的镜像，后面还会详细讲解。
下面是镜像文件（Dockerfile-modified-jenkins）

FROM jenkins/jenkins:lts    USER root    ENV DOCKERVERSION=19.03.4    RUN curl -fsSLO https://download.docker.com/linux/static/stable/x86_64/docker-${DOCKERVERSION}.tgz     && tar xzvf docker-${DOCKERVERSION}.tgz --strip 1                    -C /usr/local/bin docker/docker     && rm docker-${DOCKERVERSION}.tgz    RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl       && chmod +x ./kubectl       && mv ./kubectl /usr/local/bin/kubectl

上面的镜像在“jenkins/jenkins:lts”的基础上又安装了Docker和kubectl，这样就支持这两个软件了。镜像里使用的是docker的19.03.4版本。这里装的只是“Docker CLI”，没有Docker引擎。用的时候还是要把虚拟机的卷挂载到容器上，使用虚机的Docker引擎。因此最好保证容器里的Docker版本和虚机的Docker版本一致。

使用如下命令查看Docker版本：

vagrant@ubuntu-xenial:/$ docker version

详细情况请参见Configure a CI/CD pipeline with Jenkins on Kubernetes

准备工作已经完成，现在要正式创建Jenkins项目：

Jenkins脚本：

项目的创建是在Jenkins的主页上来完成，它的名字是“jenkins-k8sdemo”，它的最主要部分是脚本代码，它也跟Go程序存放在相同的源码库中，文件的名字也是“jenkins-k8sdemo”。项目的脚本页面如下图所示。

如果你不熟悉安装和创建Jenkins项目，请参阅在k8s上安装Jenkins及常见问题

下面就是jenkins-k8sdemo脚本文件：

def POD_LABEL = "k8sdemopod-${UUID.randomUUID().toString()}"  podTemplate(label: POD_LABEL, cloud: 'kubernetes', containers: [      containerTemplate(name: 'modified-jenkins', image: 'jfeng45/modified-jenkins:1.0', ttyEnabled: true, command: 'cat')    ],    volumes: [       hostPathVolume(mountPath: '/var/run/docker.sock', hostPath: '/var/run/docker.sock')    ]) {        node(POD_LABEL) {         def kubBackendDirectory = "/script/kubernetes/backend"         stage('Checkout') {              container('modified-jenkins') {                  sh 'echo get source from github'                  git 'https://github.com/jfeng45/k8sdemo'              }            }         stage('Build image') {              def imageName = "jfeng45/jenkins-k8sdemo:${env.BUILD_NUMBER}"              def dockerDirectory = "${kubBackendDirectory}/docker/Dockerfile-k8sdemo-backend"               container('modified-jenkins') {                 withCredentials([[$class: 'UsernamePasswordMultiBinding',                   credentialsId: 'dockerhub',                   usernameVariable: 'DOCKER_HUB_USER',                   passwordVariable: 'DOCKER_HUB_PASSWORD']]) {                   sh """                     docker login -u ${DOCKER_HUB_USER} -p ${DOCKER_HUB_PASSWORD}                     docker build -f ${WORKSPACE}${dockerDirectory} -t ${imageName} .                     docker push ${imageName}                     """                 }               }             }         stage('Deploy') {             container('modified-jenkins') {                 sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-deployment.yaml"                 sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-service.yaml"               }         }      }  }

我们逐段看一下代码：

设定容器镜像：

podTemplate(label: POD_LABEL, cloud: 'kubernetes', containers: [      containerTemplate(name: 'modified-jenkins', image: 'jfeng45/modified-jenkins:1.0', ttyEnabled: true, command: 'cat')    ],    volumes: [       hostPathVolume(mountPath: '/var/run/docker.sock', hostPath: '/var/run/docker.sock')    ])

这里设定Jenkins子节点Pod的容器镜像，用的是“jfeng45/modified-jenkins:1.0”，也就是我们在上个步骤创建的。所有的脚本里的步骤（stage）都用的是这个镜像。“volumes：”用来挂载卷到Jenkins容器中，这样Jenkins子节点就可以使用虚机的Docker引擎。

关于Jenkins脚本命令和设置挂载卷请参阅jenkinsci/kubernetes-plugin

创建镜像：

下面的代码生成Go程序的Docker镜像文件，这里我们没有用Docker插件，而是直接调用Docker命令，它的好处后面会讲到。它引用了我们前面设置的“Docker hub”的凭证去访问Docker库。在脚本里，我们先登录到“Docker hub”，然后使用上一步从GitHub下载的源代码来创建镜像，最后上传镜像到“Docker hub”。其中“${WORKSPACE}”是Jenkins预定义变量，从GitHub下载的源代码就存放在“${WORKSPACE}”里。

stage('Build image') {                def imageName = "jfeng45/jenkins-k8sdemo:${env.BUILD_NUMBER}"              def dockerDirectory = "${kubBackendDirectory}/docker/Dockerfile-k8sdemo-backend"               container('modified-jenkins') {                 withCredentials([[$class: 'UsernamePasswordMultiBinding',                   credentialsId: 'dockerhub',                   usernameVariable: 'DOCKER_HUB_USER',                   passwordVariable: 'DOCKER_HUB_PASSWORD']]) {                   sh """                     docker login -u ${DOCKER_HUB_USER} -p ${DOCKER_HUB_PASSWORD}                     docker build -f ${WORKSPACE}${dockerDirectory} -t ${imageName} .                     docker push ${imageName}                     """                 }               }             }

如果你想了解Jenkins命令详情，请参阅Set Up a Jenkins CI/CD Pipeline with Kubernetes

我们这里并没有重新生成Go程序的镜像文件，而是复用了以前就有的k8s创建Go程序的镜像文件，Go程序的镜像文件路径是“scriptkubernetesbackenddockerDockerfile-k8sdemo-backend”。
它的代码如下。后面还会讲到这样做的好处。

# vagrant@ubuntu-xenial:~/app/k8sdemo/script/kubernetes/backend$  # docker build -t k8sdemo-backend .    FROM golang:latest as builder    # Set the Current Working Directory inside the container  WORKDIR /app    COPY go.mod go.sum ./    RUN go mod download    COPY . .    WORKDIR /app/cmd    # Build the Go app  #RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main.exe    RUN go build -o main.exe    ######## Start a new stage from scratch #######  FROM alpine:latest    RUN apk --no-cache add ca-certificates    WORKDIR /root/    RUN mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2    # Copy the Pre-built binary file from the previous stage  COPY --from=builder /app/cmd/main.exe .    # Command to run the executable  # CMD exec /bin/bash -c "trap : TERM INT; sleep infinity & wait"  CMD

关于Go镜像文件详情，请参阅创建优化的Go镜像文件以及踩过的坑

部署镜像：

下面部署Go程序到k8s上，这里也没有用kubectl插件，而是直接用kubectl命令调用已经存在的k8s的部署和服务配置文件（文件里会引用生成的Go镜像），它的好处后面也会讲到。

 stage('Deploy') {             container('modified-jenkins') {                 sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-deployment.yaml"                 sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-service.yaml"               }         }

关于k8s的部署和服务配置文件详情，请参阅把应用程序迁移到k8s需要修改什么？

为什么没用Declarative？

用脚本来写Pipeline有两种方法，“Scripted Pipleline”和“Declarative Pipleline”，这里用的是第一种方法。 “Declarative Pipleline”是新的方法，之所以没用它，是因为开始用的是Declarative模式但没调出来，然后就改用“Scripted Pipleline”，结果成功了。后来才发现设置Declarative的方法，特别是如何挂载卷，但看了一下，比起“Scripted Pipleline”要复杂不少，就偷了一下懒，没有再改。

如果你想知道怎样在Declarative模式下设置挂载卷，请参阅Jenkins Pipeline Kubernetes Agent shared Volumes

自动执行项目：

现在的Jenkins中的项目需要手动启动，如果你需要自动启动项目的话就要创建webhook，GitHub和dockerhub都支持webhook，在它们的页面上都有设置选项。“webhook”是一个反向调用的URL，每当有新的代码或镜像提交时，GitHub和dockerhub都会调用这个URL，URL被设置成Jenkins的项目地址，这样相关的项目就会自动启动。

检验结果：

现在Jenkins的项目就完全配置好了，需要运行项目，检验结果。启动项目后，
查看“Console Output”，下面是部分输出（全部输出太长，请看附录），说明部署成功。

。。。  + kubectl apply -f /home/jenkins/workspace/test1/script/kubernetes/backend/backend-deployment.yaml  deployment.apps/k8sdemo-backend-deployment created  [Pipeline] sh+ kubectl apply -f /home/jenkins/workspace/test1/script/kubernetes/backend/backend-service.yaml  service/k8sdemo-backend-service created  [Pipeline] }  [Pipeline] // container  [Pipeline] }  [Pipeline] // stage  [Pipeline] }  [Pipeline] // node  [Pipeline] }  [Pipeline] // podTemplate  [Pipeline] End of Pipeline  Finished: SUCCESS

查看运行结果：
获得Pod名字：

vagrant@ubuntu-xenial:/home$ kubectl get pod  NAME                                           READY   STATUS    RESTARTS   AGE  envar-demo                                     1/1     Running   15         32d  k8sdemo-backend-deployment-6b99dc6b8c-8kxt9    1/1     Running   0          50s  k8sdemo-database-deployment-578fc88c88-mm6x8   1/1     Running   9          20d  k8sdemo-jenkins-deployment-675dd574cb-r57sb    1/1     Running   0          2d23h

登录Pod并运行程序：

vagrant@ubuntu-xenial:/home$ kubectl exec -ti k8sdemo-backend-deployment-6b99dc6b8c-8kxt9 -- /bin/sh  ~ # ./main.exe  DEBU[0000] connect to database  DEBU[0000] dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8  DEBU[0000] FindAll()  DEBU[0000] created=2019-10-21  DEBU[0000] find user:{1 Tony IT 2019-10-21}  DEBU[0000] find user list:[{1 Tony IT 2019-10-21}]  DEBU[0000] user lst:[{1 Tony IT 2019-10-21}]

结果正确。

Jenkins原理

实例部分已经结束，下面来探讨最佳实践。在这之前，先要搞清楚Jenkins的原理。

可执行命令

我一直有一个问题就是那些命令是Jenkins可以通过shell执行的？Jenkins和Docker、k8s不同，后者有自己的一套命令，只要把它们学会了就行了。而Jenkins是通过与别的系统集成来工作的，因此它的可执行命令与其他系统有关，这导致了你很难知道那些命令是可以执行的，那些不行。你需要弄懂它的原理，才能得到答案。当Jenkins执行脚本时，主节点会自动生成一个子节点（Docker容器），所有的Jenkins命令都是在这个容器里执行的。所以能执行的命令与容器密切相关。一般来讲，你可以通过shell来运行Linux命令。那下面的问题就来了：

为什么我不能用Bash？

因为你使用的子节点的容器可能使用的是精简版的Linux，例如Alpine，它是没有Bash的。
为什么我不能运行Docker命令或Kubectl？

因为它的默认容器是jenkinsci/jnlp-slave，而它里面没有预装Docker或kubectl。你可以不使用默认容器，而是指定你自己的容器，并在其中预装上述软件，那么就可以执行这些命令了。

如何共享文件

一个Jenkins项目通常要分成几个步骤（stage）来完成，例如你下载的源码要在几个步骤之间共享，那怎么共享呢？Jenkins为每个项目分配了一个WORKSPACE（磁盘空间）, 里面存储了所有从源码库和其他地方下载的文件，不同stage之间可以通过WORKSPACE来共享文件。

关于WORKSPACE详情，请参阅Jenkins Project Artifacts and Workspace

最佳实践

要总结最佳实践就要理解持续部署在整个开发流程中的作用和位置，它主要起一个串接各个环节的作用。而程序的部署是由k8s和Docker来完成的，因此程序部署的脚本也都在k8s中，并由k8s来维护。我们不想在Jenkins里再维护一套类似的脚本，因此最好的办法是把Jenkins的脚本压缩到最小，尽可能多地直接调用k8s的脚本。

另外能写代码就不要在页面上配置，只有代码是可以重复执行并保证稳定结果的，页面配置不能移植，而且不能保证每次配置都产生一样的结果。

尽量少使用插件

Jenkins有许多插件，基本上你想要完成什么功能都有相应的插件。例如你需要使用Docker功能，就有“Docker Pipeline”插件，你要使用k8s功能就有“kubectl”插件。但它会带来很多的问题。

第一，每个插件都有他自己的设置方式（一般要在Jenkins插件页面进行设置），但这种设置是与其他持续部署工具不兼容的。如果以后你要迁移到其他持续部署工具，这些设置都需要废弃。
第二，每个插件都有自己的命令格式，因此你需要另外学习一套新的命令。
第三，这些插件往往只支持部分功能，使你能做的事情受到了限制。

例如，你需要创建一个Docker镜像文件，命令如下，它将创建一个名为"jfeng45/jenkins-k8sdemo"的镜像，镜像的默认文件是在项目的根目录下的Dockerfile。

app = docker.build("jfeng45/jenkins-k8sdemo"）

但创建Docker镜像文件命令有许多参数选项，例如，你的镜像文件名不是Dockerfile，并且目录不是在项目根目录下，应如何写呢？这在以前的版本是不支持的，后来的版本支持了，但毕竟不太方便，还要学新的命令。最好的办法是能直接使用Docker命令，这样就完美的解决了上面说的三个问题。答案就在前面讲的Jenkins原理里，其实绝大多数插件都是不需要的，你只要自己创建一个Jenkins子节点容器，并安装相应的软件就能圆满解决。

下面是使用插件的脚本和不使用的对比，不使用的看起来更长，那时因为使用插件的脚本和Jenkins里的凭证设置有更好的集成，而不使用的脚本没有。但除了这个小缺点，其他方面不使用的脚本都要远远优于使用插件的。

使用插件的脚本（用插件命令）：

stage('Create Docker images') {    container('docker') {        app = docker.build("jfeng45/codedemo", "-f ${WORKSPACE}/script/kubernetes/backend/docker/Dockerfile-k8sdemo-test .")        docker.withRegistry('', 'dockerhub') {            // Push image and tag it with our build number for versioning purposes.            app.push("${env.BUILD_NUMBER}")        }      }    }

不使用插件的脚本（直接用Docker命令）：

stage('Create a d ocker image') {       def imageName = "jfeng45/codedemo:${env.BUILD_NUMBER}"       def dockerDirectory = "${kubBackendDirectory}/docker/Dockerfile-k8sdemo-backend"        container('modified-jenkins') {          withCredentials([[$class: 'UsernamePasswordMultiBinding',            credentialsId: 'dockerhub',            usernameVariable: 'DOCKER_HUB_USER',            passwordVariable: 'DOCKER_HUB_PASSWORD']]) {            sh """              docker login -u ${DOCKER_HUB_USER} -p ${DOCKER_HUB_PASSWORD}              docker build -f ${WORKSPACE}${dockerDirectory} -t ${imageName} .              docker push ${imageName}              """          }        }      }

尽量多使用k8s和Dcoker

例如我们要创建一个应用程序的镜像，我们可以写一个Docker文件，并在Jenkins脚本里调用这个Docker文件来创建，也可以写一个Jenkins脚本，在脚本里来创建镜像。比较好的方法是前者。因为Docker和k8s都是事实上的标准，移植起来很方便。

Jenkins脚本的代码越少越好

如果你认同前面两个原则，那么这一条就是顺理成章的，原因也和上面是一样的。

常见问题：

1.变量要放在双引号里
Jenkins的脚本即可以使用单引号也可以使用双引号，但如果你在引号里引用了变量，那么就要使用双引号。

正确的命令：

sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-deployment.yaml"

错误的命令：

sh 'kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-deployment.yaml'

2.docker not found

如果Jenkins的容器里没有Docker，但你又调用了Docker命令，那么“Console Output”里就会有如下错误：

+ docker inspect -f . k8sdemo-backend:latest  /var/jenkins_home/workspace/k8sdec@2@tmp/durable-01e26997/script.sh: 1:     /var/jenkins_home/workspace/k8sdec@2@tmp/durable-01e26997/script.sh: docker:     not found

3.Jenkins宕机了

在调试Jenkins时，我新创建了一个镜像文件并上传到“Docker hub”之后就发现Jenkins宕机了。检查了Pod，发现了问题，k8s找不到Jenkins的镜像文件了（镜像文件从磁盘上消失了）。因为Jenkins的部署文件的设置是“imagePullPolicy: Never”，所以一旦镜像没有了，它不会自动重新下载。后来找到了原因，Vagrant的默认磁盘大小是10G，如果空间不够，它会自动从磁盘上删除其他镜像文件，腾出空间，结果就把Jenkins的镜像文件给删了，解决方案是扩充Vagrant的磁盘大小。

下面是修改之后的Vagrantfile，把磁盘空间改成了16G。

Vagrant.configure(2) do |config|       。。。       config.vm.box = "ubuntu/xenial64"       config.disksize.size = '16GB'       。。。  end

详情请见How can I increase disk size on a Vagrant VM?

源码:

完整源码的github链接

下面是项目中与本文有关的部分：

索引

附录：

下面是Jenkins项目运行后的完整的“Console Output”：

Running in Durability level: MAX_SURVIVABILITY  [Pipeline] Start of Pipeline  [Pipeline] podTemplate  [Pipeline] {  [Pipeline] node  Still waiting to schedule task  ‘k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3’ is offline  Agent k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3 is provisioned from template Kubernetes Pod Template  Agent specification [Kubernetes Pod Template] (k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa):  * [modified-jenkins] jfeng45/modified-jenkins:1.0    Running on k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3 in /home/jenkins/workspace/jenkins-k8sdemo  [Pipeline] {  [Pipeline] stage  [Pipeline] { (Checkout)  [Pipeline] container  [Pipeline] {  [Pipeline] sh  + echo get source from github  get source from github  [Pipeline] git  No credentials specified  Cloning the remote Git repository  Cloning repository https://github.com/jfeng45/k8sdemo   > git init /home/jenkins/workspace/jenkins-k8sdemo # timeout=10  Fetching upstream changes from https://github.com/jfeng45/k8sdemo   > git --version # timeout=10   > git fetch --tags --force --progress -- https://github.com/jfeng45/k8sdemo +refs/heads/*:refs/remotes/origin/*   > git config remote.origin.url https://github.com/jfeng45/k8sdemo # timeout=10   > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10   > git config remote.origin.url https://github.com/jfeng45/k8sdemo # timeout=10  Fetching upstream changes from https://github.com/jfeng45/k8sdemo   > git fetch --tags --force --progress -- https://github.com/jfeng45/k8sdemo +refs/heads/*:refs/remotes/origin/*  Checking out Revision 90c57dcd8ff362d01631a54125129090b503364b (refs/remotes/origin/master)   > git rev-parse refs/remotes/origin/master^{commit} # timeout=10   > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10   > git config core.sparsecheckout # timeout=10   > git checkout -f 90c57dcd8ff362d01631a54125129090b503364b   > git branch -a -v --no-abbrev # timeout=10   > git checkout -b master 90c57dcd8ff362d01631a54125129090b503364b  Commit message: "added jenkins continous deployment files"  [Pipeline] }   > git rev-list --no-walk 90c57dcd8ff362d01631a54125129090b503364b # timeout=10  [Pipeline] // container  [Pipeline] }  [Pipeline] // stage  [Pipeline] stage  [Pipeline] { (Build image)  [Pipeline] container  [Pipeline] {  [Pipeline] withCredentials  Masking supported pattern matches of $DOCKER_HUB_USER or $DOCKER_HUB_PASSWORD  [Pipeline] {  [Pipeline] sh  + docker login -u **** -p ****  WARNING! Using --password via the CLI is insecure. Use --password-stdin.  WARNING! Your password will be stored unencrypted in /home/jenkins/.docker/config.json.  Configure a credential helper to remove this warning. See  https://docs.docker.com/engine/reference/commandline/login/#credentials-store    Login Succeeded  + docker build -f /home/jenkins/workspace/jenkins-k8sdemo/script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend -t ****/jenkins-k8sdemo:7 .  Sending build context to Docker daemon  218.6kB    Step 1/13 : FROM golang:latest as builder   ---> dc7582e06f8e  Step 2/13 : WORKDIR /app   ---> Running in c5770704333e  Removing intermediate container c5770704333e   ---> 73445078c82d  Step 3/13 : COPY go.mod go.sum ./   ---> 6762344c7bc8  Step 4/13 : RUN go mod download   ---> Running in 56a1f253c3f5  [91mgo: finding github.com/davecgh/go-spew v1.1.1  [0m[91mgo: finding github.com/go-sql-driver/mysql v1.4.1  [0m[91mgo: finding github.com/konsorten/go-windows-terminal-sequences v1.0.1  [0m[91mgo: finding github.com/pkg/errors v0.8.1  [0m[91mgo: finding github.com/pmezard/go-difflib v1.0.0  [0m[91mgo: finding github.com/sirupsen/logrus v1.4.2  [0m[91mgo: finding github.com/stretchr/objx v0.1.1  [0m[91mgo: finding github.com/stretchr/testify v1.2.2  [0m[91mgo: finding golang.org/x/sys v0.0.0-20190422165155-953cdadca894  [0mRemoving intermediate container 56a1f253c3f5   ---> 455ef98244eb  Step 5/13 : COPY . .   ---> 092444c8a5ef  Step 6/13 : WORKDIR /app/cmd   ---> Running in 558240a3dcb1  Removing intermediate container 558240a3dcb1   ---> 044e01b8184b  Step 7/13 : RUN go build -o main.exe   ---> Running in 648899ba522c  Removing intermediate container 648899ba522c   ---> 69f6652bc706  Step 8/13 : FROM alpine:latest   ---> 965ea09ff2eb  Step 9/13 : RUN apk --no-cache add ca-certificates   ---> Using cache   ---> a27265887a1e  Step 10/13 : WORKDIR /root/   ---> Using cache   ---> b9c048c97f07  Step 11/13 : RUN mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2   ---> Using cache   ---> 95a2b77e3e0a  Step 12/13 : COPY --from=builder /app/cmd/main.exe .   ---> Using cache   ---> c5dc6dfdf037  Step 13/13 : CMD exec /bin/sh -c "trap : TERM INT; (while true; do sleep 1000; done) & wait"   ---> Using cache   ---> b141558cb0f3  Successfully built b141558cb0f3  Successfully tagged ****/jenkins-k8sdemo:7  + docker push ****/jenkins-k8sdemo:7  The push refers to repository [docker.io/****/jenkins-k8sdemo]  0e5809dd35f7: Preparing  8861feb71103: Preparing  5b63d4bd63b4: Preparing  77cae8ab23bf: Preparing  77cae8ab23bf: Mounted from ****/codedemo  8861feb71103: Mounted from ****/codedemo  5b63d4bd63b4: Mounted from ****/codedemo  0e5809dd35f7: Mounted from ****/codedemo  7: digest: sha256:95c780bb08793712cd2af668c9d4529e17c99e58dfb05ffe8df6a762f245ce10 size: 1156  [Pipeline] }  [Pipeline] // withCredentials  [Pipeline] }  [Pipeline] // container  [Pipeline] }  [Pipeline] // stage  [Pipeline] stage  [Pipeline] { (Deploy)  [Pipeline] container  [Pipeline] {  [Pipeline] sh  + kubectl apply -f /home/jenkins/workspace/jenkins-k8sdemo/script/kubernetes/backend/backend-deployment.yaml  deployment.apps/k8sdemo-backend-deployment created  [Pipeline] sh  + kubectl apply -f /home/jenkins/workspace/jenkins-k8sdemo/script/kubernetes/backend/backend-service.yaml  service/k8sdemo-backend-service created  [Pipeline] }  [Pipeline] // container  [Pipeline] }  [Pipeline] // stage  [Pipeline] }  [Pipeline] // node  [Pipeline] }  [Pipeline] // podTemplate  [Pipeline] End of Pipeline  Finished: SUCCESS