Ansible,运维管理平台部署,维护与调优常见问题及技巧

　Ansible 运维管理平台部署 维护与调优常见问题及技巧

　Ansible 是基于一致性、安全性、高可靠性设计的轻量级自动化工具，功能强大、部署便捷、描述清晰。对于管理员、开发者、IT 经理等都容易上手，学习曲线较低，能够快速理解、掌握 Ansible 的自动化体系，满足不同技术级别的用户需求。本文分享了在 Ansible 部署、维护、调优中常见的一些难点解决办法和技巧，帮助大家更快的掌握使用方法。

　1、Ansible 运维管理平台部署都可以部署在哪些系统上？对系统配置有哪些具体要求?

　对管理主机的要求：

　目前，只要机器上安装了 Python 2.6 或 Python 2.7 (windows 系统不可以做控制主机)，都可以运行 Ansible。主机的系统可以是 Red Hat, Debian, CentOS, OS X, BSD 的各种版本，等等。自 2.0 版本开始，Ansible 使用了更多句柄来管理它的子进程，对于 OS X 系统，需要增加 ulimit 值才能使用 15 个以上子进程，方法 sudo launchctl limit maxfiles 1024 2048，否则可能会看见”Too many open file”的错误提示。

　Ansible 每个版本里面有详细的设备列表你可以参考

　目前常用的支持 RedHat，Ubuntu，SUSE， windows( Ansible 需要 winrm)，AIX(需要安装 python)，HPUX (需要安装 python) 网络设备 cisco，Huawei ；防火墙目前只能连接操作需要模块支持 cisco 的，华为的目前没看到模块。

　 2、无法访问外网如何快速安装 Ansible？是否有打包好的依赖包？

　Ansible 软件安装的方式较多，非常灵活，可以满足各种环境 的 部署需求。一般可以直接用源码进行安装 ，包括从 GitHub 源码库安装方式 、TAR 包安装、制作 RPM 包安装等。也可用操作系统软件包管理工具进行安装 ，包括 YUM 安装（适合 Fedora、RHEL、 CentOS ）、APT 安装（适合 Ubuntu ）、 Homebrew 安装 ( 适合 Mac OS X ）

　、PIP 安装等。其中大部分安装方式需要服务端连通公网，在无法连接外部互联网的条件下，可以通过 TAR 包的安装方式， 快速搭建 Ansible 整套环境，所有安装包的下载地址为：

　 yum download 把需要的包下载到一个目录。

　然后把这个目录做成 yum 本地源。

　可以 mount 操作系统安装盘 dvd 版镜像 iso 文件，找到软件包目录然后将 yum 源设置为该目录。

　3、在编排程序执行，软件安装等过程中，Ansible playbook 与 shell 脚本，各自的特点有哪些？

　【问题描述】有时候遇到 linux 系统批量安装程序，部分程序是公司内部开发人员编写，会倾向写 shell，再通过批量工具执行脚本。在什么情况下会选择使用 ansible 工具？

　目前使用的是 2.9.9 版本，实际使用过程发现，ansible 解决了大文件批量远程复制效率低的问题，以前老版本在上传 1G 的大文件非常慢？

　最大的三个不同：

　1、 Ansible 内置了大量的模块，这些模块是声明式的（Declarative），只需使用这些模块描述被管节点期望达到的状态。而 Shell 脚本是命令式，声明式相比命令式更智能，例如分别使用 Shell 脚本和 Ansible Playbook 启动某个服务，然后再完成其他事情。如果在启动时发现这个服务已经启动，监控端口已经被占用，Shell 脚本将异常退出，返回非 0，导致后面的脚本中断执行，但使用 Playbook 将不会遇到这样的问题。

　2、 Ansible 内置模块都是等幕性的（Idempotent）。等幕性对于自动化维护是非常重要的特性，这样在被管节点上多次执行 Ansible Playbook 也能达到同样效果。相对于直接执行操作系统 Shell 脚本的方式是巨大的改进，操作系统脚本再执行一次可能就会产生不同的、非预期的结果。而 Ansible 具有幂等性的特点，无论执行多少次，只要你的操作系统是同一个版本，那么安装出来的环境绝对是一样的，这样也就保证了应用所处的底层环境的一致性，而不会造成同一个版本的应用在不同的机器上运行出现不同的效果的问题。

　3、Ansible Role 功能，可以使用 ansible role 来简化 playbook 的编写且易于复用，这点是 Shell 脚本非常难以做到的。例如我们想要 在主机 A 、 B 、 C 上部署 JDK1.7 的环境，主机 D 、 E 、 F 上部署 JDK1.8 的环境，而又想在 A 、 B 上安装 Nginx ；C 、 D 上部署 Tomcat ；E 、 F 上部署 MySQL ，这时候使用 Ansible工具是最佳的。对于这种情况只需要新建 5 个 roles ，分别是：JDK1.7 、 JDK1.8 、 Nginx 、 Tomcat 、 MySQL 。对于 A 、 B 主机，安装 JDK1.7 和 Nginx 的 roles ， C 主机安装 JDK1.7 和 Tomcat 的 roles ；D 主机安装 JDK1.8 和 Tomcat 的角色， E 、 F 主机安装 JDK1.8 和 MySQL 的角色。换句话讲， Ansible 就是对于各种环境的搭积木式组合，你需要什么环境，我就给你装上什么环境，对于系统管理员来讲，不必再去每一台机器上根据需求名单一个一个安装，不仅效率低、劳动成本高、而且容易出错，造成环境的不一致。

　playbook，就像你坐镇指挥台指挥大家打仗，发布号令即可，最后执行的结果坐等就有报告。

　shell，就像你跑到步兵阵营，一个一个告诉他们一会儿怎么操作，然后再跑到骑兵阵营一个一个告诉他们怎么操作。。。。执行结果你还需要一个一个记录，自己汇总。

　4、Ansible 批量管理主机时选择长连接还是短连接？选择长连接时资源占用高不高？

　用长连接效率高，加快 Ansible 的执行速度，尤其是批量管理的主机上千上万时。而且长连接可以复用，对受管主机的开销就是一个连接的开销。

　开源版本的是无连接方式，每次创建 ssh 连接。

　企业版本支持 MQ，是长连接方式。

　 5、关于执行 Ansible 查看任务进度：在执行需要长时间等待的命令时，如何显示实时任务的状态。

　Ansible playbook 执行任务时会显示当前任务执行到哪儿的。

　6、Ansible 告警通知功能除了邮件，现在支持微信方式吗？

　用 Ansible 调用脚本驱动微信接口，微信接口需要开发。

　7、关于 Ansible mysql 模块执行添加权限，然后 mysql 查看用户权限却失败？

　【问题描述】在创建 mysql 用户时使用 mysql 模块，结果权限却没有执行上

　 用 mysql_user 模块授权是没问题的，您可以用 select * from mysql.user 看到实际用户权限已经授予的。

　只是您查看用户授权的命令有些许问题，要用 show grants for keystone@localhost；去查看，因为您通过模块去授权默认的主机是 localhost

　8、如何使用 Ansible 使用变量在一个被控节点中，往一个文件中写入另一个被控节点的 IP？

　【问题描述】在自己写 ansible 部署 K8s 的 playbook 时，master 节点为 192.168.23.20

　 node 节点为192.168.23.21 192.168.23.22

　在编写 node 节点时要插入 master 的信息，由于无法做到以变量的方式把 master 节点 ip 信息插入到 node 节点的/etc/kubernetes/kubelet 文件中，最后以 var 变量的方式解决。请问如何使用 ansible 使用变量在一个被控节点中，往一个文件中写入另一个被控节点的 IP？

　 三种方式：

　1、直接在 playbook 中通过“ vars: 变量 名”的方式声明变量，并通过“{{变量名}}”的方式使用已声明的变量的方式来带入 master 节点的 IP 地址信息。

　2、在 roles 中用 var 变量文件的方式（您的方式）。

　3、引用 inventory 文件中定义的主机变量。

　9、Ansible 能否自定义功能？

　【问题描述】Ansible 在使用过程中，可能会有部分功能无法满足要求，能否根据实际情况，进行自行定义？

　ANSIBLE 很强大，能够支持自定义模块和自定义插件，来满足我们的实际需要，实现现有模块和插件无法达到的效果。

　Ansible 自定义模块：

　模块是 Ansible 的核心引擎， Ansible 中的模块就是传输给远程主机并执行的那点代码。它们可以使用远程主机可以执行的任何语言实现。Ansible 的核心开发团队维护的 Ansible 核心模块大概有 150 多个，涵盖了云、命令、数据库、文件、网络、包、源控制、系统、工具、web 设施等等。另外，还有 100 多个其他额外模块，主要由社区贡献者维护，它们扩展了这些类别的很多功能。真正神奇就发生在模块代码内部，它们接受传入的参数，然后建立预期的结果。而且 Ansible 能够提供一种简单的机制来利用来自 Ansible 外部的自定义模块。

　Ansible 自定义插件使用场景举例：

　1)除 Paramiko、本机 SSH、Local、Winrm 连接方式外,希望 Ansible 基于新的通信方式与远程主机交互;

　2)除 Ansible 内置的 with_items、with_fileglob 循环体外,希望有新的遍历方式;

　3)除了 Ansible 内置的 host_vars、group_vars 等变量调用方式外,希望有新的变量定义方式;

　4)除了 Ansible 的内置的 Jinja2 模板渲染、to_yaml、to_json 等过滤器外,希望有新的过滤器;

　5)定义新的回调机制,即捕获响应事件后自定义新的响应形式。

　Ansible 的功能自定义可以通过两个方法来解决：

　方法 1：自定义脚本，如果自定义功能比较简单，可以通过操作系统脚本方式来实现的话，可以通过自定义一个 shell脚本，并通过 ansible 的 script 模块进行调用。以实现自定义功能

　方法 2：自定义模块，这个会稍微复杂一点。ansible 是通过 python 语言开发的，并且支持通过 python 语言自定义模块。不过这一点需要具有一定的编程知识。

　10、Ansible 是否可以主动侦测网络拓扑中新增加设备，并根据不同的操作系统进行主动添加监控运维对象性能指标？

　这个 Ansible 没法做，Ansible 管理的对象必须要支持 OPENSSH、满足 PYTHON 版本要求、且要提前建立 SSH互信，主动侦测设备接入并探测到操作系统类型没办法进行。但可以通过流程来驱动，例如流程平台的设备新增，信息自动录入 CMDB，然后 Ansible 和 CMDB 联动，发现了这个设备，可以自动地通过默认的用户密码与之建立互信，然后采集数据。

　11、技巧分享：利用 ssh-agent 来提升 Ansible 管控的安全性

　默认情况下，Ansible 会使用中控端操作系统上安装的原生 SSH 客户端来实现与远端主机的通信。在之前我们会建立中控端与远端主机的 SSH 互信，首先利用 ssh-keygen 来生成一对私钥和公钥，再利用 ssh-copy-id 将公钥下发到远端主机，中控端则可以利用私钥免密地与远端主机通信。

　然而这样一来，如果私钥文件泄露了，其他服务器使用这个私钥同样能够免密地和远端主机通信。这时我们可以采用加密的 SSH 私钥来增强私钥的安全性，在用 ssh-kengen 生成私钥时，输入加密密码。当私钥和公钥配对前，会强制要求输入这个私钥密码。然而这样一来又会带来另一个新问题，ansible 管控了成千上万个远端主机，不可能每次都要输入私钥密码来执行任务。

　这时，我们就要用到 ssh agent 了，它有以下几个优点：

　1、ssh agent 让加密的 SSH 私钥的管理变得更加容易，通过它能够实现免私钥密、免远端主机密码去登录远端主机。

　使用方法：我们只需在中控端通过“ssh-agent”命令来启动 ssh agent，然后通过“ssh-add 私钥路径/私钥文件名”来添加私钥至 ssh-agent，第一次需要输入加密私钥的密码。在添加私钥时，可能会出现“Could not open a connection to your authentication agent”的报错，这时需要运行“ssh-agent bash”命令来解决。最后我们可以使用“ssh-add -L”命令来查看添加到 agent 中的所有私钥。

　2、如果之前我们使用了 ansible 来管理不同的 SSH 私钥，使用 ssh agent 可以简化 ansible 的配置文件，而不必在主机上明确指定 ansible_ssh_private_key_file。

　这样一方面加强了 ansible 利用 ssh 私钥的安全性，另一方面也避免了因私钥密码的设置带来的不便利性，同时也增强了私钥的管控的统一性。

　 12、技巧分享：使用 Ansible role 简化 playbook 编写，且易于复用

　playbook 是 Ansible 的主要管理方式，也是 ansible 功能强大的关键所在，playbook 通过多个 task 集合完成一类功能，这类功能的复杂度可以低，低到一个简单的操作也可以用 playbook 去实现，也可以非常高，编制出非常复杂的功能逻辑。然而，如果在复杂任务下，仅用一个 playbook 剧本去实现整个复杂逻辑将变得很难，且非常不容易维护，也没办法将这个复杂 playbook 复用到其他类似功能实现中去。这时就要用到 ansible role 的方式来管理 playbook 了，通过它来将复杂任务分解为比较小的部分，将原来复杂的 playbook 分割为多个文件，大大简化复杂 playbook 的编写。

　Ansible role 可以看成是一台或者多台主机的某些事情，分开进行 playbook 编写，通过规范化的目录结构来重新整理复杂 playbook，例如我们需要部署一个 nginx+was+mysql 数据库，我们可以设计以下目录格式：

　 其中 deploy_nginx_was_mysql.yaml 是 roles 的入口文件，例如：

　这里就可以根据 hosts 文件中定义的不同主机组来引用不同的 roles 进行相关的配置部署，并通过：

　ansible-playbook -i hosts deploy_nginx_was_mysql.yaml 来调用。

　hosts 文件中定义了 nginx、mysql 和 was 主机组相关信息。

　vars 目录下的文件中定义 playbook 中需要引用到的变量。

　roles 目录下则编制了 base_install、mysql_install、was_install、nginx_install 等四个不同 roles 的 playbook、配置模板和文件等内容。

　通过这样分拆的方式，一个复杂的 playbook 大大简化、清晰化，而且 roles 目录下的所有子 roles 都可以复用到其他项目中去使用，我们的任务就是编写一个个小型的 playbook，最后再用 role 的方式去整合，形成一个大的复杂的功能逻辑。

推荐访问:常见问题 管理平台 部署