[Ansible] 在GitLab上管理Cloudflare Zero Trust下的AAP配置①〜创建Playbook〜

8 月 ago
科, 雅
3 minutes

这篇文章有以下两个部分组成。

[Ansible]Cloudflare Zero Trust配下のAAP設定をGitLabで管理①～Playbook作成～(本記事)
[Ansible]Cloudflare Zero Trust配下のAAP設定をGitLabで管理②～Cloudflare・GitLab設定～

首先

你们都使用Ansible Automation Platform (AAP) 和 AWX的工作模板配置进行代码管理吗？

在 AAP 中使用的 Playbook 代码本身是通过 Git 进行管理的，但 AAP 的设置是通过具备GUI的界面来进行手动处理的，这是我也可以说的。

然而，一旦涉及到验证、生产Playbook的管理，以及多个团队的介入，AAP的设置就会变得混乱不堪，并且手动管理变得困难。

因此，本次我们尝试通过GitLab来管理AAP的设置参数，并将设置内容自动应用到设备中，下面将介绍该设置的具体内容。

由于之前的内容是重复的，所以我们将AAP置于Cloudflare Zero Trust（以下简称Cloudflare）之下，只允许来自GitLab的访问。

总体的构成如下所示。

image.png

在本文中，我們只討論AAP的Playbook部分（圖表中的①），並將使用Cloudflare Zero Trust在GitLab中安全地使用Webhook的部分（圖表中的②、③）作為另一篇文章發表。

环境

    • Ansible Automation Platform: 2.2

 

    ansible.controller collection: 4.4.0

建立

①AAP设定Playbook和工作模板的创建

创建用于设置AAP的Playbook以及运行它的Job Template。

制作游戏规则书

进行AAP设置的集合将使用ansible.controller集合。

请参考awx.awx收藏，因为这个收藏只有AAP订阅用户才能查看。

最初，我們嘗試使用GitLab Runner直接運行Ansible以進行AAP設置，但在嘗試使用Cloudflare時，無法通過技術策略。因此，我們改為讓GitLab Runner向AAP發送Webhook，由AAP端執行工作模板。

我們將設定對象設定為可能在操作中經常更改的以下物件。

    • Inventory

 

    • Inventory Sources

 

    • Projects

 

    • Execution Environments

 

    • Job Templates

 

    Workflow Job Templates

将要设置的数据按如下所示，根据模块说明定义为vars。由于非常麻烦，所以使用ansible.controller.export模块只导入必要的部分，并改变字典的顺序来使用。

---
projects:
  - name: PJ_DEV
    description: Develop Project
    organization: Default
    credential: GitLab SCM
    scm_url: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    scm_branch: develop
    scm_update_on_launch: true
  - name: PJ_PRD
    description: Production Project
    organization: Default
    credential: GitLab SCM
    scm_url: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    scm_branch: main
    scm_update_on_launch: true

Playbook的步骤如下，会读取先前定义的数据，并在循环中创建对象。

---
- name: Configure AAP
  hosts: localhost
  gather_facts: false
  vars_files:
    - vars/projects.yml
    - vars/inventory.yml
    - vars/inventory_sources.yml
    - vars/execution_environments.yml
    - vars/job_templates.yml
    - vars/workflow_job_templates.yml
  tasks:
    - name: Configure projects
      ansible.controller.project:
        state: present
        name: "{{ item.name }}"
        description: "{{ item.description | default(omit) }}"
        organization: "{{ item.organization | default(omit) }}"
        credential: "{{ item.credential | default(omit) }}"
        default_environment: "{{ item.default_environment | default(omit) }}"
        scm_type: "{{ item.scm_type | default(omit} }"
        scm_url: "{{ item.scm_url | default(omit) }}"
        scm_branch: "{{ item.scm_branch | default(omit) }}"
        scm_refspec: "{{ item.scm_refspec | default(omit) }}"
        scm_update_on_launch: "{{ item.scm_update_on_launch | default(omit) }}"
        scm_clean: "{{ item.scm_clean | default(omit) }}"
        scm_delete_on_update: "{{ item.scm_delete_on_update | default(omit) }}"
        scm_track_submodules: "{{ item.scm_track_submodules | default(omit) }}"
        scm_update_cache_timeout: "{{ item.scm_update_cache_timeout | default(omit) }}"
      loop: "{{ projects }}"

    - name: Configure EE
      ansible.controller.execution_environment:
    　・・・

创建职位模板

然后，在AAP端创建作业模板，以便能够执行Playbook。

首先，按照以下步骤创建操作AAP所需的令牌。

image.png

然后，创建一个认证信息类型，使得可以在作业模板中使用之前创建的令牌，并通过环境变量实现令牌认证。

fields:
  - id: CONTROLLER_HOST
    type: string
    label: Controller Host URL
  - id: CONTROLLER_OAUTH_TOKEN
    type: string
    label: Controller API Token
    secret: true
  - id: CONTROLLER_VERIFY_SSL
    type: boolean
    label: Verify SSL
required:
  - CONTROLLER_HOST
  - CONTROLLER_OAUTH_TOKEN
  - CONTROLLER_VERIFY_SSL

env:
  CONTROLLER_HOST: '{{ CONTROLLER_HOST }}'
  CONTROLLER_VERIFY_SSL: '{{ CONTROLLER_VERIFY_SSL }}'
  CONTROLLER_OAUTH_TOKEN: '{{ CONTROLLER_OAUTH_TOKEN }}'

最后，与适当的库存配合，创建作业模板。

image.png

Webhook监听设置

最终可通过AAP的Webhook执行作业模板。

只需勾选Webhook选项的启用复选框即可配置Webhook，然后可以进行监听。

image.png

由于Webhook服务有两种模式，分别是GitHub和GitLab，因此本次选择GitLab。

通过输入身份验证信息，您可以在执行完成后向GitLab发送结果通知。但是，根据本次的方法，我们将不使用GitLab纯粹的 Webhook，因此将保持不变。

因为现在可以使用Webhook，所以我们可以使用curl来执行，其中包括在创建工作模板时提供的Webhook URL和Webhook密钥。

curl <Webhook URL> -X POST \
 -H "Content-Type: application/json" \
 -H "X-Gitlab-Token: <Webhookキー>" \
 -d "{\"test\": \"test\"}"

只要以下出现的结果，Webhook就成功了。

{"message":"Job queued."}

Webhook只需返回一个被接收为队列的信息，任务执行的结果需要在AAP方面查看。
在AAP方面，若任务结果为成功，则表示OK。

通过这个工具，可以创建包含调查和复杂工作流的工作流模板。

image.png

然后我试图执行第二次，但是出现了以下警告，无法执行。

{"message":"Webhook previously received, aborting."}

由于AAP在Webhook方面将请求主体进行了哈希处理并作为GUID进行管理，所以确保不会多次执行。

因此，在使用curl进行POST请求时，需要向请求正文中输入随机的JSON数据。
在GitLab上执行时，我认为附带提交哈希是合适的做法。

最后

尝试使用AAP的自动构建Playbook和作业模板，复制粘贴参数可以轻松地创建验证环境和生产环境，这非常实用。

我第一次使用Job Template的Webhook功能，同时还使用了基于Webhook密钥的简易认证功能，看起来即使对外公开也应该没有问题。
然而，考虑到AAP的角色，当被利用漏洞时存在风险，因此最好不要直接公开。
这个问题将在下一次使用Cloudflare Zero Trust时得以解决。

考虑到Webhook只适用于GitHub和GitLab这两种服务，为了通用性考虑，我觉得最好通过API来进行作业控制。
特别是因为每次需要更改请求的主体，以及无法确认执行作业的结果，这是值得注意的问题。

请查阅以下链接

https://docs.ansible.com/automation-controller/4.0.0/html_ja/userguide/webhooks.html

AAP Webhook説明ページ

https://console.redhat.com/ansible/automation-hub/repo/published/ansible/controller

ansible.controllerコレクションのページ(要Red Hatアカウントログイン)

https://docs.ansible.com/ansible/latest/collections/awx/awx/index.html

awx.awxコレクション説明ページ

https://github.com/ansible/awx/blob/2a1dffd36346e31a5eb9bd9e5770a3ea12827c4f/awx/api/views/webhooks.py#L200

webhookでGUID計算しているソースコード部分