AWSのインスタンスのユーザーデータを定義することは、あらゆる種類のブートストラップタイプのアクションを実行するのに非常に便利です。残念ながら、PCIの理由で提供されたAMIの1つから生成されたものではないカスタムCentOS AMIを使用する必要があるため、cloud-initはまだインストールおよび構成されていません。ホスト名を設定し、小さなbashスクリプトを実行するだけです。どうすれば動作しますか?
cloud-initは非常に強力ですが、文書化されていないツールです。一度インストールされても、AMIですでに定義されている可能性のある内容を上書きする多くのモジュールがデフォルトでアクティブになっています。ゼロからの最小セットアップの手順は次のとおりです。
標準リポジトリからcloud-initをインストールします。 PCIが心配な場合は、おそらくAWSのカスタムリポジトリを使用したくないでしょう。
# rpm -Uvh https://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# yum install cloud-init
Yamlファイルである/etc/cloud/cloud.cfg
を編集して、目的の構成を反映します。以下は、各モジュールのドキュメントを含む最小構成です。
#If this is not explicitly false, cloud-init will change things so that root
#login via ssh is disabled. If you don't want it to do anything, set it false.
disable_root: false
#Set this if you want cloud-init to manage hostname. The current
#/etc/hosts file will be replaced with the one in /etc/cloud/templates.
manage_etc_hosts: true
#Since cloud-init runs at multiple stages of boot, this needs to be set so
#it can log in all of them to /var/log/cloud-init.
syslog_fix_perms: null
#This is the bit that makes userdata work. You need this to have userdata
#scripts be run by cloud-init.
datasource_list: [Ec2]
datasource:
Ec2:
metadata_urls: ['http://169.254.169.254']
#modules that run early in boot
cloud_init_modules:
- bootcmd #for running commands in pre-boot. Commands can be defined in cloud-config userdata.
- set-hostname #These 3 make hostname setting work
- update-hostname
- update-etc-hosts
#modules that run after boot
cloud_config_modules:
- runcmd #like bootcmd, but runs after boot. Use this instead of bootcmd unless you have a good reason for doing so.
#modules that run at some point after config is finished
cloud_final_modules:
- scripts-per-once #all of these run scripts at specific events. Like bootcmd, can be defined in cloud-config.
- scripts-per-boot
- scripts-per-instance
- scripts-user
- phone-home #if defined, can make a post request to a specified url when done booting
- final-message #if defined, can write a specified message to the log
- power-state-change #can trigger stuff based on power state changes
system_info:
#works because Amazon's linux AMI is based on CentOS
distro: Amazon
defaults.cfg
に/etc/cloud/cloud.cfg.d/
がある場合は、削除します。
この構成を利用するには、新しいインスタンスに次のユーザーデータを定義します。
#cloud-config
hostname: myhostname
fqdn: myhostname.mydomain.com
runcmd:
- echo "I did this thing post-boot"
- echo "I did this too"
また、#cloud-config
を#!/bin/bash
に置き換えてbashスクリプトを本体に配置するだけでbashスクリプトを実行することもできますが、実行する場合は、cloud_init_modules
からホスト名関連のモジュールをすべて削除する必要があります。
これは最小限の構成であり、cloud-initはユーザー、sshキー、マウントポイントなどを管理できることに注意してください。これらの特定の機能に関する詳細なドキュメントについては、以下のリファレンスを参照してください。
一般的に、cloud-initは指定されたモジュールに基づいて処理を行うようです。 「disable-ec2-metadata」などの一部のモジュールは、指定するだけで処理を行います。 「runcmd」などのその他のものは、パラメーターがcloud.cfgまたはcloud-configユーザーデータのいずれかで指定されている場合にのみ処理を行います。以下のドキュメントのほとんどは、モジュールの名前ではなく、各モジュールで使用可能なパラメーターのみを示していますが、デフォルトのcloud.cfgには最初から完全なモジュールリストが必要です。モジュールを無効にする最善の方法は、リストから単に削除することです。
場合によっては、「rhel」は「distro」タグに対して「Amazon」よりも適切に機能することがあります。私は本当にいつを理解していません。
AWS EC2(CentOS)で cloud-init を使用して起動時にスクリプトを実行する方法に関する簡単なチュートリアルを次に示します。
このチュートリアルでは次のことを説明します。
- 設定ファイルの設定方法
/etc/cloud/cloud.cfg
- クラウドパス
/var/lib/cloud/scripts
は次のようになります- 例を使用して、クラウドパスの下のスクリプトファイル、および
- インスタンスの起動中にスクリプトファイルが実行されたかどうかを確認する方法
構成ファイル
以下の設定ファイルはAWS CentOS6にあります。 Amazon Linuxの場合は、 here を参照してください。
# cat /etc/cloud/cloud.cfg
manage_etc_hosts: localhost
user: root
disable_root: false
ssh_genkeytypes: [ rsa, dsa ]
cloud_init_modules:
- resizefs
- update_etc_hosts
- ssh
cloud_final_modules:
- scripts-per-once
- scripts-per-boot
- scripts-per-instance
- scripts-user
ディレクトリツリー
クラウドパス/var/lib/cloud/scripts
は次のようになります。
# cd /var/lib/cloud/scripts
# tree `pwd`
/var/lib/cloud/scripts
├── per-boot
│ └── per-boot.sh
├── per-instance
│ └── per-instance.sh
└── per-once
└── per-once.sh
スクリプトファイルの内容
サンプルスクリプトファイルの内容は次のとおりです。
ファイルはユーザーroot
の下になければなりません。 ブートスクリプトの作成 の私の方法を参照してください。
# cat /var/lib/cloud/scripts/per-boot/per-boot.sh
#!/bin/sh
echo per-boot: `date` >> /tmp/per-xxx.txt
# cat /var/lib/cloud/scripts/per-instance/per-instance.sh
#!/bin/sh
echo per-instance: `date` >> /tmp/per-xxx.txt
# cat /var/lib/cloud/scripts/per-once/per-once.sh
#!/bin/sh
echo per-once: `date` >> /tmp/per-xxx.txt
実行結果
初回起動の場合
# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST
再起動の場合
# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST
AMIから開始する場合
# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST
per-boot: 1 January 3, 2013 Thursday 17:44:08 JST
参照
cloud-init(CentOS6)でスクリプトが実行されるタイミングが調べられました (translated)
前の回答 を拡張して、cloud-init
対応(および実際にCloudFormationスクリプトを実行できる)CentOS AMIを作成しようとする人は、次の操作を行うことで成功する可能性があります。
Sudo yum install -y cloud-init
であることを確認しますrm -rf /var/lib/cloud/data
rm -rf /var/lib/cloud/instance
rm -rf /var/lib/cloud/instances/*
/etc/cloud/cloud.cfg
を上記の回答の構成に置き換えますが、必ずdistro: rhel
を設定してくださいマーケットプレイスの画像が自然にインスタンスごとに1回だけUserDataを実行すること、そしてもちろん既に実行されていることに気付くまで、UserDataが呼び出されなかった理由を理解しようとしていた。 distro: rhel
ファイル内のcloud.cfg
を変更することで、それらが既に実行されていることを示すインジケーターを削除することは、トリックを行いました。
好奇心が強い人のために、distro:
の値はpython /usr/lib/python2.6/site-packages/cloudinit/distros
内のスクリプトのいずれかに対応する必要があります。起動したAmazon.py
がなかったので、CentOSにrhel
を使用する必要があります。起動するAMIとcloud-initのバージョンYMMVによって異なります。