Benoît Courtine



    Navigation
     » Accueil
     » A propos
     » Mentions légales
     » XML Feed

    Déploiement du blog avec Gitlab-CI

    11 Mar 2019 (MAJ le 11/03/2019 à 21:58) » jekyll, script

    Au début…​

    La première version de ce blog statique était mise en production manuellement :

    • Construction et test du site en local, sur ma machine de développement.

    • Déploiement du site construit via rsync.

    Pour les besoins d’un blog perso, ça suffit amplement. Cependant, ce blog servant également à faire des tests, je voulus aller plus loin.

    Déploiement continu V1

    Ce blog étant initialement hébergé sur un beau serveur dédié Dedibox, il y avait la place pour d’autres services. Entre autres, Gitorious et Jenkins.

    La premier script de déploiement continu fut donc l’occasion de tester (et d’approuver) les pipelines.

    Plus tard, le code fut migré vers Bitbucket, un des premiers hébergeurs à proposer des dépôts privés gratuitement. Le pipeline de déploiement a été conservé sur Jenkins.

    Vers Gitlab

    D’autres offres existent :

    • La dernière en date, Github propose depuis peu des dépôt privés gratuits.

    • Gitlab également, avec en plus 2000 heures mensuelles de calcul sur des instances Gitlab Runner partagées.

    C’est cette dernière option qui m’a convaincu de migrer l’hébergement des sources du blog. Elle m’a également fourni un remplaçant plus simple au pipeline Jenkins de déploiement continu. L’existence de ce remplaçant a aidé à la décision d’abandonner la Dédibox.

    Il ne restait plus qu’à écrire le script de déploiement .gitlab-ci.yml. Je me suis pour cela inspiré de la documentation et des posts de Philippe Charrière.

    Déploiement continu d’un site Jekyll via SSH
    image: ruby:2.6
    
    stages:
    - build
    - deploy
    
    variables:
      JEKYLL_ENV: production
      LC_ALL: C.UTF-8
    
    cache: (1)
      paths:
      - /vendor
    
    before_script:
      - gem install bundler
      - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )' (2)
    
    build:
      stage: build
      script:
      - bundle install --path=/vendor
      - bundle exec jekyll build -d blog
      artifacts: (3)
        paths:
        - blog
    
    deploy:
      stage: deploy
      script:
      - mkdir .ssh
      - chmod 700 .ssh
      - echo $KNOWN_HOSTS > .ssh/known_hosts (4)
      - eval $(ssh-agent -s)
      - echo "$SSH_PRIVATE_KEY" | ssh-add -
      - "scp -r blog $BLOG_USER@$BLOG_SERVER:" (5)
      dependencies: (3)
      - build
      only:
      - master
    1 L’utilisation du cache permet de conserver les gems d’un build au suivant.
    2 Précaution non nécessaire pour cette image, qui contient déjà ssh-agent.
    3 La déclaration d’un artefact dans une étape de build permet de réutiliser celui-ci dans une étape ultérieure, via une dépendance.
    4 Utilisation des secrets Gitlab : les variables définies dans le projet sont injectées lors de l’exécution du script.
    5 rsync est plus adapté, mais n’est pas installé par défaut dans l’image ruby.

    Avec ce pipeline, le site est construit à chaque push sur Gitlab, et la branche master déployée automatiquement.

    Conclusion

    Ce nouveau script de déploiement me donne plainement satisfaction, en particulier pour sa simplicité : un seul service (Gitlab) gère le code, l’intégration continue, et le déploiement.

    Une alternative aurait pu être d’utiliser Cloudbess Codeship. Mais cette solution aurait nécessité un service supplémentaire. C’est la raison pour laquelle je me suis plutôt orienté vers Gitlab, dont j’apprécie la simplicité et l’approche "tout en un".