Github Pages

30 January 2019 #jekyll#github#cloudfront

В марте 2011 года я начал использовать Jekyll для своего сайта: Сменил wordpress на jekyll

Для деплоя своего сайта на сервера Амазона долгое время использовал s3_website. Очень функциональный gem, много чего умеет, но имеющий один довольно неприятный недостаток. Для его использования необходимо иметь как ruby, так и java, так как в его коде используются groovy скрипты.

Ну используется, и что такого, спросите вы? Проблема заключается в поддержании рабочего окружения в актуальном состоянии. И к примеру, при обновлении версии ruby мы уже не сможем так же просто поднять версию java. Более того, как оказалось, s3_website не поддерживает версии java выше 8-й. И именно этот gem создавал мне массу неудобств.

В субботу, после того, как попытался опубликовать Ссылки #10, оказалось, что я допустил ошибку в заголовке статьи, что сломало сборку. Не сразу разобравшись в чем дело, доломал сайт окончательно, выведя из строя тот самый s3_website за счет обновления используемой версии Ruby. В конце концом мне надоело решать проблемы с s3_website, и я его просто заменил на стандартный gem деплоя в Travis, что использовался для сборки сайта. Проблема была устранена, но в результате на сервера Амазона попала ломанная версия сайта и при этом была закеширована там на сутки.

Потратил еще несколько часов на решение создавшейся проблемы, но, что странно, даже инвалидация объектов в CloudFront не выводила объекты из кеша. Решился на миграцию сайта к другому хостеру. Только какому? Создавать свой сервер для статического сайта не хотелось, других вариантов не просматривалось. Мигрировать на s3, с потерей ssl тоже не хотелось. И тут вспомнил про Github Pages.

Изменить деплой с Travis на Github Pages заняло порядка 5 минут, плюс еще 10 на чтение документации. И уже через 15 минут чистого времени получил работающий сайт на серверах Github. В тот же день провел несколько экспериментов по использовании Github в качестве сборщика сайта, в замен Travis, но как оказалось, мой сайт к этому на тот момент времени еще не был готов. Причина в том, что Github Pages не поддерживают source отличную от текущей директории. И в результате работы сборщика Github в корне своего сайта наблюдал html-вариант README файла из репозитория.

Сборка в Travis всего сайта занимала порядка 2 минут, включая деплой. В то же время при комитах на Github при включенном Pages предупреждения получал уже спустя несколько секунд. То есть сборка на Github проводиться гораздо быстрее. Оно и понятно, окружение используется одно и то же для всех сайтов, и не нужно каждый раз при комитах готовить окружение заново, устанавливая каждый раз полный набор зависимостей. Несколько дней потратил на изменение структуры сайта, приводя его к виду, необходимому к использованию в Github Pages без использования сторонних сборщиков. При этом добивался того, чтобы в корне сайта оставалось как можно меньше файлов. В результате получилась следующая структура: juev/juev.org.

И на текущий момент времени сборка и размещение сайта полностью лежит на стороне Github. Проводил тесты по измерению web page performance, результаты довольно хорошие, не смотря даже на то, что в Github Pages очень ограниченное время кеширования ваб-страниц. Для “персонального” сайта вполне оптимально, на мой взгляд.

Если ищете вариант размещения своего сайта, то рассмотрите Github Pages, мои рекомендации.