
服务器只有一两台时,SSH登录以后手工安装Nginx并不麻烦;但当同样的配置需要重复到更多主机上,真正容易出现的问题往往不是命令不会写,而是不同机器执行步骤不一致、有人漏了一步,或者后续修改配置时又需要重新逐台处理。
Ansible提供了一种更适合重复操作的方式:通过Inventory定义需要管理的主机,再用Playbook描述软件是否应该安装、服务是否应该启动等目标状态。配置完成以后,同一个Playbook可以面向一组符合条件的服务器重复执行。
本文会从一个基础案例开始,使用Ansible安装并启动Nginx,再通过目标机上的软件包、服务状态和80端口检查部署结果。需要注意的是,正文采用CentOS 7作为历史测试环境,而CentOS Linux 7已经结束生命周期,因此这套命令更适合用来理解Ansible工作流程,不建议直接作为2026年新生产服务器的系统选型。
另外,Inventory中的组名必须与Playbook里的hosts保持一致,SSH账号、密码和目标机Python版本也会直接决定Playbook能否正常运行。实际环境中更推荐使用SSH Key和独立运维账号,并通过Ansible Vault等方式保护确实需要保存的敏感变量,而不是把root密码明文写进Inventory。
最后还会通过cpolar为SSH建立一条公网可达路径,演示控制端不在同一局域网时如何继续连接目标主机。这里解决的是SSH网络可达性,并不替代SSH自身的身份认证;如果扩展到大量服务器,更适合结合内网Ansible控制节点、VPN或跳板机等整体架构,而不是简单把每台生产服务器的SSH分别暴露到公网。

Ansible是一款开源的自动化运维工具,旨在简化配置管理、应用部署、任务编排和IT编排等操作。其核心设计理念是“简单、可靠、无侵入”,通过声明式语言实现对大规模基础设施的高效管控。
在传统运维模式下,面对数百台服务器的批量操作,往往依赖脚本循环执行SSH命令,不仅效率低下,还难以保证执行的一致性与可追溯性。Ansible的出现有效解决了这一痛点,使运维人员能够以一条命令完成跨节点的标准化操作。
核心优势:
Ansible无需在目标主机上安装额外客户端或代理程序,仅依赖标准SSH服务即可完成通信与指令下发。这显著降低了系统开销与维护复杂度,同时避免了因中心化代理服务故障导致的全局性风险。
利用成熟的SSH协议进行连接,天然支持密钥认证、跳板机、堡垒机等企业级安全策略,确保操作过程的安全合规。
Ansible的模块设计遵循幂等原则——无论Playbook被执行多少次,系统最终状态始终保持一致。这一特性对于生产环境中的配置修复、状态校验和持续同步至关重要。
使用结构清晰、易于阅读的YAML格式编写Playbook,大幅降低学习成本,提升协作效率与可维护性。
Ansible内置数千个模块,覆盖操作系统、网络设备、数据库、中间件及主流云平台,支持从基础资源管理到复杂业务编排的全场景自动化需求。
凭借上述特性,Ansible已成为DevOps实践中广泛采用的自动化引擎,助力企业实现高效、可靠、可重复的基础设施即代码管理。
更新所有系统软件包:
yum update -y 安装EPEL仓库(提供 Ansible 包):
yum install -y epel-release
安装ansbile:

验证是否安装成功:
ansible --version
确保你在playbook所在目录(假设是 /etc/ansible):
cd /etc/ansible编辑hosts文件,加入你所要监控的ip和他的用户名及密码:
[test]
ip ansible_ssh_user=用户名 ansible_ssh_pass=密码
编辑命令yml文件:
---
- name: 在主机上安装并启动Nginx
hosts: dbservers
become: yes
gather_facts: yes
tasks:
- name: 安装EPEL软件源(Nginx依赖)
yum:
name: epel-release
state: present
- name: 安装Nginx
yum:
name: nginx
state: present
- name: 启动Nginx服务并设置开机自启
systemd:
name: nginx
state: started
enabled: yes
然后使用ansible-playbook执行就好啦:
ansible-playbook -i hosts 3.yml
接下来我们去目标主机查看一下nginx是否安装成功(我这里是192.168.42.146):
输入下面目录:
rpm -q nginx # 检查Nginx是否已安装
systemctl status nginx # 检查Nginx服务状态
ss -tuln | grep ':80' # 检查80端口是否监听
netstat -tuln | grep ':80' # 检查80端口是否监听
检查到了,我们一键部署ansible就完成啦!
我们可以在hosts文件添加上百台主机,皆可以使用ansible命令一键安装。
如果公司突然要求你给上百台服务器部署任务,而你正躺在家里的沙发上享受难得的假期——不想回公司,又不在同一个局域网,远程访问内网机器成了难题……
别急!cpolar这时就派上用场了!
有了cpolar,你可以轻松穿透内网,安全、稳定地将本地服务暴露到公网,随时随地远程管理服务器,真正实现“人在家中坐,活在云上干”——假期不被打扰,工作照样高效完成!
cpolar是一款安全高效的内网穿透工具,无需公网IP或复杂配置,只需一条命令,即可将本地服务器、Web服务或任意端口映射到公网,让你随时随地远程访问内网应用,特别适合开发调试、远程运维和应急部署等场景。
cpolar 可以将你本地电脑中的服务(如 SSH、Web、数据库)映射到公网。即使你在家里或外出时,也可以通过公网地址连接回本地运行的开发环境。
❤️以下是安装cpolar步骤:
使用一键脚本安装命令:
sudo curl https://get.cpolar.sh | sh
安装完成后,执行下方命令查看cpolar服务状态:(如图所示即为正常启动)
sudo systemctl status cpolar
Cpolar安装和成功启动服务后,在浏览器上输入虚拟机主机IP加9200端口即:【http://ip:9200】访问Cpolar管理界面,使用Cpolar官网注册的账号登录,登录后即可看到cpolar web 配置界面,接下来在web 界面配置即可:
打开浏览器访问本地9200端口,使用cpolar账户密码登录即可,登录后即可对隧道进行管理。

通过配置,你可以在本地 WSL 或 Linux 系统上运行 SSH 服务,并通过 Cpolar 将其映射到公网,从而实现从任意设备远程连接开发环境的目的。

创建成功后,打开左侧在线隧道列表,可以看到刚刚通过创建隧道生成了公网地址,接下来就可以在其他电脑或者移动端设备(异地)上,使用任意一个地址在终端中访问即可。

通过 Cpolar 提供的公网地址和端口,就可以使用ansible进行远程部署啦!
接下来我们操作一下。
修改hosts配置文件:
[dbservers]
15.tcp.cpolar.top ansible_user=root ansible_port=13633 ansible_password=***
接下来我们执行配置node_exporter文件:
ansible-playbook -i hosts 3.yml
执行成功,我们去对应主机查看nginx是否安装成功:

我们可以看见,目标主机已经成功安装~
使用cpolar为其配置TCP地址,该地址为固定地址,不会随机变化。

选择区域和描述:有一个下拉菜单,当前选择的是“China VIP”。 右侧输入框,用于填写描述信息。 保留按钮:在右侧有一个橙色的“保留”按钮,点击该按钮可以保留所选的TCP地址。 列表中显示了一条已保留的TCP地址记录。

登录cpolar web UI管理界面,点击左侧仪表盘的隧道管理——隧道列表,找到所要配置的隧道ssh,点击右侧的编辑。

修改隧道信息,将保留成功的TCP端口配置到隧道中。
点击更新。

创建完成后,打开在线隧道列表,此时可以看到随机的公网地址已经发生变化,地址名称也变成了保留和固定的TCP地址。

这样我们的ansible操作就没有任何的阻碍啦!
完成以上配置后,本文已经跑通了Ansible从Inventory读取目标主机、执行Playbook、安装Nginx并启动服务的基础流程,同时通过软件包、systemd状态和80端口对单台测试服务器进行了人工验证。
这套案例更适合用来理解Ansible“定义目标主机+描述期望状态+统一执行”的工作方式。虽然同一个Inventory组可以继续加入更多服务器,但本文实际只验证了单节点,并没有进行上百台主机的并发、批次发布、失败恢复和回滚测试,因此不能把当前结果直接等同于完整的大规模生产部署方案。
正文使用的CentOS 7已经结束生命周期,现代Ansible版本对控制端和目标端Python版本的要求也已经发生变化。如果准备在新环境中重新实施这套方案,应优先选择仍受支持的操作系统,并根据实际Ansible版本重新确认软件包模块和Python兼容性。
远程连接部分通过cpolar把目标主机的SSH服务转换成外部可达的TCP地址后,Ansible可以把对应域名和公网端口写入Inventory继续连接。不过公网可达并不等于安全,长期远程运维应优先采用SSH Key、独立运维用户和最小权限,并避免把root密码明文保存在Inventory中。
如果需要管理的是一整组内网服务器,更合理的思路通常是让Ansible控制节点本身位于服务器网络内,再通过受控的远程入口连接控制节点,或者结合VPN、堡垒机和SSH跳板机制,而不是为每台目标服务器分别开放公网SSH。
从Inventory、Playbook到Nginx安装与远程SSH连接,本文完成的是一套Ansible批量运维的基础实践流程。