Understanding our migration strategy

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.
See the migration process in action: Migrating registries.

Our migration methodology seamlessly transitions from one infrastructure to another without being tied to any specific cloud or environment. Our priority is ensuring data security, consistency, and availability during the migration. We can offer high data integrity and minimal service disruption by controlling and limiting the migration process within our defined clusters.

1. Cloud-agnostic approach

Our system does not depend on any particular environment. It is cloud-agnostic. This approach means it can migrate registries, their components, and resources between different environments, from public to private clouds, on-premises, and vice versa—AWS to vSphere.

2. Two cluster scenarios

Consider we have OKD Cluster A in AWS and OKD Cluster B in vSphere. Migration happens between these two clusters.

3. Pre-conditions for migration

Installing the Platform and its central infrastructure components on Clusters A and B are necessary to begin migration. The only thing to remember is that the migration is possible only between the identical versions (say version 1.9.5) of the Platform and registries on both Clusters A and B.

4. Restrictions on external migration

  • Migration to a bare OKD Cluster in any environment is not feasible. This limitation exists because critical processes like portal or admin tool logins rely on Keycloak. Keycloak is part of the user management, and it gets installed and updated when the Platform is deployed.

  • The basic version of the regulations comes from a central repository in Gerrit during Platform deployment.

  • Docker images, which are crucial for operation, are fetched from the Docker Registry Nexus during the Platform deployment.

5. Migration process

The Velero mechanism enables the migration process. Velero is an open-source solution adapted to the needs of our product. It is installed and updated during the Platform deployment.

6. Migrating existing systems onto our Platform

Our Platform primarily focuses on managing the "Load" stage of the ETL process, which involves importing pre-processed and transformed data. Before transferring your data to our system, it’s essential to extract them from your current setup and, if required, convert them to the relevant format. After completing these steps, our Platform can effectively and dependably handle the data import process.

6.1. Brief overview of the ETL process

ETL stands for Extract, Transform, Load. These represent the three primary stages of moving data from one system or format to another:

  1. Extract: This step involves pulling data from various sources.

  2. Transform: The extracted data is converted or processed into a desired format or structure for further use or storage.

  3. Load: This is the phase where the transformed data is loaded into a destination system or database.

6.2. Areas of responsibility

  • Extract & Transform: Before using our Platform, users or organizations must independently manage the extraction and transformation stages. These stages could involve various tools or processes suited to their specific needs.

  • Load: Our Platform specializes solely in this final stage, ensuring efficient and secure data loading without handling the initial extraction and transformation.

7. Related pages