标签 Ansible 下的文章

市面上有很多自动化工具。我可以举几个例子,例如 Puppet、Chef、CFEngine、Foreman、Katello、Saltstock、Space Walk,它们被许多组织广泛使用。

自动化工具可以做什么?

自动化工具可以自动执行例行任务,无需人工干预,从而使 Linux 管理员的工作变得更加轻松。这些工具允许用户执行配置管理,应用程序部署和资源调配。

为什么喜欢 Ansible?

Ansible 是一种无代理的自动化工具,使用 SSH 执行所有任务,但其它工具需要在客户端节点上安装代理。

什么是 Ansible?

Ansible 是一个开源、易于使用的功能强大的 IT 自动化工具,通过 SSH 在客户端节点上执行任务。

它是用 Python 构建的,这是当今世界上最流行、最强大的编程语言之一。两端都需要使用 Python 才能执行所有模块。

它可以配置系统、部署软件和安排高级 IT 任务,例如连续部署或零停机滚动更新。你可以通过 Ansible 轻松执行任何类型的自动化任务,包括简单和复杂的任务。

在开始之前,你需要了解一些 Ansible 术语,这些术语可以帮助你更好的创建任务。

Ansible 如何工作?

Ansible 通过在客户端节点上推送称为 ansible 模块的小程序来工作,这些模块临时存储在客户端节点中,通过 JSON 协议与 Ansible 服务器进行通信。

Ansible 通过 SSH 运行这些模块,并在完成后将其删除。

模块是用 Python 或 Perl 等编写的一些脚本。

控制节点,用于控制剧本的全部功能,包括客户端节点(主机)。

  • 控制节点 Control node :使用 Ansible 在受控节点上执行任务的主机。你可以有多个控制节点,但不能使用 Windows 系统主机当作控制节点。
  • 受控节点 Managed node :控制节点配置的主机列表。
  • 清单 Inventory :控制节点管理的一个主机列表,这些节点在 /etc/ansible/hosts 文件中配置。它包含每个节点的信息,比如 IP 地址或其主机名,还可以根据需要对这些节点进行分组。
  • 模块 Module :每个模块用于执行特定任务,目前有 3387 个模块。
  • 点对点 ad-hoc :它允许你一次性运行一个任务,它使用 /usr/bin/ansible 二进制文件。
  • 任务 Task :每个 动作 Play 都有一个任务列表。任务按顺序执行,在受控节点中一次执行一个任务。
  • 剧本 Playbook :你可以使用剧本同时执行多个任务,而使用点对点只能执行一个任务。剧本使用 YAML 编写,易于阅读。将来,我们将会写一篇有关剧本的文章,你可以用它来执行复杂的任务。

测试环境

此环境包含一个控制节点(server.2g.lab)和三个受控节点(node1.2g.labnode2.2g.labnode3.2g.lab),它们均在虚拟环境中运行,操作系统分别为:

System PurposeHostnameIP AddressOS
Ansible Control Nodeserver.2g.lab192.168.1.7Manjaro 18
Managed Node1node1.2g.lab192.168.1.6CentOS7
Managed Node2node2.2g.lab192.168.1.5CentOS8
Managed Node3node3.2g.lab192.168.1.9Ubuntu 18.04
User: daygeek

前置条件

  • 在 Ansible 控制节点和受控节点之间启用无密码身份验证。
  • 控制节点必须是 Python 2(2.7 版本) 或 Python 3(3.5 或更高版本)。
  • 受控节点必须是 Python 2(2.6 或更高版本) 或 Python 3(3.5 或更高版本)。
  • 如果在远程节点上启用了 SELinux,则在 Ansible 中使用任何与复制、文件、模板相关的功能之前,还需要在它们上安装 libselinux-python

如何在控制节点上安装 Ansible

对于 Fedora/RHEL 8/CentOS 8 系统,使用 DNF 命令 来安装 Ansible。

注意:你需要在 RHEL/CentOS 系统上启用 EPEL 仓库,因为 Ansible 软件包在发行版官方仓库中不可用。

$ sudo dnf install ansible

对于 Debian/Ubuntu 系统,使用 APT-GET 命令APT 命令 来安装 Ansible。

配置下面的 PPA 以便在 Ubuntu 上安装最新稳定版本的 Ansible。

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo apt-add-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible

对于 Debian 系统,配置以下源列表:

$ echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main" | sudo tee -a /etc/apt/sources.list.d/ansible.list
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
$ sudo apt update
$ sudo apt install ansible

对于 Arch Linux 系统,使用 Pacman 命令 来安装 Ansible:

$ sudo pacman -S ansible

对于 RHEL/CentOS 系统,使用 YUM 命令 来安装 Ansible:

$ sudo yum install ansible

对于 openSUSE 系统,使用 Zypper 命令 来安装 Ansible:

$ sudo zypper install ansible

或者,你可以使用 Python PIP 包管理工具 来安装:

$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ sudo python get-pip.py
$ sudo pip install ansible

在控制节点上检查安装的 Ansible 版本:

$ ansible --version

ansible 2.9.2
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/daygeek/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.8/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.1 (default, Jan  8 2020, 23:09:20) [GCC 9.2.0]

如何在受控节点上安装 Python?

使用以下命令在受控节点上安装 python:

$ sudo yum install -y python
$ sudo dnf install -y python
$ sudo zypper install -y python
$ sudo pacman -S python
$ sudo apt install -y python

如何在 Linux 设置 SSH 密钥身份验证(无密码身份验证)

使用以下命令创建 ssh 密钥,然后将其复制到远程计算机。

$ ssh-keygen
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

具体参考这篇文章《在 Linux 上设置 SSH 密钥身份验证(无密码身份验证)》。

如何创建 Ansible 主机清单

/etc/ansible/hosts 文件中添加要管理的节点列表。如果没有该文件,则可以创建一个新文件。以下是我的测试环境的主机清单文件:

$ sudo vi /etc/ansible/hosts

[web]
node1.2g.lab
node2.2g.lab

[app]
node3.2g.lab

让我们看看是否可以使用以下命令查找所有主机。

$ ansible all --list-hosts

 hosts (3):
   node1.2g.lab
   node2.2g.lab
   node3.2g.lab

对单个组运行以下命令:

$ ansible web --list-hosts

 hosts (2):
   node1.2g.lab
   node2.2g.lab

如何使用点对点命令执行任务

一旦完成主机清单验证检查后,你就可以上路了。干的漂亮!

语法:

ansible [pattern] -m [module] -a "[module options]"

Details:
========
ansible: A command
pattern: Enter the entire inventory or a specific group
-m [module]: Run the given module name
-a [module options]: Specify the module arguments

使用 Ping 模块对主机清单中的所有节点执行 ping 操作:

$ ansible all -m ping

node3.2g.lab | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
node1.2g.lab | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
node2.2g.lab | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}

所有系统都返回了成功,但什么都没有改变,只返回了 pong 代表成功。

你可以使用以下命令获取可用模块的列表。

$ ansible-doc -l

当前有 3387 个内置模块,它们会随着 Ansible 版本的递增而增加:

$ ansible-doc -l | wc -l
3387

使用 command 模块对主机清单中的所有节点执行命令:

$ ansible all -m command -a "uptime"

node3.2g.lab | CHANGED | rc=0 >>
 18:05:07 up  1:21,  3 users,  load average: 0.12, 0.06, 0.01
node1.2g.lab | CHANGED | rc=0 >>
 06:35:06 up  1:21,  4 users,  load average: 0.01, 0.03, 0.05
node2.2g.lab | CHANGED | rc=0 >>
 18:05:07 up  1:25,  3 users,  load average: 0.01, 0.01, 0.00

对指定组执行 command 模块。

检查 app 组主机的内存使用情况:

$ ansible app -m command -a "free -m"

node3.2g.lab | CHANGED | rc=0 >>
              total        used        free      shared  buff/cache   available
Mem:           1993        1065          91           6         836         748
Swap:          1425           0        1424

要对 web 组运行 hostnamectl 命令,使用以下格式:

$ ansible web -m command -a "hostnamectl"

node1.2g.lab | CHANGED | rc=0 >>
   Static hostname: CentOS7.2daygeek.com
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 002f47b82af248f5be1d67b67e03514c
           Boot ID: dc38f9b8089d4b2d9304e526e00c6a8f
    Virtualization: kvm
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-957.el7.x86_64
      Architecture: x86-64
node2.2g.lab | CHANGED | rc=0 >>
   Static hostname: node2.2g.lab
         Icon name: computer-vm
           Chassis: vm
        Machine ID: e39e3a27005d44d8bcbfcab201480b45
           Boot ID: 27b46a09dde546da95ace03420fe12cb
    Virtualization: oracle
  Operating System: CentOS Linux 8 (Core)
       CPE OS Name: cpe:/o:centos:centos:8
            Kernel: Linux 4.18.0-80.el8.x86_64
      Architecture: x86-64

参考:Ansible 文档


via: https://www.2daygeek.com/install-configure-ansible-automation-tool-linux-quick-start-guide/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:MjSeven 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

一名系统管理员分享了如何使用 Ansible 在网络中配置计算机并把其带入实际工作的信息和建议。

 title=

无论是第一次还是第五十次,启动并运行一台新的物理或虚拟计算机都非常耗时,而且需要大量的工作。多年来,我一直使用我创建的一系列脚本和 RPM 来安装所需的软件包,并为我喜欢的工具配置各种选项。这种方法效果很好,简化了我的工作,而且还减少了在键盘上输入命令的时间。

我一直在寻找更好的工作方式。近几年来,我一直在听到并且读到有关 Ansible 的信息,它是一个自动配置和管理系统的强大工具。Ansible 允许系统管理员在一个或多个 剧本 playbook 中为每个主机指定一个特定状态,然后执行各种必要的任务,使主机进入该状态。这包括安装或删除各种资源,例如 RPM 或 Apt 软件包、配置文件和其它文件、用户、组等等。

因为一些琐事,我推迟了很长一段时间学习如何使用它。直到最近,我遇到了一个我认为 Ansible 可以轻松解决的问题。

这篇文章并不会完整地告诉你如何入门 Ansible,相反,它只是对我遇到的问题和我在一些隐秘的地方发现的信息的做了一些记录。我在各种在线讨论和问答小组中找到的有关 Ansible 的许多信息都是错误的。错误范围包括明显的老旧信息(没有任何日期或来源的迹象),还有一些是完全错误的信息。

本文所介绍的内容是有用的,尽管可能还有其它方法可以完成相同的事情,但我使用的是 Ansible 2.9.13 和 Python 3.8.5。

我的问题

我所有的最佳学习经历都始于我需要解决的问题,这次也不例外。

我一直在做一个小项目,修改 Midnight Commander 文件管理器的配置文件,并将它们推送到我网络上的各种系统中进行测试。尽管我有一个脚本可以自动执行这个操作,但它仍然需要使用命令行循环来提供我想要推送新代码的系统名称。我对配置文件进行了大量的更改,这使我必须频繁推送新的配置文件。但是,就在我以为我的新配置刚刚好时,我发现了一个问题,所以我需要在修复后再进行一次推送。

这种环境使得很难跟踪哪些系统有新文件,哪些没有。我还有几个主机需要区别对待。我对 Ansible 的一点了解表明,它可能能够满足我的全部或大部分工作。

开始

我读过许多有关 Ansible 的好文章和书籍,但从来没有在“我必须现在就把这个做好!”的情况下读过。而现在 —— 好吧,就是现在!

在重读这些文档时,我发现它们主要是在讨论如何从 GitHub 开始安装并使用 Ansible,这很酷。但是我真的只是想尽快开始,所以我使用 DNF 和 Fedora 仓库中的版本在我的 Fedora 工作站上安装了它,非常简单。

但是后来我开始寻找文件位置,并尝试确定需要修改哪些配置文件、将我的剧本保存在什么位置,甚至一个剧本怎么写以及它的作用,我脑海中有一大堆(到目前为止)悬而未决的问题。

因此,不不需要进一步描述我的困难的情况下,以下是我发现的东西以及促使我继续前进的东西。

配置

Ansible 的配置文件保存在 /etc/ansible 中,这很有道理,因为 /etc/ 是系统程序应该保存配置文件的地方。我需要使用的两个文件是 ansible.cfghosts

ansible.cfg

在进行了从文档和线上找到的一些实践练习之后,我遇到了一些有关弃用某些较旧的 Python 文件的警告信息。因此,我在 ansible.cfg 中将 deprecation_warnings 设置为 false,这样那些愤怒的红色警告消息就不会出现了:

deprecation_warnings = False

这些警告很重要,所以我稍后将重新回顾它们,并弄清楚我需要做什么。但是现在,它们不会再扰乱屏幕,也不会让我混淆实际上需要关注的错误。

hosts 文件

/etc/hosts 文件不同,hosts 文件也被称为 清单 inventory 文件,它列出了网络上的主机。此文件允许将主机分组到相关集合中,例如“servers”、“workstations”和任何你所需的名称。这个文件包含帮助和大量示例,所以我在这里就不详细介绍了。但是,有些事情你必须知道。

主机也可以列在组之外,但是组对于识别具有一个或多个共同特征的主机很有帮助。组使用 INI 格式,所以服务器组看起来像这样:

[servers]
server1
server2
......

这个文件中必须有一个主机名,这样 Ansible 才能对它进行操作。即使有些子命令允许指定主机名,但除非主机名在 hosts 文件中,否则命令会失败。一个主机也可以放在多个组中。因此,除了 [servers] 组之外,server1 也可能是 [webservers] 组的成员,还可以是 [ubuntu] 组的成员,这样以区别于 Fedora 服务器。

Ansible 很智能。如果 all 参数用作主机名,Ansible 会扫描 hosts 文件并在它列出的所有主机上执行定义的任务。Ansible 只会尝试在每个主机上工作一次,不管它出现在多少个组中。这也意味着不需要定义 all 组,因为 Ansible 可以确定文件中的所有主机名,并创建自己唯一的主机名列表。

另一件需要注意的事情是单个主机的多个条目。我在 DNS 文件中使用 CNAME 记录来创建别名,这些别名指向某些主机的 A 记录,这样,我可以将一个主机称为 host1h1myhost。如果你在 hosts 文件中为同一主机指定多个主机名,则 Ansible 将尝试在所有这些主机名上执行其任务,它无法知道它们指向同一主机。好消息是,这并不会影响整体结果;它只是多花了一点时间,因为 Ansible 会在次要主机名上工作,它会确定所有操作均已执行。

Ansible 实情

我阅读过 Ansible 的大多数材料都谈到了 Ansible 实情 facts ,它是与远程系统相关的数据,包括操作系统、IP 地址、文件系统等等。这些信息可以通过其它方式获得,如 lshwdmidecode/proc 文件系统等。但是 Ansible 会生成一个包含此信息的 JSON 文件。每次 Ansible 运行时,它都会生成这些实情数据。在这个数据流中,有大量的信息,都是以键值对形式出现的:<"variable-name": "value">。所有这些变量都可以在 Ansible 剧本中使用,理解大量可用信息的最好方法是实际显示一下:

# ansible -m setup <hostname> | less

明白了吗?你想知道的有关主机硬件和 Linux 发行版的所有内容都在这里,它们都可以在剧本中使用。我还没有达到需要使用这些变量的地步,但是我相信在接下来的几天中会用到。

模块

上面的 ansible 命令使用 -m 选项来指定 setup 模块。Ansible 已经内置了许多模块,所以你对这些模块不需要使用 -m。也可以安装许多下载的模块,但是内置模块可以完成我目前项目所需的一切。

剧本

剧本 playbook 几乎可以放在任何地方。因为我需要以 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 开始(如果它不是最新的版本的话)。下一个任务确保创建所需的目录(如果它们不存在),其余任务将文件复制到合适的位置,这些 filecopy 任务还可以为目录和文件设置所有权和文件模式。

剧本细节超出了本文的范围,但是我对这个问题使用了一点蛮力。还有其它方法可以确定哪些用户需要更新文件,而不是对每个用户的每个文件使用一个任务。我的下一个目标是简化这个剧本,使用一些更先进的技术。

运行剧本很容易,只需要使用 ansible-playbook 命令。.yml 扩展名代表 YAML,我看到过它的几种不同含义,但我认为它是“ 另一种标记语言 Yet Another Markup Language ”,尽管有些人声称 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] =&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]

<截断>

cowsay

如果你的计算机上安装了 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,因为有更好的方法可以实现特定的计算机状态。我想到的场景是使 VM 返回到初始状态,以便可以多次使用它来执行从已知状态开始的测试。让 VM 进入特定状态,然后对此时的计算机状态进行快照要容易得多。还原到该快照与 Ansible 将主机返回到之前状态相比,通常还原到快照通常会更容易且更快。在研究文章或测试新代码时,我每天都会做几次这样的事情。

在完成用于更新 Midnight Commander 的剧本之后,我创建了一个新的剧本,用于在新安装的 Fedora 主机上执行安装任务。我已经取得了不错的进步,剧本比我第一个的更加复杂,但没有那么粗暴。

在使用 Ansible 的第一天,我创建了一个解决问题的剧本,我还开始编写第二个剧本,它将解决安装后配置的大问题,在这个过程中我学到了很多东西。

尽管我真的很喜欢使用 Bash 脚本来管理任务,但是我发现 Ansible 可以完成我想要的一切,并且可以使系统保持在我所需的状态。只用了一天,我就成为了 Ansible 的粉丝。

资源

我找到的最完整、最有用的参考文档是 Ansible 网站上的用户指南。本文仅供参考,不作为入门文档。

多年来,我们已经发布了许多有关 Ansible 的文章,我发现其中大多数对我的需求很有帮助。Enable Sysadmin 网站上也有很多对我有帮助 Ansible 文章。你可以通过查看本周(2020 年 10 月 13 日至 14 日)的 AnsibleFest 了解更多信息。该活动完全是线上的,可以免费注册。


via: https://opensource.com/article/20/10/first-day-ansible

作者:David Both 选题:lujun9972 译者:MjSeven 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

只要付出一点点努力,你就可以帮助下一个人,不只是绘制出安全路径,还可以留下危险的警告。

 title=

在博客圈里,人们对基础架构即代码、持续集成/持续交付(CI/CD)管道、代码审查和测试制度赞不绝口,但人们很容易忘记,这种精心设计的象牙塔只是一种理想,而不是现实。虽然不完美的系统困扰着我们,但我们必须交付一些东西。

在系统自动化的过程中,很少有比那些通过粘合 API 创建的象牙塔更脆弱的塔。这是一个脆弱的世界。要让它“工作起来”,交付它,然后继续前进,压力巨大。

要解决的问题

想象一个简单的功能请求:编写一些 Ansible 代码,在外部系统中创建几条记录,以记录一个 VLAN 的一些详细信息。我最近很想做一些实验室的管理工作来完成这个任务。这个外部系统是一个常见的 互联网协议地址管理 Internet Protocol Address Management (IPAM)工具,但对于一个更抽象的 配置管理数据库 Configuration Management DataBase (CMDB)或一个与网络无关的记录来说,困难是一样的。在这个例子中,我创建一个记录的直接愿望就是让系统保存记录而已。

如果我们的目标是一个超紧凑的、直接的、笨拙的宏,那么它可能用 100 行代码就能写出来。如果我记得 API,我也许能在一个小时内把它敲出来,该代码的作用不会超过预期,除了确切的成品之外,什么也没留下。对它的目的而言是完美的,但是对未来的扩展毫无用处。

如今,我希望几乎每个人都能从一个 角色 role 和几个 任务 task 文件开始这项任务,准备扩展到十几个创建、读取、更新和删除(CRUD)操作。因为我不了解这个 API,我可能会花上几个小时到几天的时间,仅仅是摆弄它,弄清楚它的内部模式和工艺,弥和它的功能和我用代码编写出来的意图之间的差距。

在研究 API 的时候,我发现创建一个 VLAN 记录需要一个父对象引用 vlan_view_ref。这看起来像一个路径片段,里面有随机字符。也许它是一个哈希,也许它真的是随机的,我不确定。我猜想,许多在泥泞中挣扎的人,在迫在眉睫的截止日期前,可能会把这个任意的字符串复制粘贴到 Ansible 中,然后继续混下去。忽略这个 角色 role 的实现细节,显而易见这个 剧本 playbook 级的任务应该是这样:

- name: "Create VLAN"
  include_role:
    name: otherthing
    tasks_from: vlan_create.yml
  vars:
    vlan_name: "lab-infra"
    vlan_tag: 100
    vlan_view_ref: "vlan_view/747f602d-0381"

不幸的是,除了通过 API,vlan_view_ref 标识符是不可用的,所以即使把它移到 清单文件 inventory 或额外的变量中也没有什么帮助。 剧本 playbook 的用户需要对系统有一些更深入的理解,才能找出正确的引用 ID。

在实验室建设的情况下,我会经常重新部署这个记录系统。因此,这个父对象引用 ID 每天都会发生变化,我不希望每次都要手动找出它。所以,我肯定要按名称搜索该引用。没问题:

- name: Get Lab vlan view reference
  include_role:
    name: otherthing
    tasks_from: search_for.yml
  vars:
    _resource: vlan_view
    _query: "name={{ vlan_parent_view_name }}"

最终,它进行了一个 REST 调用。这将“返回” 一个 JSON,按照惯例,为了便于在角色外访问,我把它填充进了 _otherthing_search_result 中,。search_for.yml 的实现是抽象的,它总是返回一个包含零或多个结果的字典。

正如我读过的几乎所有真实世界的 Ansible 代码所证明的那样,大多数 Ansible 开发者将会继续前进,好像一切都很好,并且可以直接访问预期的单个结果:

- name: Remember our default vlan view ref
  set_fact:
    _thatthig_vlan_view_ref: "{{ _otherthing_search_result[0]._ref }}"

- name: "Create VLAN"
  include_role:
    name: otherthing
    tasks_from: vlan_create.yml
  vars:
    vlan_name: "lab-infra"
    vlan_tag: 100
    vlan_view_ref: "{{ vlan_parent_view_name }}"

但有时 _otherthing_search_result[0] 是未定义的,所以 _thatthig_vlan_view_ref 也将是未定义的。很有可能是因为代码运行在不同的真实环境中,而有人忘记了在清单中或在命令行中更新 {{ vlan_parent_view_name }}。或者,无论公平与否,也许有人进入了工具的图形用户界面(GUI),删除了记录或更改了它的名称什么的。

我知道你在想什么。

“好吧,不要这样做。这是一个没有哑巴的场所。不要那么笨。”

也许我对这种情况还算满意,反驳道:“Ansible 会很正确的告诉你错误是:list 对象没有元素 0,甚至会带个行号。你还想怎样?”作为开发者,我当然知道这句话的意思 —— 我刚写的代码。我刚从三天的和 API 斗智斗勇中走出来,我的脑子很清醒。

明天是另一个故事

但是到了明天,我可能会忘记什么是父对象引用,我肯定会忘记第 30 行上的内容。如果一个月后出了问题,就算你能找到我,我也得花一个下午的时间重新解读 API 指南,才能搞清楚到底出了什么问题。

而如果我出门了呢?如果我把代码交给了一个运维团队,也许是一个实习生通过 Tower 来运行,把 vlan_view_name 手动输入到表单之类的东西呢?那第 30 行出的问题是对他们没有帮助的。

你说,加注释吧! 嗯,是的。我可以在代码中写一些梗概,以帮助下周或下个月的开发人员。这对运行代码的人没有帮助,他的“工作”刚刚失败,当然对于企业也无济于事。

记住,我们此刻无所不能。在写代码或者跳过写代码的时候,我们是站在实力和知识的立场上进行的。我们花了几个小时,甚至几天的时间,研究了文档、现实、其他 bug、其他问题,我们留下了代码、注释,甚至可能还有文档。我们写的代码是分享成功的,而成功正是我们用户想要的。但是在这种学习中也有很多失败的地方,我们也可以留下这些。

在代码中留言

“第 30 行有错误”对任何人都没有帮助。至少,我可以用更好的错误信息来处理明显的错误情况:

  - name: Fail if zero vlan views returned
     fail:
       msg: "Got 0 results from searching for VLAN view {{ vlan_parent_view_name }}. Please verify exists in otherthing, and is accessible by the service account."
     when: _otherthing_search_result | length == 0

在这四行代码中(没有额外的思考),我把具体的、有用的建议留给了下一个人 —— 那个无助的运维团队成员,或者更有可能是一个月后的我 —— 这是关于现实世界中的问题,其实根本不是关于代码的。这条消息可以让任何人发现一个简单的复制/粘贴错误,或者记录系统发生了变化。不需要 Ansible 知识,不需要凌晨 3 点给开发人员发短信“看看第 30 行”。

但是等等!还有更多!

在了解 otherthing 的过程中,我了解到它在一个关键的方面,嗯,还挺笨的。它的许多记录类型(如果不是全部的话)没有唯一性约束,可能存在几个相同的记录。VLAN 视图被定义为有一个名称、一个开始 ID 和一个结束 ID;其他记录类型也同样简单,显然这应该是一个唯一的元组 —— 基于现实和数据库规范化的抽象概念。但 otherthing 允许重复的元组,尽管在概念上讲永远不可能。

在我的实验室里,我很乐意尝试并记住不要这样做。在企业生产环境中,我可能会写一个策略。不管是哪种方式,经验告诉我,系统会被破坏,会在倒霉的时候被破坏,而且可能需要很长时间才能让这些问题发酵成,嗯,一个问题。

对于 “第 30 行有错误”,一个本来有丰富经验的 Ansible 开发者可能会认识到这是“记录没有找到”,而不用知道其他的事情就足以解决这个问题。但如果 _otherthing_search_result[0] 只有有时是正确的 vlan_view_ref,那就糟糕多了,它让整个世界被破坏,而悄无声息。而这个错误可能完全表现在其他地方,也许六个月后的安全审计会将其标记为记录保存不一致,如果有多种工具和人工访问方式,可能需要几天或几周的时间才能发现这个特定代码出错的事实。

在几天对 API 的摸索中,我学到了这一点。我不是在找问题,如果有记录,我没有看到。所以我来到了这篇文章的重点。我没有因为它是一个实验室,修复它,然后继续前进而忽略了这种不可能的情况,而是花了两分钟留下了\_代码\_ —— 不是注释,不是心理笔记,不是文档 —— 而是会一直运行的代码,涵盖了这种不可能的情况:

  - name: Fail if > 1 views returned
     fail:
       msg: "Got {{ _otherthing_search_result | length }} results from searching for VLAN view {{ vlan_parent_view_name }}. Otherthing allows this, but is not handled by this code."
     when: _otherthing_search_result | length > 1

我手动创建了失败条件,所以我可以手动测试这个条件。我希望它永远不会在实际使用中运行,但我觉得它会。

如果(当)这个错误发生在生产环境中,那么有人可以决定该怎么做。我希望他们能修复坏数据。如果它经常发生,我希望他们能追踪到另一个损坏的系统。如果他们要求删除这段代码,而这段代码做了未定义和错误的事情,那是他们的特权,也是我不想工作的地方。代码是不完美的,但它是完整的。这是匠人的工作。

现实世界中的自动化是一个迭代的过程,它与不完美的系统进行斗争,并平等地使用。它永远不会处理所有的特殊情况。它甚至可能无法处理所有的正常情况。通过 Lint、代码审查和验收测试的工作代码是处理安全和所需路径的代码。只要付出一点点努力,你就可以帮助下一个人,不仅仅是绘制安全路径,还可以对你发现的危险留下警告。


via: https://opensource.com/article/21/1/improve-ansible-play

作者:Jeff Warncia 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

建立一个支持学习和实验新软件的环境。

能够构建和拆解公有云环境是非常有用的,但我们大多数人都不能轻松访问公有云。退而求其次的最好办法就是在本地机器上建立一个实验室,但即使在本地机器上运行也会带来性能、灵活性和其他挑战。大多数时候,本地机器上额外的工作负载会干扰我们日常的工作,它们当然也会影响你提供一个现成的环境来玩耍和实验新软件。

几年前,当我和我的团队开始学习 Ansible 时,我们就遇到了这个挑战。我们找不到一个可以单独使用的环境,我们对这种情况的失望导致我们中的一些人停止了实验。我们知道需要找到一个解决方案。

我们花了很多时间研究各种方案,得出了一套工具,使我们的好奇心能够在我们完全控制的环境中学习。我们可以在本地机器上轮换和拆解实验室环境,而不需要访问内部实验室或公共云。

本文将解释如何在 20 分钟内以完全自动化的方式在本地机器上部署自己的实验室环境。

你可以在我的 GitHub 仓库中找到这个练习的所有代码。

工具和软件

本方案使用以下工具和软件:

  • Ansible 是我们选择的自动化工具,因为它易于使用,而且足够灵活,可以满足实验室的要求。
  • Vagrant 易于使用,用于构建和维护虚拟机。
  • VirtualBox 是一个托管管理程序,可以在 Windows 和 Linux 环境中使用。
  • Fedora v30+ 是我本地机器上的操作系统。

你必须进行以下设置才能建立环境:

  • 一个互联网连接
  • 在 BIOS 中启用虚拟化技术支持(以下是在我的联想笔记本上的过程
  • Vagrant v2.2.9
  • 最新版本的 Ansible
  • 最新版本的 VirtualBox
  • Fedora v30+ 宿主机操作系统

这个实验室环境有什么?

这个项目旨在部署一个带有 Ansible 引擎和多个 Linux 节点的 Ansible 主机,以及一些预加载和预配置的应用程序(httpd 和 MySQL)。它还启用了 Cockpit,这样你就可以在测试过程中监控虚拟机(VM)的状态。使用预部署的应用程序的原因是为了提高效率(所以你不必花时间安装这些组件)。这样你就可以专注于创建角色和剧本,并针对上述工具部署的环境进行测试。

我们确定,对于我们的用例来说,最好的方案是多机 Vagrant 环境。Vagrant 文件创建了三个 CentOS 虚拟机,以模拟两个目标主机和一个 Ansible 控制机。

  • Host1: 没有图形用户界面(GUI),安装 httpd 和 MySQL
  • Host2: 没有 GUI,安装了 httpd 和 MySQL
  • Ansible-host:没有 GUI,安装了 Ansible 引擎

启用多个管理程序

如果使用了多个管理程序,一些管理程序可能不允许你拉起虚拟机。要解决这个问题,请遵循以下步骤(基于 Vagrant 的安装说明)。

首先,找出管理程序的名称:

$ lsmod | grep kvm
kvm_intel             204800  6
kvm                   593920  1 kvm_intel
irqbypass              16384  1 kvm

我感兴趣的是 kvm_intel,但你可能需要另一个(比如 kvm_amd)。

以 root 身份运行以下内容,将该管理程序列入黑名单:

$ echo 'blacklist kvm-intel' >> /etc/modprobe.d/blacklist.conf

重新启动你的机器并尝试再次运行 Vagrant。

Vagrant 文件

cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
# Define VMs with static private IP addresses, vcpu, memory and vagrant-box.
  boxes = [
    {
      :name => "web1.demo.com", ⇒ Host1 this is one of the target nodes
      :box => "centos/8",             ⇒ OS version
      :ram => 1024,                   ⇒ Allocated memory
      :vcpu => 1,               ⇒  Allocated CPU
      :ip => "192.168.29.2"     ⇒ Allocated IP address of the node
    },
    {
      :name => "web2.demo.com", ⇒ Host2 this is one of the target nodes
      :box => "centos/8",
      :ram => 1024,
      :vcpu => 1,
      :ip => "192.168.29.3"
    },
    {
      :name => "ansible-host", ⇒ Ansible Host with Ansible Engine
      :box => "centos/8",
      :ram => 8048,
      :vcpu => 1,
      :ip => "192.168.29.4"
    }
  ]

  # Provision each of the VMs.
  boxes.each do |opts|
    config.vm.define opts[:name] do |config|
#   Only Enable this if you are connecting to Proxy server
#      config.proxy.http    = "http://usernam:[email protected]:80"⇒ Needed if you have a proxy
#      config.proxy.https   = "http://usernam:[email protected]:80"
#      config.proxy.no_proxy = "localhost,127.0.0.1"
      config.vm.synced_folder ".", "/vagrant", id: "vagrant-root", disabled: true
      config.ssh.insert_key = false
      config.vm.box = opts[:box]
      config.vm.hostname = opts[:name]
      config.vm.provider :virtualbox do |v| ⇒  Defines the vagrant provider
        v.memory = opts[:ram]
        v.cpus = opts[:vcpu]
      end
      config.vm.network :private_network, ip: opts[:ip]
      config.vm.provision :file do |file|
         file.source     = './keys/vagrant' ⇒ vagrant keys to allow access to the nodes
         file.destination    = '/tmp/vagrant' ⇒ the location to copy the vagrant key
      end
      config.vm.provision :shell, path: "bootstrap-node.sh" ⇒ script that copy hosts entry
      config.vm.provision :ansible do |ansible| ⇒ declaration to run ansible playbook
        ansible.verbose = "v"
        ansible.playbook = "playbook.yml" ⇒ the playbook used to configure the hosts
      end
        end
  end
end

这些是你需要注意的重要文件。

  • inventory-test.yaml:连接到节点的清单文件
  • playbook.yaml:Vagrant 供应者调用的用于配置节点的剧本文件
  • `Vagrantfile':Vagrant 用来部署环境的文件
  • Vagrant 密钥文件:连接实验室环境中各节点的 Vagrant 密钥

你可以根据你的需要调整这些文件。Ansible 的灵活性使你有能力根据你的需要声明性地改变你的环境。

部署你的实验室环境

首先,克隆这个 GitHub 仓库 中的代码:

$ git clone https://github.com/mikecali/ansible-labs-101.git
Cloning into 'ansible-labs-101'...
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 15 (delta 2), reused 10 (delta 0), pack-reused 0
Unpacking objects: 100% (15/15), 6.82 KiB | 634.00 KiB/s, done.

接下来,将你的目录改为 vagrant-session-2,并查看其内容:

$ ls
Bootstrap-node.sh   inventory   keys   playbook.yml   README.md Vagrantfile

现在你已经拥有了实验室环境所需的所有工件和配置文件。要部署环境,请运行:

$ vagrant up

只要有一个像样的网络连接,只需要 20 分钟左右就可以得到一个运行环境:

$ vagrant up
Bringing machine 'web1.demo.com' up with 'virtualbox' provider...
Bringing machine 'web2.demo.com' up with 'virtualbox' provider...
Bringing machine 'ansible-host' up with 'virtualbox' provider...
==> web1.demo.com: Importing base box 'centos/8'...
==> web1.demo.com: Matching MAC address for NAT networking...
==> web1.demo.com: Checking if box 'centos/8' version '1905.1' is up to date...
==> web1.demo.com: Setting the name of the VM: ansible-labs_web1democom_1606434176593_70913
==> web1.demo.com: Clearing any previously set network interfaces...
==> web1.demo.com: Preparing network interfaces based on configuration...
    web1.demo.com: Adapter 1: nat
    web1.demo.com: Adapter 2: hostonly
==> web1.demo.com: Forwarding ports...
    web1.demo.com: 22 (guest) => 2222 (host) (adapter 1)
==> web1.demo.com: Running 'pre-boot' VM customizations...
==> web1.demo.com: Booting VM...
==> web1.demo.com: Waiting for machine to boot. This may take a few minutes...
    web1.demo.com: SSH address: 127.0.0.1:2222
    web1.demo.com: SSH username: vagrant
    web1.demo.com: SSH auth method: private key
[...]

一旦该剧本执行完成,你会看到这样的输出:

PLAY RECAP *********************************
Ansible-host     : ok=20 changed=11 unreachable=0 failed=0 skipped=0 rescued=0 ignored=3

Real 18m14.288s
User 2m26.978s
Sys 0m26.849s

确认所有虚拟机都在运行:

$ vagrant status
Current machine states:

Web1.demo.com    running (virtualbox)
Web2.demo.com    running (virtualbox)
ansible-host     running (virtualbox)
[...]

你可以通过登录其中一个虚拟机进一步调查。访问 ansible-host

> vagrant ssh ansible-host
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Thu Nov 26 12:21:23 2020 from 10.0.2.2
[vagrant@ansible-host ~] uptime
16:46:42 up 1:24, 1 user, load average: 0.00, 0.01, 0.04

最后,你可以使用 Ansible 模块来 ping 你创建的其他节点:

[vagrant@ansible-host]$ ansible -i inventory-test.yaml \
webservers -m ping -u vagrant
192.168.29.2 | SUCCESS =&gt; {
  "Ansible-facts": {
      "Discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "Changed": false;
    "Ping": "pong"
}
[...]

清理

运行如下命令来清理环境:

$ vagrant destroy [vagrant machine name]

你的输出会像这样:

 title=

有创意的学习

在自己的实验室里利用自己的时间学习 Ansible 这样的软件是一个好习惯,但由于受到无法控制的限制,可能会很困难。

有时候,你需要发挥创意,找到另一种方法。在开源社区中,你可以选择很多方案;我们选择这些工具的主要原因之一是,它们是许多人常用和熟悉的。

另外,请注意,这些剧本并没有按照我的要求进行优化。请随时改进它们,并在评论中分享你的工作。


via: https://opensource.com/article/20/12/ansible-lab

作者:Mike Calizo 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

将 Kubernetes 与 Ansible 结合实现云端自动化。此外,还可以参照我们的 Ansible 的 k8s 模块速查表。

Ansible 是实现自动化工作的优秀工具,而 Kubernetes 则是容器编排方面的利器,要是把两者结合起来,会有怎样的效果呢?正如你所猜测的,Ansible + Kubernetes 的确可以实现容器编排自动化。

Ansible 模块

实际上,Ansible 本身只是一个用于解释 YAML 文件的框架。它真正强大之处在于它丰富的模块,所谓 模块 module ,就是在 Ansible 剧本 playbook 中让你得以通过简单配置就能调用外部应用程序的一些工具。

Ansible 中有模块可以直接操作 Kubernetes,也有对一些相关组件(例如 DockerPodman)实现操作的模块。学习使用一个新模块的过程和学习新的终端命令、API 一样,可以先从文档中了解这个模块在调用的时候需要接受哪些参数,以及这些参数在外部应用程序中产生的具体作用。

访问 Kubernetes 集群

在使用 Ansible Kubernetes 模块之前,先要有能够访问 Kubernetes 集群的权限。在没有权限的情况下,可以尝试使用一个短期在线试用账号,但我们更推荐的是按照 Kubernetes 官网上的指引,或是参考 Braynt Son 《入门 Kubernetes》的教程安装 Minikube。Minikube 提供了一个单节点 Kubernetes 实例的安装过程,你可以像使用一个完整集群一样对其进行配置和交互。

在安装 Minikube 之前,你需要确保你的环境支持虚拟化并安装 libvirt,然后对 libvirt 用户组授权:

$ sudo dnf install libvirt
$ sudo systemctl start libvirtd
$ sudo usermod --append --groups libvirt `whoami`
$ newgrp libvirt

安装 Python 模块

为了能够在 Ansible 中使用 Kubernetes 相关的模块,你需要安装以下这些 Python 模块:

$ pip3.6 install kubernetes --user
$ pip3.6 install openshift --user

启动 Kubernetes

如果你使用的是 Minikube 而不是完整的 Kubernetes 集群,请使用 minikube 命令在本地创建一个最精简化的 Kubernetes 实例:

$ minikube start --driver=kvm2 --kvm-network default

然后等待 Minikube 完成初始化,这个过程所需的时间会因实际情况而异。

获取集群信息

集群启动以后,通过 cluster-info 选项就可以获取到集群相关信息了:

$ kubectl cluster-info
Kubernetes master is running at https://192.168.39.190:8443
KubeDNS is running at https://192.168.39.190:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

使用 k8s 模块

Ansible 使用 k8s 这个模块来实现对 Kubernetes 的操作,在剧本中使用 k8s 模块就可以对 Kuvernetes 对象进行管理。这个模块描述了 kubectl 命令的最终状态,例如对于以下这个使用 kubectl 创建新的命名空间的操作:

$ kubectl create namespace my-namespace

这是一个很简单的操作,而对这个操作的最终状态用 YAML 文件来描述是这样的:

- hosts: localhost
  tasks:
    - name: create namespace
      k8s:
        name: my-namespace
        api_version: v1
        kind: Namespace
        state: present

如果你使用的是 Minikube,那么主机名(hosts)应该定义为 localhost。需要注意的是,所使用的模块也定义了可用参数的语法(例如 api_versionkind 参数)。

在运行这个剧本之前,先通过 yamllint 命令验证是否有错误:

$ yamllint example.yaml

确保没有错误之后,运行剧本:

$ ansible-playbook ./example.yaml

可以验证新的命名空间是否已经被创建出来:

$ kubectl get namespaces
NAME              STATUS   AGE
default           Active   37h
kube-node-lease   Active   37h
kube-public       Active   37h
kube-system       Active   37h
demo              Active   11h
my-namespace      Active   3s

使用 Podman 拉取容器镜像

容器是个 Linux 系统,几乎是最小化的,可以由 Kubernetes 管理。LXC 项目和 Docker 定义了大部分的容器规范。最近加入容器工具集的是 Podman,它不需要守护进程就可以运行,为此受到了很多用户的欢迎。

通过 Podman 可以从 Docker Hub 或者 Quay.io 等存储库拉取容器镜像。这一操作对应的 Ansible 语法也很简单,只需要将存储库网站提供的镜像路径写在剧本中的相应位置就可以了:

   - name: pull an image
      podman_image:
        name: quay.io/jitesoft/nginx

使用 yamllint 验证:

$ yamllint example.yaml

运行剧本:

$ ansible-playbook ./example.yaml
[WARNING]: provided hosts list is empty, only localhost is available.
Note that the implicit localhost does not match 'all'

PLAY [localhost] ************************

TASK [Gathering Facts] ************************
ok: [localhost]

TASK [create k8s namespace] ************************
ok: [localhost]

TASK [pull an image] ************************
changed: [localhost]

PLAY RECAP ************************
localhost: ok=3 changed=1 unreachable=0 failed=0
           skipped=0 rescued=0 ignored=0

使用 Ansible 实现部署

Ansible 除了可以执行小型维护任务以外,还可以通过剧本实现其它由 kubectl 实现的功能,因为两者的 YAML 文件之间只有少量的差异。在 Kubernetes 中使用的 YAML 文件只需要稍加改动,就可以在 Ansible 剧本中使用。例如下面这个用于使用 kubectl 命令部署 Web 服务器的 YAML 文件:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webserver
spec:
  selector:
    matchLabels:
      run: my-webserver
  replicas: 1
  template:
    metadata:
      labels:
        run: my-webserver
    spec:
      containers:
      - name: my-webserver
        image: nginx
        ports:
        - containerPort: 80

如果你对其中的参数比较熟悉,你只要把 YAML 文件中的大部分内容放到剧本中的 definition 部分,就可以在 Ansible 中使用了:

   - name: deploy a web server
      k8s:
        api_version: v1
        namespace: my-namespace
        definition:
          kind: Deployment
          metadata:
            labels:
              app: nginx
            name: nginx-deploy
          spec:
            replicas: 1
            selector:
              matchLabels:
                app: nginx
            template:
              metadata:
                labels:
                  app: nginx
              spec:
                containers:
                  - name: my-webserver
                    image: quay.io/jitesoft/nginx
                    ports:
                      - containerPort: 80
                        protocol: TCP

执行完成后,使用 kubectl 命令可以看到预期中的的 部署 deployment

$ kubectl -n my-namespace get pods
NAME                      READY  STATUS
nginx-deploy-7fdc9-t9wc2  1/1    Running

在云上使用模块

随着现在越来越多的开发和部署工作往云上转移的趋势,我们必须了解如何在云上实现自动化。其中 k8spodman_image 这两个模块只是云开发中的其中一小部分。你可以在你的工作流程中寻找一些需要自动化的任务,并学习如何使用 Ansible 让你在这些任务上事半功倍。


via: https://opensource.com/article/20/9/ansible-modules-kubernetes

作者:Seth Kenlon 选题:lujun9972 译者:HankChow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

通过将日历应用集成到 Ansible 中,确保你的自动化工作流计划不会与其他东西冲突。

“随时”是执行自动化工作流的好时机吗?出于不同的原因,答案可能是否定的。

如果要避免同时进行更改,以最大限度地减少对关键业务流程的影响,并降低意外服务中断的风险,则在你的自动化运行的同时,其他任何人都不应该试图进行更改。

在某些情况下,可能存在一个正在进行的计划维护窗口。或者,可能有大型事件即将来临、一个关键的业务时间、或者假期(你或许不想在星期五晚上进行更改)。

 title=

无论出于什么原因,你都希望将此信息发送到你的自动化平台,以防止在特定时间段内执行周期性或临时任务。用变更管理的行话,我说的是当变更活动不应该发生时,指定封锁窗口。

Ansible 中的日历集成

如何在 Ansible 中实现这个功能?虽然它本身没有日历功能,但 Ansible 的可扩展性将允许它与任何具有 API 的日历应用集成。

目标是这样的:在执行任何自动化或变更活动之前,你要执行一个 pre-task ,它会检查日历中是否已经安排了某些事情(目前或最近),并确认你没有在一个阻塞的时间段中。

想象一下,你有一个名为 calendar 的虚构模块,它可以连接到一个远程日历,比如 Google 日历,以确定你指定的时间是否已经以其他方式被标记为繁忙。你可以写一个类似这样的剧本:

- name: Check if timeslot is taken
  calendar:
    time: "{{ ansible_date_time.iso8601 }}"
  register: output

Ansible 实际会给出 ansible_date_time,将其传递给 calendar 模块,以验证时间的可用性,以便它可以注册响应 (output),用于后续任务。

如果你的日历是这样的:

 title=

那么这个任务的输出就会指明这个时间段被占用的事实 (busy: true):

ok: [localhost] =&gt; {
   "output": {
       "busy": true,
       "changed": false,
       "failed": false,
       "msg": "The timeslot 2020-09-02T17:53:43Z is busy: true"
   }
}

阻止任务运行

接下来,Ansible Conditionals 将帮助阻止所有之后任务的执行。一个简单的例子,你可以在下一个任务上使用 when 语句来强制它只有当上一个输出中的 busy 字段不是 true 时,它才会运行:

tasks:
  - shell: echo "Run this only when not busy!"
    when: not output.busy

总结

上一篇文章中,我说过 Ansible 是一个将事物连接在一起的框架,将不同的组成部分相互连接,以协调端到端自动化工作流。

这篇文章探讨了 Ansible 剧本如何与日历应用集成以检查可用性。然而,我只做了一些表面工作!例如,你的任务也可以阻止日历中的一个时间段,这里的发挥空间很大。

在我的下一篇文章中,我将深入 calendar 模块是如何构建的,以及其他编程语言如何与 Ansible 一起使用。如果你和我一样是 Go 的粉丝,请继续关注!


这篇文章最初发表在 Medium 上,名为 Ansible and Google Calendar integration for change management,采用 CC BY-SA 4.0 许可,经许可后转载。


via: https://opensource.com/article/20/10/calendar-ansible

作者:Nicolas Leiva 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出