Delen via


Wijzigingen na de migratie

De cloudservicesimplementatie (klassiek) wordt geconverteerd naar een cloudservicesimplementatie (uitgebreide ondersteuning). Zie de documentatie voor Cloud Services (uitgebreide ondersteuning) voor meer informatie.

Wijzigingen in implementatiebestanden

Kleine wijzigingen worden aangebracht in het .csdef- en CSCFG-bestand van de klant om ervoor te zorgen dat de implementatiebestanden voldoen aan de vereisten voor Azure Resource Manager en Cloud Services (uitgebreide ondersteuning). Na de migratie worden uw nieuwe implementatiebestanden opgehaald of worden de bestaande bestanden bijgewerkt, die nodig zijn voor update-/verwijderbewerkingen.

  • Virtual Network maakt gebruik van de volledige Azure Resource Manager-resource-id in plaats van alleen de resourcenaam in de sectie NetworkConfiguration van het CSCFG-bestand. Bijvoorbeeld: /subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name. Voor virtuele netwerken die behoren tot dezelfde resourcegroep als de cloudservice, kunt u ervoor kiezen om het CSCFG-bestand weer bij te werken met alleen de naam van het virtuele netwerk.

  • Klassieke grootten zoals Small, Large, ExtraLarge worden vervangen door hun nieuwe groottenamen, Standard_A*. De groottenamen moeten worden gewijzigd in de nieuwe namen in het .csdef-bestand. Zie Vereisten voor cloudservices (uitgebreide ondersteuning) voor meer informatie

  • Gebruik de Get-API om de meest recente kopie van de implementatiebestanden op te halen.

Azure Traffic Manager-configuratie bijwerken na migratie van de cloudservice

Nadat u uw Cloud Services (klassiek) naar Cloud Services (uitgebreide ondersteuning) hebt gemigreerd, kunnen er problemen optreden met het bijwerken of verwijderen van eindpuntconfiguraties in Azure Traffic Manager. Dit komt door synchronisatieproblemen met resource-id's, waarbij het Traffic Manager-eindpunt nog steeds verwijst naar de oude resource-id voor Cloud Services (klassiek), maar de implementatie van Cloud Services (uitgebreide ondersteuning) een nieuwe resource-id heeft. Volg deze stappen om dit probleem op te lossen:

  1. Tijdelijk eindpunt voor verkeer migreren: Migreer uw Azure Traffic Manager-verkeer naar een secundair eindpunt.
  2. Klassieke rekeneindpunten verwijderen in Azure Traffic Manager: nadat het verkeer naar een tijdelijk eindpunt wordt omgeleid, verwijdert u het klassieke rekeneindpunt uit het Traffic Manager-profiel.
  3. Migreren naar Cloud Services (uitgebreide ondersteuning): Migreer de cloudserviceresource naar Cloud Services (uitgebreide ondersteuning).
  4. Nieuwe eindpunten toevoegen in ATM: Maak nieuwe eindpunten in uw Traffic Manager-profiel voor de gemigreerde Cloud Services-resource (uitgebreide ondersteuning). Dit eindpunt heeft de nieuwe resource-id voor de gemigreerde cloudservice.
  5. Verkeer hervatten naar het eindpunt primaire cloudservices (uitgebreide ondersteuning): het secundaire eindpunt kan worden verwijderd of aangepast aan een lager gewicht. Verkeer wordt geleverd aan nieuwe (uitgebreide ondersteunings) resource. Dit proces zorgt ervoor dat uw Traffic Manager correct is afgestemd op de bijgewerkte resource-id's en voorkomt configuratieproblemen die projecten kunnen vertragen.

Wijzigingen in de Automatisering, CI/CD-pijplijn van de klant, aangepaste scripts, aangepaste dashboards, aangepaste hulpprogramma's, enzovoort.

Klanten moeten hun hulpprogramma's en automatisering bijwerken om de nieuwe API's/opdrachten te kunnen gebruiken om hun implementatie te beheren. De klant kan eenvoudig nieuwe functies en mogelijkheden van Azure Resource Manager/Cloud Services (uitgebreide ondersteuning) gebruiken als onderdeel van deze wijziging.

  • Wijzigingen in resource- en resourcegroepnamen na migratie

  • Regels en beleidsregels maken die zijn vereist voor het beheren en schalen van cloudservices

    • Regels voor automatisch schalen worden niet gemigreerd. Maak na de migratie de regels voor automatisch schalen opnieuw.
    • Waarschuwingen worden niet gemigreerd. Maak na de migratie de waarschuwingen opnieuw.
    • De Sleutelkluis wordt gemaakt zonder toegangsbeleid. Als u uw certificaten wilt weergeven of beheren, maakt u het juiste beleid voor de Key Vault. Certificaten zijn zichtbaar onder instellingen op het tabblad geheimen.

Wijzigingen in certificaatbeheer na migratie

Als standaardpraktijk voor het beheren van uw certificaten, moeten alle geldige PFX-certificaatbestanden worden toegevoegd aan het certificaatarchief in Key Vault en werkt de update perfect via elke client - Portal, PowerShell of REST API.

Op dit moment wordt in Azure Portal een validatie uitgevoerd om te controleren of alle vereiste certificaten worden geĆ¼pload in het certificaatarchief in Key Vault en wordt gewaarschuwd als er geen certificaat wordt gevonden. Als u echter van plan bent certificaten als geheimen te gebruiken, kunnen deze certificaten niet worden gevalideerd voor hun vingerafdruk en eventuele updatebewerkingen waarbij geheimen worden toegevoegd, mislukken via de portal. Klanten worden aangeraden PowerShell of RestAPI te gebruiken om door te gaan met updates met betrekking tot geheimen.

Wijzigingen voor update via Visual Studio

Als u updates rechtstreeks via Visual Studio hebt gepubliceerd, moet u eerst het meest recente CSCFG-bestand downloaden vanuit uw implementatie na de migratie. Gebruik dit bestand als verwijzing om netwerkconfiguratiegegevens toe te voegen aan uw huidige CSCFG-bestand in het Visual Studio-project. Bouw vervolgens de oplossing en publiceer deze. Mogelijk moet u de sleutelkluis en de resourcegroep voor deze update kiezen.

Volgende stappen