, via Wikimedia Commons" width="300" height="200"> New Use Cases, New Rules: Shipping containers used as a retail shop and visitors center outside of Copper & Kings Brandy Distillery
Welcome to the Era of Image Build Services
There are a number of emerging ways to automate your image build and deployment processes using OpenShift, Kubernetes, Docker, Jenkins and other popular toolchains. Integrating the image build processes into your organization's' CI pipeline can accelerate system provisioning, reduce job time, increase the volume of jobs run, enable flexibility in language stacks and improve overall infrastructure utilization.
The industry is embracing containers as a more agile and streamlined model for application delivery. Containers enable a simple and efficient way to assemble, distribute, and deploy software. These advantages make containers ubiquitous and easy to install with a one-line command to most clouds.
New Rules Emerging
When creating Docker images to run on OpenShift, there are a number of best practices to consider as an image author to ensure a good experience for consumers of those images. Because images are intended to be immutable and used as-is, we offer some best practices and guidelines for creating images to help ensure that your images are highly consumable and easy to use on OpenShift.
CI/CD with a Twist
Best practices for adapting Continuous Integration (CI) and Continuous Delivery (CD) processes for image-based builds are also being established. These new delivery pipeline models promise to track container updates and dependency changes, optionally rebuild and re-test on change, and relay the results as security patches are made available and as they are being applied.
The CentOS and Fedora communities are both codifying these new standards into their build processes as they build out their own respective Container Pipelines and Layered Image Build Services. These hosted services are projected to become publicly available for community use as well!
Be a Part of the Conversation(s)!
Grupo Santander's Produban, an OpenShift Commons member, have developed their own CI/CD solution for building corporate docker images. Their solution builds, executes unit tests, deploys docker images, and ensures that every docker image project contains an OpenShift template. Produban then uses this build system to deploy their openshift templates into their multi-region OpenShift Enterprise project on OpenStack. Their use case is just one of many that we'll be hearing about in upcoming Image Builder SIG meetings.
Learn best practices for a variety of tool chains and how to use source2image, environment variables, secrets, service accounts, and templates to design, develop and maintain OpenShift-ready redistributable images of your applications and services directly from your peers. You’ll hear from both the Fedora and CentOS teams, and other members of the OpenShift Commons who are already in production with their own image build services.
As with all new technologies, there are things that you’ll need to change in your current processes and there are many people with opinions about the types of changes they’d prefer to see you make, this SIG is the place to ask questions, share your use cases, give feedback to others and voice your opinions.
Upcoming Image Builder SIG Discussion Topics include:
How to Build Redistributable OpenShift-Ready Images (led by Ryan Jarvinen, OpenShift)
Atomic Registry (led by Aaron Weitekamp, Red Hat)
CI/CD for Corporate Images on OSE (led by Cristian Roldan, Produban)
Fedora Cloud’s Image Builder Service (led by Adam Miller, Fedora)
CentOS’ Container Pipeline (led by Karanbir Singh, CentOS)
Don’t wait on the sidelines and just be an observer, join us and share your musings on what the New Rules should be for Image Builders. Your feedback and thoughts are essential to building out the best practices and generating the ideas that feed the Open Source way.
The Basics A common request from OpenShift users has long been to raise the number of pods per node. OpenShift has set the limit to 250 starting with the first Kubernetes-based release (3.0) through ...