blog.bressure.net

Application, Paramétrage

Wekan

admin

Wekan est un outils de gestion de projet utilisant la méthode Kanban. Il est une alternative opensource à Trello. Je voulais l’installer depuis maintenant un mois mais j’avais dû retarder cette tâche pour mettre au point mon architecture avec Traefik. Maintenant que Traefik est installé et permet de faire la mise au point facilement en disposant d’un environnement staging à la demande, je vais pouvoir tester Wekan.

Création de l’instance Wekan

Wekan est la première application avec laquelle je vais tester mon petit workflow de déploiement. Je commence par déclarer l’application en partant du fichier docker-compose disponible dans la documentation officielle. Je l’adapte à mes besoins pour ce qui est de la messagerie et je n’expose aucun port.

docker-compose.yml

J’ajoute 2 autres fichiers docker-compose.staging et docker-compose.production.yml qui décrivent les routages spécifiques à l’environnement. La construction et le déploiement se fait de manière standard avec un .gitlab-ci.yml toujours identique au nommage du job de test près et je pourrais même utiliser un nom générique.

Je laisse alors l’IC faire son travail de test dans DIND puis de déploiement automatique en staging.

Test en environnement staging

Pour tester l’application il me faut ajouter dans mon fichier /etc/hosts le nom wekan.bressure.net pour le faire pointer vers mon frontal TLS. Le nom n’est pas encore dans mon DNS public. En utilisant mon navigateur je vais sur https://wekan.bressure.net:444

Je tombe alors grâce à mon infra vhost TLS/haproxy/traefik de staging sur l’instance wekan déployée en staging. Je teste ainsi toute la chaine dont j’ai la maitrise complète jusqu’à l’application. Le routeur ADSL qui appartient à mon FAI n’en fait pas partie !

Au niveau sécurité l’instance wekan en staging n’est pas accessible depuis internet car le port 444 de mon frontal TLS n’est accessible depuis internet à la fois via la box ADSL mais comme je ne lui fais pas totalement confiance, via le virtual host qui n’accepte que des connexions du réseau local.

Ouverture en production

L’étape suivante du pipeline dans Gitlab est le déploiement en production que je garde manuel non seulement pour garder un contrôle humain mais aussi parce que le déploiement en production suppose que mon DNS public ait été mis à jour or cette action est encore manuelle. On pourrait je pense l’automatiser mais je préfèrerai quand même valider l’application en staging avant de passer en production.

La dernière étape du pipeline passé puis le DNS mis à jour, mon application est enfin accessible en production.

Tags:

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Back to top