The following talk discusses the opportunity to leverage on docker to create an hybrid logical cloud built simultaneously on top of traditionnal datacenters and public cloud vendors and enabling to manage new kind of containers (Windows, linux over ARM). It also discusses the value of such capacity for applications in a contexte of topology orchestrations and micro service oriented applications.
3. @adrienblind
Fine-grained, highly decoupled and
atomic purpose centric services
Designed
for failure
Multi-versioned
Horizontally
scalable
Micro services
Stateless
Share-nothing
Immutable
Continuously
delivered
Distributed
4. @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
5. @adrienblind
Application
From containers to application topologies
An application is made of several components interacting each together
Microservice A
Microservice B
Hadoop cluster
Third-part service
ambassador
6. @adrienblind
From Enterprise Services buses to full-mesh topologies
Service Service Service
Service Service
>
ServiceService
Service
Service
Service
Service discovery challenge
App App
ESB
7. @adrienblind
Network challenge
The necessary porosity of your IS requires to stick security 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
8. @adrienblind
Distributed application
Compute (service/task)
Storage (volume) Transport (network)
Topology
(Stack)
Docker shifted from container infra.to object-oriented app. topologies
CaaS platform
Clustering (swarm)
Image mgmt
(registry)
Hosting (node)
Provisioning (machine)
... relying on an CaaS platform
The rise of the orchestration
9. @adrienblind
Docker 1.12 orchestration
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
10. @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 node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1o46ikaidagi91w940h81byd1 w1 Ready Active
3bboy53bjyeqd9ad0tsegju51 m2 Ready Active Reachable
48yqo4607pfzkpct4jz9t1t9y m3 Ready Active Reachable
6fyvwd6cc4nguth29ycexaxat * m1 Ready Active Leader
Cluster setup example
11. @adrienblind
Docker network & service
Create an overlay network dedicated to the app:
$ docker network create appnet
Depicts the desired runtime behavior of a given image :
networking, resiliency, quotas... shift to state-
machine paradigms
$ docker service create --name front -–network appnet
–-replicas 3 -p 80:80/tcp nginx:latest
Attach the containers to a given network
Define 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
12. @adrienblind
Example
LB LB LB LB
Network
Dynamic level 4 LB
All containers
belonging to a same
app are connected
through an overlay
network
Overlay network
13. @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
15. @adrienblind
Almost all cloud vendors provide their own complete,
ready-to-use docker CaaS stacks:
Amazon ECS
Azure Container Service
Google Container Engine
You may create your own docker Swarm CaaS leveraging
on several providers at the same time
Your own traditional DC
Various Cloud vendors
Cloud provider hybridation
17. @adrienblind
Scale the application through
docker service replicas
Scale the swarm cluster capacity
leveraging on docker-machine tool,
controling AWS, Azure, etc. providers
Scale up, scale down
AVOID
CONFUSION
19. @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
20. @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 architecture
Up to 54 cores/SoC + 1TB RAM
Cavium srv: 384 cores enclosed in 2U
21. @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
24. @adrienblind
Containers are more & more universal
workload units
Orchestration is more than ever the key
You may wish to keep control while
delegating commodities
Conclusion