目录
1. 前言
在现代软件开发中,采用devops(development和operations的结合)方法已成为提高效率、加速交付和提升产品质量的重要手段。devops不仅仅是一种工具或技术的集合,更是一种文化和理念的融合,旨在通过自动化和协作来消除传统开发与运维之间的隔阂,实现持续交付和持续集成。
本系列文章将深入探讨devops的各个方面,从基础概念到实际工具的使用,为读者提供全面的指导和实用的建议。我们将详细介绍各种工具如git、gitlab、docker、jenkins、maven等的安装和配置过程,帮助读者快速掌握并应用这些关键技术,从而建立高效的软件开发和交付流程。
2. devops(详细介绍)
软件开发最开始是由两个团队组成:
这看似两个目标不同的团队需要协同完成一个软件的开发。
在开发团队指定好计划并完成coding后,需要提供到运维团队。
运维团队向开发团队反馈需要修复的bug以及一些需要返工的任务。
这时开发团队需要经常等待运维团队的反馈。这无疑延长了事件并推迟了整个软件开发的周期。
会有一种方式,在开发团队等待的时候,让开发团队转移到下一个项目中。等待运维团队为之前的代码提供反馈。
可是这样就意味着一个完整的项目需要一个更长的周期才可以开发出最终代码。
基于现在的互联网现状,更推崇敏捷式开发,这样就导致项目的迭代速度更快,但是由于开发团队与运维团队的沟通问题,会导致新版本上线的时间成本很高。这又违背的敏捷式开发的最初的目的。
那么如果让开发团队和运维团队整合到成一个团队,协同应对一套软件呢?这就被称为devops。
devops,字面意思是development &operations的缩写,也就是开发&运维。
虽然字面意思只涉及到了开发团队和运维团队,其实qa测试团队也是参与其中的。
网上可以查看到devops的符号类似于一个无穷大的符号
devops |
---|
|
这表明devops是一个不断提高效率并且持续不断工作的过程
devops的方式可以让公司能够更快地应对更新和市场发展变化,开发可以快速交付,部署也更加稳定。
核心就在于简化dev和ops团队之间的流程,使整体软件开发过程更快速。
整体的软件开发流程包括:
-
plan:开发团队根据客户的目标制定开发计划
-
code:根据plan开始编码过程,需要将不同版本的代码存储在一个库中。
-
build:编码完成后,需要将代码构建并且运行。
-
test:成功构建项目后,需要测试代码是否存在bug或错误。
-
deploy:代码经过手动测试和自动化测试后,认定代码已经准备好部署并且交给运维团队。
-
operate:运维团队将代码部署到生产环境中。
-
monitor:项目部署上线后,需要持续的监控产品。
-
integrate:然后将监控阶段收到的反馈发送回plan阶段,整体反复的流程就是devops的核心,即持续集成、持续部署。
为了保证整体流程可以高效的完成,各个阶段都有比较常见的工具,如下图:
软件开发过程&涉及工具 |
---|
|
最终可以给devops下一个定义:devops 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。
3. code阶段工具
在code阶段,我们需要将不同版本的代码存储到一个仓库中,常见的版本控制工具就是svn或者git,这里我们采用git作为版本控制工具,gitlab作为远程仓库。
3.1 git安装
https://git-scm.com/(傻瓜式安装)
3.2 gitlab安装
单独准备服务器,采用docker安装
-
查看gitlab镜像
docker search gitlab
-
拉取gitlab镜像
docker pull gitlab/gitlab-ce
-
准备docker-compose.yml文件
version: '3.1' services: gitlab: image: 'gitlab/gitlab-ce:latest' container_name: gitlab restart: always environment: gitlab_omnibus_config: | external_url 'http://192.168.11.11:8929' gitlab_rails['gitlab_shell_ssh_port'] = 2224 ports: - '8929:8929' - '2224:22' volumes: - './config:/etc/gitlab' - './logs:/var/log/gitlab' - './data:/var/opt/gitlab'
-
启动容器(需要稍等一小会……)
docker-compose up -d
-
访问gitlab首页
首页 |
---|
|
|
-
查看root用户初始密码
docker exec -it gitlab cat /etc/gitlab/initial_root_password
初始密码 |
---|
|
-
登录root用户
登录成功后跳转页面 |
---|
|
-
第一次登录后需要修改密码
修改密码 |
---|
|
搞定后,即可像gitee、github一样使用。
4. build阶段工具
构建java项目的工具一般有两种选择,一个是maven,一个是gradle。
这里我们选择maven作为项目的编译工具。
具体安装maven流程不做阐述,但是需要确保配置好maven仓库私服以及jdk编译版本。
5. operate阶段工具
部署过程,会采用docker进行部署,暂时只安装docker即可,后续还需安装kubenetes
5.1 docker安装
-
准备测试环境&生产环境
-
下载docker依赖组件
yum -y install yum-utils device-mapper-persistent-data lvm2
-
设置下载docker的镜像源为阿里云
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
-
安装docker服务
yum -y install docker-ce
-
安装成功后,启动docker并设置开机自启
# 启动docker服务 systemctl start docker # 设置开机自动启动 systemctl enable docker
-
测试安装成功
docker version
效果 |
---|
|
5.2 docker-compose安装
-
下载docker/compose:github - docker/compose: define and run multi-container applications with docker
-
将下载好的docker-compose-linux-x86_64文件移动到linux操作系统
-
设置docker-compose-linux-x86_64文件权限,并移动到$path目录中
# 设置文件权限 chmod a+x docker-compose-linux-x86_64 # 移动到/usr/bin目录下,并重命名为docker-compose mv docker-compose-linux-x86_64 /usr/bin/docker-compose
-
测试安装成功
docker-compose version
效果 |
---|
|
6. integrate工具
持续集成、持续部署ci、cd的工具很多,其中jenkins是一个开源的持续集成平台。
jenkins涉及到将编写完毕的代码发布到测试环境和生产环境的任务,并且还涉及到了构建项目等任务。
jenkins需要大量的插件保证工作,安装成本较高,下面会基于docker搭建jenkins。
6.1 jenkins介绍
jenkins是一个开源软件项目,是基于java开发的一种持续集成工具
jenkins应用广泛,大多数互联网公司都采用jenkins配合gitlab、docker、k 作为实现devops的核心工具。
jenkins最强大的就在于插件,jenkins官方提供了大量的插件库,来自动化ci/cd过程中的各种琐碎功能。
| |
jenkins最主要的工作就是将gitlab上可以构建的工程代码拉取并且进行构建,再根据流程可以选择发布到测试环境或是生产环境。
一般是gitlab上的代码经过大量的测试后,确定发行版本,再发布到生产环境。
ci/cd可以理解为:
-
ci过程即是通过jenkins将代码拉取、构建、制作镜像交给测试人员测试。
-
持续集成:让软件代码可以持续的集成到主干上,并自动构建和测试。
-
-
cd过程即是通过jenkins将打好标签的发行版本代码拉取、构建、制作镜像交给运维人员部署。
-
持续交付:让经过持续集成的代码可以进行手动部署。
-
持续部署:让可以持续交付的代码随时随地的自动化部署。
-
ci、cd |
---|
|
6.2 jenkins安装
-
拉取jenkins镜像
docker pull jenkins/jenkins
-
编写docker-compose.yml
version: "3.1" services: jenkins: image: jenkins/jenkins:2.319.1-lts container_name: jenkins ports: - 8080:8080 - 50000:50000 volumes: - ./data/:/var/jenkins_home/
-
首次启动会因为数据卷data目录没有权限导致启动失败,设置data目录写权限
错误日志 |
---|
|
chmod -r a+w data/
-
重新启动jenkins容器后,由于jenkins需要下载大量内容,但是由于默认下载地址下载速度较慢,需要重新设置下载地址为国内镜像站
# 修改数据卷中的hudson.model.updatecenter.xml文件 <?xml version='1.1' encoding='utf-8'?> <sites> <site> <id>default</id> <url>https://updates.jenkins.io/update-center.json</url> </site> </sites> # 将下载地址替换为http://mirror.esuni.jp/jenkins/updates/update-center.json <?xml version='1.1' encoding='utf-8'?> <sites> <site> <id>default</id> <url>http://mirror.esuni.jp/jenkins/updates/update-center.json</url> </site> </sites>
-
再次重启jenkins容器,访问jenkins(需要稍微等会)
jenkins首页 |
---|
|
|
-
查看密码登录jenkins,并登录下载插件
docker exec -it jenkins cat /var/jenkins_home/secrets/initialadminpassword
登录并下载插件 |
---|
|
|
-
选择需要安装的插件
选择需要安装的插件 |
---|
|
|
|
-
下载完毕设置信息进入首页(可能会出现下载失败的插件)
|
|
|
6.3 jenkins入门配置
由于jenkins需要从git拉取代码、需要本地构建、甚至需要直接发布自定义镜像到docker仓库,所以jenkins需要配置大量内容。
6.3.1 构建任务
准备好gitlab仓库中的项目,并且通过jenkins配置项目的实现当前项目的devops基本流程。
-
构建maven工程发布到gitlab(gitee、github均可)
-
gitlab查看项目 -
jenkins点击左侧导航新建任务
-
新建任务 -
选择自由风格构建任务
-
构建任务
6.3.2 配置源码拉取地址
jenkins需要将git上存放的源码存储到jenkins服务所在磁盘的本地
-
配置任务源码拉取的地址
源码管理 |
---|
|
-
jenkins立即构建
点击任务test中的立即构建 |
---|
|
-
查看构建工程的日志,点击上述③的任务条即可
查看任务拉取git源码日志 |
---|
|
可以看到源码已经拉取带jenkins本地,可以根据第三行日志信息,查看jenkins本地拉取到的源码。
-
查看jenkins容器中/var/jenkins_home/workspace/test的源码
源码存放位置 |
---|
|
6.3.3 配置maven构建代码
代码拉取到jenkins本地后,需要在jenkins中对代码进行构建,这里需要maven的环境,而maven需要java的环境,接下来需要在jenkins中安装jdk和maven,并且配置到jenkins服务。
-
准备jdk、maven压缩包通过数据卷映射到jenkins容器内部
-
数据卷存放位置 -
解压压缩包,并配置maven的settings.xml
<!-- 阿里云镜像地址 --> <mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorof>central</mirrorof> </mirror> <!-- jdk1.8编译插件 --> <profile> <id>jdk-1.8</id> <activation> <activebydefault>true</activebydefault> <jdk>1.8</jdk> </activation> <properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <maven.compiler.compilerversion>1.8</maven.compiler.compilerversion> </properties> </profile>
-
jenkins配置jdk&maven并保存 -
配置jenkins任务构建代码
-
配置maven构建代码 -
立即构建测试,查看target下的jar包
-
构建源码
6.3.4 配置publish发布&远程操作
jar包构建好之后,就可以根据情况发布到测试或生产环境,这里需要用到之前下载好的插件publish over ssh。
-
配置publish over ssh连接测试、生产环境
-
publish over ssh配置 -
配置任务的构建后操作,发布jar包到目标服务
-
配置构建后操作 -
立即构建任务,并去目标服务查看
-
立即构建
7. 结语
本文对devops的基本概念进行了介绍,同时展示了基础环境搭建步骤,下篇文章将对ci/cd如何闭环实现进行更进一步的讲解,如本文对你有帮助,请动动小手三连一下哦~
发表评论