☰

カスタムFreeBSD AMIでユーザーデータスクリプトを実行するには？

tag-icon • tag-icon freebsd amazon-ec2
カスタムFreeBSD AMIでユーザーデータスクリプトを実行するには？

EC2 AMIでは、ユーザーデータを一度だけ実行できることを読みました。 EC2 インスタンスでカスタム AMI を生成する場合、カスタム AMI でユーザーデータスクリプトを実行することはできません。 Ubuntuインスタンスでは、/var/lib/cloud/*を削除し、カスタムAMIを作成し、カスタムAMIからユーザーデータを実行できます。 FreeBSDで/var/lib/cloud/*に対応するエントリが見つかりません。

カスタムFreeBSD AMIでuserdataを実行する方法、またはuserdataスクリプトを再実行できるようにAMIを生成する方法はありますか？

Linuxには#cloud-boothookがありますが、FreeBSDでは私のニーズに合わないconfiginitだけが見つかりました。インスタンスを起動すると、コマンドラインからユーザーデータスクリプトにパラメータを渡します。

答え1

AWS の FreeBSD AMI は、他の AMI と同じレベルの user_data スクリプトサポートを提供しません。指摘したように、#cloud-boothookuser_dataはサポートされておらず、起動後に渡されたuser_dataは無視されます。

簡単な解決策は次のとおりです。

sed -i '' '/KEYWORD: *firstboot$/d' /usr/local/etc/rc.d/ec2_configinit

これはハッキングです。これで、インスタンスはタグなしのスクリプトを含むすべてのuser_dataスクリプトを実行します#cloud-boothookが、私の意見ではスクリプトのデフォルトの動作よりはるかに優れています。人々はいつもec2_configinitにアクセスできます/etc/rc.conf。

答え2

許可された回答は非常に粗いので、私自身の答えを提供しています。

更新：許可された答えはかなり粗いと思いましたが、最終的に使用するようになりました。なぜならそれが私に最もよく似合うからだ。残りの部分は、一部の人に役立つ追加の背景情報を提供することです。 （1）常にシェルスクリプトを実行することができ、（2）以下のようにユーザーデータファイルを処理する以外は何もしません。必要に応じてrc.confでこれを無効にできます。

問題は、Amazon LinuxでもMIMEマルチパート/ミキシングトリックを使用しない限り、ユーザーデータスクリプトが最初の起動時にのみ実行されることです。確認できますhttps://cloudinit.readthedocs.io/en/latest/topics/format.htmlしかし、私は限界を超える例を挙げました。

Content-Type: multipart/mixed; boundary="schnipp-schnapp"
MIME-Version: 1.0

--schnipp-schnapp
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="user-data.sh"

#!/bin/bash
echo "Hello World." >> /etc/motd

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="another.sh"

#!/bin/bash
echo "Kilroy was here." >> /etc/motd

--schnipp-schnapp
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="imput64-8503-small.jpg"

/9j/4AAQSkZJRgABAQEAlgCWAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo
...
JFSUkfQjjHr9yT2T9SSSdLS15R/qM64pbLRUcsExOk6axzpxhiQATFSDIB6E68K/c6WlrzEoTypl
JoceL9zq7NbXis8oopa6RRNUQovmNlCM5IIzxQLkgkD0wQCAFLYaXzKkSSVEkzOZXqJJOUjsfXkf
cknJOMk++lpa9u+AGkJwsuJACiqCeJGm5pJiZJXBr4Sx04IfzZiS3I9r3/TQakADkD260tLWjxQk
hE9/tVFgPm8K/9k=

--schnipp-schnapp--

どちらのスクリプトもアルファベット順に実行され、画像部分が無視されることがわかりました。

FreeBSD AMI管理者がこのマルチパートコンテンツとそれに関連するすべてを実装しない限り

  • テキスト/クラウドガイド
  • テキスト/クラウドの設定
  • テキスト/クラウド構成アーカイブ
  • テキスト/jinja2
  • テキスト/セクションハンドラ
  • テキスト/ニューリッチワーク
  • テキスト/x-include-once-url
  • テキスト/x-include-url
  • テキスト/x-シェルスクリプト

ec2-cloudinitが実行する他のすべての作業が常にこのように行われると期待するのはなぜですか？結局あなたは一人です。

ユーザーデータを取得し、それをどのように処理するかを直接決定するには何の害もありません。取得する方法は次のとおりです。

fetch -q -o - http://169.254.169.254/latest/user-data

したがって、実行したい場合は、rc.localに入れてください。

fetch -q -o - http://169.254.169.254/latest/user-data |sh

または

fetch -q -o /tmp/user-data.sh http://169.254.169.254/latest/user-data
mkdir 700 /tmp/user-data.sh
/tmp/user-data.sh

本当に別ではありません。複雑なマルチパート構造をサポートする価値があるかどうかはわかりません。 FreeBSD AMIはこれを非常に異なる方法で行い、より簡単で、間違いなく悪くはありません。

  • hash-bang#!で始まると保存され実行されます。
  • "">/var/tmp/here" で始まると、指定された宛先に書き込まれます。
  • ">>/var/tmp/here"で始まると、指定された宛先に追加されます。
  • それ以外の場合は、シェルスクリプトの圧縮されていないtarアーカイブとして処理され、展開され、上記の規則を使用して各ファイルが実行されます。

AWS 標準ではないので、そのままにします。スクリプトを持ち、rc.localで強制的に実行したり実行したりすることなく、何らかの方法で動作を制御するパラメータを見つけることができます。

関連情報