固定链接 Golang 基于GitLab CI/CD 部署方案

Golang 基于GitLab CI/CD 部署方案

Golang 基于GitLab CI/CD 部署方案

持续集成(Continuous Integration)是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

持续部署(Continuous Deployment)是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度,毕竟快速运转的互联网公司人力成本会高于机器,投资机器优化开发流程化相对也提高了人的效率,让 engineering productivity 最大化。

1. 环境准备

本次试验是基于 CentOS 7.3,Docker 17.03.2-ce 环境下的。Docker 的安装这里就不赘述了,提供官方链接:https://docs.docker.com/install/linux/docker-ce/centos/

1.1 Docker 启动 GitLab

启动命令如下:

port,hostname,volume 根据具体情况具体设置。

1.2 Docker 启动 gitlab-runner

启动命令如下:

volume 根据具体情况具体设置。

1.3 用于集成部署的镜像制作

我们的集成和部署都需要放在一个容器里面进行,所以,需要制作一个镜像并安装一些必要的工具,用于集成和部署相关操作。目前我们的项目都是基于 Golang 1.9.2 的,这里也就基于 Golang 1.9.2 的镜像制定一个特定的镜像。

Dockerfile 内容如下:

其中 Golint 是用于 Golang 代码风格检查的工具。

Docker 是由于需要在容器里面使用宿主的 Docker 命令,这里就需要安装一个 Docker 的可执行文件,然后在启动容器的时候,将宿主的 /var/run/docker.sock 文件挂载到容器内的同样位置。

Expect 是用于 SSH 自动登录远程服务器的工具,这里安装改工具是为了可以实现远程服务器端部署应用。

另外,在安装 Golint 的时候,是需要去 golang.org 下载源码的,由于墙的关系,go get 命令是执行不了的。为了处理这个问题,首先通过其他渠道先下载好相关源码,放到指定的路径下,然后 copy 到镜像里,并执行安装即可。

下面有段脚本是用于生成镜像的:

生成镜像后,推送到镜像仓库,并在 gitlab-runner 的服务器上拉取该镜像。

本次试验的 GitLab 和 gitlab-runner 是运行在同一服务器的 Docker 下的。

2. Runner 注册及配置

2.1 注册

环境准备好后,在服务器上执行以下命令,注册 Runner:

按照提示输入相关信息:

成功后,可以看到 GitL ab-> 你的项目 ->Settings -> CI/CD ->Runners settings 页面下面有以下内容:

2.2 配置

注册成功之后,还需要在原有的配置上做一些特定的配置,如下:

这里先解释下 gitlab-runner 的流程吧,gitlab-runner 在执行的时候,会根据上面的配置启动一个容器,即配置中的 go-tools:1.9.2,其中所有的启动参数都会在 [runners.docker] 节点下配置好,包括挂载啊,网络啊之类的。容器启动成功之后,会使用这个容器去 GitLab 上 pull 代码,然后根据自己定义的规则进行检验,全部检测成功之后便是部署了。

  • volumes:是为了在容器中可以执行宿主机的 Docker 命令。
  • extra_hosts:给 GitLab 添加个 host 映射,映射到 127.0.0.1
  • network_mode:令容器的网络与宿主机一致,只有这样才能通过 127.0.0.1 访问到 GitLab。
  • pull_policy:当指定的镜像不存在的话,则通过 Docker pull 拉取。

3. 定义规则

在 GitLab 项目根目录创建 .gitlab-ci.yml 文件,填写 Runner 规则,具体语法课参考官方文档:https://docs.gitlab.com/ee/ci/yaml/

3.1. Go集成命令

下面介绍几个 Golang 常见的集成命令:

包列表 正如在官方文档中所描述的那样,Go 项目是包的集合。下面介绍的大多数工具都将使用这些包,因此我们需要的第一个命令是列出包的方法。我们可以用 go list 子命令来完成:

请注意,如果我们要避免将我们的工具应用于外部资源,并将其限制在我们的代码中。 那么我们需要去除 vendor 目录,命令如下:

单元测试 这些是您可以在代码中运行的最常见的测试。每个 .go 文件需要一个能支持单元测试的 _ test.go 文件。可以使用以下命令运行所有包的测试:

数据竞争 这通常是一个难以逃避解决的问题,Go 工具默认具有(但只能在 Linux/amd64、FreeBSD/amd64、Darwin/amd64 和 Windows/amd64 上使用):

代码覆盖 这是评估代码的质量的必备工具,并能显示哪部分代码进行了单元测试,哪部分没有。

要计算代码覆盖率,需要运行以下脚本:

如果我们想要获得 HTML 格式的覆盖率报告,我们需要添加以下命令:

构建 最后一旦代码经过了完全测试,我们要对代码进行编译,从而构建可以执行的二进制文件。

linter 这是我们在代码中使用的第一个工具:linter。它的作用是检查代码风格/错误。这听起来像是一个可选的工具,或者至少是一个“不错”的工具,但它确实有助于在项目上保持一致的代码风格。

linter 并不是 Go 本身的一部分,所以如果要使用,你需要手动安装它(之前的 go-tools 镜像我们已经安装过了)。

使用方法相当简单:只需在代码包上运行它(也可以指向 . go 文件):

注意 -set_exit_status 选项。 默认情况下,Golint 仅输出样式问题,并带有返回值(带有 0 返回码),所以 CI 不认为是出错。 如果指定了 -set_exit_status,则在遇到任何样式问题时,Golint 的返回码将不为 0。

3.2 Makefile

如果我们不想在 .gitlab-ci.yml 文件中写的太复杂,那么我们可以把持续集成环境中使用的所有工具,全部打包在 Makefile 中,并用统一的方式调用它们。

这样的话,.gitlab-ci.yml 文件就会更加简洁了。当然了, Makefile 同样也可以调用 *.sh 脚本文件。

3.3 配置示例

3.3.1 .gitlab-ci.yml

3.3.2 Makefile

3.3.3 coverage.sh

3.3.4 buildDockerImage.sh

3.3.5 automationDeployment.sh

3.3.6 Dockerfile

3.3.7 run_application.sh

4. 结果

以下为部署成功后的截图:

原文链接:http://www.chairis.cn/blog/article/96

您的留言将激励我们越做越好