使用AWS Systems Manager构建从中执行Ansible的CI/CD流程。(第一步:从Systems Manager执行Ansible)
首先
最近我在业余时间观看了《AWS初学者亲手操作》,其中有一集是关于利用AWS Code服务组合来构建CI/CD配置。因此,我也想尝试搭建自己的CI/CD环境。虽然在之前的文章中我提到可能不太推荐,但我想利用Systems Manager的Ansible执行功能,将Ansible执行所需的代码提交到CodeCommit,然后尝试在指定的实例上执行Ansible来构建环境。
-
- 【関連1】Amazon S3からのスクリプトの実行をやってみた。
【関連2】SSM Agentの実行スクリプトを削除する方法
【関連3】Systems Managerでベストプラクティス構成のPlaybook運用する場合に注意すること
- 【次】AnsibleをAWS Systems Managerから実行するCI/CDを構築する。(その2:CodeCommitの準備)
最终的构成 de
我计划将此次分成数次,以以下方式构建。
- 拡大図
关于Systems Manager对Ansible的执行
Systems Manager的RunCommand功能之一是能够对目标节点执行ansible-playbook操作的功能。
如果您已经在使用Ansible运维环境,那么通过执行单文件结构的playbook以及所谓的最佳实践结构的playbook,都可以比较顺利地进行迁移。
- Ansibleベストプラクティス
请参考上述【相关1】中的说明,了解使用 Systems Manager 的 RunCommand 功能时的操作和机制。
请参考上述【相关3】,详细说明了使用Systems Manager的RunCommand功能执行Ansible时需要注意的事项。
直接执行Ansible的步骤来自于系统管理器。
要实际从Systems Manager执行Playbook,你需要按照以下步骤进行操作。
以类似于“尝试在Amazon S3上执行脚本”的方式,使用RunCommand功能进行执行,因此流程几乎相同。
-
- SSM Agentインストール
-
- S3バケットへのPlaybook格納
-
- S3&Systems Managerアクセス用ロールの作成
-
- 対象のEC2インスタンスにS3&Systems Managerアクセス用ロールをアタッチ
- Amazon S3からのスクリプトの実行
在下面的解释中,将省略与以前的文章重复的部分。
安装SSM Agent
为了与”尝试运行来自Amazon S3的脚本”的操作相等,这一步骤被省略。
将Playbook存储到S3存储桶中。
因为我打算尝试执行以下文件/目录结构的Playbook,所以我想把它存储到S3中。
ansible_playbook
├── group_vars
│ └── all.yml
├── roles
│ ├── packages
│ │ └── tasks
│ │ └── main.yml
│ └── users
│ └── tasks
│ └── main.yml
├── site.yml
└── test_server.yml
# パッケージインストール
yum_install:
- { name: "gcc" }
# test-groupグループ作成
add_group:
- { name: "test-group", gid: "1100" }
# test-userユーザ作成
add_user:
- { name: "test-user", group: "test-group", uid: "1100" }
---
# tasks file for packages
- name: Package Install
ansible.builtin.yum:
name: "{{ item.name }}"
state: present
with_items: "{{ yum_install }}"
---
# tasks file for users
- name: add group
ansible.builtin.group:
name: "{{ item.name }}"
state: present
gid: "{{ item.gid }}"
with_items: "{{ add_group }}"
- name: add user
ansible.builtin.user:
name: "{{ item.name }}"
group: "{{ item.group }}"
uid: "{{ item.uid }}"
state: present
with_items: "{{ add_user }}"
---
- import_playbook: test_server.yml
- name: test_server playbook
hosts: all
become: yes
roles:
- { role: packages }
- { role: users }
由于尚、S3支持无压缩和Zip格式的存储方式,因此可以将无压缩的最佳实践配置Playbook存储到S3中,但在这次我打算先将其压缩为Zip格式,然后再存储到S3中。
以下是在Mac上创建Zip文件的例子。
zip -r ansible_playbook.zip ansible_playbook
将压缩的源代码存储在合适的存储桶下方。
创建用于S3和System Manager访问的角色。
由于需要完成与「尝试在Amazon S3上执行脚本」相等的步骤,因此省略。
将S3和Systems Manager访问角色附加到指定的EC2实例上。
与之前的情况一样
在亚马逊S3上执行脚本
由于无法立即进入最终构建阶段,因此本次试验将使用以下的Systems Manager的RunCommand功能来单独执行Ansible,直到完整执行为止。
命令文档
有两种方法可以在Systems Manager的RunCommand中执行Ansible,但根据AWS的说法,AWS-RunAnsiblePlaybook已经被废弃,只是为了保持兼容性而保留。
因此,如果您要使用新的选项,选择AWS-ApplyAnsiblePlaybooks就没有问题。
同時に,AWS-ApplyAnsiblePlaybooks可以在命令执行时自动安装运行Ansible所需的软件包和模块,因此无需事先在目标节点上安装Ansible或其依赖软件包来执行RunCommand。
- チュートリアル: Ansible プレイブックを実行する関連付けの作成
执行Run Command
我们将使用RunCommand通过管理控制台实际执行Ansible。
在「系统管理」→「节点管理」中选择「运行命令」,然后选择「运行命令」。
在中国境内,只需要一个选项:
选择「命令文档」,如前所述,选择AWS-ApplyAnsiblePlaybooks。
在同一画面下,我们要设置”命令参数”如下所示。
除了源代码设置和检查设置(即所谓的 DryRun 运行设置)外,其他设置均保持默认配置。
今回は反映で設定Verbose-vログ詳細表示設定Timeout Seconds3600実行タイムアウト設定
需要将Source Info以JSON格式设置,并按照表格的方式进行指定。
即使Playbook File的设置将源文件无损上传到S3,由于会根据目录结构进行判断,所以只需根据上传路径指定site.yml,就没有问题。
目标
选择“手动选择实例”,并检查为测试而创建的EC2实例。
其他设置
除了上述的设置外,还有以下参数设置项,但是由于我们只想确认Ansible的操作,所以将执行而不进行通知或输出。
确认执行结果
如果一切顺利,执行之后将会如下成功。
此外,选择实例ID后,您可以查看Playbook的执行结果和错误内容,如下所示。
如果失败了,请确认分配给目标节点的 IAM 角色权限、Playbook 路径、错误日志等。
结束
这次作为构建CI/CD配置的前期阶段,我们尝试使用Systems Manager的RunCommand功能来执行Ansible Playbook。
这次我直接将压缩后的源文件上传到S3,但最终要建立在CodeCommit提交的基础上执行,所以下次我们会准备CodeCommit的环境。