Immer mehr Unternehmen zerlegen ihre Softwaresysteme in kleine Microservices. Wenn man seine Software in Microservices zerlegt hat, erhält man unweigerlich mehrere Deployment-Artefakte, was das Deployment des Gesamtsystems aber auch komplexer macht. Um diese Komplexität beherrschen zu können, ist der Einsatz von Werkzeugen zur Infrastrukturautomatisierung unumgänglich. Schauen wir uns deshalb an einem Microservice-Architekturbeispiel an, wie man diese Komplexität mit verschiedenen auf Docker basierenden Werkzeugen beherrschen kann. Werkzeuge, wie Kubernetes und Vamp (Mesos + Marathon), bieten dabei eine perfekte Basis, um ein verteiltes System aufzubauen und hochverfügbar zu betreiben können.

1. Bernd Zuther | codecentric AG
Von Null auf Hundert mit
Microservices

6. Data
Functionality
Microservice
6/45

7. Data
Functionality
Microservice
fits in one
brain,
·
6/45

8. Data
Functionality
Microservice
fits in one
brain,
designed for
replaceability,
·
·
6/45

9. Data
Functionality
Microservice
fits in one
brain,
designed for
replaceability,
autonomy
(organisation &
technology)
·
·
·
6/45

10. Microservice Taxonomy
Microservice
Application
Frontend
Service
Service
Repository /
Orchestration
Service
Discovery
Contract Implementation Interface
Business
Logic
Data
Monitoring /
Logging
7/45

11. Microservice Architecture

12. Processes
bz@cc:~/$ ps aux
www-data 1699 0.5 7.7 2453320 158076 ? Sl 10:49 0:26 java -cp cart.jar
www-data 1834 0.3 5.0 2435400 102684 ? Sl 10:49 0:17 java -cp navigation.jar
www-data 1972 0.0 0.1 90792 3124 ? Ss 10:49 0:00 nginx: master process
www-data 1973 0.0 0.1 91148 3820 ? S 10:49 0:00 nginx: worker process
www-data 1974 0.0 0.1 91148 3820 ? S 10:49 0:00 nginx: worker process
www-data 1975 0.0 0.1 91148 3820 ? S 10:49 0:00 nginx: worker process
www-data 1976 0.0 0.1 91148 3820 ? S 10:49 0:00 nginx: worker process
www-data 1980 1.5 7.0 2456532 143688 ? Sl 10:49 1:20 java -cp product.jar
BASH
9/45

13. Online Shop - Deployment
<<device>>
Microservice Server
<<web server>>
Ngnix
<<service>>
Cart Service
<<service>>
Product
Service
<<device>>
Monolith Server
<<application server>>
Tomcat
<<artifact>>
shop.war
<<artifact>>
Catalog View
<<artifact>>
cart-service.jar
<<artifact>>
product-
service.jar
Cart
Catalog
Product
10/45

15. Linux Packages
bz@cc:~/$ ar t cart_0.6.20.deb
debian-binary
control.tar.gz
data.tar.gz
bz@cc:~/$ tar tzf data.tar.gz
./etc/default/cart
./etc/init.d/cart
./usr/share/shop/cart/bin/cart
./usr/share/shop/cart/bin/cart.bat
./usr/share/shop/cart/lib/cart-microservice-0.6.20.jar
bz@cc:~/$ tar tzf control.tar.gz
./postinst
./control
./md5sums
bz@cc:~/$ cat debian-binary
2.0
BASH
12/45

16. Control File
Source: shop-cart-service
Section: web
Priority: optional
Version: 4.2.42
Maintainer: Bernd Zuther
Homepage: http://www.bernd-zuther.de/
Vcs-Git: https://github.com/zutherb/AppStash.git
Vcs-Browser: https://github.com/zutherb/AppStash
Package: shop-cart-service
Architecture: amd64
Depends: redis-server (>= 2.8.13)
Description: Cart Service
VIM
13/45

17. Package Source
Buildserver
Provision
reprepro -Vb /var/packages/debian includedeb shop /tmp/*.deb
reprepro -b /var/packages/debian/ export
reprepro -b /var/packages/debian/ list shop
BASH
---
- apt_repository: repo='deb http://ci-repo/debian/ shop main' state=present
- apt: update_cache=yes force=yes
- apt: pkg={{item}} state=present force=yes
with_items:
- shop-cart-service
YAML
14/45

18. Linux Packages
Pro Contra
Service Repository No Service Discovery
Dependency Management Runtime enviroment must be created on
every single node
Technologies are battle-tested Depends on the linux distribution

20. Docker

21. Docker-File
FROM relateiq/oracle-java8
MAINTAINER Bernd Zuther <bernd.zuther@codecentric.de>
EXPOSE 18080
ADD product-0.6.tar /
ENTRYPOINT ["/product-0.6/bin/product"]
BASH

22. Docker-Workflow
bz@cc1 $ docker build -t zutherb/product-service .
bz@cc1 $ docker push zutherb/product-service
bz@cc2 $ docker pull zutherb/product-service
bz@cc2 $ docker run zutherb/product-service
bz@cc2 $ docker ps
CONTAINER ID IMAGE COMMAND CREATED
87bb5524067d zutherb/product-service:latest "/product-0.6/bin/pr 14 seconds
BASH

23. Deployment Scenario
<<device>>
Docker Deamon
<<container>>
Ngnix
<<container>>
Cart Service
<<container>>
Product
Service
<<artifact>>
checkout
.war
<<artifact>>
catalog.tar
<<artifact>>
cart-service.jar
<<artifact>>
product-
service.jar
<<container>>
Tomcat
<<container>>
MongoDB
<<container>>
Redis
<<container>>
Navigation
Service
<<artifact>>
navigation-
service.jar

24. Linking
bz@cc ~$ docker run -d --name mongodb mongo
705084daa3f852ec796c8d6b13bac882d56d95c261b4a4f8993b43c5fb2f846c
bz@cc ~$ docker run -d --name redis redis
784ebde0e867adb18663e3011b3c1cabe990a0c906396fc306eac669345628cf
bz@cc ~$ docker run -d -P --name cart --link redis:redis zutherb/cart-service
438b2657c7a5c733787fb32b7d28e1a0b84ba9e10d19a8a015c6f24085455011
bz@cc ~$ docker run -d -P -p 8080:8080 --name shop --link cart:cart
--link mongodb:mongodb zutherb/monolithic-shop
9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e
bz@cc $ docker exec 9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=87bb5524067d
MONGODB_PORT_27017_TCP=tcp://172.17.0.28:27017
MONGODB_PORT_27017_TCP_ADDR=172.17.0.28
MONGODB_PORT_27017_TCP_PORT=27017
MONGODB_PORT_27017_TCP_PROTO=tcp
BASH

26. Docker Compose
redis:
image: dockerfile/redis
ports:
- "6379:6379"
cart:
image: eshop/cart-service
ports:
- "18100:18100"
links:
- redis
catalog:
image: eshop/catalog-frontend
ports:
- "80:80"
links:
- product
- cart
YAML
23/45

27. Docker
Pro Contra
Applications are isolated Daemon runs as root on host
Images are built once and run anywhere No Process Supervisor
Docker Repository No Service Discovery
Big ecosystem (Kubernetes, Mesos,
Vamp)

28. Blue Green Deployment
Old Version
Web
Server
Application
Server
Database
Server
New Version
Web
Server
Application
Server
Database
Server
RouterUsers
25/45

29. Canary Release
Old Version
Web
Server
Application
Server
Database
Server
New Version
Web
Server
Application
Server
Database
Server
RouterUsers
95%
5%
26/45

30. Microservice - Canary Release
Old Version
Web
Server
Application
Server
Database
Server
New Version
Web
Server
Application
Server
Database
Server
RouterUsers
Old Version
Web
Server
Application
Server
Database
Server
New Version
Web
Server
Application
Server
Database
Server
Old Version
Web
Server
Application
Server
Database
Server
New Version
Web
Server
Application
Server
Database
Server
27/45

32. Distributed System
Resource
Allocator
Executor Executor Executor
Scheduler
Docker
Repository
29/45

33. Kubernetes
Kublet Info
Service
Kublet Kublet Kublet
API Server
Docker
Repository
Scheduler
Resource
Allocator
Executor
30/45

34. Pod
apiVersion: v1
kind: Pod
metadata:
labels:
name: cart
role: backend
name: cart
spec:
containers:
- name: cart
image: zutherb/cart-service
ports:
- containerPort: 18100
YAML
31/45

35. Replication Controller
apiVersion: v1
kind: ReplicationController
metadata:
... (labels)
spec:
replicas: 2
selector:
name: cart
template:
metadata:
... (labels)
spec:
containers:
- name: cart
image: zutherb/cart-service
ports:
- containerPort: 18100
YAML
32/45

36. Service
33/45

37. Service
kind: Service
apiVersion: v1
metadata:
labels:
name: cart
role: backend
name: cart
spec:
ports:
- name: cart
port: 18100
selector:
name: cart
YAML
34/45

38. Kubernetes
Pro Contra
You needn't care where work is executed No description of the whole application (in
contrast to docker compose) and for
deployment scenario
You needn't care about dependencies Failure analysis will get harder
Service discovery Master is a single point of failure
Process Supervisor Few tools and documentation is avaiable
yet

39. Mesos
Mesos
Master
Mesos
Slave
Mesos
Slave
Mesos
Slave
Marathon
Docker
Repository
Scheduler
Resource
Allocator
Executor
Standby
Mesos
Master
Standby
Mesos
Master
Zookeeper
36/45

40. Marathon Deployment
{"id": "basic-3",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32.0,
"container": {
"type": "DOCKER",
"docker": {
"image": "python:3",
"network": "BRIDGE",
"portMappings": [
{ "containerPort": 8080, "hostPort": 0 }]}}}
YAML
curl -X POST http://10.141.141.10:8080/v2/apps -d @basic-3.json
-H "Content-type: application/json"
BASH
37/45

41. Marathon + Mesos
Pro Contra
You needn't care where work is executed No description of the whole application
and for deployment scenario
High Availability No Service Discovery
Process Supervisor Failure analysis will get harder
Many tools and documentation are
available

42. Very Awesome Microservices Platform (Vamp)
39/45

43. Vamp + Marathon + Mesos
Pro Contra
Description of the whole application and
for deployment scenario
Many components that have to be
understood
You needn't care where work is executed Failure analysis will get harder
High Availability
Process Supervisor
Service Discovery

44. Summary
Linux Packages Docker Daemon Kubernetes
Vamp + Marathon +
Mesos
Service Repository
Orchestration
(< 100)
Service Discovery
Process Supervisor
High Availability
Application
Description
Routing Definition

45. <Thank You!>
g+ plus.google.com/+BerndZuther
twitter @Bernd_Z
www bernd-zuther.de
github github.com/zutherb/

46. Demo + Slides Application

47. Links
Java Aktuell 02/15 - Microservices und die Jagd nach mehr Konversion
Microservice-Deployment ganz einfach mit Giant Swarm
Microservice-Deployment ganz einfach mit Kubernetes
Microservice-Deployment ganz einfach mit Docker Compose
Microservice-Deployment ganz einfach ohne Docker mit der Linux-
Paketverwaltung
Canary Release mit der Very Awesome Microservices Platform
Lean Startup
Test Driven Business Featuring Lean StartUp
Continuous Delivery mit dem FeatureToggle Pattern
FeatureToggle
Do Good Microservices Architectures Spell the Death of the Enterprise Service
Bus?
Microservices
·
·
·
·
·
·
·
·
·
·
·
·
44/45

48. Links
The Twelve Factors
Microservices im Zusammenspiel mit Continuous Delivery, Teil 1 – die Theorie
Fast, isolated development environments using Docker
Warnung vor dem Microservice – Versuch einer Definition
Micro Services in der Praxis: Nie wieder Monolithen!
Deployment ganz einfach – Microservice Deployment mit Hilfe der Linux
Paketverwaltung
Splunk – Marke Eigenbau mit Elasticsearch, Logstash und Kibana (ELK Stack)
Scaling Docker with Kubernetes
Container-Technik: Docker & Co.
Appstash Project
·
·
·
·
·
·
·
·
·
·
45/45