基于gitlab+docker+k8s打造自动化构建部署流程

Posted 2021-09-03 董洪臣

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于gitlab+docker+k8s打造自动化构建部署流程相关的知识，希望对你有一定的参考价值。

工程自动化构建部署

前言

随着需求越来越多，以及相关代码分支权限的流程规范化，团队内部的项目上线部署复杂度提升，基于现有的环境和市场上主流的软件，打造了一套基于gitlab+docker+harbor+kubernetes的自动化构建部署流程(CI/CD)，目前团队内部流程基本走通，整理了一份相关文档分享出来。写的糙的地方，轻喷。

概念

GitLab CI/CD

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。与之对应的有GitHub和Gitee，公司内部使用一般使用GitLab作为代码管理工具。

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：

Continuous Integration (CI) 持续集成
Continuous Delivery (CD) 持续交付
Continuous Deployment (CD) 持续部署

持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。

持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。这些方法使得可以在开发周期的早期发现bugs和errors，从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。

GitLab CI/CD 由一个名为 .gitlab-ci.yml 的文件进行配置，改文件位于仓库的根目录下。文件中指定的脚本由GitLab Runner执行。

Docker

Docker 是一个开源的应用容器引擎，基于Go语言开发并遵从 Apache2.0 协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口,更重要的是容器性能开销极低。

Harbor

虽然Docker官方提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署公司私有环境内的Registry是非常有必须要的。

Harbor是由VMware公司开源的企业级的Docker Registry管理项目，相比docker官方拥有更丰富的权限管理和完善的架构设计，适用于大规模docker集群部署提供仓库服务

它主要提供Docker Registry管理界面UI，可基于角色访问控制，镜像复制，AD/LDAP集成，日志审核等功能，重点是完全支持中文。

Kubernetes

kubernetes(简称k8s)是用于自动部署、扩容和管理编排容器化应用程序的开源系统，该系统由Google设计并捐赠给Linux基金会来使用。

它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。它支持一系列容器工具，包括docker、containerd等。

搭建GitLab-Runner

服务器要求

最少一台runner服务器，建议最低配置为2C4G以上
gitlab服务

配置CI/CD的Runners

点击项目，左侧的Settings---->CI/CD---->Runners---->Expand，如下图所示

登录runner服务器，安装gitlab-runner

curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"

chmod +x /usr/local/bin/gitlab-runner

##添加用户，此处可以不添加，如果用root权限的话，建议直接指定root用户。防止后续持续性集成的时候出现权限问题
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
## 切换到root用户  --user=root
gitlab-runner install --user=root --working-directory=/home/gitlab-runner
#gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
 
gitlab-runner start
## 也可以后续调整配置文件
vim /etc/systemd/system/gitlab-runner.service

配置文件： /etc/systemd/system/gitlab-runner.service

[Unit]
Description=GitLab Runner
ConditionFileIsExecutable=/usr/local/bin/gitlab-runner
After=syslog.target network.target

[Service]
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--user" "root"

Restart=always
RestartSec=120
EnvironmentFile=-/etc/sysconfig/gitlab-runner
[Install]
WantedBy=multi-user.target

重启服务

systemctl daemon-reload
systemctl restart gitlab-runner.service

注册到gitlab上

说明：

gitlab-ci-multi-runner register：执行注册命令
Please enter the gitlab-ci coordinator URL：输入 ci 地址
Please enter the gitlab-ci token for this runner：输入 ci token
Please enter the gitlab-ci description for this runner：输入 runner 名称
Please enter the gitlab-ci tags for this runner：设置 tag
Whether to run untagged builds：这里选择 true ，代码上传后会能够直接执行
Whether to lock Runner to current project：直接回车，不用输入任何口令	
Please enter the executor：选择 runner 类型，这里我们选择的是 shell

执行注册：（后面在GitLab的UI中更改）

gitlab-runner register
##输入gitlab的地址，以下信息在上图中有体现，图中4的位置
Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlaball.nicetuan.net/
##输入token
Enter the registration token:
*********
##输入runner的描述，一般可以设置为runner的hostname
Enter a description for the runner:
do-runner-004
## 输入与Runner关联的标签
Enter tags for the runner (comma-separated):
master
##输入Runner执行程序，一般选择shell，根据真实情况选择
Enter an executor: docker+machine, parallels, shell, ssh, virtualbox, kubernetes, custom, docker, docker-ssh, docker-ssh+machine:
shell
##执行完毕
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

刷新刚刚的CI/CD页面，发现已经添加runner机器成功

配置gitlab-ci.yml文件

注意：此处demo是演示的go版本，可以根据具体的项目环境进行调整脚本操作，大体操作是不变的

项目添加.gitlab-ci.yml

此处默认为该文件名，如有调整，可以从GitLab项目中的Settings---->CI/CD---->General pipelines中修改

before_script:
  - go env -w GOPROXY=https://goproxy.cn,direct
  - go env -w GO111MODULE=on
stages:
  - build
  - test
  - lint
  - docker-deploy
build:
  stage: build
  allow_failure: false  
  script:
    - go mod tidy
    - make
  only:
    - tags
    - branches
  retry: 1
test:
  stage: test
  script:
    - go test -test.v  ./...  -nacosDir=$PWD/conf  -logDir=$PWD/
  only:
    - tags
    - branches
  retry: 1
lint:
  stage: lint
  allow_failure: false
  script:
    - golangci-lint --version
    - golangci-lint run -v
  only:
    - tags
    - branches
  retry: 1
docker-deploy:
  stage: docker-deploy
  script:
    - make
    - docker build --rm -t bigdata-harbor.nicetuan.net/risk/riskclient:$CI_COMMIT_REF_NAME .
    - docker push bigdata-harbor.nicetuan.net/risk/riskclient:$CI_COMMIT_REF_NAME
  only:
    - tags

说明：

触发build、test、lint 流程：当branchs和tags变更的时候。注意allow_failure: false ，设置是否允许该job失败。

触发docker-deploy 流程：当项目打tag版本的时候，触发docker编译和推送到公司私有仓库上。此处需要特别注意：

1：代码的tag版本需要严格按照发版操作，vx.y.z。因为下面的docker 镜像就是根据这个版本来创建，同时生产环境升级也是根据此情况来执行。

2：runner服务器如果已经登录过私服，则可以不执行docker login 192.168.1.1 -u admin -p 123456，否则会推送到仓库失败

3：如果上面执行gitlab-runner 的用户不是root，则此处有可能会出现权限问题，因为docker是用root启动的。