背景
本节是继DevOps实例演示
的第四篇文章, 在上一篇文章中, 我们已经成功安装部署了GitLab
并且安装了GitLab-Runner
,初步完成了我们的DevOps的第一步需求, 本篇文章目的在于再向大家介绍一种git-runner
的安装, 在阅读本篇前,笔者强烈建议先阅读上篇
DevOps系列GitLab-CICD(二)之安装git-runner-rpm安装方式
声明: 在本文以及本系列文中, 不会涉及公司内部相关内容,旨在能帮助到和我一样摸着光亮前进的人。
备注: 在阅读本章节前, 若您掌握有一定的git命令
、Linux
以及Docker
知识将更容易理解。
介绍/区别
在上一篇文章中, 我们说讲到了, 比较常用的git-runner
的安装方式就是shell
以及Docker
. 那么他们有什么不同点呢?
先看一下我们在注册git-runner
的那一条选项有什么区别
#shell方式
Please enter the executor: docker+machine, kubernetes, docker, parallels, shell, ssh, virtualbox, docker-ssh+machine, docker-ssh:
shell
#docker方式
Please enter the executor: docker+machine, kubernetes, docker, parallels, shell, ssh, virtualbox, docker-ssh+machine, docker-ssh:
docker
# -----可以看到, 当我们选择了docker之后, 会多一个选项(选择一个docker镜像)
Please enter the default Docker image (e.g. ruby:2.1):
# -----因为笔者要对java进行编译打包, 在这选择一个已经包含基本环境`maven:3-jdk-8`的镜像
maven:3-jdk-8 (针对于java环境)
从上面我们已经看到一条区别了, 那么下面我们再具体说一下, 区别:
-
第一点:因为我们在runner的时候需要不同的环境, 比如你要runner的是
Java
你可能会需要依赖JDK以及Maven
环境, 如果你runner的是前端, 你可能需要依赖node以及npm
环境.- shell模式: 依赖环境都需要自己提前在服务器上面安装,配置好
- docker模式: 依赖环境可以直接通过现有的docker镜像进行部署
-
第二点: 如果服务器有限, 或者不想太多的资源浪费, 那么可以选择
docker
部署 -
第三点: 如果在整个
CI的pipeline
过程中, 每个阶段的产物你可能在下一个阶段会用到, 比如build完的jar或者一些其他资源, 在后续步骤中你用到, 那么选择shell
模式会比较理想一点,因为可以少去很多配置, 如果docker
模式的话, 完成一系列操作, 你可能需要费点劲去挂载目录
, 然后你后续再从挂载的目录下获取pipeline
的一些成果.
安装
在上一篇我们的安装比较详细, 在该篇文章中, 会涉及到不少重复的步骤, 会省略.
系统
CentOS Linux release 7.5.1804 (Core)
安装Docker
Docker版本
[root@gitlab-runner-64 ~]# docker version
Client:
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:48:22 2018
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:19:08 2018
OS/Arch: linux/amd64
Experimental: false
启动gitlab-runner
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
或者可以使用第三方存储valume的启动方式
docker run -d --name gitlab-runner-config \
-v /etc/gitlab-runner \
busybox:latest \
/bin/true
docker run -d --name gitlab-runner --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
--volumes-from gitlab-runner-config \
gitlab/gitlab-runner:latest
注册(配置和参考上一篇)
docker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner --name gitlab-runner gitlab/gitlab-runner register
执行完成之后,会有以下文件生成/srv/gitlab-runner/config
[root@gitlab-runner-64 ~]# cat /srv/gitlab-runner/config/config.toml
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "docker-runner"
url = "http://xxxxxxx/"
token = "xxxxxxxxxxxxxxxxxxxx"
executor = "docker"
[runners.docker]
tls_verify = false
image = "golang:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock","/cache"]
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
查看是否已经注册完成
到这里, 以及和上一篇文章一样了, 剩余后续的pipeline工作, 在这里就不在多多赘述了,
同时呢, 我们Devops过程中第一步也就介绍到这里了. 下面的一个系列是关于第二步骤中的Cd自动部署部分