AV
Что значит "новый тип инстансов"?
Size: a a a
2020 May 01
D
Что значит "новый тип инстансов"?
ну добавили например постгрес ноду, которой раньше не было, был RDS
AV
...packer не предлагать ))
Да тут неважно что предлагать, userdata работает как и должна, имо. Изменения в userdata не повод для пересоздания инстанса.
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
AV
ну добавили например постгрес ноду, которой раньше не было, был RDS
Я думал Instance Type. Это, всё-таки, термин, который уже застолблён.
AV
Тут же речь идёт о mutable infratructure, видимо. И изменения нужно раскатывать по-другому. Вам там нужно эти запреты на не-CloudFormation выбивать из головы менеджмента.
DZ
Да тут неважно что предлагать, userdata работает как и должна, имо. Изменения в userdata не повод для пересоздания инстанса.
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
но вот изменения в userdata в launchconfiguration приводят к пересозданию инстансов
DZ
где-то тут логика поломалась, нет?
AV
Dmytro Zavalkin
но вот изменения в userdata в launchconfiguration приводят к пересозданию инстансов
Не знаю, я считаю, что UserData - это быстрый хак, а полноценно использовать это для конфигурирования инстанса нельзя.
В проде не использовал никогда Userdata, как инструмент конфигурации. Пользовался описанным выше.
В проде не использовал никогда Userdata, как инструмент конфигурации. Пользовался описанным выше.
D
Тут же речь идёт о mutable infratructure, видимо. И изменения нужно раскатывать по-другому. Вам там нужно эти запреты на не-CloudFormation выбивать из головы менеджмента.
так после отладки оно не будет меняться
D
и работать как нужно. А пока - надо переключить режим first-boot в always. Или использовать другую секцию, которая всегда выполняется, забыл как зовётся
D
boot вроде
D
пока читал доку, нашёл такое
cloud_final_modules:
- [scripts-user, always]
проверяю
cloud_final_modules:
- [scripts-user, always]
проверяю
D
Да тут неважно что предлагать, userdata работает как и должна, имо. Изменения в userdata не повод для пересоздания инстанса.
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
Правильный pipeline:
Изменения где-то (в том числе и в userdata, если хочется) -> build AMI -> tests -> deploy with new AMI
build AMI -> tests -> deploy with new AMI
так и есть, для уже отлаженных стэков
так и есть, для уже отлаженных стэков
D
Dmytro Zavalkin
но вот изменения в userdata в launchconfiguration приводят к пересозданию инстансов
должно. А у нас - не приводят :(
AV
build AMI -> tests -> deploy with new AMI
так и есть, для уже отлаженных стэков
так и есть, для уже отлаженных стэков
Ну а если это не прод, так почему не убить инстанс просто? При пересоздании не подтянет новую UserData ?
D
Ну а если это не прод, так почему не убить инстанс просто? При пересоздании не подтянет новую UserData ?
долго. На каждый чих минут 15 ждать.
AV
долго. На каждый чих минут 15 ждать.
Это куда столько времени уходит?
D
Ну а если это не прод, так почему не убить инстанс просто? При пересоздании не подтянет новую UserData ?
а, и просто убить инстанс не поможет, стэк развалится. Надо удалять стэк, потом создавать
D
Это куда столько времени уходит?
а шоб я знал
AV
а, и просто убить инстанс не поможет, стэк развалится. Надо удалять стэк, потом создавать
Вот за что я "люблю" CloudFormation