Octopress предоставляет несколько способов публикации собранного сайта на удаленный сервер. Лично мне больше всего подходит использование Rsync, поскольку мой сайт размещен на собственном хостинге, а не на Github’e или, не приведи Господи, Heroku. Ниже я кратко опишу процесс настройки публикации сайта на удаленный сервер с использованием rsync и команды rake deploy, включая некоторые подводные камни этого процесса.

Настраиваем работу Rsync через SSH

Настройки публикации сайта находятся в Rakefile в разделе Rsync Deploy config. Поэтому первым делом идем туда и вводим свои настройки:

ssh_user       = "username@domain.ru"
ssh_port       = "22"
document_root  = "/path/to/site/root/"
rsync_delete   = true
deploy_default = "rsync"

После установки настроек в Rakefile необходимо озаботиться тем, чтобы в процессе публикации удаленный сервер не спрашивал у нас пароля пользователя username, от имени которого мы и будем осуществлять логин на удаленный сервер во время публикации. Если вас не смущает ввод пароля каждый раз при публикации новой заметки или если у вас уже настроена авторизация через, скажем, rsa-ключи, можете смело пропустить следущий раздел.

Генерация пары ключей

Процесс описывается для связки Mac (локальная машина) + Ubuntu 10.10 (удаленный сервер), однако, всё будет работать и на более поздних версиях Ubuntu. Сперва генерируем пару ключей. В зависимости от того, какая версия протокола используется на вашем удаленном сервере, необходимо генировать подходящие ключи.

Генерация ключей RSA

Для наших целей подойдет самая простая пара ключей с настройками по-умолчанию. Для этого набираем в терминале локальной машины:

ssh-keygen

В результате работы получаем:

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/developer/.ssh/id_rsa): username_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in username_rsa.
Your public key has been saved in username_rsa.pub.

Нам предлагается ввести имя файла (я ввел username_rsa), а также ввести passphrase (я не вводил, это не обязательно, кроме того, passphrase можно добавить к ключу позже при помощи команды ssh-keygen -p), которая повышает уровень защиты ключей. Если при запросе имени файла просто нажать enter, создастся пара ключей с именами по-умолчанию id_rsa. Однако я не рекомендую оставлять имя файла по-умолчанию, потому что при генерации следующей пары ключей с именем по-умолчанию старые ключи перезапишутся и станут непригодны к использованию.

В результате будут созданы пара ключей в директории ~/.ssh с именами (в моем случае) username_rsa и username_rsa.pub. Файл username_rsa содержит в себе секретный ключ и не должен передаваться кому-либо. Файл username_rsa.pub содержит в себе публичный ключ и может быть передан на удаленный сервер.

Генерация ключей DSA

Update: Внимание! ключи DSA в настоящее время считаются уязвимыми, не используйте их!

Процесс генерации ключей DSA весьма похож на генерацию ключей RSA:

ssh-keygen -t dsa

В результате работы получаем:

Generating public/private dsa key pair.
Enter file in which to save the key (/Users/developer/.ssh/id_dsa): username_dsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in username_dsa.
Your public key has been saved in username_dsa.pub.

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

В этом случае создалась пара ключей username_dsa и username_dsa.pub, первый является секретным ключом, второй - публичным.

Помещаем публичные ключи на удаленный сервер

Для того, чтобы общаться с удаленным сервером без запроса авторизации пользователя, в директории ~./ssh удаленного сервера создается файл authorized_keys для ключей RSA и файл authorized_keys2 для ключей DSA. Далее содержимое файлов публичных ключей добавляется в конец указанных файлов.

Предположим, что у нас есть файлы username_rsa.pub и username_dsa.pub, содержащие публичные ключи. Скопируем их на удаленный сервер (находясь при этом в директории ~./ssh) в директорию ~/.ssh удаленного сервера:

scp username_rsa.pub username@hostname.ru:/username/.ssh
username_rsa.pub     100%  624     0.6KB/s   00:00 
scp username_dsa.pub username@hostname.ru:/username/.ssh
username_dsa.pub     100%  624     0.6KB/s   00:00

Далее заходим на удаленный сервер по ssh с вводом пароля, идем в директорию ~/.ssh и создаем файлы authorized_keys и authorized_keys2, если их там еще нет:

touch authorized_keys
touch authorized_keys2

Далее меняем права доступа к этим файлам, чтобы к ним не мог доступиться кто попало:

chmod 600 authorized_keys
chmod 600 authorized_keys2

Далее копируем содержимое файлов публичных ключей в созданные нами файлы authorized_keys и authorized_keys2:

cat username_rsa.pub >> authorized_keys
cat username_dsa.pub >> authorized_keys2

Обратите внимание, содержимое файла username_dsa.pub дописывается в конец файла authorized_keys2 поскольку это ключ DSA! Более файлы публичных ключей нам не нужны, поэтому можем их удалить:

rm username_rsa.pub
rm username_dsa.pub

Почти все готово! Теперь для логина по SSH к удаленному серверу достаточно набрать:

ssh -1 -v username@hostname.ru

или

ssh -2 -v username@hostname.ru

Обратите внимание! Вам достаточно создать только одну пару ключей - RSA или DSA - в зависимости от того, какая версия поддерживается вашим удаленным сервером. Я привел описания процесса для двух пар ключей исключительно для того, чтобы можно было выбрать нужный вариант.

Update: В настоящее время authorized_keys2 считается depricated и не используется. Вместо него используется authorized_keys.

Использование собственного имени пары ssh-ключей

Однако, если вы проделали все в точности согласно описанной процедуре, залогиниться вам не удастся. Дело в том, что при создании файлов ключей с именем, отличным от имени по умолчанию (id_rsa, id_dsa), при попытке логина ssh ищет именно файлы с именами по-умолчанию. Для использования выбранных вами кастомных имен (в нашем примере это username_rsa и username_dsa) совместно с rsync, вам необходимо создать на локальной машине в директории ~/.ssh файл config (touch config), в котором задать для вашего удаленного хоста свой IdentityFile, например:

Host 66.77.44.99
IdentityFile ~/.ssh/username_dsa

При использовании нестандартного порта для SSH (отличного от порта 22), в config можно задать этот порт.

После этого вам удастся зайти на удаленный хост по SSH с использованием команды:

ssh -2 -v username@66.77.44.99

Настроив доступ к удаленному серверу через SSH с использованием пары шифрованных ключей, мы можем использовать rsync, на которой базируется команда публикации сайта на удаленный сервер rake deploy.

Публикуем сайт через Rsync

Все готово для публикации сайта через rsync. Для публикации сайта наберите в терминале (находясь в директории octopress):

rake generate   # Генерируем блог, если еще этого не сделали
rake deploy     # Синхронизируем блог через SSH

При выполнении этой команды Ваша директория public будет синхронизирована с удаленным сервером.

Настройка rsync delete

Если в вашем Rakefile значение rsync_delete равно true, rsync будет создавать полную копию вашей public директории на удаленном сервере, включая создание, обновление и удаление страниц и заметок. Иными словами, если на локальной машине вы удалили заметку, она исчезнет и на удаленном сервере при следующем rake deploy.

Если вы не хотите, чтобы какие-либо локальные файлы передавались при деплое на сервер, вам необходимо создать файл rsync-exclude в корневую директорию вашего проекта, содержимое этого файла может быть таким:

some-file.txt
some-directory/
*.mp4

Использование rsync-exclude предотвратит передачу на сервер указанных в нем файлов, а также при включенном rsync_delete удаление на удаленном сервере файлов, перечисленных в rsync-exclude.

Источники

При написании данной заметки были использованы следующие источники, которые рекомендуются к прочтению для углубленного изучения вопроса, либо при возникновении проблем в процессе использования представленного описания настроек rsync: