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.jsonqui 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
/repodu container - la commande du container est celle spécifiée dans le
.microci.jsondu dépôt - si la commande retourne un code d'erreur égal à 0, le job passe à
SUCCEED, sinonFAILED - 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!
# DroneCI ?
Posté par Cheuteumi . Évalué à 4.
Ça donne quoi DroneCI niveau intégration ? Ça se base aussi sur Docker tout ça.
[^] # Re: DroneCI ?
Posté par flan (site web personnel) . Évalué à 2.
Merci pour l'info, ça a l'air intéressant mais encore un peu jeune :( Dans mon cas, il manquerait au moins l'authentification HTTP et le packaging en .deb, mais je garde sous le coude.
[^] # Re: DroneCI ?
Posté par Cheuteumi . Évalué à 3. Dernière modification le 14 novembre 2017 à 09:53.
Pour le packaging ce n’est pas embêtant puisqu’il tourne dans Docker :)
Pour l’authentification HTTP, tu peux utiliser un reverse proxy. Apache est bien fourni en modules d’authenth, tu pourras le brancher sur un LDAP/AD assez facilement.
# gitlab CI ?
Posté par dzecniv . Évalué à 10.
salut, et Gitlab CI ? Tu peux l'auto héberger au besoin.
[^] # Re: gitlab CI ?
Posté par François GUÉRIN (Mastodon) . Évalué à 3.
… c'est ce que je fait, et c'est super bien, avec en prime une forge très complète et configurable aux petits ognons…
En plus, j'utilise les dockerd de plusieurs machines, chaque image est assez minimaliste (python:3.5-jessie), les dépendances sont installées par le script de CI. (.gitlab-ci.yml)
# RAM versus time?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Pourquoi ne pas étendre la RAM de ce serveur? En attendant les effets des ordonnances, ça coute encore infiniment moins cher que du temps de travail.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Docker, Gitlab, ...
Posté par karchnu . Évalué à 2.
N'y a-t-il rien de plus simple, réellement, pour faire de l'intégration continue ? Nécessiter Gitlab ou même "que" Docker me semble déjà assez complexe en soit.
[^] # Re: Docker, Gitlab, ...
Posté par Cheuteumi . Évalué à 3.
Et que veux tu mettre au lieu de Docker, ou même LXC, pour isoler tes builds ?
Docker, on en dira ce qu’on voudra en prod, pour du dev et des tests, c’est juste extrêmement pratique, léger (pour peu que les images le soient et qu’on ai pas déféqué dans la colle sur le déploiement de son produit) et pratique : il gère la partie système, la seule chose qu’on a à faire c’est d’exécuter notre code, et c’est précisément ce qui nous intéresse.
Avec LXC on est plus proche d’un "vrai" système mais la mise en place est un poil plus lourde, à savoir la conf par défaut, les rootfs, les fichiers de conf des conteneurs, ton bridge réseau et le dnsmasq…
Quand l’objectif est d’avoir des builds dont on est sûr qu’il ne tournent pas grâce à un fichier oublié lors du précédent build, Docker c’est parfait.
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . Évalué à 1.
C'est précisément la question. :)
LXC et Docker sont des solutions très centrées sur Linux. Pour ma part je n'utilise pas (ou peu) Linux. Je préfère me renseigner sur une solution un poil plus générique qui tournerait sur tous les UNIX.
De nos jours, nous avons des systèmes de fichier qui savent gérer des snapshots (lire "une copie d'un répertoire qui coûte rien en temps et en volume de stockage occupé"), ce qui pourrait largement nous aider à créer des rootfs pour un millier de builds sans que cela n'occupe vraiment plus de place qu'avec du Docker. Du coup un "simple" chroot (ou solution équivalente) serait envisageable. Peut-être que ce ne serait pas suffisant, mais tellement plus simple et générique… Docker au fond n'est qu'une abstraction à une solution de ce type, mais en utilisant des fonctionnalités disponibles uniquement sur Linux, et un fonctionnement loin d'être intuitif. Tout ça pour pas avoir à faire un pont réseau, gérer des IP et un le DNS soit-même ?
[^] # Re: Docker, Gitlab, ...
Posté par Cheuteumi . Évalué à 1. Dernière modification le 13 novembre 2017 à 15:27.
Si Docker ne tourne pas sur autre chose que Linux c’est uniquement qu’ils n’ont pas fais en sorte que ça puisse utiliser les jails BSD par exemple.
Les snapshots FS je veux bien, mais les FS sont aussi relativement liés au système. ZFS existe bien sur Linux, donc c’est vrai qu’on peut imaginer pouvoir faire de la portabilité via ZFS… mais alors dans ce cas on oublie Windows ?
Pour l’instant il n’y a pas de solution magique, enfin, si, avec de la grosse VM… c’est moins léger tout d’un coup.
Et je t’assure que pour être dans une équipe de devs ne connaissant pas l’admin, ne pas savoir ce qu’il se passe au niveau système, c’est nécessaire. Chacun son métier, sans condescendance aucune, vraiment, tout le monde n’a pas toutes les connaissances sur tout, et avant tout, on a des sous à faire rentrer avant de se soucier de la portabilité de tel ou tel système de build.
Si quelqu’un veut créer un tel système, franchement ça sera avec grand plaisir, en attendant bah on a besoin d’outils avec lesquels on peut travailler et non devoir s’en occuper pour qu’ils puissent travailler.
En deux mots : la portabilité c’est cool, mais avant ça j’aimerais pouvoir bosser sur ce qui m’importe vraiment avant de m’occuper de la beauté du système qui me fait le café.
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . Évalué à 1.
J'ai demandé si quelqu'un connaissait un système de build qui se passe de Docker. Que dans ton entreprise le choix s'est porté sur Docker c'est très bien… mais hors sujet. Peu importe les arguments.
[^] # Re: Docker, Gitlab, ...
Posté par Cheuteumi . Évalué à 1.
Je répondais à cette question. Maintenant si tu veux pas discuter…
[^] # Re: Docker, Gitlab, ...
Posté par kg7 . Évalué à -1.
Regarde peut-être du coté de Bazel et Nix
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . Évalué à 2.
Bazel fonctionne que pour un ensemble très restreint de langages et ne fonctionne pas sur BSD (d'ailleurs il suppose par défaut que bash est installé et est dans /bin… ça a l'air bien codé ce truc) donc pour la généricité, on repassera.
Et à côté de ça, Nix, un gestionnaire de paquets. Je ne comprends pas en quoi il répond à la question. J'ai raté un truc ? :-D
[^] # Re: Docker, Gitlab, ...
Posté par kg7 . Évalué à 0.
Concernant Bazel, je ne connais pas bien mais j'avais eu l'impression que ca pouvait builder n'importe quoi. Mais c'est fort probable que je me trompe.
Nix permet de builder une application, de passer des tests et de produire qq chose (un binaire, une image Docker, un qcow, …) de manière (plus ou moins) isolée sans utiliser Docker. Par contre, il me semble que ca ne fonctionne pas sur BSD.
# Intercepter les webhooks sans artillerie lourde
Posté par Yth (Mastodon) . Évalué à 3.
Je dis sans artillerie lourde, mais bon, c'est pour appâter le chaland.
En fait j'ai fait ça avec une version modifiée de bashttpd, donc que du shell derrière, selon le hook appelé on exécute tel ou tel script et hop !
On a besoin de connaître le bash pour modifier bashttpd, et de screen/tmux ou un autre truc du genre (qui ne se fasse pas tuer par systemd si on utilise une distrib qui y est passé) pour faire tourner le serveur.
Yth, et ça tourne toujours…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.