Le dépôt pour le service gogs sur Docker Swarm est en ligne

Cet article a été publié il y a 6 ans 4 mois 4 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Voilà, après plusieurs soirées et matinées à pleurer pour maîtriser les modules et mettre en forme potable les fichiers et le code liés à l’histoire de ma première expérience de Docker Swarm, j’ai décidé de publier le tout sur GitHub, qui est, vous vous en doutez, un miroir du dépôt gogs privé. Je pense qu’il va aussi être intéressant de détailler les raisons du décalage dans la publication.

En soi la partie Gogs est ultra simple et c’est surtout la partie maison, la mise à jour de DNS, qui m’a pris le plus de temps à mettre au propre. Je vous donne tout de suite l’adresse du dépôt, si vous souhaitez consulter son historique pour suivre cet article au cas où ça ne serait pas assez parlant.

Une image initiale beaucoup trop grosse (et c’était pas le seul problème)

Mes choix de départs étaient fonctionnels, mais vraiment pas optimisés. Pour les plus curieux qui fouilleront les logs git, vous verrez à quel point c’était dégueulasse. En soi la partie gestion de l’API OVH n’était pas affreuse, mais pour récupérer l’hôte sur lequel le service tourne, je passais par subprocess et lançais la commande docker directement. Ce qui impliquait de l’installer en même temps que les autres morceaux dont j’avais besoin.

Moralité, l’image de base pesait 157Mo, pour exécuter un script Python d’une trentaine de lignes. Pire encore, si j’ai dès le départ pris le pli d’exporter la configuration des credentials pour l’API, tout le reste était géré en dur dans le code : nom du service, zone DNS, sous-domaine, et même la liste des membres du cluster avec leur IP. Non vraiment y’a pas grand chose à sauver de ce script.

Le Dockerfile lui-même n’était pas le plus optimisé du monde, avec trois commandes RUN successives pour :

• mettre à jour le dépot
• installer docker
• installer le module ovh via pip

Sachant que pour chaque RUN il crée une image intermédiaire sur laquelle il s’appuie pour le RUN suivant. Ouais c’est pas dingue, mais c’est mon premier Dockerfile en même temps. Vous comprendrez que j’avais envie de faire les choses un peu plus proprement, autant pour vous que pour moi d’ailleurs.

Des choix un peu plus pertinents, mais qui demandent plus de maîtrise

Donc, mon premier réflexe a été de m’interroger sur le poids de cette fameuse image, un problème que j’avais déjà formulé lors de mon premier cas d’usage personnel de Docker avec wpscan (d’ailleurs un commentateur éclairé avait présenté les choses différemment et améliorait grandement le dossier). En cherchant, il s’avère qu’il existe un module Docker pour Python, et un test rapide de construction montre une taille de seulement 63,4Mo une fois les choses réglées. Une sacrée amélioration, qu’il sera compliqué de pousser plus loin.

Restait à savoir s’en servir. Et ça a été une purge croyez-moi, j’ai souffert, je sais que ça ne sera probablement pas la dernière fois, d’autant plus que la documentation est particulièrement peu accessible pour un débutant. Là où on peut directement sélectionner et récupérer les infos d’un service avec la cli docker en une seule commande, il aura fallu pas mal d’itérations et d’échecs successifs pour arriver à un résultat fonctionnel, qui vous le conviendrez, n’est pas des plus esthétiques et pourrait peut-être mériter un peu plus de lisibilité de ma part.

Il y aurait je pense encore pas mal de boulot pour faire quelque chose de définitivement carré. Dans l’immédiat, c’est déjà je pense suffisamment organisé et généralisé pour que vous l’adaptiez un peu facilement à votre cas d’usage.

Enfin, pour le Dockerfile, il ne reste plus que les installations de modules Python, qui se fait en un seul RUN. On gagne donc deux étapes, ce qui permet de gagner du temps et des images intermédiaires. Toujours pratique quand on voit que même sur une connexion locale, le temps de génération et d’upload sur un registry privé peut s’avérer d’une lenteur que je n’explique toujours pas.

Vous n’aurez pas forcément L’Alsace et la Lorraine tous les dépôts

J’ai décidé de publier celui-ci car la part de « créativité » le justifiait à mes yeux. Mais certains dépôts qui vont contenir les descriptions d’autres services qui tourneront sur le cluster ne seront que des légères adaptations de ce qu’on pourrait trouver à portée d’une recherche sur n’importe quel moteur, alors ne vous attendez pas non plus à une profusion de partages.

Mais évidemment, si la « valeur ajoutée » se justifie sur un autre de mes projets, je n’en parlerai certes peut-être pas sur le blog, mais surveillez GitHub, on sait jamais. J’ai également un compte sur Framagit (créé à l’occasion d’une légère implication sur lufi), un jour qui ne sera pas fait comme un autre j’ajouterai peut-être une ligne sur mes hooks pour rebalancer les infos là-bas aussi, histoire d’avoir une deuxième version publique de ce que je décide de partager.