English version available on: http://www.slideshare.net/PierreVincent3/microservices-docker-service-discovery-with-smartstack-english-version L'architecture en microservices vise à résoudre les problèmes auxquels font face les applications monolithiques. Dans un premier temps, cette présentation revient sur ces problématiques et sur la façon dont les microservices peuvent les réduire. On étudiera aussi pourquoi Docker se prête très bien à ce type d'architecture, tant sur la cohésion et l'isolation que sur les facilités de déploiements et de scaling. Cependant, décomposer une application en microservices engendre une certaine complexité liée aux systèmes distribués. Le service discovery est une nouvelle difficulté à laquelle cette architecture doit faire face, pour s'assurer que le système soit dynamique et résiste aux fautes (que ce soit au niveau logiciel, materiel ou réseau). Cette présentation explore plusieurs solutions possible pour le service discovery, avant de décrire de façon plus détaillée le framework Smartstack (Synapse / Nerve) et son intégration possible avec des microservices déployés en conteneurs Docker. Cette présentation a été faite dans le cadre du Docker Meetup à Rennes: http://www.meetup.com/Docker-Rennes Vous pouvez me suivre sur Twitter sur @PierreVincent ainsi que sur le Tech Blog de Newsweaver (http://techblog.newsweaver.com).

1. techblog.newsweaver.com
github.com/PierreVincent
@PierreVincent
pierrevincent
Microservices, Docker
& Service Discovery
avec Smartstack
Meetup - Docker Rennes
ISTIC, 28 Mai 2015
This work is licensed under a Creative Commons
Attribution 4.0 International License.

3. Déploiement
Microservices
Environnement de
Build
Tests d’intégration
Environnement de
Dev.

4. Microservices are small, autonomous
services that work together.
Sam Newman

5. Application
Monolithique
Ancrage
Technologique
Code complexe et
difficile d’accès
Refactoring difficile
Dette technique
croissante
Déploiement
disruptif
Problèmes en
production difficiles
à isoler
Options de scaling
limitées

6. Taille réduite
=
Cohésion forte
Autonomie et
isolation
=
Couplage faible
Indépendance
technologique
Isolation des fautes
=
Résilience
Réduction de
l’impact des
déploiements
Scaling spécifique

7. +
Microservices
Cohésion
1 conteneur = 1 microservice
Indépendance Technologique
Langage specifique au conteneur
Livraison
- Image docker (peu importe la techno)
- Docker registry
Couplage faible
Chaque conteneur est independant
Liberté de déploiement
Seulement besoin de Docker
Solutions d’orchestration
- Déploiements plus complexes
- Swarm, Compose, Kubernetes, Mesos...

8. Test / Validation
Systèmes distribués
Continuous
Delivery
Monitoring
Interfaces entre
services

9. Tout sur les microservices
Délimiter les microservices
Un peu de lecture !

10. Service Discovery
Organisation dynamique entre microservices

11. Nombre de services variable Services à courte durée de vie
Comment localiser les
services disponibles ?
Comment répartir la
charge entre les
instances ?
Comment savoir
qu’un service n’est
plus disponible ?

12. ❏ Enregistrement / Découverte
❏ Load Balancing
❏ Abstraction pour les clients
❏ Gestion proactive des erreurs
❏ Résilience aux problèmes exterieurs
❏ Pas de “Single Point of Failure”
Checklist

13. Recommendations
Service
Viewing History
Service
C*
.../users/123/recommendations
.../users/123/viewingHistory
{ “watched”: [
“Breaking Bad”,
…
]}
{“recommendations”: [
{
“watch”: “Better call saul!”,
“because”: [“Breaking Bad”]
},
...
]}

14. Recommendations
Service
Viewing History
Service
http://1.1.1.1/users/123/recommendations
services.properties
viewing_history_url = http://1.1.1.1
1.1.1.1
Solution 1: Dépendances en config.
Possibilité de volume partagé avec liste des services
et instances
Pas vraiment dynamique :
- service doit prendre en compte les
changements
- configuration doit être mise à jour
+
-

15. Recommendations
Service
Viewing History
Service
http://viewing-history/users/123/recommendations
/etc/hosts
1.1.1.1 viewing-history
1.1.1.1
Solution 2: Docker links
docker run
--named=viewing-history
viewing-history-service:latest
docker run
--named=recommendations
--link viewing-history:viewing-history
recommendations-service:latest
Simplicité pour les clients
Dépendances claires
Déploiment possible avec docker-compose
Manque de dynamisme :
- ordre prédefini
- difficile pour instances multiples
+
-

16. viewing-history.service
→ 1.1.1.1
Recommendations
Service
Viewing History
Service
http://viewing-history.service/users/123/recommendations
1.1.1.1
Solution 3: DNS
DNS
Simplicité pour les clients
DNS avec round-robin :
- instances multiples
- load balancing
Problèmes de propagation
+
-

17. [
viewing-history: 1.1.1.1
...
]
Recommendations
Service
Viewing History
Service
http://1.1.1.1/users/123/recommendations
1.1.1.1
Solution 4: Publisher / Subscriber
Key-value
Store
Dynamique :
- chaque instance s’enregistre
- les clients découvrent les instances
Mise en place d’un Key-value Store HA
Complexité pour les services
- Logique codées dans les services
+
-

18. [
viewing-history: 1.1.1.1
...
]
Recommendations
Service
Viewing History
Service
1.1.1.1
Solution 4: Publisher / Subscriber + Ambassadeur
Key-value
Store
http://1.1.1.1/users/123/recommendations
Très dynamique
Transparence pour Clients et Services
Mise en place d’un Key-value Store HA
+
-

19. Smartstack
Discovery framework et intégration avec Docker

20. github.com/airbnb/nerve
github.com/airbnb/synapse

21. Zookeeper
(Quorum)
Application
Viewing History Service
API Application
Recommendations Service
SynapseHAProxyNerve
Smartstack
Vue d’ensemble

22. Application
Nerve
ZK
1.1.1.1
nerve.conf
name = viewing_history
ip = 1.1.1.1
port = 8080
healthCheck = /health
Smartstack
Nerve
API
(8080)
/health
Viewing History Service

23. Application
Synapse
ZK
1.1.1.2
synapse.conf
viewing_history → 9000
Smartstack
Synapse
HAProxy
1.1.1.1
haproxy.conf
viewing_history:
frontend: localhost:9000
backends: [1.1.1.1:8080]
GET
http://localhost:9000/users/123/viewingHistory
8080 Services
viewing_history: [1.1.1.1:8080]
Recommendations Service
ping

24. Distribution de base
(ex. Ubuntu)
ruby
synapse (gem)
HA Proxy
nerve (gem)
service.jar
synapse.conf / nerve.conf
startup script
server.js + autres
startup script
Base Smartstack
startSynapse.sh
startNerve.sh
+ Techno
synapse.conf / nerve.conf + Code du service
+ Config

25. FROM smartstack-java
# Discovery
ADD nerve.conf.json /etc/
ADD synapse.conf.json /etc/
# JAR
ADD service.jar /opt/service/
# Startup
ADD start.sh /opt/start.sh
ENTRYPOINT ["/opt/start.sh"]
Dockerfile
#!/bin/bash
/opt/startSynapse.sh
/opt/startNerve.sh
java -jar service.jar
start.sh
$ docker build -t my-service .
...
$ docker run -d -e ZK_HOSTS=zk1:2181,zk2:2181 my-service

26. color-service
color-service
color-service
color-ui-service
blue
{
"name": "blue",
"hex": "0000FF"
}
{
"name": "red",
"hex": "FF0000"
}
{
"name": "green",
"hex": "00FF00"
}
Démo !

27. techblog.newsweaver.com
Questions ?
@PierreVincent