document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-23 21:20:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #20895 from MjSeven/20201013_firstday_ansible

Browse Source 
翻译完成
This commit is contained in:
geekpi 2021-02-01 08:56:10 +08:00 committed by GitHub
commit a0fe0e57d7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 297 additions and 304 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

304
sources/tech/20201013 My first day using Ansible.md
View File

@ -1,304 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (MjSeven)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (My first day using Ansible)
[#]: via: (https://opensource.com/article/20/10/first-day-ansible)
[#]: author: (David Both https://opensource.com/users/dboth)
My first day using Ansible
======
A sysadmin shares information and advice about putting Ansible into
real-world use configuring computers on his network.
![People work on a computer server with devices][1]
Getting a new computer, whether physical or virtual, up and running is time-consuming and requires a good deal of work—whether it's your first time or the 50th. For many years, I have used a series of scripts and RPMs that I created to install the packages I need and to perform many bits of configuration for my favorite tools. This approach has worked well and simplified my work, as well as reduced the amount of time I spend typing commands.
I am always looking for better ways of doing things, and, for several years now, I have been hearing and reading about [Ansible][2], which is a powerful tool for automating system configuration and management. Ansible allows a sysadmin to define a specific state for each host in one or more playbooks and then performs whatever tasks are necessary to bring the host to that state. This includes installing or deleting various resources such as RPM or Apt packages, configuration and other files, users, groups, and much more.
I have delayed learning how to use it for a long time because—stuff. Until recently, when I ran into a problem that I thought Ansible could easily solve.
This article is not a complete how-to for getting started with Ansible; rather, it is intended to provide insight into some of the issues that I encountered and some information that I found only in some very obscure places. Much of the information I found in various online discussions and Q&A groups about Ansible was incorrect. Errors ranged from information that was really old with no indication of its date or provenance to information that was just wrong.
The information in this article is known to work—although there might be other ways of accomplishing the same things—and it works with Ansible 2.9.13 and [Python][3] 3.8.5.
### My problem
All of my best learning experiences start with a problem I need to solve, and this was no exception.
I have been working on a little project to modify the configuration files for the [Midnight Commander][4] (mc) file manager and pushing them out to various systems on my network for testing. Although I have a script to automate this, it still requires a bit of fussing with a command-line loop to provide the names of the systems to which I want to push the new code. The large number of changes I was making to the configuration files made it necessary for me to push the new ones frequently. But, just when I thought I had my new configuration just right, I would find a problem and need to do another push after making the fix.
This environment made it difficult to keep track of which systems had the new files and which did not. I also have a couple of hosts that need to be treated differently. And my little bit of knowledge about Ansible suggested that it would probably be able to do all or most of what I need.
### Getting started
I had read a number of good articles and books about Ansible, but never in an "I have to get this working NOW!" kind of situation. And now was—well, NOW!
In rereading these documents, I discovered that they mostly talk about how to install Ansible from GitHub using—wait for it—Ansible. That is cool, but I really just wanted to get started, so I installed it on my Fedora workstation using DNF and the version in the Fedora repository. Easy.
But then I started looking for the file locations and trying to determine which configuration files I needed to modify, where to keep my playbooks, what a playbook even looks like, and what it does. I had lots of (so far) unanswered questions running around in my head.
So, without further descriptions of my tribulations, here are the things I discovered and that got me going.
### Configuration
Ansible's configuration files are kept in `/etc/ansible`. Makes sense, right, since `/etc` is where system programs are supposed to keep their configuration files. The two files I needed to work with are `ansible.cfg` and `hosts`.
#### ansible.cfg
After getting started with some of the exercises I found in the documents and online, I began receiving warning messages about deprecating certain older Python files. So, I set `deprecation_warnings` to `false` in `ansible.cfg` and those angry red warning messages stopped:
```
`deprecation_warnings = False`
```
Those warnings are important, so I will revisit them later and figure out what I need to do. But for now, they no longer clutter the screen and obfuscate the errors I actually need to be concerned about.
#### The hosts file
Not the same as the `/etc/hosts` file, the `hosts` file is also known as the inventory file, and it lists the hosts on your network. This file allows grouping hosts together in related sets, such as servers, workstations, and pretty much any designation you need. This file contains its own help and plenty of examples, so I won't go into boring detail here. However, there are some things to know.
Hosts can be listed outside of any groups, but groups can be helpful in identifying hosts with one or more common characteristics. Groups use the INI format, so a server group looks like this:
```
[servers]
server1
server2
...etc.
```
A hostname must be present in this file for Ansible to work on it. Even though some subcommands allow you to specify a hostname, the command will fail unless the hostname is in the `hosts` file. A host can also be listed in multiple groups. So `server1` might also be a member of the `[webservers]` group in addition to the `[servers]` group, and a member of the `[ubuntu]` group to differentiate it from Fedora servers.
Ansible is smart. If the `all` argument is used for the hostname, Ansible scans the file and performs the defined tasks on all hosts listed in the file. Ansible will only attempt to work on each host once, no matter how many groups it appears in. This also means that there does not need to be a defined "all" group because Ansible can determine all hostnames in the file and create its own list of unique hostnames.
Another little thing to look out for is multiple entries for a single host. I use `CNAME` records in my DNS zone file to create aliased names that point to the [A records][5] for some of my hosts. That way, I can refer to a host as `host1` or `h1` or `myhost`. If you use multiple hostnames for the same host in the `hosts` file, Ansible will try to perform its tasks on all of those hostnames; it has no way of knowing that they refer to the same host. The good news is that this does not affect the overall result; it just takes a bit more time as Ansible works on the secondary hostnames and determines that all of the operations have already been performed.
### Ansible facts
Most of the materials I have read on Ansible talk about [Ansible facts][6], which "are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more." This information is available in other ways, such as `lshw`, `dmidecode`, the `/proc` filesystem, and more, but Ansible generates a JSON file containing this information. Each time Ansible runs, it generates this facts data. There is an amazing amount of information in this data stream, all of which are in `<"variable-name": "value">` pairs. All of these variables are available for use within an Ansible playbook. The best way to understand the huge amount of information available is to display it yourself:
```
`# ansible -m setup <hostname> | less`
```
See what I mean? Everything you ever wanted to know about your host hardware and Linux distribution is there and usable in a playbook. I have not yet gotten to the point where I need to use those variables, but I am certain I will in the next couple of days.
### Modules
The `ansible` command above uses the `-m` option to specify the "setup" module. Ansible has many modules already built-in, so you do not need to use the `-m` for those. There are also many downloadable modules that can be installed, but the built-ins do everything I have needed for my current projects so far.
### Playbooks
Playbooks can be located almost anywhere. Since I need to run my playbooks as root, I placed mine in `/root/ansible`. As long as this directory is the present working directory (PWD) when I run Ansible, it can find my playbook. Ansible also has a runtime option to specify a different playbook and location.
Playbooks can contain comments, although I have seen very few articles or books that mention this. As a sysadmin who believes in documenting everything, I find using comments can be very helpful. This is not so much about saying the same things in the comments as I do in the task name; rather, it is about identifying the purpose of groups of tasks and ensuring that I record my reasons for doing certain things in a certain way or order. This can help with debugging problems later when I may have forgotten my original thinking.
Playbooks are simply collections of tasks that define the desired state of a host. A hostname or inventory group is specified at the beginning of the playbook and defines the hosts on which Ansible will run the playbook.
Here is a sample of my playbook:
```
################################################################################
# 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
&lt;SNIP&gt;
```
The playbook starts with its own name and the hosts it will act on—in this case, all of the hosts listed in my `hosts` file. The `tasks` section lists the specific tasks required to bring the host into compliance with the desired state. This playbook starts with a task in which Ansible's built-in DNF updates Midnight Commander if it is not the most recent release. The next tasks ensure that the required directories are created if they do not exist, and the remainder of the tasks copy the files to the proper locations. These `file` and `copy` tasks can also set the ownership and file modes for the directories and files.
The details of my playbook are beyond the scope of this article, but I used a bit of a brute-force attack on the problem. There are other methods for determining which users need to have the files updated rather than using a task for each file for each user. My next objective is to simplify this playbook to use some of the more advanced techniques.
Running a playbook is easy; just use the `ansible-playbook` command. The .yml extension stands for YAML. I have seen several meanings for that, but my bet is on "Yet Another Markup Language," despite the fact that some claim that YAML is not one.
This command runs the playbook I created for updating my Midnight Commander files:
```
`# ansible-playbook -f 10 UpdateMC.yml`
```
The `-f` option specifies that Ansible should fork up to 10 threads in order to perform operations in parallel. This can greatly speed overall task completion, especially when working on multiple hosts.
### Output
The output from a running playbook lists each task and the results. An `ok` means the machine state managed by the task is already defined in the task stanza. Because the state defined in the task is already true, Ansible did not need to perform the actions defined in the task stanza.
The response `changed` indicates that Ansible performed the task specified in the stanza in order to bring it to the desired state. In this case, the machine state defined in the stanza was not true, so the actions defined were performed to make it true. On a color-capable terminal, the `TASK` lines are shown in color. On my host with my amber-on-black terminal color configuration, the `TASK` lines are shown in amber, `changed` lines are in brown, and `ok` lines are shown in green. Error lines are displayed in red.
The following output is from the playbook I will eventually use to perform post-install configuration on new hosts:
```
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] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/DavidsGoTar.ini)
changed: [testvm2] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/ini)
changed: [testvm2] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/panels.ini)
TASK [create ~/.config/mc directory in /etc/skel]
changed: [testvm2]
&lt;SNIP&gt;
```
### The cow
If you have the [cowsay][7] program installed on your computer, you will notice that the `TASK` names appear in the cow's speech bubble:
```
 ____________________________________
&lt; TASK [Ensure we have connectivity] &gt;
 ------------------------------------
        \   ^__^
         \  (oo)\\_______
            (__)\       )\/\
                ||----w |
                ||     ||
```
If you do not have this fun feature and want it, install the cowsay package using your distribution's package manager. If you have this and don't want it, disable it with by setting `nocows = 1` in the `/etc/ansible/ansible.cfg` file.
I like the cow and think it is fun, but it reduces the amount of screen space that can be used to display messages. So I disabled it after it started getting in the way.
### Files
As with my Midnight Commander task, it is frequently necessary to install and maintain files of various types. There are as many "best practices" for creating a directory tree for storing files used in playbooks as there are sysadmins—or at least as many as the number of authors writing books and articles about Ansible.
I chose a simple structure that makes sense to me:
```
/root/ansible
└── UpdateMC
    ├── files
    │   └── MidnightCommander
    │       ├── DavidsGoTar.ini
    │       ├── ini
    │       └── panels.ini
    └── UpdateMC.yml
```
You should use whatever structure works for you. Just be aware that some other sysadmin will likely need to work with whatever you set up, so there should be some level of logic to it. When I was using RPM and Bash scripts to perform my post-install tasks, my file repository was a bit scattered and definitely not structured with any logic. As I work through creating playbooks for many of my administrative tasks, I will introduce a much more logical structure for managing my files.
### Multiple playbook runs
It is safe to run a playbook as many times as needed or desired. Each task will only be executed if the state does not match the one specified in the task stanza. This makes it easy to recover from errors encountered during previous playbook runs. The playbook stops running when it encounters an error.
While testing my first playbook, I made many mistakes and corrected them. Each additional run of the playbook—assuming my fix is a good one—skips the tasks whose state already matches the specified one and executes those that did not. When my fix works, the previously failed task completes successfully, and any tasks after that one in my playbook also execute—until it encounters another error.
This also makes testing easy. I can add new tasks and, when I run the playbook, only those new tasks are performed because they are the only ones that do not match the test host's desired state.
### Some thoughts
Some tasks are not appropriate for Ansible because there are better methods for achieving a specific machine state. The use case that comes to mind is that of returning a VM to an initial state so that it can be used as many times as necessary to perform testing beginning with that known state. It is much easier to get the VM into the desired state and then to take a snapshot of the then-current machine state. Reverting to that snapshot is usually going to be easier and much faster than using Ansible to return the host to that desired state. This is something I do several times a day when researching articles or testing new code.
After completing my playbook for updating Midnight Commander, I started a new playbook that I will use to perform post-installation tasks on newly installed Fedora hosts. I have already made good progress, and the playbook is a bit more sophisticated and less brute-force than my first one.
On my very first day using Ansible, I created a playbook that solves a problem. I also started a second playbook that will solve the very big problem of post-install configuration. And I have learned a lot.
Although I really like using [Bash][8] scripts for many of my administrative tasks, I am already finding that Ansible can do everything I want—and in a way that can maintain the system in the state I want. After only a single day of use, I am an Ansible fan.
### Resources
The most complete and useful document I have found is the [User Guide][9] on the Ansible website. This document is intended as a reference and not a how-to or getting-started document.
Opensource.com has published many [articles about Ansible][10] over the years, and I have found most of them very helpful for my needs. The Enable Sysadmin website also has a lot of [Ansible articles][11] that I have found to be helpful. You can learn even more by checking out [AnsibleFest][12] happening this week (October 13-14, 2020). The event is completely virtual and free to register.
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/10/first-day-ansible
作者：[David Both][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/dboth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003499_01_linux11x_cc.png?itok=XMDOouJR (People work on a computer server with devices)
[2]: https://www.ansible.com/
[3]: https://www.python.org/
[4]: https://midnight-commander.org/
[5]: https://en.wikipedia.org/wiki/List_of_DNS_record_types
[6]: https://docs.ansible.com/ansible/latest/user_guide/playbooks_vars_facts.html#ansible-facts
[7]: https://en.wikipedia.org/wiki/Cowsay
[8]: https://opensource.com/downloads/bash-cheat-sheet
[9]: https://docs.ansible.com/ansible/latest/user_guide/index.html
[10]: https://opensource.com/tags/ansible
[11]: https://www.redhat.com/sysadmin/topics/ansible
[12]: https://www.ansible.com/ansiblefest

297
translated/tech/20201013 My first day using Ansible.md Normal file
View File

@ -0,0 +1,297 @@
[#]: collector: "lujun9972"
[#]: translator: "MjSeven"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
[#]: subject: "My first day using Ansible"
[#]: via: "https://opensource.com/article/20/10/first-day-ansible"
[#]: author: "David Both https://opensource.com/users/dboth"
使用 Ansible 的第一天
======
一名系统管理员分享了如何使用 Ansible 在网络中配置计算机并把其带入实际工作的信息和建议。
![People work on a computer server with devices][1]
无论是第一次还是第五十次，启动并运行一台新的物理或虚拟计算机都非常耗时，而且需要大量的工作。多年来，我一直使用我创建的一系列脚本和 RPM 来安装所需的软件包，并为我喜欢的工具配置选项。这种方法效果很好，简化了我的工作，而且还减少了在键盘上输入命令的时间。
我一直在寻找更好的工作方式。近几年来，我一直在听到并且读到有关 [Ansible][2] 的信息，它是一个自动配置和管理系统的强大工具。Ansible 允许系统管理员在一个或多个剧本中为每个主机指定一个特定状态，然后执行使主机进入该状态的所有任务。包括安装或删除各种资源，例如 RPM 或 Apt 软件包、配置和其它文件、用户、组等等。
因为一些琐事，我推迟了很长一段时间学习如何使用它。直到最近，我遇到了一个我认为 Ansible 可以轻松解决的问题。
这篇文章并不会完整地告诉你如何入门 Ansible，相反，它只是对我遇到的问题和我在一些隐秘的地方发现的信息的做一些记录。我在各种在线讨论和问答小组中找到的有关 Ansible 的许多信息都是错误的。错误范围包括明显的老旧信息（没有任何日期或来源的迹象），还有一些是完全错误的信息。
本文所介绍的内容是有用的，尽管可能还有其它方法可以完成相同的事情，但我使用的是 Ansible 2.9.13 和 [Python][3] 3.8.5。
### 我的问题
我所有的最佳学习经历都始于我需要解决的问题，这次也不例外。
我一直在做一个小项目，修改 [Midnight Commander][4] 文件管理器的配置文件，并将它们推送到我网络上的各种系统中进行测试。尽管我有一个脚本可以自动执行这个操作，但它仍然需要使用命令行循环来提供我想要推送新代码的系统名称。我对配置文件进行了大量的更改，这使我必须频繁推送新的配置文件。但是，就在我以为我的新配置刚刚好时，我发现了一个问题，所以我需要在修复后再进行一次推送。
这种环境使得很难跟踪哪些系统有新文件，哪些没有。我还有几个主机需要区别对待。我对 Ansible 的一点了解表明，它可能能够满足我的全部或大部分工作。
### 开始
我读过许多有关 Ansible 的好文章和书籍，但从来没有遇到过“我必须把这个用到工作中”那种情况。但是，现在就是这种情况。
在重读这些文档时，我发现它们主要是在讨论如何从 GitHub 开始安装并使用 Ansible，这很酷。但是我真的只是想尽快开始，所以我使用 DNF 和 Fedora 仓库中的版本在我的 Fedora 工作站上安装了它，非常简单。
但是后来我开始寻找文件位置，并尝试确定需要修改哪些配置文件、将我的剧本保存在什么位置，甚至一个剧本怎么写以及它的作用，我脑海中有一大堆（到目前为止）悬而未决的问题。
因此，在没有进一步描述我的困难的情况下，以下是我发现的东西以及促使我继续前进的东西。
### 配置
Ansible 的配置文件保存在 `/etc/ansible` 中，这很有道理，因为 `/etc/` 是系统程序应该保存配置文件的地方。我需要使用的两个文件是 `ansible.cfg` 和 `hosts`。
#### ansible.cfg
在进行文档和线上找到的一些实践练习之后，我遇到了一些有关弃用某些较旧的 Python 文件的警告信息。因此，我在 `ansible.cfg` 中将 `deprecation_warnings` 设置为 `false`，这样那些愤怒的红色警告消息就不会出现了：
```bash
deprecation_warnings = False
```
这些警告很重要，所以我稍后将重新回顾它们，并弄清楚我需要做什么。但是现在，它们不会再扰乱屏幕，也不会让我混淆实际上需要关注的错误。
#### hosts 文件
与 `/etc/hosts` 文件不同，`hosts` 文件也被称为清单文件，它列出了网络上的主机。此文件允许将主机分组到相关集合中，例如服务器、工作站和任何你所需的名称。这个文件包含帮助和大量示例，所以我在这里就不详细介绍了。但是，有些事情你必须知道。
主机可以在任何组之外列出，但是组对于识别具有一个或多个共同特征的主机很有帮助。组使用 INI 格式，所以服务器组看起来像这样：
```
[servers]
server1
server2
...etc.
```
这个文件中必须有一个主机名，这样 Ansible 才能对它进行操作。尽管有些子命令允许指定主机名，但除非主机名在 `hosts` 文件中，否则命令会失败。一个主机也可以在多个组中。因此，除了 `[servers]` 组之外，`server1` 也可能是 `[webservers]` 组的成员，还可以是 `[ubuntu]` 组的成员，这样以区别于 Fedora 服务器。
Ansible 很智能。如果 `all` 参数用作主机名，Ansible 会扫描 `hosts` 文件并在它列出的所有主机上执行定义的任务。Ansible 只会尝试在每个主机上工作一次，不管它出现在多少个组中。这也意味着不需要定义 "all" 组，因为 Ansible 可以确定文件中的所有主机名，并创建自己唯一的主机名列表。
另一件需要注意的事情是单个主机的多个条目。我在 DNS 文件中使用 `CNAME` 记录来创建别名，这些别名指向某些主机的 [A 记录][5]，这样，我可以将一个主机称为 `host1` 或 `h1` 或 `myhost`。如果你在 `hosts` 文件中为同一主机指定多个主机名，则 Ansible 将尝试在所有这些主机名上执行其任务，它无法知道它们指向同一主机。好消息是，这并不会影响整体结果；它只是多花了一点时间，因为 Ansible在辅助主机名上工作，它会确定所有操作均已执行。
### Ansible facts
我阅读过 Ansible 的大多数材料都谈到了 [Ansible facts][6]，它是与远程系统相关的数据，包括操作系统、IP 地址、文件系统等等。这些信息可以通过其它方式获得，如 `lshw`、`dmidecode` 或 `/proc` 文件系统等。但是 Ansible 会生成一个包含此信息的 JSON 文件。每次 Ansible 运行时，它都会生成这些数据。在这个数据流中，有大量的信息都是键值对形式：`<"变量名": "值">`。所有这些变量都可以在 Ansible 剧本中使用，理解海量信息的最好方法是亲自实践：
```bash
# ansible -m setup <hostname> | less
```
明白了吗？你想知道的有关主机硬件和 Linux 发行版的所有内容都在这里，它们都可以在剧本中使用。我还没有达到需要使用这些变量的地步，但是我相信在接下来的几天中会用到。
### 模块
`ansible` 命令使用 `-m` 选项来指定 `setup` 模块。Ansible 已经内置了许多模块，所以你不需要使用 -m。也可以安装许多下载的模块，但是内置模块可以完成我目前项目所需的一切。
### 剧本
剧本可以放在任何地方。因为我需要以 root 身份运行，所以我将它放在了 `/root/ansible` 下。当我运行 Ansible 时，只要这个目录是当前的工作目录(PWD)，它就可以找到我的剧本。Ansible 还有一个选项，用于在运行时指定其它剧本和位置。
剧本可以包含注释，但是我看到的文章或书籍很少提及此。作为一个相信记录的系统管理员，我发现使用注释很有帮助。这并不是和任务名称做同样的事情，而是要确定任务组的目的，并确保我以某种方式或顺序记录我做这些事情的原因。当我可能忘记最初的想法时，这可以帮助以后解决调试问题。
剧本只是定义主机所需状态的任务集合。在剧本的开头指定主机名或目录组，并定义 Ansible 将在其上运行剧本的主机。
以下是我的一个剧本示例：
```bash
################################################################################
# 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
&lt;SNIP&gt;
```
剧本从它自己的名字和它将要操作的主机开始，在本文中，所有主机都在我的 `hosts` 文件中。`tasks` 部分列出了使主机达到所需状态的特定任务。这个剧本从使用 DNF 更新 Midnight Commander 开始（如果它不是最新的版本的话）。下一个任务确保创建所需的目录（如果它们不存在），其余任务将文件复制到合适的位置，这些 `file` 和 `copy` 任务还可以为目录和文件设置所有权和文件模式。
剧本细节超出了本文的范围，但是我对这个问题使用了一点蛮力。还有其它方法可以确定哪些用户需要更新文件，而不是对每个用户的每个文件使用一个任务。我的下一个目标是简化这个剧本，使用一些更先进的技术。
运行剧本很容易，只需要使用 `ansible-playbook` 命令。.yml 扩展名代表 YAML，我看到过它的几种不同含义，但我认为它是“另一种标记语言”，尽管有些人声称 YAML 不是这种语言。
这个命令将会运行剧本，它会更新 Midnight Commander 文件：
```bash
# ansible-playbook -f 10 UpdateMC.yml
```
`-f` 选项指定 Ansible 使用 10 个线程来执行操作。这可以大大加快整个任务的完成速度，特别是在多台主机上工作时。
### 输出
剧本运行时会列出每个任务和执行结果。`ok` 代表任务管理的机器状态已经完成，因为在任务中定义的状态已经为真，所以 Ansible 不需要执行任何操作。
`changed` 表示 Ansible 已经执行了指定的任务。在这种情况下，任务中定义的机器状态不为真，所以执行指定的操作使其为真。在彩色终端上，`TASK` 线会显示彩色。在我的咖啡色终端的主机上，`TASK` 线显示为琥珀色，`changed` 是棕色，`ok` 为绿色，错误是红色。
下面的输出是我最终用于在新主机执行安装后配置的剧本：
```bash
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] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/DavidsGoTar.ini)
changed: [testvm2] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/ini)
changed: [testvm2] =&gt; (item=/root/ansible/PostInstallMain/files/MidnightCommander/panels.ini)
TASK [create ~/.config/mc directory in /etc/skel]
changed: [testvm2]
&lt;SNIP&gt;
```
### cowsay
如果你的计算机上安装了 [cowsay][7] 程序，你会发现 `TASK` 的名字出现在奶牛的语音泡泡中：
```
 ____________________________________
&lt; TASK [Ensure we have connectivity] &gt;
 ------------------------------------
        \   ^__^
         \  (oo)\\_______
            (__)\       )\/\
                ||----w |
                ||     ||
```
如果你没有这个有趣的程序，你可以使用发行版的包管理器安装 Cowsay 程序。如果你有这个程序但不想要它，可以通过在 `/etc/ansible/ansible.cfg` 文件中设置 `nocows=1` 将其禁用。
我喜欢这头奶牛，它很有趣，但是它会占用我的一部分屏幕。因此，在它开始妨碍我使用时，我就把它禁用了。
### 目录
与我的 Midnight Commander 任务一样，经常需要安装和维护各种类型的文件。创建用于存储剧本的目录树的“最佳实践”和系统管理员一样多，至少与编写有关 Ansible 书和文章的作者数量一样多。
我选择了一个对我有意义的简单结构：
```bash
/root/ansible
└── UpdateMC
    ├── files
    │   └── MidnightCommander
    │       ├── DavidsGoTar.ini
    │       ├── ini
    │       └── panels.ini
    └── UpdateMC.yml
```
你可以使用任何结构。但是请注意，其它系统管理员可能需要使用你设置的剧本来工作，所以目录应该具有一定程度的逻辑。当我使用 RPM 和 Bash 脚本执行安装任务后，我的文件仓库有点分散，而且绝对没有任何逻辑结构。当我为许多管理任务创建剧本时，我将介绍一个更有逻辑的结构来管理我的目录。
### 多个剧本运行
根据需要或期望多次运行剧本是安全的。只有当主机状态与任务中指定的状态不匹配时，才会执行每个任务。这使得很容易从先前的剧本运行中遇到的错误中恢复。因为当剧本遇到错误时，它将停止运行。
在测试我的第一个剧本时，我犯了很多错误并改正了它们。假设我的修正正确，那么剧本每次运行，都会跳过那些状态已与指定状态匹配的任务，执行不匹配状态的任务。当我的修复程序起作用时，前面失败的任务将成功完成，并且会执行此任务之后的任务--直到遇到另一个错误。
这使得测试变得容易。我可以添加新任务，并且在运行剧本时，只有新任务会被执行，因为它们是唯一与测试主机期望状态不匹配的任务。
### 一些想法
有些任务不适合用 Ansible，因为有更好的方法可以实现特定的计算机状态。我想到的场景是使 VM 返回到初始状态，以便可以多次使用它来执行从已知状态开始的测试。让 VM 进入特定状态，然后对此时的计算机状态进行快照要容易得多。还原到该快照通常比 Ansible 将主机返回到之前状态相比，还原到快照通常会更容易且更快。在研究文章或测试新代码时，我每天都会做几次这样的事情。
在完成用于更新 Midnight Commander 的剧本之后，我创建了一个新的剧本，用于在新安装的 Fedora 主机上执行安装任务。我已经取得了不错的进步，剧本比我第一个的更加复杂，但没有那么粗暴。
在使用 Ansible 的第一天，我创建了一个解决问题的剧本，我还开始编写第二个剧本，它将解决安装后配置的大问题，在这个过程中我学到了很多东西。
尽管我真的很喜欢使用 [Bash][8] 脚本来管理任务，但是我发现 Ansible 可以完成我想要的一切，并且可以使系统保持在我所需的状态。只用了一天，我就成为了 Ansible 的粉丝。
### 资源
我找到的最完整、最有用的参考文档是 Ansible 网站上的[用户指南][9]。本文仅供参考，不作为入门文档。
多年来，Opensource.com 已经发布了许多[有关 Ansible 的文章][10]，我发现其中大多数对我的需求很有帮助。Enable Sysadmin 网站上也有很多对我有帮助 [Ansible 文章][11]。你可以通过查看本周（2020 年 10 月 13 日至 14 日）的 [AnsibleFest][12] 了解更多信息。该活动完全是虚拟的，可以免费注册。
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/10/first-day-ansible
作者：[David Both][a]
选题：[lujun9972][b]
译者：[MjSeven](https://github.com/MjSeven)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/dboth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003499_01_linux11x_cc.png?itok=XMDOouJR "People work on a computer server with devices"
[2]: https://www.ansible.com/
[3]: https://www.python.org/
[4]: https://midnight-commander.org/
[5]: https://en.wikipedia.org/wiki/List_of_DNS_record_types
[6]: https://docs.ansible.com/ansible/latest/user_guide/playbooks_vars_facts.html#ansible-facts
[7]: https://en.wikipedia.org/wiki/Cowsay
[8]: https://opensource.com/downloads/bash-cheat-sheet
[9]: https://docs.ansible.com/ansible/latest/user_guide/index.html
[10]: https://opensource.com/tags/ansible
[11]: https://www.redhat.com/sysadmin/topics/ansible
[12]: https://www.ansible.com/ansiblefest