KAZ/kaz-vagrant
2
0
Fork 0
Code Issues Pull Requests Projects Releases 1 Wiki Activity

update doc

Browse Source
This commit is contained in:
Francois Lesueur 2023-05-26 16:18:54 +02:00
parent 0f5412ea8b
commit f0270a56ec
2 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
README.md
View File

@ -11,7 +11,7 @@ Nous utilisons :
* LXC pour faire tourner ces services dans des conteneurs distincts (ie, kaz-prod est un conteneur LXC) * LXC pour faire tourner ces services dans des conteneurs distincts (ie, kaz-prod est un conteneur LXC)
* Docker pour chaque service de notre serveur * Docker pour chaque service de notre serveur
À la fin, nous obtenons une maquette d'un petit internet simulé, avec du DNS, des mails tiers, et notre serveur kaz-prod dans un coin. À la fin, nous obtenons une maquette d'un petit internet simulé, avec du DNS, des mails tiers, et nos serveurs hoster-a-kaz1 et hoster-b-kaz2 dans un coin.
![topologie](/doc/images/topologie.png) ![topologie](/doc/images/topologie.png)
@ -36,7 +36,7 @@ cd kaz-vagrant/
vagrant up vagrant up
``` ```
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. Cette étape peut-être (très) longue, notamment la construction des machines Kaz... Comptez entre 40 minutes et quelques heures, selon la connexion réseau et les performances de la machine.
@ -52,9 +52,10 @@ cd /root/snster-kaz
snster start snster start
``` ```
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 ?) Normalement, hoster-a-kaz1 et hoster-b-kaz2 lancent automatiquement les dockers (dans 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 ?)
```bash ```bash
snster attach kaz-prod -x /kaz/bin/container.sh start snster attach hoster-a-kaz1 -x /kaz/bin/container.sh start
snster attach hoster-b-kaz2 -x /kaz/bin/container.sh start
``` ```
Vous pouvez alors (toutes les commandes snster doivent être exécutées dans `/root/snster-kaz`) : Vous pouvez alors (toutes les commandes snster doivent être exécutées dans `/root/snster-kaz`) :
@ -62,15 +63,16 @@ Vous pouvez alors (toutes les commandes snster doivent être exécutées dans `/
* Ouvrir Firefox et naviguer vers : * Ouvrir Firefox et naviguer vers :
* `https://www.kaz.sns`, le Kaz interne à la VM * `https://www.kaz.sns`, le Kaz interne à la VM
* `https://listes.kaz.sns`, le sympa interne à la VM * `https://listes.kaz.sns`, le sympa interne à la VM
* `https://pad2.kaz.sns`, le pad sur kaz2
* `https://www.kaz.bzh`, le vrai Kaz * `https://www.kaz.bzh`, le vrai Kaz
* Ouvrir claws-mail et retrouver les comptes mails configurés : * Ouvrir claws-mail et retrouver les comptes mails configurés :
* `contact1@kaz.sns` à `contact4@kaz.sns`, hébergés sur le kaz-prod de la VM * `contact1@kaz.sns` à `contact4@kaz.sns`, hébergés sur le kaz-prod de la VM
* `email@isp-a.sns`, hébergé dans le conteneur LXC isp-a-infra * `email@isp-a.sns`, hébergé dans le conteneur LXC isp-a-infra
* Travailler sur kaz-prod : `snster attach kaz-prod` * Travailler sur hoster-a-kaz1 : `snster attach hoster-a-kaz1`
* Afficher un plan de réseau : `snster print` * Afficher un plan de réseau : `snster print`
* Le système de fichiers de kaz-prod est accessible directement dans la VM: * Le système de fichiers de hoster-a-kaz1 est accessible directement dans la VM:
* `/kaz-prod/` [VM] correspond à `/` [kaz-prod] * `/kaz1-prod/` [VM] correspond à `/` [hoster-a-kaz1]
* `/kaz` [VM] correspond à `/kaz` [kaz-prod] * `/kaz` [VM] correspond à `/kaz` [hoster-a-kaz1]
* Il est probablement pratique d'installer son environnement de développement sur la VM, avec ses clés SSH et son éditeur favori. * Il est probablement pratique d'installer son environnement de développement sur la VM, avec ses clés SSH et son éditeur favori.
Il y a un aperçu de l'état des services avec l'url https://kaz.sns/status/allServices.html Il y a un aperçu de l'état des services avec l'url https://kaz.sns/status/allServices.html
@ -93,9 +95,9 @@ Il vous faudra accepter les éventuelles alertes de sécurité pour certificat a
## Mise au point ## Mise au point
Pour réinstaller Kaz sur kaz-prod (avec suppression de /kaz, des volumes dockers et réinstallation complète), depuis la VM : Pour réinstaller Kaz sur kaz1 (avec suppression de /kaz, des volumes dockers et réinstallation complète; idem kaz2), depuis la VM :
```bash ```bash
snster attach kaz-prod -x "/root/kaz.sh" snster attach hoster-a-kaz1 -x "/root/kaz.sh"
``` ```
Pour détruire la VM et recommencer, depuis l'hôte : Pour détruire la VM et recommencer, depuis l'hôte :

BIN
doc/images/topologie.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 156 KiB

After

Width:  |  Height:  |  Size: 103 KiB