TOC

Как развернуть сайт Hugo в производство с помощью Git Hooks в Ubuntu 14.04

Вступление

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

В previous guide мы рассмотрели как установить Hugo в систему Ubuntu 14.04 и использовать его для создания контента. В этом руководстве мы покажем вам, как настроить систему с + git +, которую вы можете использовать для автоматического развертывания нового контента на вашем рабочем веб-сервере.

Предпосылки

В этом руководстве мы предполагаем, что у вас есть машина Ubuntu 14.04, запущенная и работающая в качестве машины разработки, как описано в нашем https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo -the-static-site-generator-on-ubuntu-14-04 [Руководство по установке Hugo].

Мы будем настраивать * второй * сервер Ubuntu 14.04 для обслуживания нашего реального рабочего сайта. На этом сервере убедитесь, что вы создали пользователя без полномочий root с правами + sudo +. Чтобы создать эту учетную запись, воспользуйтесь нашим https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 руководстве по настройке начального сервера].

Подготовка вашего сервера разработки

Мы начнем с нашего сервера разработки (сервер, настроенный с помощью предыдущего руководства Hugo). Войдите на этот сервер, используя ту же учетную запись без полномочий root, которую вы использовали в прошлый раз.

Нам нужно сделать несколько вещей на этом сервере, чтобы настроить его для одношагового развертывания. Мы должны:

  • Настройте SSH Key Access на наш производственный сервер

  • Перенесите исходный репозиторий + git + на рабочий сервер

  • Добавьте производственный сервер как удаленный + git + в нашем репозитории сайта

Давайте начнем.

Настройка доступа по SSH-ключу к производственному серверу

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

Сначала проверьте, настроена ли в вашей учетной записи пара ключей SSH на сервере разработки:

ls ~/.ssh/id_rsa

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

Outputls: cannot access /home/demouser/.ssh/id_rsa: No such file or directory

Вы можете создать отсутствующую пару ключей, набрав:

ssh-keygen

Нажмите клавишу ВВОД во всех запросах, чтобы создать ключ без пароля.

Если, с другой стороны, команда + ls + дала вам строку, которая выглядит следующим образом, у вас уже есть ключ в вашей учетной записи:

Output/home/demouser/.ssh/id_rsa

Если у вас есть пара ключей, вы можете передать свой открытый ключ на рабочий сервер, набрав его. В этой команде замените имя учетной записи без полномочий root, которое вы настроили на своем производственном сервере на этапе предварительных требований для этого руководства:

ssh-copy-id @

Если вы впервые используете SSH между этими двумя компьютерами, вам будет предложено подтвердить соединение, введя «да». После этого вам будет предложено ввести пароль пользователя для производственного сервера. Ваш открытый ключ будет передан на рабочий сервер, что позволит вам в следующий раз войти без пароля.

Проверьте эту функциональность, запросив имя хоста вашего рабочего сервера с помощью команды + ssh +:

ssh @ cat /etc/hostname

На этот раз вам не нужно будет вводить пароль. Вы должны получить обратно имя хоста для вашего производственного сервера:

Output

Перенос начального Git Repo на производственный сервер

Затем нам нужно перенести начальный клон нашего репозитория Hugo на наш производственный сервер. Это понадобится нам для того, чтобы позже установить хук + post-receive + на производственном сервере. Для этого нам нужно создать «голый» клон нашего репозитория + git + и скопировать его на наш другой сервер.

Пустой репозиторий - это специальный репозиторий + git + без рабочего каталога. В обычных репозиториях + git + файлы вашего проекта хранятся в главном каталоге, а данные контроля версий + git + хранятся в скрытом каталоге внутри, называемом + .git +. В пустом репозитории нет рабочего каталога для файлов вашего проекта, поэтому файлы и каталоги, которые обычно хранятся в скрытой папке + .git +, находятся в основной папке. Голые репозитории обычно используются для удаленных серверов, потому что это упрощает процесс загрузки контента.

Мы создадим пустое хранилище из нашего основного репозитория Hugo в каталоге + / tmp +. Голые репозитории обычно обозначаются конечным суффиксом + .git +. Чтобы создать эту копию, мы будем использовать команду + git clone + с опцией + - bare +:

git clone --bare ~/ /tmp/.git

Мы можем перенести этот пустой репозиторий на наш рабочий сервер с помощью + scp +. Обязательно добавьте в конце команды завершающий символ «:», чтобы репозиторий был помещен в домашний каталог нашего пользователя на удаленной системе.

scp -r /tmp/ @:

Добавьте Git Remote для производственного сервера

Теперь, когда у нас есть наше репозиторий + git + на нашем рабочем сервере, мы можем добавить рабочий сервер в качестве отслеживаемого удаленного репозитория. Это позволит нам легко загружать новый контент на наш производственный сервер.

Вернитесь в свой каталог Hugo:

cd ~/

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

git remote add prod @:

Вы не сможете проверить эту удаленную ссылку до тех пор, пока мы не установим + git + на наш рабочий сервер.

Настройка производственного сервера

Теперь, когда наша машина для разработки полностью настроена, мы можем перейти к настройке нашей производственной системы.

В нашей производственной системе нам необходимо выполнить следующие шаги:

  • Установите + git +, + nginx и` + пигменты`

  • Установить Хьюго и темы Хьюго

  • Сконфигурируйте + nginx для обслуживания файлов из нашего домашнего каталога

  • Создайте скрипт + post-receive + для развертывания нового контента, отправляемого в наш репозиторий.

Установите Git, Pygments и Nginx на рабочий сервер

Первое, что мы должны сделать, это установить на сервере + git +, + pygments + и + nginx +. Хотя наш репозиторий проектов уже находится на нашем сервере, нам необходимо программное обеспечение + git + для получения запросов и выполнения нашего сценария развертывания. Нам нужно + pygments +, чтобы применить подсветку синтаксиса на стороне сервера для любых блоков кода. Мы будем использовать + nginx в качестве веб-сервера, который сделает ваш контент доступным для посетителей.

Обновите локальный индекс пакета и установите + git + и + nginx из репозиториев Ubuntu по умолчанию. Нам понадобится установить + pip +, менеджер пакетов Python, чтобы получить + pygments +:

sudo apt-get update
sudo apt-get install git nginx python-pip

Затем мы можем использовать + pip + для установки + pygments +:

sudo pip install Pygments

После завершения загрузки мы можем проверить, правильно ли мы настроили удаленный репозиторий на нашей машине для разработки. На вашей * машине разработки * перейдите в каталог проекта Hugo и используйте команду + git ls-remote +:

cd ~/
git ls-remote prod

Если + git + может установить соединение между репозиториями на ваших компьютерах разработки и производства, он отобразит список ссылок, например так:

Output103902f5d448cf57425bd6830e544128d9522c51    HEAD
103902f5d448cf57425bd6830e544128d9522c51    refs/heads/master

Установите Hugo на рабочий сервер

Вернувшись на наш * рабочий сервер *, нам нужно установить Hugo. Вместо того чтобы строить наш контент на нашем сервере разработки, мы будем создавать статические ресурсы на рабочем сервере после каждого + git push +. Для этого нам нужно установить Хьюго.

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

uname -i

Затем посетите страницу Hugo релизов. Прокрутите вниз до раздела «Загрузки» для самой последней версии Hugo. Щелкните правой кнопкой мыши ссылку, соответствующую вашей архитектуре:

  • Если команда + uname -i + создала + x86_64 +, щелкните правой кнопкой мыши и скопируйте ссылку, заканчивающуюся на + amd64.deb +

  • Если команда + uname -i + создала + i686 +, щелкните правой кнопкой мыши и скопируйте ссылку, заканчивающуюся на + i386.deb +

На рабочем сервере перейдите в домашний каталог и используйте + wget +, чтобы скачать скопированную ссылку:

cd ~
wget https://github.com/spf13/hugo/releases/download/

После завершения загрузки вы можете установить пакет, набрав:

sudo dpkg -i hugo*.deb

Проверьте, что установка прошла успешно, попросив Хьюго показать номер версии:

hugo version

Вы должны увидеть строку версии, показывающую, что Hugo теперь доступен:

OutputHugo Static Site Generator v0.14 BuildDate: 2015-05-25T21:29:16-04:00

Прежде чем двигаться дальше, нам нужно клонировать темы Hugo на наш производственный сервер:

git clone --recursive https://github.com/spf13/hugoThemes ~/themes

Настройте Nginx для обслуживания файлов, созданных во время развертывания

Далее нам нужно немного изменить нашу конфигурацию Nginx.

Чтобы упростить наше развертывание, вместо помещения сгенерированного контента в каталог + var / www / html +, контент будет помещен в каталог с именем + public_html + в домашнем каталоге нашего пользователя.

Давайте продолжим и создадим каталог + public_html + прямо сейчас:

mkdir ~/public_html

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

sudo nano /etc/nginx/sites-available/default

Единственные опции, которые нам нужно изменить, это + server_name +, который должен указывать на доменное имя или IP-адрес вашего производственного сервера и директиву + root +, которая должна указывать на каталог + public_html +, который мы только что создали:

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       root ;
       index index.html index.htm;

       # Make site accessible from http://localhost/
       server_name ;

. . .

Убедитесь, что вы заменили «username» в директиве + root + реальным именем пользователя на рабочем сервере. Сохраните и закройте файл, когда вы закончите.

Перезапустите сервер Nginx, чтобы применить ваши изменения:

sudo service nginx restart

Наш веб-сервер теперь готов обслуживать файлы, которые мы помещаем в каталог + public_html +.

Создайте хук после получения для развертывания сайта Hugo

Теперь мы, наконец, готовы создать ваш сценарий хука развертывания + post-receive. Этот скрипт будет вызываться всякий раз, когда вы добавляете новый контент в производственный код.

Чтобы создать этот сценарий, мы перейдем в наш пустой репозиторий на нашем производственном сервере в каталог с именем + hooks +. Перейдите в этот каталог сейчас:

cd ~//hooks

В этом каталоге довольно много примеров сценариев, но для этого руководства нам понадобится сценарий + post-receive +. Создайте и откройте файл с таким именем в каталоге + hooks +:

nano post-receive

В верхней части файла, указав, что это скрипт bash, мы начнем с определения нескольких переменных. Мы установим + GIT_REPO + в наше пустое хранилище. Мы будем клонировать это во временный репозиторий, указанный в переменной + WORKING_DIRECTORY +, чтобы Хьюго мог получить доступ к содержимому внутри, чтобы построить реальный сайт. Поскольку каталог тем в нашем репозитории + git + на самом деле является просто символической ссылкой, указывающей на местоположение в родительском каталоге, мы должны убедиться, что клон рабочего каталога создан в том же месте, что и загруженные нами темы Hugo.

Общедоступная веб-папка будет указываться переменной + PUBLIC_WWW +, а резервная веб-папка будет оставаться доступной через переменную + BACKUP_WWW +. Наконец, мы установим + MY_DOMAIN + для доменного имени или публичного IP-адреса нашего сервера:

Учитывая это, начало вашего файла должно выглядеть примерно так:

~ / Мой-website.git / Крючки / после приема

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

После установки наших переменных мы можем начать с логики нашего скрипта. Во-первых, мы будем использовать команду bash + set -e +, чтобы указать, что скрипт должен завершиться немедленно, если он обнаружит какие-либо ошибки. Мы будем использовать это для очистки в случае возникновения проблем в данный момент.

После этого давайте удостоверимся, что наша среда настроена для нашего развертывания. Мы хотим удалить любой существующий рабочий каталог, так как мы хотим клонировать свежую копию во время развертывания. Мы также хотим сделать резервную копию нашего веб-каталога, чтобы мы могли восстановить, если что-то пойдет не так. Мы используем + rsync + здесь, потому что он обрабатывает пустые каталоги и каталоги с содержимым в них более последовательно, чем + cp +. Убедитесь, что вы добавляете завершающий + / + после + $ PUBLIC_WWW +, чтобы команда была правильно проанализирована.

Одна из последних процедур настройки, которую мы сделаем, - это установка команды + trap + для ответа в случае получения сигнала «выход». Поскольку мы включили команду + set -e +, сигнал выхода будет появляться всякий раз, когда команда в нашем развертывании завершается неудачно. В этом случае команды, указанные ловушкой, восстановят нашу резервную копию в веб-каталоге и удалят любой экземпляр рабочего каталога + git +.

~ / Мой-website.git / Крючки / после приема

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred.  Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

Теперь мы можем начать наше развертывание. Мы создадим обычный клон нашего репо, чтобы Хьюго мог получить доступ к его репо. Затем мы удалим все содержимое из общедоступного веб-каталога, чтобы в общедоступном веб-каталоге были доступны только свежие файлы. После этого мы будем использовать Hugo для создания нашего сайта. Мы укажем его на наш новый клон в качестве исходного каталога и скажем ему разместить сгенерированный контент в общедоступной веб-папке. Мы также передадим ему переменную, содержащую имя домена или IP-адрес нашего производственного сервера, чтобы он мог правильно создавать ссылки.

После того, как Хьюго соберет контент, мы удалим рабочий каталог. Затем мы сбросим команду + trap +, чтобы наша резервная копия не сразу перезаписывала наш новый контент, когда скрипт пытается завершиться:

~ / Мой-website.git / Крючки / после приема

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred.  Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

git clone $GIT_REPO $WORKING_DIRECTORY
rm -rf $PUBLIC_WWW/*
/usr/bin/hugo -s $WORKING_DIRECTORY -d $PUBLIC_WWW -b "http://${MY_DOMAIN}"
rm -rf $WORKING_DIRECTORY
trap - EXIT

На этом наш сценарий закончен. Сохраните и закройте файл, когда вы закончите.

Все, что нам нужно сделать сейчас, это сделать скрипт исполняемым, чтобы + git + мог вызвать его в соответствующее время:

chmod +x post-receive

Наша система развертывания завершена. Давайте проверим это.

Проверьте систему развертывания

Теперь, когда мы настроили нашу систему, мы можем ее протестировать.

Давайте начнем с тестирования вашего скрипта хука + post-receive. Это позволит нам заполнить наш каталог + ~ / public_html + начальной копией нашего веб-контента. Это также поможет убедиться, что основные компоненты скрипта работают должным образом:

bash ~//hooks/post-receive

Это должно запустить ваш скрипт и вывести на экран обычные сообщения + git + и Hugo:

OutputCloning into '/home/justin/my-website-working'...
done.
0 draft content
0 future content
4 pages created
0 paginator pages created
0 tags created
1 categories created
in 26 ms

Если вы посещаете доменное имя или IP-адрес рабочего сервера в своем веб-браузере, вы должны увидеть текущую версию своего сайта:

http://

изображение: https: //assets.digitalocean.com/articles/hugo_deployment_1404/initial_site.png [исходное состояние сайта Hugo]

Теперь мы можем вернуться к машине, которую мы используем для разработки Hugo. На этой машине давайте создадим новый пост:

hugo new post/Testing-Deployment.md

В новом посте просто добавьте немного контента, чтобы мы могли протестировать нашу систему:

~ / Мой-сайт / содержание / должность / Testing-Deployment.md

+++
categories = ["misc"]
date = "2015-11-11T16:24:33-05:00"
title = "Testing Deployment"

+++

## A Test of the New Deployment System

I hope this works!

Теперь добавьте содержимое в + git + и передайте изменения:

git add .
git commit -m 'Deployment test'

Теперь, если все идет по плану, мы можем внедрить наши новые изменения, просто нажав на наш производственный сервер:

git push prod master

Теперь, если вы повторно посетите свой производственный сайт в веб-браузере, вы должны увидеть новый контент:

http://

изображение: https: //assets.digitalocean.com/articles/hugo_deployment_1404/new_content.png [Уго новый контент]

Кажется, наша система развертывания работает правильно.

Заключение

В этом руководстве мы настроили отдельный производственный сервер, предназначенный для предоставления посетителям нашего веб-контента. На этом сервере мы установили и настроили несколько компонентов, чтобы Hugo могла правильно создавать и обслуживать наш контент. Затем мы создали сценарий развертывания, который запускается каждый раз, когда мы отправляем новый контент на сервер с нашего компьютера для разработки.

Фактические механизмы, задействованные в нашей системе развертывания, довольно просты. Однако они составляют основу простой в обслуживании системы для быстрого и безболезненного получения локального контента на веб-сервере. Поскольку процесс развертывания автоматизирован, вам не придется взаимодействовать с вашим сервером, чтобы вносить изменения, кроме простого + git push +.

Related