Journey to Containerization with IBM DevOps Deploy
Authors: @Randall Langehennig and @Thomas Neal
Overview
IBM DevOps Deploy (formerly known as UrbanCode Deploy) was originally developed to run on Linux or Windows servers and many of our clients continue to use the solution in this manner today. It has a robust architecture that can scale to enterprise levels, can provide disaster recovery options, and is one of the most trusted, enterprise-class solutions in the application release automation space.
What some may not realize is that you can now implement the same solution in a Kubernetes or OpenShift cluster and some of our long-time customers are looking to begin the journey to containerization with IBM DevOps Deploy. There is no need to worry that you are the first to make this successful journey as we have many of our clients already running the solution in this manner in production environments.
The purpose of this blog is to provide some guidance on the steps required to start the journey to containerization with IBM DevOps Deploy (formerly known as IBM UrbanCode Deploy).
The following steps help you navigate the path to containerization:
- Document your current state
- Clone your existing on-premise environment (both the database and the appdata folder structure)
- Setup new containerized server instance using cloned data
- Migrate agents to new containerized instance
With this in mind, let’s take a look at the installation options for the Deploy Server, Deploy Agent, and Deploy Agent Relay.
Installation of containerized IBM DevOps Deploy
IBM DevOps Deploy provides containerized solutions for the server, agent and relay. All three are installed via Helm charts. The Helm charts are available in the public IBM Helm repository (https://github.com/IBM/charts/tree/master/repo/ibm-helm).
Each Helm chart has a README.md with prerequisites, installation instructions, and more. All the information required to install a containerized instance of Deploy server, agent or relay is contained there.
Here are the links to each helm chart:
Server: https://github.com/IBM/charts/blob/master/repo/ibm-helm/ibm-ucd-prod.md
Agent: https://github.com/IBM/charts/blob/master/repo/ibm-helm/ibm-ucda-prod.md
Relay: https://github.com/IBM/charts/blob/master/repo/ibm-helm/ibm-ucdr-prod.md
If you prefer to use an operator for installation, we have these as well that can be leveraged for installation.
How is containerization supported?
The IBM DevOps Deploy containerized offerings can run in a OpenShift or Kubernetes environment. Standalone docker containers are not supported outside of these environments. You must have an OpenShift or Kubernetes cluster to run our images.
If you want to scale our containerized offerings (i.e. run multiple servers in an HA scenario) your cluster will need to provide persistent storage that supports ReadWriteMany access mode.
On OpenShift, routes are used to provide ingress to the applications. On Kubernetes we have tested using Emissary Ingress, but customers can use other Ingress controllers (NGINX) if they configure them.
What if we have a hybrid environment for deployment?
If you have an environment where you need to deploy applications to on-premise systems as well as containers in the cloud, IBM DevOps Deploy can support both and this is a real strength of the solution.
Containerized DevOps Deploy offerings can also connect with their on-premise equivalents. For example, you can run the containerized server and connect on-premise agents and relays to that server as long as there is network connectivity. In a similar fashion, you can run containerized agents or relays and connect them to an on-premise DevOps Deploy server.
A containerized DevOps Deploy server can use a database (Oracle, SQL Server, MySQL, or DB2) running on-premise or in a OpenShift / Kubernetes cluster. In such a scenario, the network connection between the cluster running the containerized Deploy server and the database would need to be fast enough to provide the required response times.
Why containers in a Kubernetes or OpenShift cluster?
Running containers in a Kubernetes/OpenShift cluster has some built-in advantages around fail-over (worker nodes go down or get busy, pods are automatically moved to another worker node) and scalability (need more CPU/RAM, add more/larger worker nodes to the cluster).
The functionality between the DevOps Deploy containerized offerings and on-premise offerings are the same. Your containerized DevOps Deploy Server can communicate with on-premise Deploy Agents or Agent Relays. Likewise, an on-premise DevOps Deploy server can communicate with containerized Deploy Agents running in a Kubernetes or OpenShift cluster.
Summary
IBM continues to invest in IBM DevOps Deploy as it is a solution used by clients all across the globe in many different industries. IBM has invested in making sure the solution can run in a Kubernetes or OpenShift cluster and it is thoroughly tested with each release.
If you are considering the journey to containerization with DevOps Deploy and want to learn more about migrating from an on-premise DevOps Deploy Server instance to a containerized instance, please read this document: https://www.ibm.com/docs/en/devops-deploy/8.1.1?topic=migrating-server-kubernetesopenshift.
When you are ready, please feel free to open a support case with our team indicating your interest in making these steps. We will work with you to provide guidance and support to make sure the transition goes smoothly.
Want to learn more?
If you are interested in learning more about DevOps Deploy, you can request a meeting at: https://ibm.biz/DevOpsMeeting
Further, we host DevOps Summits and Bootcamps in cities around the globe to dive deeper into the future of software delivery. Please join our mailing list to be notified of future events and feel free to contact us if you have a request for a event in your area at this link: https://ibm.biz/DevOpsEventsList