Successfully reported this slideshow.

DockerCon 2016 - Structured Container Delivery

1

Share

Upcoming SlideShare
Kubernetes 101 and Fun
Kubernetes 101 and Fun
Loading in …3
×
1 of 19
1 of 19

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

DockerCon 2016 - Structured Container Delivery

  1. 1. Structured Container Delivery Oscar Renalias Accenture Container Platforms Lead
  2. 2. Infrastructure DevOps Architecture Virtualization/ Cloud savings Hardware savings Flexible platforms Predictability Flexible application environments Efficiency Alignment with modern architectures Developer Productivity • Reduce/eliminate virtualization licenses for workloads to be containerized • Reduce number of hardware blades/servers/cloud instances • Faster container startup times means instances can be turned off when not used, or dynamically scaled according to demand • Minimize environment and configuration defects in new environment setup by packaging all components and dependencies in containers • Provision an arbitrary number of application environments easily, when needed, and destroy them when done • Minimize human effort / involvement with deploying code to new environments • Containers are a great runtime platforms for modern scalable and high performance application architectures, e.g. microservices • Greatly reduce the amount of time needed for a developer to create a working application environment locally $$$ $$$ $ $$ $$$ ⭐ ⭐ ⭐ ⭐ ⭐ ⭐ Benefit Container Business Case
  3. 3. So you want to run containers? Container Platform
  4. 4. Dev Tools Official Repositories Operating Systems Big Data Service Discovery Build / Continuous Integration Configuration Management Management Storage Clustering & Scheduling Networking Infrastructure & Service Providers Security Monitoring & Logging Where do we start?
  5. 5. Container Platform Architecture
  6. 6. Container Platform Architecture Principles Patterns Capabilities Reference Implementations
  7. 7. Understanding how to design for, and with containers Business Continuity Operations Agility Prepare for Failure Fit for Purpose Adaptability and Flexibility Infrastructure Independence Information Security Leverage service discovery for inter/external service lookup Use standard protocols to interact with interfaces Use standardized and best-practice components Reuse services offered by platform and extend components if necessary Data Integrity Communications Prefer container image digital-signing Use isolated networking between containers, regardless of their location Prefer lightweight infrastructure components Use container clustering and/or other HA practices Use external persistence data sources for container data Leverage DevOps practices for container image build and deployment L1 Principles L2 Decisions Leverage dynamic routing capabilities Monitor container infrastructure components Limit container access Use private or secure hosted image registry Container as the build artifact Immutable infrastructure, deploy by replacing old containers with new ones Make sure that logs aren't retained only in containers Version container images in repository Encourage reuse of container definitions Data and process must be encapsulated Multi-tenancy – keep teams isolated
  8. 8. How do we do <…> with containers? • Operations agility: This pattern handles complex architecture in build process where multiple version of packages are to be managed Architecture Pattern: Container as build output Conceptual View Enabling Principles • Usability: There should be no reason to not build containers using a Continuous Integration platform and leverage the automation and versioning capabilities provided. Risks & Issues • Operability: Best used when continuos integrationis needed • Versioning: Continuous Integration platform is also responsible for versioning containers and publishing them to a private/public Docker registryfor consumption Benefits / Force Integrate the container build process withina Continuous Integration tool and ensures repeatability of the build process. Additionally, the CI platform is alsoresponsible for versioning containers and publishing them to a private/public Docker registry for consumption. Overview SCM Jenkins Docker Internal Registry Receive Code Build Container Tag Container Push Container • Prepare for failure: As one contaioner provides only one service, isolation is preserved. And failure of one unit in system do not affect other services. • Operations agility: As each container offers single service it can be used by multiple applicationwithout affecting others Architecture Pattern: One service per container Conceptual View Enabling Principles • Operability : As only one service (process) is run in the container, this pattern requires careful consideration of its operational concerns such as logging, monitoring and restarting the container should the process inside crash. Risks & Issues • Maintainability: Smaller, lightweight containers • Operability: Stacks are easier to compose by combining and linking containers withdifferent components • Security: Smaller attacksurface incase of vulnerabilities Benefits / Force The “one service per container” app enforces anapproach where a container runs only a single applicationor service. No process manager is used within the container. Implement an application packaged withina container, as the only one process that runs within the container. Overview Logging Monitoring Data Storage Frontend
  9. 9. Clustering Security Service Discovery Persistence What features do we need? Clustering Load balancing Fail-over Authentication Authorization Encryption Digital Signature Service Lookup & Indirection Publishing & Subscribing APIs Image Persistence Versioning Data persistence
  10. 10. Infrastructure Runtime Platform Administration Public/ Private Cloud VM Bare Metal Host OS Container OS Container Engine Container Tooling Browser Application Integrations Containers Data Registry Storage Orchestration Resource Management Service Discovery Data AccessNetworkingMetrics DevOps Image Build/ Deployment Monitoring Logging What components do we need?
  11. 11. Getting opinionated: Component Reference Architecture for Docker Datacenter on AWS Infrastructure Runtime Services Administration Orchestration Resource Management Service Discovery Data Access Browser Containers Data Metrics DevOps CloudWatch Networking Overlay Network Flocker Docker Compose Universal Control Plane Overlay DNS (intra- cluster) EC2 Storage Registry Docker Trusted Registry Docker Volumes Storage EBS Service Discovery Interlock Container OS Docker Docker Amazon Linux Engine Host OS Container Tooling Monitoring CloudWatch Logging CloudWatch Logs Image build/ Deployment Jenkins CI
  12. 12. How about the old stuff? Container Platform Old stuff New stuff
  13. 13. Efficiently migrating existingapplications to containers
  14. 14. Central Internal Team Project-based migration Migration factory Centralized team working in concert with project teams to coordinate and migrate projects to the new platform Leverage existing project team group to orchestrate and execute migration effort + Fast, efficient deployment + Shared team provides economies of scale and knowledge sharing + Optimized resource model + Focused on migration delivery and managed to avoid cost overruns - Increased number of resources - Limited cross-team knowledge sharing - Lengthier migration - Inconsistent migrations - Team has other priorities - Limited or non-existent container skills - Limited migration skills Migration conducted by an internal team, staffed by current IT resources Centralizing the migration effort
  15. 15. Migration Factory Docker Migration Team Migration Framework Container Patterns Container Best Practices Base Images Container Reference Architecture Legacy Application Expertise + Framework + Feedback loop
  16. 16. Establish Overall Migration Plan Perform Detailed Migration Planning Upgrade/Migrate Applications Certify/Deploy Applications Migration & RolloutDiscovery & Assessment High-Level Assessment & Planning Detailed Application Assessment Testing & Certification App. Architecture Recommendations Container Infrastructure Planning Rollout & Decom- mission Containerize Application
  17. 17. @oscarrenalias github.com/accenture oscar.renalias@accenture.com www.linkedin.com/oscarrenalias www.slideshare.net/oscarrenalias
  18. 18. Thank you!

Editor's Notes

  • Containers everywhere. Clients are very interested and are can definitely see the business case.
  • Containers have clear benefits, but how do we get there?
  • So you want to run containers, but where do you start?

    We need a container platform. What should be in there? What capabilities do we need? What components should provide those capabilities?

    Once we have a platform, we can build stateless microservices, yay. But there’s a whole lot of legacy applications that could greatly benefit from running on containers, not least because of infrastructure cost and licensing savings.
  • So you want to run containers, but where do you start?

    We need a container platform. What should be in there? What capabilities do we need? What components should provide those capabilities?

    Once we have a platform, we can build stateless microservices, yay. But there’s a whole lot of legacy applications that could greatly benefit from running on containers, not least because of infrastructure cost and licensing savings.
  • Repeatable, industrialized
    Low risk
    Cost-efficient
    Feedback loop – migration learnings are fed back
  • ×