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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

variables:
  GIT_SUBMODULE_STRATEGY: recursive

# on definit 2 stages: 
# build qui contient un job  commnun pour générer le site dans le dossier public
# deploy qui contient un job "pages" pour la prod ( branche master ) et un job deploy_staging pour la qualification
stages:
  - build
  - deploy


# le job build execute Hugo et déclare l'artifact public qui sera utilise par les job de deploy
build:
  image: registry.gitlab.com/capedev-labs/docker/hugo-with-git/0-55-6:latest
  stage: build
  script:
    - hugo
  artifacts:
    paths:
      - public

# PROD le job qui déploie le site en prod est simple: il utilise GitLab Pages et fait juste "passe-plat"
# il ne s'execute que sur la master
pages:
  stage: deploy
  script:
    - echo "deploying on prod"
  artifacts:
    paths:
      - public
  only:
    - master
    
# qualification: upload via SFTP du site. Lancé sur la branche staging uniquement 
deploy_staging:
  image: registry.gitlab.com/capedev-labs/docker/alpine-lftp/master:latest
  stage: deploy  
  script:
    # le fichier .htaccess doit contenir le chemin absolu du fichier .htpasswd. Un sed permet de le générer:
    - sed -e "s|@REMOTE_STAGE_FOLDER@|$REMOTE_STAGE_FOLDER|"  htaccess-staging.txt > public/.htaccess
    # le mot de passe crypté
    - echo $STAGE_USER_PASSWORD > public/.htpasswd
    # Gestion de la connexion ssh
    - mkdir ~/.ssh
    # la clé RSA. Ne pas oublier le chmod 600...
    - echo "$ID_RSA"  >  ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa
    # le clé SSH du serveur
    - echo $SERVER_FINGERPRINT >  ~/.ssh/known_hosts
    # on peut pousser sur le serveur distant. 
    - lftp -e "mirror --delete -R  public/ $REMOTE_STAGE_FOLDER;quit;"  -u $FTP_USER, $REMOTE_FTP_URL
  only:
    - staging

Fichiers .htaccess, .htpasswd

Au sujet du contenu des fichiers .htaccesset .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:

1
2
3
4
5

AuthName "Staging blog protected"
AuthType Basic
AuthUserFile "@REMOTE_STAGE_FOLDER@/.htpasswd"
Require valid-user
RewriteEngine on

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.

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…