Человек и машина

#машины_aws

У CloudFormation два классных нововведения. Про первое уже написал Рома, обязательно пройдите и прочитайте, если вас задолбала последовательность: создал стек с бакетом - набил бакет объектами - удалил стек - стек не удалился - матерясь, чистишь бакет - удаляешь стек снова - раздраженно снимаешь галочку с “игнорировать удаление”.

Но мне, честно говоря, больше понравилась новость про дебаг с помощью CloudTrail.

Когда я работаю с новым или мало изученными сервисом, у меня часто происходят итерации trial and error. Где-то опечатался, где-то перепутал параметр, где-то добавил несовместимые свойства, где-то забыл построить зависимость с помощью DependsOn.

До того, как появилась возможно управлять стеками с disable rollback, обычный цикл разработки выглядел похожим на цикл удаления стека с непустыми бакетом:
1. Создаем стек
2. Стек валится, откатывается назад. Пока он откатывается, смотрим ошибку API
3. Ждем пока стек откатится. Поскольку это новый стек, мы его удаляем, потому что перенакатить изменения на новый стек, который сломался и откатился в пустоту ПОЧЕМУ-ТО ДО СИХ ПОР НЕЛЬЗЯ
4. Находим ошибку в шаблоне, исправляем. Повторяем итерацию с пункта 1.

Чем же тут хорош CloudTrail? Тем, что раньше у нас была скучная консоль с логом стека, где мы по куску ошибки должны были сделать вывод. Теперь же можно пройти в CloudTrail, посмотреть подробно не только ошибку, но и какие параметры были у запроса в API, со всеми полями. Это так же упрощает разбор ситуаций, когда создание валится не из-за опечаток в шаблоне, а например если у роли, с которой CloudFormation создает ресурс, недостаточно прав.

www.tgoop.com/manandthemachine/824

2.0K viewsMay 26 at 18:31

#машины_aws

У CloudFormation два классных нововведения. Про первое уже написал Рома, обязательно пройдите и прочитайте, если вас задолбала последовательность: создал стек с бакетом - набил бакет объектами - удалил стек - стек не удалился - матерясь, чистишь бакет - удаляешь стек снова - раздраженно снимаешь галочку с “игнорировать удаление”.

Но мне, честно говоря, больше понравилась новость про дебаг с помощью CloudTrail.

Когда я работаю с новым или мало изученными сервисом, у меня часто происходят итерации trial and error. Где-то опечатался, где-то перепутал параметр, где-то добавил несовместимые свойства, где-то забыл построить зависимость с помощью DependsOn.

До того, как появилась возможно управлять стеками с disable rollback, обычный цикл разработки выглядел похожим на цикл удаления стека с непустыми бакетом:
1. Создаем стек
2. Стек валится, откатывается назад. Пока он откатывается, смотрим ошибку API
3. Ждем пока стек откатится. Поскольку это новый стек, мы его удаляем, потому что перенакатить изменения на новый стек, который сломался и откатился в пустоту ПОЧЕМУ-ТО ДО СИХ ПОР НЕЛЬЗЯ
4. Находим ошибку в шаблоне, исправляем. Повторяем итерацию с пункта 1.

Чем же тут хорош CloudTrail? Тем, что раньше у нас была скучная консоль с логом стека, где мы по куску ошибки должны были сделать вывод. Теперь же можно пройти в CloudTrail, посмотреть подробно не только ошибку, но и какие параметры были у запроса в API, со всеми полями. Это так же упрощает разбор ситуаций, когда создание валится не из-за опечаток в шаблоне, а например если у роли, с которой CloudFormation создает ресурс, недостаточно прав.

BY Человек и машина