ここ数日で「ユーザーデータスクリプトが機能しない」というトピックをたくさん検索しましたが、今まで自分のケースについてまだ何も考えていませんでした。
AWSによると ユーザーデータ 説明:
Amazon EC2でインスタンスを起動すると、一般的な自動設定タスクを実行したり、インスタンスの起動後にスクリプトを実行したりするために使用できるユーザーデータをインスタンスに渡すオプションがあります。
したがって、インスタンスの起動時に自分のユーザーデータを渡そうとしましたが、これは私のユーザーデータです:
\#!/bin/bash
echo 'test' > /home/ec2-user/user-script-output.txt
しかし、このパスにはファイルがありません:/home/ec2-user/user-script-output.txt
私はチェックした /var/lib/cloud/instance/user-data.txt
、ファイルは存在し、ユーザーデータスクリプトと同じです。
また、ログを確認しました/var/log/cloud-init.log
、エラーメッセージはありません。
ただし、Amazon linux(2014.09.01)で新しいインスタンスを起動すると、ユーザーデータスクリプトは機能しますが、AMI(Amazon linuxベース)とAmazon linuxの違いはわかりません。
私が見た唯一の異なる部分は、このスクリプトを実行した場合です。
Sudo yum list installed | grep cloud-init
私のAMI:
cloud-init.noarch 0.7.2-8.33.amzn1 @ amzn-main
Amazon Linux:
cloud-init.noarch 0.7.2-8.33.amzn1がインストールされている
これが理由かどうかわかりませんか?
さらに情報が必要な場合は、喜んで提供します。自分のAMIで何が起こったのか、それを修正する方法を教えてください。
どうもありがとう
更新
これから答えを見つけました post 、
ユーザーデータファイルの先頭に#cloud-boothookを追加すると、機能します!
#cloud-boothook
#!/bin/bash
echo 'test' > /home/ec2-user/user-script-output.txt
しかし、まだ理由はわかりません。
User_dataは、最初の起動時にのみ実行されます。あなたの画像はカスタム画像であるため、すでに一度起動されているため、user_dataは非アクティブ化されています。
Windowsの場合、 Ec2サービスプロパティ のボックスをチェックすることで実行できます。カスタムイメージの作成の最後に、自動化された方法でそれを行う方法を探しています。
Linuxの場合、メカニズムは同じであり、カスタムイメージでuser_dataを再アクティブ化する必要があると思います。
#cloud-boothook
は、スクリプトをuser_data
メカニズム cloud-boothook 起動ごとに実行されるメカニズム。
編集:
PowerShellを使用してWindowsで開始を再アクティブ化するコードは次のとおりです。
$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\Config.xml"
[xml] $xdoc = get-content $configFile
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2HandleUserData"} |%{ $_.State = "Enabled" }
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2SetComputerName"} |%{ $_.State = "Enabled" }
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile
$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\BundleConfig.xml"
[xml] $xdoc = get-content $configFile
$xdoc.SelectNodes("//Property") |?{ $_.Name -eq "AutoSysprep"} |%{ $_.Value = "Yes" }
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile
(私は質問がLinuxに焦点を当てていることを知っていますが、他の人を助けることができます...)
私がテストしたように、いくつかのbootstrap data in /var/lib/cloud
ディレクトリ。そのディレクトリをクリアした後、ユーザーデータスクリプトは正常に機能しました。
rm -rf /var/lib/cloud/*
Ubuntu 16.04 hvm AMIでも同じ問題に直面しました。 AWSサポートに問題を提起しましたが、それにも影響する正確な理由/バグを見つけることができませんでした。
しかし、まだ私はあなたを助けるかもしれない何かを持っています。
AMIを使用する前に、/ var/lib/cloudディレクトリを削除します(毎回)。次に、イメージの作成中に、再起動なしに設定します。
これらがまだ機能しない場合は、ユーザーデータを手動で強制的に実行することで、さらにテストできます。また、tailf /var/log/cloud-init-output.log
cloud-initステータス。ユーザーデータを実行するには、modules:finalのようなもので終わる必要があります。 modules:configで止まってはいけません。
Sudo rm -rf /var/lib/cloud/* Sudo cloud-init init Sudo cloud-init modules -m final
上記のコマンドがCentOSで動作するかどうかはあまりわかりません。 Ubuntuでテストしました。
私の場合、/ var/lib/cloudディレクトリも削除しようとしましたが、それでもこのシナリオではユーザーデータの実行に失敗しました。しかし、私はそれに対して別の解決策を思いつきました。上記のコマンドを使用してスクリプトを作成し、システムの起動中に実行するスクリプトを作成しました。
それを実現するために/etc/rc.localの以下の行を追加しました。
Sudo bash /home/ubuntu/force-user-data.sh || exit 1
しかし、ここに問題があります。各ブートでスクリプトが実行されるため、#cloud-boothookのように、すべての単一ブートでユーザーデータが実行されます。心配はいりません。最後にforce-user-data.sh自体を削除するだけで調整できます。したがって、force-user-data.shは次のようになります。
#!/bin/bash Sudo rm -rf /var/lib/cloud/* Sudo cloud-init init Sudo cloud-init modules -m final Sudo rm -f /home/ubuntu/force-user-data.sh exit 0
誰かがユーザーデータを実行できない理由を明かしてくれれば幸いです。
私はこれで多くの問題を抱えていました。詳細なウォークスルーを提供します。
私の追加のしわは、起動構成および自動スケーリンググループを介してホストをインスタンス化するためにterraformを使用していることです。
Lc.tfにスクリプトをインラインで追加しても機能しない
user_data = DATA <<
"
#cloud-boothook
#!/bin/bash
echo 'some crap'\'
"
DATA
ユーザーデータから取得できますが、
wget http://169.254.169.254/latest/user-data
しかし、引用符がまだ残っているのに気づきました。
これが私がどのように動作するようになったかです:あなたが見るものがあなたが得るものであるので、私は代わりにテンプレートからそれを引き出すことに移動しました。
user_data = "${data.template_file.bootscript.rendered}"
つまり、テンプレートファイルも次のように宣言する必要があります。
data "template_file" "bootscript" {
template = "${file("bootscript.tpl")}"
}
しかし、クラウド初期化ログ/var/log/cloud-init.logでエラーがまだ発生していました[警告]:未処理の非マルチパート(text/x-not-multipart)ユーザーデータ: 'Content-Type:text/cloud。 .. '
そして、私は見つけました ユーザーデータのフォーマットユーザーに関するこの記事 それは理にかなっています、ユーザーデータが複数の部分に来ることができる場合、おそらくcloud-initにはcloud-initコマンドが必要で、スクリプトは他の場所に必要です。
したがって、私のbootscript.tplは次のようになります。
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
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]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
echo "some crap"
--//
私はCentOSとユーザーデータのロジックを使用しています:
ファイル/etc/rc.localにはinitial.shスクリプトの呼び出しがありますが、最初にフラグを探します:
if [ -f /var/tmp/initial ]; then
/var/tmp/initial.sh &
fi
initial.shはユーザーデータの実行を行うファイルですが、最終的にはフラグを削除します。したがって、新しいAMIでユーザーデータを再度実行する場合は、イメージを作成する前にフラグを再度作成するだけです。
touch /var/tmp/initial
ユーザーデータは、#cloud-boothook
を使用せずに正常に実行する必要があります(ブートプロセス中のできるだけ早い時間にユーザーデータをアクティブ化するために使用されます)。
新しいAmazon Linux AMIを開始し、ユーザーデータに加えて少し追加しました:
#!/bin/bash
echo 'bar' > /tmp/bar
echo 'test' > /home/ec2-user/user-script-output.txt
echo 'foo' > /tmp/foo
これにより、3つのファイルが正常に作成されました。
ユーザーデータスクリプトはroot
として実行されるため、任意の場所にファイルを作成する権限が必要です。
提供されたコードでは、1つの例が/home/ec2-user/user-script/output.txt
(サブディレクトリあり)を参照し、1つの例が/home/ec2-user/user-script-output.txt
(サブディレクトリなし)を参照していることに気付きます。存在しないディレクトリにファイルを作成しようとすると、コマンドは当然失敗しますが、「更新」の例は実際に機能したことを示しているようです。
これは一例としての答えです。見出しに必ず#!/bin/bash
#!/bin/bash
yum update -y
yum install httpd mod_ssl
service httpd start
chkconfig httpd on