第一节运维自动化---ansible
- 1.1为什么使用运维自动化
- 1.2使用运维自动化场景
- 1.3运维自动化----playbook
- 1.4运维自动化的层次
- 1.4.1 OS Provisioning
- 1.4.2 OS Config
- 1.4.3 Deloyment
- 1.5运维自动化的特点
- 1.5.1 no agent
- 1.5.2 no server
- 1.5.3 modules is any lanuages
- 1.5.4 YAML(YAML Ain’t Markup Language)
- 1.6运维自动化的基本架构
1.1为什么使用运维自动化
日常管理/环境搭建----》1台服务器中执行30条命令—》如何执行？
1）常见方法：命令一个一个去执行，
但是我们生产环境中往往都是多服务器场景，假如需要管理30台服务器，就需要执行900条命令。这样容易出错，工作效率低。----人肉运维
2）编写脚本-----一个脚本中包含30条命令-----分发给30台服务器（远程传输scp）----执行脚本30次--------就需要操作90次-----这样不容易出错，工作效率高
3）运维自动化工具----ansible----批量执行命令----一次执行30台服务器上的脚本-1条命令
1.2使用运维自动化场景
1）命令----脚本-----在服务器中批量执行命令-----适用于命令很多的场景
我们的生产环境中面临的并不只是单台服务器的管理工作，往往涉及到集群管理
2）Ansible-----批量执行命令----适用于服务器很多的场景中，服务器越多，命令/脚本都可以放入到ansible中执行
1.3运维自动化----playbook
1）ansible可以直接发送命令到服务器
2）在ansible有一个playbook（剧本）-----编写playbook—执行命令
假如命令很多就可以使用playbook----达到多条命令执行一次playbook等于执行多条命令的效果
3）Linux命令----通过命令编写成Linux脚本-----在批量执行命令
4）ansible命令—（在服务器少，命令少的情况）在不同主机批量执行命令----执行一次
Ansible命令----在服务器多，命令多的情况下需要使用ansible中的playbook（剧本）-----在不同的主机批量执行命令----可以将多条命令编写到playbook中，执行一次playbook即可
1.4运维自动化的层次
1.4.1 OS Provisioning
OS Provisioning —系统准备阶段
1）准备新的服务器
2）给新的服务器装系统-----cobbler 批量安装操作系统
批量安装操作系统-----无人值守自动化安装操作系统
光盘启动（先刻镜像文件到系统盘—插入到服务器中），U盘启动，网卡启动
A．先将镜像文件的保存到之前的服务器上，并通过dhcp服务给新的服务器分配IP地址，并将bios中的引导启动顺序改为网卡启动。
B．Kickstart文件----里面是安装准备阶段的操作----可以指定新的服务器去选择某个写选项
C．anaconda-ks.cfg—是操作系统安装器
D．开始传输镜像文件
E．通过TFTP来进行传输
才可以实现开机自动安装操作系统
由于以上安装操作比较复杂，因此就出现了cobbler（补鞋匠）----是rpm包
里面包含了dhcp配置文件、kickstart、ftp配置文件
Cobbler工具---自动化部署操作系统3）安装对应的服务器软件
4）进行相应的配置（系统的配置，软件的配置，页面配置等）
1.4.2 OS Config
OS Config----系统配置阶段
1）准备一台服务器
2）自动化运维工具----saltstack/ansible—进行配置（创建用户，配置yum源、yum安装，configure、make、make install----./nginx服务）
3）Cfengine puppet chef saltstack 都是系统配置工具
早些时候使用puppet + func--------基于ssl(安全套接层)----tcp/ip位于应用层和传输层-----应用层准备完数据后交接给套接层，套接层在进行打包加密，在交接给传输层打包----重型验证机制
现在使用saltstack + python -------基于ssh-----轻型验证机制
Ansible 具备 puppet +func的组合功能
Ansible底层依赖的是ssh服务----有openssh-server和openssh-clients
1.4.3 Deloyment
Deloyment-----联动工具
和系统配置里的工具功能差不多
1.5运维自动化的特点
1.5.1 no agent
没有代理端，不需要在被管理端安装对应的软件
1.5.2 no server
ansible去执行命令，不存在被管理端找管理端的情况
Ansible没有客户端的概念，底层依赖的是ssh服务----有openssh-server和openssh-clients
A服务器中有安装ansible，那么它依赖于clients，被管理节点中依赖于server
没有ansible进程
1.5.3 modules is any lanuages
用任何语言都可以开发模块
1.5.4 YAML(YAML Ain’t Markup Language)
是一种标记语言
1.6运维自动化的基本架构
1.Host Inventory（主机清单）：需要自己编写哪些主机是需要管理的—给相应的主机发送请求
2.Connection Plugins （连接插件）：就是基于ssh服务 而其对应的host1，host2，hostN。。。都是被管理端
3.Public/private cloud（公有/私有云（网络））：可以基于私网进行管理，也可以基于公网进行管理-----基于ssh加密传输
4.Playbooks（剧本）—批量执行ansible
5.Core modules (核心模块)：ansible自带的模块
6.Custom Modules（自定义模块）：自己开发的模块，推荐用saltstack
7.Plugins（插件）：例如—email logging 。。。。other
8.说明：
1）ansible的工作是依赖于模块的,因此ansible是一个核心,ansible本身有ansible,ansible-playbook命令
2）ansible所有的工作都依赖于核心模块来完成,这些核心模块都是ansible自身携带的,若这个内置模块功能不满足需求,还可以自己编写模块,任何语言都行,遵循基本的语法规范,能执行就行
3）ansible同时有插件,能够完成ansible任务当中的功能性补充
4）为了对部分主机执行配置,区分不同组的主机我们需要定义host inventory. 可以通过读取组名自动识别组成员
