Post on 09-Aug-2015
techblog.newsweaver.com
github.com/PierreVincent
@PierreVincent
pierrevincent
Microservices, Docker & Service Discovery
avec Smartstack
Meetup - Docker RennesISTIC, 28 Mai 2015
This work is licensed under a Creative Commons Attribution 4.0 International License.
DéploiementMicroservices
Environnement de Build
Tests d’intégration
Environnement de Dev.
Microservices are small, autonomous services that work together.
Sam Newman
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
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
+
Microservices
Cohésion1 conteneur = 1 microservice
Indépendance TechnologiqueLangage specifique au conteneur
Livraison- Image docker (peu importe la techno)- Docker registry
Couplage faibleChaque conteneur est independant
Liberté de déploiementSeulement besoin de Docker
Solutions d’orchestration- Déploiements plus complexes- Swarm, Compose, Kubernetes, Mesos...
Test / Validation
Systèmes distribués
ContinuousDelivery
MonitoringInterfaces entre
services
Tout sur les microservices
Délimiter les microservices
Un peu de lecture !
Service DiscoveryOrganisation dynamique entre microservices
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 ?
❏ 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
Recommendations Service
Viewing HistoryService
C*
.../users/123/recommendations
.../users/123/viewingHistory
{ “watched”: [ “Breaking Bad”, … ]}
{“recommendations”: [ { “watch”: “Better call saul!”, “because”: [“Breaking Bad”] }, ...]}
Recommendations Service
Viewing HistoryService
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
+
-
Recommendations Service
Viewing HistoryService
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
+
-
viewing-history.service → 1.1.1.1
Recommendations Service
Viewing HistoryService
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
+
-
[ viewing-history: 1.1.1.1 ...]
Recommendations Service
Viewing HistoryService
http://1.1.1.1/users/123/recommendations
1.1.1.1
Solution 4: Publisher / Subscriber
Key-valueStore
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
+
-
[ viewing-history: 1.1.1.1 ...]
Recommendations Service
Viewing HistoryService
1.1.1.1
Solution 4: Publisher / Subscriber + Ambassadeur
Key-valueStore
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
+
-
SmartstackDiscovery framework et intégration avec Docker
github.com/airbnb/nerve
github.com/airbnb/synapse
Zookeeper(Quorum)
Application
Viewing History Service
API Application
Recommendations Service
SynapseHAProxyNerve
Publication
Discovery
SmartstackVue d’ensemble
Application
Nerve
ZK
1.1.1.1
nerve.confname = viewing_historyip = 1.1.1.1port = 8080healthCheck = /health
Publicatio
n
SmartstackNerve
API(8080)
/health
Viewing History Service
Application
Synapse
ZK
1.1.1.2
synapse.confviewing_history → 9000
Discov
ery
SmartstackSynapse
HAProxy
1.1.1.1
haproxy.confviewing_history: frontend: localhost:9000 backends: [1.1.1.1:8080]
GEThttp://localhost:9000/users/123/viewingHistory
8080 Servicesviewing_history: [1.1.1.1:8080]
Recommendations Service
ping
Distribution de base(ex. Ubuntu)
ruby
synapse (gem)
HA Proxy
nerve (gem)
service.jarsynapse.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
FROM smartstack-java
# DiscoveryADD nerve.conf.json /etc/ADD synapse.conf.json /etc/
# JARADD service.jar /opt/service/
# StartupADD start.sh /opt/start.shENTRYPOINT ["/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
color-service
color-service
color-serviceGET .../v1/color
color-ui-service
blue
{ "name": "blue", "hex": "0000FF"}
{ "name": "red", "hex": "FF0000"}
{ "name": "green", "hex": "00FF00"}
Démo !
techblog.newsweaver.com
Questions ?
@PierreVincent