[EDP-DDM-26049] Added about migration strategy in en and ua versions,…

… refactored structure, added overview Change-Id: I2657b02edc15c6e49509a6a86d000089eb056d54
epam · Sep 14, 2023 · 335e1b8 · 335e1b8
1 parent 3e666d3
commit 335e1b8
Show file tree

Hide file tree

Showing 12 changed files with 163 additions and 42 deletions.
diff --git a/docs/en/modules/admin/pages/admin-overview.adoc b/docs/en/modules/admin/pages/admin-overview.adoc
@@ -13,7 +13,7 @@ This section is an essential resource for technical professionals aiming to full
 
 * xref:admin:installation/overview.adoc[Installing and configuring]
 * xref:admin:registry-management/overview.adoc[Managing the Platform and registries in the Control Plane]
-* xref:admin:migrate-registry.adoc[Migrating registries]
+* xref:admin:migration/migration-overview.adoc[Migration]
 * xref:admin:update/overview.adoc[Updating]
 * xref:admin:backup-restore/overview.adoc[Backing up and restoring]
 * xref:admin:scaling/overview.adoc[Scaling]

diff --git a/...modules/admin/pages/migrate-registry.adoc → ...min/pages/migration/migrate-registry.adoc b/...modules/admin/pages/migrate-registry.adoc → ...min/pages/migration/migrate-registry.adoc
@@ -1,21 +1,13 @@
-:toc-title: On this page:
-:toc: auto
-:toclevels: 5
-:experimental:
-:sectnums:
-:sectnumlevels: 5
-:sectanchors:
-:sectlinks:
-:partnums:
-
-//= Міграція реєстрів
 = Migrating registries
+include::platform:ROOT:partial$templates/document-attributes/default-set-en.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-en.adoc[]
+
+This page provides a practical guide for seamlessly migrating between two OKD clusters.
 
-//== Позначення та скорочення
 == Terminology
 
-//TODO: Added intro
-This guide provides instructions on migrating a registry from one cluster to another. We use the following names to identify the clusters:
+We use the following names to identify the clusters:
 
 //* [.underline]#Кластер А# -- кластер, на якому розгорнуто наявний реєстр.
 //* [.underline]#Кластер B# -- кластер, куди буде перенесено наявний реєстр (цільовий кластер).
@@ -746,6 +738,4 @@ Transfer registry configuration parameters (the `global.registry` section) from
 * *Access restrictions* (for details, see xref:admin:registry-management/control-plane-cidr-access-endpoints.adoc[]).
 * *Service providers authentication* (for details, see xref:registry-develop:registry-admin/cp-auth-setup/cp-auth-setup-officers.adoc[] and xref:registry-develop:registry-admin/cp-auth-setup/cp-officer-self-registration.adoc[]).
 * *Service recipients authentication* (for details, see xref:registry-develop:registry-admin/cp-auth-setup/cp-auth-setup-citizens.adoc[])
-* *Backup* (for details, see xref:admin:backup-restore/control-plane-backup-restore.adoc[] and xref:admin:backup-restore/backup-schedule-registry-components.adoc[]).
-
-//NOTE: У випадку будь-яких проблем із міграцією, зверніться до [email protected].
+* *Backup* (for details, see xref:admin:backup-restore/control-plane-backup-restore.adoc[] and xref:admin:backup-restore/backup-schedule-registry-components.adoc[]).
diff --git a/docs/en/modules/admin/pages/migration/migration-overview.adoc b/docs/en/modules/admin/pages/migration/migration-overview.adoc
@@ -0,0 +1,15 @@
+:sectlinks:
+:sectanchors:
+
+= Migration
+
+include::platform:ROOT:partial$admonitions/language-en.adoc[]
+
+The *_Migration_* section provides you with a comprehensive look into our migration framework. Begin with xref:admin:migration/migration-strategy.adoc[Understanding our migration strategy], where you'll delve into our cloud-agnostic approach, exploring essential prerequisites and restrictions and understanding the principles of our Velero-driven method.
+
+Next, jump into the xref:admin:migration/migrate-registry.adoc[Migrating registries] page for a practical guide on executing the migration seamlessly between OKD Cluster A and B.
+
+== Section overview
+
+* xref:admin:migration/migration-strategy.adoc[Understanding our migration strategy]
+* xref:admin:migration/migrate-registry.adoc[Migrating registries]
diff --git a/docs/en/modules/admin/pages/migration/migration-strategy.adoc b/docs/en/modules/admin/pages/migration/migration-strategy.adoc
@@ -0,0 +1,57 @@
+= Understanding our migration strategy
+include::platform:ROOT:partial$templates/document-attributes/default-set-en.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-en.adoc[]
+
+TIP: See the migration process in action: xref:admin:migration/migrate-registry.adoc[].
+
+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.
+
+== 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.
+
+== Two cluster scenarios
+
+Consider we have OKD Cluster A in AWS and OKD Cluster B in vSphere. Migration happens between these two clusters.
+
+== 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.
+
+== 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.
+
+== 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.
+
+== 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.
+
+=== 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:
+
+. *Extract*: This step involves pulling data from various sources.
+
+. *Transform*: The extracted data is converted or processed into a desired format or structure for further use or storage.
+
+. *Load*: This is the phase where the transformed data is loaded into a destination system or database.
+
+=== 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.
+
+== Related pages
+
+* xref:admin:migration/migrate-registry.adoc[]
+* xref:registry-develop:data-modeling/initial-load/index.adoc[]
diff --git a/docs/en/modules/admin/partials/nav.adoc b/docs/en/modules/admin/partials/nav.adoc
@@ -34,7 +34,9 @@
 *** xref:admin:registry-management/control-plane-quick-links.adoc[Quick links to registry services]
 // ===================== MIGRATING REGISTRIES ========================
 +
-** xref:admin:migrate-registry.adoc[Migrating registries]
+** xref:admin:migration/migration-overview.adoc[Migration]
+*** xref:admin:migration/migration-strategy.adoc[Understanding our migration strategy]
+*** xref:admin:migration/migrate-registry.adoc[Migrating registries]
 +
 //========================= UPDATING =========================
 ** xref:admin:update/overview.adoc[Updating]

diff --git a/docs/ua/modules/admin/pages/admin-overview.adoc b/docs/ua/modules/admin/pages/admin-overview.adoc
@@ -13,7 +13,7 @@
 
 * xref:admin:installation/overview.adoc[Встановлення та налаштування]
 * xref:admin:registry-management/overview.adoc[Керування Платформою та реєстрами в Control Plane]
-* xref:admin:migrate-registry.adoc[Міграція реєстрів]
+* xref:admin:migration/migration-overview.adoc[Міграція]
 * xref:admin:update/overview.adoc[Оновлення]
 * xref:admin:backup-restore/overview.adoc[Резервне копіювання та відновлення]
 * xref:admin:scaling/overview.adoc[Масштабування]

diff --git a/docs/ua/modules/admin/pages/admin-study/platform-admin-study.adoc b/docs/ua/modules/admin/pages/admin-study/platform-admin-study.adoc
@@ -65,7 +65,7 @@ TIP: Детальніше про CIDR читайте на сторінці xref:
 Міграція реєстру виконується з останньої резервної копії наявного реєстру та переноситься із кластера А до кластера Б й відновлюється вже на цільовому кластері.
 
 [TIP]
-Детальніше про перенесення реєстру ви можете переглянути на сторінці xref:admin:migrate-registry.adoc[].
+Детальніше про перенесення реєстру ви можете переглянути на сторінці xref:migration/migrate-registry.adoc[].
 
 == Резервне копіювання та відновлення центральних компонентів Платформи
 

diff --git a/...modules/admin/pages/migrate-registry.adoc → ...min/pages/migration/migrate-registry.adoc b/...modules/admin/pages/migrate-registry.adoc → ...min/pages/migration/migrate-registry.adoc
@@ -1,23 +1,9 @@
-:toc-title: ЗМІСТ
-:toc: auto
-:toclevels: 5
-:experimental:
-:important-caption:     ВАЖЛИВО
-:note-caption:          ПРИМІТКА
-:tip-caption:           ПІДКАЗКА
-:warning-caption:       ПОПЕРЕДЖЕННЯ
-:caution-caption:       УВАГА
-:example-caption:           Приклад
-:figure-caption:            Зображення
-:table-caption:             Таблиця
-:appendix-caption:          Додаток
-:sectnums:
-:sectnumlevels: 5
-:sectanchors:
-:sectlinks:
-:partnums:
-
 = Міграція реєстрів
+include::platform:ROOT:partial$templates/document-attributes/default-set-ua.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-ua.adoc[]
+
+Ця сторінка надає практичне керівництво з виконання міграції між OKD кластерами A та B.
 
 == Позначення та скорочення
 

diff --git a/docs/ua/modules/admin/pages/migration/migration-overview.adoc b/docs/ua/modules/admin/pages/migration/migration-overview.adoc
@@ -0,0 +1,12 @@
+= Міграція
+
+include::platform:ROOT:partial$admonitions/language-ua.adoc[]
+
+Розділ _Міграція_ представляє докладний огляд нашої міграційної концепції. Почніть з xref:admin:migration/migration-strategy.adoc[Розуміння нашої стратегії міграції], де ви познайомитеся із cloud-агностичним підходом, дізнаєтеся про основні передумови та обмеження, а також зрозумієте принципи нашого методу на базі _Velero_.
+
+Далі перейдіть на сторінку xref:admin:migration/migrate-registry.adoc[Міграція реєстрів] для практичного керівництва з виконання міграції між OKD кластерами A та B.
+
+== Огляд секції
+
+* xref:admin:migration/migration-strategy.adoc[]
+* xref:admin:migration/migrate-registry.adoc[]
diff --git a/docs/ua/modules/admin/pages/migration/migration-strategy.adoc b/docs/ua/modules/admin/pages/migration/migration-strategy.adoc
@@ -0,0 +1,57 @@
+= Розуміння нашої стратегії міграції
+include::platform:ROOT:partial$templates/document-attributes/default-set-ua.adoc[]
+
+include::platform:ROOT:partial$admonitions/language-ua.adoc[]
+
+TIP: Перегляньте процес міграції на прикладі: xref:admin:migration/migrate-registry.adoc[].
+
+Наша стратегія міграції дозволяє безперебійно переходити з одного оточення в інше без прив'язки до конкретної хмари або середовища. Наш пріоритет -- _забезпечення безпеки даних, консистентності та доступності_ під час міграції. Ми гарантуємо _цілісність даних та мінімальні перебої в роботі_ шляхом контролю та обмеження процесу міграції в межах наших визначених кластерів.
+
+== Cloud-агностичний підхід
+
+Наша система не залежить від конкретного оточення. Вона є cloud-agnostic, тобто не прив'язана до середовища. Це означає, що ви можете мігрувати реєстри, їх компоненти та ресурси між різними оточеннями, від публічних до приватних хмар, на локальні системи (_наприклад, з AWS на vSphere_), та навпаки.
+
+== Сценарії для двох кластерів
+
+Припустимо, у нас є кластер OKD A на AWS і кластер OKD В на vSphere. Міграція можлива між цими двома кластерами.
+
+== Попередні умови для міграції
+
+Встановлення Платформи та її основних компонентів інфраструктури на кластерах A та B необхідне для початку міграції. Головне, що треба пам'ятати — міграція можлива лише між однаковими версіями (скажімо, версія `1.9.5`) Платформи та реєстрів на обох кластерах A і B.
+
+== Обмеження зовнішньої міграції
+
+* Міграція до чистого кластера OKD у будь-якому оточенні неможлива. Це обмеження існує, тому що критичні процеси, як вхід до порталів або інструментів адміністрування, залежать від Keycloak. Keycloak є частиною управління користувачами й встановлюється та оновлюється під час розгортання Платформи.
+
+* Базова версія регламенту реєстру береться із центрального Gerrit-репозиторію під час розгортання Платформи.
+
+* Образи Docker, які є життєво важливими для роботи, отримуються з Docker Registry Nexus під час розгортання Платформи.
+
+== Процес міграції
+
+Механізм *_Velero_* відповідає за процес міграції. Velero -- це відкрите програмне забезпечення, адаптоване до потреб нашого продукту. Цей інструмент встановлюється та оновлюється під час розгортання Платформи.
+
+== Міграція наявних систем на нашу Платформу
+
+Наша Платформа перш за все зосереджена на управлінні етапом *"Завантаження"* у процесі *ETL*, який передбачає імпорт попередньо оброблених та трансформованих даних. Перед передачею даних до нашої системи важливо витягти їх з вашої поточної конфігурації та, за потреби, перетворити їх у відповідний формат. Після завершення цих етапів наша Платформа може ефективно та надійно здійснювати процес імпорту даних.
+
+=== Короткий огляд процесу ETL
+
+*ETL* -- це скорочення від *Витягування*, *Трансформація*, *Завантаження*. Це основні етапи переміщення даних з однієї системи чи формату в інший:
+
+. *Витягування*: На цьому етапі дані отримуються з різних джерел.
+
+. *Трансформація*: Витягнуті дані перетворюються або обробляються у потрібний формат чи структуру для подальшого використання або зберігання.
+
+. *Завантаження*: На цьому етапі трансформовані дані завантажуються в систему призначення або базу даних.
+
+=== Зони відповідальності
+
+* *Витягування & Трансформація*: Перед використанням нашої Платформи користувачі або організації повинні самостійно керувати етапами витягування та трансформації. Ці етапи можуть включати різні інструменти або процеси, що відповідають їх конкретним потребам.
+
+* *Завантаження*: Наша Платформа спеціалізується виключно на цьому останньому етапі, гарантуючи ефективне та безпечне завантаження даних без обробки початкового витягування та трансформації.
+
+== Пов'язані сторінки
+
+* xref:admin:migration/migrate-registry.adoc[]
+* xref:registry-develop:data-modeling/initial-load/index.adoc[]
diff --git a/docs/ua/modules/admin/partials/nav.adoc b/docs/ua/modules/admin/partials/nav.adoc
@@ -37,7 +37,9 @@
 *** xref:admin:registry-management/control-plane-quick-links.adoc[]
 +
 // ===================== МІГРАЦІЯ РЕЄСТРІВ ========================
-** xref:admin:migrate-registry.adoc[]
+** xref:admin:migration/migration-overview.adoc[]
+*** xref:admin:migration/migration-strategy.adoc[]
+*** xref:admin:migration/migrate-registry.adoc[]
 +
 //========================= ОНОВЛЕННЯ =========================
 ** xref:admin:update/overview.adoc[]

diff --git a/docs/ua/modules/platform-develop/pages/platform-prod-deployment.adoc b/docs/ua/modules/platform-develop/pages/platform-prod-deployment.adoc
@@ -354,7 +354,7 @@ TIP: Детальніше про це див. на сторінці xref:admin:u
 
 Міграція реєстру виконується з останньої резервної копії наявного реєстру та переноситься із кластера А до кластера В й відновлюється вже на цільовому кластері.
 
-TIP: Детальніше про це див. на сторінці xref:admin:migrate-registry.adoc[].
+TIP: Детальніше про міграцію див. у розділі xref:admin:migration/migration-overview.adoc[].
 
 == Підготовчі дії на рівні реєстрів