onlyq
@onlyq
Разработчик Девелопер HTML5 программист

Как правильно делпоить на AWS?

Помоги разобраться господа, я совсем запутался что к чему
Есть проект на стандартном стакэ:
Express/React/Webpack

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

Следующим решением было добавить hash в имя файла file.hash2.js
И сохранить старый файл в /dist file.hash1.js

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

Как правильно организовать production build что бы пользователи даже не поняли что у них все обновилось
  • Вопрос задан
  • 92 просмотра
Пригласить эксперта
Ответы на вопрос 3
@rPman
Имя файла с его хешем или версией - норма! Помимо косяков браузеров, которые в различных граничных ситуациях кешируют то что нельзя, есть еще корявые провайдеры - делающие это кеширование прозрачным.

Самый простой пример возможной работы двух версий одновременно - это возможность обеспечить непрерывную работу во время обновления.

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

И не только обновление файлов может все поломать. Процесс обновления почти всегда в простом виде обрывает бизнеспроцессы, завязанные на обновляемые данные, особенно это заметно если необходимо обновлять базу, и это занимает время (десятки минут-часы), пользователи в этот момент могут получить сообщения об ошибках или даже нарушение самого бизнеспроцесса вплоть до повреждения данных, если это обновление не учло (например состояния объектов, вы вводите новое промежуточное состояние, а старая версия его не учитывает, старая версия бакэнда может пропустить новое состояние, задав неправильное с точки зрения новой версии или наоборот задать новое там где старые клиенты его не поймут и будут выдавать ошибки).

Кстати, версия, с которой работает клиент может храниться и учитываться в сессии, чтобы случайно по середине бизнеспроцесса пользователь не перескочил, обновив страницу.

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

Очень сложно описывать в общем виде косяки которые могут вылезти, и дай бог если для обновления у вас есть возможность остановить работу, но что делать если у вас миллиарды записей и вам нужно править структуру, на которую может уйти сутки или даже недели? Мало кто может позволить себе остановку бизнеса на такой срок.
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Самое простое чтобы не думать то использовать aws beanstalk. Там есть blue-green deployment. Когда станет система сложнее то чтоит переползти на AWS ECS.

Ну а что до тимлида то ему можно только посочувствоать. Человек явно не в курсе про SDLC и о том какие практики по выводу старых версий из обращения. Абсолютно нормально когда 2 версии продукта работают параллельно
Ответ написан
zoonman
@zoonman
CEO @ LinuxQuestions.ru
Переведите ваше приложение под create-react-app.
Оно автоматом все файлики собирает с хэшами.
Дальше сделайте дистрибьюцию через CloudFront и после сборки приложения грузите в бакет артефакты сборки (s3 sync). После загрузки вызывайте сброс кэша дистрибьюции CF.
Чтобы не ломать фронт, полностью пишите код обратно совместимым в пределах нескольких последних деплойментов.
Продумывайте стратегию развертываний и т.д. Вплоть до форсирования перезагрузки на клиенте по событию с сервера.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы