Netlify и Amazon Cloudfront
Возникли мысли о децентрализации используемых ресурсов. На текущий момент времени все сайты и все используемые сервисы у меня размещаются на одном сервере. И если возникнет проблема с ним, я теряю сразу все. Мало того, что теряю в сервисах, так еще и восстанавливать их на другом сервере проблематично. Задумался.
Во-первых, нужно перенести сайты с сервера. Только куда? Статический сайт можно разместить по сути где угодно, тут и Github Pages и Netlify и Amazon S3. Не считая еще массы других вариантов. Сперва перенес визитку на Github Pages, вспомнил о том, что здесь нет возможности управлять кешированием страниц. И по умолчанию он задается довольно коротким. Для непопулярного сайта, типа моих это нормально. Но хочется же большего.
Перенес сначала визитку, а затем и сайт на Netlify. Понравилось то, что сделать это крайне просто. Достаточно подключить репозиторий к сервису, задать команду сборки и указать директорию с результатом. Для того, чтобы управлять кешированием и редиректами можно или задать отдельные файлы конфигурации в результирующей директории сайта. Или же создать единый файл конфигурации для Netlify в корне репозитория.
Несколько недель тестировал поведение сайтов. Давно уже настроен непрерывный момниторинг. И как только появляются проблемы с доступом, тут же в ящик падает письмо. К чему это я? К тому, что за эти недели возникали ситуации, когда сайт был просто недоступен. Пусть не надолго, но мое доверие они потеряли. В чем сложность хостить простенький статический сайт? И из-за чего возникают такие проблемы??
К тому же возникли проблемы со стандартными редиректами, типа с одного протокола на другой. Или с теми редиректами, что задавал, то есть с корневого домена на www. Периодически возникали ситуации, когда время ответа от сервера достигал от 5 до 10 секунд. Время ответа сервера, задумайтесь!
Подумал и решил попробовать в очередной раз Amazon. Стоимость небольшая. Есть масса разработок по деплою результатов сборки. Ранее у меня возникали проблемы только с кешированием. И после деплоя нужно было проводить инвалидацию страниц сайта, чтобы пользователи получили доступ к новой версии. В этот раз решил попробовать задать TTL равным нулю. Как оказалось это решило проблемы с кешированием. Каждый запрос адресовался напрямую в S3, и каждый раз бралась актуальная версия.
В итоге экспериментов сайты перенес на Amazon. Размещаются в S3, раздаются с помощью Cloudfront, DNS-зона в Route 53. Деплой производиться с помощью Travis по комиту в репозиторий, все в автоматическом режиме. И таким образом работа сайтов теперь не зависит от работосопосбности моего сервера.