首先

我打算写一下我曾经感兴趣的Systems Manager上的Ansible Playbook实施，我这次实际上亲自尝试过了，得出了一些需要注意的结论。

AWS Systems Manager で複雑な Ansible のプレイブックを実行可能に

希望您能阅读以下的文章内容，因为这是基于本次文章的前提，如果能读一下就好了。

• 【参考1】Amazon S3からのスクリプトの実行をやってみた。

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

如果在Systems Manager中运行Ansible的情况下的配置。

作为机制，我们将通过”在Amazon S3上执行脚本”中介绍的Run Command功能来执行Ansible。因此，配置将如下所示。

如果使用Run Command功能来运行Ansible，就不需要使用清单文件，而是需要在Systems Manager中指定执行节点。

由于在内部使用localhost运行，所以需要在目标EC2实例上安装Ansible。这样一来，Ansible的优点，即可以在目标节点上无需代理地运行，就会消失。但是，除了一个文件结构的Playbook之外，还可以使用最佳实践的目录结构的Playbook在Systems Manager上运行；可以使用Systems Manager来控制输出日志等；并且可以与CodePipeline等服务轻松集成。我认为这是有用的。

如果目标节点没有安装Ansible，那么将会自动安装Ansible并执行，因此不需要提前手动安装Ansible或包含安装过程。

然而，根据我进行的各种调查结果，如果要在系统管理器中执行和持续运行最佳实践配置的Playbook，需要在使用之前理解以下几点。

如果要在 Systems Manager 上操作最佳实践配置的 Playbook，请注意以下事项。

我个人的感觉是，根据我这次尝试的结果，需要注意以下几点。

• 対象ノード全てにAnsibleインストールが行われる

• RunCommand実行時、ベストプラクティス構成のディレクトリを毎回ダウンロードする

実行対象ホスト指定はSystems Managerで行うため、Ansibleのインベントリファイルによる制御ができない

我之前已经解释过，如果使用Run Command功能来运行Playbook，那么必须在目标节点上执行Playbook，因此无法享受无需代理就能执行的好处。

对于执行Playbook，每次都需要在目标节点上下载执行脚本，并且下载目录的规格也会每次不同，所以无法仅下载差异部分。（可能没有避免措施）

即使在指定执行主机的主机清单中使用了Systems Manager，也需要在系统管理器中指定目标主机。在每个节点上执行Ansible时，它将在localhost上执行，因此如果原先在每个节点上使用host_vars等方式切换变量，则可能会导致迁移困难。

此外，根据SSM Agent的默认设置，用于下载的编排目录不会自动删除，因此每次执行后文件和目录将保持在最佳实践配置中（通过设置可以避免这种情况）。

[1回目のPlaybook実行用ディレクトリ]
 │ └―[ベストプラクティス構成のファイル・ディレクトリ群]
[2回目のPlaybook実行用ディレクトリ]
 │ └―[ベストプラクティス構成のファイル・ディレクトリ群]
・・・
[n回目のPlaybook実行用ディレクトリ]
   └―[ベストプラクティス構成のファイル・ディレクトリ群]

因此，如果使用Ansible时的文件和目录大小较大，每次下载都需要花费时间，并且每次执行都会占用目标节点的容量，因此如果Playbook整体大小较大，不建议使用Run Command来执行Ansible。

请在以下链接中查看有关Run Command执行时的操作和管弦乐目录清理方法的详细信息。

SSM Agentの実行スクリプトを削除する方法

无法通过库存文件来进行控制的方法论

如果在Systems Manager上执行Playbook，由于host_vars无效，我们需要在Playbook内部编写条件语句，改变读取变量的方式，不是执行site.yml，而是根据每个主机执行不同的Playbook，这样的方法是必要的。

最后

最初我是想通过使用系统管理器中的最佳实践配置Playbook功能来尝试并希望将来能在某个系统中提出建议，但是我试了试发现有几个要注意的问题，并且很难说能直接取代现有的Ansible配置。

希望在未来的更新中AWS能够添加管理Ansible的功能，但在那之前，我们建议大家参考这篇文章，考虑在各自的系统中采用更好的配置。