在数据库运维里，MongoDB 的部署通常比关系型数据库更容易出现细节问题，比如副本集成员的 hosts 配置、keyfile 权限、仲裁节点角色等。使用 Ansible 的社区角色 mongodb-ansible-role 能把这些步骤统一起来，避免每台服务器单独操作。这个角色的核心思路是把 MongoDB 的安装、配置、服务启动、副本集初始化和用户管理拆成一系列可幂等执行的任务，通过 inventory 和变量文件描述目标状态。
一、安装角色与设计Inventory
安装角色最直接的方式是通过 ansible-galaxy 命令从 Galaxy 或 GitHub 获取。对于离线环境，也可以把角色目录放进项目仓库统一版本管理。
ansible-galaxy install community.mongodb.mongodb_ansible_role # 或者从源码仓库安装 ansible-galaxy install git+https://github.com/mongodb/ansible-role.git
这里需要注意，不同来源的角色名称可能不同。安装完成后，可以在 playbook 的 roles 字段中引用，例如 roles: - mongodb-ansible-role。如果项目需要固定版本，建议在 requirements.yml 中声明版本号，避免角色更新引入不兼容变更。
Inventory 设计直接影响后续变量继承和任务分发。角色会根据主机名或组名判断节点类型。一个典型的副本集 inventory 如下：
all:
children:
mongodb_replset:
hosts:
mongo01:
ansible_host: 192.168.10.11
mongo02:
ansible_host: 192.168.10.12
mongo03:
ansible_host: 192.168.10.13如果希望在一台机器上跑多个实例，可以在 inventory 中定义多个逻辑主机，并为每个实例设置独立的 mongod_port 和 dbpath。角色通过变量 mongodb_replication_replset 指定副本集名称，通过 mongodb_replication_params 控制副本集初始化参数。节点角色可以通过组变量区分，例如把 mongo01 设为 primary 优先节点，其他节点作为 secondary。
二、核心变量与配置模板
mongodb-ansible-role 暴露了大量变量，从安装源、版本号到安全选项都有覆盖。常见的变量包括 mongodb_version、mongodb_package、mongodb_conf_bind_ip、mongodb_conf_port、mongodb_conf_dbpath、mongodb_conf_logpath 等。角色会根据操作系统选择 yum 或 apt 源，如果使用官方仓库，需要在变量中配置 mongodb_repository_url 或启用 mongodb_repo_use_ssl。
配置文件采用 Jinja2 模板渲染，变量名通常以 mongodb_conf_ 开头。例如监听地址和端口：
mongodb_conf_bind_ip: "0.0.0.0" mongodb_conf_port: 27017 mongodb_conf_dbpath: "/var/lib/mongodb" mongodb_conf_logpath: "/var/log/mongodb/mongod.log" mongodb_conf_logappend: true mongodb_conf_fork: false
角色默认会关闭 fork，转由 systemd 管理进程。这样更符合现代 Linux 服务管理习惯，避免进程脱离控制。另一个关键变量是 mongodb_conf_storage_engine，旧版本可选择 mmapv1，新版本默认为 wiredTiger。wiredTiger 支持压缩和文档级并发，通常不需要修改，但如果有特殊需求可以通过 mongodb_conf_wiredtiger_cache_size_gb 调整缓存。
安全相关变量包括 mongodb_security_authorization 和 mongodb_security_keyfile_path。启用认证时需要提供 keyfile 内容或路径，角色会自动生成 keyfile 文件并设置为 600 权限。这里要注意：副本集所有成员的 keyfile 必须完全一致，否则节点无法通信。角色通过变量 mongodb_keyfile_content 或文件路径统一分发，避免手动拷贝出错。
三、副本集初始化与用户管理
角色可以在安装完成后自动执行副本集初始化。关键变量 mongodb_replication_replset 指定副本集名称，mongodb_replication_params 可以传入优先级、投票数等参数。初始化任务通常只在第一次运行时触发，重复执行会检测现有副本集状态，避免重复 rs.initiate。示例 playbook：
- name: Deploy MongoDB replica set
hosts: mongodb_replset
become: yes
vars:
mongodb_version: "6.0"
mongodb_replication_replset: "rs0"
mongodb_replication_params:
- _id: "rs0"
members:
- _id: 0
host: "mongo01:27017"
priority: 2
- _id: 1
host: "mongo02:27017"
- _id: 2
host: "mongo03:27017"
arbiterOnly: true
roles:
- community.mongodb.mongodb_ansible_role上面的配置把 mongo03 设置为仲裁节点，只参与选举不存储数据。仲裁节点机制适合奇数成员数量不足又想避免平票的场景。不过仲裁节点不能承载数据副本，可靠性不如完整数据节点，生产环境更建议使用三个数据节点或增加 hidden 节点。
用户管理可以通过角色提供的 mongodb_user_admin_password 和 mongodb_root_admin_password 等变量完成。角色会在启用认证后创建 root 用户和业务用户。除了基本的 root 用户，还可以用 mongodb_users 列表声明业务账号、角色和密码。示例：
mongodb_users:
- name: appuser
password: "AppUserPassw0rd"
roles:
- db: "appdb"
role: "readWrite"
- name: backupuser
password: "BackupPassw0rd"
roles:
- db: "admin"
role: "backup"密码建议使用 Ansible Vault 加密，不要把明文密码提交到版本库。角色在每次执行时会同步用户列表，新增或修改用户会更新，已删除的用户是否会清理取决于具体版本，操作前最好确认文档。启用认证后，所有数据库连接需要指定用户名和密码，应用程序配置也要同步变更。
四、常见部署组合与验证
除了副本集，角色也支持单机模式、分片集群的 config server 和 mongos 组件。通过设置 mongodb_replication_replset 为空或使用不同角色入口可以部署单机。分片集群通常需要额外的 shard 和 config server 部署，再单独安装 mongos，角色对 mongos 的支持因版本而异，使用前建议查阅项目 README。
验证部署结果可以通过 systemctl status mongod 查看服务状态，再用 mongosh 命令确认副本集成员健康。例如：
systemctl status mongod --no-pager mongosh --eval "rs.status()" admin -u root -p 'YourPassword'
输出中应该看到 health 为 1，stateStr 为 PRIMARY 或 SECONDARY。如果某个节点一直处于 STARTUP 状态，通常是 keyfile 不一致、bind_ip 未包含主机名或防火墙拦截。角色生成的配置文件位于 /etc/mongod.conf，可以检查 systemLog 路径中的日志找到具体错误。另一个常见问题是 SELinux 阻止访问数据目录，可以调整 SELinux 上下文或使用策略模块放行。
日常运维中，配置变更应通过修改 playbook 变量并重新执行，而不是直接登录服务器改 mongod.conf。角色的幂等性会对比模板渲染结果和现有文件，只更新变化的部分。需要升级 MongoDB 版本时，调整 mongodb_version 变量并执行 playbook，角色会更新仓库并安装目标版本，但大版本升级前仍需备份数据并阅读官方升级说明。
