SuperOleg dev notes

Forwarded from royal_blue_dev

Методология The Twelve-Factor App требует строгого разделения сборки и рантайма. Технически это значит что docker-образ приложения привязывается к хэшу коммита, на котором собирается. Главное – это позволяет релизить в прод именно тот код, который был протестирован на стенде. Такой подход дает определенные гарантии, однако, порождает и непростые ситуации:
• Продукт одной из команд – это NodeJS SSR приложение. Важная часть таких приложений, это stats.json файл, который содержит информацию о получившихся при сборке файлах. Сами файлы раздаются с CDN, соответственно и загрузка их туда является шагом сборки;
• Поскольку stats.json зашивается внутрь docker-образа и переиспользуется между деплоями с одного коммита, мы точно также должны переиспользовать файлы, загружаемые на CDN, поэтому на этапе сборки пакуем получившиеся файлы в .zip-архив и сохраняем на S3;
• Ссылки на файлы содержат хэши, которые должны быть идемпотентными, но это не всегда так, например, из-за багов в инструментах сборки. Таким образом, мы получаем критическую неочевидную связь образ => архив, так как для образа и архива хэши файлов должны совпадать. Несовпадение хэшей – риск полной недоступности приложения, поскольку приложение будет запрашивать файлы которых может не быть на CDN;
• Образы хранятся в Artifactory, который имеет политики очистки. В нашем случае, для нерелизных образов это 7 дней. Отсюда следует, что если кто-то создаст МР, задеплоит его, подождет 7 дней, а потом задеплоит приложение еще раз или откатится на коммит, для которого нет образа в Artifactory и при этом разойдутся хэши файлов – приложение не будет работать. Это не очень страшно при деплое, но катастрофа при откате: выпустили приложение => решили откатить => откатили и приложение все равно не работает;
• Вишенка на торте: у S3 тоже есть политики очистки, и здесь все работает с точностью да наоборот;

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

Не призываю отказываться от The Twelve-Factor App, считаю ее очень важной и оберегающей от множества ошибок, скорее хочу подсветить, что при разделении системы на части автоматически вылезают проблемы синхронизации состояния. Стоит учитывать это при проектировании.

12factor.net

The Twelve-Factor App

A methodology for building modern, scalable, maintainable software-as-a-service apps.

👍5

www.tgoop.com/super_oleg_dev/208

1.52K viewsDec 2, 2024 at 11:23

Методология The Twelve-Factor App требует строгого разделения сборки и рантайма. Технически это значит что docker-образ приложения привязывается к хэшу коммита, на котором собирается. Главное – это позволяет релизить в прод именно тот код, который был протестирован на стенде. Такой подход дает определенные гарантии, однако, порождает и непростые ситуации:
• Продукт одной из команд – это NodeJS SSR приложение. Важная часть таких приложений, это stats.json файл, который содержит информацию о получившихся при сборке файлах. Сами файлы раздаются с CDN, соответственно и загрузка их туда является шагом сборки;
• Поскольку stats.json зашивается внутрь docker-образа и переиспользуется между деплоями с одного коммита, мы точно также должны переиспользовать файлы, загружаемые на CDN, поэтому на этапе сборки пакуем получившиеся файлы в .zip-архив и сохраняем на S3;
• Ссылки на файлы содержат хэши, которые должны быть идемпотентными, но это не всегда так, например, из-за багов в инструментах сборки. Таким образом, мы получаем критическую неочевидную связь образ => архив, так как для образа и архива хэши файлов должны совпадать. Несовпадение хэшей – риск полной недоступности приложения, поскольку приложение будет запрашивать файлы которых может не быть на CDN;
• Образы хранятся в Artifactory, который имеет политики очистки. В нашем случае, для нерелизных образов это 7 дней. Отсюда следует, что если кто-то создаст МР, задеплоит его, подождет 7 дней, а потом задеплоит приложение еще раз или откатится на коммит, для которого нет образа в Artifactory и при этом разойдутся хэши файлов – приложение не будет работать. Это не очень страшно при деплое, но катастрофа при откате: выпустили приложение => решили откатить => откатили и приложение все равно не работает;
• Вишенка на торте: у S3 тоже есть политики очистки, и здесь все работает с точностью да наоборот;

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

Не призываю отказываться от The Twelve-Factor App, считаю ее очень важной и оберегающей от множества ошибок, скорее хочу подсветить, что при разделении системы на части автоматически вылезают проблемы синхронизации состояния. Стоит учитывать это при проектировании.

BY SuperOleg dev notes