by Stéphane Woilliez, Docker TIAD Camp Docker 6 Octobre 2017

1. Strategy, Planning and Governance for
Enterprise Deployments of Containers
Stéphane Woillez
Technical Lead South Europe
Docker Inc.

2. Hummm, it’s time to think about Enterprise deployment….
• Most internal developers use Docker and want to deliver containers
• Commercial software start to be delivered as container images
• There is an Hybrid cloud initiative
• More than 5 dockerized applications now run in production
• IT needs to lower costs and densify applications in production
• There is a DevOps strategy going on
• The Software Factory thinks about Micro Services and Serverless
The signs that tell it’s time to build an enterprise strategy for containers
2

3. Agenda of my Enterprise deployment strategy
• Choice of the underlying infrastructure
• Image Governance
• Security of my Docker Platform
• Operations
• Applications Migration
• Conclusion : Wow wow wow, tell me where to start from
Obviously non exhaustive
3

4. Choice of the underlying infrastructure
Virtualization or bare metal ?
What about using Linux Micro Distributions
How many Docker environments ?
Is production more critical than other environments ?

5. Virtualization or bare metal ?
• Docker works perfectly in both environments
• Virtualization :
o Pros : Operations ready, easy backup
o Cons : Overhead, Cost
• Bare Metal :
o Pros : Efficiency, low cost, simplicity
o Cons : I forgot how to manage Bare Metal
• Decision has to be made on different aspects :
o Cost or expected TCO
o Workload compatibility
o Existing Operational environment
• Advice : Take the hybrid way
o Use virtualization for managers
o Use Bare Metal for workers
The cost optimization does not come from where expected… Think densification
5

6. What about using Linux Micro Distributions ?
• Many Micro Linux distributions exists :
o Alpine, CoreOS, Docker LinuxKit, RedHat Atomic,
Ubuntu Core, VMWare Photon, …
• Pros :
o Ultra optimized for containers execution
o Best host security
o Lower cost
• Cons :
o Not a lot of experience in production
o Difficult to have a end to end support yet
• Advice : Take time to deploy in production
o Test Micro Linuxes in non production
o Keep standard distributions for production
Small and strong
6

7. How many Docker environments ?
• The number of environments and the number of
clusters may differ because of multi tenancy
• Many aspects influence the number if environments
o Existing organization
o Security level
o Outsourcing & third party software
o Split between organizations or divisions
• Most users have 2 clusters (production, non-
production), others have much more (6-10)
• Advice : Production is important, but Dev is even
more, because of its visibility during the Docker
project
My Docker cluster is bigger than yours…
Production
Development
BetaIntegration, Test, Sandbox,
Preproduction
7

8. Image Governance
Registry Architectures
Images Management
Change Management

9. Registry Architectures
• Should I use a general purpose registry, or one
designed for containers management ?
o Keep existing general purpose registries
o Don’t miss extra functions of containers
registries (ex:DTR brings content trust)
• Should I have separate registries for :
o Production protection : NO
o Physical isolation : YES
o Accepting third party images : MAYBE
o Delivering images to locations : NO
o Application separation : MAYBE
o Managing hybrid deployments : MAYBE
Standalone Deployment
High Availability
Simple Chaining
Complex Chaining
One to rule them all…. Or maybe not
9

10. Docker images registries : The usual deployment schemes
• Standalone or high availability ?
o The choice depends on the deployment frequency
o Standalone can be ok for production
o In general, high availability is required for dev
• IT provides base images using a central registry
• Managed production is linked to the central registry
• Autonomous clusters can replicate the base images
• For security reasons, a secondary registry is deployed in
DMZ for external deliveries
• Access by developers from remote locations can be eased
by a network of proxies / cache servers
• Everyone can pull from Central, no one but the CI/CD can
push
Central or distributed, or maybe replicated
Central DTR
Production Autonomous Cluster
Local DTR
DMZ DTR
DTR Cache
DTR Cache
DTR Cache
DTR Cache
PUSH
PULL
COMMIT
10

11. Image Management
• Hub Images or my private images ?
o Allow developers to use hub images locally
o Deny uncontrolled images on clusters
• Build your own base images
o Tar the content of a chroot dir and use “scratch”
o Look for examples in the Docker Hub
• Minimize the number of layers in images using
multi stage builds
• Tagging
o LATEST is your enemy in production
o Favor major versions, update using minors
o Some use extra tags like DEV,INTEGRATION...
FROM scratch
ADD <chroot_dir or tar file> /
CMD ["/bin/bash"]
Docker HUB Trusted Registry
Image quality is key to many aspects of Docker : security, efficiency, shareability…
11

12. Change Management
• Apps in containers are not patched !!!
• Change Management is about:
o Update of the platform
o Update of applications
o Update of images
• The update of the platform is not a problem, the
orchestrator takes care about availability of Apps
• Same for applications. Rolling updates of Apps is a
standard of orchestration
• Triggers of images change management:
o New versions of base OS images
o Updates of middlewares and runtimes
o Reaction to the discovery of a vulnerability
Yes, I do not patch, but I need to update
12

13. Security
Containers are secure. What can we do more?
Security of the engine
Security inside the container
Multi tenancy

14. State of the union : Containers are secure !
• Isolation of containers with NameSpaces
• Resource Usage Limits with CGroups
• Admin rights control with LibCap
• Kernel protection with AppArmor,
SELinux or Seccomp
• Prevent Compromising with immutable
image layers
• Limit attack surface with Images built best
practices
Readonly
Readonly
Readonly
Install only the required libraries in images
Even the more secured environment, if poorly managed, can be compromised
14

15. Security of the Engine
• Install & configure kernel protection using
AppArmor, SELinux or Seccomp
• Prevent root access to clusters, to ensure no one
can disable protection
• Limit the installed packages on host to reduce risk
• Use a tool like DockerBench for Security to assess
and fix the configuration of hosts
• On clusters, configure certificates rotation for TLS
sessions
Configure, control, and test…
15

16. Content trust : Run only trusted images
• Clusters should only run trusted images
• Images should pass security validation before been
granted for production
• Digital signing of images ensure trust. Engines do
not create containers from unsigned images
• Sophisticated signing policies can be used for
different purposes :
o Implement a validation chain
o Ensure all security tests have been applied
o Involve the responsibility of image providers
Don’t open the Pandora’s box, unless you know exactly what it contains
16

17. Detection of intrusions and abnormal activities
• Very early stage. Attacks adapted to containers still
to be developed. Risk low for Micro Services Apps
• The security approach depends on the type of
containers managed
• For « Virtual Machines » containers
o Well, everything works like in VMs
o Host based Intrusion detection
o Anti malware
• For « Services » containers
o Containers may live for only milliseconds
o Vulnerability assessment BEFORE execution
What the hell are you doing inside my Docker cluster ?
17

18. Multi tenancy
• Do not mix up platform multi tenancy and application
multi tenancy
• Two main usage of Multi Tenancy :
o Isolate users/apps from others
o Protect environments from unauthorized users
▪ Production vs Other environments
• Several combined technics allows multi tenancy :
o Authentication (not only for users)
o Role based access control
o Isolation of compute resources (pros & cons)
o Resource usage limits (ensure they are set)
Ensure & control good relationship between neighbors
18

19. Operations (lot’s of subjects)
Should I manage containers like VMs ?
Log, Monitoring, Alert management
Backup Management
Chargeback and License Management

20. Logging, Monitoring, Alerting, Backup, Chargeback & License Management
• They are all important, and need a specific focus
• Two approaches are often seen :
o Built-in capabilities of the Docker platform
o Integration with existing external systems
• Logging, Monitoring and Alerting are strong
requirements of production
• Backup is not always required with containers, due
to their stateless nature
• Chargeback is required in mutualized
environments, partly built-in partly integrated
• License Management is pretty new and brought
by the « Modernization of applications » initiative.
It’s a tricky subject as it involves both technical and
legal aspects.
Often seen in this order from most to less urgent/required
20

21. Application Migration
Containers Playground
Good candidates to app migration
Trickier apps for containerization
Don’t stop at step 1 of modernization (please!)

22. Containers, the playground
• Supported platforms : Linux, Windows
Server, zLinux, pLinux
• The underlying infra : Bare Metal,
Virtualisation, Public clouds
• No Graphical User Interface inside
containers (though…)
• Unattended installation
• Check the support of commercial software
on https://store.docker.com
• Beware of high end requirements regarding
storage performances
Most fairly modern applications can be converted to containers
22

23. App Modernization is much more than lift and shift
App
• App Modernization with containers requires a bit of refactoring to deliver higher value
• Additional value can be obtained by applying Cloud Principles and Micro Services
• Docker allows the use of an iterative process for modernization
• Deliver quick & visible results with Apps sharing the same components
Existing
Application
Modern
Methodologies
Integrate to CI/CD
and automation
system
Convert to a
container
Modern
Infrastructure
Built on premise, in the
cloud, or as part of a
hybrid environment.
Modern
Microservices
Add new services or
start peeling off
services from monolith
code base
Don’t use containers for huge monolithic applications, use the technology to fuel your modernization strategy
23

24. Conclusion
Where to start to build and deliver a CaaS platform…

25. Start by building the platform, or start with Apps ?
• The Platform approach : Build the enterprise container platform, then onboard applications
• The Apps approach : Migrate applications to collect operational requirements, then mutualize
• A combined approach seems the most appropriate :
o Production requires the availability of a minimum set of
operational services
o Success & Adoption are triggered by a critical mass of
applications in production, estimated between 3 and 5
o Docker = Dev Ops. A common initiative is needed for
Devs and Ops to understand their respective trades and
work on a common initiative
A Docker project is a good way to complement a DevOps strategy, and vice-versa
25