-
mettez vous par deux et reliez vous avec un câble RJ, ça évitera de tout faire péter sur vos machines. Mettez-vous dans un petit réseau en /24 on sera large
-
Récupérez le projet git https://github.com/coreos/coreos-vagrant.
-
explorez un peu le Vagrantfile
-
ajouter un disque de 10 g
-
Créez ensuite 5 machines à l'aide de ce Vagrantfile (ça se fait facilement à l'aide d'une variable déjà créée dans le fichier Vagrantfile)
Réponse 1
Lors de ce TP il était demandé de connecté 2 ordinateur à l'aide d'un cable RJ45 malheureusement je ne dispose pas de port sur mon ordinateur. Je vais alors faire ce TP en n'abordant pas se problème.
Réponse 2
git clone https://github.com/coreos/coreos-vagrant
Réponse 3
-
La syntaxe du Vagrantfile est ruby.
-
Le Vagrantfile appel une librairie "fileutils".
-
Il est ensuite précisé la version du Vagrantfile "1,60".
-
Ligne 9 à 19 on procède à l'installation d'un plugin "igniton". L'installation à était scripté afin que si il est présent il ne se réinstalle pas et inversement .
-
Ligne 26 à 36 des variables de configuration son instancié.
-
Ligne 40 à 59 crée un nombre de VM exact à la valeur de la variable "$num_instance" ainsi qu'application des variables "vm_memory", "vm_cpu".
-
Ligne 61 à 74 configuration de l'agent SSH et du nom des VMs.
-
Ligne 61 à la fin configuration du founisseur de virtualisation VMware, Hyper-v, Virtualbox et application des variable d'environnement au VM mise en place d'un partage de dossier entre host et vm.
Réponse 4:
Afin d'ajouter un disque de 10Go à core il faut ajouter les lignes de code suivante au Vagrantfile.
file_to_disk = 'disk2.vdi'
unless File.exist?(file_to_disk)
vb.customize ['createhd', '--filename', file_to_disk, '--size', 10 * 1024]
end
vb.customize ['storageattach', :id, '--storagectl', 'IDE Controller', '--port', 1, '--device', 0, '--type', 'hdd', '--medium', file_to_disk]
Réponse 5:
Afin de crée 5 machines simultanéments il faut changer la valeur de la variable "$num_instance" qui est par défaut à 1 pour 5.
# Change default to 5
$num_instances = 5
Aller à la racine du référentiel coreOS
cd /coreos-vagrant/
Démarrer les VMs à l'aide de la commande suivante
Vagrant up
Les VMs vont poper dans votre envirronement virtualbox.
Il est maintenant possible de se connecté aux différente VMs Coreos à l'aide de la commande suivante:
Vagrant ssh core-0$x
Soit la variable x le nombre correspondant à la vm choisie
- Cette partis du TP ne met pas accessible du à mon manque de port Ethernet .
- Dans cette partis il nous est demandé d'utiliser la technologie "Swarm" de docker. Nous allons mettre en place un swarm de 5 noeuds : 3 managers et 2 workers.
-
Configurer le mode experimental et la clause métric-addr au démon docker.
-
Mise en place d'un swarm 3 managers 2 workers.
Réponse 1: Pour ajouter le mode "experimental" et la publication des metrics il faut ajouté ces close au fichier de configuration du démon docker comme suis.
( Si vous n'avez pas encore utiliser docker le répertoire "/etc/docker" n'existe pas encore pour le crée il suffit de taper une commande docker tel que docker info).
Création du fichier:
touch daemon.json
Editer le fichier et y ajouter les clauses suivantes.
Réponse 2:
Initialisation du swarm:
Génération d'un commande d'ajout de managers au swarm:
Création d'un commande d'ajout de workers au swarm:
Une fois les commandes généraient. Il suffit d'une simple éxectution sur les machines ditent "Managers", "Workers" et elles seront ajoutés au swarm.
Pour les Managers:
Pour les Workers:
Ont peut vérifier que la configuration fonctionne en utilisant la commande Docker node ls qui check l'état des liens sur notre swarm docker.
Managers:
- core-01
- core-02
- core-03
Workers:
- core-04
- core-05
Dans cette partie du travaux pratique tous nos services, nos applicatifs, tourneront sous la forme de stacks ou services Swarm.
Pour simplifier la tâche et aller plus vite lors de phase d'exécution j'ai bricolé un script utile pour éxecuter une même commande sur toute les machines du swarm.
#!/bin/bash
for i in $(seq 1 5)
do
vagrant ssh core-0$i -c '<the command>'
# Example
vagrant ssh core-0$i -c 'mkdir /test'
done
Installation de "docker-compose" sur les machine.
Création d'un répertoire "/opt/bin/":
cd / && sudo mkdir -p /opt/bin
Téléchargement puis installation du binaire "docker-compose":
cd / && sudo curl -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" -o /opt/bin/docker-compose
Réglage des permissions pour utilisation du pacquet:
cd / && sudo chmod +x /opt/bin/docker-compose
Utilisez le compose.yml fourni afin d'avoir une stack de test. Il pop l'archi suivante : BDD <--- AppPython <--- NGINX >
Ensuite on télécharge le référentiel avec le "docker-compose.yml" sur chacun des noeuds:
git clone https://github.com/It4lik/B3-Cloud-2018.git
Enfin pour déployer l'infrastructure sur tout les hôtes. Il faut exécuter la commande suivante sur l'hote "core-01" manager et leader du swarm pour propager le déploiment de configurations:
cd /docker stack deploy python_dirty_app -c docker-compose.yml
Il est possible de vérifier que l'essaim c'est bien déployé avec la commande qui suit:
Si l'ont veut vérifier que les services sont correctement démarrer il existe la commande:
L'application est bien joingnable sur le port 8080 car si ont effectue une commande curl depuis la machine sur le localhost et le port 8080 le code de l'apps web nous est bien renvoyé:
Pour effectuer la fin du TP correctement nous allons supprimer notre nouvelle pile d'application avec la commande:
docker stack rm python_dirty_app
- Weave Cloud outils Saas de monitoring et métrologie directement depuis interface très performant. Il permet de monitorer un swarm. Durant cette partie nous allons déployé et configurer cet outils sur notre swarm.
Avec github.
Executer la commande sur le leader du swarm pour lancer les services:
Le conteneur va se servir de son propre socket docker et monter le répertoire sur le conteneur lancer par la commande. C'est le principe "docker in docker" le conteneur pourras alors utiliser le socket docker de l'hote pour lancer des conteneur depuis celui-ci.
Il est possible par l'interface web weave de surveiller les performances des applications et leur évènement.
- stockage des données
- organisation des données
- accès aux métiques
- visualisation des donnée
- journalisation des logs
- surveillance continue
- Automatisation
- alerte automatique
docker run -d --net=host \
--restart always \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph/ \
-e MON_IP=<IP_HOST_ONLY> \
-e CEPH_PUBLIC_NETWORK=<HOST_ONLY_CIDR_NETWORK> \
--name="ceph-mon" \
ceph/daemon mon
- MON_IP c'est pour "monitor IP".
- suite à ça, déplacer tout le contenu de /etc/ceph/ sur tous les autres noeuds.
- exécuter de nouveau la commande docker run ci-dessus sur deux autres noeuds (ce sera vos 3 monitors).
- n'oubliez pas de changer la variable MON_IP sur chacun de vos 3 monitors.
J'execute la commande sur mon premier hote.
Il est possible que les configuration ne soit pas bonne alors on peut modifier le fichier de configuration ceph "/etc/ceph" pour y rajoutez ces configurations réseaux valide pour mon cas:
cat /etc/ceph/ceph.conf
Je partage ensuite ma configurations avec mes autres hôtes via github:
#core-01
cd /etc/ceph/
git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/Odka33/Docker-provision.git
git push -u origin master
#core-0{2,3}
mkdir -P /etc/ceph
sudo git clone https://github.com/Odka33/Docker-provision.git .
Ensuite j'éxecute de nouveau la commande "docker run":
(core-02)
(core-03)
Ont peut vérifié que la configurtaion fonctionne en effectuant les commandes "ceph df" et "ceph status":
- Sur les 3 mêmes hôtes que les monitors :
docker run -d --net=host \
--privileged=true \
--pid=host \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph/ \
--name="ceph-mgr" \
--restart=always \
ceph/daemon mgr
- Effectuer une vérification.
J'execute la commande sur les 3 même hôtes que les moniteurs soit core-01 ""-02 et ""-03. j'effectue une vérification de configurations:
Si le service "mgr" est apparue et est actif alors c'est bon.
-
Récupérez l'output de la commande ceph auth get client.bootstrap-osd et stockez le dans un fichier.
-
Sur tous les noeuds : copier le contenu du fichier précédemment créé dans /var/lib/ceph/bootstrap-osd/ceph.keyring, effacez s'il existe déjà, créez s'il n'existe pas
-
Puis executé :
docker run -d --net=host \
--privileged=true \
--pid=host \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph/ \
-v /dev/:/dev/ \
-e OSD_FORCE_ZAP=1 \
-e OSD_DEVICE=<CHEMIN_VERS_NEW_DISK_IN_/dev> \
-e OSD_TYPE=disk \
--name="ceph-osd" \
--restart=always \
ceph/daemon osd_ceph_disk
-
n'oubliez pas de changer CHEMIN_VERS_NEW_DISK_IN_/dev par /dev/sdb par exemple
-
check cluster status
On peut récupérér l'output de la commande avec:
Terminal.
docker exec ceph-mon ceph auth get client.bootstrap-osd > file.txt
Pour créer le chemin s'il n'existe pas:
Terminal.
mkdir -p /var/lib/ceph/bootstrap-osd/
Modifier ou crée s'il n'existe pas ceph.keyring:
Fichier.
Nous exécutons la commande suivante:
docker run -d --net=host \
--privileged=true \
--pid=host \
-v /etc/ceph:/etc/ceph \
-v /var/lib/ceph/:/var/lib/ceph/ \
-v /dev/:/dev/ \
-e OSD_FORCE_ZAP=1 \
-e OSD_DEVICE=/dev/sdc> \
-e OSD_TYPE=disk \
--name="ceph-osd" \
--restart=always \
ceph/daemon osd_ceph_disk
Pour "/dev/sdc" emplacement du bloc de 10go ajoutez plutôt dans les prérequis.
Ont check que la configurtation et correct:
Terminal.
- Sur tous les noeuds:
docker run -d --net=host --name ceph-mds --restart always -v /var/lib/ceph/:/var/lib/ceph/ -v /etc/ceph:/etc/ceph -e CEPHFS_CREATE=1 -e CEPHFS_DATA_POOL_PG=128 -e CEPHFS_METADATA_POOL_PG=256 ceph/daemon mds
- Sur un noeud, pour éviter de péter vos machines :
ceph osd pool set cephfs_data size 2
ceph osd pool set cephfs_metadata size 2
ceph osd set nodeep-scrub
On démarre le conteneur mds via la commande. Mds démon du serveur de métadonnée.
On peut voir que le démon a démarrer en executant la commande docker ps.
Terminal.
Exécution des commandes sur l'hôte core-01.
- Dans un des conteneurs monitor, on va créer un secret qui nous permettra d'accéder au volume CEPH sur tous nos noeuds:
ceph auth get-or-create client.dockerswarm osd 'allow rw' mon 'allow r' mds 'allow' > keyring.dockerswarm
cat keyring.dockerswarm
- Puis sur tous les noeuds:
mkdir /data
echo "<MONITOR_IPS_COMMA_SEPARATED>:6789:/ /data/ ceph name=dockerswarm,secret=<YOUR_SECRET_HERE>,noatime,_netdev 0 2" > /etc/fstab
mount -a`
Le répertoire /data devrait être accessible sur les noeuds.
On execute la commande suivante sur les monitors qui va générer une clé et l'enregistrer dans le fichier keyring.dockerswarm.
Terminal.
docker exec ceph-mon ceph auth get-or-create client.dockerswarm osd 'allow rw' mon 'allow r' mds 'allow' > keyring.dockerswarm
On va crée un répertoire data sur tout nos hôtes.
Terminal.
mkdir data
Ensuite on va écrire les configurations pour le stockage dans le fichier de configuration de filesystem fstab ont y ajoute les ips des moniteur ainsi que la clé générer dans la réponse 1.
Terminal.
echo "172.17.8.101,172.17.8.102,172.17.8.103:6789:/ /data/ ceph name=dockerswarm,secret=AQAZq+lbbuAFJhAAkOBSYIVTs8N16zTGfkATKA==,noatime,_netdev 0 2" >> /etc/fstab
Ensuite ont monte le filesystem avec la commande mount.
Terminal.
mount -a
Pour finir ont peut vérifier que la configuration fonctionne et que le répertoire data et répliquer sur tout nos hôtes en créant un fichier dedans si il apparait sur tout les autres alors sa fonctionne.
- Expliquer rapidement le principe d'un système de fichiers distribué ( distributed filesystem ).
- Proposer une façon d'automatiser le déploiement de cette configuration CEPH, sans passer par un volume de l'hôte ?
actuel : CEPH --MDS--> Host --run -v--> conteneur
demandé : CEPH --MDS--run -v--> conteneur
Les principes du systèmes de fichier distribué sont une aborescence logique et des données partagé depuis des emplacemnts différents, assurer la redondance et la disponibilité des données grâce à la réplication, rassembler différents partages de fichiers à un endroit unique de façon transparente.
Pour automatiser le déploiement de CEPH j'utiliserai Vagrant et ansible. Je déploireais les hosts VM via vagrant et à la fin du script vagrant j'utiliserais l'automatisation et le déploiement d'ansible via les playbooks pour fournir les configurations CEPH à mes hosts simultanément.
Example:
Vagrant -> core-01, core-02, core-03, core-04, core-05 Ansible -> CEPH -> MDS-run -> conteneur
-
Expliquez le principe d'un partage NFS, quels pourraient être ses limites dans le cas d'un swarm comme le nôtre (qui peut être amené à grandir) ?
-
Proposez une façon d'automatiser le déploiement cette conf NFS.
-
Où est lancé le service réellement ? (sur quel hôte, et comment on fait pour savoir ?) Combien y'a-t-il de conteneur(s) lancé(s) ?
-
Pourquoi le service est accessible depuis tous les hôtes ? Documentez vous sur internet.
Le service est lancé localement ont execute un registre local toute les images seront stocker sur le filesystem de la machine. Il n'y à aucun conteneur lancé à la suite de cette opération.
Le service est accessible sur tous les hôtes car il à était publié sur le port 5000 de la machine core-01 les autres machine étant sur le même réseaux elle peuvent accéder au registres.
-
Hébergez les images du Dumb Service dans le registre
-
Utilisez le répertoire /data pour stocker ses données (docker-compose.yml, configurations, applications, données)
-
Observer son évolution sur Weave Cloud
Nous allons commencé par construire les images.
Terminal.
cd /app/
docker-compose build
Une fois l'image crée ont vas tager celle ci pour qu'elle pointe vers notre registre.
Terminal.
docker image tag m1.swarm:5000/python-app 127.0.0.1:5000/python
Enfin ont la pousse sur le registre.
docker push localhost:5000/python
On vérifie qu'elle à bien était pousser sur le registre.
Terminal.
Nos images ont bien était poussé sur le registre.
Il est aussi possible de les download.
Pour cette partis j'ai télecharger le contenus /tp1/app/* dans le répertoire /data/ .
Ont déploit weave.
Terminal.
On patiente et on peut ensuite visité l'interface qui nous permet d'avoir les metrics de informations de notre swarm.
-
Lancez la commande sur tous vos hôtes, en modifiant la priorité à chaque fois. Une fois fait, vous n'accéderez à votre cluster plus qu'avec l'ip virtuelle
-
que fait le --net=host de la commande exactement ? Je veux voir une utilisation de nsenter en réponse à cette question. Pourquoi avoir besoin de ça sur Keepalived ?
-
A quoi sert --cap-add=NET_ADMIN ?
-
Le principe de priorité au sein de Keepalived et le fonctionnement simplifié de vrrp (schéma si vous voulez)
Ont execute la commande sur tout le cluster entier pour core-01 la priorité à 200 et pour le reste 199, 198, 197 etc...
ont vérifie ensuite que la configuration à bien fonctionner.
En ping
ou via l'interface réseau des hôte coreos
La directive --net=host sert à préciser le pilote réseau utiliser. Si elle est préciser elle a pour effet de ne pas isolée la pile réseaux de ce conteneur de l'hote docker.
Nous avons besoin de sa sur keepalived pour executer avec nsenter des commandes et configuration sur tout les hôtes docker à partir de l'ip virtuel préalablement crée.
cap-add=NET_ADMIN sert à donner les priviléges sur les cartes et interfaces réseaux du systèmes hôtes.
Le principe de priorité sert à désigner l'hote qui serviras de Master du swarm docker. Le principe de vrrp est de définir la passerelle par défaut pour les hôtes du réseau comme étant une adresse IP virtuelle.
-
ce qu'est un 'collector' dans ce contexte
-
un peu plus en détail le fonctionnement de chacun des tools déployés par cette stack
grafana
Dans ce contexte un collector est un collecteur de metrics à des fins de visualisation dans le cas de grafana.
Prometheus: Database monitoring tools
Grafana: data vizualisation tools
Cadvisor: Analyzes resource usage and performance characteristics of running containers.
AlertManager: Le AlertManager gère les alertes envoyées par les applications clientes est une partis du projet prometheus
unsee: Alert dashboard for Prometheus Alertmanager
caddy: Caddy is the HTTP/2 web server with automatic HTTPS.