Sdílet prostřednictvím

Změny po migraci

  • Článek

Nasazení Cloud Services (Classic) se převede na nasazení Cloud Services (rozšířená podpora). Další informace najdete v dokumentaci ke cloudovým službám (rozšířená podpora).

Změny souborů nasazení

V souboru .csdef a .cscfg zákazníka se provádějí menší změny, aby soubory nasazení odpovídaly požadavkům Azure Resource Manageru a cloudových služeb (rozšířená podpora). Po migraci se načtou nové soubory nasazení nebo se aktualizují existující soubory, které jsou potřeba pro operace aktualizace nebo odstranění.

  • Virtuální síť používá úplné ID prostředku Azure Resource Manageru místo názvu prostředku v části NetworkConfiguration souboru .cscfg. Například /subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name. U virtuálních sítí patřících do stejné skupiny prostředků jako cloudová služba můžete soubor .cscfg aktualizovat zpět tak, aby používal pouze název virtuální sítě.

  • Klasické velikosti, jako je Small, Large, ExtraLarge, se nahrazují novými názvy velikostí Standard_A*. Názvy velikostí je potřeba změnit na nové názvy v souboru .csdef. Další informace najdete v požadavcích nasazení cloudových služeb (rozšířená podpora).

  • Pomocí rozhraní Get API získáte nejnovější kopii souborů nasazení.

Aktualizace konfigurace Azure Traffic Manageru po migraci cloudových služeb

Po migraci cloudových služeb (Classic) do cloudových služeb (rozšířená podpora) může dojít k problémům s aktualizací nebo odstraněním konfigurací koncových bodů v Azure Traffic Manageru. Důvodem jsou problémy se synchronizací ID prostředku, kdy koncový bod Traffic Manageru stále odkazuje na staré ID prostředku pro cloudové služby (classic), ale nasazení Cloud Services (rozšířená podpora) má nové ID prostředku. Pokud chcete tento problém vyřešit, postupujte následovně:

  1. Migrace dočasného koncového bodu provozu: Migrace provozu Azure Traffic Manageru do sekundárního koncového bodu
  2. Odebrání klasických koncových bodů výpočetních prostředků v Azure Traffic Manageru: Jakmile se provoz směruje do dočasného koncového bodu, odstraňte klasický výpočetní koncový bod z profilu Traffic Manageru.
  3. Migrace do cloudových služeb (rozšířená podpora): Migrace prostředku cloudové služby do cloudových služeb (rozšířená podpora)
  4. Přidání nových koncových bodů v ATM: Vytvořte nové koncové body v profilu Traffic Manageru pro migrovaný prostředek cloudových služeb (rozšířená podpora). Tento koncový bod má nové ID prostředku pro migrovanou cloudovou službu.
  5. Obnovení provozu do koncového bodu primární cloudové služby (rozšířená podpora): Sekundární koncový bod je možné odstranit nebo upravit na nižší váhu. Provoz se bude obsluhovat do nového (rozšířeného podpůrného) prostředku. Tento proces zajišťuje, že traffic Manager je správně v souladu s aktualizovanými ID prostředků a zabrání problémům s konfigurací, které můžou zpozdit projekty.

Změny automatizace, kanálu CI/CD zákazníka, vlastních skriptů, vlastních řídicích panelů, vlastních nástrojů atd.

Zákazníci potřebují aktualizovat své nástroje a automatizaci, aby mohli začít používat nová rozhraní API nebo příkazy ke správě nasazení. Zákazník může v rámci této změny snadno přijmout nové funkce a možnosti Azure Resource Manageru nebo cloudových služeb (rozšířená podpora).

  • Změny názvů prostředků a skupin prostředků po migraci

  • Opětovné vytvoření pravidel a zásad potřebných ke správě a škálování cloudových služeb

    • Pravidla automatického škálování se nemigrují. Po migraci znovu vytvořte pravidla automatického škálování.
    • Upozornění se nemigrují. Po migraci znovu vytvořte výstrahy.
    • Služba Key Vault se vytvoří bez jakýchkoli zásad přístupu. Pokud chcete zobrazit nebo spravovat certifikáty, vytvořte ve službě Key Vault odpovídající zásady . Certifikáty jsou viditelné v nastavení na kartě s názvem tajné kódy.

Změny správy certifikátů po migraci

Standardním postupem při správě certifikátů by měly být všechny platné soubory certifikátů .pfx přidány do úložiště certifikátů ve službě Key Vault a aktualizace by fungovaly dokonale v pořádku prostřednictvím libovolného klienta – portálu, PowerShellu nebo rozhraní REST API.

Azure Portal v současné době provádí ověření, jestli se všechny požadované certifikáty nahrají do úložiště certifikátů ve službě Key Vault a zobrazí upozornění, pokud se certifikát nenajde. Pokud ale plánujete používat certifikáty jako tajné kódy, tyto certifikáty se nedají ověřit pro kryptografický otisk a všechny operace aktualizace, které zahrnují přidání tajných kódů, selžou prostřednictvím portálu. Zákazníkům se doporučuje používat PowerShell nebo RestAPI, aby mohli pokračovat v aktualizacích tajných kódů.

Změny pro aktualizaci prostřednictvím sady Visual Studio

Pokud jste aktualizace publikovali přímo přes Visual Studio, budete si muset nejprve stáhnout nejnovější soubor CSCFG z nasazení po migraci. Tento soubor použijte jako odkaz na přidání podrobností o konfiguraci sítě do aktuálního souboru CSCFG v projektu sady Visual Studio. Pak sestavte řešení a publikujte ho. Pro tuto aktualizaci možná budete muset zvolit službu Key Vault a skupinu prostředků.

Další kroky