13518219792
这篇文章主要介绍了如何使用Ansible，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
创新互联自成立以来，一直致力于为企业提供从网站策划、网站设计、成都网站建设、成都网站设计、电子商务、网站推广、网站优化到为企业提供个性化软件开发等基于互联网的全面整合营销服务。公司拥有丰富的网站建设和互联网应用系统开发管理经验、成熟的应用系统解决方案、优秀的网站开发工程师团队及专业的网站设计师团队。
Ansible 的配置文件保存在 /etc/ansible 中，这很有道理，因为 /etc/ 是系统程序应该保存配置文件的地方。我需要使用的两个文件是 ansible.cfg 和 hosts。
在进行了从文档和线上找到的一些实践练习之后，我遇到了一些有关弃用某些较旧的 Python 文件的警告信息。因此，我在 ansible.cfg 中将 deprecation_warnings 设置为 false，这样那些愤怒的红色警告消息就不会出现了：
deprecation_warnings = False
这些警告很重要，所以我稍后将重新回顾它们，并弄清楚我需要做什么。但是现在，它们不会再扰乱屏幕，也不会让我混淆实际上需要关注的错误。
与 /etc/hosts 文件不同，hosts 文件也被称为清单文件，它列出了网络上的主机。此文件允许将主机分组到相关集合中，例如“servers”、“workstations”和任何你所需的名称。这个文件包含帮助和大量示例，所以我在这里就不详细介绍了。但是，有些事情你必须知道。
主机也可以列在组之外，但是组对于识别具有一个或多个共同特征的主机很有帮助。组使用 INI 格式，所以服务器组看起来像这样：
[servers]server1server2......
这个文件中必须有一个主机名，这样 Ansible 才能对它进行操作。即使有些子命令允许指定主机名，但除非主机名在 hosts 文件中，否则命令会失败。一个主机也可以放在多个组中。因此，除了 [servers] 组之外，server1 也可能是 [webservers] 组的成员，还可以是 [ubuntu] 组的成员，这样以区别于 Fedora 服务器。
Ansible 很智能。如果 all 参数用作主机名，Ansible 会扫描 hosts 文件并在它列出的所有主机上执行定义的任务。Ansible 只会尝试在每个主机上工作一次，不管它出现在多少个组中。这也意味着不需要定义 all 组，因为 Ansible 可以确定文件中的所有主机名，并创建自己唯一的主机名列表。
另一件需要注意的事情是单个主机的多个条目。我在 DNS 文件中使用 CNAME 记录来创建别名，这些别名指向某些主机的 A 记录，这样，我可以将一个主机称为 host1 或 h2 或 myhost。如果你在 hosts 文件中为同一主机指定多个主机名，则 Ansible 将尝试在所有这些主机名上执行其任务，它无法知道它们指向同一主机。好消息是，这并不会影响整体结果；它只是多花了一点时间，因为 Ansible 会在次要主机名上工作，它会确定所有操作均已执行。
我阅读过 Ansible 的大多数材料都谈到了 Ansible 实情，它是与远程系统相关的数据，包括操作系统、IP 地址、文件系统等等。这些信息可以通过其它方式获得，如 lshw、dmidecode 或 /proc 文件系统等。但是 Ansible 会生成一个包含此信息的 JSON 文件。每次 Ansible 运行时，它都会生成这些实情数据。在这个数据流中，有大量的信息，都是以键值对形式出现的：<"variable-name": "value">。所有这些变量都可以在 Ansible 剧本中使用，理解大量可用信息的最好方法是实际显示一下：
# ansible -m setup| less
明白了吗？你想知道的有关主机硬件和 Linux 发行版的所有内容都在这里，它们都可以在剧本中使用。我还没有达到需要使用这些变量的地步，但是我相信在接下来的几天中会用到。
上面的 ansible 命令使用 -m 选项来指定 setup 模块。Ansible 已经内置了许多模块，所以你对这些模块不需要使用 -m。也可以安装许多下载的模块，但是内置模块可以完成我目前项目所需的一切。
剧本几乎可以放在任何地方。因为我需要以 root 身份运行，所以我将它放在了 /root/ansible 下。当我运行 Ansible 时，只要这个目录是当前的工作目录（PWD），它就可以找到我的剧本。Ansible 还有一个选项，用于在运行时指定不同的剧本和位置。
剧本可以包含注释，但是我看到的文章或书籍很少提及此。但作为一个相信记录一切的系统管理员，我发现使用注释很有帮助。这并不是说在注释中做和任务名称同样的事情，而是要确定任务组的目的，并确保我以某种方式或顺序记录我做这些事情的原因。当我可能忘记最初的想法时，这可以帮助以后解决调试问题。
剧本只是定义主机所需状态的任务集合。在剧本的开头指定主机名或清单组，并定义 Ansible 将在其上运行剧本的主机。
以下是我的一个剧本示例：
################################################################################# This Ansible playbook updates Midnight commander configuration files. #################################################################################- name: Update midnight commander configuration files hosts: all tasks: - name: ensure midnight commander is the latest version dnf: name: mc state: present - name: create ~/.config/mc directory for root file: path: /root/.config/mc state: directory mode: 0755 owner: root group: root - name: create ~/.config/mc directory for dboth file: path: /home/dboth/.config/mc state: directory mode: 0755 owner: dboth group: dboth - name: copy latest personal skin copy: src: /root/ansible/UpdateMC/files/MidnightCommander/DavidsGoTar.ini dest: /usr/share/mc/skins/DavidsGoTar.ini mode: 0644 owner: root group: root - name: copy latest mc ini file copy: src: /root/ansible/UpdateMC/files/MidnightCommander/ini dest: /root/.config/mc/ini mode: 0644 owner: root group: root - name: copy latest mc panels.ini file copy: src: /root/ansible/UpdateMC/files/MidnightCommander/panels.ini dest: /root/.config/mc/panels.ini mode: 0644 owner: root group: root<截断>
剧本从它自己的名字和它将要操作的主机开始，在本文中，所有主机都在我的 hosts 文件中。tasks 部分列出了使主机达到所需状态的特定任务。这个剧本从使用 DNF 更新 Midnight Commander 开始（如果它不是最新的版本的话）。下一个任务确保创建所需的目录（如果它们不存在），其余任务将文件复制到合适的位置，这些 file 和 copy 任务还可以为目录和文件设置所有权和文件模式。
剧本细节超出了本文的范围，但是我对这个问题使用了一点蛮力。还有其它方法可以确定哪些用户需要更新文件，而不是对每个用户的每个文件使用一个任务。我的下一个目标是简化这个剧本，使用一些更先进的技术。
运行剧本很容易，只需要使用 ansible-playbook 命令。.yml 扩展名代表 YAML，我看到过它的几种不同含义，但我认为它是“另一种标记语言”，尽管有些人声称 YAML 不是这种语言。
这个命令将会运行剧本，它会更新 Midnight Commander 文件：
# ansible-playbook -f 10 UpdateMC.yml
-f 选项指定 Ansible 使用 10 个线程来执行操作。这可以大大加快整个任务的完成速度，特别是在多台主机上工作时。
剧本运行时会列出每个任务和执行结果。ok 代表任务管理的机器状态已经完成，因为在任务中定义的状态已经为真，所以 Ansible 不需要执行任何操作。
changed 表示 Ansible 已经执行了指定的任务。在这种情况下，任务中定义的机器状态不为真，所以执行指定的操作使其为真。在彩色终端上，TASK 行会以彩色显示。我的终端配色为“amber-on-black”，TASK 行显示为琥珀色，changed 是棕色，ok 为绿色，错误是红色。
下面的输出是我最终用于在新主机执行安装后配置的剧本：
PLAY [Post-installation updates, package installation, and configuration] TASK [Gathering Facts]ok: [testvm2] TASK [Ensure we have connectivity]ok: [testvm2] TASK [Install all current updates]changed: [testvm2] TASK [Install a few command line tools]changed: [testvm2] TASK [copy latest personal Midnight Commander skin to /usr/share]changed: [testvm2] TASK [create ~/.config/mc directory for root]changed: [testvm2] TASK [Copy the most current Midnight Commander configuration files to /root/.config/mc]changed: [testvm2] => (item=/root/ansible/PostInstallMain/files/MidnightCommander/DavidsGoTar.ini)changed: [testvm2] => (item=/root/ansible/PostInstallMain/files/MidnightCommander/ini)changed: [testvm2] => (item=/root/ansible/PostInstallMain/files/MidnightCommander/panels.ini) TASK [create ~/.config/mc directory in /etc/skel]changed: [testvm2] <截断>
如果你的计算机上安装了 cowsay 程序，你会发现 TASK 的名字出现在奶牛的语音泡泡中：
____________________________________< TASK [Ensure we have connectivity] > ------------------------------------ \ ^__^ \ (oo)\\_______ (__)\ )\/\ ||----w | || ||
如果你没有这个有趣的程序，你可以使用发行版的包管理器安装 Cowsay 程序。如果你有这个程序但不想要它，可以通过在 /etc/ansible/ansible.cfg 文件中设置 nocows=1 将其禁用。
我喜欢这头奶牛，它很有趣，但是它会占用我的一部分屏幕。因此，在它开始妨碍我使用时，我就把它禁用了。
与我的 Midnight Commander 任务一样，经常需要安装和维护各种类型的文件。创建用于存储剧本的目录树的“最佳实践”和系统管理员一样多，至少与编写有关 Ansible 书和文章的作者数量一样多。
我选择了一个对我有意义的简单结构：
/root/ansible └── UpdateMC ├── files │ └── MidnightCommander │ ├── DavidsGoTar.ini │ ├── ini │ └── panels.ini └── UpdateMC.yml
你可以使用任何结构。但是请注意，其它系统管理员可能需要使用你设置的剧本来工作，所以目录应该具有一定程度的逻辑。当我使用 RPM 和 Bash 脚本执行安装任务后，我的文件仓库有点分散，绝对没有任何逻辑结构。当我为许多管理任务创建剧本时，我将介绍一个更有逻辑的结构来管理我的目录。
根据需要或期望多次运行剧本是安全的。只有当主机状态与任务中指定的状态不匹配时，才会执行每个任务。这使得很容易从先前的剧本运行中遇到的错误中恢复。因为当剧本遇到错误时，它将停止运行。
在测试我的第一个剧本时，我犯了很多错误并改正了它们。假设我的修正正确，那么剧本每次运行，都会跳过那些状态已与指定状态匹配的任务，执行不匹配状态的任务。当我的修复程序起作用时，之前失败的任务就会成功完成，并且会执行此任务之后的任务 —— 直到遇到另一个错误。
这使得测试变得容易。我可以添加新任务，并且在运行剧本时，只有新任务会被执行，因为它们是唯一与测试主机期望状态不匹配的任务。
感谢你能够认真阅读完这篇文章，希望小编分享的“如何使用Ansible”这篇文章对大家有帮助，同时也希望大家多多支持创新互联，关注创新互联行业资讯频道，更多相关知识等着你来学习!
