AWSユーザーデータの実行後にサービスを開始します
Ubuntu 16.04 AMIに基づいてAMIを構築しています。
AMIからインスタンスを起動するとき、AMIでサービスが起動する前に実行されるユーザーデータスクリプトを渡したいのですが。
ユーザーデータはcloud-final.serviceで実行されているようです。 systemctl status cloud-finalまたはjournalctl -u cloud-finalの場合、ユーザーデータスクリプトの出力が表示されます。
Cloud-final.serviceの後でサービスを開始するように.serviceファイルを設定しようとしました
[Unit]
Description=My Service
After=network.service
After=cloud-final.service
...
ただし、cloud-finalにはRemainAfterExit=yesがあるため、完了しないため、サービスが開始されません。
サービスを開始するようにAWS Ubuntuを構成するにはどうすればよいですかafterユーザーデータスクリプトが実行されましたか？
使用する
[Unit]
…
After=cloud-final.service
…
[Install]
WantedBy=cloud-init.target
私もこれに遭遇しました。 journalctlは、multi-userの後でターゲットcloud-initに到達する前に実行されているユーザーデータを示しました。
<timestamp> <ip_addr> systemd[1]: Reached target Multi-User System.
[snip]
<timestamp> <ip_addr> systemd[1]: Starting Execute cloud user/final scripts...
<timestamp> <ip_addr> user-data[1592]: my user data stuff
[snip]
<timestamp> <ip_addr> systemd[1]: Started Execute cloud user/final scripts.
[snip]
<timestamp> <ip_addr> systemd[1]: Reached target Cloud-init target.
だから私はそれを通常のcloud-initターゲット（これはmayが持っていたものである）の代わりにmulti-userによって必要とされたいと思っていて、それはうまくいきました。
vlfig によって提案されたソリューションが機能します。でも、改善できると思います。
私の例では、cloud-initの終了後にPuppetエージェントを実行しようとしています。
私の場合、Puppetは、Cloud Initのセットアップが完了した後にのみ実行する必要がありました。そのためには、systemdユニットの設定を変更する必要があります。
関心のあるサービスとターゲットのデフォルトの実行順序は次のとおりです。1. cloud-init-local.service 2. cloud-init.service 3. cloud-config.target 4. basic.target 5. cloud-config。サービス6. puppet.service 7. multi-user.target 8. cloud-final.service 9. cloud-init.target
(stag) dki@appbackend-i-0f0d3f6abd8520f12:~$ systemd-analyze --no-pager critical-chain puppet.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
puppet.service @17.737s
└─basic.target @17.291s
└─paths.target @17.290s
└─resolvconf-pull-resolved.path @17.290s
└─sysinit.target @17.282s
└─cloud-init.service @14.709s +2.572s
└─systemd-networkd-wait-online.service @13.872s +832ms
└─systemd-networkd.service @13.487s +377ms
└─network-pre.target @13.482s
└─cloud-init-local.service @6.983s +6.495s
└─var-lib.mount @11.888s
└─local-fs-pre.target @10.584s
└─keyboard-setup.service @6.506s +4.072s
└─systemd-journald.socket @6.430s
└─system.slice @6.416s
└─-.slice @3.772s
ディペンデンシーグラフ：
Systemdサービスの依存関係グラフ
注：緑の矢印はAfter=を意味し、灰色の矢印はWants=を意味します
puppet.serviceに/etc/systemd/system/multi-user.target.wantsを含めることにより、systemdは https://www.freedesktop.org/softwareに従ってAfter=puppet.service型の依存順序を自動的に作成します/systemd/man/systemd.target.html#Default%20Dependencies
ディペンデンシーグラフ：
Puppetサービス依存グラフオリジナル
注：緑の矢印はAfter=を意味し、灰色の矢印はWants=を意味します
結果として、After=cloud-init.targetを実行しようとすると、依存関係サイクルが作成され、まったく開始されません。
[Mon Jul 9 12:49:01 2019] systemd[1]: multi-user.target: Found ordering cycle on puppet.service/start
[Mon Jul 9 12:49:01 2019] systemd[1]: multi-user.target: Found dependency on cloud-init.target/start
[Mon Jul 9 12:49:01 2019] systemd[1]: multi-user.target: Found dependency on cloud-final.service/start
[Mon Jul 9 12:49:01 2019] systemd[1]: multi-user.target: Found dependency on multi-user.target/start
[Mon Jul 9 12:49:01 2019] systemd[1]: multi-user.target: Job puppet.service/start deleted to break ordering cycle starting with multi-user.target/start
このサイクルを断ち切るには、DefaultDependenciesディレクティブを無効にする必要があります。そうすることで、PuppetユニットにAfter=cloud-init.targetを追加して、実行を開始する前にCloud-Initが完了するのを確実に待機することができます。両方のディレクティブは、/etc/systemd/system/puppet.service.d/override.confファイルを作成することによって実行されます。これにより、元のコンテンツを変更することなく、パッケージの元の構成が上書きされます。それの利点は、実際に必要なディレクティブのみへの変更を維持しながらパッケージをアップグレードできることです。
ディペンデンシーグラフ：
その後のPuppetサービスの依存関係グラフ
注：緑の矢印はAfter=を意味し、灰色の矢印はWants=を意味します
結果の実行順序は次のとおりです。1. cloud-init-local.service 2. cloud-init.service 3. cloud-config.target 4. basic.target 5. cloud-config.service 6. multi-user.target 7。 cloud-final.service 8. cloud-init.target 9. puppet.service
(sand) dki@supplier-integrations-i-035c65e75762aaabd:~$ systemd-analyze --no-pager critical-chain puppet.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
puppet.service @43.300s
└─cloud-init.target @43.298s
└─cloud-final.service @33.272s +10.025s
└─multi-user.target @33.246s
└─splunk.service @13.815s +19.429s
└─basic.target @13.463s
└─sockets.target @13.463s
└─docker.socket @13.453s +10ms
└─sysinit.target @13.436s
└─cloud-init.service @10.873s +2.557s
└─systemd-networkd-wait-online.service @9.182s +1.689s
└─systemd-networkd.service @9.034s +143ms
└─network-pre.target @9.032s
└─cloud-init-local.service @854ms +8.177s
└─var-lib.mount @7.587s
└─local-fs-pre.target @1.391s
└─keyboard-setup.service @569ms +822ms
└─systemd-journald.socket @564ms
└─system.slice @564ms
└─-.slice @423ms
おそらくあなたができることは、ユーザーデータスクリプトにそれが完了したことを示すファイルを（スクリプトの最後に）書き込み、最後の近くのどこかで他のサービスを開始させ、最初にファイルを監視させることです。ファイルが作成されている（またはタイムスタンプが更新されている、内容が変更されているなど）ことに気づいたら、残りのサービスを開始し、通常どおり終了します。
このスレッドで見つかったいくつかのヒントのおかげで、私はようやくAL2ベースのAMIで機能するように見えるソリューションを見つけました。
私の使用例：AMIはすでに有効になっていますinstall.serviceこれは、アプリを微調整するためにいくつかのスクリプトを開始します。エンドユーザーはawsツールを使用して、起動時にユーザーデータを介して既存のEBSボリュームを動的にアタッチできます。
これが誰かを助けるかもしれない場合の完全なinstall.serviceファイルです：
[Unit]
Description=Post launch, pre-installation service
After=cloud-init.target
DefaultDependencies=no
AssertFileIsExecutable=/usr/local/bin/install-script
[Service]
Type=simple
ExecStart=/usr/local/bin/install-script
LimitNOFILE=16384
SuccessExitStatus=0
[Install]
WantedBy=default.target