Данное в статье решение, емнип, умещается в free tier амазона, так что сильно волноватся насчет внезапного счёта на пару килобаксов я бы не стал. Хотя если это волнует больше чем аптайм сайта, склонен согласится. Я в данном случае возможно забил бы на редирект с http вообще, ибо не помню где и кто последние пару лет куда либо тыкался по http, тем самым уменьшил риск на перерасход квоты запусков.
Время отдачи самого cloudfront на порядок быстрее чем запуск фукнции, и это то что вы получите при прямом доступе к файлам по https. И это будет более-менее одинаково безотносительно того как далеко юзер от вашего сервера.
Если не рассматривать варианты физического сервера (или кустарщину а-ля подавать сайт с домашнего компа) - альтернативы облаку в данном случае все сами по себе "облачные", будь то vpc-шка в хецнере или что либо другое. Так что для данных требований на сегодняшний день, если ты не организация у которой есть своя платформа для раздачи статики - шило на мыло, а мыло в этом случае означает админить свой сервак. Для дедов у которых конфиги апача от зубов отскакивают - не вопрос. А для тех кто родился после 2000 года - уже не факт ))
И вам придётся таки жёстко поспорить за утверждение что S3 + cloudfront не обгоняют по надёжности сервачок с апачем, даже если его админит сам Линус ))
а прикрутить костыли для гашения всего этого добра, если оно начало жрать финансы, модуля терраформ не нашлось )
terraform destroy Проблема не гасить, проблема узнать что есть проблема, особенно в амазоне где обновления билинга могут опаздывать аж на сутки, за которы может утечь много воды баксов.
Хотя в целом, если требуется поднять статический сайт хоть как-то за 2 копейки я бы тоже не шёл в амазон а выбрал бы решение где биллинг фиксирован и есть защита от такой ерунды, даже если это будет стоить на пару копеек больше, зато фикс.
Да, только статический сайт в конфигурации в статье даёт вам сразу кучу преимуществ:
Он дешевле, т.к не нужен сервер с процессором для того чтоб запускать апач
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Он быстрее, т.к тут вы получаете CDN в комплекте
Он требует меньше головняка ибо не нужно обновлять сертификат
Да и насчёт простоты - конфигурация описанная в статье поднимается 30 строками терраформ кода которые можно найти в гитхабе готовым модулем. При желании сразу интегрированным с гитхабом для авто-обновления сайта с билдом (если скажем страничка на nodejs с webpack). И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Так что не уверен что на самом деле проще. Наверное только github pages и всякие такие.
(автор сего камента сам много лет apt-get install apache2 пока не ушел в девопс, если что)
Было бы интересно почитать про ваш опыт с модулями опенстака вне коренных.
Последний раз когда я имел дело с опенстаком в середине 2018 года, ни один из интересующих и реально востребованных у меня модулей (Designate, Trove, Manila) не заводился, от слова вообще, несмотря на уверения документации что оно прям работает и статьй людей у которых оно якобы бежит аж в проде.
Про более эзотерические модули как Mistral или Murano вообще молчу, такое ощущение что их просто выпустили полностью сырыми в расчете что пользователи будут их дописывать в процессе установки.
Практически дословно мой опыт работы с опенстаком в 2015-16 годах.
Даже обидно что за 7 лет в этом плане ничего не стало лучше - та же страшная документация, неработающие из коробки all-in-one референс-развертки, стопки глюков на ровном месте. Я влюбился в опенстак тогда, и до сих пор считаю что это впринципе отличная платформа не имеющая аналогов по многим пунктам, но исполнение, особенно во всем что связано с разверткой и администрированием - из рук вон плохо.
Мне тогда повезло, я практически сразу понял что не потяну ручную развертку и наткнулся на набор chef openstack cookbooks которые позволили мне хоть как-то развернуть рабочий кластер а потом разбиратся на рабочей системе.
Очень рекоммендую залезть руками поглубже в работающий кластер и как следует разобратся как оно работает - как различные модули/сервисы взаимодействуют между собой (message broker, база данных, зачем нужен keystone, iptables/openVswitch итп.), что они на самом деле делают за кулисами и как. Без этого вся эта красивая конструкция посыпется при первом серьёзном глюке и не будет никакой возможности что-либо починить, только переделывать и надеятся что оно снова заработает.
А глюки будут, увы. Достаточно чтоб несколько раз без обьяснения пропала сеть или отвалились ноды, как у меня было - и довольное руководство может резко изменить своё мнение.
Спасибо за статью, помогло.
Как раз недавно столкнулся с очень похожей задачей, раньше не приходилось разворачивать react-приложения а тут почти один в один то что мне надо.
Да, я бы уточнил в статье что для продакшена это сыро. Лишние файлы и пакеты, совершенно лишний билд при разворачивании, да и компоуз для прода как-то не очень. Зато очень подходит для дев-среды разраба.
Но в целом, например для джуна/мидла реакт разработчика статья супер полезная, имхо, и намного лучше и целостней того что навскидку гуглиться по теме.
Данное в статье решение, емнип, умещается в free tier амазона, так что сильно волноватся насчет внезапного счёта на пару килобаксов я бы не стал. Хотя если это волнует больше чем аптайм сайта, склонен согласится. Я в данном случае возможно забил бы на редирект с http вообще, ибо не помню где и кто последние пару лет куда либо тыкался по http, тем самым уменьшил риск на перерасход квоты запусков.
Время отдачи самого cloudfront на порядок быстрее чем запуск фукнции, и это то что вы получите при прямом доступе к файлам по https. И это будет более-менее одинаково безотносительно того как далеко юзер от вашего сервера.
Если не рассматривать варианты физического сервера (или кустарщину а-ля подавать сайт с домашнего компа) - альтернативы облаку в данном случае все сами по себе "облачные", будь то vpc-шка в хецнере или что либо другое. Так что для данных требований на сегодняшний день, если ты не организация у которой есть своя платформа для раздачи статики - шило на мыло, а мыло в этом случае означает админить свой сервак. Для дедов у которых конфиги апача от зубов отскакивают - не вопрос. А для тех кто родился после 2000 года - уже не факт ))
И вам придётся таки жёстко поспорить за утверждение что S3 + cloudfront не обгоняют по надёжности сервачок с апачем, даже если его админит сам Линус ))
terraform destroyПроблема не гасить, проблема узнать что есть проблема, особенно в амазоне где обновления билинга могут опаздывать аж на сутки, за которы может утечь много
водыбаксов.Хотя в целом, если требуется поднять статический сайт хоть как-то за 2 копейки я бы тоже не шёл в амазон а выбрал бы решение где биллинг фиксирован и есть защита от такой ерунды, даже если это будет стоить на пару копеек больше, зато фикс.
Да, только статический сайт в конфигурации в статье даёт вам сразу кучу преимуществ:
Он дешевле, т.к не нужен сервер с процессором для того чтоб запускать апач
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Он быстрее, т.к тут вы получаете CDN в комплекте
Он требует меньше головняка ибо не нужно обновлять сертификат
Да и насчёт простоты - конфигурация описанная в статье поднимается 30 строками терраформ кода которые можно найти в гитхабе готовым модулем. При желании сразу интегрированным с гитхабом для авто-обновления сайта с билдом (если скажем страничка на nodejs с webpack). И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Так что не уверен что на самом деле проще. Наверное только github pages и всякие такие.
(автор сего камента сам много лет apt-get install apache2 пока не ушел в девопс, если что)
Было бы интересно почитать про ваш опыт с модулями опенстака вне коренных.
Последний раз когда я имел дело с опенстаком в середине 2018 года, ни один из интересующих и реально востребованных у меня модулей (Designate, Trove, Manila) не заводился, от слова вообще, несмотря на уверения документации что оно прям работает и статьй людей у которых оно якобы бежит аж в проде.
Про более эзотерические модули как Mistral или Murano вообще молчу, такое ощущение что их просто выпустили полностью сырыми в расчете что пользователи будут их дописывать в процессе установки.
Практически дословно мой опыт работы с опенстаком в 2015-16 годах.
Даже обидно что за 7 лет в этом плане ничего не стало лучше - та же страшная документация, неработающие из коробки all-in-one референс-развертки, стопки глюков на ровном месте. Я влюбился в опенстак тогда, и до сих пор считаю что это впринципе отличная платформа не имеющая аналогов по многим пунктам, но исполнение, особенно во всем что связано с разверткой и администрированием - из рук вон плохо.
Мне тогда повезло, я практически сразу понял что не потяну ручную развертку и наткнулся на набор chef openstack cookbooks которые позволили мне хоть как-то развернуть рабочий кластер а потом разбиратся на рабочей системе.
Очень рекоммендую залезть руками поглубже в работающий кластер и как следует разобратся как оно работает - как различные модули/сервисы взаимодействуют между собой (message broker, база данных, зачем нужен keystone, iptables/openVswitch итп.), что они на самом деле делают за кулисами и как. Без этого вся эта красивая конструкция посыпется при первом серьёзном глюке и не будет никакой возможности что-либо починить, только переделывать и надеятся что оно снова заработает.
А глюки будут, увы. Достаточно чтоб несколько раз без обьяснения пропала сеть или отвалились ноды, как у меня было - и довольное руководство может резко изменить своё мнение.
Как раз недавно столкнулся с очень похожей задачей, раньше не приходилось разворачивать react-приложения а тут почти один в один то что мне надо.
Да, я бы уточнил в статье что для продакшена это сыро. Лишние файлы и пакеты, совершенно лишний билд при разворачивании, да и компоуз для прода как-то не очень. Зато очень подходит для дев-среды разраба.
Но в целом, например для джуна/мидла реакт разработчика статья супер полезная, имхо, и намного лучше и целостней того что навскидку гуглиться по теме.