Pour une première étape avec Docker, j’ai essayé d’installer le logiciel taiga via cet outil de container. La solution la plus classique serait de prendre une image ubuntu et de suivre l’installation de docker (Setup development installation taiga).

Sauf qu’après avoir suivi une formation de Docker, j’ai compris que l’intérêt de Docker ou du moins un intéret est dans les micro service soit d’avoir 5 containers au lieu d’un seul.

NOTE: Vous avez un problème pour impoter votre projet taiga dans taiga (par exemple après une mise à jours) ?

Taiga contient un utilitaire qui se trouve dans le cotnaineur taiga-back et qui permet de faire l’importation suivant cette commande:

/usr/bin/python3 manage.py load_dump dump.json p.jean@mines-ales.fr

Taiga et Docker

Taiga est un logiciel de gestion de projet agile de type assez classique avec kanban et sprint intégré. Ce que j’aime dans Taiga en plus qu’il soit open source est que l’on peut activer ou non les outils agile, par exemple commencé avec un simple kanban et ensuite rajouter des sprint et/ou un wiki et/ou un gestionnaire de bug.

Taiga n’a pas de version officielle de Docker. Plusieurs images sont disponibles mais j’avoue que parfois les personnes qui ont fait les images avaient des idées très précises de leur utilisation qui ne m’allait par.

Dans ma solution je souhaite que Docker puisse gérer les cinq containers avec l’avantage de pouvoir renforcer un container ou le remplacer au besoin :

• taiga-db database postgreSQL
• taiga-front pour la partie front web de Taiga
• taiga-back pour la partie backoffice de Taiga
• taiga-rabbit pour le gestionnaire de message dans Taiga
• taga-events pour l’envoie des notifications dans Taiga via le navigateur
• taiga-proxy pour le serveur front nginx dispatchant les requêtes.

L’image de docker de base

Je pars donc d’une image existante de docker. En fait, j’en essaye plusieurs avant de trouver une image qui correspond à ce que je souhaite soit avec une base de données et avec la partie notifications/messages.

La version suivante : https://github.com/docker-taiga/taiga semble être un bon compromis. Je télécharge donc le dépot github et je fais une installation sans problème sur un serveur linux de test.

Hors, cette installation ne fonctionne qu’une seule fois. Je n’arrive pas en relançant à récupérer le fonctionnement de mon serveur taiga. Après plusieurs essaies et avec l’obligation de devoir intégrer mes propres développements dans Taiga, je suis donc contraint de prépare une installation à partir du fichier docker-compose.yml.

Docker-taiga-pje

Pourquoi faire une version de taiga docker personnelles:

• Je souhaite intégrer 1 fichier et une bibliothèque python en plus.
• Je souhaite débugger avec un outil curl dans taiga-back et taiga-proxy
• Je souhaite que le déploiement se fasse tout seul avec le minimum d’intervention de ma part
• Le container taiga-back contient un serveur web nginx qui fait double emploie pour moi avec le serveur taiga-proxy en frontal
• Monter en compétence avec Docker avec un exemple et des contraintes réelles
• Docker sur Windows 10 avec tout les désavantages que l’on y trouve (et il y en a Docker est fait pour Linux et cela se voit)

La première étape que je vais faire est de créer un dossier pour le taiga-proxy et modifier le code de nginx.conf et nginx_ssl.conf pour que le nginx de ce container aille chercher le http://back:8000/. Cela suppose aussi la modificaiton du docker-compose.yml pour qu’il prenne en charge cette nouvelle image appelée taiga-proxy-pje.

Puis je faire la même modification pour le taiga-back pour qu’il prenne en charge de nouveau modules python et modifier le script de démarrage pour ne pas charger le serveur nginx. J’en profiterai pour que le port 8000 de ce container soit accessible pour faire le débogage avec curl installé dans ce container.

Etape 1 création de l’image taiga-proxy-pje

Téléchargement des fichiers du dépot git-hub depuis https://github.com/docker-taiga/proxy

Version initiale du fichier nginx.conf

server {
	server_name $TAIGA_HOST;
	listen 80;
	location ^~ /events {
		proxy_pass http://$EVENTS_HOST:8888/;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_connect_timeout 7d;
		proxy_send_timeout 7d;
		proxy_read_timeout 7d;
	}
	location ^~ /api {
		include proxy_params;
		proxy_pass http://$TAIGA_BACK_HOST;
	}
	location ^~ /admin {
		include proxy_params;
		proxy_pass http://$TAIGA_BACK_HOST;
	}
	location ^~ /static {
		include proxy_params;
		proxy_pass http://$TAIGA_BACK_HOST;
	}
	location ^~ /media {
		include proxy_params;
		proxy_pass http://$TAIGA_BACK_HOST;
	}
	location / {
		include proxy_params;
		proxy_pass http://$TAIGA_FRONT_HOST;
	}
}

Version modifiée du fichier nginx.conf

Maintenant dans le dossier taiga-pje/proxy en ligne de commande pour construire l’image taiga-proxy-pje :

Il faut ensuite modifier le fichier docker-compose.yml pour ne plus appeler l’image taiga-proxy mais l’image taiga-proxy-pje, donc après avoir téléchargé tous les fichiers du dossier taiga via git

Nous obtenons le dossier suivant:

Nous pouvons donc ensuite modifier le fichier docker-compose.yml:

Pour fabriquer l’ensemble des containers en allant chercher les images, la magie de docker est appeler avec

Pour mémoire, le dossier taiga/ contient le docker-compose.yml qui va faire l’assemblage des images et le dossier proxy contient l’image spéciale docker-proxy-pje.

Rapidement, vous allez faire un fichier go.bat avec:

et un purge.bat qui fait plusieurs actions: retire les fichiers indiquant que ce démarrage n’est pas la version initiale, arrête l’option redémarrage des container pour pouvoir les arrêter :

• retire les fichiers .initial_setup.lock qui indiquent que la configuration a déjà été faite (cf processus de création des fichiers conf ci-dessous)
• mettre à jours le critères restart à no pour me permettre d’arrêter les containers car sinon docker les redémarre automatiquement, vous pouvez aussi faire docker update –restart=np $(docker ps -q) pour empecher tous les containers en fonctionnement de redémarrer
• effacer les containeurs
• effacer les images
• effacer les volumes non utilisé par aucun container, attention cela pourrait retirer aussi d’autres volumes qui ne serait pas lié à des containers

Attention c’est assez violent de retirer tous les volumes non utilisé. Dans mon cas je n’avais que les containers et images liés à taiga.

Processus de créations des fichiers

J’ai eu beaucoup de problème pour comprendre qui fabrique les fichiers dans le dossier taiga/conf. En effet, au premier démarrage des containers taiga-back, taiga-proxy, taiga-front, le script appelé par le RUN (habituellement start.sh) de chaque Dockerfile va créer les dossiers et fichiers de la configuraton pour qu’au redémarrage du container, ces fichiers soient utilisés au lieu de les recréer à chaque fois. Le problème est de créer un processus complet de fabrication et non pas de bricoler dans les fichiers de taiga/conf/. On peut modifier ces fichiers pour tester quelqus réglages de nginx par exemple mais il faut bien qu’à la fin on ai la totalité du processus from scratch

Enfin, j’ai un taiga proxy qui appelle sur le port 8000, le serveur django. Maintenant, il faut configurer le taiga-back pour ne pas utiliser le nginx inclus mais directement le django

taiga-back-pje

Création du dossier back et modification du fichier go.sh

et purge.bat:

Dans notre dossier back, nous allons trouver:

Il faut avec le terminal créer une nouvelle image docker-back que l’on va appeler docker-back-pje.

Cette commande fabrique une nouvelle image de taiga-back. Sauf que sur windows, j’ai une erreur :

WARNING: Ignoring APKINDEX.b89edf6e.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.737f7e01.tar.gz: No such file or directory

Cette erreur vient d’un problème de dossier cache des packages d’alpine.

La solution est de modifier le dockerfile pour détruire ce cache et d’ajouter le package ca-certificates.
Je rajoute aussi le package « jq » pour avoir un outil d’affichage des données json lisible.

Ok cela fabrique l’image, je peux modifier le fichier docker-compose.yml et recréer l’ensemble des images manquantes et des containers associés avec le script go.sh

Sauf que après un petit tour dans le container taiga-back fabriqué à partir de mon image taiga-back-pje

La date est complètement fausse sur Windows

En fait, docker windows ne peut accéder (avec la version que j’avais en mars 2019) à l’horloge système.
Il n’y a pas de problème sous Linux.

Comme j’ai besoins de cette date à jour pour la suite du projet. Je dois injecter un serveur de temps openntpd et le configurer dans l’image docker-back-pje

Nouveaux modifications du fichier Dockerfile

On note qu’il y a une injection de la timezone dans le fichier /etc/timezone pour indiquer le fuseau horaire

Bien sur le fichier ntpd.conf sur le disque dur a ces informations

On peut indiquer d’autres serveurs de temps dans le cas d’une structure qui aurait une politique locale des serveurs de temps

Je suis toujours dessus pour améliorer le processus…