jenkins for continuous delivery of infrastructure via...
TRANSCRIPT
Jenkins for continuous delivery of infrastructure via Docker
Greg Hoelzer and Michael HeldebrantRed HatDecmber 2014
RED HAT CLOUD INFRASTRUCTURE
AGENDA
● Building a Docker factory with Jenkins
● Docker Tagging and Genealogy
● Docker factory floor from OS image to production
● Build Slaves● Dockerfile builds via Jenkins● Docker build slaves for Jenkins● Production image build
● Patch cycle with Containers
● OpenShift 3.0 roadmap
RED HAT CLOUD INFRASTRUCTURE
An allegory for managing constant change in operations
Traditional patch cycle in adowntime window Continuous Delivery
4
RED HAT CLOUD INFRASTRUCTURE
CI/CD for infrastructure?
Challenge: How can you continuously deliver and integrate the latest infrastructure and platforms to deploy and maintain your applications?
Solution: By continuously updating and deploying infrastructure to build and test your applications that you can then deploy in a single unit to production.
Docker containers are one way to approach this solution.
6
RED HAT CLOUD INFRASTRUCTURE
Docker tags
By using symbolic tags you will automatically update your inputs to the next step of the factory build with Dockerfiles
For example:
OS:latest – always the most current OS update that finished a docker build
Platform:latest – the most current platform installed onto OS:latest
YourApp:latest – the most current application deployed on Platform:latest
8
RED HAT CLOUD INFRASTRUCTURE
Docker tags
Multiple factory lines can coexist. All Docker images that are the same input and steps are cached and reused in the build process.
For example:
YourApp:Latest – always the most current update that finished a Docker build
YourApp:QA – the version undergoing testing
YourApp:Tested – the version that passed integrated testing
YourApp:Production – the most current version running in production
YourApp:Next – the next version to deploy to production
YourApp:Tested-datestamp – save a tag by date that passed the build and testing for archive
12
RED HAT CLOUD INFRASTRUCTURE
Build a Docker factory
How does CI and Containers work together?
Define your jobs in Jenkins to build the next dependent job● Jenkins will build from the point of change all the way to the end of the factory● Fan out strategy for variants you need to support such as multiple jdk versions● Fan out for for multiple os versions or patch levels, latest/tested/production/next
Docker run build and test containers via symbolic tags and manually assign network information or consistent ports● Restart containers with new code early and often in the latest track● Restart containers with the latest versions of other tracks as they are promoted ● Always make sure you can build an app only change in the production and next tracks
Create dns aliases for these symbolic tagged containers and relaunch on changes● YourApp-latest● YourApp-tested● YourApp-production
14
RED HAT CLOUD INFRASTRUCTURE
Test at multiple levels
Don’t be a bond villan DevOps team:
Dr. Evil: All right guard, begin the unnecessarily slow-moving dipping mechanism.[guard starts dipping mechanism]Dr. Evil: Close the tank!Scott Evil: Wait, aren't you even going to watch them? They could get away!Dr. Evil: No no no, I'm going to leave them alone and not actually witness them dying, I'm just gonna assume it all went to plan.
● Unit test your applications during the build● Plan for automated integration tests: launch a whole app stack of containers and a driver
container to run the tests● Reduce human interventions as much as possible as it will become a bottleneck
Core Jenkins Build PipelinesBuild Pipelines help visualize job dependencies & chaining
Infrastructure Build Pipeline -
* Starts with OS Base
* Completes with new App & Build Slave Images
Application Build Pipeline -
Starts with Application Build on Build Slave Container
Completes with new App Image
Jenkins/Docker Build Slave ConfigurationCombination of Docker Container execution & Jenkins Node configuration
Docker Build Slave Container-
* Run from Docker Image (Maven & SSH Server)
* Docker Container run on Jenkins Host
Jenkins Node Configuration -* Defined by Name/Label
* Specify Launch Method (SSH + Connection Parms)
* Needs permissions to install & execute Java Slave agent
Jenkins/Docker Build Job ConfigurationCombination of Docker Files in github repo & docker command orchestration
Docker File Image Definition -
* Starts from existing Image
* Defines steps to implement incremental updates
Jenkins Job Definition -* Starts with pull from SCM Repo (github)
* Executes Build Steps (bash & docker commands)
* Triggers dependent Jobs
Docker Application Image DefinitionCombination of Jenkins Job Artifacts, Docker File Definition
Jenkins App Build Job -
* Run Maven build on target Node (Build Slave Container)
* Archive Build Artifacts (Jboss EAP WAR file)
* Trigger Final Docker App Image creation
Jenkins App Image Job -
* Use Latest Successful Build
* Docker File Image Definition ADDs artifacts to Image (Jboss EAP WAR file)
* Docker Commands create and tag new Application Image
Docker Image Management & Container ExecutionCombination of Docker Image Tagging, Docker Container Naming Conventions
Docker Image Tagging -* Use target image Naming Convention (Platform + App Name + OS/JDK Version)* Tag Latest and Specific Builds
Docker Container Execution -* Use a defined Container Naming Convention (based on image name, instance, function, etc.)* Use environment variables to pass in environment specific configuration* Harvest/Delete stopped Containers that won't be restarted or used again
22
RED HAT CLOUD INFRASTRUCTURE
Subscription Management for containers
Using the RHEL 7 subscription model, if you want to create Docker images or containers, you must properly register and entitle the host computer on which you build them.
If you use the Red Hat registry.access.redhat.com docker images when you use yum install within a container to add or upgrade packages, the container automatically has access to the entitlements available from the RHEL 7 host.
The containers can get RPM packages from the appropriate repositories so that RHEL6 images and RHEL7 images can co-exist on the same RHEL7 container host.