Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Такім чынам, адбыўся афіцыйны запуск платформы Red Hat OpenShift 4. Сёння мы раскажам, як перайсці на яе з OpenShift Container Platform 3 максімальна хутка і проста.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

У рамках гэтага артыкула нас першым чынам цікавяць новыя кластары OpenShift 4, якія выкарыстоўваюць магчымасці разумнай і нязменнай (immutable - аднолькавай для ўсіх асяроддзяў разгортвання) інфраструктуры на аснове RHEL CoreOS і сродкаў аўтаматызацыі. Ніжэй мы пакажам, як перайсці на OpenShift 4 без лішніх праблем.

Даведацца падрабязней пра адрозненні новай версіі ад старой можна тут.

Міграцыя кластараў з OpenShift 3 на OpenShift 4 з выкарыстаннем сертыфікаванай платформы Red Hat Appranix

Appranix і Red Hat старанна працавалі над тым, каб упрасіць міграцыю кластарных рэсурсаў з OpenShift 3 на OpenShift 4 з дапамогай адмысловага сэрвісу, які працуе па-над Appranix Site Reliability Automation для Kubernetes.

Рашэнне Appranix (яго можна знайсці ў Red Hat Container Catalog) дазваляе стварыць бэкапы ўсіх кластараў OpenShift 3 і аднавіць іх на OpenShift 4 усяго за некалькі клікаў.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Чым добрая міграцыя з выкарыстаннем Appranix для OpenShift 4

  • Хуткі старт. Паколькі рашэнне Appranix пабудавана на прынцыпах SaaS, не трэба наладжваць ніякую інфраструктуру і канфігураваць ці выкарыстоўваць асобныя спецыялізаваныя рашэнні для міграцыі.
  • Маштабаванасць Appranix палягчае міграцыю вялікіх кластараў.
  • Аўтаматычны бэкап складаных кластарных канфігурацый OpenShift 3 з наступным пераносам на OpenShift 4 спрашчае сам працэс міграцыі.
  • Магчымасць пратэставаць, як прыкладанні з карпаратыўнай інфраструктуры OpenShift 3 паводзяць сябе на платформе OpenShift 4 у воблаку AWS.
  • Міграцыя RBAC-налад доступу разам з рэсурсамі кластара.
  • Выбарачная ці поўная міграцыя ўсіх праектаў на новыя кластары OpenShift 4.
  • Апцыянальна - арганізацыя некалькіх узроўняў адмоваўстойлівасці для кантэйнерных прыкладанняў пры наяўнасці адпаведнай падпіскі.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Шматузроўневая адмоваўстойлівасць (resiliency) для прыкладанняў OpenShift

Пасля міграцыі з 3-й на 4-ю версію OpenShift рашэнне Appranix можна выкарыстоўваць для забеспячэння бесперапыннай адмоваўстойлівасці прыкладанняў (Continuous App Resilience), у якой магчымыя тры варыянты. узровень 1 устойлівасці (Level 1 Resiliency) дазваляе аднавіць прыкладанні без змены рэгіёну і хмарнага правайдэра. Ён можа выкарыстоўвацца для адкату прыкладанняў ці ўзнаўленні пасля лакальнага збою на ўзроўні рэгіёна, напрыклад, у выпадку няўдалага разгортвання прыкладання, або ў сітуацыі, у якой неабходна хутка стварыць тэставае асяроддзе ў тым жа рэгіёне, але ў асобным кластары OpenShift.

узровень 2 дазваляе перанесці прыкладанні ў іншы рэгіён без змены правайдэра. Пры гэтым можна захаваць асноўную (primary) інфраструктуру дадзеных у асноўным рэгіёне, але запускаць прыкладанні ў іншым кластары ў іншым рэгіёне. Гэты варыянт карысны, калі з ладу выходзіць хмарны рэгіён або зона, альбо патрабуецца перакінуць прыкладанні ў іншы рэгіён з-за кібератакі. І нарэшце, узровень 3 дазваляе мяняць не толькі рэгіён, але і хмарнага правайдэра.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Як працуе Appranix SRA
Шматузроўневая адмоваўстойлівасць прыкладанняў OpenShift у Appranix дасягаецца за кошт функцыяналу «машыны часу», аўтаматычна стварае копіі асяроддзя прыкладанняў. Каб задзейнічаць гэты функцыянал і павысіць абароненасць прыкладанняў, дастаткова дадаць у канвеер DevOps усяго адзін радок кода.
У інфраструктурных сэрвісах хмарных правайдэраў таксама ўзнікаюць праблемы, таму магчымасць хутка пераключыцца на іншага правайдэра карысная, каб пазбегнуць залежнасці ад адзінага пастаўшчыка паслуг.

Як паказана на малюнку ніжэй, рэзервовыя копіі асяроддзя прыкладанняў могуць стварацца ў Appranix не толькі аўтаматычна з зададзенай перыядычнасцю, але і па камандзе з канвеера бесперапыннай інтэграцыі і дастаўкі CI/CD. Пры гэтым "машына часу" забяспечвае:

  • Інкрыментны, па тыпу GitHub, часопісаванне прастор імёнаў і асяроддзяў прыкладанняў.
  • Просты адкат прыкладанняў.
  • Кіраванне версіямі канфігурацый хмарных асяроддзяў і кантэйнераў.
  • Аўтаматызаванае кіраванне жыццёвым цыклам даных.
  • Аўтаматызаванне кіраванне інфраструктурай як кодам (IaC).
  • Аўтаматызаванае кіраваннем станамі IaC.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

З дапамогай Appranix можна арганізаваць абарону і аднаўленне на ўзроўні прыкладанняў цалкам для такіх сцэнарыяў, як хаос-інжынірынг (chaos engineering), аварыйнае аднаўленне, абарона ад вымагальніцтваў і забеспячэнне бесперапыннасці бізнес-працэсаў. Мы не будзем спыняцца на гэтым падрабязна і далей разгледзім, як выкарыстоўваць Appranix для міграцыі з OpenShift 3 на OpenShift 4.

Як выконваецца міграцыя OpenShift 3 на OpenShift 4 з выкарыстаннем Appranix Site Reliability Platform

Працэс уключае тры этапы:

  1. Наладжваем OpenShift 3 і OpenShift 4 для аўтавыяўлення ўсіх кампанентаў, якія падлягаюць пераносу.
  2. Ствараем палітыкі і задаём прасторы імёнаў для міграцыі.
  3. Аднаўляем усе прасторы імёнаў на OpenShift 4 у адзін клік.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Наладжваем OpenShift 3 і 4 Clusters для аўтавыяўлення

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Appranix лічыць, што ў вас ужо ёсць якія працуюць кластары OpenShift 3 і OpenShift 4. Калі кластараў OpenShift 4 пакуль няма, стварыце іх, скарыстаўшыся дакументацыяй Red Hat па разгортванні OpenShift 4. Настройка асноўнага (primary) і мэтавага (target) кластараў у Appranix выконваецца аднолькава і ўключае ў сябе ўсяго некалькі крокаў.

Усталёўваны Appranix Controller Agent для выяўлення кластараў

Для выяўлення кластарных рэсурсаў патрэбен невялікі агент sidecar-кантролера. Для яго разгортвання дастаткова скапіяваць і ўставіць адпаведную каманду curl, як паказана ніжэй. Пасля таго, як агент будзе ўсталяваны ў OpenShift 3 і ў OpenShift 4, Appranix аўтаматычна выявіць усе якія падлягаюць міграцыі кластарныя рэсурсы, уключаючы прасторы імёнаў, разгортванні, pod-ы, службы, а таксама хасты з іншымі рэсурсамі.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Міграцыя вялікіх размеркаваных прыкладанняў
Цяпер мы на прыкладзе разбяром, як без лішніх намаганняў перанесці з OpenShift 3 на OpenShift 4 размеркаваны мікрасэрвісны дадатак SockShop (па спасылцы – падрабязнае апісанне гэтага прыкладання і яго мікрасэрвіснай архітэктуры). Як відаць з малюнка ніжэй, архітэктура SockShop змяшчае мноства кампанентаў.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Appranix выяўляе ўсе рэсурсы, для якіх неабходна забяспечыць абарону і міграцыю на OpenShift 4, у тым ліку, PoD-ы, разгортванні (deployments), сэрвісы і кластарныя канфігурацыі.

OpenShift 3 з працуючым дадаткам SockShop

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Ствараем палітыкі Protection Policies для міграцыі

Палітыкі можна задаваць гнутка ў залежнасці ад таго, як мусіць праводзіцца міграцыя. Напрыклад, на аснове некалькіх крытэрыяў або бэкапаў адзін раз у гадзіну.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Выконваем міграцыю некалькіх кластараў OpenShift 3 з дапамогай планаў абароны (Protection Plans)

У залежнасці ад асаблівасцяў прыкладання ці прасторы імёнаў, да кластараў OpenShift 3 можна ўжываць палітыкі, якія адпрацоўваюцца раз у гадзіну, раз у тыдзень ці нават раз у месяц.

Appranix дазваляе перанесці на OpenShift 4 усе прасторы імёнаў кластара ці ж толькі абраныя прасторы.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Выконваем міграцыю на OpenShift 4 у адзін клік

Міграцыя - гэта аднаўленне абраных прастор імёнаў на мэтавай кластар OpenShift 4. Гэтая аперацыя выконваецца ў адзін клік. Appranix сам прарабляе ўсю працу па зборы дадзеных аб канфігурацыі і рэсурсах зыходнага асяроддзя і затым самастойна аднаўляе яе на платформе OpenShift 4.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Правяраем прыкладанні пасля міграцыі на OpenShift 4

Залагінцеся на кластар OpenShift 4, абновіце праекты і праверце, што ўсе прыкладанні і прасторы імёнаў у парадку. Паўторыце працэдуру міграцыі для іншых прастор імёнаў, стварыўшы для гэтага новыя планы Protection Plans або змяніўшы ўжо наяўныя.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Запускаем міграваныя прыкладанні на OpenShift 4

Пасля міграцыі прыкладанняў з дапамогай працэдуры аднаўлення Appranix важна не забыцца наладзіць маршруты - яны павінны паказваць OpenShift 4. Магчыма, што, перш чым цалкам пераносіць прадакшн з OpenShift 3, вам захочацца правесці тэставае аднаўленне. Калі на OpenShift 4 з'явяцца некалькі працавальных прыкладанняў у адпаведных прасторах імёнаў, узнікне неабходнасць перанесці і астатнія прыкладанні з ужываннем гэтага працэсу.

Пасля пераносу ўсіх прастор імёнаў вы зможаце абараніць усе кластары OpenShift для бесперапыннага аварыйнага аднаўлення, абароны ад вымагальніцтваў, забеспячэнні бесперапыннасці бізнеспрацэсаў або для наступнай міграцыі, паколькі Appranix Site Reliability Automation аўтаматычна абнаўляецца па меры выхаду новых версій OpenShift.

Спрашчаем міграцыю з OpenShift 3 на OpenShift 4

Разам

OpenShift 4 - гэта вялікі крок наперад, перш за ўсё, за кошт новай нязменнай архітэктуры і Operator-платформеннай мадэлі для аўтаматызацыі складаных канфігурацый прыкладанняў і платформаў, якія працуюць у кластарных асяроддзях. Appranix прапануе карыстальнікам OpenShift просты і зручны спосаб пераходу на OpenShift 4 з дапамогай свайго хмарна-арыентаванага рашэння для аварыйнага аднаўлення прыкладання Site Reliability Platform.

Рашэнне Appranix можна выкарыстоўваць прама з Red Hat Container Catalog.

Крыніца: habr.com

Дадаць каментар