document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #19796 from MjSeven/20200908_Ansible

Browse Source 
翻译完成
This commit is contained in:
geekpi 2020-10-09 09:02:42 +08:00 committed by GitHub
commit 231ac22ad3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 205 additions and 229 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

229
sources/tech/20200908 How to install software with Ansible.md
View File

@ -1,229 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (MjSeven)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to install software with Ansible)
[#]: via: (https://opensource.com/article/20/9/install-packages-ansible)
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
How to install software with Ansible
======
Automate software installations and updates across your devices with
Ansible playbooks.
![Puzzle pieces coming together to form a computer screen][1]
Ansible is a popular automation tool used by sysadmins and developers to keep their computer systems in prime condition. As is often the case with extensible frameworks, [Ansible][2] has limited use on its own, with its real power dwelling in its many modules. Ansible modules are, in a way, what commands are to a [Linux][3] computer. They provide solutions to specific problems, and one common task when maintaining computers is keeping all the ones you use updated and consistent.
I used to use a text list of packages to keep my systems more or less synchronized: I'd list the packages installed on my laptop and then cross-reference that with my desktop, or between one server and another server, making up for any difference manually. Of course, installing and maintaining applications on a Linux machine is a basic task for Ansible, and it means you can list what you want across all computers under your care.
### Finding the right Ansible module
The number of Ansible modules can be overwhelming. How do you find the one you need for a given task? In Linux, you might look in your Applications menu or in `/usr/bin` to discover new applications to run. When you're using Ansible, you refer to the [Ansible module index][4].
The index is listed primarily by category. With a little searching, you're very likely to find a module for whatever you need. For package management, the [Packaging modules][5] section contains a module for nearly any system with a package manager.
### Writing an Ansible playbook
To begin, choose the package manager on your local computer. For instance, if you're going to write your Ansible instructions (a "playbook," as it's called in Ansible) on a laptop running Fedora, start with the `dnf` module. If you're writing on Elementary OS, use the `apt` module, and so on. This gets you started with something you can test and verify as you go, and you can expand your work for your other computers later.
The first step is to create a directory representing your playbook. This isn't strictly necessary, but it's a good idea to establish the habit. Ansible can run with just a configuration file written in YAML, but if you want to expand your playbook later, you can control Ansible by how you lay out your directories and files. For now, just create a directory called `install_packages` or similar:
```
`$ mkdir ~/install_packages`
```
The file that serves as the Ansible playbook can be named anything you like, but it's traditional to name it `site.yml`:
```
`$ touch ~/install_packages/site.yml`
```
Open `site.yml` in your favorite text editor, and add this:
```
\---
\- hosts: localhost
  tasks:
    - name: install packages
      become: true
      become_user: root
      dnf:
        state: present
        name:
         - tcsh
         - htop
```
You must adjust the module name you use to match the distribution you're using. In this example, I used `dnf` because I wrote the playbook on Fedora Linux.
Like with a command in a Linux terminal, knowing _how_ to invoke an Ansible module is half the battle. This playbook example follows the standard playbook format:
* `hosts` targets a computer or computers. In this case, the computer being targeted is `localhost`, which is the computer you're using right now (as opposed to a remote system you want Ansible to connect with).
* `tasks` opens a list of tasks you want to be performed on the hosts.
* `name` is a human-friendly title for a task. In this case, I'm using `install packages` because that's what this task is doing.
* `become` permits Ansible to change which user is running this task.
* `become_user` permits Ansible to become the `root` user to run this task. This is necessary because only the root user can install new applications using `dnf`.
* `dnf` is the name of the module, which you discovered from the module index on the Ansible website.
The items under the `dnf` item are specific to the `dnf` module. This is where the module documentation is essential. Like a man page for a Linux command, the module documentation tells you what options are available and what kinds of arguments are required.
![Ansible documentation][6]
Ansible module documentation (Seth Kenlon, [CC BY-SA 4.0][7])
Package installation is a relatively simple task and only requires two elements. The `state` option instructs Ansible to check whether or not _some package_ is present on the system, and the `name` option lists which packages to look for. Ansible deals in machine _state_, so module instructions always imply change. Should Ansible scan a system and find a conflict between how a playbook describes a system (in this case, that the commands `tcsh` and `htop` are present) and what the system state actually is (in this example, `tcsh` and `htop` are not present), then Ansible's task is to make whatever changes are necessary for the system to match the playbook. Ansible can make those changes because of the `dnf` (or `apt` or whatever your package manager is) module.
Each module is likely to have a different set of options, so when you're writing playbooks, anticipate referring to the module documentation often. Until you're very familiar with a module, it's the only reasonable way to expect a module to do what you need it to do.
### Verifying YAML
Playbooks are written in YAML. Because YAML adheres to a strict syntax, it's helpful to install the `yamllint` command to check (or "lint," in computer terminology) your work. Better still, there's a linter specific to Ansible called `ansible-lint` created specifically for playbooks. Install these before continuing.
On Fedora or CentOS:
```
`$ sudo dnf install yamllint python3-ansible-lint`
```
On Debian, Elementary, Ubuntu, or similar:
```
`$ sudo apt install yamllint ansible-lint`
```
Verify your playbook with `ansible-lint`. If you don't have access to `ansible-lint`, you can use `yamllint`.
```
`$ ansible-lint ~/install_packages/site.yml`
```
Success returns nothing, but if there are errors in your file, you must fix them before continuing. Common errors from copying and pasting include omitting a newline character at the end of the final line and using tabs instead of spaces for indentation. Fix them in a text editor, rerun the linter, and repeat this process until you get no feedback from `ansible-lint` or `yamllint`.
### Installing an application with Ansible
Now that you have a verifiably valid playbook, you can finally run it on your local machine. Because you happen to know that the task defined by the playbook requires root permissions, you must use the `--ask-become-pass` option when invoking Ansible, so you will be prompted for your administrative password.
Start the installation:
```
$ ansible-playbook --ask-become-pass ~/install_packages/site.yml
BECOME password:
PLAY [localhost] ******************************
TASK [Gathering Facts] ******************************
ok: [localhost]
TASK [install packages] ******************************
ok: [localhost]
PLAY RECAP ******************************
localhost: ok=0 changed=2 unreachable=0 failed=0 [...]
```
The commands are installed, leaving the target system in an identical state to the one described by the playbook.
### Installing an application on remote systems
Going through all of that to replace one simple command would be counterproductive, but Ansible's advantage is that it can be automated across all of your systems. You can use conditional statements to cause Ansible to use a specific module on different systems, but for now, assume all your computers use the same package manager.
To connect to a remote system, you must define the remote system in the `/etc/ansible/hosts` file. This file was installed along with Ansible, so it already exists, but it's probably empty, aside from explanatory comments. Use `sudo` to open the file in your favorite text editor.
You can define a host by its IP address or hostname, as long as the hostname can be resolved. For instance, if you've already defined `liavara` in `/etc/hosts` and can successfully ping it, then you can set `liavara` as a host in `/etc/ansible/hosts`. Alternately, if you're running a domain name server or Avahi server and can ping `liavara`, then you can set it as a host in `/etc/ansible/hosts`. Otherwise, you must use its internet protocol address.
You also must have set up a successful secure shell (SSH) connection to your target hosts. The easiest way to do that is with the `ssh-copy-id` command, but if you've never set up an SSH connection with a host before, [read my article on how to create an automated SSH connection][8].
Once you've entered the hostname or IP address in the `/etc/ansible/hosts` file, change the `hosts` definition in your playbook:
```
\---
\- hosts: all
  tasks:
    - name: install packages
      become: true
      become_user: root
      dnf:
        state: present
        name:
         - tcsh
         - htop
```
Run `ansible-playbook` again:
```
`$ ansible-playbook --ask-become-pass ~/install_packages/site.yml`
```
This time, the playbook runs on your remote system.
Should you add more hosts, there are many ways to filter which host performs which task. For instance, you can create groups of hosts (`webservers` for servers, `workstations` for desktop machines, and so on).
### Ansible for mixed environments
The logic used in the solution so far assumes that all hosts being configured by Ansible run the same OS (specifically, one that uses the **dnf** command for package management). So what do you do if you're managing hosts running a different distribution, such as Ubuntu (which uses **apt**) or Arch (using **pacman**), or even different operating systems?
As long as the targeted OS has a package manager (and these days even [MacOS has Homebrew][9] and [Windows has Chocolatey][10]), Ansible can help.
This is where Ansible's advantage becomes most apparent. In a shell script, you'd have to check for what package manager is available on the target host, and even with pure Python you'd have to check for the OS. Ansible not only has those checks built in, but it also has mechanisms to use the results in your playbook. Instead of using the **dnf** module, you can use the **action** keyword to perform tasks defined by variables provided by Ansible's fact gathering subsystem.
```
\---
\- hosts: all
  tasks:
    - name: install packages
      become: true
      become_user: root
      action: >
       {{ ansible_pkg_mgr }} name=htop,transmission state=present update_cache=yes
```
The **action** keyword loads action plugins. In this example, it's using the **ansible_pkg_mgr** variable, which is populated by Ansible during the initial **Gathering Facts** task. You don't have to tell Ansible to gather facts about the OS it's running on, so it's easy to overlook it, but when you run a playbook, you see it listed in the default output:
```
TASK [Gathering Facts] *****************************************
ok: [localhost]
```
The **action** plugin uses information from this probe to populate **ansible_pkg_mgr** with the relevant package manager command to install the packages listed after the **name** argument. With 8 lines of code, you can overcome a complex cross-platform quandary that few other scripting options allow.
### Use Ansible
It's the 21st century, and we all expect our computing devices to be connected and relatively consistent. Whether you maintain two or 200 computers, you shouldn't have to perform the same maintenance tasks over and over again. Use Ansible to synchronize the computers in your life, then see what else Ansible can do for you.
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/9/install-packages-ansible
作者：[Seth Kenlon][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/seth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/puzzle_computer_solve_fix_tool.png?itok=U0pH1uwj (Puzzle pieces coming together to form a computer screen)
[2]: https://opensource.com/resources/what-ansible
[3]: https://opensource.com/resources/linux
[4]: https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
[5]: https://docs.ansible.com/ansible/latest/modules/list_of_packaging_modules.html
[6]: https://opensource.com/sites/default/files/uploads/ansible-module.png (Ansible documentation)
[7]: https://creativecommons.org/licenses/by-sa/4.0/
[8]: https://opensource.com/article/20/8/how-ssh
[9]: https://opensource.com/article/20/6/homebrew-mac
[10]: https://opensource.com/article/20/3/chocolatey

205
translated/tech/20200908 How to install software with Ansible.md Normal file
View File

@ -0,0 +1,205 @@
[#]: collector: (lujun9972)
[#]: translator: (MjSeven)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to install software with Ansible)
[#]: via: (https://opensource.com/article/20/9/install-packages-ansible)
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
如何使用 Ansible 安装软件
======
使用 Ansible 剧本自动安装和更新设备上的软件。
![Puzzle pieces coming together to form a computer screen][1]
Ansible 是系统管理员和开发人员用来保持计算机系统处于最佳状态的一种流行的自动化工具。与可扩展框架一样，[Ansible][2] 本身功能有限，它真正的功能体现在许多模块中。在某种程度上，Ansible 模块是 [Linux][3] 系统的命令。它们针对特定问题提供解决方案。维护计算机时的一项常见任务是使所有计算机的更新和一致。
我曾经使用软件包的文本列表来保持系统或多或少同步：我会列出笔记本电脑上安装的软件包，然后将其与台式机或另一台服务器之间进行交叉引用，手动弥补差异。当然，在 Linux 机器上安装和维护应用程序是 Ansible 的一项基本功能，这意味着你可以在自己关心的计算机上列出所需的内容。
### 寻找正确的 Ansible
Ansible 模块的数量非常庞大，如何找到能完成你任务的模块？在 Linux 中，你可以在应用程序菜单或 `/usr/bin` 中查找要运行的应用程序。使用 Ansible 时，参考 [Ansible 模块索引][4]。
这个索引按照类别列出。稍加搜索，你就很可能找到所需的模块。对于包管理，[Packaging 模块][5]几乎适用于所有带包管理器的系统。
### 动手写一个 Ansible 剧本
首先，选择本地计算机上的包管理器。例如，如果你打算在运行 Fedora 的笔记本电脑上编写 Ansible 指令（在 Ansible 中称为“剧本”），那么从 dnf 模块开始。如果你在 Elementary OS 上编写，使用 `apt` 模块，以此类推。这样你就可以开始进行测试和验证，并可以在以后扩展到其它计算机。
第一步是创建一个代表你剧本的目录。这不是绝对必要的，但这是一个好习惯。Ansible 只需要一个配置文件就可以运行在 YAML 中，但是如果你以后想要扩展剧本，你就可以通过改变目录和文件的方式来控制 Ansible。现在，只需创建一个名为 `install_packages` 或类似的目录：
```
$ mkdir ~/install_packages
```
你可以根据自己的喜好来命名 Ansible 的剧本，但通常将其命名为 `site.yml`：
```
$ touch ~/install_packages/site.yml
```
在你最喜欢的文本编辑器中打开 `site.yml`，添加以下内容：
```
\---
\- hosts: localhost
  tasks:
    - name: install packages
      become: true
      become_user: root
      dnf:
        state: present
        name:
         - tcsh
         - htop
```
你必须调整使用的模块名称来匹配你使用的发行版。在此示例中，我使用 `dnf` 是因为我在 Fedora Linux 上编写剧本。
就像 Linux 终端中的命令一样，知道 _如何_ 来调用 Ansible 模块就已经成功了一半。这个示例剧本遵循标准剧本格式：
* `hosts` 是一台或多台计算机。在本示例中，目标计算机是 `localhost`，即你当前正在使用的计算机（而不是你希望 Ansible 连接的远程系统）。
* `tasks` 是你要在主机上执行的任务列表。
* `name` 是任务的人性化名称。在这种情况下，我使用 `install packages`，因为这就是该任务正在做的事情。
* `become` 允许 Ansible 更改运行此任务的用户。
* `become_user` 允许 Ansible 成为 `root` 用户来运行此任务。这是必须的，因为只有 root 用户才能使用 `dnf` 安装应用程序。
* `dnf` 是模块名称，你可以在 Ansible 网站上的模块索引中找到。
`dnf` 下的节点是 `dnf` 模块专用的。这是模块文档的关键所在。就像 Linux 命令的手册页一样，模块文档会告诉你可用的选项和所需的参数。
![Ansible 文档][6]
Ansible module documentation (Seth Kenlon, [CC BY-SA 4.0][7])
安装软件包是一个相对简单的任务，仅需要两个元素。`state` 选项指示 Ansible 检查系统上是否存在 _软件包_，而 `name` 选项列出要查找的软件包。Ansible 会处理机器 _状态_，因此模块指令始终意味着更改。假如 Ansible 扫描了系统状态，发现剧本里描述的系统（在本例中，`tcsh` 和 `htop` 存在）与实际状态存在冲突，那么 Ansible 的任务是进行必要的更改来使系统与剧本匹配。Ansible 可以通过 dnf（或 apt 或者其它任何包管理器）模块进行更改。
每个模块可能都有一组不同的选项，所以在编写剧本时，要经常参考模块文档。除非你对模块非常熟悉，否则这是期望模块完成工作的唯一合理方法。
### 验证 YAML
剧本是用 YAML 编写的。因为 YAML 遵循严格的语法，所以安装 `yamllint` 来检查剧本是很有帮助的。更妙的是，有一个专门针对 Ansible 的检查工具称为 `ansible-lint`，它专门为剧本而生。在继续之前，安装它。
在 Fedora 或 CentOs 上：
```
$ sudo dnf ins tall yamllint python3-ansible-lint
```
在 Debian、Elementary 或 Ubuntu 上，同样的：
```
$ sudo apt install yamllint ansible-lint
```
使用 `ansible-link` 来验证你的剧本。如果你无法使用 `ansible-lint`，你可以使用 `yamllint`。
```
$ ansible-lint ~/install_packages/site.yml
```
成功则不返回任何内容，但如果文件中有错误，则必须先修复它们，然后再继续。复制和粘贴过程中的常见错误包括在最后一行的末尾省略换行符、使用制表符而不是空格来缩进。在文本编辑器中修复它们，重新运行 `ansible-llint`，重复这个过程，直到 `ansible-lint` 或 `yamllint` 没有返回为止。
### 使用 Ansible 安装一个应用
现在你有了一个可验证的有效剧本，你终于可以在本地计算机上运行它了，因为你碰巧知道该剧本定义的任务需要 root 权限，所以在调用 Ansible 时必须使用 `--ask-become-pass` 选项，因此系统会提示你输入管理员密码。
开始安装：
```
$ ansible-playbook --ask-become-pass ~/install_packages/site.yml
BECOME password:
PLAY [localhost] ******************************
TASK [Gathering Facts] ******************************
ok: [localhost]
TASK [install packages] ******************************
ok: [localhost]
PLAY RECAP ******************************
localhost: ok=0 changed=2 unreachable=0 failed=0 [...]
```
这些命令被执行后，目标系统将处于与剧本中描述的相同的状态。
### 在远程系统上安装应用程序
通过这么多操作来替换一个简单的命令可能会适得其反，但是 Ansible 的优势是它可以在你的所有系统中实现自动化。你可以使用条件语句使 Ansible 在不同的系统上使用特定的模块，但是现在，假定所有计算机都使用相同的包管理器。
要连接到远程系统，你必须在 `/etc/ansible/hosts` 文件中定义远程系统，该文件与 Ansible 是一起安装的，所以它已经存在了，但它可能是空的，除了一些解释性注释之外。使用 `sudo` 在你喜欢的文本编辑器中打开它。
只要主机名可以解析，就可以通过其 IP 地址或主机名定义主机。例如，如果你已经在 `/etc/hosts` 中定义了 `liavara` 并可以成功 ping 通，那么你可以在 `/etc/ansible/hosts` 中将 `liavara` 设置为主机。或者，如果你正在运行一个域名服务器或 Avahi 服务器并且可以 ping 通 `liavara`，那么你就可以在 `/etc/ansible/hosts` 中定义它。否则，你必须使用它的 IP 地址。
你还必须成功地建立与目标主机的安全 shell（SSH）连接。最简单的方法是使用 `ssh-copy-id` 命令，但是如果你以前从未与主机建立 SSH 连接，[阅读我关于如何创建自动 SSH 连接的文章][8]。
一旦你在 `/etc/ansible/hosts` 文件中输入了主机名或 IP 地址后，你就可以在剧本中更改 `hosts` 定义：
```
\---
\- hosts: all
  tasks:
    - name: install packages
      become: true
      become_user: root
      dnf:
        state: present
        name:
         - tcsh
         - htop
```
再次运行 `ansible-playbook`:
```
$ ansible-playbook --ask-become-pass ~/install_packages/site.yml
```
这次，剧本会在你的远程系统上运行。
如果你添加更多主机，则有许多方法可以过滤哪个主机执行哪个任务。例如，你可以创建主机组（服务器的 `webserves`，台式机的 `workstations`等）。
### 适用于混合环境的 Ansible
到目前为止，我们一直假定 Ansible 配置的所有主机都运行相同的操作系统（都是是使用 **dnf** 命令进行程序包管理的操作系统）。那么，如果你要管理不同发行版的主机，例如 Ubuntu（使用 **apt**）或 Arch（使用 **pacman**），或者其它的操作系统时，该怎么办？
只要目标操作系统具有程序包管理器（[MacOs 有 Homebrew][9]，[Windows 有 Chocolatey][10]），Ansible 就能派上用场。
这就是 Ansible 优势最明显的地方。在 shell 脚本中，你必须检查目标主机上有哪些可用的包管理器，即使使用纯 Python，也必须检查操作系统。Ansible 不仅内置了这些功能，而且还具有在剧本中使用命令结果的机制。你可以使用 **action** 关键字来执行由 Ansible 事实收集子系统提供的变量定义的任务，而不是使用 **dnf** 模块。
```
\---
\- hosts: all
  tasks:
    - name: install packages
      become: true
      become_user: root
      action: >
       {{ ansible_pkg_mgr }} name=htop,transmission state=present update_cache=yes
```
**action** 关键字会加载目标插件。在本例中，它使用了 **ansible_pkg_mgr** 变量，该变量由 Ansible 在初始 **收集信息** 期间填充。你不需要告诉 Ansible 收集有关其运行操作系统的事实，所以很容易忽略这一点，但是当你运行一个剧本时，你会在默认输出中看到它：
```
TASK [Gathering Facts] *****************************************
ok: [localhost]
```
**action** 插件使用来自这个探针的信息，使用相关的包管理器命令填充 **ansible_pkg_mgr**，以安装在 **name** 参数之后列出的程序包。使用 8 行代码，你可以克服在其它脚本选项中很少允许的复杂跨平台难题。
### 使用 Ansible
现在是 21 世纪，我们都希望我们的计算机设备能够互联并且相对一致。无论你维护的是两台还是 200 台计算机，你都不必一次又一次地执行相同的维护任务。使用 Ansible 来同步生活中的计算机设备，看看 Ansible 还能为你做些什么。
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/9/install-packages-ansible
作者：[Seth Kenlon][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/seth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/puzzle_computer_solve_fix_tool.png?itok=U0pH1uwj (Puzzle pieces coming together to form a computer screen)
[2]: https://opensource.com/resources/what-ansible
[3]: https://opensource.com/resources/linux
[4]: https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
[5]: https://docs.ansible.com/ansible/latest/modules/list_of_packaging_modules.html
[6]: https://opensource.com/sites/default/files/uploads/ansible-module.png (Ansible documentation)
[7]: https://creativecommons.org/licenses/by-sa/4.0/
[8]: https://opensource.com/article/20/8/how-ssh
[9]: https://opensource.com/article/20/6/homebrew-mac
[10]: https://opensource.com/article/20/3/chocolatey