technique:infrastructure:tests

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
Dernière révisionLes deux révisions suivantes
technique:infrastructure:tests [2020/09/15 16:01] qduchemitechnique: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. 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 20: Ligne 20:
 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.  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. 
  
-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 disqueon préfère **//build// nos images Docker de test uniquement en local**, directement sur la VM de test\\+Si on en est qu'à une phase de test préliminaireon n'utilisera pas le dépôt Dockerfilemais des fichiers de son dossier personnel.
  
 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. 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.
  
-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''+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`.