はじめに
前回「Amazon S3からのスクリプトの実行をやってみた。」という記事でSystems ManagerのRun Command機能を使用して、コマンド実行を試してみましたが、その際に、実行対象のインスタンスに残り続けるスクリプトが気になったので、調べた結果をまとめておきます。
SSM Agentの実行スクリプト格納先
前回説明したRun Commandだけではなく、Systems Manager関連でリモートマシン操作が伴う場合、実行対象インスタンスの以下ディレクトリ配下に実行ステータスや実行スクリプトが格納されるようです。
/var/lib/amazon/ssm
├── daemons
├── i-0cbfefff950933df4
│ ├── channels
│ ├── document
│ │ ├── orchestration
│ │ │ └── 0f4f1fe2-fef8-41ca-a726-c1507dfe2262 ★コマンド実行したときに毎回作られるディレクトリ
│ │ │ ├── awsdownloadContent
│ │ │ │ └── downloadContent
│ │ │ │ ├── stderr
│ │ │ │ ├── stderrConsole
│ │ │ │ ├── stdout
│ │ │ │ └── stdoutConsole
│ │ │ ├── awsrunShellScript
│ │ │ │ └── runShellScript
│ │ │ │ ├── stderr
│ │ │ │ ├── stderrConsole
│ │ │ │ ├── stdout
│ │ │ │ └── stdoutConsole
│ │ │ ├── downloads
│ │ │ │ ├── 546b91d3f020855852cdf17aa5074800e7b3be82.etag
│ │ │ │ └── test.sh
│ │ │ └── runShellScript
│ │ │ └── _script.sh
│ │ └── state
│ │ ├── completed
│ │ ├── corrupt
│ │ ├── current
│ │ └── pending
│ ├── idempotency
│ │ └── SendCommand
│ │ ├── 584efcee-cbe1-4221-8bc1-d3708900a4ac
│ │ ├── 8d23ed95-1492-4979-9f70-5eb0f9aa8bda
│ │ └── f3d54e23-c835-44e1-8bd3-fd62d255f695
│ ├── inventory
│ │ ├── custom
│ │ ├── file
│ │ └── role
│ ├── longrunningplugins
│ │ ├── datastore
│ │ └── healthcheck
│ ├── replies
│ └── replies_mgs
├── ipc
│ ├── health
│ └── termination
├── localcommands
│ └── completed
└── runtimeconfig
└── identity_config.json
上記のツリーで★で示したディレクトリはコマンド実行するごとに毎回別のUUIDのディレクトリが生成され、ダウンロードしたファイルや実行したときのスクリプトが格納されます。
これは、例えばRun Commandの「コマンド履歴」から過去に実行したコマンドを再実行した場合でも、新たにUUIDを生成＆実行スクリプト等ダウンロードが行われるため、実行回数が多ければ多いほど、数が増えていく仕様となります。
また、orchestration配下のファイル・ディレクトリはデフォルトだとそのまま残り続けるようなので、ファイルサイズが大きかったり、ファイル数が多かったりするとそれだけディスクを圧迫したり、i-node枯渇の問題が発生する可能性があります。
※調べてみると、実際にディスクフルになったりi-node枯渇が発生した人もいるようです。
SSM Agentの実行スクリプトを削除する設定
orchestration配下のディレクトリは消してしまっても問題ないようなので、過去のワークアラウンドとしてはcronに以下のような処理を追加して、一定期間経ったら削除する処理を加えている人もいたようです。
0 0 * * * find /var/lib/amazon/ssm/i-*/document/orchestration -mindepth 2 -maxdepth 2 -type d -mtime +3 -print0 | xargs -0 rm -rf
ただ、以下SSM AgentのGitHubページのREADMEを見ると、amazon-ssm-agent.jsonファイルを編集することでスクリプト実行後に削除させることもできるようなので、やってみようと思います。
SSM Agentの設定ファイル格納先
SSM Agentの設定ファイル格納先は「/etc/amazon/ssm」となり、以下のようなファイル構成となります。
SSM Agentの設定はamazon-ssm-agent.json.templateのファイル名を変更して、ファイル編集、再起動することで有効になります。
| ファイル名 | 内容 |
|---|---|
| amazon-ssm-agent.json.template | SSM Agentの設定テンプレート |
| NOTICE.md | ライセンス情報など |
| README.md | GitHubのREADMEと同等のREADMEファイル |
| RELEASENOTES.md | リリースノート |
| seelog.xml.template | ログ設定テンプレート |
また、SSM Agent関連のログは「/var/log/amazon/ssm」配下に出力されますが、ログのローテーション設定等はseelog.xmlを編集することで変更することも可能です。
今回は説明しませんが、ログローテーションの設定を変更したい場合は、seelog.xml.templateをseelog.xmlにリネームして設定してみてください。
amazon-ssm-agent.jsonの編集
テンプレートファイルをコピーしてamazon-ssm-agent.jsonファイルを作成します。
sudo su -
cd /etc/amazon/ssm/
cp amazon-ssm-agent.json.template amazon-ssm-agent.json
ファイルをvi等で開き、orchestration関連の設定を変更します。
orchestration関連の設定項目はOrchestrationDirectoryCleanupが該当し、デフォルトでは削除されない設定となっております。
OrchestrationDirectoryCleanupは以下の設定値を設定することが可能です。
| 設定値 | 説明 |
|---|---|
| (設定無し) | 実行後にオーケストレーションフォルダーを削除しない（デフォルト） |
| clean-success | ドキュメントの実行が成功した場合にのみ、オーケストレーションフォルダーを削除する。 |
| clean-success-failed | 成功および失敗したドキュメント実行のオーケストレーションフォルダーを削除する。 |
実行に失敗した場合に原因調査のため、ディレクトリを残しておきたい場合はclean-success、成功・失敗に関わらず、実行後にディレクトリを消してしまいたい場合はclean-succecc-failedを設定します。
ちなみに執筆時点のSSM Agentバージョンとなる「3.1.1575.0」のamazon-ssm-agent.json.templateデフォルト設定は以下となります。
amazon-ssm-agent.json.templateのデフォルト設定（展開してください）
{
"Profile":{
"ShareCreds" : true,
"ShareProfile" : "",
"ForceUpdateCreds" : false,
"KeyAutoRotateDays": 0
},
"Mds": {
"CommandWorkersLimit" : 5,
"StopTimeoutMillis" : 20000,
"Endpoint": "",
"CommandRetryLimit": 15
},
"Ssm": {
"Endpoint": "",
"HealthFrequencyMinutes": 5,
"CustomInventoryDefaultLocation" : "",
"AssociationLogsRetentionDurationHours" : 24,
"RunCommandLogsRetentionDurationHours" : 336,
"SessionLogsRetentionDurationHours" : 336,
"PluginLocalOutputCleanup": "",
"OrchestrationDirectoryCleanup": ""
},
"Mgs": {
"Region": "",
"Endpoint": "",
"StopTimeoutMillis" : 20000,
"SessionWorkersLimit" : 1000,
"DeniedPortForwardingRemoteIPs" : [
"169.254.169.254",
"fd00:ec2::254",
"169.254.169.253",
"fd00:ec2::253",
"169.254.169.123",
"169.254.169.250"
]
},
"Agent": {
"Region": "",
"OrchestrationRootDir": "",
"SelfUpdate": false,
"TelemetryMetricsToCloudWatch": false,
"TelemetryMetricsToSSM": true,
"AuditExpirationDay" : 7,
"LongRunningWorkerMonitorIntervalSeconds": 60
},
"Os": {
"Lang": "en-US",
"Name": "",
"Version": "1"
},
"S3": {
"Endpoint": "",
"Region": "",
"LogBucket":"",
"LogKey":""
},
"Kms": {
"Endpoint": ""
}
}
今回はclean-success-failedを設定して動作確認してみます。
sed -i -e "/OrchestrationDirectoryCleanup/s/:.*$/: \"clean-success-failed\"/g" /etc/amazon/ssm/amazon-ssm-agent.json
設定したらサービスを再起動して有効化します。
systemctl restart amazon-ssm-agent
動作確認
設定を変更したので、動作確認を行います。
clean-success-failedの設定を行った場合の動作としては、スクリプト実行中はorchestration配下にファイル・ディレクトリが作成され、実行完了したら削除される動作となります。
動作確認を行うため、前回使ったスクリプトを以下のように修正してRun Commandを実行、その際に対象のEC2インスタンスのorchestrationディレクトリ配下の状況を確認してみます。
#!/bin/bash
echo "Hello World"
uname -n
sleep 5
pwd
while true; do ls -ltr /var/lib/amazon/ssm/[インスタンスID]/document/orchestration; sleep 1; done
以下Run Command実行時のorchestrationディレクトリ状態。
total 0
drwx------ 6 root root 96 Aug 28 02:50 584efcee-cbe1-4221-8bc1-d3708900a4ac
drwx------ 6 root root 96 Aug 28 02:50 8d23ed95-1492-4979-9f70-5eb0f9aa8bda
total 0
drwx------ 6 root root 96 Aug 28 02:50 584efcee-cbe1-4221-8bc1-d3708900a4ac
drwx------ 6 root root 96 Aug 28 02:50 8d23ed95-1492-4979-9f70-5eb0f9aa8bda
drwx------ 6 root root 96 Aug 28 05:59 dfa66ed2-1bce-4ab0-8aab-8f6c88324fc2 ★ディレクトリが作成された
total 0
drwx------ 6 root root 96 Aug 28 02:50 584efcee-cbe1-4221-8bc1-d3708900a4ac
drwx------ 6 root root 96 Aug 28 02:50 8d23ed95-1492-4979-9f70-5eb0f9aa8bda
★ディレクトリが削除された
想定通り、実行中だけファイル・ディレクトリが作成されて、実行完了後、ディレクトリが削除されることが確認できました。
尚、orchestrationディレクトリ配下を削除する設定に変更した場合でも、設定以前に作られたディレクトリは残り続けるため、過去のディレクトリは手動削除するようにしてください。
おわりに
SSM Agentのログについてはデフォルトでローテーションされるような設定となっておりますが、実行スクリプトはデフォルトではそのまま残ってしまうため、通常運用でSSM AgentのRun Command等を多く使う場合は上記の設定を入れておいたほうが良いと感じました。