GitLab在Kubernetes上的CI/CD

GitLab在Kubernetes上的CI/CD

[TOC]

1. Gitlab在Kubernetes中CI/CD流程

下图中，Gitlab在整个过程当中，参与了60%以上的工做，能够说，开发自从push了代码后，就能够直接测试并上线到生产环境。

在Kubernetes中，Gitlab Runner，是一个中介的做用，它申请pod运行stage，因此Runner并不直接运行stage。

在开始前，须要详细阅读.gitlab-ci.yml各名词和用法。

2. 环境

Kubernetes version: 1.12

Gitlab version: 11.4.3

3. Kubernetes安装

略

可以使用我写的一键安装脚本：
https://github.com/ygqygq2/kubernetes/blob/master/kubeadm/kubeadm_install_k8s.sh

4. GitLab安装

由于已经既然已经用上Kubernetes，那干脆把GitLab也搭建在它上面。
使用helm安装。

1. 添加gitlab的chart地址到helm repo；
2. 下载gitlab的chart；
3. 设置相关values.yaml；
4. helm安装；

gitlab的chart里，模块不少，使用--set有的并很差写，因此建议先修改values.yaml（包含各模块的values.yaml）。

这里若是是不使用自带的nginx ingress，推荐修改gitlab/values.yaml
global.ingress.annotations参数，下面增长
kubernetes.io/ingress.class: nginx

默认它会安装prometheus、certmanager、nginx ingress，按本身需求选择。个人环境已经有nginx ingress、prometheus了，certmanager又暂时没用上。因此这几个都设置为false，不安装。如需正式使用，注意持久存储大小。

helm repo add gitlab https://charts.gitlab.io/
helm fetch gitlab/gitlab --untar
cd gitlab
# vim values.yaml
namespace="devops"
helm upgrade --install gitlab --timeout 600 --namespace $namespace . \
--set gitlab.migrations.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-rails-ce \
--set gitlab.sidekiq.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce \
--set gitlab.unicorn.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-unicorn-ce \
--set gitlab.unicorn.workhorse.image=registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce \
--set gitlab.task-runner.image.repository=registry.gitlab.com/gitlab-org/build/cng/gitlab-task-runner-ce \
--set certmanager-issuer.email=my_email@163.com \
--set global.hosts.domain=linuxba.com \
--set global.smtp.enabled=true \
--set global.smtp.address=smtp.163.com \
--set global.smtp.user_name=my_email@163.com \
--set global.smtp.password.key=password \
--set global.smtp.password.secret=ygqmail \
--set global.time_zone="Asia/Shanghai" \
--set gitlab.gitaly.persistence.storageClass=ceph-rbd \
--set gitlab.gitaly.persistence.size=2Gi \
--set gitlab.gitaly.persistence.storageClass=ceph-rbd \
--set postgresql.persistence.size=2Gi \
--set postgresql.persistence.storageClass=ceph-rbd \
--set minio.persistence.size=5Gi \
--set minio.persistence.storageClass=ceph-rbd \
--set redis.persistence.size=1Gi \
--set redis.persistence.storageClass=ceph-rbd \
--set nginx-ingress.enabled=false \
--set prometheus.install=false \
--set certmanager.install=false \
--set gitlab.gitlab-shell.service.externalPort=20022 \
--set gitlab.gitlab-shell.service.internalPort=20022 \
--set gitlab.gitlab-runner.rbac.clusterWideAccess=true \
--set gitlab.gitlab-runner.rbac.create=true \
--set gitlab.gitlab-runner.runners.privileged=true \
--set glabal.initialRootPassword.key="Git@linuxba.com" \
--set gitlab.migrations.initialRootPassword.key="Git@linuxba.com"

# 自定义runner secret，统一管理
# --set gitlab.gitlab-runner.runners.secret=gitlab-runner-custom

# 上面已经不安装prometheus了，则不申请它的pvc
# --set prometheus.server.persistentVolume.storageClass=ceph-rbd \
# --set prometheus.server.persistentVolume.size=2Gi \

安装过程当中很容易出现以下提示：

E1129 15:21:12.482144 2878016 portforward.go:178] lost connection to pod
Error: UPGRADE FAILED: transport is closing

能够等1分钟，查看下pod是否在生成，若是在生成中，则其实已经安装成功。也能够再次使用上面命令，或者使用helm delete --purge删除再从新安装。

这也是让人讨厌的helm缺点之一，这篇文章
恕我直言，对Helm你们仍是要三思然后用有提到过。

安装成功后，我发现安装设置的root密码不生效，能够经过如下命令获取登陆的root密码：
kubectl get secret -n $namespace gitlab-test-gitlab-initial-root-password -ojsonpath={.data.password}|base64 -d

kubectl get ing能够看到，有3个ingress，访问gitlab.linuxba.com能够访问到gitlab界面。

注意：
HTTPS访问，由于证书secret关系，可能须要修改ing或者使用事先准备的证书文件生成ing中名称对应的secret。
这些都是k8s细节，这里不做详细描述。

5. Auto DevOps

5.1 添加Kubernetes集群

管理员经过服务模板添加Kubernetes集群，是生效全部项目的。

项目中也能够添加Kubernetes集群，优先于管理员添加的全局集群。

• Active须要勾上；
• 添加集群的API URL即为Kubernetes API地址，由于这里gitlab安装在Kubernetes内，可使用地址：https://kubernetes.default；
• CA证书，即为Kubernetes的ca证书内容所有复制粘贴；
• 添加集群使用的token和博客《
  为Kubernetes dashboard访问用户添加权限控制》中kubeconfig使用的token是同样的，这里再也不详细描述；
• Kubernetes namespace，若添加的token的serviceaccount对应的权限为某个namespace，这里须要填写其对应的namespace。默认为空的话，在ci/cd过程当中，会自动建立项目的惟一namespace，且只有此namespace的rbac权限。

5.2 一个demo

在看demo前，先了解下gitlab中.gitlab-ci.yml流水线：

Stage
GitLab CI/CD 的执行过程当中首先驱动的是 Stage。
每一个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的。若是其中任何一个 Stage 失败，则后续的 Stage 不会被执行，整个 CI 过程被认为失败。
默认包含三个 Stage：build、test 和deploy。
build 被首先执行。若是发生错误，本次 CI 马上失败；
test 在 build 成功执行完毕后执行。若是发生错误，本次 CI 马上失败；
deploy 在 test 成功执行完毕后执行。若是发生错误，本次 CI 失败。

Job
Job 包含了真正的执行逻辑，例如调用 mvn 或者 gcc 等命令。

demo项目地址：
https://github.com/ygqygq2/kubernetes-gitlab-autodevops
https://github.com/ygqygq2/kubernetes-gitlab-autodevops/tree/master/mytest

demo是一个maven项目，用到了maven环境的docker image。
脚本中，设置了settings.xml以用于上传image到harbor。
在.gitlab-ci.yml中，各步骤都有注释，已经算是一个完整的流程。
脚本都是shell，如有用到数组功能，须要在运行的stage的pod基础镜像安装bash，不然出现语法错误，比较误导人。

如下是此demo的流水线过程：

分支流水线：

主分支流水线：

build过程：

deploy过程：

手动运行流水线：


访问相关环境：

6. 小结

上文没有详细介绍demo，但从流水线图能够看出.gitlab-ci.yml的stage，熟悉gitlab的stage和job才能灵活配置CI/CD。建议先从最简单的开始，全部操做使用echo代替，整个流水线跑通了，再细化各job。

参考资料：
[1] https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html
[2] https://docs.gitlab.com/ee/user/project/clusters/index.html
[3] https://docs.gitlab.com/ee/topics/autodevops/index.html
[4] https://docs.gitlab.com/ee/ci/variables/
[5] https://docs.gitlab.com/ee/ci/yaml/README.html
[6] https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
[7] http://www.ttlsa.com/auto/gitlab-cicd-gitlab-ci-yml-configuration-tasks-detailed/