Paris Container Day 2016 : Architecture microservices hautement disponible au sein d’un cluster swarm (Xebia)

@ContainerDay16 @jlrigau @tauffredou

Architecture microservices hautement disponible au sein d’un cluster Swarm


Jean-Louis RIGAU@jlrigau

Continuous Delivery, DevOps and Docker@ Xebia IT Architects

Thomas AUFFREDOU@tauffredou

Continuous Delivery, DevOps and Docker@ Xebia IT Architects


Contexte

La startup Tromb'In souhaite révolutionner le marché des réseaux sociaux en proposant une application de trombinoscope offrant une fonctionnalité de vote innovante.

Elle a fait le choix de développer son application en s’appuyant sur une architecture microservices et de gérer l’ensemble de son infrastructure sur Amazon AWS.

Elle a entendu parler de Docker et souhaite mettre en place une solution d’orchestration de conteneurs résiliente et scalable pour déployer son application.


Trombinoscope


● Identity○ Affiche une identité : nom + photo○ Permet de voter○ Génère un évènement à chaque vote

● Messaging Channel○ Redis en Publish/Subscribe

● Service Discovery○ Liste l’ensemble des applications Identity

● Trombinoscope○ Liste l’ensemble des identités○ Affiche le nombre de votes (Hit/Sec)

Une application, plusieurs services


Architecture globale

Messaging Channel

Identity

Service Discovery

Trombinoscope

Identity Identity

IdentityIdentity

Identity

<publish>

<register>

<subscribe>

<discover>


“Microservices”

● 1 identité = 1 service

● Composition de services● Mécanisme de Service Discovery● Architecture orientée évènements● Paradigme de message

Publish/Subscribe


● Mise en place d’un cluster Docker Swarm○ 3 masters en quorum + 5 nodes

● Utilisation de Consul comme KV-Store○ Configuration du cluster + Overlay Network

● Service discovery avec Interlock avec Nginx○ Exposition de l’ensemble des services

● Load Balancing avec Amazon ELB○ masters sur le port 3375○ nodes sur le port 80

● Gestion des DNS avec Route 53○ admin○ *.service

Choix d’infrastructure


Schéma d’infrastructure

node #2 node #3 node #4 node #5

master #1 master #2 master #3

Docker Engine Docker Engine Docker Engine

node #1

Docker Engine

Interlock

Docker Engine

Interlock

Docker Engine

Interlock

Docker Engine

Interlock

Docker Engine

Interlock

Elastic Load Balancing

Elastic Load BalancingAmazon Route 53

Amazon Route 5380:80

*.service

3375:3375admin

Masters

Nodes


Workflow de mise en oeuvre

Création de l’infrastructure Provisioning Déploiement


Création de l’infrastructure avec Terraform


Création de l’infrastructure

● Entièrement sur Amazon AWS● Terraform pour automatiser la création de l’infrastructure

○ Instances Amazon EC2○ Security Groups○ Elastic Load Balancing○ Règles Route 53

● Nombre d’instances configurable

$ make launch-infra


Provisioning des instances avec Ansible


Génération de l’inventaire

● Génération de l’inventaire pour Ansible○ à partir des données de Terraform○ script en javascript pour la conversion

$ make terraform-to-ansible


Provisioning des instances

● Provisioning des instances avec Ansible○ Installation de docker○ Configuration du cluster○ Déploiement de conteneurs de base

$ make configure


Déploiement de l’application avec Docker Compose


Déploiement de l’application

● Compilation en utilisant un conteneur de build● Création des images applicatives● Stockage des images sur le Docker Hub● Déploiement avec Docker Compose

$ docker-compose up -d


Scalabilité de l’application avec Docker Compose


Scalabilité ?

Service Discovery

Trombinoscope

<register><discover>

interlockIdentity

Identity

Identity

80:80*.service

3375:3375admin


Scalabilité de l’application

● Ajout de nouvelles instances avec Docker Compose

$ docker-compose scale jlrigau=3 tauffredou=3


Sourceshttps://github.com/xebia-france/xke-haswarm


Q&A

Technology

Paris Container Day 2016 : Architecture microservices hautement disponible au sein d’un cluster swarm (Xebia)