そのため、Packerを使用してAWSイメージを作成し、user_data_fileを介していくつかのユーザーデータを指定しようとしています。このファイルの内容は、インスタンスが起動するたびに一意になるため、起動時に実行する必要があります。これをAMIに焼き付けることはできません。
パッカーを使用して私は以下を持っています:
{
"variables": {
"AMI_name": ""
},
"builders": [
{
"type": "Amazon-ebs",
"region": "us-east-1",
"source_AMI": "AMI-c8580bdf",
"instance_type": "t2.micro",
"ssh_username": "ubuntu",
"AMI_name": "{{ user `AMI_name` }}-{{ isotime | clean_AMI_name }}",
"user_data_file": "user_data.sh",
"tags": {
"os_version": "ubuntu",
"built_by": "packer",
"build_on": "{{ isotime | clean_AMI_name }}",
"Name": "{{ user `AMI_name` }}"
}
}],
"provisioners": [
{
"type": "ansible",
"playbook_file": "playbook.yml",
"user": "ubuntu"
}]
}
私のuser_dataシェルスクリプトの内容は、プロビジョナーステップで実行されたansibleスクリプトを介してインストールされたパッケージの基本的な構成行のほんの一部です。 Packerの出力を見ると、ansibleスクリプトがすべて実行されていることを確認できます。
PackerはAMIを完了して作成しますが、ユーザーデータは実行されません。結果の画像にはその記録はありません。 /userdata.logファイルがなく、/var/lib/cloud/instance/user-data.txt
が空です。これはPackerで行うのは非常に簡単なことなので、基本的なものが欠けているように感じます。
Rickard von Essenが指摘したように、答えはスクリプトを/var/lib/cloud/scripts/per-instance
にコピーすることでした。これにより、このAMIから起動されたすべてのインスタンスでスクリプトが実行されます。
または、インスタンスが起動するたびにこれを実行する必要がある場合は、スクリプトを/var/lib/cloud/scripts/per-boot
に配置できます。
私の場合、インスタンスをサードパーティのサービスに登録したかったので、インスタンスの作成ごとに1回だけ実行しました。
これを読み直すと、ユーザーデータスクリプトがPackerでどのように機能するかを誤解しているかもしれません。
user_data
は、EC2インスタンスがPackerによって起動されたときに提供されます。このインスタンスは、スナップショットをプロビジョニングしてAMIとして保存した後、最後になります。
作成されたAMIから新しいインスタンスを起動すると、ない同じユーザーデータがあり、この新しいインスタンスの起動時に指定したユーザーデータを取得します。
初期(テンプレートで定義されている)ユーザーデータの影響は、変更がAMIで永続化されているかどうかに応じて、新しいインスタンスに存在する場合と存在しない場合があります。
/var/lib/cloud/scripts/*
へのアップロードは機能しますが、イメージの作成方法によって異なります。インスタンスをすばやく起動できるようにする必要がありますか?
最善の解決策は私たちにとってです パッカープロビジョナー 。プロビジョナーは、起動後にansible/salt/puppet/cheff/Shellスクリプトなどを使用してマシンイメージをインストールおよび構成するために使用されます。必要に応じて、イメージをプロビジョニングできます。そうすれば、インスタンスの起動ごとにdepをプロビジョニングする必要がなくなり、いくつかの問題が発生する可能性があります(断続的なネットワークの問題/障害により、一部のdepがインストールされない可能性があります)。
パッカーのプロビジョナーはサードパーティです。