Overview
Did you know that the Deploy Server (controller) can be installed as a container and run in an OpenShift or Kubernetes environment and can communicate with Deploy Agents, Agent Relays that are on-premise and/or containerized? We provide excellent documented instructions for installation using either a helm chart or an operator in your Kubernetes environment of choice.
To learn more, please see the introductory blog post that covers the Journey to Containerization with IBM DevOps Deploy.
In this blog, I will try to cover some of the questions we receive most frequently as customers are preparing to move to our containerized implementation of IBM DevOps Deploy.
The Common Questions
Here are some common questions that may come up as you consider the journey to containerization with IBM DevOps Deploy:
- Does DevOps Deploy support air-gap installations?
- What Kubernetes persistent storages are supported?
- Do the following restrictions:
o Access to ‘root’ is not allowed
o Cluster wide access is not allowed
have any impact to the IBM DevOps Deploy installation when installing in a Kubernetes cluster?
Let’s review the answer to each of these questions in the segments below.
Does IBM DevOps Deploy support air-gap installations?
Yes, DevOps Deploy (UCD) can support the installation in an air gap environment. It is simple with DevOps Deploy since there is only one image for the Deploy Server. The simplest way is to get started involves these steps:
- First, use the Skopeo utility that is designed for working with remote image registries to run:
'skopeo copy…’ the DevOps Deploy Server image into your air gap registry.
- Second, set Values.version=imageSpec where ‘imageSpec’ is the reference to the image in your air gap image registry when doing the helm install.
There are other ways to implement air gap support for IBM DevOps Deploy and we would be happy to discuss those other options if you have questions. Please do reach out to us by replying to this blog post or reaching out to your IBM representative.
What Kubernetes persistent storage are supported?
IBM DevOps Deploy can run in a single server instance (i.e. one pod) using persistent storage that supports ReadWriteOnce access mode.
If you want to scale your DevOps Deploy Server instance to multiple servers (pods), then we need persistent storage class that supports ReadWriteMany access.
Persistent storage backed by NFS most likely supports ReadWriteMany access mode (i.e. Isilon (NFS) ~ primary PVC type).
Are there any restrictions that could impact the IBM DevOps Deploy Server installation in a Kubernetes cluster?
In this example, the question centered around installation restrictions where access to ‘root’ is not allowed or cluster wide access is not allowed.
IBM DevOps Deploy containers run as non-root. Root access is not required. To install DevOps Deploy, you only need namespace access. The cluster Admin access is only required if installing via operators, which require cluster admin permissions to install the operator. This type of installation adds CustomResourceDefinitions (CRDs) to the cluster.
The actual install via Helm chart or the creation of the "UcdServer" Custom Resource only requires namespace access.
Summary
I hope this reference on the most common questions related to the IBM DevOps Deploy installation in a Kubernetes or OpenShift environment help in your preparation for a move to the container world. Special thanks to @Thomas Neal for his contributions to this blog post.
Want to accelerate your software delivery while boosting reliability and security?
Schedule a meeting with our DevOps experts to explore tailored solutions for your team.
Stay ahead of the curve in software delivery.
We host DevOps Summits and Bootcamps worldwide—join our mailing list to get updates on upcoming events near you.
To see further details of What’s New in DevOps Deploy 8.1.2, please the What’s New page or review this blog post that provides even more details.