Integrate DevOps and containers with simple tool adjustments
Organizations with an established DevOps pipeline can migrate from VMs to containers without tossing out the entire toolstack. Focus on these steps to enable containers in production.
Organizations adopt DevOps methodologies to reduce application development time and improve code quality, consistency and security. They adopt containers for many of the same reasons.
A typical implementation pulls together multiple tools for development and deployment tasks in a chain. It must be flexible enough to accommodate:
- different programming languages, such as C, Python and Go;
- application targets, both mobile and web; and
- diverse deployment platforms, including virtual servers, cloud services and containers.
Given the ever-increasing popularity of containers as a runtime environment for server applications, IT organizations often combine DevOps and containers. DevOps methodologies appeal to organizations and developers on the leading edge of technology -- a natural fit with container usage and the often open source software to support them.
Automation and containers: A perfect match
The key decision in a container strategy is the choice of orchestration and cluster management software; for the runtime engine, Docker is the de facto standard. Increasingly, container orchestration is narrowing down to a single technological choice, Kubernetes, particularly for large enterprises and online businesses that need scalable capacity. Kubernetes isn't the right fit for everyone because it's often complicated to set up and difficult to manage. Kubernetes is the upstream technology for many commercial orchestration products that aim to smooth over these challenges. Some organizations prefer a packaged container management system that builds on existing virtual infrastructure, such as VMware vSphere Integrated Containers or Windows Server Containers. Other companies that implement DevOps and containers prefer a structured platform as a service (PaaS) stack, such as Cloud Foundry or Google App Engine, that uses containers as the runtime environment by default.
Because a toolchain decouples components -- with different software for code version control, module integration, regression testing and application deployment -- the user can mix and match tools to suit an exact environment. When the application developers swap out traditional VMs for containers, they can update rather than replace the entire DevOps toolchain.
Adapt the pipeline
Several steps constitute a basic DevOps process: a code repository with version management, build automation, CI/CD, configuration management and infrastructure deployment.
Moving from VMs to containers only requires changes to configuration management and infrastructure deployment practices, with some possible customization to the CI/CD pipeline. IT operations members of the DevOps team are affected, while developers continue to use existing version control and build systems. The container management system handles image packaging, resource configuration and deployment. Organizations that migrate to containers 100% might eliminate infrastructure configuration and automation tools, but most enterprises run applications in production with various deployment methods.
An example organization runs the Docker suite for container-based applications. The DevOps team keeps private container images in the Docker Hub repository. The DevOps toolchain connects to the developers' Git code management systems and CI/CD tools using webhooks, such that new code commits that pass integration tests are automatically built to a Docker image and posted to Docker Hub. Docker Hub feeds image instances to Docker's swarm orchestration system. The system then either automatically deploys new images to the container cluster via swarm or Kubernetes or sends an alert to operations that code has been delivered and is ready for production.
Editor's note: As of October 2017, Docker has added native Kubernetes integration as an option, in addition to its internal swarm orchestration tool.
Add cloud services
It's a similar scenario to deploy containers on cloud services in a DevOps model; the difference is whether the toolchain itself is based in the cloud or if only the runtime environment resides there.
Hybrid toolchain implementations appeal to DevOps teams that already use build automation and CI/CD tools but seek to change the runtime deployment target. When deployment moves from VMs to cloud-based containers, the image repository and deployment tools are the only elements that change. Cloud vendors can help: Google Cloud Platform (GCP) documents how to integrate its Container Registry and Kubernetes Engine with 10 popular CI/CD tools; Microsoft Azure has similar information for using Jenkins with its container service. The CI/CD tool handles the build and test cycle and pushes new code to either a local image repository or cloud service. To deploy the code to production, it uses cloud RESTful APIs or command-line scripts to install the updated image onto a container cluster. For example, a DevOps team uses the Codefresh CI/CD tool as the pipeline. It provides a script for the gcloud and kubectl command-line tools, along with a YAML deployment template that pushes successfully tested images to a GCP Kubernetes cluster.
Organizations that want to run the entire DevOps pipeline in the cloud should evaluate the various developer services on AWS, Azure and GCP. For example, in the AWS suite, CodePipeline detects new submissions to the CodeCommit code repository and triggers CodeBuild to create a Docker image; after tests return successful, CodeBuild pushes the image to Elastic Container Registry. CodePipeline can then trigger a Lambda function to Kubernetes to pull the new image from the repository and start a rolling update to all container instances in its Pod. This is one example of how DevOps and containers combine to enable rapid, automated application updates without major production changes.
The same process flow and integrations work with a PaaS, such as Azure App Service or Google App Engine. These platforms handle the container configuration, deployment and scaling automatically, obviating the need for an ops admin to manage a Kubernetes cluster. Cloud Foundry, a container-based private PaaS, works with popular developer tools, such as private Git servers or hosted GitHub source code management services. However, some users report shortcomings with other CI pipeline software and instead developed Concourse CI as an alternative. Due to the tight integration, Cloud Foundry users are advised to use Concourse to automate the code-to-image-to-deployment pipeline.
CI/CD-based DevOps toolchains and containers are a natural combination for Agile development and deployments. Due to the portability of container images and cross-platform support, an automated pipeline makes it easier to implement a hybrid or multi-cloud deployment strategy, whether it relies on Kubernetes clusters managed by IT operations or a cross-platform PaaS.
