使用 Ansible Automation Platform、GitLab CE 和 Webhook 部署 IIS 网站
使用 Ansible Automation Platform、GitLab CE 和 Webhook 部署 IIS 网站
在 Red Hat Ansible Automation Platform 内部，Ansible Tower REST API 是帮助将自动化集成到环境中现有流程或工具的关键机制。在 Ansible Tower 3.6 中，我们实现了与 GitHub 和 GitLab Webhook 的直接集成，包括企业内部版本。这意味着源代码管理中的更改可以触发自动化，以应用基础设施配置更改、部署新服务、重新配置现有应用程序等等。在本博文中，我将介绍一个简单的场景并应用新的集成 Webhook 功能。
环境
我的环境包括 Ansible Tower（Red Hat Ansible Automation Platform 的一个组件）、带有已创建项目的 GitLab CE 和运行 IDE 的代码服务器（已克隆相同的 Git 存储库）。Ansible Tower 上存在一个清单，其中只有一个主机，即在经过认证的云上运行的 Windows 2019 Server 实例。在本例中，我将在此 Windows 服务器上部署 IIS，并对我想从此站点提供的 html 文件进行一些修改。
我部署 IIS 的 Playbook *非常*简单
--- - name: Configure IIS hosts: windows tasks: - name: Install IIS win_feature: name: Web-Server state: present - name: Start IIS service win_service: name: W3Svc state: started - name: Create website index.html win_copy: src: files/web.html dest: C:\Inetpub\wwwroot\index.html
我在这里所做的只是添加 Web-Server 功能，启动 IIS 并将我的站点的 html 文件复制到 IIS 提供的 Web 内容的默认位置。
我的 html 文件也同样简单
<html> <title></title> <body> </body> </html>
目标和设置
我希望发生的是，对于对这个 IIS 站点进行更改的每个合并请求，都应该重新部署该站点并使用此基本 html 文件。
GitLab 访问令牌
由于我的 Webhook 被触发，我想使用 Ansible Tower 作业的状态更新在 GitLab 中创建的合并请求。
为此，我首先必须为我的 GitLab 帐户创建一个个人访问令牌，以便 Ansible Tower 可以访问 GitLab API。这非常简单。我所要做的就是导航到我的用户设置，并从左侧导航面板中选择“访问令牌”。
我为我的访问令牌提供了一个易于识别的名称“Ansible Tower”，将过期日期设置为月末，并将此访问令牌的范围限定为仅 API。点击“创建个人访问令牌”后，令牌本身就会可见，并且此页面底部会显示一个新条目。
接下来，我将使用此令牌在 Ansible Tower 中创建一个类型为“GitLab 个人访问令牌”的新凭据。
保存后，Ansible Tower 现在可以访问我的 GitLab 帐户的 API。
Ansible Tower 作业模板
现在 Ansible Tower 能够更新我的合并请求，我需要将 Webhook 访问配置到配置为运行我的简单 IIS Playbook 的作业模板。从 Ansible Tower 3.6 版本开始，每个作业模板上都有一个名为 **启用 Webhook** 的复选框。
选择 **启用 Webhook** 选项后，将显示一些新字段。我选择 GitLab 作为我的 **Webhook 服务**，提供我使用 GitLab 个人访问令牌创建的凭据，**Webhook URL** 已预先填充到此作业模板的路径，并且保存修改后，将生成一个 **Webhook 密钥**，我将使用它来配置 GitLab 中的项目钩子。此外，请注意我的项目允许我覆盖 SCM 分支。这意味着该项目将从“change-web-text”分支而不是 Master 分支拉取更新。
GitLab 项目钩子集成
下一步将我带回 GitLab，这次导航到我想执行 Webhook 的项目的集成页面。
在集成页面上，我提供 URL（Ansible Tower 中的作业模板中的 **Webhook URL**）和秘密令牌（Ansible Tower 中的作业模板中的 **Webhook 密钥**）。我还将触发器指定为“合并请求事件”，这意味着每当打开合并请求时，都会启动我指定的 URL。
操作：更新我的网站文本
现在我已经使用个人访问令牌作为新的凭据类型授予 Ansible Tower 访问我的项目的权限，配置了我的作业模板以启用 Webhook，并在 GitLab 上配置了一个项目钩子以响应我的项目的合并请求事件，我准备对我的 html 文件进行测试提交。
在这里，我在 html 文档的 <title> 和 <body> 标签中添加文本并保存文件。
在“change-web-text”分支上提交更改后，我将推送我的代码，返回 GitLab 并打开一个合并请求以将更改合并回 master。
打开此合并请求现在将触发我的 Webhook，这将把我的网页更改部署到我的 IIS 站点。因为我已经使用我的个人访问令牌配置了 Ansible Tower，所以 Ansible Tower 将在合并请求上发布指向由于 Webhook 触发而执行的作业的链接。
如果所有配置都正确，我应该会看到一个新的作业正在执行，该作业对应于配置了 Webhook 的作业模板。我还应该看到一个已启动的作业，更新我的项目，这将从我的 GitLab 项目中提取最新的更改。
选择“iis website create”的作业，这是我为 Webhook 执行配置的作业模板，显示该作业是 **由** Webhook **启动的**。**额外变量** 将显示许多特定于项目的配置信息，更重要的是，作业输出应显示作业正在执行其应执行的操作。
完成后，我应该能够调出我的 IIS 服务器的 IP 并查看我令人惊叹的 html 页面的更改。
要点
Ansible Tower 3.6 中引入的 Webhook 是一种非常强大的方法，可以响应源代码控制中的事件启动自动化。虽然此基本网站只是一个非常快速简单的示例，但将此功能应用于基础设施即代码（其中所有服务配置都在 Ansible Playbook 中定义）极大地突出了此强大功能。
