Skip to content

Files

Latest commit

f87fb9e · Dec 29, 2021

History

History
659 lines (394 loc) · 43.2 KB

File metadata and controls

659 lines (394 loc) · 43.2 KB

五、AWX 企业基础设施管理

很明显,Ansible 是一个非常强大和通用的自动化工具,非常适合管理整个服务器和网络设备。平凡、重复的任务可以变得可重复和简单,节省大量时间!显然,这在企业环境中有很大的好处。然而,这种力量是有代价的。如果每个人都在自己的机器上有自己的 Ansible 副本,你怎么知道谁运行了什么剧本,什么时候运行的?您如何确保所有行动手册都得到正确存储和版本控制?此外,您如何防止超级用户级别的访问凭证在您的组织中扩散,同时受益于 Ansible 的强大功能?

这些问题的答案以 AWX 的形式出现,这是一个面向 Ansible 的开源企业管理系统。AWX 是 Red Hat 提供的商用 Ansible Tower 软件的开源上游版本,它提供了几乎相同的功能和优势,但没有 Red Hat 提供的支持或产品发布周期。AWX 是一款功能强大、功能丰富的产品,它不仅包括一个图形用户界面,使非 Ansible 用户可以轻松运行剧本,还包括一个完整的应用编程接口,可集成到更大的工作流和 CI/CD 流水线中。

在本章中,我们将为您提供安装和使用 AWX 的坚实基础,具体包括以下主题:

  • 让 AWX 起床跑步
  • 将 AWX 融入你的第一部剧本
  • 超越基础

技术要求

为了遵循本章中给出的示例,您将需要一台运行 Ansible 4.3 或更高版本的 Linux 机器。几乎任何味道的 Linux 都应该做;对于那些对细节感兴趣的人来说,本章介绍的所有代码都在 Ubuntu 服务器 20.04 LTS 和 Ansible 4.3 上进行了测试,除非另有说明。本章附带的示例代码可从 GitHub 下载,网址为:https://GitHub . com/PacktPublishing/Mastering-Ansible-第四版/tree/main/Chapter05

查看以下视频,查看来自 Packt 的《行动守则》视频:https://bit.ly/3ndx73Q

让 AWX 起床跑步

在我们开始安装 AWX 之前,有必要先简单探讨一下什么是 AWX,什么不是。AWX 是一个可以和 Ansible 一起使用的工具。它不以任何方式复制或复制 Ansible 的特性。事实上,当 Ansible 剧本在 AWX 运行时,可执行文件正在幕后被调用。AWX 应该被认为是一个补充工具,它增加了许多企业所依赖的以下好处:

  • 丰富的基于角色的访问控制 ( RBAC )
  • 集成集中式登录服务(例如,LDAP 或 AD)
  • 安全凭据管理
  • 可审计性
  • 有责任
  • 降低新操作商的准入门槛
  • 改进剧本版本控制的管理
  • 功能齐全的应用编程接口

大多数 AWX 代码运行在一组 Linux 容器中。然而,标准的安装方法在本书的最后一版已经改变了,现在更倾向于在 Kubernetes 上部署 AWX。如果您已经精通 Kubernetes,您可能希望在您自己的环境中尝试并部署它,因为 AWX 应该运行在红帽的 OpenShift、开源的 OKD 以及 Kubernetes 的许多其他现有版本中的任何一个上。

但是,如果您不精通 Kubernetes,或者您正在寻找一些关于如何开始的提示,那么在本章的这一部分,我们将从头开始引导您完成 AWX 的完整安装。我们将基于优秀的microk8s发行版,您只需一个命令就可以在 Ubuntu 服务器上的单个节点上启动并运行它!

在我们开始之前,最后一个注意事项。虽然 Kubernetes 现在是首选的安装平台,但在撰写本文时,Docker 主机仍然有一种安装方法可用。然而,AWX 项目的维护者注意到,这只是针对开发和测试环境,并没有正式发布的版本。因此,我们不会在本章中讨论这个问题。但是,如果您想了解更多信息,可以通过以下链接阅读安装说明:https://github . com/ansi ble/awx/blob/dev/tools/docker-compose/readme . MD

至此,让我们开始基于microk8s的部署。这里概述的安装过程假设您从一个未修改的 Ubuntu 服务器 20.04 安装开始。

首先,让我们安装microk8s本身,使用 Ubuntu 提供的snap:

sudo snap install microk8s --classic

唯一需要的另一步是将您的用户帐户添加到microk8s组,这样您就可以在不需要sudo权限的情况下运行本节中剩余的命令:

sudo gpasswd -a $USER microk8s

您需要注销并重新登录,才能将组成员资格的更改应用到您的帐户。一旦你做了这些,让我们开始准备microk8s我们的 AWX 部署。我们的部署需要storagednsingress插件,因此让我们使用以下命令启用它们:

for i in storage dns ingress; do microk8s enable $i; done

现在我们准备安装 AWX 操作器,它反过来用于管理安装的其余部分。安装它就像运行以下命令一样简单:

microk8s kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/devel/deploy/awx-operator.yaml

当安装在后台继续时,该命令将立即返回。您可以使用以下命令检查安装状态:

microk8s kubectl get pods

一旦完成,AWX 操作员部署的STATUS字段应显示Running

重要说明

之前的命令将克隆 AWX 操作商的最新开发版本。如果您想克隆其中一个版本,请浏览存储库的版本部分,该部分位于以下链接,并查看您想要的版本:https://github.com/ansible/awx-operator/releases

图 5.1 截图显示了 AWX 操作商成功部署后的输出:

Figure 5.1 – The microk8s pod status following the successful deployment of AWX Operator

图 5.1–AWX 操作商成功部署后的 microk8s 吊舱状态

接下来,我们将为我们的 AWX 部署创建一个简单的自签名证书。如果您有自己的证书颁发机构,当然欢迎您使用适合您环境的签名生成自己的证书。如果您正在使用以下命令生成自签名证书,请确保用您分配给 AWX 服务器的主机名替换awx.example.org:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout awx.key -out awx.crt -subj "/CN=awx.example.org/O=mastery" -addext "subjectAltName = DNS:awx.example.org"

我们将在 Kubernetes 中创建一个包含我们新生成的证书的机密(一个包含少量敏感数据的对象):

microk8s kubectl create secret tls awx-secret-ssl --namespace default --key awx.key --cert awx.crt

做完这些,是时候考虑存储了。AWX 的设计是从源代码管理存储库(如 Git)获取剧本,因此,默认安装无法轻松访问本地剧本文件。但是,为了在本书中创建一个每个人都可以遵循的工作示例,我们将创建一个持久卷来存储本地行动手册。创建一个名为my-awx-storage.yml的 YAML 文件,包含以下内容:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: awx-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: microk8s-hostpath
  resources:
    requests:
      storage: 1Gi

运行以下命令,使用我们刚刚创建的 YAML 文件创建此存储:

microk8s kubectl create -f my-awx-storage.yml

现在是时候部署 AWX 本身了。为此,我们必须创建另一个描述部署的 YAML 文件。我们将这个称为my-awx.yml,对于我们的例子,它应该包含以下内容:

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
spec:
  tower_ingress_type: Ingress
  tower_ingress_tls_secret: awx-secret-ssl
  tower_hostname: awx.example.org
  tower_projects_existing_claim: awx-pvc
  tower_projects_persistence: true

使用以下命令使用此文件部署 AWX:

microk8s kubectl apply -f my-awx.yml

部署需要几分钟时间,尤其是第一次运行时,因为容器映像必须在后台下载。您可以使用以下命令检查状态:

microk8s kubectl get pods

部署完成后,所有吊舱应显示STATUSRunning,如图图 5.2 :

Figure 5.2 – Kubernetes pod status after a successful AWX deployment

图 5.2–成功部署 AWX 后的库本内斯吊舱状态

当然,部署 AWX 只有在我们无法进入的情况下才有有限的用处。我们将使用 Microk8s 的入口插件来创建一个入口路由器,这样我们就可以通过标准的 HTTPS 端口在我们选择的主机名(【本例中的 T0】)上访问我们的 AWX 部署。创建另一个 YAML 文件,这次称为my-awx-ingress.yml。它应包含以下内容:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: awx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  tls:
  - hosts:
    - awx.example.org
    secretName: awx-secret-ssl
  rules:
    - host: awx.example.org
      http:
        paths:
          - backend:
              service:
                name: awx-service
                port:
                  number: 80
            path: /
            pathType: Prefix

展开然后用以下命令检查入口定义:

microk8s kubectl apply -f my-awx-ingress.yml
microk8s kubectl describe ingress

如果您没有看到Reason值设置为CREATE的事件,您可能必须删除然后重新部署入口定义,如下所示:

microk8s kubectl delete -f my-awx-ingress.yml
microk8s kubectl apply -f my-awx-ingress.yml

入口规则的成功部署应该如下图所示:

Figure 5.3 – A successful deployment of the ingress configuration for AWX

图 5.3–AWX 入口配置的成功部署

登录 AWX 的默认用户名为admin。但是,密码是随机生成的,并存储在 Kubernetes 内部的一个机密中。要检索此信息以便第一次登录,请运行以下命令:

microk8s kubectl get secret awx-admin-password -o jsonpath='{.data.password}' | base64 --decode

恭喜你!现在,您应该能够通过将 web 浏览器指向您之前选择的主机名来登录到您的 AWX 部署。在这个例子中,它将是https://awx.example.org

在 AWX 的第一次运行中,许多操作(如构建数据库模式)都是在后台执行的。因此,最初可能会出现图形用户界面没有响应的情况。如果您的 pod 状态看起来正常,只需等待,几分钟后您将看到登录屏幕出现,如下图所示:

Figure 5.4 – Accessing the login screen of AWX after deployment

图 5.4–部署后访问 AWX 的登录屏幕

当你第一次登录 AWX 时,你会看到一个仪表盘屏幕和一个位于左侧的菜单栏。正是通过这个菜单栏,我们将探索 AWX 并执行我们的第一个配置工作。同样,值得注意的是,当第一次安装 AWX 时,会填充一些示例内容来帮助您更快地跟上进度。请随意探索演示内容,因为示例与本书中给出的不同。

在我们完成本节之前,请考虑一下我们之前为存储本地行动手册而创建的持久卷。我们怎么能接触到它?当使用我们在这里使用的microk8s的简单单节点部署时,您可以执行一些命令来查询环境并找出文件应该放在哪里。

首先,检索你的hostpath-provisioner吊舱的名称。它看起来应该有点像hostpath-provisioner-5c65fbdb4f-jcq8b,可以使用以下命令进行检索:

microk8s kubectl get pods -A | awk '/hostpath/ {print $2}'

建立了这个唯一的名称后,运行下面的命令来发现为您的 pods 存储文件的本地目录。请确保用系统中的名称替换唯一的hostpath-provisioner名称:

microk8s kubectl describe -n kube-system pod/hostpath-provisioner-5c65fbdb4f-jcq8b | awk '/PV_DIR/ {print $2}'

最后,使用以下命令为您的 AWX 行动手册检索持久卷声明的唯一名称:

microk8s kubectl describe pvc/awx-pvc | awk '/Volume:/ {print $2}'

您的最终路径将是这些结果的合并,包括namespace(本例中为default)和您的聚氯乙烯名称(之前在my-awx-storage.yml文件中定义为awx-pvc)。因此,在我的演示系统上,我的本地行动手册应该放在以下目录下:

/var/snap/microk8s/common/default-storage/default-awx-pvc-pvc-52ea2e69-f3c7-4dd0-abcb-2a1370ca3ac6/

我们将在本章后面的目录中放入一些简单的示例行动手册,因此现在找到它并记下它是值得的,以便您可以在后面的示例中轻松访问它。

随着 AWX 在 Microk8s 上启动并运行,在下一节中,我们将了解如何将我们的第一个行动手册与 AWX 集成并运行。

将 AWX 融入你的第一部剧本

从 AWX 拿到剧本有一个基本的四阶段流程。一旦您理解了这一点,它就为企业环境中更高级的使用和更全面的集成铺平了道路。在这一章的这一部分,我们将掌握这四个阶段,以便达到我们可以运行我们的第一个简单剧本的地步,这将为我们自信地与 AWX 一起前进提供基础。这四个阶段如下:

  1. 定义一个项目。
  2. 定义库存。
  3. 定义凭据。
  4. 定义模板。

前三个阶段可以以任何顺序执行,但是在最后一个阶段中提到的模板将之前创建的三个方面结合在一起。因此,必须最后定义。此外,请注意,这些项目之间不需要一对一的关系。一个项目可以创建多个模板。库存和凭证也是如此。

在我们开始之前,我们需要一个简单的剧本,当我们完成本章的这一部分时,我们可以在我们的示例中使用它。在 AWX 主机上,找到本地 AWX 永久卷文件夹(如果您在 Microk8s 上运行 AWX,这将在上一节中介绍)。我将在下面的命令中展示我的演示系统中的例子,但是您的系统将有自己独特的标识。确保你为你的系统调整了路径——从我的系统复制和粘贴路径几乎肯定不会起作用!

每个本地托管的项目在持久卷中都必须有自己的子目录,所以让我们在这里创建一个:

cd /var/snap/microk8s/common/default-storage/default-awx-pvc-pvc-64aee7f5-a65d-493d-bdc1-2c33f7da8a4e
mkdir /var/lib/awx/projects/mastery

现在将以下示例代码放入该文件夹中,如example.yaml:

---
- name: AWX example playbook
  hosts: all
  gather_facts: false
  tasks:
    - name: Create temporary directory
      ansible.builtin.file:
        path: /tmp/mastery
        state: directory
    - name: Create a file with example text
      ansible.builtin.lineinfile:
        path: /tmp/mastery/mastery.txt
        line: 'Created with Ansible Mastery!'
        create: yes

完成这些之后,我们就可以开始定义项目了。

定义项目

一个项目,用 AWX 的术语来说,就是一个集合在一起的 Ansible 剧本的集合。这些剧本集通常从源代码管理 ( 供应链管理)系统中检索。事实上,这是在企业中托管 Ansible 行动手册的推荐方式。使用配置管理意味着每个人都从同一个版本的代码工作,所有的变化都被跟踪。这些是企业环境中至关重要的元素。

关于行动手册的分组,没有正确或错误的方法来组织项目,所以这在很大程度上取决于所涉及的团队。简而言之,一个项目链接到一个存储库,因此在多个行动手册存在于一个存储库中的情况下,它们存在于 AWX 的一个项目中是有意义的。然而,这不是一个要求——如果每个项目最适合您的需求,您可以只拥有一本行动手册!

如前所述,也可以在本地存储 Ansible 行动手册。这在测试或开始时非常有用,我们将在这里的示例中利用这一功能,因为它确保阅读本书的每个人都能轻松完成示例。

使用admin账户登录 AWX 界面,点击左侧菜单栏的项目链接。然后点击窗口右上角的添加按钮。这为我们创造了一个新的空白项目。

目前,我们不需要去担心所有的字段(我们稍后会详细讨论这些)。但是,我们确实需要配置以下内容:

最终结果应该如下图所示:

Figure 5.5 – Creating your first project in AWX using our local playbook directory

图 5.5–使用我们的本地行动手册目录在 AWX 创建您的第一个项目

点击保存按钮保存您的编辑。就是这样——你已经定义了你在 AWX 的第一个项目!从这里,我们可以定义一个库存。

定义库存

AWX 的库存与我们在 第 1 章**ansi ble的系统架构和设计中使用的库存完全相同,我们使用命令行引用了它们。它们可以是静态的或动态的,可以由组和/或单个主机组成,并且可以在全局、每组或每台主机的基础上定义变量—我们现在只是通过用户界面定义它们。

*点击左侧菜单栏上的库存项。和项目一样,我们想要定义一些新的东西,所以点击窗口右上角的添加按钮。将出现一个下拉列表。从该列表中选择添加库存

出现新建库存画面时,输入库存名称(例如Mastery Demo,然后点击保存按钮。

重要说明

您必须先保存空白清单,然后才能开始定义主机或组。

完成后,您应该有一个看起来像下图所示的的屏幕:

Figure 5.6 – Creating a new empty inventory in AWX

图 5.6–在 AWX 创建新的空库存

保存新库存后,请注意库存子窗格顶部的选项卡–详细信息访问主机来源作业。您会在 AWX 用户界面的几乎每一个窗格中发现类似这样的选项卡——我们在本章前面定义了我们的第一个项目之后也看到了它们(我们只是在那个阶段不需要使用它们)。

为了简单起见,我们将在一个组中定义一台主机来运行我们的示例行动手册。点击选项卡,然后点击添加按钮添加新的库存组。给组命名,点击保存**,如下图所示:**

Figure 5.7 – Creating a new inventory group in AWX

图 5.7–在 AWX 创建新的库存组

现在点击主机选项卡,然后点击添加按钮,从下拉菜单中选择添加新主机。在名称字段中输入您的 AWX 主机的 IP 地址(如果您已经设置了 DNS 解析,则输入 FQDN)。如果愿意,也可以给主机添加描述,然后点击保存。最终结果应该如下图所示:

Figure 5.8 – Creating a new host in the Mastery Group group of the Mastery Demo inventory

图 5.8–在掌握演示清单的掌握组组中创建新主机

重要说明

在大多数库存屏幕上看到的变量框期望变量以 YAML 或 JSON 格式定义,而不是我们在命令行上使用的 INI 格式。先前我们定义了变量,如ansible_ssh_user=james,现在如果选择 YAML 模式,我们将进入ansible_ssh_user: james

干得好!您刚刚在 AWX 创建了第一个库存。如果我们要在命令行上创建这个清单,它将如下所示:

[MasteryGroup]
10.0.50.25

这可能很简单,但它为我们运行第一个剧本铺平了道路。接下来,让我们看看 AWX 的凭证概念。

定义凭证

AWX 向企业贷款的方式之一是安全存储凭证。考虑到 Ansible 的性质和典型用例,它通常以 SSH 密钥或密码的形式获得王国的密钥,这些密钥具有 root 或其他管理级别的权限。即使在保管库中加密,运行剧本的用户也将拥有加密密码,因此可以获得凭据。显然,让许多人不受控制地访问管理员凭据可能是不可取的。幸运的是,AWX 解决了这个问题。

我们举一个简单的例子。假设我的测试主机(我们之前为其定义了清单的主机)的root密码为Mastery123!。我们如何安全地存储它?

首先,导航到凭证菜单项,然后点击添加按钮(如我们之前所做的)来创建新的东西。给凭证取一个合适的名称(例如Mastery Login),然后点击凭证类型下拉菜单,展开可用凭证类型列表(如果在这里看不到需要的,甚至可以自己创建!).

您将看到 AWX 可以存储许多不同的凭据类型。对于像我们这样的机器登录,我们要选择Machine类型。设置凭据类型后,您将看到屏幕发生变化,并且出现了适合创建计算机凭据的字段。我们可以基于 SSH 密钥和各种其他参数来定义登录,但是在我们的简单示例中,我们将简单地将用户名和密码设置为适当的值,如下图所示:

Figure 5.9 – Adding a new machine credential in AWX

图 5.9–在 AWX 添加新的计算机凭据

现在,保存凭证。如果你现在回去编辑凭证,你会注意到密码消失了,被字符串ENCRYPTED代替。现在无法直接通过 AWX 用户界面检索密码(或 SSH 密钥或其他敏感数据)。您会注意到,您可以替换现有的值(通过单击现在灰显的密码字段左侧的卷曲箭头),但看不到它。获取凭据的唯一方法是获得后端数据库的连接和安装时使用的数据库加密密钥。这意味着即使有人对数据库本身执行SELECT操作,也看不到密钥,因为包含敏感数据的数据库行都是用安装时自动生成的密钥加密的。虽然这对组织来说显然具有巨大的安全优势,但也必须指出,后端数据库或与之相关的加密密钥的丢失将导致 AWX 配置的完全丢失。因此,备份您的 AWX 部署和相关机密非常重要(与任何基础架构部署一样),以防您需要从潜在的灾难情况中恢复。

尽管如此,AWX 以与 Ansible Vault 不完全不同的方式保护了您的敏感访问数据。当然,Ansible vault 仍然是一个命令行工具,尽管 Vault 数据可以在 AWX 的剧本中使用,就像 Ansible 在命令行中使用时一样,但是 Vault 的创建和修改仍然是一个命令行活动。准备好我们的证书后,让我们进入运行我们的第一份 AWX 剧本所必需的最后一步——定义一个模板。

定义模板

作业模板-给它取个全名-是一种方式将所有先前创建的配置项以及任何其他所需参数集合在一起,根据清单运行给定的行动手册。把它想象成定义如果你在命令行上,你将如何运行ansible-playbook

让我们通过执行以下步骤来创建我们的模板:

  1. 点击左侧菜单中的模板
  2. 点击添加按钮创建新模板。
  3. 从下拉列表中选择添加作业模板
  4. 作为运行我们第一个作业的最低要求,您需要在创建新作业模板屏幕上定义以下字段:

这应该会产生如下图所示的屏幕:

Figure 5.10 – Creating a new template in AWX

图 5.10–在 AWX 创建新模板

填充所有字段,如前一张截图所示,点击保存按钮。恭喜你!现在,您可以从 AWX 开始运行您的第一个剧本了。为此,导航回模板列表,点击我们新创建的模板右侧的小火箭图标。这样做后,您将立即看到作业正在执行,并将从命令行看到我们熟悉的ansible-playbook输出,如下图所示:

Figure 5.11 – The output from our first playbook template run in AWX

图 5.11–我们在 AWX 运行的第一个行动手册模板的输出

在此屏幕上,您可以看到ansible-playbook的原始输出。点击菜单栏上的作业菜单项,浏览所有已运行的作业,即可随时进入作业画面。这非常适合审核 AWX 一直在策划的各种活动,尤其是在大型多用户环境中。

作业屏幕的顶部,可以看到详情选项卡,这里列出了我们之前定义的所有基础参数,如项目模板。还会显示用于审核目的的有用信息,例如启动作业的用户信息以及作业开始和结束的时间。下图显示了此操作的屏幕截图:

Figure 5.12 – The Details tab from our playbook template run

图 5.12–我们的行动手册模板运行的详细信息选项卡

虽然 AWX 有能力做得更多,但这些基本阶段是你想在 AWX 执行的大部分任务的核心。因此,了解它们的用法和顺序是学习如何使用 AWX 的关键。现在我们已经掌握了基本原理,在下一节中,我们将看看您可以利用 AWX 做的一些更高级的事情。

超越基础

我们现在已经介绍了从 AWX 运行您的第一份行动手册所需的基础知识,这是在此环境中实现大多数 Ansible 自动化所需的基础知识。当然,我们不可能在一章中涵盖 AWX 提供的所有高级功能。因此,在本节中,如果您希望了解更多关于 AWX 的信息,我们将重点介绍一些更高级的方面。

基于角色的访问控制(RBAC)

到目前为止,我们只从内置admin用户的角度来看使用 AWX。当然,AWX 的企业级特色之一是 RBAC。这是通过使用用户团队实现的。一个团队基本上就是一组用户,用户可以是一个或多个团队的成员。

用户和团队都可以在 AWX 用户界面中手动创建,或者通过与外部目录服务(如 LDAP 或活动目录)集成来创建。在目录集成的情况下,团队很可能被映射到目录中的组,尽管丰富的配置允许管理员定义这种行为的确切性质。

AWX 境内的 RBAC 很富有。例如,给定用户可以在一个团队中被授予Admin角色,而在另一个团队中被授予MemberRead角色。

用户帐户本身可以设置为系统管理员、普通用户或系统审计员。

除此之外,当我们逐步完成本章的基本设置部分时,您将会注意到 AWX 用户界面几乎每一页上的选项卡。其中,几乎总是有一个名为权限的标签,允许实现真正的细粒度访问控制。

例如,普通用户类型的给定用户可以在其分配的团队中被赋予Admin角色。然而,他们可以在给定的项目中被分配READ角色,这个更具体的特权取代在团队级别设置的不太具体的Admin角色。因此,当他们登录时,他们可以看到有问题的项目,但不能更改它或执行任何任务——例如,来自配置管理的更新。

重要说明

作为一般的经验法则,更具体的特权取代不太具体的特权。因此,项目级别的优先于团队或用户级别的。请注意,对于没有通过用户或其团队指定权限的项目,该用户在登录到用户界面时甚至看不到该项目。这些规则的唯一例外是系统管理员,他们可以看到一切并执行任何操作。谨慎地将此类型分配给用户帐户!

说到 RBAC,有很多值得探索的地方。一旦掌握了窍门,就很容易在 AWX 创建安全且严密锁定的部署,每个人都有适当的访问权限。

组织

AWX 包含一个名为组织的顶级配置项目。这是库存项目作业模板团队的集合(反过来,这些又是一组用户)。因此,如果企业的两个不同部分有完全不同的需求,但仍然需要使用 AWX,它们可以共享一个 AWX 实例,而不需要通过组织在用户界面中进行重叠配置。

虽然系统管理员类型的用户可以访问所有组织,但普通用户只能看到与其关联的组织和配置。这是隔离对 AWX 企业部署不同部分的访问的一种非常有效的方式。

举例来说,当我们在本章前面创建库存时,您会注意到我们忽略了组织字段(该字段被设置为默认值-新 AWX 安装中存在的唯一组织)。如果我们要创建一个名为Mastery的新组织,那么任何不是该组织成员的人都将无法查看该清单,无论他们拥有什么权限或特权(例外情况是系统管理员用户类型,它可以查看所有内容)。

调度

一些 AWX 配置项目,如项目(可能需要从配置管理更新)或作业模板(执行特定任务),可能需要定期运行。拥有一个像 AWX 这样强大的工具,但是要求操作员定期登录来执行常规任务,将是毫无意义的。因此,AWX 有内置的调度。

在任何项目或模板的定义页面上,只需查找时间表选项卡,您就可以使用丰富的时间表选项–图 5.13 显示了创建每日时间表的示例,从 2021 年 5 月 7 日至 11 日每天下午 1 点在伦敦时区运行。请注意,此计划是根据我们之前创建的Mastery Template作业模板创建的,因此将根据定义的计划自动运行此行动手册模板:

Figure 5.13 – Creating a daily schedule to run the Mastery Template job template created earlier

图 5.13–创建每日计划来运行之前创建的掌握模板作业模板

请注意可供您安排的各种选项。为了帮助您确保时间表符合您的要求,当您保存新时间表时,会显示时间表的详细细分。当您的日程表无人值守运行,并且多个用户登录到一个系统(如 AWX)时,保持对正在发生的事情的监督是至关重要的。值得庆幸的是,AWX 有丰富的功能,允许对发生的事件进行审计,我们将在下一节中研究这些功能。

审计

在命令行上运行 Ansible 的风险之一是,一旦某个特定任务已经运行,它的输出将永远丢失。当然,可以为 Ansible 打开日志记录。然而,在企业中,这需要强制执行,这对于许多拥有给定 Ansible 机器的根访问权限的操作员来说是很困难的,无论是他们自己的笔记本电脑还是其他地方的服务器。值得庆幸的是,正如我们在前面的例子中看到的,AWX 不仅存储了谁运行了什么任务以及何时运行的细节,还存储了ansible-playbook运行的所有输出。通过这种方式,希望使用 Ansible 的企业可以实现合规性和可审计性。

只需导航至作业菜单项,将显示所有先前运行的作业(用户有权查看)的列表。甚至可以通过点击相关作业旁边的火箭图标,直接从该屏幕重复先前完成的作业。请注意,这将立即使用上次启动的相同参数启动作业,因此请确保单击它是您想要做的事情!

图 5.14 显示了本书使用的演示 AWX 实例的作业历史:

Figure 5.14 – The job history pane of the AWX instance being used for the book

图 5.14–用于该书的 AWX 实例的作业历史窗格

点击名称栏中的编号条目,您将进入输出详细信息选项卡窗格,我们在图 5.11图 5.12 中看到,但当然与您点击的特定作业运行相关。虽然您可以清理作业历史记录,但作业仍会保留在那里供您检查,直到您将其删除。还要注意顶部的两个灰色按钮图 5.14 。使用这些,您可以取消正在运行的作业(如果由于任何原因它们被卡住或失败,这很有用),还可以从作业历史记录中删除多个条目。这对于完成审计后的清理非常有用。

当然,有了行动手册,就没有放之四海而皆准的解决方案,有时我们需要操作员能够在运行行动手册时输入唯一的数据。AWX 为此提供了一个名为“调查”的功能,我们将在下一节中讨论这个功能。

调查

有时,当启动一个工作模板时,不可能(或不希望)预先定义所有信息。虽然在 AWX 用户界面中使用变量定义参数是完全可能的,但这并不总是令人满意的,或者实际上是用户友好的,因为变量必须在有效的 JSON 或 YAML 语法中指定。此外,仅被授予模板Read角色的用户将无法编辑该模板定义,这包括变量!然而,他们设置变量可能有一个合理的理由,即使他们不应该编辑模板本身。

调查提供了答案,在您创建的任何工作模板上,您都会在顶部找到一个标记为调查的标签。一项调查本质上是一份问卷(因此得名!)由管理员定义,以用户友好的方式请求输入,并在其中执行简单的用户输入验证。一旦通过验证,输入的值将存储在 Ansible 变量中,就像它们以 YAML 或 JSON 格式定义一样。

例如,如果我们想在作业模板运行时捕获其http_port变量值,我们可以创建一个调查问题,如图 5.15 所示:

Figure 5.15 – Creating a survey question to capture a valid HTTP port number into a variable

图 5.15–创建调查问题,将有效的 HTTP 端口号捕获到变量中

一旦您创建了所有问题,请注意您需要为您的职务模板打开调查,如图 5.16所示,否则问题不会在运行时出现:

*Figure 5.16 – Turning on surveys for a job template

图 e 5.16–打开工作模板的调查

现在,运行剧本时,系统会提示用户输入一个值,AWX 会确保该值是指定范围内的整数。还定义了一个合理的默认值。现在让我们来看看在 AWX 使用职务模板的一种更高级的方式,称为工作流。

工作流模板

剧本的运行,尤其是来自 AWX 的,可能是复杂的。例如,可能需要首先从供应链管理系统和任何动态库存更新项目。然后我们可能会运行一个作业模板来推出一些更新的代码。然而,如果失败了,几乎可以肯定的是回滚已经做出的任何更改(或者采取其他补救措施)。当您点击现在熟悉的添加按钮添加新模板时,您将在下拉菜单中看到两个选项–工作模板(我们已经使用了这个)和工作流模板

新的工作流模板填写完所有必填字段并保存后,您将自动进入工作流可视化工具(要在以后回到这一点,只需以正常方式通过图形用户界面访问您的工作流模板,然后点击可视化工具选项卡)。工作流可视化工具建立了一个从左到右的任务流,供 AWX 执行。例如,下面的截图显示了一个工作流,其中我们的演示项目最初与其配置管理同步。

如果该步骤成功(由指向下一个块的绿色链接表示),则运行演示作业模板。如果这反过来成功,那么掌握模板运行。如果前面的任何步骤失败,那么工作流就此停止(尽管在任何阶段都可以定义一个 On Failure 动作)。基于这个简单的构建模块前提,以及在成功、失败或总是失败的情况下执行后续操作的能力,将使您能够在 AWX 建立大规模的操作流程。这一切都将在无需构建庞大的整体行动手册的情况下实现。图 5.17 显示了可视化工具中的简单工作流程:

Figure 5.17 – The workflow visualizer in AWX

图 5.17–AWX 的工作流可视化工具

使用这个工具,我们可以强大地建立多步骤工作流,在每个阶段之后采取智能行动,这取决于它是否成功。

如果您直接与 AWX 图形用户界面进行交互,我们到目前为止讨论的一切都很棒。但是,如果您已经将无人参与的操作设置为运行,但希望得到关于其结果的通知(尤其是当它们失败时),会发生什么?同样,如果有人运行潜在的影响服务的变更,您如何通知团队?你将在下一部分找到这些问题的答案。

通知

当您检查 AWX 用户界面时,您会注意到大多数屏幕都有一个名为通知的选项卡。AWX 有能力与许多流行的通信平台集成,如 Slack、IRC、page return,甚至是优秀的老式电子邮件(此列表并不详尽)。一旦通过用户界面定义了给定平台的配置,就可以在特定事件发生时发送通知。这些事件将根据您希望生成通知的项目而有所不同。例如,使用作业模板,您可以选择在作业开始、成功和/或失败(以及这些事件的任意组合)时收到通知。您可以为不同的事件生成不同的通知类型。例如,您可以通知 Slack 频道模板正在启动,但如果模板未能自动生成票证以提示进一步调查,您可以向票务系统发送电子邮件。

例如,图 5.18 显示了我们之前配置的Mastery Template设置为在给定收件人列表执行失败时通过电子邮件发送给该列表。在启动和成功时,不会发出任何通知(当然,这可以打开):

Figure 5.18 – Setting up email notifications for failed runs of Mastery Template

图 5.18–为精通模板的失败运行设置电子邮件通知

在 AWX 定义的所有通知出现在通知标签中。但是,它们一旦定义就不必添加。用户只需打开或关闭每个通知服务的开始成功失败通知。

还有一种不使用图形用户界面与 AWX 互动的方式。当然,这是通过应用编程接口实现的,我们将在本章的最后部分讨论。

使用原料药

在本书的这一章中,我们已经查看了使用图形用户界面的所有 AWX 操作,因为这可能是解释它们的功能和用法的最简单和最直观的方式。然而,对于任何企业来说,AWX 的关键特性之一是 API,这是一个完整的特性,使我们能够执行这里完成的所有操作(以及更多操作),而无需接触用户界面。

这是一个非常强大的工具,尤其是在集成到更大的工作流方面。例如,您可以使用 API 将 AWX 连接到您的 CI/CD 流水线中,并且在成功构建代码后,您可以触发 AWX 作业来部署一个测试环境来运行它(甚至将代码部署到该环境中)。同样,您可以通过应用编程接口自动创建作业模板、库存项目和配置的所有其他方面。

API 本身是可浏览的,您可以通过将/api/api/v2添加到您的 AWX 服务器的 URL 来访问它(分别针对 API 的版本 1 和版本 2)。

虽然通常您会将这些集成到一个更大的应用或工作流中,但是使用curl演示应用编程接口的用法是很容易的。例如,假设我们想要检索 AWX 服务器中定义的清单列表。我们可以使用如下命令来实现这一点:

curl -k -s --user admin:adminpassword -X GET https://awx.example.org/api/v2/inventories/ | python -m json.tool

自然,您将需要将您的凭证替换为--user参数,并将 AWX 服务器的正确 FQDN 替换为命令中的 URL。一旦完成,该命令将以 JSON 格式检索 AWX 定义的所有库存的详细信息——您不需要通过 Python 的json.tool工具来传输这些信息——它只是使输出对人类来说更具可读性!

同样,我们可以通过应用编程接口启动我们的精通示例模板。AWX 的所有配置元素都有一个唯一的数字标识,我们必须使用它来访问它们。因此,例如,让我们使用应用编程接口从 AWX 检索职务模板列表:

curl -k -s --user admin:adminpassword -X GET https://awx.example.org/api/v2/job_templates/ | python -m json.tool

通过 JSON 输出,我可以看到我们的Mastery Template在我的系统上有一个12id。此外,因为我为本章前面的一个示例设置了关于该模板的调查,所以 JSON 输出告诉我,在启动该模板之前,我需要指定一些变量。在GET查询的输出中有许多项目可能需要在行动手册推出之前设置,因此在将您的API POST放在一起之前,值得仔细查看它们。图 5.19 显示了API GET调用的输出,显示了模板启动前必须设置的变量:

Figure 5.19 – Partial output from the API GET call on job template 12

图 5.19–作业模板 12 上 API GET 调用的部分输出

这个变量数据可以使用 API 中的extra_vars数据字段来指定,所以我们可以像下面这样创建一个 API 调用来启动作业:

curl -k -s --user admin:adminpassword -X POST -H 'Content-Type:application/json' https://awx.example.org/api/v2/job_templates/12/launch/ --data '{"extra_vars": "{\"http_port\": 80}"}' | python -m json.tool

该命令的输出将包括作业标识等使用细节,以便我们可以根据需要查询作业运行。在我的示例中,返回的作业 ID 是10,因此我可以用以下内容查询该作业的状态(包括是否成功):

curl -k -s --user admin:adminpassword -X GET https://awx.example.org/api/v2/jobs/10/ | python -m json.tool

您甚至可以从作业运行中检索ansible-playbook命令的输出,使用如下的应用编程接口调用:

curl -k -s --user admin:adminpassword -X GET https://awx.example.org/api/v2/jobs/10/stdout/

虽然您不太可能在生产环境中使用curl来驱动应用编程接口,但希望这些简单、可重复的示例将有助于您开始使用应用编程接口进行 AWX 集成的旅程。

AWX 甚至有一个命令行界面,可以通过 Python 的pip打包系统安装。该命令行界面使用的命名和命令结构与我们在本节中讨论的基于 HTTP 的应用编程接口一致,鉴于相似性,因此这是一个可选的练习。但是,为了帮助您入门,您可以在这里找到 AWX 命令行界面的官方文档:

https://docs . ansi ble . com/ansi ble-tower/latest/html/tower rcli/index . html

尽管文档中提到了 Ansible Tower,但它在与开源的 AWX 软件一起使用时同样有效。

总结

我们短暂的 AWX 之旅到此结束。在本章中,我们展示了一旦您了解了所涉及的核心四步过程,AWX 就可以直接安装和配置。我们还展示了如何利用调查、通知和工作流等功能来构建这个过程。

您了解到 AWX 安装起来很简单(事实上,它是用 Ansible 安装的!),以及如何为其添加 SSL 加密。然后,您了解了该平台如何工作,以及如何从全新安装到构建项目、清单、凭据和模板来运行 Ansible 作业。您了解到在此基础上还有许多附加功能。为了帮助您为 Ansible 构建一个健壮的企业管理系统,这些在本章的最后部分进行了介绍。

在下一章中,我们将回到 Ansible 语言,看看 Jinja2 模板系统的好处。

问题

  1. AWX runs either in standalone Docker containers or Kubernetes.

    真的

    假的

  2. AWX provides which of the following to enterprises looking to manage their automation processes?

    一个网络用户界面

    功能齐全的应用编程接口

    3)源代码管理集成

    所有上述内容

  3. AWX directly supports the secure management of credentials for automation.

    真的

    假的

  4. AWX provides a graphical development environment for creating and testing Ansible playbooks.

    真的

    假的

  5. AWX can schedule unattended jobs to run.

    真的

    假的

  6. In AWX, the pre-configured parameter set for an ansible-playbook run is known as what?

    工作配置

    b)Ansible 模板

    3)工作模板

    d)安全运行

  7. AWX can have its configuration divided between different parts of a business through the creation of which of the following?

    团队

    组织

    部署第二台 AWX 服务器

    团体

  8. In AWX, it is possible to tell which of the following?

    当一个剧本被运行时

    谁负责剧本

    c)向行动手册传递了哪些参数

    所有上述内容

  9. User-friendly variable definition in AWX is provided via which feature?

    表格

    电子表格

    (c)其馀者

    调查

  10. Projects in AWX are made up of what?

用户的逻辑团队

行动手册的逻辑文件夹

任务管理系统

角色的逻辑集合**