和Jenkins相比,GitLab本身,就相当于Jenkins的Master。 GitLab Runner类似Jenkins的Agent(Slave),可以理解为运行Job的容器或管理者
前置条件
在开始之前,你需要满足以下条件:
- 创建一个Kubernetes集群
- 手动安装创建一个GitLab源码库
- 手动安装一个GitLab Runner
- 了解GitLab CI/CD的基本概念和使用方法
准备安装包:
1.安装gitlab
gitlab-ce-12.0.0-ce.0.el7.x86_64.rpm
gitlab-runner-12.0.0-1.x86_64.rpm
如果确实依赖包,可以选择yum安装
即:
yum - y install gitlab-ce-12.0.0-ce.0.el7.x86_64.rpm
修改中文
默认语言使用的英文,如果想修改为中文的话。操作步骤:右上角头像 -> Settings -> Preferences -> Language -> 简体中文 -> save changes。
初始化;
启动,首先要修改初始化文件,一般是在/etc/gitlab/gitlab.rb,主要是修改如下几项:
external_url ‘http://自己服务器IP’,#这个是gitlab url,就是以后访问要使用的,所以一定要设置好,严格按照格式设置,"http://"不能省略,生产环境建议使用域名。
邮件设置:
# 启用 smtp 服务
gitlab_rails['smtp_enable'] = true
# 配置 smtp 服务地址,这里需要填写邮件服务里面的“SMTP服务器地址”(如下是网易163邮箱的smtp服务器地址)
gitlab_rails['smtp_address'] = "smtp.163.com"
# 配置 smtp 服务的端口号(默认)
gitlab_rails['smtp_port'] = 465
# 配置发送邮件的电子邮箱名称(即刚才注册的邮箱名称)
gitlab_rails['smtp_user_name'] = "xxx@163.com"
# 配置发送邮件的电子邮箱授权密码,刚才在邮箱里面开启 SMTP 服务的时候弹框提示的那一串【授权密码】(切记:这里不是邮箱的登录密码,是SMTP的授权密码)
gitlab_rails['smtp_password'] = "xxAxxSxxDx"
# 配置 SMTP 服务的域名,和上面的smtp服务器地址一致(如下是网易163邮箱的smtp域名)
gitlab_rails['smtp_domain'] = "smtp.163.com"
# 配置 SMTP 鉴定类别(默认 login 即可)
gitlab_rails['smtp_authentication'] = "login"
# 开启纯文本通信协议扩展
gitlab_rails['smtp_enable_starttls_auto'] = true
# 开启 smtp_tls (传输安全)
gitlab_rails['smtp_tls'] = true
# gitlab 服务邮件发送来源邮箱(即发出邮件的发送方邮箱),填写刚才注册的邮箱即可
gitlab_rails['gitlab_email_from'] = 'git_xxx@163.com'
gitlab_rails['time_zone'] = 'Asia/Shanghai'
还有就是数据目录存放,默认存放到/var/lib/gitlab下面,可以修改为其他较大空间的目录。
#重新加载配置信息
gitlab-ctl reconfigure
#重新启动服务
gitlab-ctl restart
启动完成后,查看一下状态:
出现以上证明启动成功,使用上面设置的external_url ‘http://自己服务器IP’,访问一下,生产环境建议设置一个域名,使用nginx代理一下。
首次访问会提示更新密码,设置一个新的密码就可以了,默认用户名root。
其他命令
#启动 gitlab 服务gitlab-ctl start
#停止 gitlab 服务gitlab-ctl stop
查看版本:
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
管理员配置:
http://127.0.0.0/admin 管理员配置
2、安装gitlab-runner
yum -y install gitlab-runner-12.0.0-1.x86_64.rpm
2. 安装GitLab Runner
为了在Kubernetes集群中执行GitLab CI Pipeline,我们需要在该集群中安装GitLab Runner并配置相应的Runner Executor。具体步骤如下:
2.1 获取GitLab Runner的注册信息
在GitLab源码库中获取GitLab Runner的注册信息,包括URL和registration token等。
2.2 配置GitLab Runner
使用以下命令注册Runner:
gitlab-runner register \
--non-interactive \
--url "http://YOUR_GITLAB_URL/" \
--registration-token "YOUR_REGISTRATION_TOKEN" \
--executor "shell" \
--description "k8s-runner" \
--tag-list "build,k8s,java" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"
向GitLab-CI注册一个Runner必须有:GitLab-CI的url和注册token。
token用于确定Runner是所有工程都能够使用的Shared Runner还是具体某一个工程才能使用的Specific Runner。
如果要注册Shared Runner,需要到管理界面的Runners页面里面查找注册token。使用管理员登录,点击Admin Area菜单,右侧导航栏Runners,
通过gitlab-ci-multi-runner register注册的Runner配置会存储在/etc/gitlab-runner/config.toml中,如果需要修改可直接编辑该文件。GitLab-CI会为每个Runner生成一个唯一的token,以后Runner就通过token与GitLab-CI进行通信。变量配置:
在这里,你需要将YOUR_GITLAB_URL
和YOUR_REGISTRATION_TOKEN
替换为你的GitLab URL和注册令牌。
图形化配置查看
获取GitLab Runner的注册信息。
获取项目专用Runner的注册信息。
登录GitLab。
在顶部导航栏中,选择Projects > Your projects。
在Your projects页签下,选择相应的Project。
在左侧导航栏中,选择Settings > CI / CD。
单击Runners右侧的Expand。
命令查询
gitlab-runner list
列出注册的Runner,显示Runner的状态、标签、运行器等信息。
gitlab-runner stop 28923
停止指定Runner,28923为Runner的ID。停止Runner后,其状态变为stopped,不会再执行新任务。
gitlab-runner verify
验证Runner的配置是否正确。
2.3 缓存配置
GitLab Runner对缓存方案的支持有限,所以我们需要使用挂载Volume的方式做缓存。在上面的示例中,安装GitLab Runner时默认使用/opt/cache
目录作为缓存空间。你也可以通过修改values.yaml
文件中的runners.cachePath
字段修改缓存目录。
例如,如需建立Maven缓存,你可以在variables
下添加MAVEN_OPTS
变量并指定本地缓存目录:
variables:
KUBECONFIG: /etc/deploy/config
MAVEN_OPTS: “-Dmaven.repo.local=/opt/cache/.m2/repository”
2.4 设置全局变量
在GitLab源码库中设置全局变量,包括Registry用户名、密码和KubeConfig的编码字符串。
-
REGISTRY_USERNAME
:镜像仓库用户名。 -
REGISTRY_PASSWORD
:镜像仓库密码。 -
kube_config
:KubeConfig的编码字符串。
执行以下命令生成KubeConfig的编码字符串:
echo $(cat ~/.kube/config | base64) | tr -d " "
- 编写.gitlab-ci.yml
创建.gitlab-ci.yml
文件来定义Pipeline,该Pipeline将完成Java项目的编译构建、镜像推送和应用部署。示例.gitlab-ci.yml
文件如下所示:
image: docker:stable # Pipeline中各个步骤阶段的构建镜像没有指定时, 默认使用docker:stable镜像
stages:
- package # 源码打包阶段
- docker_build # 镜像构建和打包推送阶段
- deploy_k8s # 应用部署阶段
variables:
KUBECONFIG: /etc/deploy/config # 定义全局变量KUBECONFIG
maven源码打包阶段。
mvn_build_job: # job名称
image: maven:3.6.2-jdk-14 # 本阶段构建使用的构建镜像
stage: package # 关联的阶段名称
tags: # GitLab Runner的tag
- k8s-runner
script:
- mvn package -B -DskipTests # 执行构建脚本
- cp target/demo.war /opt/cache # 构建物保存至缓存区
镜像构建和打包推送阶段。
docker_build_job: # job名称
image: docker:latest # 本阶段构建使用的构建镜像
stage: docker_build # 关联的阶段名称
tags: # GitLab Runner的tag
- k8s-runner
script:
- docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD registry.cn-beijing.aliyuncs.com # 登录镜像仓库
- mkdir target
- cp /opt/cache/demo.war target/demo.war
- docker build -t registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID . # 打包Docker镜像,使用的tag为本次Pipeline的ID
- docker push registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID # 推送Docker镜像
应用部署阶段。
deploy_k8s_job: # job名称
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/kubectl:1.16.6 # 本阶段构建使用的构建镜像
stage: deploy_k8s # 关联的阶段名称
tags: # GitLab Runner的tag
- k8s-runner
script:
- mkdir -p /etc/deploy
- echo $kube_config |base64 -d > $KUBECONFIG # 配置连接Kubernetes集群的config文件
- sed -i "s/IMAGE_TAG/$CI_PIPELINE_ID/g" deployment.yaml # 动态替换部署文件中的镜像tag
- cat deployment.yaml
- kubectl apply -f deployment.yaml
需要修改的地方有自己的config文件,已经变量账户名密码
包含模板文件
上述Pipeline包括三个阶段:
- package:使用maven构建Java项目,并将构建结果复制到缓存目录;
- docker_build:使用Docker构建镜像,并推送到k8s集群Registry;
- deploy_k8s:使用kubectl部署应用到Kubernetes集群中。
在这个Pipeline中,我们使用了一些GitLab CI的特性,例如:
- 使用
stages
设置流水线的阶段,定义了任务执行的顺序; - 使用
variables
设置变量,这些变量会在整个Pipeline中生效; - 使用
script
脚本指定具体的任务执行命令。
设置tags
Runner的设置可以在GitLab的网页上,进行二次调整,比如tags。
这是对Runner进行分类,以便不同项目的不同业务选择
- 启动Pipeline
当编辑完成.gitlab-ci.yml
文件之后,在GitLab源码库中点击“CI/CD”菜单,手动启动Pipeline。
此时,GitLab Runner将根据.gitlab-ci.yml
文件中的定义,自动执行Pipeline并完成Java项目的构建、镜像推送和应用部署。
执行Pipeline
提交.gitlab-ci.yml文件后,Project gitlab-java-demo会自动检测到这个文件并执行Pipeline, 如下图所示。
访问服务
如果部署文件中没有指定Namespace,则默认会部署到GitLab命名空间下:
kubectl -n gitlab get svc
预期输出:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
java-demo LoadBalancer 172.19.9.252 xx.xx.xx.xx 80:32349/TCP 1m
浏览器访问xx.xx.xx.xx/demo进行验证。
tips:
stages:
- test
- deploy
build:
stage: test
tags:
- linux
script:
- make
- make test
only:
- master
- merge_requests
- tags
install:
stage: deploy
tags:
- linux
- production
script:
- make
- make install
only:
- tags
示例,上面定义的两个Job,展示了GitLab CI的常见用法。 build属于test阶段,而install属于后面的deploy阶段,build会先于install执行。 如果build执行失败,install则不会执行。 build这个Job会在master分支、MR以及打tag三种情况下触发, 而install只会在打tag情况下触发。 build会在仅有标签linux的Runner下执行, 而install只会在包含linux和production两个标签的Runner下执行。