@danielstocker Merci beaucoup d'avoir porté cela à notre attention. J'ai attribué cela au responsable du service pour qu'il fasse l'objet d'une enquête plus approfondie et je ferai une mise à jour lorsque nous aurons plus de clarté.

@Mike-Ubezzi-MSFT @mike-urnun-msft

Merci d'avoir examiné cela.

Avez-vous besoin de plus d'informations pour faire avancer cela?

@danielstocker pouvez-vous fournir plus d'informations sur votre problème d'origine qui a conduit à cette découverte ? Je ne suis pas sûr de bien comprendre l'implication de le définir de manière incorrecte (ce que vous avez mentionné comme unintentional swap )

Salut @ggirard07 ,

Aucun problème. Permettez-moi de résumer.
Cela s'est produit initialement parce que notre documentation indique que WEBSITE_CONTENTSHARE est requis. (voir ici : https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

Si nous exportons un modèle de fonctions depuis la place de marché (modèle d'exportation sur la dernière page), nous obtenons WEBSITE_CONTENTSHARE comme paramètre d'application standard. Si nous l'utilisons, la situation suivante peut se produire.

1) Nous déployons un template ARM et obtenons une fonction vide avec deux slots
2) Nous déployons sur le créneau de mise en scène
3) On échange pour rendre le contenu disponible en production
4) SWAP NON INTENTIONNEL car le modèle ARM est redéployé et les paramètres de l'application sont réappliqués (cela se produit même lors d'un déploiement ARM incrémentiel car la ressource appsettings écrase et réinitialise toujours le paramètre WEBSITE_CONTENTSHARE)
5) La routine de déploiement déploie maintenant le nouveau code dans l'emplacement intermédiaire et notre emplacement de production est vide au lieu de contenir la version précédente. Notre fonction de production est "involontairement" en panne

Le client dans ce cas particulier a alors indiqué cet article https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

Cela suggère que le paramètre doit être défini comme un paramètre d'emplacement pour corriger le comportement. Bien que cela corrige le comportement dans mes tests, cela semble faux, car cela ne devrait pas fonctionner.

Vous trouverez ci-dessous un tableau de ce qui s'est passé lors de mes tests. (après en avoir fait un paramètre de slot)

Ma perception (et celle du client) est que les slots ne devraient plus du tout échanger, mais comme décrit dans l'article, cela fonctionne quand même.

J'ai également soulevé cette question en interne et les gens ont trouvé un comportement incohérent lors de la modification des paramètres de l'application. (C'est pourquoi cela est mis en évidence dans ma grille de test) Pour un collègue qui l'a testé, la mise à jour des paramètres de l'application a réappliqué les paramètres de l'emplacement, provoquant ainsi à nouveau un échange involontaire.

Ceci puis finalement (désolé pour la longue réponse) m'a amené à soulever le cas de support où le résultat était "ne définissez tout simplement pas le réglage du tout".
Mes tests personnels ont montré que cela résout le problème, mais il n'y a aucune indication dans la documentation pour le confirmer, d'où la raison pour laquelle j'ai soulevé cet élément.

J'espère que cela t'aides.
Faites-moi savoir si quelque chose n'est pas clair.

@danielstocker est définitivement une information importante, en particulier pour comprendre comment fonctionnent les emplacements et l'échange pour les fonctions par rapport à une application Web traditionnelle avec des tâches Web.
De plus, cela n'est pas expliqué non plus dans la documentation des machines à sous, bien que 'WEBSITE_CONTENTSHARE' joue un rôle critique ici. Il n'y a qu'une seule capture d'écran à l'étape 4 qui la représente, où ces valeurs sont tronquées pour rendre les choses encore plus claires...

Salut @ggirard07 et merci d'avoir lu ma diatribe. Alors, quelle est la voie à suivre à partir d'ici ? :)

@ggirard07 @ggailey777 @mike-urnun-msft

Est-ce que plus d'informations sont nécessaires pour créer une certaine clarté de la documentation autour de ce comportement ? Je travaille avec un client qui envisage d'arrêter d'utiliser des emplacements de fonction car il n'est pas sûr des directives officielles concernant ce scénario.

Merci pour ton aide

@danielstocker Juste pour que je sois clair sur ce que vous pensez résoudre les problèmes de documentation liés à cela:

• Supprimez le paramètre de déploiement WEBSITE_CONTENTSHARE d' ici .
• Ajoutez une note dans l'article de référence que WEBSITE_CONTENTSHARE ne doit être défini que par le runtime.

Pensez-vous que ce serait suffisant ?

cc. @matchenderson

Salut @ggailey777
oui je pense que ce serait une bonne solution

WEBSITE_CONTENTSHARE n'est-il pas l'un des paramètres d'application requis lors du déploiement d'une application de fonction à l'aide d'ARM ?

WEBSITE_CONTENTSHARE n'est-il pas l'un des paramètres d'application requis lors du déploiement d'une application de fonction à l'aide d'ARM ?

S'il n'est pas appliqué, le runtime en générera un pour vous, je pense.

J'ai déployé un ARM avec un plan de consommation et une application de fonction avec une section _Microsoft.Web/sites/config_ nommée appsettings et les propriétés suivantes

• FUNCTIONS_EXTENSION_VERSION : "~2",
• FUNCTIONS_WORKER_RUNTIME : "dotnet",
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [
• WEBSITE_NODE_DEFAULT_VERSION : 6.5.0

Le déploiement a renvoyé l'erreur suivante :

      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

Après avoir _également_ supprimé le paramètre WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, le déploiement s'est déroulé sans erreur. Donc, il semble y avoir une relation requise entre ces deux paramètres.
Bien que réussi, ce déploiement m'a fait errer si et où les fonctions (packages) sont physiquement déployées (et si ce cas est valable en premier lieu).

Nous avons vu le comportement exact décrit par @tjgalama et nous nous

Nos applications de fonction incluent également une fonction déclenchée par une minuterie, nous spécifions donc le paramètre AzureWebJobsStorage comme suggéré : nous aurions deviné/espéré que le runtime aurait utilisé la même chaîne de connexion pour le WEBSITE_CONTENTAZUREFILECONNECTIONSTRING (maintenant implicite) azure-webjobs-hosts et azure-webjobs-secrets , mais aucun partage de fichiers n'est présent.

J'ai vérifié dans Kudu des indices et il semble que tous les fichiers qui doivent être là soient dans le système de fichiers (où que ce soit, vérifié sur app-name.scm.azurewebsites.net/api/vfs/ ), mais aucune référence à aucun des paramètres ( WEBSITE_CONTENTSHARE ou WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ) est à voir dans l'onglet environnement ( appname.scm.azurewebsites.net/Env.cshtml ).

Peut-être important de mentionner, nos applications sont configurées avec WEBSITE_ENABLE_SYNC_UPDATE_SITE=True et WEBSITE_RUN_FROM_PACKAGE=1 .
Les applications semblent fonctionner, mais nous aimerions vraiment avoir des éclaircissements sur ce point, car nous portons un service métier de base vers Azure Functions et voulons comprendre celui-ci avant de le déployer en production.

Suite à quelques conseils, nous avions défini WEBSITE_CONTENTSHARE comme paramètre d'emplacement pour nous assurer que les valeurs étaient distinctes entre nos emplacements de production et de mise en scène. Aujourd'hui, le modèle ARM que nous utilisons a commencé à échouer avec 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (même si j'ai confirmé qu'il est bien défini comme paramètre d'emplacement dans le portail actuellement). Est-ce que quelque chose autour de ce comportement a changé ?

Nous avons remarqué ce même problème au cours des derniers jours et avons besoin de conseils sur la façon de procéder. Nous avons également suivi l'approche consistant à définir le WEBSITE_CONTENTSHARE en tant que paramètre d'emplacement pour contourner le problème de swap involontaire, mais nous ne pouvons désormais pas déployer en raison de cette erreur. J'ai essayé de supprimer rétroactivement ces paramètres et les paramètres WEBSITE_CONTENTAZUREFILECONNECTIONSTRING pour évoluer vers ce qui semble être l'approche recommandée consistant à ne pas utiliser l'un ou l'autre, mais ces déploiements échoueraient également.

Suite à quelques conseils, nous avions défini WEBSITE_CONTENTSHARE comme paramètre d'emplacement pour nous assurer que les valeurs étaient distinctes entre nos emplacements de production et de mise en scène. Aujourd'hui, le modèle ARM que nous utilisons a commencé à échouer avec 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (même si j'ai confirmé qu'il est bien défini comme paramètre d'emplacement dans le portail actuellement). Est-ce que quelque chose autour de ce comportement a changé ?

Supprimez-le et laissez le moteur d'exécution choisir un nom. C'est comme ça que je fais.

@jeffhollan pouvez-vous nous donner un peu de clarté s'il vous plaît

Cela dit que WEBSITE_CONTENTSHARE et WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sont _requis_ : https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

Les commentateurs pensent qu'ils ne sont _pas_ requis ; ARM pense qu'ils sont nécessaires ? ; Le support Azure pense que WEBSITE_CONTENTSHARE casse les scénarios d'emplacement.

Nous avons fini par vérifier le code de l'hôte des fonctions Azure et il semble que , lors de l'exécution à partir du package, le paramètre WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ne soit
Nous l'avons vérifié en supprimant de notre modèle ARM à la fois WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE et en obtenant de bons résultats : nos applications de fonction n'ont pas du tout ces deux paramètres (même pas assignés par le runtime) et ils n'utilisez pas de partage de fichiers dans aucun compte de stockage (du moins que nous pouvons voir).

Donc, une chose à garder à l'esprit est que le système de fichiers d'une application Web/application de fonction ressemble à ceci :

|-data
|-LogFiles
|-site
  |-deployments
  |-tools
  |-wwwroot

Lorsque vous utilisez run from package, cela ne remplace que le dossier wwwroot dans cette arborescence. Tout le reste est fourni par le système de fichiers principal. Si vous créez une application de fonction premium de consommation ou élastique sans WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, le système de fichiers principal n'est pas disponible en dehors de l'unité d'échelle dans laquelle l'application de fonction a été créée. Il ne s'agit pas d'une configuration prise en charge/recommandée. Cela signifie que votre application de fonction ne peut pas évoluer au-delà des limites de l'unité d'échelle dans laquelle elle a été créée, ou si c'est le cas, vous ne pourrez pas être sûr que l'état du système de fichiers en dehors de wwwroot reste cohérent.

Les conseils les plus récents que j'ai vus du développeur qui gère la façon dont WEBSITE_CONTENTSHARE interagit avec les emplacements sont les suivants :

• WEBSITE_CONTENTSHARE ne doit PAS être un paramètre d'emplacement. Un changement d'API qui bloque cela est en cours de déploiement au moment de la rédaction.
• Lors de la création initiale de la ressource via ARM, WEBSITE_CONTENTSHARE doit être défini. Cependant, après la création initiale, ce paramètre doit être omis du modèle ARM (car s'il était inclus, d'autres exécutions du modèle ARM pourraient provoquer des échanges de contenu inattendus)

Suite à mon commentaire ci-dessus.. J'ai également découvert que le système a actuellement un comportement incohérent concernant la génération de WEBSITE_CONTENTSHARE de sorte que vous n'avez même pas besoin de le spécifier au départ. Certains d'entre vous ont dit que vous n'aviez pas besoin de le spécifier, tandis que d'autres reçoivent une erreur indiquant que c'est requis. Pour autant que je sache, ce comportement fonctionne correctement pour la consommation (c'est-à-dire qu'un modèle ARM pour la consommation n'a pas besoin de ce paramètre au départ) mais il n'en va pas de même pour la prime élastique. Ce comportement est en train d'être corrigé, mais il faudra probablement 1 à 2 mois pour s'en sortir. En attendant, les conseils que j'ai partagés ci-dessus (où vous les définissez initialement, puis les supprimez du modèle ARM) sont applicables.

@paulbatum

• Lors de la création initiale de la ressource via ARM, WEBSITE_CONTENTSHARE doit être défini. Cependant, après la création initiale, ce paramètre doit être omis du modèle ARM (car s'il était inclus, d'autres exécutions du modèle ARM pourraient provoquer des échanges de contenu inattendus)

Vous réalisez que ce genre de brise le but d'un modèle ARM, n'est-ce pas ?

Ce comportement est en train d'être corrigé, mais il faudra probablement 1 à 2 mois pour s'en sortir. En attendant, les conseils que j'ai partagés ci-dessus (où vous les définissez initialement, puis les supprimez du modèle ARM) sont applicables.

Quelle est la configuration finale attendue ici ?
Pouvons-nous obtenir une annonce sur Azure/app-service-annonciations avec une configuration appropriée et un calendrier officiel une fois que tout cela est réellement déployé ?

Bonjour, je ne sais pas s'il y a eu des développements à ce sujet. J'ai toujours du mal à utiliser les modèles ARM avec l'indicateur WEBSITE_CONTENTSHARE. @paulbatum comment puis-je omettre une configuration du modèle ARM ? J'ai dû désactiver complètement l'étape pour qu'elle fonctionne.

@gustavobmichel Désolé, je ne comprends pas votre question. Le modèle ARM est JSON, vous le modifiez selon vos besoins. Il apparaît dans la section appsettings, par exemple :

          "appSettings": [
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },

Salut @paulbatum , merci d'être revenu vers moi. Je pensais que vous aviez mentionné l'omission par programmation des paramètres du modèle JSON, c'était donc ma question.

Comme d'autres l'ont dit, je pensais également que ces deux paramètres étaient nécessaires, j'ai donc supprimé les deux de mon modèle ARM.

Pour tester cette fonctionnalité sans aucun temps d'arrêt, j'ai créé un test simple avec l'infrastructure minimale nue pour la tester. J'ai supprimé toutes les ressources de mon groupe de ressources et exécuté le modèle ARM dans le cadre du pipeline de publication pour créer les ressources sans WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE et WEBSITE_RUN_FROM_PACKAGE.

J'ai effectué quelques tests et tout fonctionne toujours bien avec le plan de consommation. Je vais faire quelques tests cette semaine avec le niveau premium.

J'ai également ajouté cette configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG à 1 selon ce lien : https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

J'ai joint mon modèle de test ARM pour référence.
azuredploy.txt

Salut @paulbatum , merci d'être revenu vers moi. Je pensais que vous aviez mentionné l'omission par programmation des paramètres du modèle JSON, c'était donc ma question.

Comme d'autres l'ont dit, je pensais également que ces deux paramètres étaient nécessaires, j'ai donc supprimé les deux de mon modèle ARM.

Pour tester cette fonctionnalité sans aucun temps d'arrêt, j'ai créé un test simple avec l'infrastructure minimale nue pour la tester. J'ai supprimé toutes les ressources de mon groupe de ressources et exécuté le modèle ARM dans le cadre du pipeline de publication pour créer les ressources sans WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE et WEBSITE_RUN_FROM_PACKAGE.

J'ai effectué quelques tests et tout fonctionne toujours bien avec le plan de consommation. Je vais faire quelques tests cette semaine avec le niveau premium.

J'ai également ajouté cette configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG à 1 selon ce lien : https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

J'ai joint mon modèle de test ARM pour référence.
azuredploy.txt

En laissant de côté WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, comment votre fonction sait-elle d'où obtenir le code de l'application ?

Si cela peut aider, nous avons opté pour :

• en définissant WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sur le compte de stockage à partir duquel nous voulons que le code s'exécute
• ne pas spécifier du tout WEBSITE_CONTENTSHARE dans le modèle de bras (autoriser sa génération automatique pour les deux emplacements)
• WEBSITE_RUN_FROM_PACKAGE = 1

J'ai fait beaucoup de tests autour de ceux-ci et cela semblait être la meilleure configuration pour éviter de déclencher des échanges involontaires et de savoir où se trouvait le code, etc. Ne nécessite pas non plus de gérer ces paramètres en dehors du modèle ARM, ce que je n'ai pas aimé l'idée de (on a l'impression qu'il n'y a pas beaucoup d'intérêt à utiliser des modèles ARM à ce stade).

Le déploiement semble également fonctionner sans spécifier de valeur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, mais comme mentionné, nous n'avons pas pu savoir où se trouvait le code et le support technique MS qui gérait mon ticket semblait suggérer qu'il s'agissait d'un bogue et que cela ne devrait pas être autorisé par la plate-forme.

Si cela peut aider, nous avons opté pour :

• en définissant WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sur le compte de stockage à partir duquel nous voulons que le code s'exécute
• ne pas spécifier du tout WEBSITE_CONTENTSHARE dans le modèle de bras (autoriser sa génération automatique pour les deux emplacements)
• WEBSITE_RUN_FROM_PACKAGE = 1

J'ai fait beaucoup de tests autour de ceux-ci et cela semblait être la meilleure configuration pour éviter de déclencher des échanges involontaires et de savoir où se trouvait le code, etc. Ne nécessite pas non plus de gérer ces paramètres en dehors du modèle ARM, ce que je n'ai pas aimé l'idée de (on a l'impression qu'il n'y a pas beaucoup d'intérêt à utiliser des modèles ARM à ce stade).

Le déploiement semble également fonctionner sans spécifier de valeur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, mais comme mentionné, nous n'avons pas pu savoir où se trouvait le code et le support technique MS qui gérait mon ticket semblait suggérer qu'il s'agissait d'un bogue et que cela ne devrait pas être autorisé par la plate-forme.

C'est exactement ce que j'ai découvert aussi. Merci d'avoir confirmé.

Ma fonction rencontre des problèmes pour accéder au stockage après avoir ajouté WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_RUN_FROM_PACKAGE. Avez-vous ajouté ces deux configurations à la fois à l'application et à l'emplacement ?

L'erreur exacte est : Azure Functions Runtime est inaccessible.

C'est après avoir effectué le premier déploiement, puis j'essaie de déployer une nouvelle version.

J'ai également ajouté mon fichier yml.
fichier yml.txt
deploy.txt

J'ai également mis à jour mon modèle ARM.

Ma fonction rencontre des problèmes pour accéder au stockage après avoir ajouté WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_RUN_FROM_PACKAGE. Avez-vous ajouté ces deux configurations à la fois à l'application et à l'emplacement ?

L'erreur exacte est : Azure Functions Runtime est inaccessible.

C'est après avoir effectué le premier déploiement, puis j'essaie de déployer une nouvelle version.

J'ai également ajouté mon fichier yml.
fichier yml.txt
deploy.txt

J'ai également mis à jour mon modèle ARM.

Je l'ai sur les deux. En fait, je n'ai rien dans mon créneau de production et j'échange tout depuis la mise en scène. J'ai vu cela lors de la définition d'un WEBSITE_CONTENTSHARE ou de ne pas pointer vers le bon compte de stockage où le code réside avec WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Vous ne devez rien pointer nulle part avec WEBSITE_CONTENTSHARE. En fait, je pense avoir vu cette erreur à laquelle vous faites référence en raison de l'ajout d'un WEBSITE_CONTENTSHARE aux variables d'environnement. Assurez-vous de ne pas l'avoir défini.

Salut @mslot , je pense que le problème était sur mon déploiement. Je l'ai configuré sur zipDeploy parce que j'ai lu sur ce fil https://stackoverflow.com/a/56205917 à propos de sa configuration sur Azure DevOps. Après l'avoir changé en déploiement standard, tout semble fonctionner. Merci de votre aide.

Ce comportement est en train d'être corrigé, mais il faudra probablement 1 à 2 mois pour s'en sortir.

Une mise à jour sur ce problème? Le comportement Consommation et Premium est-il désormais aligné ? Pouvons-nous omettre WEBSITE_CONTENTSHARE du déploiement ARM initial et des déploiements ultérieurs ? Comment cela affecte-t-il les emplacements de staging ? Des documents mis à jour à lier ou des conseils ?

Nous avons essentiellement opté pour la même approche que @mslot mais juste par le biais d'expérimentations et d'essais et erreurs. Je ne sais toujours pas comment le runtime sait où trouver nos fichiers puisque WEBSITE_CONTENTSHARE n'est pas défini.

Salut. Je ne sais pas comment vous pouvez le faire, mais il semble que je ne puisse pas déployer avec
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sans WEBSITE_CONTENTSHARE. Même via le portail, cela m'a donné une erreur en essayant de définir la configuration;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

Sur la page de présentation de l'application de fonction, je vois également ce message d'avertissement : Storage is not configured, Function scaling will be limited. Click to learn more. J'utilise un forfait premium. Des mises à jour ou des directives officielles sur la façon dont devons-nous configurer nos applications de fonction ?

Pour le forfait Premium (pas sûr à 100% du forfait Consommation), voici la matrice de ce qui fonctionne/ne fonctionne pas :

• si vous déployez une nouvelle ressource :
  
  
  
  • si vous ne fournissez aucun paramètre, le déploiement réussit, mais vous obtenez le message Storage is not configured, Function scaling will be limited
  
  
  • si vous ne fournissez que WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , il échoue avec Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • si vous fournissez les deux valeurs, cela fonctionne
  
  
• si vous déployez sur une ressource existante
  
  
  
  • si vous ne fournissez aucun paramètre, le déploiement réussit, mais vous obtenez le message Storage is not configured, Function scaling will be limited
  
  
  • si vous ne fournissez que WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , cela réussit (et semble fonctionner correctement par la suite) même si WEBSITE_CONTENTSHARE est censé être requis
  
  
  • si vous fournissez les deux valeurs, cela "fonctionne" dans la mesure où la partie ARM n'échoue pas, mais cela provoque le problème de redémarrage multiple et les instructions MS ci-dessus consistent à ne pas définir WEBSITE_CONTENTSHARE sur les mises à jour
  
  

Il ne semble donc pas y avoir de moyen d'avoir un seul modèle ARM qui fonctionne pour les deux scénarios pour le moment.

Je vois également ce message d'avertissement : Storage is not configured, Function scaling will be limited. Click to learn more . Havent avait le site Web WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ou WEBSITE_CONTENTSHARE. Tout comme Korkiak le mentionne, une directive mise à jour ou officielle?

Nous avons récemment commencé à voir le message « Le stockage n'est pas configuré, la mise à l'échelle des fonctions sera limitée. Cliquez pour en savoir plus » dans le portail Azure pour les fonctions Azure existantes qui ont été déployées il y a quatre semaines. Nous n'avons jamais utilisé WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ni WEBSITE_CONTENTSHARE et cela a bien fonctionné jusqu'à présent.

@paulbatum Il semble que ce problème

Je viens de constater que le « WEBSITE_CONTENTSHARE » ne peut pas être une erreur de réglage d'emplacement comme mentionné ci-dessus lors du déploiement d'une nouvelle application de fonction pour la première fois depuis plusieurs mois à l'aide d'un modèle qui a bien fonctionné auparavant.
Le modèle a « WEBSITE_CONTENTSHARE » comme paramètre d'emplacement et défini à la fois dans les paramètres de l'application de fonction et de l'emplacement de déploiement conformément à l'article suivant qui a également été mentionné ci-dessus :
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
La lecture de ce fil a supprimé cela en tant que paramètre d'emplacement et a essayé diverses combinaisons de paramètres "WEBSITE_CONTENTSHARE" et je n'obtiens pas le même comportement que les autres. Je peux déployer sans erreur comme ci-dessous :

• Spécifiez « WEBSITE_CONTENTSHARE » pour l'application de fonction et l'emplacement de déploiement
• Spécifiez "WEBSITE_CONTENTSHARE" pour Function App uniquement

Si je ne spécifie pas du tout 'WEBSITE_CONTENTSHARE' dans le modèle, j'obtiens l'erreur "Le paramètre requis WEBSITE_CONTENTSHARE est manquant".

Alors s'il vous plaît, pouvons-nous avoir une mise à jour sur ce que devraient être les paramètres réels car je ne peux pas déployer en production avec ce comportement actuel.

Salut tout le monde, désolé pour toute la confusion ici. Nous essayions d'être intelligents en demandant au portail Azure de vous indiquer quand vous pouvez rencontrer des problèmes de mise à l'échelle avec votre configuration, mais nous avons gaffé la logique et donc maintenant, les gens peuvent voir l'avertissement de manière incorrecte. Nous travaillons sur un correctif, mais en attendant, voici comment vérifier si vous pouvez ou non rencontrer des problèmes de mise à l'échelle avec votre application :

Si vous utilisez une prime ou une consommation élastique, vous devez répondre à l'un des critères suivants :

1. Vous devez avoir défini WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE

ou

1. Si vous utilisez run from zip/package, vous devez avoir défini "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" sur autre chose que vide, 0 ou 1

Nous devrions avoir un correctif pour cela d'ici la semaine prochaine.

Merci @ehamai - pour n ° 2 lorsque vous dites "réglé sur autre chose que vide, 0 ou 1" - est-ce correct ? 0 et 1 ne sont-ils pas opposés ? (Nous avons mis les nôtres à 1 et nous avons supposé que cela voulait dire oui / vrai (ne courent à partir du paquet) comme indiqué ici: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -package-deploiement)

Salut Elliott, merci beaucoup pour la réponse extrêmement rapide.

Alors juste pour préciser :
Lors du déploiement à partir d'un modèle ARM vers le plan de consommation et en utilisant un emplacement de déploiement mais sans zip/package

• Je dois définir à la fois WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE sur les emplacements Production et Staging.

• Je ne devrais PAS définir WEBSITE_CONTENTSHARE comme paramètre d'emplacement de déploiement sur l'un ou l'autre emplacement.

Meilleures salutations

Owain

De : Elliott Hamai [email protected]
Envoyé : 22 juin 2020 17:31
À : MicrosoftDocs/azure-docs [email protected]
Cc : Owain Winterbone (ITCS - Personnel) [email protected] ; Manuel [email protected]
Objet : Re : [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE ne doit pas être utilisé conformément au support (#36458)

Avertissement : Cet e-mail provient de l'extérieur du système UEA. Ne cliquez pas sur les liens ou les pièces jointes à moins que vous ne les attendiez de l'expéditeur et que vous sachiez que le contenu est sûr.

Salut tout le monde, désolé pour toute la confusion ici. Nous essayions d'être intelligents en demandant au portail Azure de vous indiquer quand vous pouvez rencontrer des problèmes de mise à l'échelle avec votre configuration, mais nous avons gaffé la logique et donc maintenant, les gens peuvent voir l'avertissement de manière incorrecte. Nous travaillons sur un correctif, mais en attendant, voici comment vérifier si vous pouvez ou non rencontrer des problèmes de mise à l'échelle avec votre application :

Si vous utilisez une prime ou une consommation élastique, vous devez répondre à l'un des critères suivants :

1. Vous devez avoir défini WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE

ou

1. Si vous utilisez run from zip/package, vous devez avoir défini "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" sur autre chose que vide, 0 ou 1

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284402737046987 & sdata = woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA% 3D et réservé = 0 , ou désabonnement https://eur01.safelinks.protection.outlook.com/?url= https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ & data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284402737056941 & sdata = StHshC6EtV6A% 2BLi3g7x0xfNx56POAYnwjMWihEf% 2BCYM% 3D & réservés = 0 .

@briandunnington - Oui désolé c'est déroutant.

• 0 signifie désactivé
• 1 signifie exécuter à partir d'un zip local, mais pour que cela fonctionne correctement, vous devez également avoir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE définis par la première instruction.

@OwainWin - Désolé, je suis confus par votre question. Vous avez demandé si vous deviez et non inclure WEBSITE_CONTENTSHARE.

Je pense que vous devriez avoir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE définis à la fois sur l'emplacement de production et de mise en scène.

Merci @ehamai -

• si vous déployez une nouvelle ressource :
  
  
  
  • si vous ne fournissez aucun paramètre, le déploiement réussit, mais vous vous retrouvez avec le stockage non configuré, la mise à l'échelle de la fonction sera un message limité
  
  
  • si vous fournissez uniquement WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, il échoue avec le paramètre requis WEBSITE_CONTENTSHARE est manquant
  
  
  • si vous fournissez les deux valeurs, cela fonctionne
  
  
• si vous déployez sur une ressource existante
  
  
  
  • si vous ne fournissez aucun paramètre, le déploiement réussit, mais vous vous retrouvez avec le stockage non configuré, la mise à l'échelle de la fonction sera un message limité
  
  
  • si vous ne fournissez que WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, cela réussit (et semble fonctionner correctement par la suite) même si WEBSITE_CONTENTSHARE est censé être requis
  
  
  • si vous fournissez les deux valeurs, cela "fonctionne" dans la mesure où la partie ARM n'échoue pas, mais cela provoque le problème de redémarrage multiple et les instructions MS ci-dessus consistent à ne pas définir WEBSITE_CONTENTSHARE sur les mises à jour
  
  

Il ne semble donc pas y avoir de moyen d'avoir un seul modèle ARM qui fonctionne pour les deux scénarios pour le moment.

Salut Elliott

Ce que je voulais dire pour le deuxième point, c'est que le WEBSITE_CONTENTSHARE doit être défini comme un paramètre d'application, mais qu'il ne doit pas être défini comme un paramètre d'emplacement de déploiement.
Il ne devrait donc pas avoir la coche comme ci-dessous :

[cid:[email protected]]

De : Elliott Hamai [email protected]
Envoyé : 22 juin 2020 18:38
À : MicrosoftDocs/azure-docs [email protected]
Cc : Owain Winterbone (ITCS - Personnel) [email protected] ; Mentionnez [email protected]
Objet : Re : [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE ne doit pas être utilisé conformément au support (#36458)

Avertissement : Cet e-mail provient de l'extérieur du système UEA. Ne cliquez pas sur les liens ou les pièces jointes à moins que vous ne les attendiez de l'expéditeur et que vous sachiez que le contenu est sûr.

@OwainWin https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d8410835d816d2f874957Ccc09% %7C0%7C637284442665654874&sdata=x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw%3D&reserved=0 - Désolé, je suis confus par votre question. Vous avez demandé si vous deviez et non inclure WEBSITE_CONTENTSHARE.

Je pense que vous devriez avoir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE définis à la fois sur l'emplacement de production et de mise en scène.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cafedec71775f4f42d84108d816d2f967% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284442665664832 & sdata = ctK99d4qO2YuIN% 2F07lwuHC0wNut% 2Fx8LjgLd7v55rTAM% 3D et réservé = 0 , ou désabonnement https://eur01.safelinks.protection.outlook.com /?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PEPPJE7NN6RO5D4SSLRX6JGNANCNFSM4IJGDPBQ&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&sdata=wXaMW%2Fx% 2B5RXDtrfiQgHeZYtpc%2BhLyI9w6f9ut9NTFjM%3D&réservé=0 .

@paulbatum

• Lors de la création initiale de la ressource via ARM, WEBSITE_CONTENTSHARE doit être défini. Cependant, après la création initiale, ce paramètre doit être omis du modèle ARM (car s'il était inclus, d'autres exécutions du modèle ARM pourraient provoquer des échanges de contenu inattendus)

Vous réalisez que ce genre de brise le but d'un modèle ARM, n'est-ce pas ?

Ce comportement est en train d'être corrigé, mais il faudra probablement 1 à 2 mois pour s'en sortir. En attendant, les conseils que j'ai partagés ci-dessus (où vous les définissez initialement, puis les supprimez du modèle ARM) sont applicables.

Quelle est la configuration finale attendue ici ?
Pouvons-nous obtenir une annonce sur Azure/app-service-annonciations avec une configuration appropriée et un calendrier officiel une fois que tout cela est réellement déployé ?

C'est un gros bloqueur pour nous. Nous devons pouvoir utiliser le même modèle ARM pour déployer vers un nouveau groupe de ressources que nous utiliserions pour déployer vers un groupe de ressources existant. Nous exécutons spécifiquement nos modèles ARM en mode complet pour aider à fournir un peu plus de contexte.

À l'heure actuelle, notre modèle ARM ressemble à ceci :

{
  "apiVersion": "2016-08-01",
  "type": "Microsoft.Web/sites",
  "name": "[variables('functionAppName')]",
  "location": "[variables('defaultLocation')]",
  "kind": "functionapp",
  "properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  },
  "resources": [
    {
      "name": "slotconfignames",
      "type": "config",
      "apiVersion": "2016-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "appSettingNames": [
          "SomeSlotSpecificSetting"
        ]
      }
    },
    {
      "name": "staging",
      "type": "slots",
      "apiVersion": "2016-08-01",
      "location": "[variables('defaultLocation')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "AzureWebJobsStorage",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "AzureWebJobsDashboard",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "SomeSetting__Foo",
              "value": "[parameters('someSettings').foo]"
            },
            {
              "name": "SomeSetting__Bar",
              "value": "[parameters('someSettings').bar]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "dotnet"
            },
            {
              "name": "SomeSlotSpecificSetting",
              "value": "abc 123"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ],
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName'))]",
    "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  ]
}

Prenez note des détails suivants : Nous spécifions notre configuration _sur le slot de transfert_, pas le slot de production. Cela nous permet de déployer d'abord de nouveaux paramètres (et des mises à jour de ceux existants) sur le slot intermédiaire. Ainsi, notre pipeline DevOps fait ceci :

• Étape 1) Déployer le modèle ARM dans le groupe de ressources
• Étape 2) Déployer l'application Functions sur l'emplacement de transfert
• Étape 3) Exécutez des tests de fumée sur le slot intermédiaire
• Étape 4) Échangez les emplacements de mise en scène et de production

Le problème, cependant, est que parce que WEBSITE_CONTENTSHARE est défini dans le modèle ARM, le slot de production et le slot intermédiaire prennent immédiatement la nouvelle version de l'application juste après l'étape 2 (avant même qu'un échange ne se produise). Je crois que c'est de cela que les gens parlent quand ils disent "opération d'échange involontaire".

Nous _NE PAS_ voulons définir les paramètres de l'emplacement de production dans notre modèle ARM, et nous _NE voulons PAS_ que l'un des paramètres de l'emplacement de production soit supprimé à la suite de l'exécution de notre modèle ARM. La façon dont fonctionne le déploiement du modèle ARM en mode Complet est que si nous spécifions des paramètres pour l'emplacement de production, tous les paramètres qui ne sont pas explicitement spécifiés sont supprimés automatiquement.

J'espère que tout cela a du sens. Nous essayons actuellement de supprimer WEBSITE_CONTENTSHARE de notre modèle ARM, dans l'espoir que le runtime générera la valeur dans tous les scénarios et ne conduira plus à des "échanges involontaires".

Bonjour à tous, je suis le développeur principal des emplacements de déploiement et je vais répondre à vos préoccupations concernant la configuration de WEBSITE_CONTENTSHARE et WEBSITE_CONTENTAZUREFILECONNECTIONSTRING :

Voici le guide officiel :

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : cela doit toujours être défini car il indique au service d'application que vous utilisez des fichiers Azure pour le stockage de contenu.

SITE_CONTENUPARTAGE :

• Cela peut maintenant être complètement omis de vos modèles ARM pour les fonctions sku de consommation qui généreront automatiquement le champ et éviteront les échanges involontaires. Cela signifie que vous pouvez utiliser le même modèle pour la création et les mises à jour par la suite.

• Malheureusement, nous avons constaté que cette génération automatique de WEBSITE_CONTENTSHARE était négligée pour le ski Elastic Premium, donc le problème de devoir l'inclure lors de la création et de l'omettre lors des mises à jour persiste. Le correctif est en cours de déploiement et a atteint la moitié de notre flotte. Il devrait être complètement déployé au cours des 2 prochaines semaines et ensuite, les conseils seront les mêmes pour les deux skus et WEBSITE_CONTENTSHARE peut être complètement omis.

J'espère que cela répond à certaines de vos préoccupations!

@shubDhond Merci beaucoup. Pouvons-nous obtenir une mise à jour officielle sur la documentation?

@shubDhond pour les plans de consommation Windows si je fournis uniquement WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, j'obtiens une erreur via le déploiement du modèle de bras indiquant que WEBSITE_CONTENTSHARE est manquant.
Je n'ai pas besoin d'utiliser des slots. Si vous omettez les deux, le déploiement se déroule mais je reçois l'avertissement "le stockage n'est pas configuré. La mise à l'échelle de la fonction sera limitée".

Quelles sont les indications sur les plans de consommation par rapport à ces deux paramètres. J'utilise le plan de consommation Windows Core .net ?

Idem! J'obtiens également cette erreur. Quand cela sera-t-il corrigé ?

J'ai le même problème sur la consommation et le plan élastique, cela nous cause beaucoup de problèmes avec les déploiements automatisés.

J'ai eu un certain succès en omettant WEBSITE_CONTENTSHARE pour Premium lors du déploiement des paramètres directement dans les propriétés Microsoft.Web/sites (siteConfig, appSettings), mais pas lors de la spécification des paramètres en tant que ressource distincte en utilisant Microsoft.Web/sites/config avec "type": "config" .

@shubDhond Ce problème n'est certainement pas résolu. Sur le plan de consommation Windows, si vous déployez un modèle avec uniquement WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et sans WEBSITE_CONTENTSHARE, vous obtiendrez l'erreur "WEBSITE_CONTENTSHARE est manquant".

Essayer d'utiliser les tâches de déploiement App Service dans Azure DevOps et définir uniquement WEBSITE_CONTENTAZUREFILECONNECTIONSTRING produira également une erreur HTTP 400.

L'automatisation des applications Azure Function sur le plan de consommation est actuellement totalement interrompue.

Ayant le même problème que @clawrenceks

Nous rencontrons également le même problème que @clawrenceks.
Nous ne pouvons pas non plus définir uniquement WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sans WEBSITE_CONTENTSHARE via le portail Azure. Nous avons également WEBSITE_RUN_FROM_PACKAGE mis à 1.

Je ne sais pas non plus comment cela fonctionnera lorsque le mode de déploiement de votre modèle ARM est défini sur Complete ? Cela ne supprimera-t-il pas le paramètre d'application généré WEBSITE_CONTENTSHARE ?

Comme la plupart, nous sommes aussi perdus.

J'ai maintenant mon modèle ARM qui déploie avec succès mon application de fonction dans un plan de consommation Windows. Une fois déployé, le message Storage is not configured, Function scaling will be limited. Click to learn more n'est plus affiché. Les échanges de machines à sous fonctionnent également comme prévu.

Mes principales conclusions de ce processus sont les suivantes :

Si vous avez actuellement une application Azure Function SANS les paramètres d'application WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE , je pense que la seule façon de résoudre ce problème est de redéployer votre application, en vous assurant que le WEBSITE_CONTENTAZUREFILECONNECTIONSTRING paramètre

Avoir le WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en place dans le cadre de la création des ressources est la clé. Lors de l'utilisation d'ARM, mes conclusions sont qu'il doit être déployé en tant que paramètre d'application lors du déploiement du service d'application principal, avec un type de ressource de Microsoft.Web/sites . Avoir un type de ressource distinct de Microsoft.Web/sites/config dans votre modèle ARM pour déployer les paramètres de l'application ne fonctionnera pas.

Je n'inclus pas le paramètre WEBSITE_CONTENTSHARE dans mon modèle ARM. Ceci est créé par le runtime lorsque mon modèle ARM est déployé. C'est un signe que le déploiement fonctionne bien. Avec l'approche décrite ici, je suis en mesure de déployer les ressources initiales, puis de redéployer le modèle plusieurs fois sans recevoir d'erreurs liées au paramètre WEBSITE_CONTENTSHARE .

Une exigence clé distincte pour moi était que les paramètres d'application du site de production ne doivent être déployés que lors de la création initiale de la ressource. La seule façon dont je voulais obtenir de nouveaux paramètres d'application (futurs) dans le site de production est via un échange de slot. Pour y parvenir, j'ai ajouté une logique dans mon modèle ARM pour gérer les éléments suivants.

1) Les paramètres d'application dans le modèle ARM ne seront déployés sur le site de production que lors de la création initiale du site, ils ne seront pas ajoutés au site de production dans le cadre de futurs déploiements.

2) Les paramètres d'application dans le modèle ARM sont toujours appliqués à l'emplacement de transfert. Ils sont ensuite échangés en production à l'aide d'un emplacement d'échange.

Pour atteindre ce qui précède, les appSettings pour le site de production dans mon modèle ARM sont conditionnels. Si la ressource n'existe pas, je déploie l'ensemble complet des paramètres d'application dans le modèle (pour m'assurer que le service d'application est créé correctement). Si la ressource a déjà été créée, je passe un null pour les paramètres de l'application. Une fois déployé, cela conserve les paramètres d'application déjà en place pour le site de production.

Je suis aussi totalement confus. Si WEBSITE_CONTENTAZUREFILECONNECTIONSTRING est requis pour les plans de consommation, mais qu'il ne peut pas être configuré pour s'en tenir à un emplacement, comment suis-je censé basculer entre un emplacement intermédiaire et un emplacement de production où je souhaite que chacun s'exécute sur un compte de stockage différent ? Cela a toujours été possible avec les applications Web et semble être un cas d'utilisation très courant. Pour autant que je sache, l'échange d'emplacements d'application de fonction est complètement cassé / inutilisable jusqu'à ce que cela soit corrigé. J'adorerais que quelqu'un me dise pourquoi/comment j'ai tort ! Je sais que le problème d'origine fait référence aux modèles ARM, mais cela semble être un problème beaucoup plus large.

Même problème sur le plan Elastic Premium. Le déploiement sur le slot de stage du même modèle ARM avec le même WEBSITE_CONTENTSHARE fait que le slot de production pointe vers les mêmes binaires que le slot de stage.
Impossible de déployer sans WEBSITE_CONTENTSHARE car j'obtiens 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest' erreur

Je suis confus. Quelle est la bonne chose à faire ?

Si vous utilisez une prime ou une consommation élastique, vous devez répondre à l'un des critères suivants :

Vous devez avoir défini WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE

ou

Si vous utilisez run from zip/package, vous devez avoir défini "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" sur autre chose que vide, 0 ou 1

comme le dit @ehamai ?

ou

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : cela doit toujours être défini car il indique au service d'application que vous utilisez des fichiers Azure pour le stockage de contenu.

SITE_CONTENUPARTAGE :

Cela peut maintenant être complètement omis de vos modèles ARM pour les fonctions sku de consommation qui généreront automatiquement le champ et éviteront les échanges involontaires. Cela signifie que vous pouvez utiliser le même modèle pour la création et les mises à jour par la suite.

Malheureusement, nous avons constaté que cette génération automatique de WEBSITE_CONTENTSHARE était négligée pour le ski Elastic Premium, donc le problème de devoir l'inclure lors de la création et de l'omettre lors des mises à jour persiste. Le correctif est en cours de déploiement et a atteint la moitié de notre flotte. Il devrait être complètement déployé au cours des 2 prochaines semaines et ensuite, les conseils seront les mêmes pour les deux skus et WEBSITE_CONTENTSHARE peut être complètement omis.

J'espère que cela répond à certaines de vos préoccupations!

comme le dit @shubDhond ?

J'obtiens une erreur si j'ai une fonction azur sur le plan de consommation sans WEBSITE_CONTENTSHARE (en fait, l'emplacement de production n'a aucun paramètre d'application) sur l'un ou l'autre des emplacements et je :

1. déployer ARM sur l'emplacement de transfert
2. échanger
3. redéployer vers l'emplacement de transfert

Ensuite, il me dit que j'ai besoin du WEBSITE_CONTENTSHARE. C'est comme s'il ne pouvait pas générer de partage pour l'ancien créneau de production. Je n'ai pas essayé de supprimer le WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, car ce fil dit de ne pas le faire, sauf @ehamai , qui me dit que je peux le faire, si je fais un "WEBSITE_RUN_FROM_PACKAGE".

Ce qui est amusant, c'est que j'ai une fonction qui s'exécute avec cette configuration, mais avec un temps d'exécution ~2 au lieu de ~3 et cela fonctionne. Y a-t-il un problème avec ~3 et les emplacements de déploiement ?
C'est très déroutant.

Peu importe ce que cet échange spontané de machines à sous est très effrayant, de toute façon, comme nous devons créer ces deux variables WEBSITE_ , nous remplissons nous-mêmes cette dernière dans ARM selon la définition ici . L'outil de diagnostic de configuration de l'application web sur le portail n'affiche plus d'erreur.

réaffecter : @matchenderson

Une mise à jour pour ceci?

Nous avons également été informés par le support Microsoft que la propriété "WEBSITE_CONTENTSHARE" doit être définie. Lorsqu'il n'est pas possible de le définir en tant que paramètre d'emplacement, cela est assez problématique pour nos pipelines de construction et nos modèles ARM. S'il vous plaît des conseils!

Je suis d'accord aussi. Il est vraiment temps d'expliquer comment utiliser les machines à sous ici !

Je suis également d'accord, ce fil a été lancé il y a plus de 15 mois et il n'y a toujours pas de résolution stable.
Nous ne pouvons pas utiliser les slots tant que cela n'a pas été correctement résolu avec une solution de confiance, les slots sont une fonctionnalité fantastique mais ils doivent être fiables.

Salut tout le monde,

Extrêmement désolé pour le retard de réponse ici, ce fil n'était pas surveillé aussi bien qu'il aurait dû l'être.

Pour remédier à la confusion, le comportement décrit par @clawrenceks ci-dessus est correct pour le moment. Pour les sites sur lesquels le stockage Azure Files n'est pas encore configuré, vous devrez fournir à la fois WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE. Une fois ceux-ci fournis et votre application configurée pour s'exécuter sur Azure Files, vous pouvez par la suite omettre WEBSITE_CONTENTSHARE de vos modèles pour éviter d'échanger votre contenu par inadvertance.

La façon dont l'API fonctionne actuellement est que lors de la création du site (ressource 'Microsoft.Web/sites'), si vous fournissez WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et non WEBSITE_CONTENTSHARE, un partage de contenu sera généré pour vous. Cependant, lors des mises à jour d'une ressource 'Microsoft.Web/sites' existante ou d'une ressource 'Microsoft.Web/sites/config', l'API regarde s'il existe déjà une valeur pour WEBSITE_CONTENTSHARE pour l'application et si elle n'est pas présente , il renvoie une erreur.

Je suppose que cela visait à protéger les clients contre l'effacement par inadvertance de leur contenu lors du passage aux fichiers Azure, dans le cas où ils fournissent WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et nous générons un nouveau WEBSITE_CONTENTSHARE pour eux (essentiellement en essuyant leur contenu car ce partage serait nouveau). C'est beaucoup plus sûr lors de la création du site, car le site commencerait de toute façon par une table rase et nous ne risquons pas d'effacer votre contenu.

Je peux tout à fait comprendre la confusion pour vous tous qui souhaitent azurer les fichiers. Je devrai réfléchir à la meilleure façon de résoudre ce problème tout en gardant nos opérations de mise à jour à l'abri de l'effacement de votre contenu. Pour le moment, les conseils pour vous tous qui n'avez pas de fichiers Azure configurés et qui souhaitent effectuer le changement, vous devrez fournir à la fois WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE pour le changement initial, puis les conseils seraient les mêmes pour omettre WEBSITE_CONTENTSHARE de votre modèle par la suite.

S'il y a des suggestions sur la façon dont vous aimeriez voir le cas de mise à jour géré, ce serait également très apprécié !

@shubDhond , nous devons donc déployer les paramètres d'application de chaîne de connexion et de partage de contenu lors du premier déploiement sur l'emplacement de production, mais pas lors des déploiements ultérieurs. Y a-t-il un moyen de le faire automatiquement ? Comme détecter si une ressource a été déployée via ARM ? Ou devons-nous manuellement transmettre ces informations dans l'ARM (fx via un paramètre qui indique s'il s'agit du premier déploiement ?

@mslot malheureusement, je ne pense pas qu'il soit possible de dire dans un modèle si une ressource existe déjà ou non, mais cela devrait être possible avec cela (https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) combiné à un paramètre passé au modèle lui indiquant si le site est déjà configuré pour Azure Files. Cela peut être déterminé en obtenant le site et en vérifiant si les paramètres de l'application ont WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE.

@mslot malheureusement, je ne pense pas qu'il soit possible de dire dans un modèle si une ressource existe déjà ou non, mais cela devrait être possible avec cela (https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) combiné à un paramètre passé au modèle lui indiquant si le site est déjà configuré pour Azure Files. Cela peut être déterminé en obtenant le site et en vérifiant si les paramètres de l'application ont WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE.

J'espère vraiment que cela sera corrigé bientôt. Cela rend l'utilisation des slots inutile dans mon flux de travail. Il doit être entièrement automatique. Cette solution est une solution de contournement à mes yeux et cela n'a pas de sens de l'introduire lorsqu'elle fonctionne pour des applications Web, car elle diverge beaucoup sur quelque chose qui devrait fonctionner de la même manière en introduisant de la "magie noire" pour les autres entrant dans un projet.

J'espère vraiment que cela sera corrigé afin que nous puissions commencer à l'utiliser. Je pense que cela empêche beaucoup de gens d'utiliser cette fonctionnalité.

@mslot Je comprends parfaitement votre douleur avec cela et je suis désolé que nous n'ayons pas pu identifier ce problème plus tôt. Je vais parler aux développeurs qui ont initialement mis en œuvre ce comportement au cours de la semaine à venir et voir si nous pouvons trouver une solution sûre à ce problème qui pourrait éviter la possibilité que les clients passent par inadvertance à l'utilisation d'un partage de fichiers Azure vide pour leur contenu. Une fois que nous aurons une solution proposée, je mettrai à jour ici.

@shubDhond Je ne comprends pas vraiment la "partie" Azure Files. Je déploie mon projet Azure Function à l'aide d'Azure DevOps en créant d'abord un emplacement de déploiement, en déployant sur celui-ci, puis en échangeant. J'utilise la méthode de déploiement "RunFromPackage" et cela ne semble pas fonctionner lors de l'utilisation d'un StorageAccount classique. Je n'utilise PAS Azure Files et je semble avoir le même problème lié au paramètre WEBSITES_CONTENTSHARE pour les deux emplacements.

Salut @cannehag, pourriez-vous s'il vous plaît ouvrir un nouveau problème pour cela? Il peut se produire un comportement étrange lorsque le paramètre de l'application RunFromPackage est marqué comme persistant, provoquant des symptômes similaires à ceux décrits ici. Je suggérerais un nouveau problème afin que nous n'ajoutions pas de confusion ici car les problèmes sont probablement sans rapport.