Упрощение публикации статического сайта

О недостатках Jekyll мы уже говорили, теперь давайте рассмотрим, как можно перенести процесс генерации сайта на рабочий сервер.

Во-первых, сделать это можно и совершенно бесплатно. Достаточно размещать код своего сайта на Github, а генерацию производить с использованием Travis CI , с последующей публикацией результата на Github Pages.

Во-вторых, если используется свой сервер, можно генерировать сайт непосредственно с его помощью. Это вариант сейчас и рассмотрим.

Post-Receive Hooks

Для оповещения сервера о проведенных изменениях в репозитории кода используется Post-Receive Hooks . Довольно долго и безрезультатно пытался найти что-нибудь работоспособное для использования триггеров, пока наконец, не наткнулся на разработку Александра Соловьева под названием Webhooker . Устанавливаем Golang:

$ sudo apt-get install python-software-properties  # 12.04
$ sudo add-apt-repository ppa:duh/golang
$ sudo apt-get update
$ sudo apt-get install golang
$ echo 'export GOPATH=$HOME' >> ~/.profile
$ echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.profile

Теперь устанавливаем сам Webhooker:

$ go get github.com/piranha/webhooker

По привязке webhooker к nginx есть описание на официальной странице приложения, поэтому в данной статье я останавливаться на этом моменте не буду. Расскажу лишь об автоматизации запуска Webhooker при старте системы. Александр предлагает использовать для запуска и мониторинга его состояния работы Supervisor . Но я нашел использование Upstart в Ubuntu наиболее приемлемым вариантом, тем более, что он сейчас используется в системе по умолчанию.

Необходимо создать файл конфигурации /etc/init/webhook.conf в котором прописываем всего несколько строк:

description "Webhook for Gihub"

start on startup
stop on shutdown

console none
respawn

exec su usename -c "~/bin/webhooker -p 5010 -i 127.0.0.1 -c ~/hooks/webhook.conf"

Теперь для запуска достаточно дать команду:

$ sudo start webhook

Для остановки:

$ sudo stop webhook

Файл ~/hooks/webhook.conf я использую для описания правил работы триггеров, и если правило всего одно, его можно прописывать непосредственно в строке запуска. На данный момент в файле ~/hooks/webhook.conf у меня одна строка:

Juev/juev.ru:master='/home/username/hooks/juevru.sh'

Александр задумывал использовать триггеры для запуска нескольких команд максимум, и при этом использует для запуска командный интерпретатор sh. А так как у меня на сервере используется Ruby, установленный с использованием rbenv, то приходиться запускать целый скрипт, в котором помимо запуска команд, необходимо еще установить рабочее окружение:

#!/bin/bash
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

cd ~/Projects/juev.ru
git pull
rake
rsync -az --delete public/ ~/web/juevru/

Хочу обратить внимание на тот факт, что генерация сайта производиться во временной директории. И только по окончанию работы осуществляется синхронизация этой временной директории с рабочим каталогом веб-сайта с использованием команды rsync. Это позволяет избежать моментов отсутствия страниц на сайте во время генерации.

Теперь для публикации статьи достаточно будет получить доступ к веб-браузеру, в котором с использованием веб-редактора файлов создаем статью, а публикация будет проведена автоматически после сохранения результатов работы.

Единственная проблема, которая остается при использовании Jekyll – это работа с изображениями. Влад Гороховский предложил вариант решения в статье Автоматизация обработки картинок , но он использует для этого одновременно несколько довольно дорогих программ, что делает публикацию возможной только при использовании своего компьютера, что не всегда возможно.

Но уже сейчас работать с Jekyll стало гораздо проще.