Всем привет!

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

Зачем мне личный сайт

Вот основные причины:

• Я всегда хотел записывать свои мысли и делиться знаниями, а личный блог — отличная площадка для этого.
• Английский для меня не родной, поэтому излагать на нем свои мысли — хороший способ улучшить письменную речь и научиться лучше рассказывать истории.
• На личной странице нет ограничений, цензуры и прочих рамок. Территория без бюрократии, где можно все!

Полностью статический сайт

Перейдем к делу. Я решил выбрать самое простое и легкое решение — статический сайт. Почему? Во-первых, это просто, дешево и отлично закрывает основные потребности. Во-вторых, статические сайты хорошо индексируются поисковиками. Наконец, все делается быстро и без лишней боли: на создание и размещение сайта у меня ушло всего несколько часов. Когда стало понятно, что сложное решение мне не нужно, я начал искать подходящий инструмент. Критерии были довольно простыми:

1. Возможность быстро начать писать, не тратя время на настройку громоздкой CMS.
2. Простой и дешевый хостинг без необходимости поднимать сложную инфраструктуру.
3. Хорошо известный язык разметки, желательно Markdown.

О выборе движка для статического сайта написано немало статей: например, обзор на TechRadar или сравнение пяти популярных генераторов. Я прочитал несколько материалов и довольно быстро определился — свайп вправо достался Hugo.

Следующий важный вопрос — где разместить сайт. Для меня ответ был очевиден: статический хостинг в AWS S3. В интернете полно инструкций по его настройке, я воспользовался официальным руководством AWS. Этот этап оказался простым, и вскоре сайт уже открывался по адресу S3.

Делегирование DNS

Затем нужно было передать управление DNS моего домена в Route 53. И тут GoDaddy подкинула небольшую задачку. Я начал с создания публичной зоны для своего домена. В новой зоне есть NS-записи с адресами четырех DNS-серверов, которые нужно указать в панели GoDaddy, чтобы делегировать управление доменом Route 53. Я обновил записи по официальной инструкции. Подождал два дня… Ничего. Попробовал еще раз. И снова ноль, пусто, никаких изменений!

Пришлось обратиться к самому священному источнику знаний человечества — StackOverflow. Неудивительно, что похожих проблем нашлось множество. Причиной оказалась забота GoDaddy о пользователях: возможность менять DNS была спрятана за настройкой для «опытных пользователей». То есть сначала ее нужно было сознательно включить. Ладно, включил.

После делегирования DNS в Route 53 я смог настроить две записи типа A, чтобы мой домен вел на сайт в S3.

Важное замечание

Если вы пользуетесь другими сервисами GoDaddy, например, SMTP для почты на своем домене, не забудьте скопировать остальные DNS-записи или перенести их через экспорт и импорт.

Установка SSL-сертификата через CloudFront

Последним шагом стала установка SSL-сертификата. Добавлять сервер ради этого мне не хотелось, поэтому для шифрования я использовал CloudFront. Сертификат решил выпустить через Let’s Encrypt, довольно известный центр сертификации. Главное преимущество Let’s Encrypt — бесплатные сертификаты, за которые не нужно дополнительно платить AWS. Правда, есть небольшая оговорка: срок действия сертификата всего три месяца. Поэтому каждые три месяца его нужно перевыпускать и заново устанавливать, но эту задачу должно быть несложно автоматизировать.

Есть замечательная инструкция о том, как выпустить сертификат через certbot, инструмент Let’s Encrypt, и установить его в дистрибутив CloudFront.

Важное замечание

Если вы следовали описанным выше шагам, на время работы certbot у вас должна быть возможность отключить политику бакета. Я справился с этим с помощью самого распространенного приема в IT — копирования и вставки. В дальнейшем я собираюсь доработать политику и настроить GitHub Action для обновления сертификата.

В этой инструкции не хватает нескольких небольших деталей настройки CloudFront:

1. Для дистрибутива нужно указать альтернативное доменное имя — Alternate domain name (CNAME).
2. Нужно выбрать свой SSL-сертификат, он появится в выпадающем списке.
3. В качестве объекта по умолчанию — Default root object — нужно указать index.html.

Когда все готово, можно выпить кофе или пива, кому что ближе: CloudFront потребуется от пяти до тридцати минут, чтобы развернуть сайт на пограничных узлах по всему миру. После завершения развертывания я проверил сайт и обнаружил, что ссылки не работают. Понадобился еще один шаг.

Дополнительная настройка Hugo для исправления ссылок

Оказалось, что я далеко не единственный, кого озадачило такое поведение. Причина довольно проста: Hugo не добавляет в конец URL «index.html», то есть прямую ссылку на файл страницы. Решить это можно разными способами: правилом перенаправления в S3, перенаправлением на веб-сервере или через Lambda@Edge.

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

Я быстро применил настройки локально и загрузил сайт в AWS. Как ни странно, проблема осталась. Но вскоре я вспомнил, что еще не обновил кеш CloudFront. После сброса кеша сайт заработал без проблем.

Что можно улучшить

Решение пока не окончательное, но начало положено. В дальнейшем я собираюсь добавить несколько вещей:

1. Настроить GitHub Actions для обновления сертификата через Let’s Encrypt.
2. Автоматизировать загрузку обновленных файлов в бакет S3, чтобы сайт обновлялся после git push.
3. Разрешить доступ к бакету только через CloudFront, то есть правильно настроить OAI.

Продолжение следует!