Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
technique:infrastructure:tests [2020/02/14 21:59] – [Docker] qduchemi | technique:infrastructure:tests [2020/09/29 16:58] (Version actuelle) – supprimée qduchemi |
---|
====== Infrastructure de test de Picasoft ====== | |
| |
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. | |
| |
Pour y accéder il faut fournir votre clef SSH à un administrateur, puis faire un simple ''ssh <login>@pica01-test.picasoft.net''. | |
| |
===== Dossier personnel ===== | |
| |
Pour faciliter l'organisation des fichiers de chacun, il convient d'utiliser votre répertoire personnel (`/home/<login>`) | |
| |
**Faites le ménage de temps à autre** dans votre dossier pour ne pas utiliser de l'espace disque inutilement. | |
| |
===== Docker ===== | |
Picasoft utilisant Docker pour déployer ses services, c'est aussi cette technologie qui est utilisée sur la machine de test. | |
| |
==== Images ==== | |
| |
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. \\ | |
| |
La VM de test sert à tester les images construites par [la chaîne d'intégration](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 disque, on préfère **//build// nos images Docker de test uniquement en local**, directement sur la VM 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''. | |
| |
==== Conteneur ==== | |
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: | |
<code> | |
#################### | |
## Framadate kyane # | |
#################### | |
framadate: | |
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]]. | |