「自动化运维」从0到1 CICD自动化部署落地分享
目录
一、CICD简介
二、CICD实践过程
三、含泪踩坑
四、 历史 文章指路
一、CICD简介
1、CICD定义
2、DevOps定义
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps的基础核心是CICD。
CICD的基础核心是自动化。
二、CICD实践过程
1、起因
在我之前的团队，因为要切换全新业务线，需要为新业务搭建一套全新的环境，所有东西从0开始。
原先只是用于部署测试环境，后面决定一起部署生产环境，这个过程中我还造成了一个严重生产环境问题，好在当时的生产环境还未正式使用，未造成严重影响。
在当时挺害怕也挺有压力的，但是后面项目完整落地，平稳运行，我还是挺有成就感的，接下来我将整个项目过程完整的分享出来。
2、技术栈选型
首先进行技术栈选型，我们选择的是Jenkins，Jenkins当属业内持续集成老大哥，有着非常丰富的插件，也可以选择gitlab集成的CICD，因为我们还有其它的测试脚本需要集成，所以Jenkins对于我们来说是最优的选择；
Ansible是批量运维工具，通过编写yaml脚本，可以方便实现批量管理多台机器，并且Ansible是比较轻量级应用，很容易上手；
shell脚本可以用于执行一系列命令。
其它的就结合团队项目情况进行搭建。
3、Jenkins应用部署实现流程
首先来梳理下整个项目的实现流程，主要分为Jenkins主节点和应用服务器，是一对多的关系。
Jenkins主节点的主要负责项目部署前的工作，主要包含拉取代码，前端打包，后端打包，快照版检测，将压缩包和部署脚本发送到目标机器（即应用服务器），远程调用目标机器上的部署脚本进行代码替换。
应用服务器部署脚本执行过程有：解压压缩包，停止服务，覆盖代码，拉取disconf，应用目录分组赋权，重启服务，检查服务是否有进程，查看启动日志，删除/tmp目录下旧压缩包。
Jenkins应用部署流程图
4、任务计划
4.1、搭建环境
Jenkins
指路【Jenkins系列】如何搭建Jenkins环境。
Ansible
Git
GitLab
因为这个我没有实践成功的教程，所以在这里就不贴啦~
Node.js
Maven
JDK
Nginx
2、编写前置脚本
3、编写应用部署脚本
4、Jenkins配置
指路【Jenkins系列】如何构建Jenkins Job。
新增Job，主要用于拉取代码，执行Maven编译，执行app_build.sh，将压缩包通过ssh发送到目标机器，远程调用目标机器的deploy.sh。
三、含泪踩坑
踩坑1
问题描述：在错误的路径拉取配置，原因是未成功解压压缩包。
解决方案：校验压缩包是否解压成功解压成功，并且在cd到正确的路径后添加&&（&&表示上一条命令执行成功再执行下一条命令）才进行拉取配置。
踩坑2
问题描述：项目没有正常停止，导致无法重新启动。
解决方案：虽然执行kill -9，但是未找到根本原因，因此加了一个检测机制，如果检测没有正常停止服务，则退出程序。
踩坑3
问题描述：生产部署脚本拉取了开发环境的的jdbc配置，原因是生产部署脚本写错了开发环境disconf的域名，当时我同时在搞开发生产环境的脚本，开发和生产是两套不同的脚本，一时混乱写错了，吓得一批，好在当时生产环境还没投产使用。
解决方案：为了避免后续这种情况的发生，而且是必须避免的，我们通过环境名称来判断走开发还是生产域名，这样就能保证脚本一致性了。
在这个项目实际遇到的问题远不止上面这几个，在这个实践过程中，我对整个应用部署流程有了更深的理解，平时方方面面的学习终于集中化起来进行实践了。
我习惯将学到的知识和遇到的问题记录起来，在写这篇文章的过程回过头来看，五味杂陈，原来我都经历了这些哈哈哈……
踩过的坑终究使我更加强大，带你见证呱呱本呱成长为参天大呱~
搞测试，不迷路
呱呱大王本呱带你飞！
zabbix和ansible的区别
Zabbix和Ansible分别是两款非常流行的开源监控和自动化工具。具有上手简单，学习曲线平滑、配置简单、功能强大、扩展性强等优点。本质上没有什么区别。
有一种病症叫做“选择障碍症”，实际上工程师更容易被这个病症缠绕。但是，实际上没那么复杂，抓阄就行了。目前主流的自动化运维工具有puppet、ansible、saltstack，实际上每一个工具都基本上能够完成你的运维任务，也都是久经考验的。
都有NB的地方，也有挫的地方，所以，完全没法从功能、特性等等这些方面去选择。如果考虑到快速使用，建议puppet，有一个foreman做web平台，上手快。如果考虑后期自己开发。并且是无agent方式，可以用ansible基于ssh的，比较直接粗暴，会有种很“爽“的感觉。
ansible主要是远程命令执行，比较适合做“一次性”的工作。saltstack用的不多。不做评论。我个人比较喜欢用puppet和ansible，倒不是说saltsatack不好，是我从开始就在用puppet，所以，就没有再去学习saltsatck的必要了。
ansible的优势是什么？如何在企业中更好地使用ansible？ansible比较适合做“一次性”的工作，例如，系统部署、应用发布、打补丁等等。在企业中使用ansible，要注意以下几点：
1.安全控制，简单来说就是避免用root用户来执行。
2.控制好依赖在写playbook的时候，控制好先后顺序和依赖关系。
3.结果的收集和分析因为一下子几百台机器一起干活，所以，就要自己写外置脚本，更好地收集ansible的操作结果，并且进行直观的汇总和展现。
jenkins和ansible的区别
Jenkins + sonar 的系统，用来执行自动构建、自动部署、自动测试，代码质量评估的整套平台，用来做敏捷。
持续集成是个简单重复劳动，人来操作费时费力，使用自动化构建工具完成是最好不过的了。
后期应该搞单元测试，自动化测试，自动部署
做分布式，服务器集群的时候没有自动化工具是很难运转的！
ansible-core和ansible的区别
操作难度和外观区别。
1、ansible-core外观完善，能让用户身心喜悦，ansible-core更新不需要去客户端安装agent，更新是，只需要在主控机上记性一次更新即可。
2、ansible外观简陋，让人看上去心情不是很美好，ansible-core更新需要客户安装agent，而且还需要apex工具协助更新。
jenkins 自动化测试 是单元测试还是集成测试
作者：阮一峰 互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称 CI）。 本文简要介绍持续集成的概念和做法。 一、概念 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 1、快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 2、防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。 Martin Fowler 说过，“持续集成并不能消除 Bug，而是让它们非常容易发现和改正。“ 二、持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。 三、持续部署 持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。 持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。 （图片来源） 四、流程 根据持续集成的设计，代码从提交到生产，整个过程有以下几步。 4. 1 提交 流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。 4. 2 测试（第一轮） 代码仓库对 commit 操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。 测试有好几种。 单元测试：针对函数或模块的测试 集成测试：针对整体产品的某个功能的测试，又称功能测试 端对端测试：从用户界面直达数据库的全链路测试 第一轮至少要跑单元测试。 4. 3 构建 通过第一轮测试，代码就可以合并进主干，就算可以交付了。 交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS 脚本、图片）等等。 常用的构建工具如下。 Jenkins Travis Codeship Strider Jenkins 和 Strider 是开源软件，Travis 和 Codeship 对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。 4. 4 测试（第二轮） 构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。 第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。 需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。 4. 5 部署 通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar *）存档，发到生产服务器。 生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有 Ansible，Chef，Puppet 等。 4. 6 回滚 一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。 五、参考链接 Gergely Nemeth,Continuous Deployment of Node.js Applications Codeship,Continuous Integration Essentials
ansible使用笔记(二)常用命令使用及常用模块简介
目录
一、常用命令使用
二、双引号“ “ 单引号’ ’对执行结果的影响
三、ansible-console工具
四、ansible常用模块
一、常用命令使用
前面有提到过ansible的常用的命令和使用
列出要执行主机
ansible all –list-hosts
批量检测主机
ansible all -m ping -k
ansible主机集合 -m 模块名称 -a 模块参数
主机集合 主机名或分组名,多个使用“逗号“分隔
-m 模块名称,默认command模块
-a or –args模块参数
其它参数
-i inventory文件路径,或可执行脚本
-k 使用交互式登陆密码
-e 定义变量
-v 显示详细信息
二、双引号“ “ 单引号’ ’对执行结果的影响
执行以下命令来查看ansible的执行结果
1）shell
ansible web -m shell -a “echo ${HOSTNAME}“
ansible web -m shell -a ’echo ${HOSTNAME}’
2）创建的文件在哪查看
ansible cache -m shell -a ’cd /tmp’
ansible cache -m shell -a ’touch testfile’
注：
1）变量解析 双引号““ 与单引号’’使用区别
ansible 执行命令是二次解析，第一次在本机解析, 第二次在执行机器解析，需要第二次解析的变量要转移
总结: 参数默认使用 ’ ’ 号就对了
2）创建的文件在哪里
文件在用户家目录，ansible 是使用 ssh 多次连接执行，连接退出以后之前的状态就全部失效了
解决方法：使用 chdir 代替 cd 命令
ansible cache -m shell -a ’chdir=/tmp touch testfile’
三、ansible-console工具
是ansible为用户提供的交互式工具,用户可以在ansible-console虚拟出来的终端出来的终端上像shell一样使用ansible内置的各种命令,这为习惯使用shell交互方式的用户提供了良好的使用体验
四、ansible常用模块
4.1 ) ansible-doc和ping模块
ansible-doc模块手册
模块的手册相当于shell的man,很重要
ping模块
测试网络连通性,ping模块没有参数
注:测试ssh连通性
4.2 ) command模块
默认模块,远程执行命令
用法
command模块注意事项:
该模块通过-a跟上要执行的命令可以直接执行,若命令里有如下字符则执行不成功
“《“ “》“ “|“ “&“
command模块不能解析系统变量
该模块不启动shell直接在ssh进程中执行,所有使用到shell的命令执行都会失败
查看所有机器负载
查看日期和时间
4.3 )shell模块
shell模块用法基本和command一样,区别是shell模块是通过/bin/sh进行执行命令,可以执行任意命令
不能执行交互式的命令,例如 vim top等
4.4 ) script模块
命令太复杂?
在本地写脚本,然后使用script模块指量执行
ansible web -m script -a ’urscript’
注意:该脚本包含但不限于shell脚本,只要指定sha-bang解释器的脚本都可运行
案例:
给所有web主机添加用户wk
1.要求by用户与wk用户不能出现在同一台主机上
2.设置wk用户的密码是456
4.5 ) yum模块
使用yum包管理器来管理软件包
name:要进行操作的软件包名字
state:动作(installed安装、removed删除)
4.6 ) service模块
name:必须项,服务名称
enabled:是否开机启动yes|no
sleep:执行restarted,会在stop和start之间沉睡几秒钟
state:对当时服务执行启动、停止、重启中、重新加载等操作(started,stopped,restarted,reloaded)
案例:
1.给db组安装mariadb
2.开启mariadb服务并设置开机启动
4.7 ) copy模块
复制文件到远程主机
src:复制本地文件到远程主机,绝对路径和相对路径都可以,路径为目录时会递归复制,若路径以“/“结尾,只复制目录里的内容,若不以“/“结尾,则复制包含目录在内的整个内容,类似于rsync
dest:必须项,远程主机的绝对路径,如果源文件是一个目录,那该路径必须是目录
backup:覆盖前先备份原文件,备份文件包含时间信息,有两个选项:yes|no
force:若目标主机包含该文件,但内容不同,如果设置为yes,则强制覆盖,设为no,则只有当目标主机的目标位置不存在该文件时才复制,默认为yes
案例:
拷到本机/etc/resolv.conf 文件到所有拖管主机 并对原文件备份
给所有 db 主机开启 binlog 日志
4.8 ) lineinfile模块 replace模块
类似sed的一种行替换模块
path 目标文件文件
regexp 正则表达式,要修改的行
line 最终修改的结果
replace模块
类似sed的一种行替换模块
path 目标文件文件
regexp 正则表达式,要修改的行
replace 替换后的结果
lineinfile模块与 replace模块区别
lineinfile模块 是修改某个文件的单行并进行替换
replace模块 是修改某个文件的所有匹配行并进行替换
4.9 ) setup模块
主要用于获取主机信息,playbooks里经常会用的另一个参数gather_facts与该模块相关,setup模块下经常用的是filter参数
filter过滤所需信息
执行以下命令可查看包含的所有信息,可大致浏览一遍,包含的信息,
需要注意的是 filter过滤条件必须以信息中模块名为过滤条件 模块中详细信息不能为过滤条件
,jenkins svn和jenkins svn ansible的区别在哪里
在系统管理页面点击Manage and Assign Roles进入角色管理页面：
1、管理角色（Manage Roles）
选择该项可以创建全局角色、项目角色，并可以为角色分配权限。
如上图，分别创建了admin、anonymous两个全局角色，Online Program、test两个项目角色。
项目角色与全局角色的区别就是，项目角色只能管理项目，没有管理jenkins的权限配置。
添加项目角色时，需要制定匹配项目的模式，如上图中的Pattern，官方文档介绍该选项支持正则表达式，如“Roger-.”表示所有以Roger-开头的项目，“(?i)roger-.*”表示以roger-开头的项目并且不区分大小写，如以ABC开头的项目可以配置为“ABC|ABC.*”，也可以使用“abc|bcd|efg”直接匹配多个项目。
2、创建用户
在分配角色之前需要先创建用户。
在系统管理页面，点击管理用户：
点击新建使用者可以创建新用户，如果之前有项目与scm版本管理系统（如svn、git等）连接并获取源码构建过，jenkins会从svn中读取到一些用户信息，可以在查看用户菜单中看到这些用户：
点击用户id或名称都可以修改用户信息。
3、分配角色（Assign Roles）
选择Assign Roles可以为用户分配所属角色，可以分配全局角色和项目角色。
两大容器管理平台，Kubernetes与OpenShift有什么区别
容器化是开发和部署应用的热门趋势，因为它们是加速开发的有效方式。容器的使用量在过去几年呈指数增长。
但是，跨基础架构管理容器可能会变得十分复杂，所以容器管理平台对于任何企业来说都是必不可少的工具。Kubernetes和OpenShift是市场上最受欢迎的两个容器管理平台。而OpenShift是基于Kubernetes的，那么二者之间到底有哪些区别呢？
OpenShift是由红帽（Red Hat）开发的容器化软件解决方案。他们的主要产品是OpenShift容器平台，这是基于Kubernetes管理的平台即服务（PaaS）。它是用Go和AngularJS编写的，并且有Apache许可证。
OpenShift Origin是红帽基于开源的云平台，允许开发人员构建，测试和部署云应用。该系统在Kubernetes核心之上添加工具，以实现更快的应用开发，轻松部署和扩展。
该平台除了可扩展外，还支持Go，Node.js，Ruby，Python，PHP，Perl和Java，允许用户添加对其他语言的支持。关于可扩展性，该平台可以自动或手动扩展容器化应用。
OpenShift提供的一些功能包括：
在整个应用程序生命周期中的安全性 – 安全性检查内置于容器堆栈中。
平台上包含的内置监控功能是Prometheus，一种数据库和应用监控软件。你可以在Grafana仪表板上实时显示应用。
集中式策略管理 – 跨集群的单个控制台为用户提供了实施策略的集中位置。
兼容性-OpenShift是Certified Kubernetes计划的一部分，因此允许与Kubernetes容器工作负载兼容。
使用OpenShift的好处包括：
快速的应用开发 – 平台流传输和自动化容器管理过程，从而增强了DevOps过程。应用开发的这种加速意味着你可以更快地进入市场，从而提高竞争力。
没有供应商锁定提供与供应商无关的开源平台，这意味着用户可以根据需要将其容器流程迁移到新的操作系统，而无需重新进行容器化编排。
自助服务配置 – OpenShift允许用户集成他们最常使用的工具，例如，视频 游戏 开发人员在开发与多个操作系统兼容的 游戏 时可以使用此功能。
Kubernetes是一个开源容器即服务（CaaS）编排系统，用于自动化容器化应用的部署，扩展和管理，从而改进应用程序开发过程。Kubernetes的一些功能包括：
Kubernetes的好处包括：
由于OpenShift基于Kubernetes，因此它们有很多共同之处。但是，两个平台之间存在一些差异。让我们对OpenShift和Kubernetes功能进行比较：
基础
虽然两者都基于Linux，但每个产品都在不同的环境中运行：
Kubernetes在其可运行的操作系统方面更加灵活。但是，包管理器应该是RPM，这意味着选择合适的Linux发行版。因此最好在Fedora，Ubuntu或Debian上运行它。Kubernetes可以部署在任何主要的IaaS平台上，例如AWS，Azure，GCP、阿里云、IBM云平台等。
OpenShift可以安装在Red Hat Enterprise Linux（RHEL）和Red Hat Enterprise Linux Atomic Host（RHELAH）以及Fedora和CentOS上。OpenShift Dedicated允许在云中创建自己的集群，特别是基于AWS。
Rollout
这两种产品在Rollout方面都很复杂：
Kubernetes运行平台的多样性意味着有无数的解决方案可以在本地创建Kubernetes集群。大多数都基于Rancher Kubernetes Everywhere（RKE）或kops等安装程序。
OpenShift可避免在首次Rollout后需要额外的组件。因此，它配备了基于Ansible的专有安装程序，可以使用最少的配置参数安装OpenShift。
Web UI
与通过基于Web的用户界面管理集群的能力相比，OpenShift和Kubernetes之间存在很大差异。
Kubernetes的仪表板必须单独安装，需要通过kube代理访问，以将本地机器的端口转发到集群的管理服务器。此外，它没有登录页面，但你需要手动创建承载令牌以提供身份验证和授权。所有这些复杂性导致Web UI对于真正的日常管理工作而言不是很有价值。
OpenShift的Web控制台有一个登录页面，可以轻松访问，甚至可以让你通过表单创建和更改大多数资源。虽然你无法通过Web管理集群，但可以可视化服务器，项目和集群角色。
集成镜像注册表
关于集成图像注册表的两个系统之间的关键区别：
使用Kubernetes，可以设置自己的Docker注册表，但没有集成镜像注册表的概念。
OpenShift附带了一个集成的镜像注册表，可以与Docker Hub或Red Hat一起使用。它甚至还有一个注册表控制台，可以在其中搜索与集群中项目相关的镜像和镜像流的信息。
Jenkins
虽然Kubernetes中不存在该概念，但可以部署自己的自定义Jenkins镜像。生成的组件是上传到镜像存储库的docker镜像。
OpenShift使用Pipeline构建，这是一种源到镜像构建的形式，它引用包含Jenkins的镜像，而Jenkins又监控ImageStreamsTags。当需要更新时，它可以启动Jenkins构建。
网络
Kubernetes没有本机网络解决方案，但提供可供第三方网络插件使用的接口。
OpenShift有一个开箱即用的本机网络解决方案OpenvSwitch，它提供三种不同的插件。
两者都是开源软件平台，来满足容器编排和应用开发。它们使得以简单易管理的方式部署和管理容器化应用成为可能。OpenShift Web控制台使其非常有用，允许直接通过它执行80％以上的任务。
虽然两者都有类似的核心（毕竟OpenShift内置了Kubernetes），OpenShift通过其开箱即用的功能使安装更容易。安装Kubernetes通常需要交钥匙解决方案或托管Kubernetes集群。
您选择的系统将取决于您的系统要求以及开发过程的关键灵活性或良好的Web界面。
ansible2.7和2.9区别
Ansible是一个简单强大且无代理的自动化语言。2.9是升级版本。
Ansible是基于Python开发的，所以推荐Python2.7及以上版本。简单易读：基于 YAML 文本编写，易于阅读，非专业的开发人员也可以编写。功能强大：它可以同于管理配置，软件安装，流程自动化无代理：不需要在客户端安装额外的 agent跨平台支持：支持 linux，Windows，Unix 和网络设备。
Ansible 典型的工作方式是通过一个脚本文件（基于 YAML 格式构建的）去控制远端操作系统按照特定的顺序执行相关任务，我们称这个文件为 playbook。