gitlab 和gitlab-ci的使用说明

前期线上的服务器，都是使用xen。写好配置文件和脚本，用脚本一键创建的虚拟机。创建虚机比使用docker来扩容肯定慢的多，创建完虚机，还要等初始化，各种系统录入信息，主机名解析等等，最快也得5分钟。docker慢的话也就不到一分钟。使用虚拟，在创建完后要安装监控，cmdb，rundeck，主机注册consul,dns解析等等，然后还要和发版系统打通，数据库是否要授权等。docker不用做上述操作，编排器都帮忙做了。

前期持续集成，使用的gitlab+jenkins+rundeck

 

https://www.cnblogs.com/jiangyunmenglong/p/4126868.html

这篇文章写了如何通过配置文件用xen来创建虚拟机。

创建虚拟机：

1	/usr/sbin/xm create centos-root.cfg

xm console  <域ID>
   #从宿主机进入虚拟机的终端，退出时按 ctrl + ]

xm reboot   <域ID>
 #重新启动虚拟机

xm pause <域ID>
#暂停虚拟机

xm resume <域ID>
 #恢复被暂停的虚拟机

xm shutdown <域ID>           
#关闭 domain

后期重构，会使用gitlab, gitlab-ci, k8s, rancher, 来做持续集成，以及扩容缩容。

 gitlab 目前我们线上用的物理机，gitlab存储代码的分区，我们使用的raid来保证高可靠，因为代码很重要，不能丢失，

gitlab-runner是跑在docker里的。

https://www.cnblogs.com/cnundefined/p/7095368.html

 

这篇文章讲gitlab-ci和gitlab-runner讲的很好。

GitLab-CI就是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

那GitLab-Runner又是什么东东呢？与GitLab-CI有什么关系呢？

GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

GitLab-CI与GitLab-Runner关系示意图

Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。

Runner类型

GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。

Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

https://blog.csdn.net/txb0504/article/details/105300837

这篇文章gitlab-runner的配置讲的比较好。

Shared Runner 需要拿到shared runner 的token，注册到gitlab-ci，shared runner的token在 gitlab的admin区域，只有管理员可见。

Specific Runner的token在项目区域，各个项目可见。

https://blog.csdn.net/yejingtao703/article/details/83065591

讲安装注册gitlab-runner讲的好，

gitlab runner 有多种 安装方式，官方文档上有详细说明https://docs.gitlab.com/runner/install/，我们目前采用的是k8s+helm的部署方式，https://docs.gitlab.com/runner/install/kubernetes.html

 

docker部署方式也很常见，见下面说明：

2.1 准备docker环境
  docker的安装以前博文有介绍过，这里不再详解，重点是获取gitlab/gitlab-runner这个image。

  2.2 启动gitlab-runner
sudo docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest
  2.3 注册runner到gitlab
  先在gitlab的CI/CD页面找到url和token，如图

#进入容器
sudo docker exec -it gitlab-runner /bin/bash
#容器中完成注册
gitlab-runner register \
  --non-interactive \
  --url "http://10.100.129.113:8090" \
  --registration-token "S1Erstg39-nh1xQVMtBN" \
  --executor "docker" \
  --docker-image maven:latest \
  --description "193runner " \
  --tag-list "193" \
  --run-untagged \
  --locked="false"
重要参数说明：

    url和token参考上图，在runner需要对接的gitlab中获得；

    executor是runner中pipeline以什么方式运行，这里选择的是docker方式，其实还支持shell等其它方式。

    docker-image是runner中pipelne以哪个image为基础来执行executor。

    tag-list是runner的tag，在gitlab的project中关于ci的配置文件中会引用得到。

Runner注册成功后就会在gitlab的CI/CD页面看到下图中的红框内容：

如果出现灰色的runner说明runner虽然注册上来但是不可用，当gitlab与runner安装在同一台机器时就会出现这种情况，所以请尽量分开。

 

gitlab runner 的 executor是gitlab runner很重要的一个组件，用于执行构建，gitlab runner实现了很多种executor，用于不同场景下的构建。我们使用k8s+helm来安装gitlab runner,默认使用的Kubernetes executor，

The official way of deploying a GitLab Runner instance into your Kubernetes cluster is by using the gitlab-runner Helm chart.

This chart configures the Runner to:

• Run using the GitLab Runner Kubernetes executor.
• For each new job it receives from GitLab CI/CD, it will provision a new pod within the specified namespace to run it.

docker executor 也比较常用。

通常我们构建时，需要把打包后的程序集成到docker 镜像中，以便用docker, k8s来管理，CI/CD程序可能运行在容器中，就涉及到在容器中执行docker build， docker run等命令，gitlab 提供了几种方案（涉及到docker in docker dind 方案）：

https://docs.gitlab.com/ee/ci/docker/README.html

https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor

Use shell executor

Use Docker-in-Docker workflow with Docker executor

Use Docker socket binding

gitlab-ci 是gitlab中web页面的表现就是CI/CD设置页面里的那些内容。

自动部署涉及了若干个角色，主要介绍如下

• GitLab-CI 这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。

• GitLab-Runner 这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。

• .gitlab-ci.yml 这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。

三、.gitlab-ci.yml文件又是什么
.gitlab-ci.yml 用来配置GitLab-CI用你的项目做哪些操作，这个文件位于仓库的根目录，如果没有可以自己创建。

当有新内容push到仓库，或者有代码合并后，GitLab-CI会查找是否有 .gitlab-ci.yml文件，如果文件存在，GitLab-CI会依据文件内容通知某个Runner去执行.gitlab-ci.yml中定义的操作。

.gitlab-ci.yml 使用YAML语法， 你需要格外注意缩进格式，要用空格来缩进，不能用tabs来缩进。

.gitlab-ci.yml文件中的几个重要概念
Stages

Stages 表示构建阶段，说白了就是上面提到的流程。默认有3个stages：build, test, deploy。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage才会开始
只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
如果任何一个 Stage失败，那么后面的Stages不会执行，该构建任务 (Pipeline) 失败
Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

1、相同 Stage 中的 Jobs 会并行执行

2、相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功

3、如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

文章后面附注了更多关键字的解释，详细了解关键字以及YAML语法可以自己查。

yaml 文件例子：

# 定义 stages
stages:
  - build
  - test
# 定义 job
job1:
  stage: test
  script:
    - echo "I am job1"
    - echo "I am in test stage"
# 定义 job
job2:
  stage: build
  script:
    - echo "I am job2"
    - echo "I am in build stage"

另一个例子：

stages:
  - deploy
  - notice-success
  - notice-failure


package:Project:
  stage: deploy
  only:
    - /^feature.*$/
    - /^release.*$/
  variables:
    ############必须配置############
    ## 连接API的接口以及NGINX端口地址
    APIPORT: 9992
    NGINXPORT: 803

    #项目名称即git名称
    projectName: $CI_PROJECT_NAME
    #git idea 拉代码的git地址
    gitUrl: $CI_REPOSITORY_URL
    #工程所在目录
    baseDir: '/home/gitlab-runner/${CI_PROJECT_NAME}'
    ############选配############
    #打包所在目录
    buildDir: '/home/gitlab-runner/builds'
    #打包环境
    branch: $CI_COMMIT_REF_NAME
  script:
    - bash /SHELL/installPack $CI_PROJECT_NAME  $CI_REPOSITORY_URL  $CI_COMMIT_REF_NAME $APIPORT  $NGINXPORT
  tags:
    - web

notice_job:Project:
  variables:
    branch: $CI_COMMIT_REF_NAME
    projectName: $CI_PROJECT_NAME
  stage: notice-failure
  only:
    - /^feature.*$/
    - /^release.*$/
  script:
    - if [[ ${branch:0:8} = "feature/" ]];then env="dev" ;elif [[ ${branch:0:8} = "release-" ]];then  env="test";fi
    - python3 /SHELL/buildNotice.py $env $branch 失败  $projectName
  when: on_failure
  tags:
    - web

notice_job:Project:
  variables:
    branch: $CI_COMMIT_REF_NAME
    projectName: $CI_PROJECT_NAME
  stage: notice-success
  only:
    - /^feature.*$/
    - /^release.*$/
  script:
    - if [[ ${branch:0:8} = "feature/" ]];then env="dev" ;elif [[ ${branch:0:8} = "release-" ]];then  env="test";fi
    - python3 /SHELL/buildNotice.py $env $branch  成功  $projectName
  when: on_success
  tags:
    - web

gitlab有很多内置的环境变量，在.gitlab-ci.yaml中可以使用。
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

比如：CI_REGISTRY_IMAGE 返回镜像仓库的地址

CI_COMMIT_SHA 返回当前build后的hash值

gitlab-ci 可以在gitlab-runner调用的脚本中，git clone 代码到容器中。gitlab 8.9也支持通过变量来指定是否需要clone，或者fetch，或者什么都不做。

You can set the GIT_STRATEGY used for getting recent application code, either globally or per-job in the variables section. If left unspecified, the default from project settings will be used.

There are three possible values: clone, fetch, and none.

https://docs.gitlab.com/ee/ci/yaml/README.html#git-strategy

我们目前使用gitlab默认创建项目后，项目的settings-ci/cd里默认就设置了自动抓取，所以在gitlab-ci.yaml中build阶段就没必要显示指定

gitlab-runner 如何发布打包后的模块的k8s管理的容器中？

gitlab runner只是一连串功能给串起来，实现cicd. 中间得功能都得自己实现，包括构建，打包，发版等等。

gitlab-runner只是个程序，用来跑task，当然在目前使用的这个环境里他也跑在了k8s里，镜像就是官方的image(我们用的是helm chart)，打包部署这些是单独的镜像，只是要对接k8s的api，其他的都很像.

java应用部署到k8s的原理：

本质上deploy就是把应用程序包推送给k8s，对于k8s来说程序包无非两种形式，一种就是纯粹的Image，另外一种就是Chart

无论哪种程序package最终推给k8s无非是使用kubectl还是使用helm命令进行deploy操作

目前没有使用helm,原理就是前置流程制作好Image,deploy阶段kubectl apply相应的deployment,ingress,service资源

对于当前deploy脚本的实现，基本是以下流程：

• 配置kubeconfig（对应kubeconfig目录下对应的各个环境的配置信息）

• 创建名字为$CI_ENVIRONMENT_NAME的命名空间（gitlab推荐每个项目唯一一个，感觉有点太多）

• 创建gitlab registry拉去镜像的对应的secret（因为gitlab-ci-token是有有效期的，所以每次都需要创建/更新）

• 创建deployment,ingress,service...

• kubectl rollout status等待结果