[Ansible] 在GitLab上管理Cloudflare Zero Trust下的AAP配置①〜创建Playbook〜
这篇文章有以下两个部分组成。
[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的访问。
总体的构成如下所示。
在本文中,我們只討論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所需的令牌。
然后,创建一个认证信息类型,使得可以在作业模板中使用之前创建的令牌,并通过环境变量实现令牌认证。
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 }}'
最后,与适当的库存配合,创建作业模板。
Webhook监听设置
最终可通过AAP的Webhook执行作业模板。
只需勾选Webhook选项的启用复选框即可配置Webhook,然后可以进行监听。
由于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。
通过这个工具,可以创建包含调查和复杂工作流的工作流模板。
然后我试图执行第二次,但是出现了以下警告,无法执行。
{"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計算しているソースコード部分