Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:infrastructure:tests [2020/02/14 21:58] – [Docker] qduchemi
+++ technique:infrastructure:tests [2020/09/16 11:24] – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-====== Infrastructure de test de Picasoft ======
+====== Utilisation de la machine de test ======
 Picasoft dispose d'une machine virtuelle de test similaire à celles utilisées en production. Elle permet de valider le fonctionnement d'un logiciel avant une mise à jour, de tester de nouveau services ou encore d'expérimenter diverses choses (entre autre, dans le cas de TXs). C'est une machine utilisée par un grand nombre de personnes, il est **impératif** d'y garder un peu d'ordre.
@@ Ligne 18: / Ligne 18: @@
 Généralement Picasoft utilise un //registry// Docker privé pour héberger ses différentes images Docker. Ceci permet de //build// une image depuis une machine, de la pousser sur le //registry// puis de l'utiliser sur les serveurs de production. \\
-Cependant, en phase de test, on //build// très régulièrement son image au fur et à mesure que l'on avance. Si l'on pousse à chaque fois son image sur le //registry// pour l'utiliser sur la VM de test, cela va prendre beaucoup de place sur notre //registry//. Afin d'économiser notre espace disque, on préfère **//build// nos images Docker de test uniquement en local**, directement sur la VM de test. \\
+La VM de test sert à tester les images construites à part [du dépôt dockerfile](https://gitlab.utc.fr/picasoft/projets/dockerfiles), mais en phase de **conception**, on //build// très régulièrement son image au fur et à mesure que l'on avance.
-Par exemple si je souhaite tester une image de Framadate, je copie mon Dockerfile (et les autres fichiers associés) dans un dossier ''/home/<login>/framadate'' puis je fais ''docker build -t framadate:MONNOM /home/<login>/framadate''. Je peux ensuite utiliser cette image en local sur la machine de test.
-Bien sûr, lorsque j'ai fini mes tests je fais le ménage en supprimant mon image Docker de la machine avec la commande ''docker rmi''.
+Si on en est qu'à une phase de test préliminaire, on n'utilisera pas le dépôt Dockerfile, mais des fichiers de son dossier personnel.
-==== Conteneur ====
+Par exemple si je souhaite tester une image de Framadate, je copie mon Dockerfile (et les autres fichiers associés) dans un dossier ''/home/<login>/framadate'' puis je fais ''docker build -t framadate:<login> /home/<login>/framadate''. Je peux ensuite utiliser cette image en local sur la machine de test.
-Pour déployer nos conteneurs Docker, nous utilisons //docker-compose// qui permet de lancer différents conteneurs à partir d'un fichier de configuration.
-Le fichier de configuration est ''/DATA/docker/docker-compose.yml''. Puisqu'il est potentiellement utilisé par plusieurs personnes il est **impératif** de la commenter en ajoutant un header au dessus de la configuration de votre service. Par exemple si on veux configurer un conteneur du Framadate on ajoutera ceci:
+Bien sûr, lorsque j'ai fini mes tests je fais le ménage en supprimant mon image Docker de la machine avec la commande ''docker rmi'' et je commit les nouveaux fichiers sur le dépôt `dockerfiles`.
-<code>
-####################
-## Framadate kyane #
-####################
-  wiki:
-    container_name: framadate-kyane
-    image: framadate:kyane
-[...]
-</code>
-L'idée est de pouvoir identifier facilement quel bout de configuration est utilisé par qui. De même on prendra soin de nommer nos conteneurs (avec ''container_name'') de manière compréhensible.
-Si on a besoin de données persistantes pour un conteneur, on créé un dossier au nom du conteneur dans ''/DATA/docker''  que l'on pourra monter dans le conteneur ou on utilise un [[technique:docker:volumes|volume Docker]].