Différences

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

--- technique:architecture_des_services [2017/05/12 20:26] – modification externe 127.0.0.1
+++ technique:architecture_des_services [Date inconnue] (Version actuelle) – supprimée - modification externe (Date inconnue) 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-======Architecture des services======
-=====Haute disponibilité=====
-Dans le but d'avoir une architecture avec une haute disponibilité, nous avons décidé d'avoir deux machines virtuelles hébergeant les services. Chaque machine se trouvant sur une machine physique différente. Dans un souci de facilité, nous avons décidé de gérer la haute disponibilité de nos services en nous basant sur du round robin DNS. Cette méthode consiste à ajouter plusieurs enregistrements DNS pour un même domaine. Ainsi, lorsque les clients requêtent le domaine, ils sont redirigés sur l'une ou l'autre des machines. Cela permet également de répartir la charge entre les deux serveurs.
-=====Docker Swarm=====
-Pour héberger les services, nous utilisons des conteneurs Docker en mode cluster avec la fonctionnalité Swarm de Docker 1.12. Cela permet de lancer des services et de les scaler en fonction de nos besoins. Si vous voulez plus d'informations, je vous invite à consulter [[technique:installation_docker_swarm_cluster|cet article]]
-Une chose à prendre en compte est que sur Swarm, les conteneurs sont placés sur un réseau privé (on parle d'overlay) qui est partagé entre les différents noeuds du cluster. Lors du lancement d'un service sur un noeud du cluster, on peut donc spécifier à quel réseau il peut avoir accès. Une fois lancés, les conteneurs sont capables de résoudre leurs ip privées via des entrées DNS basées sur leur nom. En d'autres termes, si on lance un conteneur avec le flag <code>--name bdd</code> et un second avec le flag <code>--name apache</code>, cela signifie qu'à partir du conteneur apache, il sera possible d'avoir accès à l'IP et donc au service rattaché au conteneur bdd (un ping bdd pingera l'ip privée du conteneur bdd). l'inverse est aussi vrai.
-=====Architecture=====
-{{:passation:archi_tx_1_.png?800|}}
-Comme je le disais, les services sont donc lancés sur les deux machines virtuelles. Pour rediriger le flux entrant vers le bon conteneur, nous utilisons un reverse proxy orienté micro service et qui est en mesure de fonctionner sous swarm. Traefik, c'est son nom écoute les actions réalisées sur le démon docker. Lorsqu'il détecte un conteneur lancé avec certaines variables d'environnement, il génère une configuration pour rediriger et répartir la charge vers l'un ou l'autre des conteneurs.
-Pour le lancer, on créé le service suivant:
-<code>
-docker service create \
- --name traefik \
- --publish 80:80 --publish 443:443 --publish 8080:8080 \
- --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
- --mount type=bind,source=/DATA/WEB/traefik/traefik.toml,target=/etc/traefik/traefik.toml \
- --mount type=bind,source=/DATA/WEB/traefik/certs,target=/certs \
- --network pica-net \
- --mode global \
- traefik \
- --docker \
- --docker.swarmmode \
- --docker.domain=swarm.picasoft.net \
- --docker.watch \
- --logLevel=INFO \
- --web
-</code>
-Ensuite, il suffit d'ajouter les étiquettes suivantes aux conteneurs pour générer la configuration adéquate
-<code>
---label traefik.port=80
---label traefik.frontend.rule=Host:team.picasoft.net
-</code>
-Traefik.port correspond au port d'écoute de notre service dans le conteneur\\
-Traefik.frontend.rule correspond au nom de domaine du service exposé. Il faut au préalable avoir créé les entrées DNS pour que cela fonctionne.\\
-Traefik va donc être capable de configurer à la volée les différents services sans que l'on ait à écrire le moindre fichier de configuration. Il y a également une interface de configuration que l'on peut atteindre via le port 8080 et qui montre l'état des services et différentes statistiques.\\
-Traefik peut aussi générer automatiquement une configuration letsencrypt. Pour cela, il faut utiliser le fichier de configuration suivant:
-<code>
-defaultEntryPoints = ["http", "https"]
-[entryPoints]
- [entryPoints.http]
- address = ":80"
-   [entryPoints.http.redirect]
-      entryPoint = "https"
- [entryPoints.https]
- address = ":443"
- [entryPoints.https.tls]
-[acme]
-email = "picasoft@assos.utc.fr"
-storageFile = "/certs/acme.json"
-entryPoint = "https"
-onDemand = true
-[[acme.domains]]
- main = "swarm.picasoft.net"
-[web]
-address = ":8080"
-</code>
-Au premier lancement du conteneur, Traefik va aller générer un certificat SSL auprès de letsencrypt et ensuite rediriger le service en https.
-=====Problème des bases de données=====
-La plupart des systèmes de base de données ne gèrent pas les accès concurrents au niveau de leurs fichiers. Il faut comprendre par là qu'il n'est pas possible de lancer deux processus mysql qui pointent vers les mêmes fichiers de configuration (/var/lib/mysql). Pour outre passer ce problème, il faut obligatoirement utiliser une solution de plus haut niveau qui va effectuer des synchronisations de données manuellement. Ces solutions sont lourdes à mettre en place. Dans le cadre de cette TX, nous avons volontairement fait le choix de nous passer de ce type de solution et  d'avoir des instances standalone de nos bases de données:\\
-  * Mysql pour le service etherpad
-  * PostgreSQL pour le service mattermost\\
-Des sauvegardes sont réalisées toutes les nuits. Cela nous permet de restaurer l'état de la base de données en cas de problème en limitant les pertes de données applicatives à 24h maximum.\\