Quoi de mieux que Git pour versionner et synchroniser des fichiers ? Or une installation de Grav n'est rien d'autre qu'un (petit) paquet de fichiers.

Pour vous donner une idée, l'install de base de grav-blog-skeleton, qui a servi de base à ce site, pèse moins de 12 Mo toute mouillée et dézippée. Pour l'essentiel, ce sont des fichiers .yaml pour les configs et .md (markdown) pour vos contenus. Bon, on peut aussi ajouter quelques photos pour faire joli...

Dans le reste de ce post, je retrace la procédure suivie pour garder mon site web synchronisé (ou pas, selon mes envies) avec avec ma machine de développement.

Installation locale

Mon serveur local est un container Docker basé sur l'image nginx, que je lance via le docker-compose suivant (pour être sûr de toujours pointer vers le bon port et de partager le bon volume). Le dossier hôte nommé htdocs est celui qui doit recevoir mon installation Grav.

version: '2'

services:

  portfolio-server:
    image: unitedasian/grav:latest
    ports:
      - 8890:80
        volumes:
      - ../htdocs:/usr/share/nginx/html

Je décompresse Grav dans htdocs. Ceci signifie que les dossiers bin, user et autres, contenus dans l'archive d'installation, se retrouvent directement sous htdocs. Et là, je peux déjà tester que le site est bien servi par mon container Docker.

Edit
Même pas besoin de lancer Docker ! J'ai découvert depuis qu'il suffit d'avoir une installation locale de PHP sur sa machine, avec l'extension php-gd activée. Chez moi, elle se trouve dans C:\tools\php71, où j'ai décommenté la ligne extension=php_gd2.dll de php.ini. Ensuite, je me place à la racine de htdocs et j'exécute la commande : php -S localhost:8000 system/router.php. (Remplacer "8000" par le port de votre choix.) Et voilà, votre site est up !

Etape suivante : je crée un dépôt, d'une part dans htdocs et d'autre part dans GitHub (ou autre — BitBucket a l'avantage d'autoriser gratuitement les dépôts privés). Je les synchronise entre eux.

Installation sur le serveur Web

Sur le serveur web distant (qui tourne sous Ubuntu/Apache), je me place dans /var/www/html et je télécharge Grav :

sudo -u www-data  wget https://getgrav.org/download/core/grav-admin/1.2.4 -O grav.zip

Je le décompresse :

sudo -u www-data unzip grav.zip -d mon-site

Je déplace tout le contenu du dossier mon-site/grav (ou mon-site/grav-admin, ou mon-site/grav-skeleton-blog, selon l'archive téléchargée initialement depuis le site Grav) au niveau supérieur, sans oublier .htaccess, puis je supprime le dossier grav :

sudo mv mon-site/grav-admin/* mon-site
sudo mv mon-site/grav-admin/.htaccess mon-site
sudo rm mon-site/grav-admin/

Je vide le dossier user :

sudo rm -f mon-site/user/*

Je me place dans le dossier mon-site/user et je clone mon dépôt :

cd /mon-site/user
sudo -u www-data git clone <addresse-du-dépôt> .

Comme je n'ai pas envie de devoir revêtir l'identité de www-data chaque fois que je ferai un git pull, je crée un nouveau groupe d'utilisateurs, nommé par exemple grav :

sudo addgroup grav

J'ajoute www-data et moi-même (gdupont) à ce groupe :

sudo adduser www-data grav
sudo adduser pgouin grav

Je règle les droits sur mon-site/user() :

sudo setfacl -R -m g:grav:rwX mon-site/user
find mon-site/user -type d | xargs sudo setfacl -R -m d:g:grav:rwX

Cette manière de gérer les droits agit sur les ACL. Les droits Unix "classiques" deviennent caduques : ne plus se fier aux indications du style drwxrwxr-x+ 3 gdupont gdupont. On remarquera seulement l'ajout du signe + à la ribambelle de caractères : il indique la présence de réglages de permissions supplémentaires : voir ce thread sur serverfault.

Reste à configuer le serveur Apache... Aller dans /etc/apache2/sites-available et dupliquer le fichier 000-default.conf en le renommant, par exemple 01-mon-site.conf.

Pourquoi numéroter les fichiers de conf des VirtualHosts d'Apache ? Prenez mon exemple : sur mon VPS, j'héberge plusieurs blogs. Pour autant, je n'ai pas configuré de VirtualHost pour la racine de mon domaine. Il n'empêche : Apache aiguillera automatiquement tout visiteur qui tape www.pablomalo.fr vers le premier fichier de conf lu. Donc, puisque j'ai pris soin de lui donner le numéro le plus bas, vers portfolio.pablomalo.fr.

Edit : Cette manière de procéder n'est pas idéale si l'on veut générer des certificats SSL avec Certbot, comme expliqué dans cet autre post. En effet, Cerbot ne certifie que les VirtualHosts explicitement configurés. Par conséquent, si on souhaite que l'utilisateur soit connecté en https avec www.pablomalo.fr, mieux vaut lui écrire pour ce sous-domaine un fichier de conf dédié, avant de lancer Certbot. Quitte à faire pointer ce VirtualHost sur le même dossier que portfolio.pablomalo.fr.

Limpide, n'est-ce pas ?

Editer les lignes suivantes du nouveau fichier :

ServerAdmin gdupont@gege.fr``
DocumentRoot /var/www/html/mon-site/
ServerName mon-site.mon-domaine.fr
ServerAlias www.mon-site.mon-domaine.fr

<Directory /var/www/html/mon-site/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

Mettre en service cette configuration :

sudo a2ensite mon-site.conf
sudo a2enmod rewrite
sudo apache2 restart

Nous sommes en ligne !

A ce stade, on doit normalement tomber sur Grav en se connectant à mon-site.fr. (Si vous voulez sécuriser vos transations par SSL, il reste encore une toute petite étape.)

Si la page de mise en route affiche des dépendances manquantes, les installer — par exemple php-gd, php-zip, etc... De même, si la page affiche qu'il manque des sous-dossiers dans htdocs, les créer : ce sont les répertoires qu'on a choisi de ne pas synchroniser, listés dans le .gitignore.

Désormais, un git push côté dev, suivi d'un git pull côté serveur web, doivent suffire à mettre en conformité les deux instances de Grav, locale et distante.

Article suivant Article précédent