TOC

Comment déployer un site Hugo en production avec Git Hooks sur Ubuntu 14.04

introduction

Hugo est un générateur de site statique qui vous permet de créer et de publier facilement du contenu Web en écrivant dans des langages de balisage simples. Hugo peut analyser votre contenu en fonction des exigences fournies et appliquer un thème afin de générer des pages Web cohérentes pouvant facilement être hébergées sur n’importe quel serveur ou hôte Web.

Dans un https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo-the-static-site-generator-on-ubuntu-14-04 (guide précédent), nous avons couvert comment installer Hugo sur un système Ubuntu 14.04 et l’utiliser pour créer du contenu. Dans ce guide, nous allons vous montrer comment configurer un système avec + git + que vous pouvez utiliser pour déployer automatiquement votre nouveau contenu sur votre serveur Web de production.

Conditions préalables

Pour ce guide, nous supposerons que vous avez une machine Ubuntu 14.04 opérationnelle en tant que votre machine de développement, comme indiqué dans notre https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo. -the-static-site-generator-on-ubuntu-14-04 [Guide d’installation de Hugo].

Nous allons mettre en place un * deuxième * serveur Ubuntu 14.04 pour desservir notre site Web actuel. Sur ce serveur, assurez-vous que vous avez créé un utilisateur non root avec les privilèges + sudo +. Vous pouvez suivre notre https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 (guide de configuration du serveur initial)] pour créer ce compte.

Préparer votre serveur de développement

Nous allons commencer sur notre serveur de développement (le serveur mis en place par le guide Hugo précédent). Connectez-vous à ce serveur en utilisant le même compte non root que vous avez utilisé la dernière fois.

Nous devons faire quelques choses sur ce serveur pour nous préparer à un déploiement en une étape. Nous devons le faire:

  • Configurer l’accès par clé SSH à notre serveur de production

  • Transférer le référentiel + git + initial sur le serveur de production

  • Ajouter le serveur de production en tant que télécommande + git + dans notre référentiel de site

Commençons.

Configurer l’accès par clé SSH au serveur de production

La première chose à faire est de configurer l’accès à la clé SSH entre nos deux serveurs. Cela nous permettra de déployer sans avoir à saisir un mot de passe à chaque fois. Si vous souhaitez être invité à saisir un mot de passe pour chaque déploiement, vous pouvez ignorer cette étape. Certaines personnes aiment garder l’invite du mot de passe pendant le processus de déploiement comme une petite occasion de reconsidérer avant de diffuser du contenu en direct.

Commencez par vérifier si une paire de clés SSH est déjà configurée dans votre compte sur le serveur de développement:

ls ~/.ssh/id_rsa

Si vous récupérez une ligne qui ressemble à ceci, vous n’avez pas encore de paire de clés SSH configurée:

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

Vous pouvez créer la paire de clés manquante en tapant:

ssh-keygen

Appuyez sur ENTREE à travers toutes les invites pour créer une clé sans mot de passe.

Si, au contraire, la commande + ls + vous a donné une ligne qui ressemble à ceci, vous avez déjà une clé dans votre compte:

Output/home/demouser/.ssh/id_rsa

Une fois que vous avez une paire de clés, vous pouvez transférer votre clé publique sur votre serveur de production en la saisissant. Dans la commande, remplacez le nom du compte non root que vous avez configuré sur votre serveur de production lors de la phase des conditions préalables de ce guide:

ssh-copy-id @

Si vous utilisez SSH pour la première fois entre ces deux ordinateurs, il vous sera demandé de confirmer la connexion en tapant «oui». Ensuite, vous serez invité à entrer le mot de passe de l’utilisateur pour le serveur de production. Votre clé publique sera transférée sur le serveur de production, ce qui vous permettra de vous connecter sans mot de passe la prochaine fois.

Testez cette fonctionnalité en demandant le nom d’hôte de votre serveur de production à l’aide de la commande + ssh +:

ssh @ cat /etc/hostname

Vous ne devriez pas être invité à entrer un mot de passe cette fois. Vous devriez recevoir le nom d’hôte de votre serveur de production:

Output

Transférer le référentiel Git initial sur le serveur de production

Ensuite, nous devons transférer un premier clone de notre dépôt Hugo sur notre serveur de production. Nous en aurons besoin pour configurer ultérieurement un hook + post-receive + sur le serveur de production. Pour ce faire, nous devons créer un clone «nu» de notre référentiel + git + et le copier sur notre autre serveur.

Un référentiel nu est un référentiel + git + sans répertoire de travail. Dans les dépôts classiques + git +, vos fichiers de projet sont conservés dans le répertoire principal et les données de gestion de versions + git + sont conservées dans un répertoire caché au sein de + .git +. Un référentiel nu n’a pas de répertoire de travail pour vos fichiers de projet. Par conséquent, les fichiers et répertoires généralement conservés dans le dossier caché + .git + se trouvent plutôt dans le dossier principal. Les pensions nues sont généralement utilisées pour les serveurs distants, car elles simplifient le processus de transfert de contenu.

Nous allons créer un référentiel nu à partir de notre référentiel Hugo principal dans le répertoire + / tmp +. Les pensions nues sont généralement identifiées par un suffixe + .git + de fin. Pour créer cette copie, nous allons utiliser la commande + git clone + avec l’option + - bare +:

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

Nous pouvons transférer ce référentiel nu sur notre serveur de production avec + scp +. Veillez à inclure le ":" à la fin de la commande pour que le référentiel soit placé dans le répertoire de base de notre utilisateur sur le système distant.

scp -r /tmp/ @:

Ajouter une télécommande Git pour le serveur de production

Maintenant que nous avons notre propre référentiel + git + sur notre serveur de production, nous pouvons ajouter le serveur de production en tant que référentiel distant suivi. Cela nous permettra de transférer facilement du nouveau contenu sur notre serveur de production.

Revenez dans votre répertoire Hugo:

cd ~/

Tout ce que nous avons à faire est de choisir un nom pour la télécommande. Dans ce guide, nous utiliserons + prod +. Nous pouvons ensuite spécifier les informations de connexion et l’emplacement de notre référentiel nu sur le système distant:

git remote add prod @:

Vous ne pourrez pas tester cette liaison distante avant l’installation de + git + sur notre serveur de production.

Configuration du serveur de production

Maintenant que notre machine de développement est complètement configurée, nous pouvons passer à la configuration de notre système de production.

Sur notre système de production, nous devons suivre les étapes suivantes:

  • Installez + git +, + nginx et` + pigments`

  • Installer Hugo et les thèmes Hugo

  • Configurez + nginx + pour servir les fichiers depuis un emplacement de notre répertoire personnel

  • Créer un script + post-receive + pour déployer le nouveau contenu envoyé dans notre référentiel

Installer Git, Pygments et Nginx sur le serveur de production

La première chose à faire est d’installer + git +, + pygments + et + nginx + sur le serveur. Bien que notre référentiel de projet soit déjà sur notre serveur, nous avons besoin du logiciel + git + pour recevoir les envois et exécuter notre script de déploiement. Nous avons besoin de + pygments + pour appliquer la coloration syntaxique côté serveur pour tous les blocs de code. Nous utiliserons + nginx en tant que serveur Web qui mettra votre contenu à la disposition des visiteurs.

Mettez à jour l’index du paquet local et installez + git + et + nginx à partir des référentiels par défaut d’Ubuntu. Nous devrons installer + pip +, le gestionnaire de paquets Python, pour récupérer + pygments +:

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

Nous pouvons ensuite utiliser + pip pour installer` + pygments`:

sudo pip install Pygments

Une fois le téléchargement terminé, nous pouvons vérifier que le référentiel distant est correctement configuré sur notre machine de développement. Sur votre * machine de développement *, accédez au répertoire de votre projet Hugo et utilisez la commande + git ls-remote +:

cd ~/
git ls-remote prod

Si + git + peut établir une connexion entre les référentiels de vos machines de développement et de production, il affichera une liste de références, comme celle-ci:

Output103902f5d448cf57425bd6830e544128d9522c51    HEAD
103902f5d448cf57425bd6830e544128d9522c51    refs/heads/master

Installer Hugo sur le serveur de production

De retour sur notre * serveur de production *, nous devons installer Hugo. Au lieu de créer notre contenu sur notre serveur de développement, nous allons créer les actifs statiques sur le serveur de production après chaque + git push +. Pour ce faire, Hugo doit être installé.

Nous pouvons installer Hugo en utilisant la même méthode que celle utilisée pour notre machine de développement. Commencez par vérifier l’architecture de votre serveur de production:

uname -i

Ensuite, visitez la page Hugo. Faites défiler la liste jusqu’à la section «Téléchargements» pour obtenir la dernière version de Hugo. Cliquez avec le bouton droit sur le lien correspondant à votre architecture:

  • Si la commande + uname -i + a produit + x86_64 +, cliquez avec le bouton droit de la souris et copiez le lien se terminant par + amd64.deb +

  • Si la commande + uname -i + a produit + i686 +, cliquez avec le bouton droit de la souris et copiez le lien se terminant par + i386.deb +

Sur votre serveur de production, accédez à votre répertoire personnel et utilisez + wget + pour télécharger le lien que vous avez copié:

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

Une fois le téléchargement terminé, vous pouvez installer le package en tapant:

sudo dpkg -i hugo*.deb

Vérifiez que l’installation a réussi en demandant à Hugo d’afficher son numéro de version:

hugo version

Vous devriez voir une ligne de version affichée, indiquant que Hugo est maintenant disponible:

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

Avant de poursuivre, nous devons cloner les thèmes Hugo sur notre serveur de production:

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

Configurer Nginx pour servir les fichiers produits lors du déploiement

Ensuite, nous devons modifier un peu notre configuration Nginx.

Afin de simplifier notre déploiement, au lieu de placer notre contenu généré dans le répertoire + var / www / html +, celui-ci sera placé dans un répertoire nommé + public_html + dans le répertoire de base de nos utilisateurs.

Continuons et créons le répertoire + public_html + maintenant:

mkdir ~/public_html

Ensuite, ouvrons le fichier de configuration de bloc du serveur Nginx par défaut pour procéder aux ajustements nécessaires:

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

Les seules options à modifier sont les suivantes: + nom_serveur +, qui doit pointer vers le nom de domaine ou l’adresse IP de votre serveur de production et la directive + root +, qui doivent pointer vers le répertoire + public_html + que nous venons de créer:

/ etc / nginx / sites-available / default

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 ;

. . .

Assurez-vous de remplacer «nom d’utilisateur» dans la directive + racine + par votre nom d’utilisateur actuel sur le serveur de production. Enregistrez et fermez le fichier lorsque vous avez terminé.

Redémarrez le serveur Nginx pour appliquer vos modifications:

sudo service nginx restart

Notre serveur Web est maintenant prêt à servir les fichiers que nous avons placés dans le répertoire + public_html +.

Créer un crochet de post-réception pour déployer le site Hugo

Nous sommes enfin prêts à créer notre script de hook de déploiement + post-receive +. Ce script sera appelé chaque fois que vous insérez un nouveau contenu dans le code de production.

Pour créer ce script, nous allons aller dans notre référentiel nu sur notre serveur de production dans un répertoire appelé + hooks +. Déplacer dans ce répertoire maintenant:

cd ~//hooks

Ce répertoire contient quelques exemples de scripts, mais nous avons besoin d’un script + post-receive + pour ce guide. Créez et ouvrez un fichier portant ce nom dans le répertoire + hooks +:

nano post-receive

En haut du fichier, après avoir indiqué qu’il s’agissait d’un script bash, nous commencerons par définir quelques variables. Nous allons définir + GIT_REPO + sur notre référentiel nu. Nous allons le cloner dans un référentiel temporaire spécifié par la variable + WORKING_DIRECTORY + afin que Hugo puisse accéder au contenu qu’il contient pour construire le site actuel. Le répertoire themes de notre référentiel + git + étant en fait un simple lien symbolique pointant vers un emplacement du répertoire parent, nous devons nous assurer que le clone du répertoire de travail est créé au même emplacement que les thèmes Hugo que nous avons téléchargés.

Le dossier Web public sera spécifié par la variable + PUBLIC_WWW + et un dossier Web de sauvegarde restera accessible via la variable + BACKUP_WWW +. Enfin, nous allons définir + MY_DOMAIN + avec le nom de domaine ou l’adresse IP publique de notre serveur:

Dans cet esprit, le début de votre fichier devrait ressembler à ceci:

~ / my-website.git / hooks / post-receive

#!/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=

Après avoir défini nos variables, nous pouvons commencer par la logique de notre script. Nous allons d’abord utiliser la commande + set -e + de bash pour spécifier que le script doit se terminer immédiatement s’il rencontre des erreurs. Nous allons utiliser cela pour nettoyer en cas de problème dans un instant.

Ensuite, assurons-nous que notre environnement est configuré pour notre déploiement. Nous souhaitons supprimer tout répertoire de travail existant, car nous souhaitons cloner une nouvelle copie lors du déploiement. Nous souhaitons également sauvegarder notre répertoire Web afin de pouvoir restaurer en cas de problème. Nous utilisons + rsync + ici car il gère les répertoires vides et les répertoires avec un contenu plus cohérent que + cp +. Assurez-vous que vous incluez le + / + suivant «+ $ PUBLIC_WWW +` de fin afin que la commande soit analysée correctement.

Une dernière procédure de configuration que nous allons faire est de définir la commande + trap + pour répondre au cas où un signal de «sortie» serait reçu. Puisque nous avons inclus la commande + set -e +, un signal de sortie se produira chaque fois qu’une commande de notre déploiement échoue. Dans ce cas, les commandes spécifiées par l’interruption restaurent notre copie de sauvegarde dans le répertoire Web et suppriment toute instance du répertoire + git + de travail.

~ / my-website.git / hooks / post-receive

#!/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

Nous pouvons maintenant commencer notre déploiement. Nous allons créer un clone régulier de notre repo nu afin qu’Hugo puisse accéder au contenu du repo. Nous supprimerons ensuite tout le contenu du répertoire Web public afin que seuls les nouveaux fichiers soient disponibles dans le répertoire Web public. Ensuite, nous utiliserons Hugo pour construire notre site. Nous allons le diriger vers notre nouveau clone en tant que répertoire source et lui indiquer de placer le contenu généré dans le dossier Web public. Nous allons également lui transmettre la variable contenant le nom de domaine ou l’adresse IP de notre serveur de production afin qu’il puisse créer correctement des liens.

Une fois que Hugo aura construit le contenu, nous supprimerons le répertoire de travail. Nous réinitialiserons ensuite la commande + trap + afin que notre copie de sauvegarde n’écrase pas immédiatement notre nouveau contenu lorsque le script tente de quitter:

~ / my-website.git / hooks / post-receive

#!/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

À ce stade, notre script est terminé. Enregistrez et fermez le fichier lorsque vous avez terminé.

Il ne reste plus qu’à rendre le script exécutable de sorte que + git + puisse l’appeler au moment opportun:

chmod +x post-receive

Notre système de déploiement est maintenant complet. Laissez-le tester.

Tester le système de déploiement

Maintenant que notre système est configuré, nous pouvons le tester.

Commençons par tester votre script de hook + post-receive. Cela nous permettra de renseigner notre répertoire + ~ / / public_html + avec une première copie de notre contenu Web. Cela vous aidera également à vérifier que les principaux composants du script fonctionnent comme prévu:

bash ~//hooks/post-receive

Cela devrait exécuter votre script et afficher les messages normaux + git + et Hugo à l’écran:

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

Si vous visitez le nom de domaine ou l’adresse IP de votre serveur de production dans votre navigateur Web, vous devriez voir la version actuelle de votre site:

http://

image: https: //assets.digitalocean.com/articles/hugo_deployment_1404/initial_site.png [Etat initial du site Hugo]

Nous pouvons maintenant revenir à la machine que nous utilisons pour le développement de Hugo. Sur cette machine, créons un nouveau message:

hugo new post/Testing-Deployment.md

Dans le nouvel article, il suffit de mettre un peu de contenu pour que nous puissions tester notre système:

~ / mon-site / content / post / 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!

Ajoutez maintenant le contenu à + ​​git + et validez les modifications:

git add .
git commit -m 'Deployment test'

Maintenant, si tout se passe comme prévu, nous pouvons déployer nos nouvelles modifications simplement en poussant notre serveur de production:

git push prod master

Maintenant, si vous visitez à nouveau votre site de production dans un navigateur Web, vous devriez voir le nouveau contenu:

http://

image: https: //assets.digitalocean.com/articles/hugo_deployment_1404/new_content.png [Nouveau contenu Hugo]

Notre système de déploiement semble fonctionner correctement.

Conclusion

Dans ce guide, nous avons créé un serveur de production distinct, dédié à la fourniture de notre contenu Web aux visiteurs. Sur ce serveur, nous avons installé et configuré plusieurs composants afin qu’Hugo puisse correctement créer et servir notre contenu. Nous avons ensuite créé un script de déploiement qui est déclenché chaque fois que nous envoyons un nouveau contenu sur le serveur à partir de notre ordinateur de développement.

Les mécanismes réels impliqués dans notre système de déploiement sont plutôt basiques. Cependant, ils forment la base d’un système facile à entretenir pour obtenir votre contenu local sur votre serveur Web rapidement et sans douleur. Le processus de déploiement étant automatisé, vous n’avez pas besoin d’interagir avec votre serveur pour apporter des modifications autres qu’un simple + git push +.

Related