TLDR

• On crée une paire de clés publique/privée RSA pour SSH,
• on ajoute la clé publique au fichier ~/.ssh/authorized_keys sur son Perso,
• on ajoute la clé privée encodée dans une variable masquée et cachée SSH_PRIVATE_KEY sur Gitlab,
• on crée un fichier .gitlab-ci.yml pour compiler/exécuter le projet (on utilise perso3.runner.iiens.net et non perso3.iiens.net pour se connecter en SSH),
• on lance notre job et on constate si cela bien été transféré.

Contexte

Mon dépôt Gitlab pour le ++ de LaTeX (https://git.iiens.net/lucas2023/iiepp-latex) est de plus en plus fourni ! Il possède plusieurs fichiers de tests et des templates, et je souhaitais permettre aux utilisateurs de consulter les PDF des templates et exemples sans devoir cloner le dépôt en local pour ensuite compiler tous les exemples.

Pendant mon stage de deuxième année, mon maître de stage m'a introduit l'intégration continue. Cette fonctionnalité est très intéressante quand on développe un produit, notamment pour vérifier entre plusieurs commits si le projet qu'on développe vérifie bien toujours les tests unitaires, par exemple. Dans mon cas, cela me permet de générer des PDF LaTeX entre chaque push sur la branche main fait sur Gitlab.

À terme, je souhaitais pouvoir :

• créer les PDF entre chaque gros push,
• les rendre accessible facilement sur Internet.

Voyons alors comment cela est possible.

Utiliser l'intégration continue

Clés publique/privée RSA

Nous rendrons possible le transfert des PDF grâce à une connexion SSH entre Gitlab et le Perso. On va donc créer une paire de clés publique/privée RSA pour se connecter en SSH.

Création de la paire de clés publique/privée RSA

On se connecte sur son Perso :

ssh nomXXXX@perso3.iiens.net

Une fois connectée, nous créerons dans le dossier .ssh la paire de clés publique/privée.

Dans un souci de sécurité, nous encoderons puis décoderons la clé privée. La raison qui nous pousse à faire cela sera détaillée ci-après.

Assurez-vous que le nom soit suffisamment clair pour vous permettre par la suite d'identifier la paire de clés que vous aurez créé.

mkdir -p ~/.ssh
ssh-keygen -t rsa -b 4096 -f .ssh/gitlab_runner_monProjet_rsa

On vous demandera alors si vous souhaitez ajouter une passphrase. N'en ajoutez pas en appuyant sur Entrée deux fois.

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/gitlab_runner_monProjet_rsa
Your public key has been saved in .ssh/gitlab_runner_monProjet_rsa.pub
...

Autoriser l'accès au Perso grâce à la clé publique

À présent, copiez le contenu du fichier .ssh/gitlab_runner_monProjet_rsa.pub pour l'ajouter dans le fichier .ssh/authorized_keys.

cat .ssh/gitlab_runner_monProjet_rsa.pub >> .ssh/authorized_keys

Ajouter la clé privée sur Gitlab

RAPPEL | NE PARTAGEZ PAS VOTRE CLÉ PRIVÉE !!!

Pensez à vider votre presse-papier par précaution quand vous aurez fini cette manipulation.

À présent, on encode la clé privée présente sur notre Perso que nous enregistrerons ensuite dans une variable Gitlab.

cat .ssh/gitlab_runner_monProjet_rsa | base64 -w0

Copiez alors le résultat dans votre presse-papier.

Allez maintenant sur votre dépôt git.iiens.net en ligne.

Sélectionnez Settings, puis CI/CD. Allez dans Variables. Dans la section Visibility, sélectionnez l'option Masked and hidden. Dans la section Flags, sélectionnez l'option Protect variable et désélectionnez l'option Expand variable reference. Ajoutez, si vous le souhaitez, une description pour vous aider à vous souvenir de l'intérêt de cette variable. Dans la section Key, mettez SSH_PRIVATE_KEY. Enfin, dans la section Value, ajoutez le résultat de la commande précédente (votre clé privée encodée).

Fichier .gitlab-ci.yml

À présent, nous devons donner les instructions à Gitlab pour que ce dernier puisse exécuter toute la pipeline qui nous permet de générer nos fichiers.

Cet article n'étant pas un tutoriel d'utilisation de l'intégration continue de Gitlab, je donne directement le fichier .gitlab-ci.yml que j'utilise pour mon cas d'utilisation avec une très brève explication de ce qu'il se passe.

stages:
  - build
  - deploy

# Toute cette partie consiste à dire "tu vas compiler et créer mon PDF avec les fichiers sources présents dans le dossier 'src' dans un conteneur, puis tu garderas en mémoire le fichier 'src/main.pdf' pour la suite"
build-pdf:
  stage: build
  image: registry.gitlab.com/islandoftex/images/texlive:latest  # use a Docker image for LaTeX
  script:
    - cd src
    - make
  artifacts:
    paths:
      - src/main.pdf

# Toute cette partie consiste à dire "voilà ta clé privée, décode-la, puis envoie mon PDF sur mon Perso"
deploy-job:
  stage: deploy
  only:
    - main
  before_script:
    - eval $(ssh-agent -s)
    - mkdir -p ~/.ssh
    # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
    - echo "$SSH_PRIVATE_KEY" | base64 -d > ~/.ssh/id_rsa
    - chmod u=rw,go= ~/.ssh/id_rsa
    - ssh-add ~/.ssh/id_rsa
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  script:
    - scp src/main.pdf nomXXXX@perso3.runner.iiens.net:~/html/rapport.pdf

Notez que la copie du fichier se fait via l'adresse perso3.runner.iiens.net et non perso3.iiens.net.

C'est un problème particulier aux services d'ARISE à l'heure actuelle (problème que vous n'aurez pas si vous utilisez gitlab.com) dont il n'y a pas vraiment d'explication sur le pourquoi ça marche comme ça.

L'idée est que, comme les runners sont utilisés dans le réseau interne d'ARISE, l'IP publique ne serait donc pas accessible par ces derniers, d'où le fait qu'on utilise plutôt l'IP privée donnée par perso3.runner.iiens.net. Nous retiendrons alors que tout cela est possible grâce à l'écosystème d'ARISE ! :)

Conclusion

À présent que tout est bien configuré comme il faut, on push notre fichier .gitlab-ci.yml, et on constate si le runner s'exécute bien.

Résultat

Si tout s'est bien passé, alors on peut alors accéder au PDF généré avec le lien https://nom.iiens.net/rapport.pdf.