This site is also available in: Deutsch (German)
Introduction
Migrating from RedHat’s OpenShift 3 to 4 presents organizations with an exciting but challenging task.
With the need to migrate a multitude of services smoothly, it becomes clear that every migration comes with its own lessons.
This article dives into the world of migrating from RedHat OpenShift 3 to 4 and shares valuable lessons learned from microservices migrations.
These valuable insights can be of great interest to other organizations and engineers.
The challenge of migration
Migrating from OpenShift 3 to 4 is more than just a version change. It requires thorough planning to ensure that existing services run smoothly on the new platform. In particular, the migration of many services requires a careful analysis of dependencies, configurations and implementations.
A few important challenges can be noted in brief:
- Configuration management
- Secret management
- Packaging of microservices
- Release management
Configuration management
The correct handling of application configurations ensures the smooth functioning of the services on the various stages.
A central point in the migration of applications to OpenShift 4 concerns the management of configuration settings. There are two main categories here:
Standardized settings:
Some configurations are the same on all stages (e.g. development, test, production) and can be stored securely in the microservice repository. This enables centralized maintenance and versioning of the settings.
Different settings:
There are configurations that differ between the stages (e.g. debugging flags, logging level). These settings should not be hidden in secret Secrets/ConfigMaps, but should be transparent to allow potential analysis and debugging.
Possible locations are value-files in Helm or overlays in Kustomize.
Secret management
The actual secrets, such as sensitive passwords for databases or access data for services such as Kafka, require special attention. Proven procedures and tools are crucial here:
Secret Encryption:
To store real secrets securely, the use of encrypted code libraries is essential. Bitnami Sealed Secrets and HashiCorp Vault are two popular solutions. They enable the storage and encryption of sensitive data in the code repository.
Secret Management Tools:
HashiCorp Vault offers not only encryption, but also a central interface for the management of sensitive data. This makes it easier to update, rotate and monitor secrets.
In this context, it is also common to query secrets from an API using a sidecar container and inject them into the main container so that the openshift application developer, but also third parties, do not have access to the secrets.
This requires that the applications support this and may require some effort.
Best practices for effective secret management
During the migration from RedHat OpenShift 3 to 4, the following best practices can help in dealing with secrets and configurations:
1. clear separation: make a clear distinction between application configurations and real secrets. This allows you to maintain an overview and increase security.
2. documentation: Record which configurations and secrets are used on which stages. Clear documentation makes maintenance and analysis easier.
3. roles and access rights: Manage access rights to secrets carefully. Only authorized persons should be able to access sensitive information.
4. rotation: Implement regular rotation of real secrets such as passwords. This minimizes the risk of security breaches.
Release management
Migrating from RedHat OpenShift 3 to 4 requires not only an efficient release management strategy, but also the right tools and practices to facilitate the process. In this article, we will take a closer look at the use of ArgoCD and the differences between Helm and Kustomize. We will also emphasize the best practices for deploying microservices by pointing out the use of independent deployments instead of large “umbrella charts”.
ArgoCD: Simplified and automated release management
ArgoCD is a powerful tool for the continuous deployment of applications on Kubernetes clusters. It enables automated deployment of applications and resources on OpenShift 4. ArgoCD uses Git repositories as the source of truth for your configurations, which facilitates versioning and tracking.
Helmet vs. Kustomize: Choosing the right tools
When managing Kubernetes manifests, you can choose between Helm and Kustomize, depending on your preferences and requirements:
Helm: Helm is a popular package management tool that makes it easy to create, update and manage applications on Kubernetes. It provides an easy way to create templates for Kubernetes manifests and define reusable charts, which can be particularly useful for microservices.
Kustomize: Kustomize is another tool that is gaining importance in the open source community. It enables the customization of Kubernetes resources based on overlays without changing the original files. Kustomize is often the choice when it comes to customizing configurations for infrastructure components.
Independent microservice deployments
A crucial aspect of successful release management during migration is the way in which microservices are provided. Instead of large “umbrella charts” that bundle all microservices, they should be deployed independently of each other. This offers several advantages:
-
Independence: Microservices can be developed and deployed at their own speed without waiting for others.
-
Scalability: Each microservice can be scaled individually, which enables resource optimization.
-
Isolation: Errors in one microservice do not affect others because they are isolated.
Packaging of microservices
When migrating from RedHat OpenShift 3 to 4, efficient packaging of microservices is critical to optimize application management and deployment. We explain how the structure of microservice repositories can be designed to promote the use of shared Helm charts while ensuring consistent configuration across all stages.
The structure of the microservice repository
In each microservice repository, there should be a clearly defined Helm charts folder containing the standard values.yaml file for all stages. This values.yaml file contains the basic configurations that apply to the microservice and are shared across all stages.
Avoidance of superfluous helmet charts
An important practice when packaging microservices is to avoid unnecessary duplication. This means that no new Helm Chart should be created in each microservice repository if a corresponding shared base Helm Chart is already available.
Use of shared base helmet charts
The solution lies in the use of Shared Base Helm Charts, which are provided by the company and can serve as the basis for various microservices. These Shared Base Helm Charts can be developed for different types of applications such as frontend and backend and provide a centralized way to share common configurations and best practices.
Advantages of using Shared Base Helm Charts:
Consistency: Shared Base Helm Charts ensure a consistent configuration across all microservices. This minimizes the risk of configuration errors and facilitates maintenance.
- Efficiency: By reusing Helm charts, developers can save time and effort as they do not have to create a new chart from scratch each time.
- Centralized management: The company can centrally manage the Shared Base Helm Charts and make updates to ensure best practices and safety guidelines are followed.
- Flexibility: Despite the common basis, microservices can still be individually configured to meet your specific requirements.
