CICD 持续集成与持续交付
目录
1 CICD简介
1.1 持续集成(Continuous Integration)
1.2 持续部署(Continuous Deployment)
1.3 持续交付(Continuous Delivery)
2 git工具使用
2.1 git简介
2.2 git 工作流程
3 部署git
3.1 安装git
3.2 初始化
4 git的使用方法
4.1 git的常用方法
4.2 git对于文件如何忽略
5 gitlab代码仓库
5.1 gitlab简介
5.2 gitlab 的部署实施
5.2.1 部署gitlab
5.2.2 配置gitlab
5.2.3 登陆gitlab
5.3 在gitlab中新建项目
6 Jenkins
6.1 jenkins 简介
6.2 部署 jenkins
6.3 jenkins 与gitlab的整合
编辑编辑
6.4 genkins 中 gitlab 触发器的部署与使用
6.4.1 安装插件
6.4.2.部署自动触发
7 持续集成与持续交付企业示例
7.1 在jenkins中添加registry-node
7.2 配置构建节点
7.3.测试镜像构建
7.4.在业务节点docker-node上自动运行构建好的镜像生成容器
8 CICD流水线总结
8.1 代码编写与上传
8.2 GitLab 触发 Jenkins 构建
8.3 Jenkins 构建镜像
8.4 Jenkins 上传镜像至 Harbor
8.5 Jenkins 在业务节点触发业务
8.6 业务节点下载并启动镜像
1 CICD简介
CI/CD 是指持续集成(Continuous Integration)和持续部署(Continuous Deployment)或持续交付(Continuous Delivery)
1.1 持续集成(Continuous Integration)
持续集成是一种软件开发实践,团队成员频繁地将他们的工作集成到共享的代码仓库中。其主要特点包括:
-
频繁提交代码:开发人员可以每天多次提交代码,确保代码库始终保持最新状态。
-
自动化构建:每次提交后,自动触发构建过程,包括编译、测试、静态分析等。
-
快速反馈:如果构建失败或测试不通过,能够快速地向开发人员提供反馈,以便及时修复问题。
1.2 持续部署(Continuous Deployment)
持续部署是在持续集成的基础上,将通过所有测试的代码自动部署到生产环境中。其特点如下:
-
自动化流程:从代码提交到生产环境的部署完全自动化,无需人工干预。
-
高频率部署:可以实现频繁的部署,使得新功能能够快速地提供给用户。
-
风险控制:需要有强大的测试和监控体系来确保部署的稳定性和可靠性。
1.3 持续交付(Continuous Delivery)
持续交付与持续部署类似,但不一定自动部署到生产环境,而是随时可以部署。其重点在于确保软件随时处于可发布状态。
CI/CD 的好处包括:
-
提高开发效率:减少手动操作和等待时间,加快开发周期。
-
尽早发现问题:通过频繁的集成和测试,问题能够在早期被发现和解决。
-
降低风险:减少了大规模部署时可能出现的问题,提高了软件的质量和稳定性。
-
增强团队协作:促进团队成员之间的沟通和协作,提高团队的整体效率。
常见的 CI/CD 工具包括 Jenkins、GitLab CI/CD、Travis CI 等。这些工具可以帮助团队实现自动化的构建、测试和部署流程。
2 git工具使用
2.1 git简介
Git 是一个分布式版本控制系统,被广泛用于软件开发中,以管理代码的版本和变更。 主要特点:
-
分布式:
-
每个开发者都有完整的代码仓库副本,这使得开发者可以在离线状态下进行工作,并且在网络出现问题时也不会影响开发。
-
即使中央服务器出现故障,开发者仍然可以在本地进行开发和查看项目历史。
-
-
高效的分支管理:
-
Git 中的分支创建和切换非常快速和简单。开发人员可以轻松地创建新的分支来进行新功能的开发或修复 bug,而不会影响主分支。
-
合并分支也相对容易,可以使用多种合并策略来满足不同的需求。
-
-
快速的版本回退:
-
如果发现某个版本存在问题,可以快速回退到之前的版本。
-
可以查看每个版本的详细变更记录,方便了解代码的演进过程。
-
-
强大的提交管理:
-
每个提交都有一个唯一的标识符,可以方便地引用和查看特定的提交。
-
提交可以包含详细的提交信息,描述本次提交的更改内容。
-
-
支持协作开发:
-
开发者可以将自己的更改推送到远程仓库,供其他开发者拉取和合并。
-
可以处理多个开发者同时对同一文件进行修改的情况,通过合并冲突解决机制来确保代码的完整性。
-
Git必看秘籍:https://git-scm.com/book/zh/v2https://git-scm.com/book/zh/v2
2.2 git 工作流程
Git 有三种状态:已提交(committed)、已修改(modified) 和 已暂存(staged)。
-
已修改表示修改了文件,但还没保存到数据库中。
-
已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。
-
已提交表示数据已经安全地保存在本地数据库中。
这会让我们的 Git 项目拥有三个阶段:工作区、暂存区以及 Git 目录。
3 部署git
3.1 安装git
# yum search git
# yum install git -y# 设置命令补全
# echo "source /usr/share/bash-completion/completions/git" >> ~/.bashrc
# source ~/.bashrc
3.2 初始化
获取 Git 仓库通常有两种方式:
-
将尚未进行版本控制的本地目录转换为 Git 仓库。
-
从其它服务器克隆 一个已存在的 Git 仓库。比如: git clone
初始化版本库
# mkdir git
# cd git/
# git init
提示: 使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示: 配置使用初始分支名,并消除这条警告,请执行:
提示:
提示: git config --global init.defaultBranch <名称>
提示:
提示: 除了 'master' 之外,通常选定的名字有 'main'、'trunk' 和 'development'。
提示: 可以通过以下命令重命名刚创建的分支:
提示:
提示: git branch -m <name>
已初始化空的 Git 仓库于 /root/git/.git/# ls -a
. .. .git
# ls .git
branches config description HEAD hooks info objects refs# 设置用户信息
# git config --global user.name "user1"
# git config --global user.email "user1@user1.org"# 查看当前文件状态
# git status
位于分支 master尚无提交无文件要提交(创建/拷贝文件并使用 "git add" 建立跟踪)# 简化输出
# git status -s
注意:.git目录是git跟踪管理版本库的,没事别瞎溜达
4 git的使用方法
4.1 git的常用方法
# echo test > README.md
# ls
README.md
# git status
位于分支 master尚无提交未跟踪的文件:(使用 "git add <文件>..." 以包含要提交的内容)README.md提交为空,但是存在尚未跟踪的文件(使用 "git add" 建立跟踪)
# git status -s
?? README.md
# ??新建文件未添加至暂存区# 将文件添加至暂存区
# git add README.md
# git status -s
A README.md
# 左A表示文件已经添加至暂存区# 将文件添加至版本库
# git commit -m "add README.md"
[master(根提交) 1a09954] add README.md1 file changed, 1 insertion(+)create mode 100644 README.md
# git status -s
# 无任何显示表示暂存区的文件已经提交至版本库# 修改工作区文件
# vim README.md
# cat README.md
test
test2
# git status -sM README.md
# 右M表示文件在工作区已经被修改# 撤销工作区的修改
# git checkout -- README.md
# cat README.md
test# 将修改提交至暂存区
# echo test3 >> README.md
# git add README.md
# git status -s
M README.md
# 左M表示修改已经提交至暂存区# 从暂存区撤销工作区的修改内容
# git restore --staged README.md
# git status -sM README.md# 重新提交工作区文件
# git add README.md
# git status -s
M README.md
# 将暂存区文件更新至版本库
# git commit -m "updata v1"
[master c47522a] updata v11 file changed, 1 insertion(+)
# git status -s
# 无任何内容显示表示文件已经更新至版本库# 更新文件
# echo test4 >> README.md
# git add README.md
# git status -s
M README.md
# echo test5 >> README.md
# git status -s
MM README.md
# MM表示文件内容有一部分在暂存区,一部分在工作区并没有提交# 提交暂存区内容至版本库
[root@CICD-node1 git]# git commit -m "update v2"
[master 1e72ae7] update v21 file changed, 1 insertion(+)
[root@CICD-node1 git]# git status -sM README.md
# 右M还在,说明工作区的内容并没提交至版本库# 查看已暂存和未暂存的修改变化
# echo test6 >> README.md
# git diff
diff --git a/README.md b/README.md
index c335aa4..3501411 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,5 @@testtest3test4
+test5
+test6
# git add README.md
# echo test7 >> README.md
# git diff
diff --git a/README.md b/README.md
index 3501411..8886a53 100644
--- a/README.md
+++ b/README.md
@@ -3,3 +3,4 @@ test3test4test5test6
+test7# 跳过使用暂存区,直接提交文件至版本库,只能在提交过的版本库中存在的文件使用此方法,如果文件状态是??不能使用此方法
# git commit -a -m "update v3"
[master b392ea9] update v31 file changed, 3 insertions(+)
[root@CICD-node1 git]# git status -s# 撤销工作区中删除的动作
# touch lee.txt
# git add lee.txt
# git commit -m "add lee.txt"
[master a15e1d8] add lee.txt1 file changed, 0 insertions(+), 0 deletions(-)create mode 100644 lee.txt
# git status -s
# ls
lee.txt README.md# 删除工作区的文件
# rm -rf lee.txt
# git status -sD lee.txt
# 右D表示文件在工作区中被删除
# 撤销删除动作
# git checkout -- lee.txt
# ls
lee.txt README.md
# 被删除的文件已经恢复至工作区# 删除版本库中的文件
# git rm lee.txt
rm 'lee.txt'
# git status -s
D lee.txt
# 左D表示删除版本库文件的动作已经提交至暂存区
# 执行删除动作
# git commit -m "delete lee.txt"
[master 8f300ad] delete lee.txt1 file changed, 0 insertions(+), 0 deletions(-)delete mode 100644 lee.txt
# git status -s
# 没有内容表示删除动作已经执行# 查看操作日志
[root@CICD-node1 git]# git log
commit 8f300ad9cfd3658af46b322d17c767f715ada568 (HEAD -> master)
Author: user1 <user1@user1.org>
Date: Sun Aug 31 02:30:20 2025 -0400delete lee.txtcommit a15e1d850643119c5b0285b0bb154fa8aff09a99
Author: user1 <user1@user1.org>
Date: Sun Aug 31 02:27:54 2025 -0400add lee.txtcommit b392ea994eab00300f49b6f8e24a8e88efe50ba9
Author: user1 <user1@user1.org>
Date: Sun Aug 31 02:20:52 2025 -0400update v3commit 1e72ae7c5d6cf1454461d9558cb3df6c626f6690
Author: user1 <user1@user1.org>
Date: Sun Aug 31 02:17:55 2025 -0400update v2commit c47522aae068eee19ac0ccc56c5b45cdf61b37fc
Author: user1 <user1@user1.org>
Date: Sun Aug 31 01:58:24 2025 -0400updata v1commit 1a09954cdb974a8ff802a0c6875c65b50730a12e
Author: user1 <user1@user1.org>
Date: Sun Aug 31 01:54:40 2025 -0400add README.md# 查看提交的动作
[root@CICD-node1 git]# git reflog
8f300ad (HEAD -> master) HEAD@{0}: commit: delete lee.txt
a15e1d8 HEAD@{1}: commit: add lee.txt
b392ea9 HEAD@{2}: commit: update v3
1e72ae7 HEAD@{3}: commit: update v2
c47522a HEAD@{4}: commit: updata v1
1a09954 HEAD@{5}: commit (initial): add README.md# 版本回退至删除之前
# git reset --hard a15e1d8
HEAD 现在位于 a15e1d8 add lee.txt
git常用方法总结:
git add 工作区的文件:将工作区文件添加至在存取
git status -s :查看文件状态
?? 文件名:工作区新创建的文件,未添加至暂存区
A 文件名:已添加至暂存区M 文件名:右M表示文件在工作区已经被修改
M 文件名:左M表示文件已经从工作区提交至暂存区
MM 文件名:MM表示一部分修改在工作区,一部分修改在暂存区D 文件名:右D表示文件在工作区被删除
D 文件名:左D表示文件文件删除动作已被提交至暂存区
git commit -m "add 文件名":将暂存区文件添加至版本库
git checkout -- 文件名:撤销工作区被修改或删除的文件内容
git restore --staged 文件名:从暂存区撤销修改
git commit -m "update v1":更新版本至版本库
git diff :查看暂存区和未暂存的修改变化
git commit -a -m "update v3":跳过暂存区直接提交至版本库,只能提交在版本库存在过的文件,文件状态为??的不能使用此方法
git rm 文件名:将删除版本库中的文件命令提交至暂存区
git commit -m "delete 文件名":执行暂存区的删除动作
git log:查看操作日志
git reflog:查看提交动作
git reset --hard 提交动作中的ID:在删除版本库文件后可以选择版本回退
4.2 git对于文件如何忽略
在做软件开发时对源码编译会产生一些临时文件,我们在提交时需要忽略这些临时文件
# mkdir dir1/
# touch dir1/.file2
# git status -s
?? .file1
?? dir1/# echo .file1 > .gitignore
# git status -s
?? .gitignore
?? dir1/
# echo ".*" > .gitignore
# git status -s
# 没有任何显示,表示临时文件忽略成功
注意:git 默认不忽略 .gitignore 文件
5 gitlab代码仓库
5.1 gitlab简介
-
GitLab 是一个用于仓库管理系统的开源项目,使用 Git 作为代码管理工具,并在此基础上搭建起来的 web 服务。
-
GitLab 具有很多功能,比如代码托管、持续集成和持续部署(CI/CD)、问题跟踪、合并请求管理等。它可以帮助开发团队更好地协作开发软件项目,提高开发效率和代码质量。
官网:https://about.gitlab.com/install/
中文站点: GitLab下载安装_GitLab安装和配置_GitLab最新中文官网免费版下载-极狐GitLab
官方包地址:gitlab/gitlab-ce - Packages · packages.gitlab.com
5.2 gitlab 的部署实施
5.2.1 部署gitlab
部署gitlab需要内存大于4G
#在安装包之前需配置好软件仓库来解决依赖性
# yum install -y curl policycoreutils-python-utils openssh-server perl# yum install gitlab-ce-17.1.6-ce.0.el9.x86_64.rpm -y
5.2.2 配置gitlab
# 修改配置文件
# cd /etc/gitlab/
# ls
gitlab.rb
# vim gitlab.rb
32 external_url 'http://192.168.36.40'# 修改配置文件后需利用gitlab-crt来生效
# gitlab-ctl reconfigure# 执行命令成功后会把所有组件全部启动起来
5.2.3 登陆gitlab
用户名默认为 root
。如果在安装过程中指定了初始密码,则用初始密码登录,如果未指定密码,则系统会随机生成一个密码并存储在 /etc/gitlab/initial_root_password
文件中, 查看随机密码并使用 root
用户名登录。
注意:出于安全原因,24 小时后,/etc/gitlab/initial_root_password
会被第一次 gitlab-ctl reconfigure
自动删除,因此若使用随机密码登录,建议安装成功初始登录成功之后,立即修改初始密码。
#查看原始密码
# cat /etc/gitlab/initial_root_password
登录界面
设置语言
修改密码
5.3 在gitlab中新建项目
创建空白项目
选择项目配置
添加密钥
[root@gitlab .ssh]# ls
authorized_keys known_hosts known_hosts.old
[root@gitlab .ssh]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:OGFUWLGFjfQUX6DUV6NNAF25QgRBO7817xOGMwwYcCY root@gitlab
The key's randomart image is:
+---[RSA 3072]----+
| .E*B*BB++=o|
| .. *B.oo+=..|
| o . =ooo ..|
| . o . .o. . |
| o S o.oo |
| . =ooo|
| .+ o|
| o |
| o|
+----[SHA256]-----+
[root@gitlab .ssh]# ls
authorized_keys id_rsa id_rsa.pub known_hosts known_hosts.old
[root@gitlab .ssh]# cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCyF7jy4LI8SJd6/GoEt9Ag/kS+E9Bl5Z/ccLrscwVoGAexkjGvP/Tb/razqZR4LBV4qKJUITlwaORNYi9BOSLoSl2d/M5nAcQ+2UOHARAkj5J6aGuCHisPTXvZ0DeVT89DYvA93BpA/p90bhqgeZkj82Yxww4IeUeylptEQNuWtUrOC2HmzOsZ2FOS54mdLM+n26d+pBBnOXXr4GAfGKsOMqB9xBvO2Yu4C1E84EZZ+RkmCkBLA+6lTrtEpeB5dakwexVn4Hd8tLWcl8rXJicHuKPZjgMGgKJyPqG2KU9gX6SCbbHBlPgyDvkQr4qWkE/oyyL72mqtVpThnGc4C+MAn7JlSU/iOd7utzzMuUCDrwlWHbdLs3bJgbU/CmvFc8mBY7ppKrUPLxl7lWLv8GRg5DXtZBCFHIKoaL1me+AAUa4VXmvZSagGmyNP//341YkwmV6DLS41IYa4/DvuOjvRWoBJsCoSZQZGG3S1UH5e5oNh7JcUFskcbpQYNmzqMxk= root@gitlab
上传公钥到gitlab中
下载项目
# yum install git -y
# git clone git@192.168.36.40:root/test.git
提交文件至 gitlab 仓库
# cd test/
# ls
README.md
# git remote -v
origin git@192.168.36.40:root/test.git (fetch)
origin git@192.168.36.40:root/test.git (push)
# echo test > test
# git add test
# git config --global user.name "user1"
# git config --global user.email "user1@user1.org"
[root@gitlab test]# git status -s
A test
# git commit -m "add test"
[main ee84548] add test1 file changed, 1 insertion(+)create mode 100644 test
# git status -s
# git push -u origin main
注意:执行 git push -u origin main
命令的作用是将本地 main
分支的提交推送到到远程仓库 origin
,并设置 origin/main
为本地 main
分支的上游(upstream)分支(后续可直接用 git push
推送)
推送到仓库的test文件
test文件中包含的测试代码
6 Jenkins
6.1 jenkins 简介
-
Jenkins是开源CI&CD软件领导者, 提供超过1000个插件来支持构建、部署、自动化, 满足任何项目的需要。
-
Jenkins用Java语言编写,可在Tomcat等流行的servlet容器中运行,也可独立运行。
CI(Continuous integration持续集成)持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。
CD(Continuous Delivery持续交付) 是在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境(类生产环境)中。
6.2 部署 jenkins
软件下载:Download and deploy
详细部署Jenkins请参考官网!
jenkins需要部署在新的虚拟机中,可能会与gitlab冲突
注意:jenkins需要部署在新的虚拟机中,建议最少4G内存,4核心cpu
# 备份并移除红帽官方源
# mv /etc/yum.repos.d/redhat.repo /etc/yum.repos.d/redhat.repo.bak
# yum clean all
# yum makecache# 安装官方源
# wget -O /etc/yum.repos.d/jenkins.repo \https://pkg.jenkins.io/redhat-stable/jenkins.repo
# cat /etc/yum.repos.d/jenkins.repo
[jenkins]
name=Jenkins-stable
baseurl=http://pkg.jenkins.io/redhat-stable
gpgcheck=0#安装依赖包
# yum install fontconfig java-21-openjdk -y# 安装jenkins
# yum install jenkins -y
# systemctl daemon-reload#设置jenkins开机自启
# systemctl enable --now jenkins.service#查看原始密码
[root@jenkins ~]# cat /var/lib/jenkins/secrets/initialAdminPassword
部署插件
建议修改admin的密码,在admin的设置中修改即可
6.3 jenkins 与gitlab的整合
1.新建ltem
2.在Jenkins主机创建密钥文件
3.在gitlab主机添加Jenkins主机的公钥
4.在Jenkins页面添加Jenkins私钥
5.Jenkins主机安装git
6.设置Jenkins检测gitlab频率
7.修改设置,不验证
添加完成后报错依然存在,因为ssh首次连接主机是需要签名认证,需要手动输入yes
8.所有设定完成,报错消失
注意在Jenkins主机修改参数也可跳过验证
[root@jenkins ~]# vim /etc/ssh/ssh_config
Host *StrictHostKeyChecking no
9.jenkins与gitlab整合成功
6.4 genkins 中 gitlab 触发器的部署与使用
在 Jenkins 中配置 GitLab 触发器可以实现代码提交或合并请求时自动触发 Jenkins 流水线
6.4.1 安装插件
如果需要使用gitlab触发器需要安装gitlab插件。目前使用官方源下载比较吃力,可以直接本地部署插件即可
选择搜索到的gitlab点击安装
6.4.2.部署自动触发
插件加载完毕后在jenkins中选择之前构建的项目并配置自动触发
在gitlab中设定
重新添加
测试效果
自动触发测试
[root@gitlab ~]# cd gitlab/
[root@gitlab gitlab]# ls
test
[root@gitlab gitlab]# cd test/
[root@gitlab test]# ls
README.md test
[root@gitlab test]# vim test
[root@gitlab test]# cat test
test
test1
[root@gitlab test]# git add test
[root@gitlab test]# git commit -m "test v1"
[main 161ae20] test v11 file changed, 1 insertion(+)
[root@gitlab test]# git push -u origin main
枚举对象中: 5, 完成.
对象计数中: 100% (5/5), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (2/2), 完成.
写入对象中: 100% (3/3), 266 字节 | 266.00 KiB/s, 完成.
总共 3(差异 0),复用 0(差异 0),包复用 0(来自 0 个包)
To 192.168.36.40:root/test.gitee84548..161ae20 main -> main
分支 'main' 设置为跟踪 'origin/main'。
gitlab接收到修改
自动触发你所构建的命令ls -l
CICD处理流程:
程序员代码写好后将代码推送到gitlab仓库,gitlab接收到代码文件后将事件推送给Jenkins,Jenkins根据你设定的构建命令内容去处理上传的代码文件
7 持续集成与持续交付企业示例
为了让容器构建镜像可以持续集成并自动上传到harbor仓库,业务主机通过持续交付自动从仓库中下载镜像最近版本并实现业务更新
7.1 在jenkins中添加registry-node
1.docker节点初始化
节点名称 | IP | 硬件资源 |
docker-node | 192.168.36.60/24 | 内存4G,1个CUP4个核心 |
2.添加各个节点/etc/hosts文件,做域名解析
# vim /etc/hosts
192.168.36.60 docker-node
192.168.36.50 Jenkins
192.168.36.40 gitlabt
192.168.36.100 harbor.timinglee.org
3.在docker-node节点中安装docker和java环境并配置其可以从仓库中下载镜像
harbor仓库的搭建与配置请参考:k8s简介及部署方法-CSDN博客
# 配置docker源仓库
# vim /etc/yum.repos.d/docker.repo
[docker]
name = docker
baseurl = https://mirrors.aliyun.com/docker-ce/linux/rhel/9/x86_64/stable/
gpgcheck = 0# 安装docker、java、git
# yum install docker-ce fontconfig java-21-openjdk git -y# 从harbor仓库中把认证文件复制到当前主机
# mkdir /etc/docker/certs.d/harbor.timinglee.org/ -p
# scp root@192.168.36.100:/data/certs/timinglee.org.crt /etc/docker/certs.d/harbor.timinglee.org/ca.crt# 配置harbor仓库地址
# vim /etc/docker/daemon.json
{"registry-mirrors":["https://harbor.timinglee.org"]
}# systemctl enable --now docker.service
# 登录harbor仓库
# docker login harbor.timinglee.org# 测试拉取镜像是否成功
# docker pull harbor.timinglee.org/nginx/nginx
4.部署jenkins节点
7.2 配置构建节点
1.在harbor仓库主机中安装java环境及git
# yum install fontconfig java-21-openjdk git -y
2.在jenkins中安装构建插件
3.设置jenkins的容器构建规则
4.将构建好的镜像上传至harbor仓库
7.3.测试镜像构建
在gitlab中建立Dockerfile和index.html
# vim index.html
www.timinglee.org v1# vim Dockerfile
FROM nginx
COPY index.html /usr/share/nginx/html
构建的镜像已经上传至harbor仓库
7.4.在业务节点docker-node上自动运行构建好的镜像生成容器
测试自动构建功能是否到达预期效果
到此一个简单的流水线已经完成!
8 CICD流水线总结
8.1 代码编写与上传
- 在本地主机中编写
Dockerfile
:定义 Docker 镜像的构建规则,例如指定基础镜像、安装应用依赖、复制应用代码等。 - 将代码上传至 GitLab:开发人员将编写好的应用代码和
Dockerfile
提交并推送到 GitLab 仓库中进行版本管理。
8.2 GitLab 触发 Jenkins 构建
- 设置 GitLab 钩子(Webhook):在 GitLab 仓库的设置中,配置 Webhook,指定 Jenkins 服务器的一个特定接口地址。当有代码推送到指定分支(如
master
分支)时,GitLab 会发送一个 HTTP POST 请求到该接口,触发 Jenkins 构建任务。
8.3 Jenkins 构建镜像
- Jenkins 接收触发请求:Jenkins 的相关插件(如 Git plugin)监听到来自 GitLab 的请求后,开始执行构建任务。
- 拉取代码:Jenkins 从 GitLab 仓库中拉取最新的代码到 Jenkins 工作区。
- 构建 Docker 镜像:Jenkins 调用 Docker 命令(如
docker build
),根据Dockerfile
构建 Docker 镜像。构建过程中,Jenkins 可以配置环境变量、选择构建的镜像标签等。
8.4 Jenkins 上传镜像至 Harbor
- 配置 Harbor 认证信息:在 Jenkins 中配置 Harbor 仓库的认证信息,如用户名、密码等。
- 登录 Harbor:在构建完成后,Jenkins 使用配置的认证信息登录 Harbor 仓库。
- 推送镜像:Jenkins 将构建好的 Docker 镜像打上合适的标签(如版本号标签),然后使用
docker push
命令将镜像推送到 Harbor 仓库中指定的项目或命名空间下。
8.5 Jenkins 在业务节点触发业务
- 配置业务节点连接:在 Jenkins 中配置与业务节点(运行 Docker 的服务器)的连接,比如通过 SSH 等方式。
- 触发业务任务:Jenkins 向业务节点发送指令,通知业务节点有新的镜像可用。可以通过执行特定的脚本或命令来触发。
8.6 业务节点下载并启动镜像
- 接收触发任务:业务节点监听到来自 Jenkins 的触发信号。
- 登录 Harbor:业务节点使用配置好的认证信息登录 Harbor 仓库。
- 下载镜像:业务节点从 Harbor 仓库中拉取最新的 Docker 镜像。
- 启动容器:业务节点使用
docker run
命令,根据业务需求配置容器的参数(如端口映射、环境变量、数据卷挂载等),启动 Docker 容器,使应用在容器中运行。