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
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:8000;
}
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;
}
}
Maintenant dans le dossier taiga-pje/proxy en ligne de commande pour construire l’image taiga-proxy-pje :
docker build -t 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
git clone –depth=1 -b latest https://github.com/docker-taiga/taiga.git
Nous obtenons le dossier suivant:
Nous pouvons donc ensuite modifier le fichier docker-compose.yml:
version: ‘3’
services:
back:
image: taiga-back
container_name: taiga-back
restart: unless-stopped
depends_on:
– db
– events
networks:
– default
volumes:
– ./data/media:/taiga-media
– ./conf/back:/taiga-conf
env_file:
– variables.env
front:
image: dockertaiga/front
container_name: taiga-front
restart: unless-stopped
networks:
– default
volumes:
– ./conf/front:/taiga-conf
env_file:
– variables.env
db:
image: postgres:11-alpine
container_name: taiga-db
restart: unless-stopped
networks:
– default
env_file:
– variables.env
volumes:
– ./data/db:/var/lib/postgresql/data
rabbit:
image: dockertaiga/rabbit
container_name: taiga-rabbit
restart: unless-stopped
networks:
– default
env_file:
– variables.env
events:
image: dockertaiga/events
container_name: taiga-events
restart: unless-stopped
depends_on:
– rabbit
networks:
– default
env_file:
– variables.env
proxy:
image: taiga-proxy-pje
container_name: taiga-proxy
restart: unless-stopped
depends_on:
– back
– front
– events
networks:
– default
ports:
– 80:80
– 443:443
volumes:
#- ./cert:/taiga-cert
– ./conf/proxy:/taiga-conf
env_file:
– variables.env
networks:
default:
Pour fabriquer l’ensemble des containers en allant chercher les images, la magie de docker est appeler avec
cd taiga
docker-compose.exe up -d
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:
cd proxy
docker build -t taiga-proxy-pje .
cd ..
cd taiga
docker-compose.exe up -d
cd ..
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
rm taiga/conf/back/.initial_setup.lock
rm taiga/conf/front/.initial_setup.lock
rm taiga/conf/proxy/.initial_setup.lock
docker update –restart=no $(docker ps -a -q –filter « name=taiga-proxy » –filter « name=taiga-events » –filter « name=taiga-front » –filter « name=taiga-rabbit » –filter « name=taiga-db »)
docker rm taiga-proxy taiga-back taiga-events taiga-front taiga-rabbit taiga-db
docker rmi taiga-proxy-pje dockertaiga/front dockertaiga/events dockertaiga/rabbit dockertaiga/back
docker volume prune –force
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
cd proxy
docker build -t taiga-proxy-pje .
cd ..
cd back
docker build -t taiga-back-pje .
cd ..
cd taiga
docker-compose.exe up -d
cd ..
et purge.bat:
rm taiga/conf/back/.initial_setup.lock
rm taiga/conf/front/.initial_setup.lock
rm taiga/conf/proxy/.initial_setup.lock
docker update –restart=no $(docker ps -a -q –filter « name=taiga-proxy » –filter « name=taiga-events » –filter « name=taiga-front » –filter « name=taiga-rabbit » –filter « name=taiga-db »)
docker rm taiga-proxy taiga-back taiga-events taiga-front taiga-rabbit taiga-db
docker rmi taiga-proxy-pje dockertaiga/front dockertaiga/events dockertaiga/rabbit taiga-back-pje
docker volume prune –force
Dans notre dossier back, nous allons trouver:
d—– 11/06/2019 11:04 users <— Le dossier contenant le nouveau fichier python pour l’OTP
-a—- 13/06/2019 18:43 1225 config.py <— Le fichier de configuration de taiga back
-a—- 08/06/2019 14:52 1956 Dockerfile <— Le fichier Dockerfile où le travail est le plus important
-a—- 02/06/2019 17:26 1466 Dockerfile.v0 <— Fichier Dockerfile initial, pour voir entre Linux et Windows
-a—- 08/06/2019 14:17 157 ntpd.conf <— Le container n’a pas accès à l’heure, cf plus bas
-a—- 13/02/2019 10:26 74 README.md <— Le fichier README de github
-a—- 10/06/2019 20:05 2015 start.sh <— Le nouveau fichier start.sh qui va bien changer
Il faut avec le terminal créer une nouvelle image docker-back que l’on va appeler docker-back-pje.
docker build -t taiga-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.
FROM alpine:latestENV TAIGA_HOST=taiga.lan \
TAIGA_SECRET=secret \
TAIGA_SCHEME=http \
POSTGRES_HOST=db \
POSTGRES_DB=taiga \
POSTGRES_USER=postgres \
POSTGRES_PASSWORD=password \
RABBIT_HOST=rabbit \
RABBIT_PORT=5672 \
RABBIT_USER=taiga \
RABBIT_PASSWORD=password \
RABBIT_VHOST=taiga \
STARTUP_TIMEOUT=15sWORKDIR /srv/taigaRUN
rm -rf /var/cache/apk/* && rm -rf /tmp/* \
&& apk –no-cache add python3 gettext postgresql-dev libxslt-dev libxml2-dev libjpeg-turbo-dev zeromq-dev libffi-dev nginx \
&& apk add –no-cache –virtual .build-dependencies musl-dev python3-dev linux-headers git zlib-dev libjpeg-turbo-dev gcc
ca-certificates jq \
&& mkdir logs \
&& git clone –depth=1 -b stable https://github.com/taigaio/taiga-back.git back && cd back \
&& sed -e ‘s/cryptography==.*/cryptography==2.3.1/’ -i requirements.txt \
&& pip3 install –upgrade pip \
&& pip3 install -r requirements.txt \
&& rm -rf /root/.cache \
&& apk del .build-dependencies \
&& rm /srv/taiga/back/settings/local.py.example \
&& rm /etc/nginx/conf.d/default.confEXPOSE 80
WORKDIR /srv/taiga/back
COPY config.py /tmp/taiga-conf/
COPY nginx.conf /etc/nginx/conf.d/
COPY start.sh /
VOLUME [« /taiga-conf », « /taiga-media »]
CMD [« /start.sh »]
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
version: ‘3’
services:
back:
image: taiga-back-pje
container_name: taiga-back
restart: unless-stopped
depends_on:
– db
– events
networks:
– default
volumes:
– ./data/media:/taiga-media
– ./conf/back:/taiga-conf
env_file:
– variables.env
front:
image: dockertaiga/front
container_name: taiga-front
restart: unless-stopped
networks:
– default
volumes:
– ./conf/front:/taiga-conf
env_file:
– variables.env
db:
image: postgres:11-alpine
container_name: taiga-db
restart: unless-stopped
networks:
– default
env_file:
– variables.env
volumes:
– ./data/db:/var/lib/postgresql/data
rabbit:
image: dockertaiga/rabbit
container_name: taiga-rabbit
restart: unless-stopped
networks:
– default
env_file:
– variables.env
events:
image: dockertaiga/events
container_name: taiga-events
restart: unless-stopped
depends_on:
– rabbit
networks:
– default
env_file:
– variables.env
proxy:
image: taiga-proxy-pje
container_name: taiga-proxy
restart: unless-stopped
depends_on:
– back
– front
– events
networks:
– default
ports:
– 80:80
– 443:443
volumes:
#- ./cert:/taiga-cert
– ./conf/proxy:/taiga-conf
env_file:
– variables.env
networks:
default:
Sauf que après un petit tour dans le container taiga-back fabriqué à partir de mon image taiga-back-pje
docker exec -it taiga-back sh
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
FROM alpine:latestENV TAIGA_HOST=taiga.lan \
TAIGA_SECRET=secret \
TAIGA_SCHEME=http \
POSTGRES_HOST=db \
POSTGRES_DB=taiga \
POSTGRES_USER=postgres \
POSTGRES_PASSWORD=password \
RABBIT_HOST=rabbit \
RABBIT_PORT=5672 \
RABBIT_USER=taiga \
RABBIT_PASSWORD=password \
RABBIT_VHOST=taiga \
STARTUP_TIMEOUT=15sWORKDIR /srv/taigaRUN
rm -rf /var/cache/apk/* && rm -rf /tmp/* \
&& apk –no-cache add python3 gettext postgresql-dev libxslt-dev libxml2-dev libjpeg-turbo-dev zeromq-dev libffi-dev nginx \
&& apk add –no-cache –virtual .build-dependencies musl-dev python3-dev linux-headers git zlib-dev libjpeg-turbo-dev gcc ca-certificates jq
openntpd \
&& mkdir logs \
&& cp /usr/share/zoneinfo/Europe/Paris /etc/localtime && echo « Europe/Paris » > /etc/timezone && renice -n-8 $(pidof ntpd -s) \
&& git clone –depth=1 -b stable https://github.com/taigaio/taiga-back.git back && cd back \
&& sed -e ‘s/cryptography==.*/cryptography==2.3.1/’ -i requirements.txt \
&& pip3 install –upgrade pip \
&& pip3 install -r requirements.txt \
&& rm -rf /root/.cache \
&& apk del .build-dependencies
tzdata \
&& rm /srv/taiga/back/settings/local.py.example \
&& rm /etc/nginx/conf.d/default.confEXPOSE 80
WORKDIR /srv/taiga/back
COPY ntpd.conf /etc/ntpd.conf
COPY config.py /tmp/taiga-conf/
COPY nginx.conf /etc/nginx/conf.d/
COPY start.sh /
VOLUME [« /taiga-conf », « /taiga-media »]
CMD [« /start.sh »]
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
# See ntpd.conf(5) and /etc/examples/ntpd.conf
listen on *server time1.google.com
server time2.google.com
server time3.google.com
server time4.google.com
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…
