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