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.

Container Driven Continuous Delivery

2,735 views

Published on

In order for businesses to stay agile, developers must be able to deploy applications quickly, efficiently, and in a streamlined manner. Creating automated CI/CD pipelines is a widely accepted process to accelerate the release process, and is critical to success in adopting OpenShift. But, what should a minimal viable pipeline have? What does a good pipeline look like? What are the right tools for building a pipeline? In this interactive session, we'll look to answer these questions so you'll walk away with an understanding of how to create container-driven continuous delivery that works for your organization.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Container Driven Continuous Delivery

  1. 1. Container Driven Continuous Delivery Raffaele Spazzoli Architect May 3, 2017 Andrew Block Principal Consultant
  2. 2. INSERT DESIGNATOR, IF NEEDED Agenda ● Immutable infrastructure ● MVP CD in openshift ● CD best practices
  3. 3. INSERT DESIGNATOR, IF NEEDED Immutable infrastructure A contract between the application and the infrastructure necessary to run it
  4. 4. INSERT DESIGNATOR, IF NEEDED High-level MVP deployment process Moving through the SLDC environments
  5. 5. INSERT DESIGNATOR, IF NEEDED Organizational: 1. Who owns the pipeline process 2. Point&Click deploy vs true pipeline Technical: 1. How do we promote images 2. How do we promote API objects 3. How to we manage environment dependent properties 4. How do we manage secrets 5. How to we execute the release CI/CD considerations Questions to answer before we start
  6. 6. INSERT DESIGNATOR, IF NEEDED Docker Engine ● Utilizes Docker Client ● Command line interface Skopeo ● Project Atomic tool ● Command line interface to perform Docker operations ● Communicates with Docker REST API Image Promotion Tooling Tools to Facilitate Image Promotion
  7. 7. INSERT DESIGNATOR, IF NEEDED Image promotion recommended approach
  8. 8. INSERT DESIGNATOR, IF NEEDED oc process <template> -v … | oc apply -f - Openshift API object promotion recommended approach
  9. 9. INSERT DESIGNATOR, IF NEEDED Environment Variables Configuration Profiles All properties for all environments are stored in the image. Container process picks the right one based on an environment variable. Does not work well with ephemeral environments Environment dependent properties are passed as environment variables to the container process Does not scale with the number of variables ConfigMap Config Store Properties are retrieved from a Config Store service at application boot. Container may not be able to start if store service is down. OpenShift ConfigMaps are used to store environment dependent properties. Additional API object to manage Environment Dependant Configuration Approaches
  10. 10. INSERT DESIGNATOR, IF NEEDED Credential management approaches OpenShift Secrets Secret Store Build an integration with a secret store ● Hashicorp Vault ● CyberArk ● ... OpenShift secrets is the recommended approach. Openshift secrets have some limitations with regard to security, if this is a concern, consider a user space solution.
  11. 11. INSERT DESIGNATOR, IF NEEDED DeploymentConfig-based options: 1. Recreate 2. Rolling deployment 3. Custom deployment Routing policy-based options: 1. Blue-Green deployments 2. A/B deployments Rollout options
  12. 12. Cross cluster image promotion techniques. Environment dependent configuration management strategies. Rollout reference architecture. OpenShift-Vault Integration. References
  13. 13. THANK YOU plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews
  14. 14. INSERT DESIGNATOR, IF NEEDED14 Why / objective To make the quality of software observable at any point in time How Static analysis, unit tests, Integration tests And A DASHBOARD The effect Quality will tend to go up to the point where software is always in a releasable state. CI/CD 1/2 To reduce the cost of a release By automating all the steps Confidence in the release process goes up. Releases can be done any time code is ready to be released. CI CD
  15. 15. CI/CD 2/2 ● Code is always releasable. ● Releasing is relatively inexpensive. ● It is possible to release more frequently therefore reducing the risk. ● Releasing becomes a non-event for IT, done during normal business hours. ● Releasing becomes a business decision, not an IT decision.
  16. 16. Download the Slides

×