Exploring an Alternative to OpenShift /1
18.03.2024
When looking for solutions, there is often a tendency to prefer more economical and open-source choices with equivalent functionality. In our case, we were searching for a container orchestration platform to develop a microservices architecture, which included CI/CD tools and supported a DevOps approach.
Specifically, we simplify the requirements as follows:
- The architecture consists of approximately 20 microservices;
- Each microservice must be encapsulated in its own pod;
- The code is stored in GitLab repositories and, with each code push, the respective microservice must be restarted with the updated code;
- It should be possible to monitor and manage the entire environment through a graphical interface with different user roles and permissions.
To meet the requirements, the initial choice fell on RedHat's OpenShift: "a cloud-based Kubernetes platform that helps developers build applications." This solution met all the established requirements, but we encountered two issues: the fact that OpenShift is proprietary and its recurring cost. Therefore, we had two additional requirements, leading us to question how we could achieve the same functionality while adhering to them.
After studying various possibilities and having only a VM available in the cloud, we chose to install Kubernetes and to add two Docker containers for Jenkins and Rancher to obtain the required CI/CD and DevOps functionalities.
The final workflow is as follows: with each code push to the GitLab repository, a trigger notifies Jenkins to initiate a new build. Jenkins proceeds to create a new Docker image of the microservice according to the specifications outlined in a Dockerfile and saves the image in a container registry hosted in GitLab. It then initiates a deployment phase in the Kubernetes environment, replacing the old pod of the microservice with a new one based on the newly created image. Finally, through Rancher, it is possible to monitor the status of the Kubernetes cluster, allowing for the reading of logs from each microservice and executing commands within them through a shell. A possible evolution involves migrating the CI/CD functions from Jenkins to GitLab pipelines to streamline the architecture and reduce the number of tools to manage.
In particular, I would suggest Rancher for its ease of installation as a Docker container and its extensive capabilities in managing Kubernetes clusters. Additionally, Rancher allows for the automated creation of Kubernetes clusters in managed k8s cloud environments such as EKS (AWS), AKS (Azure), and GKE (Google Cloud) without manual intervention.
If you have any suggestions on how to improve this architecture or if you need more information, please let me know!