AWS: Как передавать большие файлы (например, конфиги) в USERDATA при создании LaunchConfiguration?

Question

[hoodie]

В Amazon AWS создаю Launch Configuration для инстанса Ubuntu Server 16.04 LTS (HVM), SSD Volume Type - ami-da05a4a0
Эти инстансы я потом хочу использовать для Auto Scaling Groups
При старте инстанса необходимо установить nginx, php, nodejs и т.д., также необходимо установить SSL сертификаты и создать кастомные конфиги.

Для этого я в файле который передаю в USERDATA (это баш-скрипт) использую следующий метод:

cat << 'EOF' > /etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
.... тут весь конфиг ....
EOF

Вобщем у меня несколько больших конфигов + таким же образом я устанавливаю ssh ключи и SSL сертификаты.

В определенный момент наткнулся на ошибку "User data is limited to 16384 bytes" при старте инстанса. В связи с чем возник вопрос:

Как правильно передавать конфиги и устанавливать SSL сертификаты в моем случае?

Вижу два варианта:
1) Создать AMI в котором сертификаты, ключи и конфиги уже сохранены и в userdata скрипте при поднятии инстанса просто раскидать их по нужным папкам. Минус такого подхода в том что при изменении конфига нужно будет пересоздавать AMI образ. Хотя, наверное, это будет не часто.
2) Выложить все конфиги, ключи и сертификаты на отдельный сервер, закрыть basic auth и при старте инстанса скачивать их curl'ом или wget'ом.

Посоветуйте, как бы сделали вы?

Answer 1

[Dmitri Kaminin]

нужно будет пересоздавать AMI образ. Хотя, наверное, это будет не часто

Не бежите вперед поезда. Если данные будут меняться не часто, то пока сделайте первый вариант, он экономит время и технически прост. В случае если у вас будут часто меняться конфиги и.т.д то только тогда занимайтесь оптимизацией. Смотрите в сторону packer

Проблема в динамичной загрузке(через конфиг сервер) в том что при запуске инстанса что то может пойти не так: глючит интернет - не смог скачатся конфиг, упал ваш сервер с конфигами и так далее...

В случае если вы подготовите готовый образ, то всех этих проблем можно избежать так как все нужное уже будет внутри. Еще один плюс это в том что у вас будет список версий образов. Если что то пойдет не так у вас всегда будут предыдущие образы на которые можно будет откатится.

Answer 2

[Евгений Хлебников]

1. AMI
Все плюсы и минусы вам расписали.
2. S3 bucket
Поддерживает шифрование, в том числе и клиентским(вашим) ключом - вы можете свободно положить в приватный бакет всю необходимую секретную информацию и простым aws s3 cp в юзердате всё получить.
Обновление сертификатов и конфигов, соответственно, просто перезаливкой в бакет и пересозданием инстансов ASG
Это вместо некоего веб хранилища.
3. SSM parameters
Можно перед развертыванием ASG инициализировать параметры вашего окружения, вплоть до сертификатов в зашифрованных ключах SSM и при развертывании забирать значения из SSM
Более сложно чем бакет, поскольку предназначается для кросс-датацентрового обмена секретами.

В вашем случае наилучшим решением будет s3 бакет, а самым простым и быстрым в реализации - AMI
Для того чтоюы не передавать access key и secret key для работы с амазоном в юзердате - используйте aws instance profile с нужными инстансу политиками.

Answer 3

[Saboteur]

1. Копировать можно просто по scp
2. Выкладывать можно не только под basic auth, а еще и в запароленных архивах