technique:architecture_des_services

Architecture des services

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. Les services sont répartis entre les deux machines virtuelles. Les backups réguliers et l’utilisation d’un volume GlusterFS permettent une reprise, en cas de panne d’une machine physique, sans perte de données.

Pour héberger les services, nous utilisons des conteneurs Docker que l’on manipulent avec Docker Compose. Pour plus d’info sur l’installation de Docker voir cet article, et pour des explications sur l’utilisation de Docker Compose voir la documentation officielle.

Notre infrastructure étant composé de 2 VM, chaque VM utilise un fichier docker-compose.yml pour définir les services qui sont lancés.

  traefik:
    image: traefik:latest
    command: --web --docker --logLevel=DEBUG --docker.watch
    container_name: traefik
    ports:
      - "80:80"
      - "8080:8080"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /DATA/pica01/traefik/traefik.toml:/traefik.toml
      - /DATA/pica01/traefik/certs:/certs
    restart: always

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

--name bdd

et un second avec le flag

--name apache

, 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.

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:

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

Ensuite, il suffit d’ajouter les étiquettes suivantes aux conteneurs pour générer la configuration adéquate

--label traefik.port=80 
--label traefik.frontend.rule=Host:team.picasoft.net 

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:

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"

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.

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.

  • technique/architecture_des_services.1494748872.txt.gz
  • (modification externe)