URL: https://linuxfr.org/users/linkdd/journaux/projet-diy-d-integration-continue-auto-hebergee Title: Projet DIY d'intégration continue auto-hébergée Authors: David Delassus Date: 2017年11月13日T08:24:23+01:00 License: CC By-SA Tags: python, docker, intégration_continue et selfhost Score: 24 Alors voilà le topo, je me suis monté une infrastructure auto-hébergée contenant : - stockage de fichier (nextcloud) - mail (postfix/dovecot/...) et webmail (roundcube) - git (gogs) - annuaire ldap (openldap) pour tout le monde - ... Le tout basé sur du container docker, sur un Kimsufi (40Go de disque, 4Go de RAM). Je voulais exécuter les TU/TF de mes projets (qui sont sur le gogs) sans passer par un service externe (CircleCI, TravisCI, Codeship, ...) qui serait potentiellement payant pour mes projets privés. J'ai du coup regardé côté Travis, on a une petite 10aine de container docker pour lancer l'infra, pas top le serveur est déjà assez charger. Après, je sais qu'il y a Jenkins. Mais parlons de manière totalement subjective, je ne suis pas fan de ce qui est fait en Java généralement (surtout pour un serveur qui a déjà 3Go de conso de RAM sur les 4Go totaux). Puis survient un manque de motivation à faire une recherche google pour trouver une solution qui saura me satisfaire. Je me dis alors "ça doit pas être si compliqué que ça à faire quand même ?". Aller, de quoi on a besoin ? - un serveur HTTP qui pour recevoir les requêtes POST de la webhook de Gogs - un daemon qui va recevoir les demandes d'exécution de job - une UI web pour voir l'avancement, l'historique, les logs et le résultat des jobs - une base de données pour stocker tout ça - un host docker pour créer le container qui va exécuter le job Au niveau des technos, ça donne donc : - serveur HTTP en Python/Flask - Python/celery pour l'exécution des jobs : - pygit2 pour cloner le dépôt - les bindings python de docker pour run le container docker - l'UI ultra minimaliste servie par le serveur HTTP, basée sur materialize - pyDAL pour la BDD -> https://github.com/web2py/pydal Le déroulement est simple : - je push dans mon dépôt, ce dernier contient un fichier ``.microci.json`` qui spécifie l'image docker à utiliser et la commande à lancer - gogs envoi la requếte POST - le handler sauvegarde le job dans la BDD puis demande à celery d'exécuter la tâche de lancement du job - le job passe du status ``PENDING`` à ``STARTED`` - on clone le dépôt git - on créé le container docker, et on bind le dépôt git dans le ``/repo`` du container - la commande du container est celle spécifiée dans le ``.microci.json`` du dépôt - si la commande retourne un code d'erreur égal à 0, le job passe à ``SUCCEED``, sinon ``FAILED`` - si une exception est levée à une des étapes précédentes, le job passe à ``ERRORED`` Voilà, moins d'une journée consécutive passé dessus et j'obtiens un petit outil de CI fait maison : https://github.com/linkdd/microci Attention néanmoins : - il n'y a pas d'authentification, je la gère au niveau du reverse proxy nginx - aucun audit de sécurité n'a été effectué, l'outil tourne en interne uniquement sur des projets privés (c'est pas une raison valable cela-dit) J'ai quand même prévu d'ajouter une webhook pour Github, Gitlab et Bitbucket, mais c'est vraiment pas dans mes priorités pour l'instant. J'ai publié le projet sous licence MIT pour les curieux, je ne m'attends pas à ce que ce dernier serve à quelqu'un cela-dit (m'enfin, on ne sait jamais). Sur ce, bonne semaine à tous!