Konfiguration und Service Discovery für Microservices

.consulting .solutions .partnership
Konfiguration und Service Discovery für
Microservices
Alexander Schwartz, Principal IT Consultant
JAX 2016 – 20. April 2016

View Slide

Konfiguration und Service Discovery für Microservices
© msg | Konfiguration und Service Discovery für Microservices | Alexander Schwartz | JAX 2016 | 20. April 2016 2
Alltag in der Cloud
1
Archaius: Zugriff auf veränderliche Konfigurationen
2
etcd: Zentrale Konfigurationsdatenbank
3
Consul: Service Discovery, Konfiguration und Monitoring
4
Netflix Eureka: Availablity First!
5
Service Discovery im Vergleich
6

View Slide

Mein Sponsor und Arbeitgeber – msg systems ag
1980 gegründet
mehr als 5.500 Kollegen
727 Mio € Umsatz 2015
24 Länder
in 14 Städten
in Deutschland präsent

View Slide

Wer ich bin – Alexander Schwartz
14 Jahre Java
7 Jahre PL/SQL
7 Jahre
Absatzfinanzierung
3,5 Jahre Direktbank
1 Frau
2 Kinder
471 gefundene
Geocaches
@ahus1de

View Slide

Alltag in der Cloud
1
2
3
4
5
6

View Slide

Cloud Setup und Herausforderungen
Ein einfaches Cloud Setup
Wo sind meine Application Server?
Wo ist meine Datenbank?

View Slide


View Slide

Alltägliche Konfigurationsänderungen
Konfigurationen zur Laufzeit spart Zeit und Nerven – und vermeidet Wartungsfenster
• Parameter der Anwendung zur Laufzeit ändern
 Ziel-Adressen für Server
 Verzeichnisnamen
 Timeouts und fachliche Parameter
• Zentrale Datenbank
 Konfigurationsparameter
 Service-Discovery für Clients
 Service-Discovery für Load Balancer

View Slide

Alltag in der Cloud
1
2
3
4
5
6

View Slide

Netflix Archaius
Netflix Archaius regelt den Zugriff auf Parameter für Java-Clients
1. Laden von Konfigurationdaten
aus: Properties-Dateien, URLs, Datenbanken
2. Kaskadierte Konfigurationen
für: Standardeinstellungen, verschiedene Umgebungen,
einzelne Server
3. Typsicherer Zugriff auf den aktuellen Wert
4. Callbacks, wenn sich ein Wert ändert Quelle: http://en.wikipedia.org/wiki/Archaius_tigris
(CC) Hans Stieglitz

View Slide

Netflix Archaius
Beim Start kann zusätzlich eine Umgebung mitgegeben werden
java
-Darchaius.deployment.environment=test
...
# database.properties
db.url=jdbc:postgresql://localhost:5432/standard-db
# database-test.properties
db.url=jdbc:postgresql://localhost:5432/test-db
// Java Startup
ConfigurationManager.loadCascadedPropertiesFromResources("database");

View Slide

Netflix Archaius
Die Java-Anwendung wird mit Angabe der Konfigurationsdatei gestartet
java
-Darchaius.configurationSource.additionalUrls=file:///.../archaius.properties
-Darchaius.fixedDelayPollingScheduler.delayMills=1000
-Darchaius.fixedDelayPollingScheduler.initialDelayMills=1000
–jar application.jar
# archaius.properties
app.timeout=1000
app.url=http://myserver:3000/

View Slide

// construct type safe accessor for property
DynamicIntProperty timeoutProperty =
DynamicPropertyFactory.getInstance()
.getIntProperty("app.timeout", 10);
// access current value
int timeout = timeoutProperty.get();
// get notified once the value changes
timeoutProperty.addCallback(() -> {
System.out.println("property has changed: " + property.get());
});
Netflix Archaius
Archaius ermöglicht typsicheren Zugriff auf den aktuellen Wert
Callbacks werden aufgerufen, wenn sich ein Parameterwert ändert.

View Slide

Netflix Archaius
Konfigurationsquellen für Konfigurationen in Archaius
Klassische Konfigurationsquellen:
• Properties-Dateien, JDBC
Cloud-Blob-Storage:
• Amazon S3, Amazon Dynamo DB, Microsoft Azure Blob, Google Cloud Storage
Konfigurationsserver:
• Etcd, Zookeeper
Custom Setup:
• API für eigene Lösungen
(ca. 150-200 Zeilen Code für eine Integration, z. B. für Consul)

View Slide

Netflix Archaius
Überlegungen Pro und Kontra Archaius
Pro:
• Konfigurationen können wie gehabt als Datei ausgerollt werden
(z. B. mit Chef, Puppet, Ansible, Salt)
• Verschiedene Ablagemöglichkeiten außer Dateien werden unterstützt
• Hierarchische Struktur vereinfacht die Konfiguration
• Erprobte Bibliothek basierend auf der Apache Commons Configuration API
• Callback-Funktion ermöglicht komplexe Rekonfiguration
Kontra:
• Zeitgleiche konsistente Änderung mehrerer Parameter kann je nach Ablageart eine Herausforderung
sein
Ähnliche Projekte und Weiterentwicklungen:
Apache DeltaSpike, Apache Commons Configuration 2.0 und Archaius 2.0, Apache Tamaya

View Slide

17
© msg | Konfiguration und Service Discovery für Microservices | Alexander Schwartz | JAX 2016 | 20. April 2016
Alltag in der Cloud
1
2
3
4
5
6

View Slide

CoreOS etcd
etcd ist eine zentrale Konfigurationsdatenbank
Geeignet für Konfiguration und Service Discovery
• Einfach: HTTP/REST mit JSON
• Zuverlässig: hochverfügbar und konsistent
• Sicher: optional mit SSL-Client-Zertifikaten
• Schnell: mehrere Tausend Schreiboperationen pro Sekunde
Operationen: GET/PUT/DELETE/CAS/WAIT/TTL
# PUT
curl -L -X PUT http://127.0.0.1:4001/v2/keys/foo-service/container1 –d value="localhost:1111"
# GET
curl -L http://127.0.0.1:4001/v2/keys/foo-service/container1
# WAIT
curl -L http://127.0.0.1:4001/v2/keys/foo-service?wait=true\&recursive=true

View Slide

CoreOS etcd + Hightower´s confd
Wenn sich Werte in etcd ändern, aktualisiert confd die Konfiguration
confd

View Slide

CoreOS etcd + Hightower´s confd
Wenn sich Werte in etcd ändern, aktualisiert confd die Konfiguration
• Service-Beschreibung (*.toml)
• Vorlage für die Konfigurationsdatei (*.tmpl)
# nginx.toml
[template]
src = "nginx.tmpl"
dest = "/etc/nginx/sites-enabled/app.conf"
keys = [ "/foo-service" ]
check_cmd = "/usr/sbin/nginx -t"
reload_cmd = "/usr/sbin/service nginx reload"
# nginx.tmpl
upstream app_pool {
{{ range getvs "/foo-service/*" }}
server {{ . }};
{{ end }}
}
confd

View Slide

CoreOS etcd + Jurmous´ Java Client
Jurmos Java Client spricht etcd über ein Java API an
• Java-API für alle etcd-Funktionen
• Implementiert auf Basis von Netty (für asynchrones, non-blocking IO)
// Simple put
etcd.put("/foo-service/container1","localhost:1111").send();
// Wait for next change on foo
EtcdResponsePromise promise = etcd.getDir("/foo-service/")
.recursive().waitForChange().send();
// Java 8 lambda construction
promise.addListener(promise -> {
// do something with change
});

View Slide

CoreOS etcd
Überlegungen Pro und Kontra etcd
Pro:
• Einfacher Zugriff (REST), einfache Installation (Go-Binary), Transport-Sicherheit (SSL)
• Änderungen werden sofort an die Clients weitergegeben
• Generische Struktur für flexiblen Einsatz
• Einsatz innerhalb von CoreOS und Kubernetes
Kontra:
• Keine Zugriffsbeschränkung für einzelne Clients
Ergänzungen:
• Vulcan (HTTP Load Balancer, Konfigurationsablage in etcd)
• SkyDNS (Servicediscovery über DNS, Datenablage in etcd)

View Slide

23
Alltag in der Cloud
1
2
3
4
5
6

View Slide

Hashicorp Consul
Consul
Geeignet für Service Discovery, Konfiguration und Monitoring
• Einfach: HTTP/REST mit JSON
• Zuverlässig: hochverfügbar und konsistent
• Sicher: eingebaute Access Control Lists und Verschlüsselung
Haupt-Sponsor: HashiCorp (die, die auch Vagrant machen)
Homepage: https://www.consul.io/

View Slide

Netflix Ribbon
Ribbon
Geeignet für Client-Seitiges Load-Balancing
• Ribbon arbeitet gut zusammen mit Feign: Typsichere Web-APIs
Haupt-Sponsor: Netflix
Homepage: https://github.com/Netflix/ribbon/

View Slide

Consul und Ribbon
Der Client nimmt direkt Verbindung mit dem funktionierenden Service auf
Consul-Server
(für Key-Value-Store
und Service-Catalog)
Services
Client

View Slide

Services mit Consul
Jede Consul Instanz kennt ihre lokalen Services
"service": {
"name": "web",
"tags": ["master"],
"port": 80
}

View Slide

Services mit Consul
Jede Consul Instanz prüft sich und ihre lokalen Services
"check": {
"id": "http",
"name": "HTTP API on port 80",
"http": "http://localhost:80",
"service_id": "web",
"interval": "10s",
"timeout": "1s"
}
"check": {
"id": "script",
"name": "Script Check",
"script": "/usr/local/bin/check_mem.py",
"interval": "10s"
}
"check": {
"id": "ttl",
"name": "Web Status",
"ttl": "30s"
}

View Slide

Services mit Consul
Consul UI

View Slide

Services mit Consul
Services finden per DNS mit SRV Record
$ dig @127.0.0.1 -p 8600 web.service.dc1.consul. SRV
web.service.dc1.consul. 0 IN SRV 1 1 80 web2.node.dc1.consul.
web.service.dc1.consul. 0 IN SRV 1 1 80 web1.node.dc1.consul.
web1.node.dc1.consul. 0 IN A 192.168.23.21
web2.node.dc1.consul. 0 IN A 192.168.23.22

View Slide

Consul und Ribbon
Anwendungs-Code für Ribbon
MyService api = Feign.builder()
.contract(new JAXRSContract())
.encoder(new JacksonEncoder())
.decoder(new JacksonDecoder())
.client(RibbonClient.builder()
.lbClientFactory(new ConsulLbFactory())
.build())
.target(MyService.class, "http://web");
api.call();

View Slide

public class ConsulLbFactory implements LBClientFactory {
private Map clients = new HashMap<>();
public synchronized LBClient create(String clientName) {
LBClient client = clients.get(clientName);
if(client == null) {
ILoadBalancer lb = new ConsulLoadBalancer(clientName);
IClientConfig clientConfig = new DefaultClientConfigImpl();
clientConfig.loadDefaultValues();
client = LBClient.create(lb, clientConfig);
clients.put(clientName, client);
}
return client;
}
}
Consul und Ribbon
Java-API für Consul
public class ConsulLoadBalancer extends BaseLoadBalancer {
public ConsulLoadBalancer(String serviceName) {
Consul consul = Consul.builder().build();
HealthClient client = consul.healthClient();
ServiceHealthCache svHealth = ServiceHealthCache.newCache(client, serviceName);
svHealth.addListener(map -> {
List newServers = new ArrayList<>();
map.forEach((hostAndPort, serviceHealth) ->
newServers.add(new Server(hostAndPort.getHostText(),
hostAndPort.getPort())));
setServersList(newServers);
});
/* ... */
}
}

View Slide

Consul und Ribbon
Überlegungen Pro und Kontra Service Discovery mit Consul
Pro:
• Kontakt zu Services ohne Single Point of Failure
• Fertige Bibliotheken verfügbar
• Dezentrales Monitoring von Services
• GUI für Key-Value-Store und Monitoring
• Zusätzliche Semantik für Services (statt nur Key-Value-Store)
Ergänzungen:
• eBay Fabio (HTTP Load Balancer, Konfigurationsablage in Consul)
• consul-template (schreibt Konfigurationsdateien analog zu confd)
• Nomad (Scheduler, der Services automatisch in Consul registriert)

View Slide

34
Alltag in der Cloud
1
2
3
4
5
6

View Slide

Netflix Eureka
Eureka
Gebaut für Service Discovery innerhalb von AWS
• REST: Wahlweise mit JSON oder XML
• Einfach: Client-Pull für Clients
• Zuverlässig: hochverfügbar, Verfügbarkeit vor Konsistenz
Hauptentwickler: Netflix
Homepage: https://github.com/Netflix/eureka

View Slide

Netflix Eureka
Brewers CAP Theorem
„Ein verteiltes System kann zwei der folgenden Eigenschaften gleichzeitig erfüllen, jedoch nicht alle drei.“
Konsistenz (C = consistency)
Hier: Wenn sich ein Service registriert hat, können alle anderen Teilnehmer anschließend diesen Service
finden (auch: Linearisierbarkeit).
Verfügbarkeit (A = availability)
Hier: Service-Registrierung und -Lookup können durch Clients ausgeführt werden.
Partitionstoleranz (P = partition tolerance)
Hier: Service-Registrierung und -Lookup sind möglich, auch wenn
Netzwerkverbindungen teilweise unterbrochen sind.

View Slide

Netflix Eureka
Eureka – Verfügbarkeit wichtiger als Konsistenz (1/2)
Etcd:
• Registrierung: CP
• Lookup: AP (Standard) oder CP („?quorum=true“)
Consul:
• Registrierung:
CP für Key-Value-Store
AP für Service-Registrierung und Health und über lokalen Agenten („Anti-Entropy“)
CP für das Zusammenführen der Informationen in der Service-Registry
• Lookup via REST API: wahlweise CP („?consistent“),
bei einem bekannten Leader oder AP („?stale“)
• Lookup via DNS: bei einem bekannten Leader,
alternativ AP mit oberer Zeitgrenze mit „stale reads“

View Slide

Netflix Eureka
Eureka – Verfügbarkeit wichtiger als Konsistenz (2/2)
Eureka:
• Registrierung für Services: AP (ein Client meldet sich an einer Server-Instanz an und publiziert alle 30
Sekunden seinen aktuellen seinen Status)
• Lookup für Services: AP (ein Client sieht die Sicht seines Servers)
• „Self-Preservation“ bei vermuteter Netzwerkpartition Server/Server oder Clients/Server:
Der Server behält seinen Status der bereits bekannten Services

View Slide

Netflix Eureka
Eureka – Pull und Cache statt Query und Push (1/2)
Etcd:
• Service-Lookup mit HTTP GET als synchroner Aufruf
• Warten auf Änderungen mit HTTP GET blocking query („?wait=true&waitIndex=X“)
Consul:
• Service-Lookup mit HTTP GET als synchroner Aufruf
• Service-Lookup mit HTTP GET als blocking query („?wait=Xs&index=Y“)

View Slide

Netflix Eureka
Eureka – Pull und Cache statt Query und Push (2/2)
Eureka:
• Clients holen alle 30 Sekunden das Delta der Service-Registry vom Server
• Server holen alle 30 Sekunden das Delta der anderen Server
• Service-Lookup ist eine Client-lokale Operation
• Weitergabe von Änderungen kann bis zu 2 Minuten dauern
(Lookup mit HTTP GET als synchroner Aufruf ist über das API möglich)

View Slide

41
Alltag in der Cloud
1
2
3
4
5
6

View Slide

Favorit Service Discovery
Capability Matrix
Etcd Consul Eureka
Konfigurationen Ja Ja Nein
Service Discovery
via REST-API
Ja
(via KV-Store)
Ja Ja
Konfigurationsdateien
schreiben
Ja
(via confd)
Ja
(nativ und confd)
Nein
Dynamic DNS Ja
(via SkyDNS)
Ja
(nativ)
Nein
Topologie Unterstützung Nein Ja (Datacenter
& WAN)
Ja
(Region & Zone)
Zugriffskontrolle SSL Client-Zertifikate Detailliert (ACLs) Servlet-Security
Health Checks für Services Nein Ja Nein
Edge Service (Vulcan) (Fabio) (Zuul)
GUI Nein Ja Nein

View Slide

Wer ist der Favorit?
Etcd – hochverfügbarer und konsistenter Key-Value-Store
• Bereits mit ausgeliefert bei CoreOS
• Einfach zu nutzendes REST-API
Consul – Services als „First Class Citizen“ zusätzlich zum Key-Value-Store
• Aktives Monitoring der Services
• Sicherheit eingebaut: Transportverschlüsselung und ACLs
Eureka – Gebaut für die Amazon Cloud
• Sehr gute Integration in die Amazon Infrastruktur
• Zeitverzögerte Replikation des kompletten Service-Katalogs an die Clients (Client Pull)
• Verfügbarkeit geht vor Aktualität und Konsistenz
@ahus1de

View Slide

Links
Netflix Archaius: https://github.com/Netflix/archaius
Apache Commons Configuration:
http://commons.apache.org/proper/commons-configuration/
Übersicht über verschiedene Methoden:
http://javaeeconfig.blogspot.de/2014/08/
overview-of-existing-configuration.html
HashiCorps Consul für Service Discovery,
Monitoring und Konfigurationsmanagement
http://heise.de/-3040847
eBay Fabio:
https://github.com/eBay/fabio
Nomad:
https://www.nomadproject.io/
Saltstack and Consul Examples
https://github.com/ahus1/saltconsul-examples @ahus1de
CoreOS etcd: https://github.com/coreos/etcd
Jurnous etcdj: https://github.com/jurmous/etcd4j
Vulcan: http://www.vulcanproxy.com/
SkyDNS: https://github.com/skynetservices/skydns
Netflix Eureka: https://github.com/Netflix/eureka
Apache Zookeeper: https://zookeeper.apache.org/
Netflix exhibitor: https://github.com/Netflix/exhibitor
HashiCorp Consul: http://consul.io/

View Slide

.consulting .solutions .partnership
Alexander Schwartz
Principal IT Consultant
+49 171 5625767
[email protected]
@ahus1de
msg systems ag (Headquarters)
Robert-Buerkle-Str. 1, 85737 Ismaning
Germany
www.msg-systems.com

View Slide

Konfiguration und Service Discovery für Microservices

Konfiguration und Service Discovery für Microservices

Alexander Schwartz

More Decks by Alexander Schwartz

Other Decks in Technology

Featured

Transcript