I’d like to share my story about migrating application to Openshift. Also, as a result, I will compare some of the most popular solutions and tools for managing your application inside Openshift.
First of all, let’s talk about our application. It is an out of box enterprise solution, it supports different databases, application servers and integration interfaces with third-party systems. Usually, our clients were installing our application on dedicated servers, however, we faced the issue. We had to tun the application inside Openshift.
The application is the product with a long history, it should work out of the box in completely different environments. As a result, there are a lot of page in our installations guides. However, the top level schema is easy as pie, you just should:
Unfortunately, the world is cruel, there were some important prerequisites.
Ansible Container is an open source project that aims to enable the automation of the entire container build, deployment and management process. Best of all, it uses the same simple, powerful and agentless Ansible automation language that you’re already using, ensuring you can automate the entire application lifecycle.
We already had written some Ansible roles for installing the application at VMs, so we reused them with ansible-container. Ansible container is a toolset for building containers. I’m not sure that it’s really good toolset, however it allows:
There was no major issue with ansible-container because Openshift creating images guidlines is awesome. However, I’d like to notice:
Docker + systemd = pain.
The main point is that ansible-container helped us to create a demo very fast, because of reusing.
The first demo container was built via ansible-container. It was good enough for the demo, however, we decided not to use it. We split the monolith container into different:
However, it wasn’t clear to initialize the database? We found a great article about PODs life inside kubernetes. So, we decided to use init container for database initialization.
As I mentioned before, the application should work out of the box in completely different environments, support different application servers/databases and integration interfaces with third-party systems.
There are a lot of ways to initialize the application:
We chose the last one, we created additional replication controller for initializing the application? Really?
We read the documentation again.
A pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.
POD is a group of the containers. As a result, we decided to run 3 containers in an application POD
This approach allows to store our configuration as a code, there are two interesting results: the application configuration is testable and reproducible.
There a lot of already exists for managing openshift.
During the migration, I’ve tested some of them. I’d like to share my results.
Ansible container was replaced by Ansible bender.
An Ansible Playbook Bundle (APB) is a lightweight application definition (meta-container). They are used to define and deploy complex groups of applications, deployment configs, deployments, and services to an OpenShift Origin cluster running the Ansible Service Broker. APBs offer more power and simple configuration by leveraging the power of Ansible. APBs have the following features:
The main idea is that you pack all needed thing into a container and run the container inside Openshift. Ansible Playbook Bundle
One one hand I don’t want to be the final authority, but on the other hand, I’d like to share my point of view. There is no silver bullet exists.