全网最全的Gitlab CI/CD自动化部署的介绍和教程,使用GitLab CI/CD自动化热部署SpringBoot或maven项目,GitLab CI/CD的Kubernetes集群的集成
1. 引言
在上家公司工作时,我提交代码到gitlab
上。主管在合并代码时,会自动化部署到服务器上,当时对这个很感兴趣,于是潜心研究gitlab
的自动化部署原理。
2. GitLab CI/CD概要
GitLab CI/CD
是一个内置在GitLab
中的工具,用于通过持续方法进行软件开发:
-
Continuous Integration (CI)
持续集成 -
Continuous Delivery (CD)
持续交付 -
Continuous Deployment (CD)
持续部署
持续集成的工作原理是将小的代码块推送到Git
仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中。
持续交付和部署相当于更进一步的CI
,可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。
这些方法使得可以在开发周期的早期发现bugs
和errors
,从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。
GitLab CI/CD
由一个名为.gitlab-ci.yml
的文件进行配置,改文件位于仓库的根目录下。文件中指定的脚本由GitLab Runner
执行。
3. GitLab CI/CD详述
软件开发的持续方法基于自动执行脚本,以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码,他们几乎不需要人工干预,甚至根本不需要干预。
它涉及到在每次小的迭代中就不断地构建、测试和部署代码更改,从而减少了基于已经存在bug
或失败的先前版本开发新代码的机会。
Continuous Integration
(持续集成)
假设一个应用程序,其代码存储在GitLab
的Git
仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送,你都可以创建一组脚本来自动构建和测试你的应用程序,从而减少了向应用程序引入错误的机会。这种做法称为持续集成,对于提交给应用程序(甚至是开发分支)的每项更改,它都会自动连续进行构建和测试,以确保所引入的更改通过你为应用程序建立的所有测试,准则和代码合规性标准。
Continuous Deliver
y(持续交付)
持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试,而且,尽管部署是手动触发的,但作为一个附加步骤,它也可以连续部署。此方法可确保自动检查代码,但需要人工干预才能从策略上手动触发以必输此次变更。
Continuous Deployment
(持续部署)
与持续交付类似,但不同之处在于,你无需将其手动部署,而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。
2.1 GitLab CI/CD如何工作
为了使用GitLab CI/CD
,你需要一个托管在GitLab
上的应用程序代码库,并且在根目录中的.gitlab-ci.yml
文件中指定构建、测试和部署的脚本。
在这个文件中,你可以定义要运行的脚本,定义包含的依赖项,选择要按顺序运行的命令和要并行运行的命令,定义要在何处部署应用程序,以及指定是否 要自动运行脚本或手动触发脚本。
为了可视化处理过程,假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。
一旦你已经添加了.gitlab-ci.yml
到仓库中,GitLab
将检测到该文件,并使用名为GitLab Runner
的工具运行你的脚本。该工具的操作与终端类似。
这些脚本被分组到jobs
,它们共同组成一个pipeline
。一个最简单的.gitlab-ci.yml
文件可能是这样的:
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version 6
before_script
属性将在运行任何内容之前为你的应用安装依赖,一个名为run-test
的job
(作业)将打印当前系统的Ruby
版本。二者共同构成了在每次推送到仓库的任何分支时都会被触发的pipeline
(管道)。
GitLab CI/CD
不仅可以执行你设置的job
,还可以显示执行期间发生的情况,正如你在终端看到的那样:
为你的应用创建策略,GitLab
会根据你的定义来运行pipeline
。你的管道状态也会由GitLab
显示:
最后,如果出现任何问题,可以轻松地回滚所有更改:
2.2 基本CI/CD工作流程
一旦你将提交推送到远程仓库的分支上,那么你为该项目设置的CI/CD
管道将会被触发。
GitLab CI/CD
通过这样做:
- 运行自动化脚本(串行或并行) 代码
Review
并获得批准
-
构建并测试你的应用
-
就像在你本机中看到的那样,使用Review Apps预览每个合并请求的更改
-
代码
Review
并获得批准 -
合并
feature
分支到默认分支,同时自动将此次更改部署到生产环境 -
如果出现问题,可以轻松回滚
通过GitLab UI
所有的步骤都是可视化的:
2.3 深入了解CI/CD基本工作流程
如果我们深入研究基本工作流程,则可以在DevOps
生命周期的每个阶段看到GitLab
中可用的功能,如下图所示:
Verify
-
通过持续集成自动构建和测试你的应用程序
-
使用
GitLab
代码质量(GitLab Code Quality
)分析你的源代码质量 -
通过浏览器性能测试(
Browser Performance Testing
)确定代码更改对性能的影响 -
执行一系列测试,比如
Container Scanning
,Dependency Scanning
,JUnit tests
-
用
Review Apps
部署更改,以预览每个分支上的应用程序更改
Package
-
用
Container Registry
存储Docker
镜像 -
用
NPM Registry
存储NPM
包 -
用
Maven Repository
存储Maven artifacts
-
用
Conan Repository
存储Conan
包
Release
-
持续部署,自动将你的应用程序部署到生产环境
-
持续交付,手动点击以将你的应用程序部署到生产环境
-
用
GitLab Pages
部署静态网站 -
仅将功能部署到一个
Pod
上,并让一定比例的用户群通过Canary Deployments
访问临时部署的功能(PS:即灰度发布) -
在
Feature Flags
之后部署功能 -
用
GitLab Releases
将发布说明添加到任意Git tag
-
使用
Deploy Boards
查看在Kubernetes
上运行的每个CI
环境的当前运行状况和状态 -
使用
Auto Deploy
将应用程序部署到Kubernetes
集群中的生产环境
使用GitLab CI/CD
,还可以:
-
通过
Auto DevOps
轻松设置应用的整个生命周期 -
将应用程序部署到不同的环境
-
安装你自己的
GitLab Runner
-
Schedule pipelines
-
使用安全测试报告(
Security Test reports
)检查应用程序漏洞
3. GitLab CI/CD快速开始
.gitlab-ci.yml
文件告诉GitLab Runner
要做什么。
一个简单的管道通常包括三个阶段:build
、test
、deploy
。
管道在 CI/CD > Pipelines
页面。
3.1. 创建一个.gitlab-ci.yml 文件
通过配置.gitlab-ci.yml
文件来告诉CI
要对你的项目做什么。它位于仓库的根目录下。
仓库一旦收到任何推送,GitLab
将立即查找.gitlab-ci.ym
l文件,并根据文件的内容在Runner
上启动作业。
下面是一个Ruby
项目配置例子:
image: "ruby:2.5"
before_script:
- apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
- ruby -v
- which ruby
- gem install bundler --no-document
- bundle install --jobs $(nproc) "${FLAGS[@]}"
rspec:
script:
- bundle exec rspec
rubocop:
script:
- bundle exec rubocop
上面的例子中,定义里两个作业,分别是rspec
和rubocop
,在每个作业开始执行前,要先执行before_script
下的命令。
3.2. 推送 .gitlab-ci.yml 到 GitLab
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
3.3. 配置一个Runner
在GitLab
中,Runner
运行你定义在.gitlab-ci.yml
中的作业(job)。
一个Runner
可以是一个虚拟机、物理机、docker
容器,或者一个容器集群。
GitLab
与Runner
之间通过API
进行通信,因此只需要Runner所在的机器有网络并且可以访问GitLab
服务器即可。
你可以去Settings ➔ CI/CD
看是否已经有Runner
关联到你的项目,设置Runner
简单又直接 。
3.4. 查看 pipeline 和 jobs的状态
在成功配置Runner
以后,你应该可以看到你最近的提交的状态 :
为了查看所有jobs
,你可以去Pipelines ➔ Jobs
页面 :
通过点击作业的状态,你可以看到作业运行的日志:
回顾一下:
-
首先,定义
.gitlab-ci.yml
文件。在这个文件中就定义了要执行的job
和命令。 -
接着,将文件推送至远程仓库。
-
最后,配置
Runner
,用于运行job
。
4. Auto DevOps
Auto DevOps
提供了预定义的CI/CD
配置,使你可以自动检测,构建,测试,部署和监视应用程序。借助CI/CD
最佳实践和工具,Auto DevOps
旨在简化成熟和现代软件开发生命周期的设置和执行。
借助Auto DevOps
,软件开发过程的设置变得更加容易,因为每个项目都可以使用最少的配置来完成从验证到监视的完整工作流程。只需推送你的代码,GitLab
就会处理其他所有事情。这使得启动新项目更加容易,并使整个公司的应用程序设置方式保持一致。
如下例子展示了如何使用Auto DevOps
将GitLab.com
上托管的项目部署到Google Kubernetes Engine
。
示例中会使用GitLab
原生的Kubernetes
集成,因此不需要再单独手动创建Kubernetes
集群。
本例将创建并部署一个从GitLab
模板创建的应用。
4.1 从GitLab模板创建项目
在创建Kubernetes
集群并将其连接到GitLab
项目之前,你需要一个Google Cloud Platform
帐户。
下面使用GitLab
的项目模板来创建一个新项目:
给项目起一个名字,并确保它是公有的:
4.2 从GitLab模板创建Kubernetes集群
点击Add Kubernetes cluster
按钮,或者Operations > Kubernetes
:
安装Helm
, Ingress
, 和Prometheus
:
4.3 启用Auto DevOps (可选)
Auto DevOps 默认是启用的。
导航栏Settings > CI/CD > Auto DevOps
,勾选 Default to Auto DevOps pipeline
。
最后选择部署策略:
一旦你已经完成了以上所有的操作,那么一个新的pipeline
将会被自动创建。为了查看pipeline
,可以去 CI/CD > Pipelines
:
4.4 部署应用
到目前为止,你应该看到管道正在运行,但是它到底在运行什么呢?
管道内部分为4个阶段,我们可以查看每个阶段有几个作业(构建 -> 测试 -> 部署 -> 性能测试
)在运行,如下图:
现在,应用已经成功部署,让我们通过浏览器查看。
首先,导航到Operations > Environments
:
在Environments
中,可以看到部署的应用的详细信息。在最右边有三个按钮,我们依次来看一下:
-
第一个图标将打开在生产环境中部署的应用程序的
URL
。这是一个非常简单的页面,但重要的是它可以正常工作! -
紧挨着第二个是一个带小图像的图标,
Prometheus
将在其中收集有关Kubernetes
集群以及应用程序如何影响它的数据(在内存/ CPU使用率,延迟等方面)。
- 第三个图标是
Web
终端,它将在运行应用程序的容器内打开终端会话。
5. 示例
5.1 GitLab CI/CD部署Spring Boot应用
.gitlab-ci.yml
image: java:8
stages:
- build
- deploy
build:
stage: build
script: ./mvnw package
artifacts:
paths:
- target/demo-0.0.1-SNAPSHOT.jar
production:
stage: deploy
script:
- curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
- ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
- ./cf push
only:
- master
5.2 GitLab CI/CD部署maven应用
.gitlab-ci.yml
image: maven:latest
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- .m2/repository/
- target/
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
script:
- mvn $MAVEN_CLI_OPTS test
deploy:
stage: deploy
script:
- mvn $MAVEN_CLI_OPTS deploy
only:
- master
6. 参考文档
相关文章
- Java项目毕业设计:基于springboot+vue的电影视频网站系统「建议收藏」
- Spring学习笔记(二十七)——springboot集成MyBatis-Plus学习总结
- 如何创建springboot项目[通俗易懂]
- 实战:springboot整合rabbitMQ「建议收藏」
- idea配置运行springboot项目_java项目框架搭建流程
- SpringBoot整合Redis[哨兵版]
- springboot启动监听线程_Springboot启动流程
- springboot启动不了也不报错的解决方案「建议收藏」
- idea创建springboot父子工程_Springboot框架
- springboot到底是什么_Springboot注解
- springboot集成sqlite数据库
- SpringBoot 项目[禁止OPTIONS等不安全的请求] 增加 OPTIONS 不安全请求处理
- kafka 结合springboot实战--第二节
- SpringBoot 多环境设置 active: @profileActive@
- springboot访问静态资源404的解决办法
- Mybatis-Plus入门案例(springboot项目实现)
- SpringBoot 超时设置详解编程语言
- springboot-zuul详解编程语言