Comments 20
Для чего это? Хостинг стоит копейки.
Во сколько в итоге это обойдется? На yandex cloud похожий вариант у меня получился за ~ 30 рублей в месяц, так как нужно оплачивать Cloud DNS, остальное укладывается в бесплатные лимиты.
А можно тоже самое, но только отдельную папку домена хостить на S3, а весь сайт на Lambda/EC2?
У дедов проще было )
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443;
server_name example.com;
...
}
Да, только статический сайт в конфигурации в статье даёт вам сразу кучу преимуществ:
Он дешевле, т.к не нужен сервер с процессором для того чтоб запускать апач
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Он быстрее, т.к тут вы получаете CDN в комплекте
Он требует меньше головняка ибо не нужно обновлять сертификат
Да и насчёт простоты - конфигурация описанная в статье поднимается 30 строками терраформ кода которые можно найти в гитхабе готовым модулем. При желании сразу интегрированным с гитхабом для авто-обновления сайта с билдом (если скажем страничка на nodejs с webpack). И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Так что не уверен что на самом деле проще. Наверное только github pages и всякие такие.
(автор сего камента сам много лет apt-get install apache2 пока не ушел в девопс, если что)
Вообще мой коммент был лулзов ради, но с вашими утверждениями готов поспорить :)
Он дешевле, т.к не нужен сервер с процессором
Сервер вам все равно нужен :) Обязательно с процессором :) Причем он будет нагружен кроме вашего редиректа еще тоннами логики приложений высокого уровня абстракций, которые скрывают от вас тот низкий уровень абстракции, где апач и процессор.
А сравнивать стоимость облака с необлаком без конкретных величин трафика, и т.п. бессмысленно. Каждый будет прав.
для того чтоб запускать апач
В моем примере апач запускать не надо :)
Он надежнее т.к у S3 хранилища и остальных компонент аптайм выше чем у вашего сервера с апачем
Дискуссионное утверждение )
Он быстрее, т.к тут вы получаете CDN в комплекте
Точно быстрее? После фразы в статье "Price class: выбрать нужный по балансу цена/время отклика."? Более того, тут вот пишут, что для этих функций latency 100мс - это офигеть как круто.
Он требует меньше головняка
Меньше головняка, что аж статью написали о том как это сделать :) Причем через 2 года она скорее всего устареет т.к. админ интерфейсы у прова изменятся и кнопки тыкать нужно будет в других местах.
И не нужно покупать сервер, ставить операционку, ставить апач и различные fail2ban и иже с ними механизмы как обезопасить сервер.
Ну да, без fail2ban на каком-нить vsp, если вдруг вы заинтересовали какого-нибуть доморощенного кулхацкера, у вас будет лежать сервер с вашей статикой, а на serverless, у вас будет лежать на столе счет на несколько килобаксов, т.к. хардлимитов из коробки нет, а прикрутить костыли для гашения всего этого добра, если оно начало жрать финансы, модуля терраформ не нашлось )
P.S.
Но я не хейчу облака, если что ) Они вполне круты для определенного рода задач.
Данное в статье решение, емнип, умещается в free tier амазона, так что сильно волноватся насчет внезапного счёта на пару килобаксов я бы не стал. Хотя если это волнует больше чем аптайм сайта, склонен согласится. Я в данном случае возможно забил бы на редирект с http вообще, ибо не помню где и кто последние пару лет куда либо тыкался по http, тем самым уменьшил риск на перерасход квоты запусков.
Время отдачи самого cloudfront на порядок быстрее чем запуск фукнции, и это то что вы получите при прямом доступе к файлам по https. И это будет более-менее одинаково безотносительно того как далеко юзер от вашего сервера.
Если не рассматривать варианты физического сервера (или кустарщину а-ля подавать сайт с домашнего компа) - альтернативы облаку в данном случае все сами по себе "облачные", будь то vpc-шка в хецнере или что либо другое. Так что для данных требований на сегодняшний день, если ты не организация у которой есть своя платформа для раздачи статики - шило на мыло, а мыло в этом случае означает админить свой сервак. Для дедов у которых конфиги апача от зубов отскакивают - не вопрос. А для тех кто родился после 2000 года - уже не факт ))
И вам придётся таки жёстко поспорить за утверждение что S3 + cloudfront не обгоняют по надёжности сервачок с апачем, даже если его админит сам Линус ))
а прикрутить костыли для гашения всего этого добра, если оно начало жрать финансы, модуля терраформ не нашлось )
terraform destroy
Проблема не гасить, проблема узнать что есть проблема, особенно в амазоне где обновления билинга могут опаздывать аж на сутки, за которы может утечь много воды баксов.
Хотя в целом, если требуется поднять статический сайт хоть как-то за 2 копейки я бы тоже не шёл в амазон а выбрал бы решение где биллинг фиксирован и есть защита от такой ерунды, даже если это будет стоить на пару копеек больше, зато фикс.
да, но только скорость nginx не играет никакой роли если а) у вас тормозной диск, а файлов много и они не влазят в кеш б) если клиент с другой стороны земли и до него сигнал даже со скоростью света, без учета тормозов раутеров, всё равно идет десятки миллисекунд. Скажете это не много? Но в силу особенностей протокола HTTP вам нужно сначала запросить страницу, потом получить ее - вот уже пакет туда и пакет обратно. А потом надо запросить все ресурсы на этой странице (картинки и стили) и снова пакет туда, пакет обратно. Уже 4 раз. Это еще если сессия SSL уже установлена. А если нет - браузер еще должен получить сертификат и сбегать проверить его цепочку. Обычно и сертификаты цепочки - в той же стране.
AWS решает эту проблему наличием датацентров во всех уголках мира, за исключением некоторых стран, напр. России. Врочем, судя по всему, Россия была в планах тоже. Поэтому 30ms на RTT сокращаются до минимума и всё работает быстрее.
И S3 надежнее, конечно, чем одиночный диск, не нужно с этим спорить. И горизонтально масштабируется очень хорошо.
100мс форы, которую дает latency этих CloudFront Functions покроют удаленность клиента от сервера при отсутствии CDN.
Касательно надежности S3, я вот тут нашел SLA амазона на S3 в котором они пишут, что за просадки до 99.9 они вообще никак не отвечают, а за просадки до 99.0 они отвечают 10% платежа. Т.е. получается они официально могут лежать до 40 минут в месяц без штрафов, а за штраф в 10% могут спокойно валяться 7.5 часов каждый месяц. Не сказал бы, что это крутой SLA. Вот тут попсовый beget обещает такой же SLA на свои VPS-ки.
Если что я не хейчу облака или CDN - это важные штуки, но пользоваться ими надо уметь, бездумное использование может приводить к забавным последствиям.
В гугле целый плейлист запилили на несколько часов посмотра на предмет "как не залететь". И это только верхушка айсберга )
У дедов было так:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
</IfModule>
И пачка случайно (или не очень) пришедших ботов отправляет ваш баланс привязанной карты в минус (пока "бесконечно масштабируемое решение" не стукнется о lambda concurrency soft limit)
Статический сайт на AWS с редиректом http→https, www.site→site