в него то что нужно?
Смотрю в сторону бото3 + ансибл
смотри в сторону ec2 user-data
Его можно передать при создании инстанса Но потом надо внутри инстанса развернуть проект по шаблону(нужен юзер инпут)
хм, а что за инпут нужен?
Бото лишнее явно и оверкил
userdata?
Ей можно поднять докер контейнер?
А зачем ec2 для контейнера? Зачем его там руками поднимать даже если нужен именно ec2?
есть альтернатива?
packer + terraform
Ну а почему нет, docker run в шелл скрипте)
Зачем изобретать велосипед если ты уже хочешь использовать ансибл? Так же и тераформ можно, свой набор утилит поддерживать не всегда рентабильно
Ну так велосипедишь, велосипедишь и раз - написал свой ансибл
Ага потом уволился и все поддерживать некому и зачем велосипеды и тратить просто так силы)
ну вот они по этому же принципе и выпилили велосипед и перешли на ансибл
Да это логично))) есть конечно случаи когда надо но достаточно редко
если на каждый чих передеплоивать с нуля инстанс то user-data (он применяется только при создании), в том числе через cloudformation/tf. Если нужно периодически на том же инстансе - ansible
А чем плох подход? https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/ просто везде юзер дата... Разве ssm не про удобную провизию теми же плейбуками?
Он даже лучше. :)
Спасибо. ещё тогда вопрос. А чем можно мониторить изменение времени на ec2 или отставание? Я так понял клаудвотч не имеем подобных метрик
Есть отличный chrony, зачем мониторить, когда можно не допустить?
мониторить нужно) мало ли хрони не оюновляеться тогда могут быть проблемы
так можно мониторить chrony и смотреть их логи, по отклонениям и вообще работе.
ну я про это и говорю) мониторить именно его
Отлично. А мониторить предлагаешь через клаудвотч логи? И просто метрику повесить на запись в логе?
Обсуждают сегодня