Notes de publication App Service sur Azure Stack Hub 2020 T3

Ces notes de publication décrivent les améliorations et les correctifs apportés à Azure App Service sur Azure Stack Hub 2020 T3, ainsi que les problèmes connus. Les problèmes connus ont été répartis selon qu’ils concernent le déploiement, le processus de mise à jour ou la build (après l’installation).

Important

Mettez à jour Azure Stack Hub vers une version prise en charge (ou déployez le dernier Kit de développement Azure Stack), si nécessaire, avant de déployer ou de mettre à jour le fournisseur de ressources App Service (RP). Veillez à lire les notes de publication basées sur les revendications afin de découvrir les nouvelles fonctionnalités, les correctifs et les problèmes connus susceptibles d’affecter votre déploiement.

Version minimale d’Azure Stack Hub prise en charge Version basée sur les revendications de App Service
2301 et versions ultérieures 2302 Installer (notes de publication)

Référence de build

Le numéro de build d’App Service sur Azure Stack Hub 2020 T3 est 89.0.2.15

Prérequis

Avant de passer au déploiement, consultez la documentation Avant de commencer.

Avant de commencer à mettre à niveau Azure App Service sur Azure Stack vers la version 2020 T3 :

  • Vérifiez que tous les rôles sont prêts dans l’Administration Azure App Service sur le portail d’administration Azure Stack Hub.

  • Sauvegardez les secrets App Service à l'aide de l'Administration Azure App Service sur le portail d’administration Azure Stack Hub.

  • sauvegardez App Service et les bases de données master :

    • AppService_Hosting
    • AppService_Metering
    • Master
  • Sauvegardez le partage de fichier de contenu d’application locataire ;

    Important

    Les opérateurs cloud sont responsables de la maintenance et du fonctionnement du serveur de fichiers et de SQL Server. Le fournisseur de ressources ne gère pas ces ressources. L'opérateur cloud est responsable de la sauvegarde des bases de données App Service et du partage des fichiers de contenu des locataires.

  • Syndiquez l’extension de script personnalisé version 1.9.3 à partir de la Place de marché Azure

Mises à jour

La mise à jour T3 d’Azure App Service sur Azure Stack contient les améliorations et correctifs suivants :

  • Mises à jour des portails Locataire, Administration et Functions d’App Service, ainsi que des outils Kudu. Cohérentes avec celles de la version du SDK du portail Azure Stack.

  • Ajout de l’expérience de création plein écran pour les applications web et de fonction

  • Nouvelle expérience du portail Azure Functions qui est à présent cohérente avec Web Apps

  • Mise à jour du runtime Azure Functions vers la version 1.0.13154.

  • Mises à jour du service principal afin d’améliorer la fiabilité et l’envoi de messages d’erreur, ce qui facilite le diagnostic des problèmes courants.

  • Mises à jour des outils et frameworks d’applications suivants :

    • ASP.NET Core 2.1.22
    • ASP.NET Core 2.2.14
    • ASP.NET Core 3.1.8
    • Module ASP.NET Core v2 13.1.19331.0
    • Azul OpenJDK
      • 8.42.0.23
      • 8.44.0.11
      • 11.35.15
      • 11.37.17
    • Curl 7.55.1
    • Git pour Windows 2.28.0.1
    • MSDeploy 3.5.90702.36
    • NodeJS
      • 14.10.1
    • NPM
      • 6.14.8
    • PHP 7.4.5
    • Tomcat
      • 8.5.47
      • 8.5.51
      • 9.0.273
      • 9.0.31
    • Kudu mis à jour vers la version 90.21005.4823
  • Mises à jour du système d’exploitation sous-jacent pour tous les rôles :

  • Les mises à jour cumulatives pour Windows Server sont désormais appliquées aux rôles de contrôleur dans le cadre du déploiement et de la mise à niveau

Problèmes résolus dans cette version

  • Les locataires peuvent à présent créer un plan App Service à l’aide du nouvel affichage Plan App Service dans le portail des locataires

  • Les locataires peuvent gérer des certificats pour leurs applications dans le portail des locataires

  • La surveillance des fonctions peut à présent récupérer des données à partir de points de terminaison de stockage appliquant TLS 1.2

  • Déplacement de l’étape d’attente Serveurs d’administration en dehors de l’étape de déploiement cloud pendant l’installation pour améliorer la fiabilité du déploiement et de la mise à niveau

  • Problème lié au fait que les workers ne parviennent pas à effectuer l’exercice de contrôle d’intégrité, car la taille du dossier de fichier journal du runtime du worker ne respecte pas la limite de quota en cas d’erreur dans la logique de nettoyage. Le problème lié à la logique de nettoyage a été résolu dans cette mise à jour.

Étapes préalables à la mise à jour

Passez en revue les problèmes connus de la mise à jour et prenez les mesures requises.

Étapes de post-déploiement

Important

Si vous avez indiqué le fournisseur de ressources App Service avec une instance SQL Always On, vous DEVEZ ajouter les bases de données appservice_hosting et appservice_metering à un groupe de disponibilité et synchroniser les bases de données pour éviter toute perte de service en cas de basculement d’une base de données.

Problèmes connus (mise à jour)

  • Dans les situations où un client a converti les bases de données appservice_hosting et appservice_metering en bases de données autonomes, la mise à niveau peut échouer si les connexions n’ont pas été correctement migrées vers les utilisateurs autonomes.

Les clients qui ont converti les bases de données appservice_hosting et appservice_metering en bases de données autonomes après le déploiement et n'ont pas correctement migré les connexions des bases de données vers les utilisateurs autonomes peuvent se heurter à des échecs de mise à niveau.

Les clients doivent exécuter le script suivant sur l’instance SQL Server hébergeant appservice_hosting et appservice_metering avant de mettre à niveau l’installation Azure App Service sur Azure Stack Hub vers 2020 T3. Ce script est non destructeur et n’entraîne pas de temps d’arrêt.

Ce script doit être exécuté dans les conditions suivantes

  • Par un utilisateur disposant des privilèges d’administrateur système, par exemple le compte d'administrateur système (SA) SQL ;

  • Si vous utilisez SQL Always On, assurez-vous que le script est exécuté à partir de l’instance SQL contenant toutes les connexions App Service sous la forme :

    • appservice_hosting_FileServer
    • appservice_hosting_HostingAdmin
    • appservice_hosting_LoadBalancer
    • appservice_hosting_Operations
    • appservice_hosting_Publisher
    • appservice_hosting_SecurePublisher
    • appservice_hosting_WebWorkerManager
    • appservice_metering_Common
    • appservice_metering_Operations
    • Toutes les connexions WebWorker, qui se présentent sous la forme WebWorker_<adresse IP de l’instance>
        USE appservice_hosting
        IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1)
        BEGIN
        DECLARE @username sysname ;  
        DECLARE user_cursor CURSOR  
        FOR
            SELECT dp.name
            FROM sys.database_principals AS dp  
            JOIN sys.server_principals AS sp
                ON dp.sid = sp.sid  
                WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA');
            OPEN user_cursor  
            FETCH NEXT FROM user_cursor INTO @username  
                WHILE @@FETCH_STATUS = 0  
                BEGIN  
                    EXECUTE sp_migrate_user_to_contained
                    @username = @username,  
                    @rename = N'copy_login_name',  
                    @disablelogin = N'do_not_disable_login';  
                FETCH NEXT FROM user_cursor INTO @username  
            END  
            CLOSE user_cursor ;  
            DEALLOCATE user_cursor ;
            END
        GO

        USE appservice_metering
        IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1)
        BEGIN
        DECLARE @username sysname ;  
        DECLARE user_cursor CURSOR  
        FOR
            SELECT dp.name
            FROM sys.database_principals AS dp  
            JOIN sys.server_principals AS sp
                ON dp.sid = sp.sid  
                WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA');
            OPEN user_cursor  
            FETCH NEXT FROM user_cursor INTO @username  
                WHILE @@FETCH_STATUS = 0  
                BEGIN  
                    EXECUTE sp_migrate_user_to_contained
                    @username = @username,  
                    @rename = N'copy_login_name',  
                    @disablelogin = N'do_not_disable_login';  
                FETCH NEXT FROM user_cursor INTO @username  
            END  
            CLOSE user_cursor ;  
            DEALLOCATE user_cursor ;
            END
        GO

Problèmes connus (après l’installation)

  • Les rôles de travail ne peuvent pas atteindre le serveur de fichiers si App Service est déployé dans un réseau virtuel existant et si le serveur de fichiers est uniquement disponible sur le réseau privé, comme indiqué dans la documentation de déploiement d’Azure App Service sur Azure Stack.

    Si vous avez choisi de procéder au déploiement dans un réseau virtuel existant et une adresse IP interne pour vous connecter à votre serveur de fichiers, vous devez ajouter une règle de sécurité sortante, qui autorise le trafic SMB entre le sous-réseau Worker et le serveur de fichiers. Accédez au WorkersNsg dans le portail d’administration, puis ajoutez une règle de sécurité sortante comportant les propriétés suivantes :

    • Source : Quelconque
    • Plage de ports source : : *
    • Destination : Adresses IP
    • Plage d’adresses IP de destination : plage d’adresses IP de votre serveur de fichiers
    • Plage de ports de destination : 445
    • Protocole : TCP
    • Action : Allow
    • Priorité : 700
    • Nom : Outbound_Allow_SMB445
  • Pour supprimer la latence pendant la communication des Workers avec le serveur de fichiers, nous vous recommandons également d’ajouter la règle suivante au NSG du Worker pour autoriser le trafic LDAP et Kerberos sortant vers vos contrôleurs Active Directory si vous sécurisez le serveur de fichiers en utilisant Active Directory, par exemple, si vous avez utilisé le modèle de démarrage rapide pour déployer un serveur de fichiers HA et SQL Server.

    Accédez au WorkersNsg dans le portail d’administration, puis ajoutez une règle de sécurité sortante comportant les propriétés suivantes :

    • Source : Quelconque
    • Plage de ports source : : *
    • Destination : Adresses IP
    • Plage d’adresses IP de destination : plage des IP de vos serveurs AD, par exemple, avec le modèle de démarrage rapide 10.0.0.100, 10.0.0.101
    • Plage des ports de destination : 389,88
    • Protocole : Tous
    • Action : Allow
    • Priorité : 710
    • Nom : Outbound_Allow_LDAP_and_Kerberos_to_Domain_Controllers

Problèmes connus des administrateurs cloud utilisant Azure App Service sur Azure Stack

  • Les domaines personnalisés ne sont pas pris en charge dans les environnements déconnectés

App Service effectue une vérification de la propriété du domaine sur les points de terminaison DNS publics, car les domaines personnalisés ne sont pas pris en charge dans les scénarios déconnectés.

Étapes suivantes