Wróć do bloga

Migracja CloudHub 1.0 → CloudHub 2.0: pułapki, które warto znać przed cutoverem

2026-09-17

Migracja CloudHub 1.0 → CloudHub 2.0 to przejście z workerów na kontenerowe repliki oraz z VPC/DLB na Private Space z managed ingress — nie jest to prosty redeploy tej samej paczki JAR. Oficjalne narzędzia (VPC upgrade + application linking z %-owym ruchem) skracają ścieżkę infrastrukturalną, ale nie zastępują redesignu wzorców, których CloudHub 2.0 świadomie nie wspiera: persistent VM queues, CloudHub Connector, Insights, JVM override, TLS 1.0 czy Mule poniżej 4.3.

Czego ten tekst nie jest: checklistą marketingową „przenieś i zapomnij”. Jest praktycznym przewodnikiem cutoveru dla architektów i leadów integracji, którzy planują VPC upgrade tool, linkowanie aplikacji i rampę ruchu — zanim partnerzy biznesowi zobaczą timeouty, a zespół „sprzątnie” CloudHub 1.0 za wcześnie.

Poniżej: skrót różnic, które realnie psują migrację, karty pułapek (objaw → przyczyna → dokumentacja → wzorzec), uporządkowana checklista oraz FAQ gotowe pod AEO.

CH1 vs CH2 w skrócie (tylko to, co psuje migrację)

Workers → replicas, VPC → Private Space, DLB → managed ingress

Na CloudHub 1.0 aplikacja biegnie na workerach (VM) w VPC, z opcjonalnym Dedicated Load Balancerem. Na CloudHub 2.0 — na replikach (kontenery) w Private Space, z automatycznie provisionowanym ingress load balancerem. Nazwy aplikacji są unikalne w obrębie Business Group / Private Space (nie per cały control plane jak na CH1). Statyczne IP wychodzące na CH2 są na poziomie Private Space (współdzielone przez aplikacje), a nie per-app jak przy włączonych Static IPs na CH1.

Źródło: CloudHub 2.0 for CloudHub 1.0 Users, Migration Configuration.

Co oficjalnie nie jest wspierane

Zanim klikniesz Upgrade, inventory powinno wyłapać m.in.:

Obszar Status na CH2
Mule < 4.3.0 Nie wspierane
Persistent VM queues Nie wspierane — użyj zewnętrznego brokera (np. Anypoint MQ)
CloudHub Connector Nie wspierane
Custom notifications / Insights Nie wspierane → Anypoint Monitoring
Overwriting JVM parameters / custom JVM truststore Nie wspierane
TLS 1.0 Nie wspierane (1.2 / 1.3)
VPN między VPC CH1 a Private Space CH2 Niemożliwe
VPC peering / Direct Connect Deprecated na CH2 → Transit Gateway / VPN

Źródło: ch2-comparison — Considerations and Limitations.

Oficjalny blog o upgrade toolu mówi wprost: tooling wspiera przypadki simple-to-moderate; złożone scenariusze wymagają customizacji przed migracją — nie „zero redesign”.

Pułapka #1: Persistent VM queues → Anypoint MQ / broker

Dlaczego CH2 nie wspiera persistent VM queues

Objaw: po deployu na CH2 znika opcja „Persistent queues”; albo kolejka VM traci wiadomości po restarcie / crashu.

Przyczyna: architektura kontenerowa z volatile storage. Lokalny persistent="true" na dysku kontenera nie przeżywa restartu ani redeployu. Oficjalna ścieżka: zewnętrzny broker.

Co mówią docs: „Use Anypoint MQ for persistent queues… Persistent queues are not supported.” (ch2-comparison); migracja wymaga usunięcia persistent queues i implementacji Anypoint MQ (migration-configuration); blog Transition from Persistent VM Queues… (2024-08-15) wskazuje Anypoint MQ, Kafka/MSK, JMS itd.

Wzorce zamiany + clustering przy schedulerze

  1. Zrób inventory wszystkich vm:publish / vm:consume oraz flagi Persistent queues w Runtime Manager.
  2. Zastąp wzorcem publish → Anypoint MQ (lub Kafka/MSK/JMS) + subscriber flow.
  3. Jeśli źródłem jest scheduler i masz ≥2 repliki: włącz Runtime Cluster Mode (wymaga min. 2 replik). Bez tego każdy kontener odpala scheduler niezależnie → duplikaty.
  4. Stan, który kiedyś „persistował” lokalnie, przenieś do Object Store v2 — CH2 czyści local disk przy restarcie (ch2-clustering).
  5. Skonfiguruj egress do hostów MQ (pułapka #4).

Praktyczny kontekst HA/cluster: CloudHub 2.0 Part II – Shared Space in HA and Cluster Mode. Ścieżka upgrade tool: VirtualMuleys103 – Upgrade Tool Overview oraz oficjalne demo VPC→Private Space.

Pułapka #2: CloudHub Connector i custom notifications

Objaw: deploy lub runtime pada na CloudHub Connector; custom alerts z CH1 milczą; Insights niedostępne.

Przyczyna: CH2 nie wspiera CloudHub Connector, custom notifications ani Insights.

Docs: lista unsupported w ch2-comparison; migration-configuration: Remove CloudHub Connector and replace with custom logic; alerting przez Anypoint Monitoring.

Wzorzec: przed migracją grep po dependency CloudHub Connector i flowach notification. Alerty przenieś do Anypoint Monitoring (per-app). Status operacyjny — przez REST/API Manager lub własne endpointy, nie przez connector platformowy.

Pułapka #3: Sieć — Peer/DC, TGW/VPN, dual-AZ static IPs

Eligibility VPC upgrade

VPC upgrade tool klonuje CIDR i (gdy obecne) TGW/VPN do Private Space — ale tylko dla eligible VPC:

  • ≥ 25% wolnego miejsca oraz ≥ 100 wolnych IP na subnet
  • Legacy VPN dyskwalifikuje
  • Direct Connect / Peering → najpierw migracja na Transit Gateway lub VPN
  • Cipher’y TLS 1.1 SHA1 (ECDHE-*-AES*-SHA1) nie przenoszą się
  • Porty firewall inne niż 80, 443, 30500–32500 odpadają przy migracji
  • Ruch TCP: HTTP/HTTPS OK; tooling nie migruje TCP

Źródło: vpc-upgrade — Eligibility.

Peering nie migruje; CH1↔CH2 VPN zabronione

Peering pozostaje na starym VPC — aplikacje CH2 go nie użyją. Nie utworzysz VPN między VPC CH1 a Private Space CH2 (ch2-comparison). Przy partial migration CH2→CH1 przez DLB dodaj CIDR infrastruktury CH2 do allowlisty DLB: 100.64/66/67/68.0.0/16 (vpc-upgrade).

Dual-AZ IP: narzędzie odkrywa dwa AZ → dwa zestawy inbound/outbound static IP. Na CH2 IP są shared na poziomie Private Space; unikalne IP per app = osobny Private Space (migration-configuration — Static IP Addresses). Przed cutoverem: eksport nowych IP → komunikat do partnerów / firewall team. Podczas upgrade’u liczenia entitlements są podwojone — ustal z account rep.

Pułapka #4: Egress — „wszystko działało na CH1”

Objaw: app startuje, ale publish do Anypoint MQ, Object Store v2 lub wywołania platformowe kończą się timeoutem / 500; w logach Failed to send request.

Przyczyna: CH1 pozwalał na all outbound bez reguł egress. CH2 ma firewall egress (Private Space + opcjonalnie app-level). Usunięcie default allow-all bez reguł do usług Anypoint blokuje ruch (vpc-upgrade, migration-configuration).

Wzorzec (z bloga App-level Egress Control, 2024-02-06):

  • Nie usuwaj allow-all, dopóki nie masz zamiennika.
  • Rule groups per klasa aplikacji (MQ, OSv2, Salesforce, ERP).
  • Dla Anypoint MQ typowo: HTTPS do anypoint.mulesoft.com oraz regionalnego hosta, np. mq-eu-central-1.anypoint.mulesoft.com (host z URL connectora).
  • Dla OSv2: anypoint.mulesoft.com + object-store-<region>.anypoint.mulesoft.com.
  • Test connectivity przed pierwszym % traffic.

Źródło: App-level Egress Control.

Pułapka #5: Traffic % linking, SLB vs DLB, default *.cloudhub.io

Objaw: po Save Changes na % traffic część lub całość ruchu ginie; switching idzie „nie tą” ścieżką.

Przyczyna — inference traffic source (app-migration — Understanding the Traffic Source):

  • Obecność default endpointu <app>..cloudhub.io ⇒ przełączanie przez SLB
  • Brak default + vanity / anypointdns.net ⇒ DLB
  • Użycie inherited *.cloudhub.io na aplikacji CH2 psuje inference i może dać outage

Dodatkowo: bez permission CloudHub Network Administrator switch failuje; DLB trzeba zrestartować przed switchingiem; aplikacja CH1 musi być STARTED do momentu ustanowienia linku.

Wzorzec: jawnie wybierz ścieżkę SLB vs DLB; dla DLB trzymaj vanity/anypointdns.net (bez default cloudhub.io na CH2). Ramp: 5% → 25% → 50% → 100% z planem rollbacku. HTTPS DLB: Last-Mile Security + Upstream TLS 1.2+. Przy rename CH2 wstaw starą nazwę CH1 w subdomain Ingress — inaczej ruch nie dotrze.

Pułapka #6: Properties, protected values, API policies przy równoległym ruchu

Properties i pułapka ******

Upgrade kopiuje properties w UI, ale nie persystują, dopóki nie zedytujesz ≥1 property albo nie dodasz nowej. Protected props pojawiają się jako ****** — trzeba ręcznie wpisać prawdziwą wartość (app-migration — Application Properties).

Wzorzec: checklista secure props ze vault/secret managera; po upgrade: „touch” jednej property + re-enter wszystkich protected; weryfikacja w non-prod przed linkingiem.

API policies przy split traffic

Obie aplikacje aktywne; policies ze stanem (cache / counters) nie dzielą stanu. Rate-limiting przy round-robin może zachowywać się jak ~2× limit; hard cut ≈ reset counters. Dotyczy m.in. rate-limiting, rate-limiting-sla-based, spike-control, OAuth/JWT/caching policies (app-migration — Managing API Policies).

Wzorzec: zdubluj równoważne policy na API instance CH2 przed % traffic; dla rate-limit rozważ tymczasowe poluzowanie lub hard cut w oknie niskiego ruchu; monitoruj 429 i błędy auth podczas rampy. Autodiscovery może podłączyć obie app do tego samego API w API Managerze.

Checklista cutover (kolejność)

  1. Inventory — persistent queues, CloudHub Connector, porty ≠ 80/443/30500–32500, TLS 1.0/1.1 SHA1, Mule < 4.3, JVM overrides, Insights/custom notifications, outbound allowlisty partnerów.
  2. VPC eligibility — free IP %, legacy VPN, Peer/DC → TGW/VPN, default VPC wyłączony.
  3. Code redesign — MQ/broker, connector out, OSv2 zamiast local disk, runtime ≥ 4.3, pom.xml pod dwuetapowy deploy CH2 (Exchange → deploy).
  4. Private Space / VPC upgrade tool — nazwa space, reserved CIDR jeśli potrzeba; certyfikaty TLS ręcznie jeśli best-effort migrate zawiódł; doubled entitlements z account rep.
  5. Egress — reguły Private Space + app-level do MQ/OSv2/API Manager przed ruchem produkcyjnym.
  6. Deploy CH2 — bez inherited default *.cloudhub.io; vanity/anypointdns.net; Last-Mile Security gdy HTTPS.
  7. Properties — touch + re-enter ******; smoke test non-prod.
  8. Link + % traffic — Network Admin; restart DLB; CH1 STARTED; rampa 5→25→50→100; rollback = obniżenie % / restart CH1.
  9. API policies — równoważna konfiguracja na CH2; monitoring 429/auth.
  10. Stop CH1 w 30 dniach po 100% → delete w kolejnych 30 dniach; potem brak rollbacku i brak ponownego utworzenia CH1 o tej samej nazwie (app-migration — Complete the Application Upgrade).
  11. DLB failover → stop/delete DLB; po delete DLB brak rollbacku.
  12. Cleanup VPC po wszystkich appach — zwolnienie entitlements CH1.

FAQ

1. Czym różni się migracja CloudHub 1.0 → 2.0 od zwykłego redeployu?

Redeploy zakłada tę samą konfigurację runtime i sieci. Migracja CH1→CH2 zmienia model wykonawczy (workers → replicas), sieć (VPC/DLB → Private Space + managed ingress) i listę wspieranych funkcji. Wzorce oparte o persistent VM queues, CloudHub Connector czy założenia „all outbound” wymagają redesignu przed cutoverem; tooling upgrade’u pomaga w infrastrukturze i %-owym ruchu, ale nie usuwa tych luk automatycznie.

2. Czy CloudHub 2.0 wspiera persistent VM queues?

Nie. Dokumentacja porównawcza stwierdza wprost, że persistent queues nie są wspierane i należy użyć Anypoint MQ (lub innego zewnętrznego brokera). Lokalny object store z persistent="true" na dysku też nie przeżywa restartu na CH2 — do stanu między restartami użyj Object Store v2.

3. Czym zastąpić CloudHub Connector i custom notifications?

Usuń CloudHub Connector z aplikacji i zastąp własną logiką / wywołaniami API. Custom notifications i Insights nie działają na CH2 — alerty konfiguruj w Anypoint Monitoring (per aplikacja).

4. Co robi VPC upgrade tool — i czego nie przenosi?

Narzędzie klonuje eligible VPC do Private Space (ten sam CIDR), przenosi TGW/VPN gdy obecne, a certyfikaty DLB migruje best-effort. Nie przenosi peeringu; nie wspiera legacy VPN; nie przenosi cipherów TLS 1.1 SHA1; dropuje niestandardowe porty firewall poza 80/443/30500–32500; nie migruje ruchu TCP. Nie da się zrobić VPN CH1 VPC ↔ CH2 Private Space.

5. Dlaczego po migracji partnerzy biznesowi muszą aktualizować allowlisty IP?

Upgrade/migracja w typowym scenariuszu tworzy Private Space z dwoma AZ, a więc dwoma zestawami inbound/outbound static IP. Na CH2 te IP są współdzielone na poziomie Private Space, nie per aplikacja jak często na CH1. Stare allowlisty oparte o pojedyncze IP workera przestają wystarczać.

6. Jak działa przełączanie ruchu (%) i kiedy mogę się cofnąć (rollback)?

Po zlinkowaniu aplikacji CH1 i CH2 ustawiasz procent ruchu w Runtime Manager (Finish Upgrade). Rollback w trakcie weryfikacji: obniż % lub zrestartuj CH1 i przywróć ruch. Wymagane: permission Network Administrator, restart DLB przed switchingiem, CH1 w stanie STARTED. Inference SLB vs DLB zależy od obecności default *.cloudhub.io w konfiguracji endpointów.

7. Co się dzieje, jeśli usunę aplikację CloudHub 1.0 po migracji?

Po pełnym przekierowaniu: stop CH1 w ciągu 30 dni, potem delete w ciągu 30 dni. Dopóki CH1 istnieje (nawet stopped), możesz wrócić przez restart + % traffic. Po delete migracja jest complete: nie utworzysz ponownie aplikacji CloudHub 1.0 o tej samej nazwie. Analogicznie po delete DLB nie ma rollbacku failoveru.

8. Dlaczego Anypoint MQ / Object Store v2 może nie działać mimo poprawnego kodu (egress)?

Bo egress na CH2 jest kontrolowany. Usunięcie domyślnego allow-all albo włączenie app-level egress bez reguł do anypoint.mulesoft.com i regionalnych hostów MQ/OSv2 blokuje połączenia — aplikacja wstaje, ale wywołania platformowe padają. Skonfiguruj reguły i przetestuj przed rampą ruchu.

9. Czy potrzebuję Runtime Cluster Mode przy schedulerze na wielu replikach?

Tak, jeśli scheduler jest źródłem i masz ≥2 repliki. Bez cluster mode każdy kontener odpala scheduler → duplikaty przetwarzania. Cluster mode wymaga minimum dwóch replik; primary node odpala scheduler, pozostałe konsumują z brokera. Przy cluster mode + OSv2 jednocześnie świadomie zarządzaj metered usage OSv2.

10. Czy Runtime Fabric to to samo co CloudHub 2.0?

Nie. CloudHub 2.0 to managed container platform MuleSoft (Shared/Private Spaces). Runtime Fabric to inny model wdrożenia (customer-managed / self-managed Kubernetes control). Wybór RTF vs CH2 to osobna decyzja architektoniczna — nie jest przedmiotem tego cutoveru CH1→CH2.

Soft CTA

Planujesz cutover CloudHub 2.0 i chcesz przejrzeć inventory kolejek, egress i plan %-owego ruchu z kimś, kto robi to na co dzień? Solita to nordycki partner MuleSoft z dostawą z Polski (EU-shoring) — możemy pomóc ułożyć runbook migracji bez lift-and-shift na ślepo. Bez obietnic „#1” i bez checklisty marketingowej: konkretny przegląd pułapek przed dniem D.

Źródła

Dokumentacja oficjalna

Oficjalne blogi MuleSoft

How-to wideo (zweryfikowane tytuły / oEmbed)