Adrien BlindDevOps Coach@adrienblind

Docker, cornerstone of an hybrid cloud ?

Rise of the orchestration

@adrienblind

Fine-grained, highly decoupled and atomic purpose centric services

Designedfor failure

Multi-versioned

Scalable

Micro services

Stateless

Share-nothingImmutable

Continuouslydelivered

Distributed

@adrienblind

Docker fits microservice paradigms‘’A universal, self-sufficient and standard artifact embedding an app module,

and its subsequent infrastructure configuration’’

Docker provides both the artifact and the ecosystem to handle it!

Immutable

Portable Lightweight

Incremental

Versionned/taggedDisposable

@adrienblind

App

From containers to appsAn application is made of several components

interacting each together

@adrienblind

From Enterprise Services busesto full-mesh topologies

ESB

Ser-vice

Ser-vice

Ser-vice

Ser-vice

Ser-vice

>Ser-vice

Ser-vice

Ser-vice

Ser-vice

Ser-vice

Service discovery challenge

App App

@adrienblind

Security paradigms shiftsThe necessary porosity of your IS requires to sticksecurity closer to each application: sandbox your apps

and expose protected interfaces!

Network is part of application topology Security is an app topic, not just infra. concern Onboard security in feature teamSecDevOps

@adrienblind

Vertical > horizontal

Apps designed for failure & scalability

Data to be externalized

Dumber infrastructure

Resilience & scalability: apps problem now!

Structured: MongoDB, Hadoop, Cassandra, Elastic Search... Binaries: object storage with Ceph, OpenStack Swift...

Helpful patterns: stateless, multi-versioning, loose coupling...

Infrastructure rationalization Low-cost, poor-SLA commodity

@adrienblind

Distributed applicationCompute (service/task)

Storage (volume) Transport (network)

Topology(compose, bundle,

deploy, stack)

Docker shifted from container infra. to object-oriented app. topologies

CaaS platformClustering (swarm)

Image mgmt(registry) Hosting (node)

Provisioning (machine)

... relying on an CaaS platform

The rise of the orchestration

@adrienblind

Docker 1.12 swarm mode

Directly over Internet ? Swarm mode secures interactions between its nodes (TLS mutual auth, authz, & encryption) Overlay network trafic may be encrypted across nodes too (use switch --opt encrypted to use IPSEC)

Built in the engine Decentralized More secured More resilient

@adrienblind

$ docker-machine create -d virtualbox m1$ docker swarm init --advertise-addr [m1_ip]

$ docker-machine create -d virtualbox m2$ eval $(docker-machine env m2)$ docker swarm join --token [mytoken] [m1_ip]:2377 \ --advertise-addr [m2_ip]$ docker swarm join-token workerTo add a worker to this swarm, run the following command: docker swarm join \ --token [TOKEN] [m1_ip]:2377

… (joined a third manager, plus a worker)

$ docker node lsID HOSTNAME STATUS AVAILABILITY MANAGER STATUS1o46ikaidagi91w940h81byd1 w1 Ready Active 3bboy53bjyeqd9ad0tsegju51 m2 Ready Active Reachable48yqo4607pfzkpct4jz9t1t9y m3 Ready Active Reachable6fyvwd6cc4nguth29ycexaxat * m1 Ready Active Leader

Cluster setup example

@adrienblind

Docker serviceDepicts the desired runtime behavior of a given image : networking, resiliency, quotas... shift to state-machine paradigms$ docker service create --name front -–network app \ –-replicas 3 -p 80:80/tcp nginx:latest

Attach the containers to a given networkDefine the desired amount of instances for this service (named « tasks »)Attach each instance to a transversal L4 loadbalancer instance, reachable on each node of the cluster

@adrienblind

Example

$ docker network create --driver overlay wordpressnet

$ docker service create --name wordpressdb --env MYSQL_ROOT_PASSWORD=plop \ --env MYSQL_DATABASE=wordpress --network wordpressnet mysql:latest

$ docker service create --name wordpressapp --env WORDPRESS_DB_HOST=wordpressdb \ --env WORDPRESS_DB_PASSWORD=plop --network wordpressnet --publish 80:80 \ --replicas 7 wordpress:latest

$ docker service lsID NAME REPLICAS IMAGE COMMAND14utiklw5g6s wordpressdb 1/1 mysql:latest c9vnvebcylg5 wordpressapp 7/7 wordpress:latest

$ docker service update --replicas 4 wordpressapp

@adrienblind

Example

LB LB LB LB

Network

Dynamic LB on each manager + workers hosting containers of the app

All containers belonging to a same app are connected through an overlay network

Overlay network

@adrienblind

Docker stack

docker-compose enabled to depicts and trigger a complete app topology from the client side

docker stack enables to feed the server-side orchestrator with a complete app topology

Hybridate clouds

@adrienblind

Almost all cloud vendors provide their own complete, ready-to-use docker CaaS stacks: Amazon ECS, Beanstalk Azure Container Service Google Container Engine

Beyond traditionnal IaaS, the much integrated & valuable service you get, the more locked-in you are Balance your args (portability, cost, etc.) No universal answer…

Cloud provider hybridation

@adrienblind

You may create your own docker Swarm CaaS leveraging on several providers Your own traditional DC Various Cloud vendors

You may even use docker tools to automate everything docker-machine create --driver azure --azure-subscription-id [MY_ID]

Cloud provider hybridation

@adrienblind

Not only interesting for portability & freedom

Progressive cloud migration Elasticity / overflooding Multiply points of presence Keep docker native ergonomy easing adoption « cloud hoster trading? » ;) …

Cloud provider hybridation

@adrienblind

Scale the application through docker service replicas

Scale the swarm cluster capacity leveraging on docker-machine

Scale up, scale down

AVOID CONFUSION

Hybridate technos

@adrienblind

Windows containers are here!Two Windows Containers types: Windows Server Containers, that are similar than Linux containers in the concepts Hyper-V Containers, that runs inside a small virtual machine on Hyper-V

https://blogs.msdn.microsoft.com/jcorioland/2016/10/13/getting-started-with-windows-containers

@adrienblind

What Tiny servers based on ARM architecture Poor per-core perf but up to 54 cores per SoC + good I/Os

Why / Pros Green IT: better perf/watt & density ratio Cost efficiency for massive threading usecases:

bigdata/grids/horizontally scalable apps.

Pitfalls / Cons Litteraly rebuild apps for ARM Only fits some usecases, not a silverbullet!

ARM: end of the x86 hegemony ?

ARM v8 architectureUp to 54 cores/SoC + 1TB RAMCavium srv: 384 cores enclosed in 2U

@adrienblind

Hybrid orchestration

App 3

App 2

App 1

X64/WIN X64/LINUX ARM/LINUX

Extend the picture ARM computing rises Windows containers arrives

The app topology integrates various techs which must be orchestrated together

Example demo

Initially co-built with Ludovic Piot (@lpiot) for a live demo given at Docker Meetup Paris

@adrienblind

Cloud hybridation

Raspberry(ARM)

Win 2016SWARMCLUSTER

Load injector (Apache AB) IIS Website MySQL Backend Overlay network

LinuxX86_64

LinuxX86_64

LinuxX86_64

LinuxX86_64

LinuxX86_64

INTERNET

REDIS

Use constraints on services to enforce containers location

@adrienblind

A real, hybrid docker clusterARM/Linux

x86_64/Linux

x86_64/Winx86_64/Linux

@adrienblind

Spawning docker services

@adrienblind

Scale the app up & down

Conclusion

@adrienblind

Orchestration is more than ever the key ; now handle multi-technologies dockerized apps

You may wish to keep control while delegating commodities

Docker swarm enables to create an abstraction layer to facilitate transition to the cloud or multi-cloud handling

Conclusion

@adrienblind

Step 1 Shift to docker packaging pardigmes Start deploying your apps through docker (trough CD pipelines

for instance) Step 2

Shift to dynamic orchestration: swarm cluster handles container deployments over the cluster, ensures desired instances are up, etc.

Step 3 Extend your local own cluster to third-part vendors

Step 4 Shift to self-healing clusters (autoscaling nodes for instance)

Plan your migration

Adrien BlindDevOps Coach@adrienblind

Thank you!