从零搭建gitlabci环境

从零搭建gitlabci环境

学习途径

搭建环境

将gitlab镜像拉到服务器上跑起来。

1】拉取镜像

• 使用docker拉取gitlab/gitlab-ce的镜像
• docker拉取nginx镜像

#查看本地镜像
docker images
#从远程仓库拉取gitlab/gitlab-ce的镜像
docker pull gitlab/gitlab-ce
#从远程仓库拉取nginx镜像
docker pull nginx

docker images

#REPOSITORY         TAG       IMAGE ID       CREATED      SIZE
#node               latest    8f1b7f0dfc2f   5 days ago   907MB
#nginx              latest    08b152afcfae   5 days ago   133MB
#gitlab/gitlab-ce   latest    75d591b81fd7   6 days ago   2.23GB

2】运行镜像到容器

sudo docker run --detach --hostname gitlab.rayhomie.icu --publish 443:443 --publish 80:80 --publish 222:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest

3】查看当前运行的容器

docker container ls -a

#CONTAINER ID   IMAGE                     COMMAND             CREATED         STATUS    PORTS     NAMES
#df62d4c44c25   gitlab/gitlab-ce:latest   "/assets/wrapper"   3 minutes ago   Created             gitlab

4】查看容器名为gitlab的日志

#打印当前运行日志
docker logs gitlab

#实时打印日志
docker logs -f gitlab

5】成功运行gitlab

此时我们就成功地将gitlab镜像跑在了本地的docker容器中，并且可以通过地址来访问gitlab界面。

GitLab CI/CD基础知识

简单理解：但我们把本地代码推到gitlab远程仓库时，会触发一个流程，这个流程会执行一系列的任务，这些任务组装起来就是一个pipeline（流水线）。

• pipeline（流水线）
• stage（阶段）
• job（任务）

如上图可以看出这几个概念之间的关系是：

• 一个流水线包含多个阶段；
• 一个阶段包含多个任务；

gitlab只是一个代码仓库（代码管理工具平台），它是不会去跑这些流水线上的任务。所以又要引出一个概念gitlab runner（一个安装在服务器上的软件），所有的我们定义的cicd的操作都是在gitlab runner上去跑。（gitlab runner就是给cicd提供一个环境）

• .gitlab-ci.yml文件：用来定义流水线、阶段、任务。

docker安装GitLab Runner

1】拉取runner镜像

在docker远程仓库拉取gitlab/gitlab-runner镜像到本地：

#拉取镜像到本地
docker pull gitlab/gitlab-runner

2】运行镜像到容器

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

3】注册gitlab runner

要使gitlab runner和gitlab产生联系，需要找到我们gitlab的Token：

然后在gitlab runner运行的docker容器中用这个Token去注册一下，脚本具体如下：

docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register --non-interactive --executor "docker" --docker-image alpine:latest --url "http://gitlab.xxxx.com/" --registration-token "vtizNrFzQKFacsSMxsJX" --description "first-register-runner" --tag-list "test-cicd,dockercicd" --run-untagged="true" --locked="false" --access-level="not_protected"

• url参数是我们gitlab的地址
• registration-token参数是上图gitlab的token
• tag-list参数是注册这个runner的标签（后面可用于指定具体哪个runner去执行流水线任务）

.gitlab-ci.yml的编写

基本关键词使用

官方文档

• script：让gitlab runner去执行shell脚本（所有的任务都需要有script关键字去执行）
• stages：全局自定义阶段
• stage：在每个job（任务）中定义该任务属于哪个stage阶段。stage 是阶段的意思，用于归档一部分的job，按照定义的stage顺序来执行。（默认的stage有.pre，build，test，deploy，.post）job执行的顺序不是按照编写的顺序，大体上是按照stage定义的顺序来执行的,注意是大体，也有例外的情况。
• retry：有可能这个任务会失败，需要有个重试的机制（retry:2指定如果失败重试2次，最多设置为重试2次，也就是最多运行3次）
• image：指定一个基础Docker镜像作为基础运行环境，经常用到的镜像有node、java、python、docker
• tags：tags 关键词是用于指定Runner，tags的取值范围是在该项目可见的runner tags中
• only、except：限定当前任务执行的条件（限定分支等）
• when：when关键词是实现在发生故障或尽管发生故障时仍能运行的作业，比如你要在任务失败后需要出发一个job，或者你需要手动执行任务，或者当你一个任务执行成功后，执行另一个任务。
  • on_success：所有任务执行成功后
  • on_failure：当至少一个任务失败后
  • always：执行作业，而不考虑作业在早期阶段的状态
  • manual：手动执行任务
  • delayed：延迟执行任务
  • never：在rules中不排除执行的任务，在workflow:rules不允许的流水线
• cache：把一些文件列表保存到缓存中，在各个任务之间互相传递。缓存是将当前工作环境目录中的一些文件，一些文件夹存储起来，用于在各个任务初始化的时候恢复
• artifacts：成功时附加到作业的文件和目录列表。
• variables：在.gitlab-ci.yml文件中定义全局变量或者局部变量。（在全局定义即全局变量，在任务中单独定义即局部变量）
• release：自动化发布包
• timeout：设置超时时间
• resource_group：确保一个分支同时只有一个流水线在工作