gitlab-ci的最简最速实践

关联git

获取 gitlab access token 或者是把主机的 ssh key 配置到 gitlab 服务端上

我这里获取 gitlab 的 access token。请根据自己的情况选择

Setting >> Access Tokens

然后勾选所有权限，并一键生成

获得一串序列码，注意保存

配置 git remotes，URL 格式为

https://oauth:${ACCESS_TOKEN}@{GIT_URI}

至此，完成了本地代码和代码库的关联。

同步代码

git pull origin master --allow-unrelated-histories

拉取私仓中的文件

然后通过ide中 add >> push >> commit 将本地代码推送到仓库

配置Runner

实际的使用环境中，会有多个私仓，多个 pipeline，这些任务都需要异步的进行。gitlab 中 gitlab-server 接收到 webhook 或者手动/定时触发的执行 pipeline 的请求，会将这些任务分发到对应的gitlab-runner 中。因此在此步骤中，我们创建 runner 并注册到 server 上去。

点开所对应的代码 reposities  >> Settings >> General >> Visibility, project features, permissions. 开启 pipeline

 Settings >> CI/CD >> Runners 寻找我们所需要的对应的启动 runner 的方法；

因为是测试环境，所以我直接在本机以单机 docker 的方式启动

其中包含了注册 runner 所需要的凭据

在启动 runner 容器之前，需要在我本机执行以下操作

因为 gitlab-ci 也是采取的 dind 的模式，所以需要我们对其进行主机的 docker 注入。

首先不要用 centos 自带的 yum 源装 docker，它的版本太低了，换阿里云的，参考这篇文章

https://www.cnblogs.com/YorkQi/p/14480428.html

在 runner 上运行任务的时候使用的是 gitlab-runner 账户，使用 docker 时会提示权限不足问题：

所以我们需要将其加入到 docker 组

sudo usermod -aG docker gitlab-runner

外部启动的话，需要把 docker-cli docker.sock 以及一个外部关联库挂载进去

docker run -d --name gitlab-runner --restart always \
  -v /root/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /usr/bin/docker:/usr/bin/docker \
  -v /usr/local/bin/kubectl:/usr/local/bin/kubectl \
  -v /root/.kube/config:/kubeconfig \
  -e KUBECONFIG=/kubeconfig \
  gitlab/gitlab-runner:latest

启动之后进入容器并执行注册命令

gitlab-runner register 

根据之前在 gitlab 注册所需凭据依次键入完成 runner 和 server 的关联

可以在 web ui 上看到以下注册成功的信息

至此，runner 的相关配置就完成了

配置流水线

我们需要在项目目录下新建 .gitlab-ci.yml

这里主要将 pipeline 的步骤分为三步：

• 测试
• 构建
• 部署

文件的大致结构如下:

stages:
  - test
  - build
  - deploy
GoTest:
  stage: test
  script: []
  after_script: []
  tags:
    - go

GoBuild:
  stage: build
  script: []
  tags:
    - go

Deploy2K8S:
  stage: deploy
  script: []
  tags:
    - go

test stage 用于通过专用测试的 dockerfile 来构建测试镜像，镜像的入口是 go test 命令，用来执行 IDE 通过 generator 功能生成的 test 文件，在完成测试步骤后会删除测试用镜像，本步骤中只做编译构建，不做镜像推送

build stage 用于构建以 main.go 为入口的 docker image，并且会推送到私有镜像仓库

deploy stage 实现了最简单的交付流程，即通过 kubectl apply 应用新镜像对工作负载进行滚动更新

注意：实际生产环境中的持续交付，还需要对Pod的实际运行状况做一定的跟踪，并且有可能涉及到多集群的分发

至此，gitlab-ci 的最简实践就完成了。