シェルプロビジョナーを備えたPackerを使用したAMIの構築
コンポーネントのセットがインストールされたプロジェクトで再利用できるAMI（ubuntuに基づく; AMI-2d39803a）を作成しようとしています。私はパッカーを使用して、プロビジョナーによって実行されるシェルスクリプトでこれを実現しています。
#/bin/bash
# salt
Sudo add-apt-repository --yes ppa:saltstack/salt
Sudo apt-get update
Sudo apt-get install --yes salt-api salt-cloud salt-master salt-minion salt-ssh salt-syndic
# run on startup
Sudo update-rc.d salt-master defaults
# salt hostname for minions
Sudo bash -v -c "echo 127.0.0.1 salt >> /etc/hosts"
# get docker-formula and move it to /srv/salt
Sudo mkdir /tmp/docker-formula
Sudo git clone https://github.com/saltstack-formulas/docker-formula /tmp/docker-formula/.
Sudo mkdir -p /srv/salt
Sudo cp -vr /tmp/docker-formula/docker /srv/salt/docker/
# top.sls
Sudo cp -v /ops/config/top.sls /srv/salt/
# accept all minions (minions try to connect to master every 30 seconds)
Sudo sleep 30
Sudo salt-key -A --yes
# apply to minions
Sudo salt '*' -v -t 60 state.apply
# add user to docker group
Sudo usermod -aG docker $USER
これが奇妙な部分です。これを実行すると、新しいインスタンスを作成してシェルスクリプトコマンドを1つずつ実行するときに問題なく機能します。ただし、packer buildを実行すると、次のようになります。
......
aws-us-east-1-ubuntu-base: The following keys are going to be accepted:
aws-us-east-1-ubuntu-base: Unaccepted Keys:
aws-us-east-1-ubuntu-base: ip-172-30-2-245.ec2.internal
aws-us-east-1-ubuntu-base: Key for minion ip-172-30-2-245.ec2.internal accepted.
aws-us-east-1-ubuntu-base: Executing job with jid 20160913191722659701
aws-us-east-1-ubuntu-base: -------------------------------------------
aws-us-east-1-ubuntu-base:
aws-us-east-1-ubuntu-base: ip-172-30-2-245.ec2.internal:
aws-us-east-1-ubuntu-base: Minion did not return. [No response]
aws-us-east-1-ubuntu-base: usermod: group 'docker' does not exist
==> aws-us-east-1-ubuntu-base: Terminating the source AWS instance...
==> aws-us-east-1-ubuntu-base: No AMIs to cleanup
==> aws-us-east-1-ubuntu-base: Deleting temporary security group...
==> aws-us-east-1-ubuntu-base: Deleting temporary keypair...
Build 'aws-us-east-1-ubuntu-base' errored: Script exited with non-zero exit status: 6
Sudo salt '*' -v -t 60 state.applyで失敗します：
ミニオンは戻ってこなかった。 [応答なし]
2つのシナリオの唯一の違いは、インスタンスの作成がファイルを実行していないのに、packerがファイルからbashスクリプトを実行していることです。しかし、それがソルトマスターとその手先の間のコミュニケーションとどのように関係しているのかはわかりません。
何かご意見は？
1ダースの終了したインスタンスとさらに数十のトリックの後、私はそれを理解しました。どうやらsalt masterはどういうわけかスラッカーです：
aws-us-east-1-ubuntu-base: Cloning into '/tmp/docker-formula/.'...
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,161 [salt.cli.daemons ][INFO ][3762] Setting up the Salt Minion "ip-172-30-2-137.ec2.internal"
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,169 [salt.cli.daemons ][INFO ][3735] Setting up the Salt Master
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,321 [salt.daemons.masterapi][INFO ][3735] Preparing the root key for local communication
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,322 [salt.cli.daemons ][INFO ][3735] The salt master is starting up
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,329 [salt.master ][INFO ][3735] salt-master is starting as user 'root'
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,329 [salt.master ][INFO ][3735] Current values for max open files soft/hard setting: 100000/100000
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,329 [salt.master ][INFO ][3735] Creating master process manager
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,329 [salt.master ][INFO ][3735] Creating master maintenance process
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,331 [salt.master ][INFO ][3735] Creating master publisher process
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,332 [salt.master ][INFO ][3735] Creating master event publisher process
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,342 [salt.master ][INFO ][3735] Creating master request server process
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,347 [salt.master ][INFO ][3769] Starting the Salt Publisher on tcp://0.0.0.0:4505
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,349 [salt.master ][INFO ][3769] Starting the Salt Puller on ipc:///var/run/salt/master/publish_pull.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:08,412 [salt.master ][INFO ][3804] Setting up the master communication server
.....
aws-us-east-1-ubuntu-base: + sleep 10
.....
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,097 [salt.master ][INFO ][3784] Worker binding to socket ipc:///var/run/salt/master/workers.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,097 [salt.master ][INFO ][3784] Clear payload received with command _auth
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,098 [salt.master ][INFO ][3784] Authentication request from ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,098 [salt.master ][INFO ][3784] New public key for ip-172-30-2-137.ec2.internal placed in pending
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,100 [salt.crypt ][ERROR ][3762] The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,100 [salt.crypt ][INFO ][3762] Waiting 10 seconds before retry.
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,199 [salt.master ][INFO ][3785] Worker binding to socket ipc:///var/run/salt/master/workers.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,203 [salt.master ][INFO ][3795] Worker binding to socket ipc:///var/run/salt/master/workers.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,203 [salt.master ][INFO ][3803] Worker binding to socket ipc:///var/run/salt/master/workers.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:13,202 [salt.master ][INFO ][3793] Worker binding to socket ipc:///var/run/salt/master/workers.ipc
aws-us-east-1-ubuntu-base: + Sudo salt-key -A --yes
aws-us-east-1-ubuntu-base: The following keys are going to be accepted:
aws-us-east-1-ubuntu-base: + sleep 30
aws-us-east-1-ubuntu-base: Unaccepted Keys:
aws-us-east-1-ubuntu-base: ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: Key for minion ip-172-30-2-137.ec2.internal accepted.
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,112 [salt.master ][INFO ][3784] Clear payload received with command _auth
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,112 [salt.master ][INFO ][3784] Authentication request from ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,112 [salt.master ][INFO ][3784] Authentication accepted from ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,127 [salt.master ][INFO ][3795] Clear payload received with command _auth
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,127 [salt.master ][INFO ][3795] Authentication request from ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,128 [salt.master ][INFO ][3795] Authentication accepted from ip-172-30-2-137.ec2.internal
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,265 [salt.loaded.int.module.cmdmod][INFO ][3762] Executing command 'date +%z' in directory '/root'
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,270 [salt.minion ][INFO ][3762] Added mine.update to scheduler
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,271 [salt.utils.schedule][INFO ][3762] Added new job __mine_interval to scheduler
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,272 [salt.cli.daemons ][INFO ][3762] The salt minion is starting up
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,272 [salt.minion ][INFO ][3762] Minion is starting as user 'root'
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,273 [salt.minion ][INFO ][3762] Starting pub socket on ipc:///var/run/salt/minion/minion_event_c0afd79315_pub.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,273 [salt.minion ][INFO ][3762] Starting pull socket on ipc:///var/run/salt/minion/minion_event_c0afd79315_pull.ipc
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,280 [salt.minion ][INFO ][3762] Minion is ready to receive requests!
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:23,281 [salt.utils.schedule][INFO ][3762] Running scheduled job: __mine_interval
aws-us-east-1-ubuntu-base: + Sudo salt * -v -t 10 state.apply
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,306 [salt.master ][INFO ][3795] Clear payload received with command publish
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,308 [salt.master ][INFO ][3795] User Sudo_root Published command state.apply with jid 20160913230251306897
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,309 [salt.minion ][INFO ][3762] User Sudo_root Executing command state.apply with jid 20160913230251306897
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,314 [salt.minion ][INFO ][4361] Starting a new job with PID 4361
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,427 [salt.state ][INFO ][4361] Loading fresh modules for state activity
aws-us-east-1-ubuntu-base: 2016-09-13 23:02:51,438 [salt.fileclient ][INFO ][4361] Fetching file from saltenv 'base', ** done ** 'top.sls'
私の（意図的な）睡眠の間の遅れに注意してください。私のシェルスクリプトのほとんどのコマンドは即座に実行されるため、これらの遅延はあらゆる種類の問題を引き起こしていました。
もう1つのポイントは、キーが受け入れられるとすぐにジョブ__mine_intervalを受け取るミニオンです。ミニオンが要求したジョブをキューに入れることができず、代わりにMinion did not return. [No response]で応答し続けた理由がわかりません。別の睡眠がこのビットを解決しました。
これが私の作業スクリプトです:(ソルトログを見たい場合はテールのコメントを外してください）
#!/bin/bash
# show stuff being executed
set -x
# salt hostname for minions
echo 127.0.0.1 salt | Sudo cat >> /etc/hosts
# salt
Sudo add-apt-repository --yes ppa:saltstack/salt
Sudo apt-get update
Sudo apt-get install --yes salt-api salt-cloud salt-master salt-minion salt-ssh salt-syndic
# run on startup
Sudo update-rc.d salt-master defaults
Sudo update-rc.d salt-minion defaults
# increase log level
echo log_level: info | Sudo cat >> /etc/salt/master
echo log_level: info | Sudo cat >> /etc/salt/minion
# restart
Sudo service salt-master restart
Sudo service salt-minion restart
# show logs
# Sudo tail -f /var/log/salt/master &
# Sudo tail -f /var/log/salt/minion &
# get docker-formula and move it to /srv/salt
Sudo mkdir /tmp/docker-formula
Sudo git clone https://github.com/saltstack-formulas/docker-formula /tmp/docker-formula/.
Sudo mkdir -p /srv/salt
Sudo cp -vr /tmp/docker-formula/docker /srv/salt/docker/
# top.sls
Sudo cp -v /ops/config/top.sls /srv/salt/
# let things .. settle
sleep 10
# accept all minions
Sudo salt-key -A --yes
# let things .. settle
sleep 30
# apply to minions
Sudo salt '*' -v -t 10 state.apply
# add user to docker group
Sudo usermod -aG docker $USER