Как заставить сценарии запуска cloud-init запускаться каждый раз при загрузке экземпляра EC2?
у меня есть экземпляр EC2 с AMI на основе AMI Amazon Linux. Как и все такие AMIs, он поддерживает cloud-init система для запуска сценариев запуска на основе пользовательских данных, передаваемых в каждый экземпляр. В этом конкретном случае мои пользовательские данные вводятся в файл Include, который является источником нескольких других сценариев запуска:
#include
http://s3.amazonaws.com/path/to/script/1
http://s3.amazonaws.com/path/to/script/2
при первой загрузке экземпляра сценарий запуска cloud-init запускается правильно. Однако, если я сделаю мягкую перезагрузку экземпляр (путем запуска sudo shutdown -r now
, например), экземпляр возвращается без запуск скрипта запуска во второй раз. Если я вхожу в системные журналы, я вижу:
Running cloud-init user-scripts
user-scripts already ran once-per-instance
[ OK ]
это не то, что я хочу-я вижу полезность наличия сценариев запуска, которые запускаются только один раз в жизни экземпляра, но в моем случае они должны запускаться каждый раз при запуске экземпляра, как обычные сценарии запуска.
Я понимаю, что одно из возможных решений-вручную пусть мои скрипты вставляются в rc.local
после запуска в первый раз. Однако это кажется обременительным, поскольку cloud-init и rc.D среды тонко отличаются, и теперь мне придется отлаживать скрипты при первом запуске и всех последующих запусках отдельно.
кто-нибудь знает, как я могу сказать cloud-init всегда запускать мои скрипты? Это, безусловно, звучит как то, что дизайнеры cloud-init рассмотрели бы.
5 ответов
в 11.10, 12.04 и более поздних версиях вы можете достичь этого, сделав "скрипты-пользователь "запустить " всегда". В /etc / cloud / облако.cfg вы увидите что-то вроде:
cloud_final_modules:
- rightscale_userdata
- scripts-per-once
- scripts-per-boot
- scripts-per-instance
- scripts-user
- keys-to-console
- phone-home
- final-message
Это может быть изменено после загрузки, или данные cloud-config, переопределяющие эту строфу, могут быть вставлены через пользовательские данные. Т. е. в user-data вы можете указать:
#cloud-config
cloud_final_modules:
- rightscale_userdata
- scripts-per-once
- scripts-per-boot
- scripts-per-instance
- [scripts-user, always]
- keys-to-console
- phone-home
- final-message
Это также может быть "#included", как вы сделали в своем описании. К сожалению, прямо сейчас вы не можете изменить "cloud_final_modules", но только переопределить его. Я надеюсь добавить возможность изменять разделы конфигурации в какой-то момент.
есть немного больше информации об этом в cloud-config doc на http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
кроме того , вы можете поместить файлы в /var/lib/cloud/scripts/per-boot, и они будут запускаться путем "scripts-per-boot".
на /etc/init.d/cloud-init-user-scripts
измените эту строку:
/usr/bin/cloud-init-run-module once-per-instance user-scripts execute run-parts ${SCRIPT_DIR} >/dev/null && success || failure
to
/usr/bin/cloud-init-run-module always user-scripts execute run-parts ${SCRIPT_DIR} >/dev/null && success || failure
удачи !
одна из возможностей, хотя и несколько хакерская, - удалить файл блокировки, который cloud-init использует для определения того, запущен ли пользовательский скрипт. В моем случае (Amazon Linux AMI) этот файл блокировки находится в /var/lib/cloud/sem/
и называется user-scripts.i-7f3f1d11
(хэш-часть в конце изменяет каждую загрузку). Поэтому следующий скрипт пользовательских данных, добавленный в конец файла Include, сделает трюк:
#!/bin/sh
rm /var/lib/cloud/sem/user-scripts.*
Я не уверен, что это будет иметь какие-либо побочные эффекты на что-либо еще, но это сработало в моих экспериментах.
cloud-init поддерживает это теперь изначально, см. описания команд runcmd vs bootcmd в документации (http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot):
"runcmd":
#cloud-config
# run commands
# default: none
# runcmd contains a list of either lists or a string
# each item will be executed in order at rc.local like level with
# output to the console
# - runcmd only runs during the first boot
# - if the item is a list, the items will be properly executed as if
# passed to execve(3) (with the first arg as the command).
# - if the item is a string, it will be simply written to the file and
# will be interpreted by 'sh'
#
# Note, that the list has to be proper yaml, so you have to quote
# any characters yaml would eat (':' can be problematic)
runcmd:
- [ ls, -l, / ]
- [ sh, -xc, "echo $(date) ': hello world!'" ]
- [ sh, -c, echo "=========hello world'=========" ]
- ls -l /root
- [ wget, "http://slashdot.org", -O, /tmp/index.html ]
"bootcmd":
#cloud-config
# boot commands
# default: none
# this is very similar to runcmd, but commands run very early
# in the boot process, only slightly after a 'boothook' would run.
# bootcmd should really only be used for things that could not be
# done later in the boot process. bootcmd is very much like
# boothook, but possibly with more friendly.
# - bootcmd will run on every boot
# - the INSTANCE_ID variable will be set to the current instance id.
# - you can use 'cloud-init-per' command to help only run once
bootcmd:
- echo 192.168.1.130 us.archive.ubuntu.com >> /etc/hosts
- [ cloud-init-per, once, mymkfs, mkfs, /dev/vdb ]
также обратите внимание на пример команды" cloud-init-per " в bootcmd. От нее помощь:
Usage: cloud-init-per frequency name cmd [ arg1 [ arg2 [ ... ] ]
run cmd with arguments provided.
This utility can make it easier to use boothooks or bootcmd
on a per "once" or "always" basis.
If frequency is:
* once: run only once (do not re-run for new instance-id)
* instance: run only the first boot for a given instance-id
* always: run every boot
Я боролся с этой проблемой почти два дня, пробовал все решения, которые мог найти, и, наконец, объединив несколько подходов, пришел со следующим:
MyResource:
Type: AWS::EC2::Instance
Metadata:
AWS::CloudFormation::Init:
configSets:
setup_process:
- "prepare"
- "run_for_instance"
prepare:
commands:
01_apt_update:
command: "apt-get update"
02_clone_project:
command: "mkdir -p /replication && rm -rf /replication/* && git clone https://github.com/awslabs/dynamodb-cross-region-library.git /replication/dynamodb-cross-region-library/"
03_build_project:
command: "mvn install -DskipTests=true"
cwd: "/replication/dynamodb-cross-region-library"
04_prepare_for_west:
command: "mkdir -p /replication/replication-west && rm -rf /replication/replication-west/* && cp /replication/dynamodb-cross-region-library/target/dynamodb-cross-region-replication-1.2.1.jar /replication/replication-west/replication-runner.jar"
run_for_instance:
commands:
01_run:
command: !Sub "java -jar replication-runner.jar --sourceRegion us-east-1 --sourceTable ${TableName} --destinationRegion ap-southeast-1 --destinationTable ${TableName} --taskName -us-ap >/dev/null 2>&1 &"
cwd: "/replication/replication-west"
Properties:
UserData:
Fn::Base64:
!Sub |
#cloud-config
cloud_final_modules:
- [scripts-user, always]
runcmd:
- /usr/local/bin/cfn-init -v -c setup_process --stack ${AWS::StackName} --resource MyResource --region ${AWS::Region}
- /usr/local/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource MyResource --region ${AWS::Region}
это настройка для процесса репликации между регионами DynamoDb.