使用AWS Systems Manager构建从中执行Ansible的CI/CD流程。（第一步：从Systems Manager执行Ansible）

9 月 ago

2 minutes

首先

最近我在业余时间观看了《AWS初学者亲手操作》，其中有一集是关于利用AWS Code服务组合来构建CI/CD配置。因此，我也想尝试搭建自己的CI/CD环境。虽然在之前的文章中我提到可能不太推荐，但我想利用Systems Manager的Ansible执行功能，将Ansible执行所需的代码提交到CodeCommit，然后尝试在指定的实例上执行Ansible来构建环境。

【関連2】SSM Agentの実行スクリプトを削除する方法

【関連3】Systems Managerでベストプラクティス構成のPlaybook運用する場合に注意すること

【次】AnsibleをAWS Systems Managerから実行するCI/CDを構築する。（その２：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功能进行执行，因此流程几乎相同。

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。

コマンドドキュメント名説明AWS-ApplyAnsiblePlaybooks複雑なPlaybook実行サポートAWS-RunAnsiblePlaybook廃止

チュートリアル: Ansible プレイブックを実行する関連付けの作成

执行Run Command

我们将使用RunCommand通过管理控制台实际执行Ansible。

在「系统管理」→「节点管理」中选择「运行命令」，然后选择「运行命令」。

在中国境内，只需要一个选项：
选择「命令文档」，如前所述，选择AWS-ApplyAnsiblePlaybooks。

在同一画面下，我们要设置”命令参数”如下所示。

除了源代码设置和检查设置（即所谓的 DryRun 运行设置）外，其他设置均保持默认配置。

パラメータ名パラメータ説明Source TypeS3ソースファイル格納先Source Info{“path”:”https://[バケット名].s3.[リージョン名].amazonaws.com”}ソースダウンロード先S3のURLInstall DependenciesTrue依存パッケージ自動インストール有無Playbook Fileansible_playbook/site.ymlZip解凍時にディレクトリ作成されるため左記パスで指定Extra VariablesSSM=Trueデフォルト設定CheckFalseAnsibleをCheck Modeで動作させるかの設定
今回は反映で設定Verbose-vログ詳細表示設定Timeout Seconds3600実行タイムアウト設定

需要将Source Info以JSON格式设置，并按照表格的方式进行指定。

即使Playbook File的设置将源文件无损上传到S3，由于会根据目录结构进行判断，所以只需根据上传路径指定site.yml，就没有问题。

目标

选择“手动选择实例”，并检查为测试而创建的EC2实例。

其他设置

除了上述的设置外，还有以下参数设置项，但是由于我们只想确认Ansible的操作，所以将执行而不进行通知或输出。

項目名設定内容その他のパラメータデフォルトのままレート制御デフォルトのまま出力オプションS3バケットに書き込まないように設定SNS通知通知しない

确认执行结果

如果一切顺利，执行之后将会如下成功。

此外，选择实例ID后，您可以查看Playbook的执行结果和错误内容，如下所示。

如果失败了，请确认分配给目标节点的 IAM 角色权限、Playbook 路径、错误日志等。

结束

这次作为构建CI/CD配置的前期阶段，我们尝试使用Systems Manager的RunCommand功能来执行Ansible Playbook。

这次我直接将压缩后的源文件上传到S3，但最终要建立在CodeCommit提交的基础上执行，所以下次我们会准备CodeCommit的环境。