Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Strategy, planning and governance for enterprise deployments of containers - TIAD Camp Docker

1,448 views

Published on

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

Published in: Technology
  • Be the first to comment

Strategy, planning and governance for enterprise deployments of containers - TIAD Camp Docker

  1. 1. Strategy, Planning and Governance for Enterprise Deployments of Containers Stéphane Woillez Technical Lead South Europe Docker Inc.
  2. 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. 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. 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. 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. 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. 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. 8. Image Governance Registry Architectures Images Management Change Management
  9. 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. 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. 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. 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. 13. Security Containers are secure. What can we do more? Security of the engine Security inside the container Multi tenancy
  14. 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. 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. 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. 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. 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. 19. Operations (lot’s of subjects) Should I manage containers like VMs ? Log, Monitoring, Alert management Backup Management Chargeback and License Management
  20. 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. 21. Application Migration Containers Playground Good candidates to app migration Trickier apps for containerization Don’t stop at step 1 of modernization (please!)
  22. 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. 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. 24. Conclusion Where to start to build and deliver a CaaS platform…
  25. 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

×