[Kaz](https://kaz.bzh/) est un CHATONS du Morbihan. Nous proposons ici un moyen de le répliquer dans une VM. Il y a des éléments de configuration à définir avant d'initialiser ce simulateur.
Le principe est de faire fonctionner un simulateur de notre CHATONS dans une VirtualBox pour mettre au point nos différents services.
Nous utilisons :
* Vagrant pour automatiser la création de la Machine Virtuelle
Cette étape peut-être (très) longue. Notamment, la construction de kaz-prod se fait dans un conteneur LXC, dans lequel les overlays docker passent par un filesystem plus lent qu'en natif... Comptez entre 40 minutes et quelques heures, selon la connexion réseau et les performances de la machine.
Si vous avec laissé la création de Kaz, il faut bien attendre la fermeture automatique de la fenêtre et l'apparition de l'écran de connexion (on vous a dit que c'était long).
Normalement, kaz-prod lance automatiquement les dockers (dans son rc.local), mais si ça ne marche pas bien il peut falloir les relancer (que se passe-t-il si on relance container.sh pendant que container.sh n'est pas encore fini ? faut-il l'enlever du rc.local ? Le lancement initial peut rater, probablement si le DNS n'est pas encore fonctionnel lors du lancement, à mettre au point et peut-être enlever du rc.local ?)
Les erreurs 502 correspondent à des fonctions en cours de développement. Les message "Can't open this page" correspond au fait que le services refuse pour des raison de sécurité de de fonctionner embarqué dans une page.
Vous pouvez également démarrer firefox avec les URL suivantes:
Il vous faudra accepter les éventuelles alertes de sécurité pour certificat absent (web et messagerie)
## Mise au point
Il est possible d'interrompre la création à la coquille vide (juste la VM sans les services KAZ) pour des question de mise au point avec la commande :
```bash
NOKAZ="true" vagrant up
```
Dans ce cas, il faudra ensuite lancer dans la VM :
```bash
KAZGUARD="true" /root/vm-install-kaz.sh
```
Pour détruire la VM et recommencer :
```bash
vagrant destroy
```
##Accélération de la construction avec un proxy cache local
Au tout début de la construction de la VM, un proxy Squid est installé au niveau de la VM. Il fait du cache et est ensuite utilisé lors des apt-get du provisionning de la VM puis lors des constructions des conteneurs LXC et des dockers. Certains téléchargements ne sont pas encore mis en cache (soit parce que certains téléchargements se font hors de ce proxy, soit par l'utilisation du HTTPS qui n'est pas (encore) intercepté pour faire ce cache), mais cela diminue déjà beaucoup le trafic réseau lors de la construction et lors des reconstructions partielles ensuite.
Il est possible de configurer ce proxy pour utiliser un proxy du réseau local à son tour. L'intérêt est d'avoir un cache persistant lors de la reconstruction de la VM, ou de pouvoir rediriger certaines requêtes (dépôts Debian ou Alpine) vers des miroirs locaux. Pour cela, il faut un fichier `files/customVM.sh`. Un fichier `files/customVM.sh.dist` est fourni en exemple : il suffit de le renommer en `customVM.sh`, puis de modifier l'IP du proxy upstream dans la ligne `cache_peer`.
