文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本篇技术指南围绕 90DaysOfDevOps 学习路线中 Day 68 的核心内容展开在 2022/Days/Configmgmt 的 ansible-scenario5/6/7 三个实战场景中系统地讲解 Ansible 的 Tags 标签机制、两类变量Ansible Facts 与用户自定义变量的采集与使用、独立 Inventory 文件的切换方法并完整走通「Vagrant 启动数据库节点 → ansible-galaxy 生成 mysql 角色 → 编写 handlers/tasks/templates → 用 Playbook 一键部署 MySQL 并验证」的数据库服务器自动化部署流程。读完本文你将掌握用--tags定向执行 Playbook、用group_vars/host_vars清理并管理变量、用ansible_facts与 Jinja2 循环生成动态 Nginx 负载均衡配置以及从零搭建 MySQL 角色的完整方法。Tags让大型 Playbook 按需定向执行在 Day 67 的 playbook4.yml 中我们一次性编排了 webservers 与 proxy 两个主机组。到了 Day 68Playbook 越来越大每次ansible-playbook都会把其中的每一个 play 和 task 完整跑一遍。如果环境中存在超大型、超长 Playbook这种做法并不高效——Tags 正是用来解决这个问题的它可以让我们把 Playbook 中的执行单元拆分开按需选择执行范围。以 ansible-scenario5/playbook5.yml 为例在 play 级别为两个主机块分别打上web与proxy标签- hosts: webservers become: yes vars: http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 66! roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy查看并定向运行标签先用ansible-playbook playbook5.yml --list-tags确认 Playbook 中已定义的所有标签命令会按 play 逐一列出web和proxy如果我们只想针对 proxy 执行运行ansible-playbook playbook5.yml --tags proxy从输出可以看到只有 proxy 对应的 play 被执行webservers 部分被完整跳过更细粒度的标签用法除了 play 级别tags 同样可以添加到单个 task 级别从而实现对在哪台机器上做什么事的精准控制。常见的实践包括按应用维度打标签例如apache、nginx、mysql按生命周期阶段打标签例如install、configure、remove让同一套任务可以分别执行安装、配置或卸载使用tag: always只要任务被标记为always无论命令行中传入--tags是什么值该任务都会在每次ansible-playbook运行时强制执行适合放置那些必须每次执行的基础性任务。还可以将多个标签打包在一起ansible-playbook playbook5.yml --tags proxy,web会运行所有带proxy或web标签的内容。在当前示例中这等同于运行整个 Playbook但如果我们有更多其他 play这种组合式定向执行的价值就会立刻显现。同一个 play 或 task 也支持同时声明多个标签。VariablesAnsible 的两类变量体系Ansible 中主要有两类变量用户自定义变量User created由我们在 Playbook、变量文件或 inventory 中自行声明Ansible Facts由 Ansible 在执行时自动从受管主机采集的系统信息。Ansible Facts自动采集的系统信息每次运行 Playbook 时输出中都会出现一个我们没有显式定义、却总会执行的任务——Gathering facts。这些自动采集的 facts 是可以在自动化任务中直接引用的宝贵变量如果想完整查看某台主机的 facts可以使用 ad-hoc 命令ansible proxy -m setup终端会输出大量 JSON 格式的系统信息——包括 IP 地址、架构、BIOS 版本等。由于输出量巨大更实用的做法是重定向到文件ansible proxy -m setup facts.json仓库中已保存了这份真实采集结果见 ansible-scenario5/facts.json打开该文件可以看到针对目标主机的全部信息IP 地址、架构、BIOS 版本……这些信息都可以在 Playbook 中作为变量引用实现真正的根据机器实际情况做自动化。用 facts Jinja2 循环生成动态负载均衡配置Day 67 中我们的 Nginx 模板 mysite.j2 把两台 webserver 的 IP 硬编码在upstream块中。利用ansible_facts我们可以把模板改造成动态生成在 mysite.j2 中用 Jinja2 的 for 循环遍历groups[webservers]组这样无论以后向该组添加还是移除 webserver负载均衡配置都会自动随之变化无需手工修改#Dynamic Config for server {{ ansible_facts[nodename] }} upstream webservers { {% for host in groups[webservers] %} server {{ hostvars[host][ansible_facts][nodename] }}:8000; {% endfor %} } server { listen 80; location / { proxy_pass http://webservers; } }循环中通过hostvars[host]访问组内每个成员各自的ansible_facts。需要注意这种基于主机名的动态配置要正常工作前提是环境中已配置好相应的名称解析name resolution。用户自定义变量从 Playbook 迁移到 group_vars用户自定义变量就是我们自己创建的变量。Day 68 的 playbook6.yml 最初沿用了 Day 66 的做法在 webservers 块中通过vars:声明三个变量- hosts: webservers become: yes vars: http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68! roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy为了让 Playbook 保持整洁可以将变量抽离到独立文件中这正是 ansible-scenario6 场景做的事在场景根目录下创建group_vars文件夹在group_vars下再创建all文件夹——表示所有主机组都会获得这些变量在all中创建common_variables.yml把 Playbook 中的三个变量连同vars:关键字整体迁移进去http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68!由于这些是全局变量我们还可以把 NTP、DNS 服务器等公共配置一并放进来。变量作用域完全由这个目录结构决定group_vars/all/下所有组共享。迁移之后playbook6.yml 变得非常干净- hosts: webservers become: yes roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy变量文件定义在 ansible-scenario6/group_vars/all/common_variables.yml对应的 Nginx 模板位于 ansible-scenario6/roles/nginx/templates/mysite.j2。迁移后我们可以在模板的 for 循环中直接引用http_port变量把写死的:8000改为变量引用#Dynamic Config for server {{ ansible_facts[nodename] }} upstream webservers { {% for host in groups[webservers] %} server {{ hostvars[host][ansible_facts][nodename] }}:{{ http_port }}; {% endfor %} } server { listen 80; location / { proxy_pass http://webservers; } }同理我们还可以在 apache2 角色的 index.html.j2 中引用ansible_facts[nodename]让每个 webserver 的欢迎页显示自己是谁便于验证负载均衡是否真的在轮询分发html h1{{ html_welcome_msg }}! Im webserver {{ ansible_facts[nodename] }} /h1 /html运行ansible-playbook playbook6.yml后反复访问负载均衡器地址会看到请求轮流落在组内的不同 webserver 上从而验证动态配置生效除此之外我们还可以在场景根目录下新建host_vars文件夹并创建web01.yml从而针对单个主机定制消息或差异化配置实现 per-host 级别的变量覆盖。Inventory Files多环境主机清单到目前为止我们一直使用/etc/ansible目录下的默认 hosts 文件来确定受管主机。但生产环境通常需要区分多个环境——例如 production 和 staging——此时完全可以创建多个独立的 inventory 文件每个文件对应一套服务器/节点清单。创建好自定义清单文件后通过-i参数指定使用哪一个例如ansible-playbook -i dev playbook.yml-i dev中的dev可以是文件或目录Ansible 会读取该清单中的主机与组定义。此外inventory 文件内部还可以为主机或组定义变量例如environmentdev这些变量可以在 Playbook 中引用或打印输出——例如在培训示例中他们把 inventory 里定义的 environment 变量注入负载均衡器网页模板让页面消息直接展示当前所属环境。Deploying our Database server部署数据库服务器目前 Vagrant 环境里还剩最后一台机器db01没有启动和配置。启动节点并打通 SSH在 Vagrantfile 所在目录执行vagrant up db01启动数据库节点节点启动并可以访问后需要先把 SSH 公钥拷贝过去以便 Ansible 控制节点免密连接vagrant up db01 ssh-copy-id db01后续所有配置工作将在 ansible-scenario7 目录中完成。用 ansible-galaxy 初始化 mysql 角色执行ansible-galaxy init roles/mysql自动生成一个名为 mysql 的新角色标准目录结构包含 defaults、handlers、meta、tasks、templates、tests、vars 等子目录。在 Playbook 中追加 database play在 playbook7.yml 中新增一个针对数据库的 play 块database组已在/etc/ansible/hosts中定义该组应用common角色和我们新建的mysql角色并打上database标签这样后续就可以像前面学的 tags 用法一样只针对数据库定向执行- hosts: webservers become: yes roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy - hosts: database become: yes roles: - common - mysql tags: database填充 mysql 角色的 handlers 与 tasksansible-galaxy init会生成完整的目录树接下来只需按需填充文件Handlers — main.yml服务重启处理器被 template 任务通过notify触发# handlers file for roles/mysql - name: restart mysql service: name: mysql state: restartedTasks — 三个文件install_mysql.yml、main.yml、setup_mysql.ymlinstall_mysql.yml负责安装 MySQL 相关软件包并确保服务运行见 ansible-scenario7/roles/mysql/tasks/install_mysql.yml- name: Install Common packages apt: name{{ item }} statelatest with_items: - python3-pip - mysql-client - python3-mysqldb - libmysqlclient-dev - name: Ensure mysql-server is installed latest version apt: namemysql-server statelatest - name: Installing python module MySQL-python pip: name: PyMySQL - name: Ensure mysql-server is running service: name: mysql state: startedmain.yml是一个指针文件通过import_tasks引入上面两个任务文件注意旧写法include即将被弃用应采用import_tasks# tasks file for roles/mysql - import_tasks: install_mysql.yml - import_tasks: setup_mysql.ymlsetup_mysql.yml负责生成 MySQL 配置文件、创建数据库用户和数据库见 ansible-scenario7/roles/mysql/tasks/setup_mysql.yml- name: Create my.cnf configuration file template: srctemplates/my.cnf.j2 dest/etc/mysql/conf.d/mysql.cnf notify: restart mysql - name: Create database user with name devops and password DevOps90 with all database privileges community.mysql.mysql_user: login_unix_socket: /var/run/mysqld/mysqld.sock login_user: {{ mysql_user_name }} login_password: {{ mysql_user_password }} name: {{db_user}} password: {{db_pass}} priv: *.*:ALL host: % state: present - name: Create a new database with name 90daysofdevops mysql_db: login_user: {{ mysql_user_name }} login_password: {{ mysql_user_password }} name: {{ db_name }} state: present仓库中的实际实现setup_mysql.yml比文档示例更进一步mysql_user的priv写为*.*:ALL,GRANTmysql_db改用新创建的db_user/db_pass登录并额外通过lineinfile修改/etc/mysql/mysql.conf.d/mysqld.cnf中的bind-address 0.0.0.0并触发重启从而启用 MySQL 远程登录——这是多节点架构中应用服务器连接数据库所必需的。可以看到任务中大量配置密码、用户名、数据库名都通过变量引用这些变量统一存放在group_vars/all/common_variables.yml中见 ansible-scenario7/group_vars/all/common_variables.ymlhttp_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68! mysql_user_name: root mysql_user_password: vagrant db_user: devops db_pass: DevOps90 db_name: 90DaysOfDevOpstemplates 目录中的 my.cnf.j2 模板内容如下仓库版本额外加入了[client]段固化 root 登录凭据[mysql] bind-address 0.0.0.0运行 Playbook 部署数据库虚拟机已启动、配置文件就绪后可以执行完整部署ansible-playbook playbook7.yml包含此前所有内容也可以只针对 database 组定向部署ansible-playbook playbook7.yml --tags database--tags database只会运行我们新写的 mysql 相关配置。作者在首次只针对 database 标签运行时遇到了一个报错——提示目标机没有安装 pip3Python解决方法是把它补进 common 角色的公共任务中一并安装修复后再次运行 Playbook得到成功变更的结果验证 db01 上的 MySQL部署完成后应从控制节点登录 db01 确认一切符合预期。先通过ssh db01连接到新配置的机器然后用 root 连接 MySQL密码为 vagrantssh db01 sudo /usr/bin/mysql -u root -p连接成功后先确认我们创建的 devops 用户是否存在select user, host from mysql.user;再执行SHOW DATABASES;查看新建的数据库我们使用的是 root 登录但现在也可以用 devops 账户以同样方式登录——用户名devops密码DevOps90sudo /usr/bin/mysql -u devops -p一个实战排错经验在setup_mysql.yml中作者必须加上login_unix_socket: /var/run/mysqld/mysqld.sock这一行才能成功连接 db01 上的 MySQL 实例同时每次运行创建用户任务时都会报告 changed 状态非幂等。这两种现象在 Ubuntu 系 MySQL 默认使用 auth_socket 认证、以及 mysql_user 模块对比逻辑下是常见问题可结合目标机 MySQL 的实际认证插件与模块行为进一步排查。小结Day 68 完成了 Ansible 进阶三大件与数据库节点落地的闭环Tags从 play 级到 task 级定向执行配合--list-tags、--tags、tag: always与多标签组合让大型 Playbook 的按需执行成为可能Variablesansible proxy -m setup采集 Factsgroup_vars/all/与host_vars/目录结构管理用户变量并用 Jinja2 循环 hostvars把负载均衡与欢迎页模板变成动态配置Inventory用-i参数切换多环境主机清单数据库部署vagrant up db01ssh-copy-idansible-galaxy init roles/mysql 填充 handlers/tasks/templates最终ansible-playbook playbook7.yml --tags database一键完成 MySQL 安装、用户与数据库创建、远程登录开启并通过 SQL 语句逐一验证。至此这套 Ansible 配置管理环境已经覆盖了 Web 服务器、负载均衡器和数据库服务器三类节点全部由 Playbook 统一驱动。下一部分Day 69将继续推进这套自动化体系把配置管理能力应用到更复杂的场景中。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps Day 68Ansible Tags、变量分层、Inventory 与 MySQL 数据库服务器部署实战90DaysOfDevOps Day 68Ansible Tags、变量分层、Inventory 与 MySQL 数据库服务器部署实战 导读 本文是 90Da文档/教程90DaysOfDevOps Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器自动化配置实战90DaysOfDevOps Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器自动化配置实战 本篇是文档/教程90DaysOfDevOps 实战 Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器部署90DaysOfDevOps 实战 Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器部署 本篇技术指文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/7 15:34:12 · 阅读 1.2k 90DaysOfDevOps Day 68：Ansible Tags、变量、Inventory 与 MySQL 数据库服务器配置实战
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本篇技术指南围绕 90DaysOfDevOps 学习路线中 Day 68 的核心内容展开在 2022/Days/Configmgmt 的 ansible-scenario5/6/7 三个实战场景中系统地讲解 Ansible 的 Tags 标签机制、两类变量Ansible Facts 与用户自定义变量的采集与使用、独立 Inventory 文件的切换方法并完整走通「Vagrant 启动数据库节点 → ansible-galaxy 生成 mysql 角色 → 编写 handlers/tasks/templates → 用 Playbook 一键部署 MySQL 并验证」的数据库服务器自动化部署流程。读完本文你将掌握用--tags定向执行 Playbook、用group_vars/host_vars清理并管理变量、用ansible_facts与 Jinja2 循环生成动态 Nginx 负载均衡配置以及从零搭建 MySQL 角色的完整方法。Tags让大型 Playbook 按需定向执行在 Day 67 的 playbook4.yml 中我们一次性编排了 webservers 与 proxy 两个主机组。到了 Day 68Playbook 越来越大每次ansible-playbook都会把其中的每一个 play 和 task 完整跑一遍。如果环境中存在超大型、超长 Playbook这种做法并不高效——Tags 正是用来解决这个问题的它可以让我们把 Playbook 中的执行单元拆分开按需选择执行范围。以 ansible-scenario5/playbook5.yml 为例在 play 级别为两个主机块分别打上web与proxy标签- hosts: webservers become: yes vars: http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 66! roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy查看并定向运行标签先用ansible-playbook playbook5.yml --list-tags确认 Playbook 中已定义的所有标签命令会按 play 逐一列出web和proxy如果我们只想针对 proxy 执行运行ansible-playbook playbook5.yml --tags proxy从输出可以看到只有 proxy 对应的 play 被执行webservers 部分被完整跳过更细粒度的标签用法除了 play 级别tags 同样可以添加到单个 task 级别从而实现对在哪台机器上做什么事的精准控制。常见的实践包括按应用维度打标签例如apache、nginx、mysql按生命周期阶段打标签例如install、configure、remove让同一套任务可以分别执行安装、配置或卸载使用tag: always只要任务被标记为always无论命令行中传入--tags是什么值该任务都会在每次ansible-playbook运行时强制执行适合放置那些必须每次执行的基础性任务。还可以将多个标签打包在一起ansible-playbook playbook5.yml --tags proxy,web会运行所有带proxy或web标签的内容。在当前示例中这等同于运行整个 Playbook但如果我们有更多其他 play这种组合式定向执行的价值就会立刻显现。同一个 play 或 task 也支持同时声明多个标签。VariablesAnsible 的两类变量体系Ansible 中主要有两类变量用户自定义变量User created由我们在 Playbook、变量文件或 inventory 中自行声明Ansible Facts由 Ansible 在执行时自动从受管主机采集的系统信息。Ansible Facts自动采集的系统信息每次运行 Playbook 时输出中都会出现一个我们没有显式定义、却总会执行的任务——Gathering facts。这些自动采集的 facts 是可以在自动化任务中直接引用的宝贵变量如果想完整查看某台主机的 facts可以使用 ad-hoc 命令ansible proxy -m setup终端会输出大量 JSON 格式的系统信息——包括 IP 地址、架构、BIOS 版本等。由于输出量巨大更实用的做法是重定向到文件ansible proxy -m setup facts.json仓库中已保存了这份真实采集结果见 ansible-scenario5/facts.json打开该文件可以看到针对目标主机的全部信息IP 地址、架构、BIOS 版本……这些信息都可以在 Playbook 中作为变量引用实现真正的根据机器实际情况做自动化。用 facts Jinja2 循环生成动态负载均衡配置Day 67 中我们的 Nginx 模板 mysite.j2 把两台 webserver 的 IP 硬编码在upstream块中。利用ansible_facts我们可以把模板改造成动态生成在 mysite.j2 中用 Jinja2 的 for 循环遍历groups[webservers]组这样无论以后向该组添加还是移除 webserver负载均衡配置都会自动随之变化无需手工修改#Dynamic Config for server {{ ansible_facts[nodename] }} upstream webservers { {% for host in groups[webservers] %} server {{ hostvars[host][ansible_facts][nodename] }}:8000; {% endfor %} } server { listen 80; location / { proxy_pass http://webservers; } }循环中通过hostvars[host]访问组内每个成员各自的ansible_facts。需要注意这种基于主机名的动态配置要正常工作前提是环境中已配置好相应的名称解析name resolution。用户自定义变量从 Playbook 迁移到 group_vars用户自定义变量就是我们自己创建的变量。Day 68 的 playbook6.yml 最初沿用了 Day 66 的做法在 webservers 块中通过vars:声明三个变量- hosts: webservers become: yes vars: http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68! roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy为了让 Playbook 保持整洁可以将变量抽离到独立文件中这正是 ansible-scenario6 场景做的事在场景根目录下创建group_vars文件夹在group_vars下再创建all文件夹——表示所有主机组都会获得这些变量在all中创建common_variables.yml把 Playbook 中的三个变量连同vars:关键字整体迁移进去http_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68!由于这些是全局变量我们还可以把 NTP、DNS 服务器等公共配置一并放进来。变量作用域完全由这个目录结构决定group_vars/all/下所有组共享。迁移之后playbook6.yml 变得非常干净- hosts: webservers become: yes roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy变量文件定义在 ansible-scenario6/group_vars/all/common_variables.yml对应的 Nginx 模板位于 ansible-scenario6/roles/nginx/templates/mysite.j2。迁移后我们可以在模板的 for 循环中直接引用http_port变量把写死的:8000改为变量引用#Dynamic Config for server {{ ansible_facts[nodename] }} upstream webservers { {% for host in groups[webservers] %} server {{ hostvars[host][ansible_facts][nodename] }}:{{ http_port }}; {% endfor %} } server { listen 80; location / { proxy_pass http://webservers; } }同理我们还可以在 apache2 角色的 index.html.j2 中引用ansible_facts[nodename]让每个 webserver 的欢迎页显示自己是谁便于验证负载均衡是否真的在轮询分发html h1{{ html_welcome_msg }}! Im webserver {{ ansible_facts[nodename] }} /h1 /html运行ansible-playbook playbook6.yml后反复访问负载均衡器地址会看到请求轮流落在组内的不同 webserver 上从而验证动态配置生效除此之外我们还可以在场景根目录下新建host_vars文件夹并创建web01.yml从而针对单个主机定制消息或差异化配置实现 per-host 级别的变量覆盖。Inventory Files多环境主机清单到目前为止我们一直使用/etc/ansible目录下的默认 hosts 文件来确定受管主机。但生产环境通常需要区分多个环境——例如 production 和 staging——此时完全可以创建多个独立的 inventory 文件每个文件对应一套服务器/节点清单。创建好自定义清单文件后通过-i参数指定使用哪一个例如ansible-playbook -i dev playbook.yml-i dev中的dev可以是文件或目录Ansible 会读取该清单中的主机与组定义。此外inventory 文件内部还可以为主机或组定义变量例如environmentdev这些变量可以在 Playbook 中引用或打印输出——例如在培训示例中他们把 inventory 里定义的 environment 变量注入负载均衡器网页模板让页面消息直接展示当前所属环境。Deploying our Database server部署数据库服务器目前 Vagrant 环境里还剩最后一台机器db01没有启动和配置。启动节点并打通 SSH在 Vagrantfile 所在目录执行vagrant up db01启动数据库节点节点启动并可以访问后需要先把 SSH 公钥拷贝过去以便 Ansible 控制节点免密连接vagrant up db01 ssh-copy-id db01后续所有配置工作将在 ansible-scenario7 目录中完成。用 ansible-galaxy 初始化 mysql 角色执行ansible-galaxy init roles/mysql自动生成一个名为 mysql 的新角色标准目录结构包含 defaults、handlers、meta、tasks、templates、tests、vars 等子目录。在 Playbook 中追加 database play在 playbook7.yml 中新增一个针对数据库的 play 块database组已在/etc/ansible/hosts中定义该组应用common角色和我们新建的mysql角色并打上database标签这样后续就可以像前面学的 tags 用法一样只针对数据库定向执行- hosts: webservers become: yes roles: - common - apache2 tags: web - hosts: proxy become: yes roles: - common - nginx tags: proxy - hosts: database become: yes roles: - common - mysql tags: database填充 mysql 角色的 handlers 与 tasksansible-galaxy init会生成完整的目录树接下来只需按需填充文件Handlers — main.yml服务重启处理器被 template 任务通过notify触发# handlers file for roles/mysql - name: restart mysql service: name: mysql state: restartedTasks — 三个文件install_mysql.yml、main.yml、setup_mysql.ymlinstall_mysql.yml负责安装 MySQL 相关软件包并确保服务运行见 ansible-scenario7/roles/mysql/tasks/install_mysql.yml- name: Install Common packages apt: name{{ item }} statelatest with_items: - python3-pip - mysql-client - python3-mysqldb - libmysqlclient-dev - name: Ensure mysql-server is installed latest version apt: namemysql-server statelatest - name: Installing python module MySQL-python pip: name: PyMySQL - name: Ensure mysql-server is running service: name: mysql state: startedmain.yml是一个指针文件通过import_tasks引入上面两个任务文件注意旧写法include即将被弃用应采用import_tasks# tasks file for roles/mysql - import_tasks: install_mysql.yml - import_tasks: setup_mysql.ymlsetup_mysql.yml负责生成 MySQL 配置文件、创建数据库用户和数据库见 ansible-scenario7/roles/mysql/tasks/setup_mysql.yml- name: Create my.cnf configuration file template: srctemplates/my.cnf.j2 dest/etc/mysql/conf.d/mysql.cnf notify: restart mysql - name: Create database user with name devops and password DevOps90 with all database privileges community.mysql.mysql_user: login_unix_socket: /var/run/mysqld/mysqld.sock login_user: {{ mysql_user_name }} login_password: {{ mysql_user_password }} name: {{db_user}} password: {{db_pass}} priv: *.*:ALL host: % state: present - name: Create a new database with name 90daysofdevops mysql_db: login_user: {{ mysql_user_name }} login_password: {{ mysql_user_password }} name: {{ db_name }} state: present仓库中的实际实现setup_mysql.yml比文档示例更进一步mysql_user的priv写为*.*:ALL,GRANTmysql_db改用新创建的db_user/db_pass登录并额外通过lineinfile修改/etc/mysql/mysql.conf.d/mysqld.cnf中的bind-address 0.0.0.0并触发重启从而启用 MySQL 远程登录——这是多节点架构中应用服务器连接数据库所必需的。可以看到任务中大量配置密码、用户名、数据库名都通过变量引用这些变量统一存放在group_vars/all/common_variables.yml中见 ansible-scenario7/group_vars/all/common_variables.ymlhttp_port: 8000 https_port: 4443 html_welcome_msg: Hello 90DaysOfDevOps - Welcome to Day 68! mysql_user_name: root mysql_user_password: vagrant db_user: devops db_pass: DevOps90 db_name: 90DaysOfDevOpstemplates 目录中的 my.cnf.j2 模板内容如下仓库版本额外加入了[client]段固化 root 登录凭据[mysql] bind-address 0.0.0.0运行 Playbook 部署数据库虚拟机已启动、配置文件就绪后可以执行完整部署ansible-playbook playbook7.yml包含此前所有内容也可以只针对 database 组定向部署ansible-playbook playbook7.yml --tags database--tags database只会运行我们新写的 mysql 相关配置。作者在首次只针对 database 标签运行时遇到了一个报错——提示目标机没有安装 pip3Python解决方法是把它补进 common 角色的公共任务中一并安装修复后再次运行 Playbook得到成功变更的结果验证 db01 上的 MySQL部署完成后应从控制节点登录 db01 确认一切符合预期。先通过ssh db01连接到新配置的机器然后用 root 连接 MySQL密码为 vagrantssh db01 sudo /usr/bin/mysql -u root -p连接成功后先确认我们创建的 devops 用户是否存在select user, host from mysql.user;再执行SHOW DATABASES;查看新建的数据库我们使用的是 root 登录但现在也可以用 devops 账户以同样方式登录——用户名devops密码DevOps90sudo /usr/bin/mysql -u devops -p一个实战排错经验在setup_mysql.yml中作者必须加上login_unix_socket: /var/run/mysqld/mysqld.sock这一行才能成功连接 db01 上的 MySQL 实例同时每次运行创建用户任务时都会报告 changed 状态非幂等。这两种现象在 Ubuntu 系 MySQL 默认使用 auth_socket 认证、以及 mysql_user 模块对比逻辑下是常见问题可结合目标机 MySQL 的实际认证插件与模块行为进一步排查。小结Day 68 完成了 Ansible 进阶三大件与数据库节点落地的闭环Tags从 play 级到 task 级定向执行配合--list-tags、--tags、tag: always与多标签组合让大型 Playbook 的按需执行成为可能Variablesansible proxy -m setup采集 Factsgroup_vars/all/与host_vars/目录结构管理用户变量并用 Jinja2 循环 hostvars把负载均衡与欢迎页模板变成动态配置Inventory用-i参数切换多环境主机清单数据库部署vagrant up db01ssh-copy-idansible-galaxy init roles/mysql 填充 handlers/tasks/templates最终ansible-playbook playbook7.yml --tags database一键完成 MySQL 安装、用户与数据库创建、远程登录开启并通过 SQL 语句逐一验证。至此这套 Ansible 配置管理环境已经覆盖了 Web 服务器、负载均衡器和数据库服务器三类节点全部由 Playbook 统一驱动。下一部分Day 69将继续推进这套自动化体系把配置管理能力应用到更复杂的场景中。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps Day 68Ansible Tags、变量分层、Inventory 与 MySQL 数据库服务器部署实战90DaysOfDevOps Day 68Ansible Tags、变量分层、Inventory 与 MySQL 数据库服务器部署实战 导读 本文是 90Da文档/教程90DaysOfDevOps Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器自动化配置实战90DaysOfDevOps Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器自动化配置实战 本篇是文档/教程90DaysOfDevOps 实战 Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器部署90DaysOfDevOps 实战 Day 68Ansible Tags、Variables、Inventory 与 MySQL 数据库服务器部署 本篇技术指文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考