Dans le précédent article, nous avons détaillé comment déployer un blog sur GitLab avec Hugo. Nous allons désormais explorer 2 solutions pour proposer un site de qualification permettant à une équipe de valider les articles avant publication.
2 solutions proposées:
- Si vous disposez d’un hébergement externe, la solution est de déployer le site sur cet hébergement
- En forkant le projet sur GitLab, il est possible de proposer sans surcoût un site de qualification.
Une des problématiques du sujet concerne la visibilité du site de qualification: ce dernier devrait être en accès restreint pour éviter par exemple le référencement par les moteurs de recherche.
Solution avec un serveur externe
Si vous avez des serveurs disponibles et offrant un accès (S)FTP, il sera possible d’ajouter un job permettant d’uploader le site sur ce serveur. L’accès à ce site sera limité (avec les fichiers de configuration usuels .htaccess
,…) pour éviter que les moteurs de recherche indexent votre site de qualification. Dans notre exemple, le site sera protégé par une authentification basique ( .htaccess
, .htpasswd
).
SFTP
Dans les exemples .gitlab-ci.yml
suivant, une image Docker personnalisée est utilisée: alpine-lftp. Elle permet simplement d’utiliser lftp.
Clé SSH du serveur
Comme nous allons accéder au site externe via SSH, une vérification des clés SSH va être effectuée. Pour des raisons de sécurité, cette fonctionnalité (“strict host key checking”) n’est pas désactivée et vous devrez récupérer la clé de votre serveur via ssh-keyscan -H yourServer.domain.com
.
Clé privé / publique
Pour vous connecter au serveur distant, nous allons utilisé l’authentification par clé. Pour plus d’infos, voir par exemple cette documentation de Fedora-fr. Par la suite, nous supposerons que l’authentification par clé au serveur est opérationnelle
Les variables CI/CD
Plusieurs variables seront nécessaires pour la configuration CI/CD ( à ajouter dans Settings> CI/CD
puis Variables
):
Variable | Description |
---|---|
REMOTE_STAGE_FOLDER | chemin absolu du dossier sur le serveur |
STAGE_USER_PASSWORD | Le mot de passe crypté pour protéger le site de qualification. Voir la doc Apache |
ID_RSA | Clé privée RSA pour connexion au serveur distant. Attention, lors de l’ajout de cette valeur dans les variables CI/CD, une ligne vide doit être ajoutée à la fin. |
SERVER_FINGERPRINT | Clé SSH du serveur |
FTP_USER | utilisateur FTP |
REMOTE_FTP_URL | URL du serveur FTP, soit sftp://.. |
le fichier .gitlab-ci.yml
Dans le cas présenté, 2 branches sont utilisées: une branche staging
déployée sur le site de qualification. Après validation, cette branche sera “mergée” sur la branche master
et le site sera automatiquement mis à jour.
|
|
Fichiers .htaccess
, .htpasswd
Au sujet du contenu des fichiers .htaccess
et .htpasswd
, tout est expliqué dans cette page de OpenClassrooms. Pour générer le contenu du fichier .htpasswd
, vous pouvez utiliser la commande htpasswd -nb username password
sous Linux.
Attention, le fichier .htaccess
doit contenir le chemin absolu du fichier .htpasswd
. Pour cette raison, on part du fichier htaccess-staging.txt
pour générer le fichier .htaccess
.
Le contenu du fichier htaccess-staging.txt
:
|
|
Solution avec GitLab uniquement
Cette deuxièeme solution s’appuie uniquement sur GitLab. L’idée est de “forker” le projet ce qui permet d’avoir une autre URL de test. Cette solution s’appuie complètement sur l’offre de GitLab et est sans surcoût. Par contre, cela demande de gérer un fork et le site de qualification sera visible.
pour l’instant, il n’est pas possible de limiter l’accès aux pages hébergées sur gitlab.com comme expliqué par GitLab Pages Access Control . Vous pouvez suivre la progression de cette action ici.
Le projet support: | https://gitlab.com/hugo-example-staging/hugo-example-staging.gitlab.io |
---|---|
Le site généré: | https://hugo-example-staging.gitlab.io |
Etape 1: créer un groupe
Le fork devra être créé dans un autre groupe. Dans notre cas, on a créé le groupe hugo-example-staging
Etape 2: le fork
On fork le projet initial hugo-example.gitlab.io et on choisit le groupe créé précédemment comme destination:
Etape 3: Changer le slug du projet
Pour déployer le site en tant que site de groupe, le slug doit être correspondre au nom du groupe. On utilise l’action Change path
accessible depuis Settings > General > Advanced
:
Etape 4: Lancer un pipeline et attendre 15 min…
On lance un pipeline CI/CD > Pipelines > Run Pipeline
, le site est généré et il faut simplement attendre (20 minutes) pour qu’il soit accessible.
Le site de qualification est opérationnel
Vous pouvez désormais tester vos modifications sur ce fork. Pour mettre à jour le site principal, une merge request doit être effectuée (menu Merge Requests
). Vérifier que les source/target soient bien renseignées:
Il ne reste plus qu’à accepter le merge depuis le projet principal…