拓冰建站拓冰建站
首页 / 资讯中心 / 正文

Ansible 2.9.27生产环境实战:批量分发文件与权限配置

简介Ansible 2.9.27 是针对 CentOS 7/RHEL 7 的自动化运维工具包面向系统管理员与运维工程师用于在离线或内网环境中快速完成配置管理、应用发布、服务编排和批量任务执行。整套资源共 29 个文件其中 22 个 RPM 软件包构成核心主体覆盖 Ansible 主程序以及 Python 依赖、sshpass、PyYAML 等常用组件另外 3 个 gz、3 个 bz2 和 1 个 xml 为 YUM 仓库元数据可据此搭建本地 yum 源便于批量安装与依赖解析压缩包整体约 19.29MB。已有 632 人学习下载特别适用于生产服务器无法访问外网、或需要统一版本管控的团队环境。借助该资源包用户无需逐一下载依赖即可部署一套可运行的 Ansible 2.9.27 环境配合 Playbook 声明式语法与 copy、yum、service、template 等常用模块可轻松实现对服务器配置、软件包、服务状态及配置文件模板的自动化管理显著提升运维效率和可重复性。 最近接手了一套生产环境控制节点上装的正是 ansible-2.9.27。最开始我还琢磨着要不要升级到新版本毕竟这两年自动化运维工具更新速度很快新特性层出不穷。但翻了一圈文档、查了一堆社区反馈之后我决定继续留在这个“过气”版本上。原因很简单对于企业内部几百台 Linux 节点的批量分发、授权、巡检这些日常操作2.9.27 足够稳定生态也完整网上几乎能找到所有踩坑答案。如果你和我一样手里有一套老环境或者在新环境里因为兼容性被迫停留在 2.9 系列那么这篇文章就是给你准备的。我会从为什么选这个版本说起然后完整走一遍安装部署流程接着用“复制文件到所有节点并授权 777 权限”这个典型需求作为实战案例最后把那些文档里不会明说的坑和心得一起抖出来。1. 为什么我仍然选择 2.9.27 这个版本1.1 2.9.27 在版本谱系中的位置ansible 在 2.10 版本之后做了重要的结构拆分原本随主发行版一起打包的大量模块被迁移到独立的 collection 仓库中。这意味着如果你习惯了“装完 ansible 之后ping、copy、yum、service 这些模块随口就能用”那么在 2.10 及以后版本中你还需要额外关心是否安装了对应的 collection。而对于 2.9.27 这个系列它是 2.9 分支的收尾版本所有常用模块还是整体打包的安装之后不需要额外的手工装配直接就能用。更重要的是2.9.27 修复了 2.9 系列前面若干版本中的一些安全问题和稳定问题。对于没有特殊新特性需求的生产环境它就是 2.9 分支里最值得装的一个版本。1.2 新旧版本切换带来的生态变化可能有人会问直接上最新版不是更好吗从功能角度确实如此但实际情况要复杂得多。Playbook 兼容性老项目里的 Playbook 很可能基于 2.9 语法写的比如循环的with_items、with_lines等旧式写法。在 2.9.27 底下跑得清清楚楚换到新版可能会出现弃用警告甚至是语法错误。插件和自定义模块不少企业有自己写的一批自定义模块或插件它们是针对 2.9 的 API 开发的在旧版本上运行非常稳定升级后未必还能正常加载。文档和社区经验2.9 系列的教程、案例、问答在过去几年里积累得异常丰富遇到问题基本一搜就有答案试错成本低。1.3 什么场景下 2.9.27 是稳妥之选如果你的环境有以下特征2.9.27 会是一个相当稳妥的选择主要是做批量命令执行、文件分发、服务状态管理、系统配置修改这类的日常运维操作没有使用到 2.10 才引入的新模块或者只在少量特定场景用到被管理节点的 Python 环境比较复杂2.9 对 Python 2 和 Python 3 的兼容能力更加宽容维护团队对旧版本更熟悉希望把精力放在业务更新上而不是折腾 ansible 本身的升级上。2. 安装部署从零跑通 ansible-2.9.27 的可行路径2.1 控制节点需求与前置依赖检查ansible 的控制节点通常建议安装在一台 Linux 主机上像 CentOS 7、Ubuntu 18.04/20.04 这些常见发行版都没问题。控制节点主要依赖 Python2.9.27 版本在 Python 2.7 和 Python 3.5 环境下都能运行但在当前主流发行版上保险起见还是用 Python 3 环境。需要提前确认两件事python 是否已经安装版本和路径pip 是否可用或者 yum 源里是否包含 ansible 2.9 系列。注意如果管理节点只有 Python 3.12 这种非常新的版本2.9.27 在部分环境里可能会因为 cryptography 等依赖库的版本问题出现编译或导入失败。这种时候建议使用系统自带 Python 版本或者直接采用包管理器安装。2.2 通过包管理器安装的完整步骤如果你用的是 CentOS 或者 RHEL 系列最省心的方式是通过 EPEL 源安装。在较老的环境中EPEL 里的 ansible 2.9 版本通常可以直接拿到。yum install -y epel-release yum install -y ansible ansible --version如果直接安装到的不是 2.9.27而是更高的 2.9.x比如 2.9.27 之前或之后的补丁版本在大多数情况下也可以接受但如果你希望精确锁版本可以通过指定版本号的方式安装yum install -y ansible-2.9.27不过不同发行版源里的版本号命名可能不太一样。有些源的软件包名是ansible而对应版本是通过ansible --version查看的。安装后如果版本不对还可以考虑 pip 安装方式。Ubuntu/Debian 系列可以通过 PPA 安装apt update apt install -y software-properties-common add-apt-repository --yes --update ppa:ansible/ansible apt install -y ansiblePPA 源默认提供的往往是较新的 ansible 版本因此如果你想精确定位 2.9.27建议还是用 pip 安装。2.3 通过 pip 安装以适配自定义环境当包管理器源里找不到目标版本或者你希望在独立的 Python 虚拟环境里安装时pip 是最通用的方式。python3 -m venv /opt/ansible-venv source /opt/ansible-venv/bin/activate pip install --upgrade pip pip install ansible2.9.27安装完成后可以把虚拟环境里的可执行文件做软链接方便系统全局使用ln -s /opt/ansible-venv/bin/ansible /usr/local/bin/ansible ln -s /opt/ansible-venv/bin/ansible-playbook /usr/local/bin/ansible-playbook ln -s /opt/ansible-venv/bin/ansible-doc /usr/local/bin/ansible-doc通过 pip 安装的好处是能够精确控制 ansible 版本不受系统源更新策略影响。坏处是你必须自己保证依赖库如cryptography、yaml、jinja2能够正常安装。遇到编译错误时先尝试升级setuptools和wheel大多数情况下可以解决。2.4 安装后必须做的验证与配置安装完成不代表万事大吉第一步先确认版本ansible --version看到类似ansible 2.9.27的输出就说明安装成功。接下来需要创建基础目录结构mkdir -p /etc/ansible默认配置文件在/etc/ansible/ansible.cfg如果你是通过 pip 在虚拟环境安装的可能不会自动生成这个目录和文件。可以手动创建一份最简配置[defaults] inventory /etc/ansible/hosts host_key_checking False retry_files_enabled False其中host_key_checking False是很多新手最容易忽略的配置。如果不关闭首次连接时的指纹确认第一次批量执行命令时会因为需要交互确认而导致批量任务卡住。当然如果你的安全规范要求严格校验主机指纹可以不关但需要提前把指纹批量写进 known_hosts。3. 菜鸟到入门核心概念与第一个命令3.1 inventory描述你的节点清单inventory 就是一组被管理节点的清单默认写在/etc/ansible/hosts。它可以是静态文件也可以是动态脚本。最常见的静态写法如下[web] 192.168.1.11 192.168.1.12 192.168.1.13 [db] 192.168.1.21 ansible_userroot ansible_ssh_port22你可以把节点按业务分组也可以单独给某个节点指定连接用户和端口。2.9.27 支持分组嵌套还支持为组设置变量[web:vars] ansible_userroot ansible_python_interpreter/usr/bin/python3这个ansible_python_interpreter变量非常关键。如果被管理节点同时存在 Python 2 和 Python 3或 Python 路径不是默认位置不显式声明会造成模块执行失败。2.9 版本对解释器的自动发现逻辑不像新版本那么完善手动指定能少踩很多坑。3.2 ansible 命令的基础结构与常用参数ansible 的单个命令格式通常是ansible 主机组或主机模式 -m 模块 -a 模块参数常用的连接参数有-i指定 inventory 文件路径-u连接用户-k提示输入 SSH 密码--become切换成 root 或者提权类似于 sudo--become-userroot提权到指定用户-K提示输入 sudo 密码--list-hosts列出匹配到的主机列表不实际执行。其中提权参数是很多初学者的分水岭。如果用自己的普通用户连接目标机器但需要执行 root 权限的操作必须加上--become否则会因为权限不足直接报错。3.3 第一个批量操作的完整示例先做一个最经典的连通性检查ansible web -i /etc/ansible/hosts -m ping这里的ping模块并不是 ICMP ping而是测试控制节点到被管理节点的 Python 通道和 SSH 连接是否正常。只要返回pong就代表链路没问题。然后执行一条 shell 命令查看所有 web 服务器的内存ansible web -i /etc/ansible/hosts -m shell -a free -hshell模块通过远程主机的 shell 执行命令也可以使用command模块但command模块不支持管道符、重定向等特殊字符而shell模块可以。比如ansible web -i /etc/ansible/hosts -m shell -a cat /etc/redhat-release | awk {print \$1}这里注意转义问题如果用 shell 变量需要小心在本地 shell 中的$符号。4. 把文件复制到所有节点并授权 777 权限从需求到落地4.1 一个看似简单但容易翻车的需求“把配置包复制到所有节点并授权 777 权限。”这是 ansible 菜鸟教程里最常被提到的需求之一但实际执行时却有不少人翻车。翻车点主要在于复制文件后文件默认属主和属组是root:root但如果你的连接用户是普通用户并通过 sudo 提权可能出现属主不一致通过shell模块执行chmod 777如果中途有节点执行失败没法保证一致性重复执行时因为文件已经存在且权限可能已被修改模块可能会报错或者不做任何处理。所以不要“复制后再用 shell 授权”而是直接利用copy模块的mode参数一次性完成。4.2 用 copy 模块一次完成分发与授权基础命令如下ansible web -i /etc/ansible/hosts -m copy -a src/data/scripts/deploy.sh dest/opt/deploy.sh ownerroot grouproot mode0777这里有几个细节src是控制节点上的本地路径dest是目标节点上的绝对路径mode最好写成0777而不是777避免数字被当成八进制转换时出现歧义owner和group如果不指定默认使用当前连接用户的身份建议显式声明。如果你想在复制的同时不改动原文件属性也可以先复制后授权但更推荐一步到位。对应的 Playbook 写法如下--- - name: 分发 deploy.sh 并授权 777 hosts: web become: yes tasks: - name: 复制脚本到所有节点 copy: src: /data/scripts/deploy.sh dest: /opt/deploy.sh owner: root group: root mode: 0777使用become: yes表示执行提权这样即使通过普通用户连接也能把文件属主改为 root。4.3 批量操作中的幂等性与权限校验ansible 模块设计强调幂等性也就是说同一个任务重复执行多次最终结果应该一致并且只有真正发生变更时才触发操作。用copy模块设置了mode0777后如果你手动把目标节点上的文件权限改成 0755再次执行 ansible 会发现模块做了变更把权限纠正回 0777。如果你没有修改权限重复执行会显示ok而不是changed说明并没有额外动作。这种特性在处理大规模节点时非常重要。你可以放心地重复执行同一个 Playbook而不用担心中断后的残留状态。也可以先验证当前权限再决定是否执行类似于预检ansible web -i /etc/ansible/hosts -m shell -a stat -c %a /opt/deploy.sh这条命令会输出所有节点上目标文件的权限数字快速确认哪些节点不符合预期。4.4 实战扩展目录分发、临时文件与清理如果你要分发的是一个目录而不是单个文件可以改用synchronize模块或者直接在copy模块中指定目录的src但要注意copy对目录的处理逻辑是会将目录本身复制到 dest 下而不是将目录内的内容直接合并到 dest。举个例子如果希望通过一次任务把所有节点上的/opt/service目录替换为控制节点上的版本可以使用- name: 同步配置目录 synchronize: src: /data/service/ dest: /opt/service/ delete: yes recursive: yes注意synchronize的delete: yes会删除目标目录中源目录不存在的文件这一点和 rsync 的行为一致使用前要谨慎。另外在实际操作中我常常需要把某些文件分发过去临时执行执行完再清理掉。比如分发一个监控采集脚本跑完以后删除。这个过程可以用两个 task 完成也可以直接使用script模块它会把本地脚本推送到远端直接执行不需要手动清理ansible web -i /etc/ansible/hosts -m script -a /data/scripts/collect.shscript模块非常实用尤其是批量执行临时脚本时省去了复制和授权两步。5. 实际使用中容易踩的坑与我的最后提醒5.1 权限写法与 Python 解释器问题关于mode参数我见过不止一个人写mode: 777结果在某些情况下 ansible 会按照十进制数解析最终生成的权限完全出乎意料。虽然 2.9.27 大多数场景下能自动处理但为了稳妥强烈建议在 YAML 里加引号写成mode: 0777。另一个高频坑就是ansible_python_interpreter。在 2.9.27 环境下如果被管理节点的默认 Python 是 3但某些模块依赖 Python 2 的库就会报类似ModuleNotFoundError的错误。正确的做法是明确每个组或每个主机的 Python 解释器路径。可以在 inventory 里直接声明[web:vars] ansible_python_interpreter/usr/bin/python3也可以在ansible.cfg里统一设置[defaults] interpreter_python /usr/bin/python3但在 2.9.27 中interpreter_python并不是所有环境都生效。如果你发现无论怎么设置远端总是调用/usr/bin/python那么请检查被管理节点上是否已经安装目标 Python并且确认ansible_python_interpreter变量是否真的传到了远端。5.2 SSH 连接参数与并发控制的调优当一个 Playbook 要同时对几十上百台机器执行时默认并发数和 SSH 连接参数显得格外重要。在ansible.cfg中可以调整[ssh_connection] forks 20 ssh_args -o ControlMasterauto -o ControlPersist60sforks是并发数默认只有 5这意味着同一时间只有 5 台机器在执行数量一大任务耗时就会很长。对于几百台机器的场景建议调大到 20 或 50但也不要无脑调高否则控制节点本身的 SSH 进程开销会很大。ControlMaster和ControlPersist是 SSH 连接复用参数开启后在一段时间内复用同一个 SSH 连接可以显著降低重复握手带来的延迟。这个参数在 2.9.27 中效果非常明显尤其是执行多条针对同一批机器的任务时。5.3 给新手的几点建议我在 ansible 2.9.27 上折腾了这么久最深切的体会是先写一个节点测试再全量执行。很多新手一上来就把整个生产环境加进 inventory接着执行一个大规模的 Playbook结果因为某个节点的 SSH 密码不同、Python 路径不对、sudo 规则受限等原因导致大面积失败。正确做法是先用单台测试节点跑通整个流程确认无误后再全量执行。其次是学会看报错信息。2.9 版本的报错信息虽然不像新版本那么友好但大多数情况下已经给出了关键线索。比如Failed to connect to the host via ssh说明连接阶段就有问题Module script failed说明模块在远端执行失败了FAILED! { msg: Using a SSH password instead of a key is not possible because Host Key checking is enabled}这是提示你关闭 host_key_checking或者把主机指纹加入 known_hosts。最后一个建议是善用ansible-doc。如果你不确定某个模块支持哪些参数直接运行ansible-doc copy它会输出完整的模块说明、参数列表和使用示例。2.9.27 的本地文档虽然旧但那是和这个版本完全匹配的比网上很多新版本的语法要靠谱。以上是我在使用 ansible-2.9.27 过程中的大部分实战经验。如果你正准备在生产环境部署这套自动化体系建议先在测试环境完整跑一遍再逐步扩大范围。配置文件的每一处细节都可能在大规模执行前变成隐藏的地雷提前排查清楚后面才能真正做到“一键操作”。本文还有配套的精品资源点击获取
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门