@danielstocker Vielen Dank, dass Sie uns darauf aufmerksam gemacht haben. Ich lasse dies dem Service Lead zuordnen, um es weiter zu untersuchen und werde ein Update vornehmen, wenn wir mehr Klarheit haben.

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

Danke, dass Sie sich das angeschaut haben.

Benötigen Sie weitere Informationen, um dies voranzutreiben?

@danielstocker können Sie mehr Hintergrundinformationen zu Ihrem ursprünglichen Problem liefern, das zu dieser Entdeckung geführt hat? Ich bin mir nicht sicher, ob ich die Implikation einer falschen Einstellung richtig verstehe (was Sie als unintentional swap ).

Hallo @ggirard07 ,

Kein Problem. Lassen Sie mich zusammenfassen.
Dies geschah ursprünglich, weil in unserer Dokumentation angegeben ist, dass WEBSITE_CONTENTSHARE erforderlich ist. (siehe hier: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

Wenn wir eine Functions-Vorlage aus dem Marketplace exportieren (Vorlage exportieren auf der letzten Seite), erhalten wir WEBSITE_CONTENTSHARE als Standard-App-Einstellung. Wenn wir dies verwenden, kann die folgende Situation eintreten.

1) Wir stellen ein ARM-Template bereit und erhalten eine leere Funktion mit zwei Slots
2) Wir stellen den Staging-Slot bereit
3) Wir tauschen, um die Inhalte in der Produktion verfügbar zu machen
4) UNBEABSICHTIGTER SWAP, wenn die ARM-Vorlage erneut bereitgestellt und App-Einstellungen erneut angewendet werden (dies geschieht sogar während einer inkrementellen ARM-Bereitstellung, da die Appsettings-Ressource immer die WEBSITE_CONTENTSHARE-Einstellung überschreibt und zurücksetzt)
5) Die Bereitstellungsroutine stellt jetzt den neuen Code im Staging-Slot bereit und unser Produktions-Slot ist leer, anstatt die vorherige Version zu enthalten. Unsere Produktionsfunktion ist "ungewollt" ausgefallen

Der Kunde verwies dann im konkreten Fall auf diesen Artikel https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

Dies legt nahe, dass die Einstellung als Slot-Einstellung festgelegt werden sollte, um das Verhalten zu beheben. Dies behebt zwar das Verhalten in meinen Tests, scheint jedoch falsch zu sein, da es nicht funktionieren sollte.

Unten ist eine Tabelle, was in meinen Tests passiert ist. (nachdem es eine Slot-Einstellung gemacht hat)

Meine (und die des Kunden) Wahrnehmung ist, dass die Slots überhaupt nicht mehr getauscht werden sollten, aber wie im Artikel beschrieben funktioniert es trotzdem.

Ich habe dies auch intern angesprochen und die Leute fanden ein inkonsistentes Verhalten beim Ändern der App-Einstellungen. (Deshalb ist dies in meinem Testraster hervorgehoben) Für einen Kollegen, der es testete und die App-Einstellungen aktualisierte, wurden die Slot-Einstellungen erneut angewendet, wodurch erneut ein unbeabsichtigter Tausch verursacht wurde.

Dies führte dann schließlich (entschuldigung für die lange Antwort) dazu, den Support-Fall anzusprechen, bei dem das Ergebnis "nur die Einstellung überhaupt nicht festlegen" lautete.
Meine persönlichen Tests haben gezeigt, dass dies das Problem behebt, aber es gibt keine Anleitung in der Dokumentation, um dies zu bestätigen, daher habe ich diesen Punkt angesprochen.

Hoffe das hilft.
Lassen Sie mich wissen, wenn etwas unklar ist.

@danielstocker definitiv eine wichtige Information, insbesondere um zu verstehen, wie die Slots und das Swapping für Functions im Vergleich zu einer traditionellen Webapp mit Webjobs funktionieren.
Auch dies wird in der Slot-Dokumentation nicht erklärt, obwohl 'WEBSITE_CONTENTSHARE' hier eine entscheidende Rolle spielt. Es gibt nur einen einzigen Screenshot in Schritt 4, der dies darstellt, wo diese Werte abgeschnitten sind, um die Dinge noch klarer zu machen ...

Hallo @ggirard07 und danke fürs Durchlesen meiner Hetzrede. Wie geht es von hier aus weiter? :)

@ggirard07 @ggailey777 @mike-urnun-msft

Sind weitere Informationen erforderlich, um Klarheit in der Dokumentation zu diesem Verhalten zu schaffen? Ich arbeite mit einem Kunden zusammen, der erwägt, die Nutzung von Funktionsslots einzustellen, weil er sich bezüglich der offiziellen Anleitung zu diesem Szenario nicht sicher ist.

Danke für Ihre Hilfe

@danielstocker Nur damit ich angehen wird:

• Entfernen Sie die WEBSITE_CONTENTSHARE Einsatz Einstellung von hier .
• Fügen Sie im Referenzartikel einen Hinweis hinzu, dass WEBSITE_CONTENTSHARE nur von der Laufzeit gesetzt werden soll.

Meinst du das würde reichen?

cc. @mattenderson

Hallo @ggailey777
Ja ich denke das wäre eine gute Lösung

Ist WEBSITE_CONTENTSHARE eine der erforderlichen Anwendungseinstellungen beim Bereitstellen einer Funktions-App mit ARM?

Ist WEBSITE_CONTENTSHARE eine der erforderlichen Anwendungseinstellungen beim Bereitstellen einer Funktions-App mit ARM?

Wenn es nicht angewendet wird, generiert die Laufzeit eine für Sie, denke ich.

Ich habe einen ARM mit einem Verbrauchsplan und eine Funktions-App mit einem Abschnitt _Microsoft.Web/sites/config_ namens appsettings und den folgenden Eigenschaften

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

Die Bereitstellung hat den folgenden Fehler zurückgegeben:

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

Nachdem ich den Parameter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING _auch_ entfernt habe, verlief die Bereitstellung ohne Fehler. Es scheint also eine erforderliche Beziehung zwischen diesen beiden Einstellungen zu geben.
Obwohl erfolgreich, hat mich diese Bereitstellung dazu gebracht, zu wandern, ob und wo Funktionen (Pakete) physisch bereitgestellt werden (und ob dieser Fall überhaupt gültig ist).

Wir haben das genaue Verhalten gesehen, das @tjgalama beschrieben hat und fragen

Unsere Funktions-Apps enthalten auch eine Timer-getriggerte Funktion, daher geben wir die Einstellung AzureWebJobsStorage wie vorgeschlagen an : Wir hätten erraten/gehofft, dass die Laufzeit dieselbe Verbindungszeichenfolge für das (jetzt implizite) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , aber das ist nicht der Fall: In dem dort angegebenen Speicherkonto sehen wir die Blob-Container azure-webjobs-hosts und azure-webjobs-secrets , aber es sind keine Dateifreigaben vorhanden.

Ich habe in Kudu nach Hinweisen gesucht und es sieht so aus, als ob sich alle Dateien, die vorhanden sein müssen, im Dateisystem befinden (wo immer das heißt, überprüft auf app-name.scm.azurewebsites.net/api/vfs/ ), aber kein Hinweis auf eine der Einstellungen ( WEBSITE_CONTENTSHARE oder WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ) ist im Umgebungs-Tab zu sehen ( appname.scm.azurewebsites.net/Env.cshtml ).

Vielleicht ist es wichtig zu erwähnen, dass unsere Apps mit WEBSITE_ENABLE_SYNC_UPDATE_SITE=True und WEBSITE_RUN_FROM_PACKAGE=1 .
Die Apps scheinen zu funktionieren, aber wir würden uns in diesem Punkt wirklich etwas Klarheit wünschen, da wir einen Kerngeschäftsdienst auf Azure Functions portieren und diesen vor dem Rollout in die Produktion herausfinden möchten.

Nach einigen Ratschlägen hatten wir WEBSITE_CONTENTSHARE als Slot-Einstellung festgelegt, um sicherzustellen, dass die Werte zwischen unseren Produktions- und Staging-Slots unterschiedlich waren. Heute schlug die von uns verwendete ARM-Vorlage mit 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (obwohl ich bestätigt habe, dass sie derzeit tatsächlich als Slot-Einstellung im Portal festgelegt ist). Hat sich an diesem Verhalten etwas geändert?

Wir haben das gleiche Problem in den letzten Tagen festgestellt und benötigen eine Anleitung zum weiteren Vorgehen. Wir haben auch den Ansatz verfolgt, WEBSITE_CONTENTSHARE als Slot-Einstellung festzulegen, um das Problem des unbeabsichtigten Swaps zu umgehen, können aber jetzt aufgrund dieses Fehlers nicht bereitgestellt werden. Ich habe versucht, sowohl diese als auch die WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-Einstellungen rückwirkend zu entfernen, um zu dem anscheinend empfohlenen Ansatz zu gelangen, beide nicht zu verwenden, aber diese Bereitstellungen würden ebenfalls fehlschlagen.

Nach einigen Ratschlägen hatten wir WEBSITE_CONTENTSHARE als Slot-Einstellung festgelegt, um sicherzustellen, dass die Werte zwischen unseren Produktions- und Staging-Slots unterschiedlich waren. Heute schlug die von uns verwendete ARM-Vorlage mit 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (obwohl ich bestätigt habe, dass sie derzeit tatsächlich als Slot-Einstellung im Portal festgelegt ist). Hat sich an diesem Verhalten etwas geändert?

Entfernen Sie es und lassen Sie die Laufzeit einen Namen auswählen. So mache ich es.

@jeffhollan kannst du uns bitte etwas Klarheit verschaffen

Dies besagt, dass WEBSITE_CONTENTSHARE und WEBSITE_CONTENTAZUREFILECONNECTIONSTRING _erforderlich_ sind: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

Kommentatoren hier denken, dass sie _nicht_ erforderlich sind; ARM hält sie für erforderlich?; Der Azure-Support ist der Meinung, dass WEBSITE_CONTENTSHARE Slotszenarien unterbricht.

Am Ende haben wir den Code des Azure-Funktionshosts überprüft und es sieht so aus , als würde die Einstellung WEBSITE_CONTENTAZUREFILECONNECTIONSTRING bei der Ausführung aus dem Paket nicht verwendet .
Wir haben dies überprüft, indem wir sowohl WEBSITE_CONTENTAZUREFILECONNECTIONSTRING als auch WEBSITE_CONTENTSHARE aus unserer ARM-Vorlage entfernt und gute Ergebnisse erzielt haben: Unsere Funktions-Apps haben diese beiden Einstellungen überhaupt nicht (nicht einmal von der Laufzeit zugewiesen) und sie Verwenden Sie keine Dateifreigaben in einem Speicherkonto (zumindest das können wir sehen).

Denken Sie also daran, dass das Dateisystem für eine Webapp/Funktions-App ungefähr so ​​​​aussieht:

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

Wenn Sie Run from package verwenden, ersetzt dies nur den Ordner wwwroot in diesem Baum. Alles andere wird vom Hauptdateisystem bereitgestellt. Wenn Sie eine Verbrauchs- oder elastische Premium-Funktions-App ohne WEBSITE_CONTENTAZUREFILECONNECTIONSTRING erstellen, ist das Hauptdateisystem außerhalb der Skalierungseinheit nicht verfügbar, in der die Funktions-App erstellt wurde. Dies ist keine unterstützte/empfohlene Konfiguration. Dies bedeutet, dass Ihre Funktions-App möglicherweise nicht über die Grenzen der Skalierungseinheit hinaus skaliert, in der sie erstellt wurde, oder wenn dies der Fall ist, können Sie nicht darauf vertrauen, dass der Dateisystemstatus außerhalb von wwwroot konsistent bleibt.

Die neueste Anleitung, die ich von dem Entwickler gesehen habe, der die Interaktion von WEBSITE_CONTENTSHARE mit Slots besitzt, ist die folgende:

• WEBSITE_CONTENTSHARE sollte KEINE Slot-Einstellung sein. Eine API-Änderung, die dies blockiert, wird zum Zeitpunkt des Schreibens eingeführt.
• Beim erstmaligen Anlegen der Ressource über ARM sollte WEBSITE_CONTENTSHARE gesetzt werden. Nach der erstmaligen Erstellung sollte diese Einstellung jedoch aus der ARM-Vorlage weggelassen werden (da, wenn sie enthalten ist, weitere Ausführungen der ARM-Vorlage zu unerwarteten Inhaltswechseln führen können)

Aus meinem obigen Kommentar folgend.. Ich habe auch festgestellt, dass das System derzeit ein inkonsistentes Verhalten beim Generieren von WEBSITE_CONTENTSHARE aufweist, sodass Sie es nicht einmal zuerst angeben müssen. Einige von Ihnen haben gesagt, dass Sie es nicht angeben müssen, während andere eine Fehlermeldung erhalten, dass es erforderlich ist. Soweit ich das beurteilen kann, funktioniert dieses Verhalten für den Konsum korrekt (dh eine ARM-Vorlage für den Konsum benötigt diese Einstellung zunächst nicht), aber das gleiche gilt nicht für die elastische Prämie. Dieses Verhalten wird behoben, aber es wird wahrscheinlich 1-2 Monate dauern, bis es herauskommt. In der Zwischenzeit gilt die oben beschriebene Anleitung (in der Sie sie zunächst festlegen und dann aus der ARM-Vorlage entfernen).

@paulbatum

• Beim erstmaligen Anlegen der Ressource über ARM sollte WEBSITE_CONTENTSHARE gesetzt werden. Nach der erstmaligen Erstellung sollte diese Einstellung jedoch aus der ARM-Vorlage weggelassen werden (da, wenn sie enthalten ist, weitere Ausführungen der ARM-Vorlage zu unerwarteten Inhaltswechseln führen können)

Sie wissen, dass diese Art von Unterbrechung den Zweck einer ARM-Vorlage hat, oder?

Dieses Verhalten wird behoben, aber es wird wahrscheinlich 1-2 Monate dauern, bis es herauskommt. In der Zwischenzeit gilt die oben beschriebene Anleitung (in der Sie sie zunächst festlegen und dann aus der ARM-Vorlage entfernen).

Was ist die endgültige erwartete Konfiguration hier?
Können wir eine Ankündigung zu Azure/App-Service-Ankündigungen mit der richtigen Konfiguration und dem offiziellen Zeitplan erhalten, sobald dies alles tatsächlich bereitgestellt wurde?

Hallo, ich bin mir nicht sicher, ob es diesbezüglich eine Entwicklung gegeben hat. Ich habe immer noch Probleme, ARM-Vorlagen mit dem Flag WEBSITE_CONTENTSHARE zu verwenden. @paulbatum Wie kann ich eine Konfiguration aus der ARM-Vorlage weglassen? Ich musste den Schritt komplett deaktivieren, damit er funktioniert.

@gustavobmichel Sorry, ich verstehe deine Frage nicht. Die ARM-Vorlage ist JSON, Sie bearbeiten sie nach Bedarf. Es erscheint als Teil des Abschnitts Appsettings, z. B.:

          "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'))]"
            },

Hallo @paulbatum , danke, dass du zu mir zurückgekommen bist. Ich dachte, Sie haben erwähnt, dass Sie die Einstellungen aus der JSON-Vorlage programmgesteuert weglassen, also war das meine Frage.

Wie andere sagten, dachte ich auch, dass diese beiden Einstellungen erforderlich sind, also habe ich die beiden aus meiner ARM-Vorlage entfernt.

Um diese Funktion ohne Ausfallzeiten zu testen, habe ich einen einfachen Test mit der minimalen Infrastruktur erstellt, um sie zu testen. Ich habe alle Ressourcen aus meiner Ressourcengruppe entfernt und die ARM-Vorlage als Teil der Release-Pipeline ausgeführt, um die Ressourcen ohne WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE und WEBSITE_RUN_FROM_PACKAGE zu erstellen.

Ich habe ein paar Tests durchgeführt und es funktioniert immer noch alles in Ordnung mit dem Verbrauchsplan. Ich werde diese Woche einige Tests mit der Premium-Stufe durchführen.

Ich habe auch diese Konfiguration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG zu 1 gemäß diesem Link hinzugefügt: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Ich habe meine Test-ARM-Vorlage als Referenz angehängt.
azuredeploy.txt

Hallo @paulbatum , danke, dass du zu mir zurückgekommen bist. Ich dachte, Sie haben erwähnt, dass Sie die Einstellungen aus der JSON-Vorlage programmgesteuert weglassen, also war das meine Frage.

Wie andere sagten, dachte ich auch, dass diese beiden Einstellungen erforderlich sind, also habe ich die beiden aus meiner ARM-Vorlage entfernt.

Um diese Funktion ohne Ausfallzeiten zu testen, habe ich einen einfachen Test mit der minimalen Infrastruktur erstellt, um sie zu testen. Ich habe alle Ressourcen aus meiner Ressourcengruppe entfernt und die ARM-Vorlage als Teil der Release-Pipeline ausgeführt, um die Ressourcen ohne WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE und WEBSITE_RUN_FROM_PACKAGE zu erstellen.

Ich habe ein paar Tests durchgeführt und es funktioniert immer noch alles in Ordnung mit dem Verbrauchsplan. Ich werde diese Woche einige Tests mit der Premium-Stufe durchführen.

Ich habe auch diese Konfiguration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG zu 1 gemäß diesem Link hinzugefügt: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Ich habe meine Test-ARM-Vorlage als Referenz angehängt.
azuredeploy.txt

Wenn wir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING weglassen, woher weiß Ihre Funktion, woher sie den App-Code bekommt?

Wenn es hilft, haben wir uns auf Folgendes festgelegt:

• Festlegen von WEBSITE_CONTENTAZUREFILECONNECTIONSTRING auf das Speicherkonto, von dem aus der Code ausgeführt werden soll
• keine Angabe von WEBSITE_CONTENTSHARE in der Arm-Vorlage (erlauben Sie, dass es für beide Slots automatisch generiert wird)
• WEBSITE_RUN_FROM_PACKAGE = 1

Ich habe viele Tests um diese herum durchgeführt und dies schien die beste Konfiguration zu sein, um zu vermeiden, dass unbeabsichtigte Swaps ausgelöst werden und zu wissen, wo der Code sitzt usw. Es ist auch nicht erforderlich, diese Einstellungen außerhalb der ARM-Vorlage zu verwalten, was mir nicht gefallen hat die Idee von (fühlt sich an, als ob es zu diesem Zeitpunkt nicht viel Sinn macht, ARM-Vorlagen zu verwenden).

Die Bereitstellung scheint auch ohne Angabe eines WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-Werts zu funktionieren, aber wie bereits erwähnt, konnten wir nicht herausfinden, wo sich der Code befand, und der MS-Supportmitarbeiter, der mein Ticket bearbeitete, schien vorzuschlagen, dass dies ein Fehler war und nicht zugelassen werden sollte durch die Plattform.

Wenn es hilft, haben wir uns auf Folgendes festgelegt:

• Festlegen von WEBSITE_CONTENTAZUREFILECONNECTIONSTRING auf das Speicherkonto, von dem aus der Code ausgeführt werden soll
• keine Angabe von WEBSITE_CONTENTSHARE in der Arm-Vorlage (erlauben Sie, dass es für beide Slots automatisch generiert wird)
• WEBSITE_RUN_FROM_PACKAGE = 1

Ich habe viele Tests um diese herum durchgeführt und dies schien die beste Konfiguration zu sein, um zu vermeiden, dass unbeabsichtigte Swaps ausgelöst werden und zu wissen, wo der Code sitzt usw. Es ist auch nicht erforderlich, diese Einstellungen außerhalb der ARM-Vorlage zu verwalten, was mir nicht gefallen hat die Idee von (fühlt sich an, als ob es zu diesem Zeitpunkt nicht viel Sinn macht, ARM-Vorlagen zu verwenden).

Die Bereitstellung scheint auch ohne Angabe eines WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-Werts zu funktionieren, aber wie bereits erwähnt, konnten wir nicht herausfinden, wo sich der Code befand, und der MS-Supportmitarbeiter, der mein Ticket bearbeitete, schien vorzuschlagen, dass dies ein Fehler war und nicht zugelassen werden sollte durch die Plattform.

Genau das habe ich auch herausgefunden. Danke für die Bestätigung.

Meine Funktion hat Probleme beim Zugriff auf den Speicher, nachdem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_RUN_FROM_PACKAGE hinzugefügt wurden. Haben Sie diese beiden Konfigurationen sowohl zu functionapp als auch zu Slot hinzugefügt?

Der genaue Fehler lautet: Azure Functions Runtime ist nicht erreichbar.

Das ist, nachdem ich die erste Bereitstellung durchgeführt habe und dann versuche, eine neue Version bereitzustellen.

Ich habe auch meine yml-Datei hinzugefügt.
yml-Datei.txt
deploy.txt

Ich habe auch meine ARM-Vorlage aktualisiert.

Meine Funktion hat Probleme beim Zugriff auf den Speicher, nachdem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_RUN_FROM_PACKAGE hinzugefügt wurden. Haben Sie diese beiden Konfigurationen sowohl zu functionapp als auch zu Slot hinzugefügt?

Der genaue Fehler lautet: Azure Functions Runtime ist nicht erreichbar.

Das ist, nachdem ich die erste Bereitstellung durchgeführt habe und dann versuche, eine neue Version bereitzustellen.

Ich habe auch meine yml-Datei hinzugefügt.
yml-Datei.txt
deploy.txt

Ich habe auch meine ARM-Vorlage aktualisiert.

Ich habe es auf beiden. Eigentlich habe ich nichts in meinem Produktionsslot und tausche alles aus dem Staging ein. Ich habe dies beim Definieren eines WEBSITE_CONTENTSHARE oder beim Verweisen auf das richtige Speicherkonto, in dem sich der Code mit WEBSITE_CONTENTAZUREFILECONNECTIONSTRING befindet, gesehen. Sie müssen mit WEBSITE_CONTENTSHARE nirgendwo hinzeigen. Ich glaube tatsächlich, dass ich den Fehler gesehen habe, auf den Sie sich beziehen, weil Sie Umgebungsvariablen einen WEBSITE_CONTENTSHARE hinzugefügt haben. Stellen Sie sicher, dass Sie es nicht definiert haben.

Hallo @mslot , ich denke, das Problem lag an meiner Bereitstellung. Ich habe es auf zipDeploy eingestellt, weil ich in diesem Thread https://stackoverflow.com/a/56205917 über das Festlegen von Azure DevOps gelesen habe. Nachdem ich es auf die Standardbereitstellung geändert habe, scheint alles zu funktionieren. Danke für Ihre Hilfe.

Dieses Verhalten wird behoben, aber es wird wahrscheinlich 1-2 Monate dauern, bis es herauskommt.

Irgendein Update zu diesem Thema? Sind Verbrauchs- und Prämienverhalten jetzt aufeinander abgestimmt? Können wir WEBSITE_CONTENTSHARE bei der anfänglichen ARM-Bereitstellung und den nachfolgenden Bereitstellungen weglassen? Wie wirkt sich dies auf Staging-Slots aus? Irgendwelche aktualisierten Dokumente zum Verlinken oder Anleitungen?

Wir haben uns im Wesentlichen für den gleichen Ansatz wie @thomaswilkin und @mslot entschieden, aber nur durch Experimentieren und Ausprobieren. Immer noch nicht einmal sicher, wie die Laufzeitumgebung weiß, wo unsere Dateien zu finden sind, da WEBSITE_CONTENTSHARE nicht gesetzt ist.

Hi. Ich bin mir nicht sicher, wie ihr das machen könnt, aber es scheint, als ob ich es nicht einsetzen kann
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ohne WEBSITE_CONTENTSHARE. Sogar über das Portal gab es einen Fehler beim Versuch, die Konfiguration einzustellen;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

Auf der Übersichtsseite der Funktions-App sehe ich auch diese Warnmeldung: Storage is not configured, Function scaling will be limited. Click to learn more. Ich betreibe einen Premium-Plan. Gibt es Updates oder offizielle Richtlinien zur Konfiguration unserer Funktions-Apps?

Für den Premium-Plan (nicht 100% sicher über den Verbrauchsplan) ist hier die Matrix dessen, was funktioniert/nicht funktioniert:

• Wenn Sie eine neue Ressource bereitstellen:
  
  
  
  • Wenn Sie keine der Einstellungen angeben, ist die Bereitstellung erfolgreich, aber Sie erhalten am Ende die Meldung Storage is not configured, Function scaling will be limited
  
  
  • Wenn Sie nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING angeben, schlägt es mit Required parameter WEBSITE_CONTENTSHARE is missing fehl
  
  
  • Wenn Sie beide Werte angeben, funktioniert es
  
  
• wenn Sie für eine vorhandene Ressource bereitstellen
  
  
  
  • Wenn Sie keine der Einstellungen angeben, ist die Bereitstellung erfolgreich, aber Sie erhalten am Ende die Meldung Storage is not configured, Function scaling will be limited
  
  
  • Wenn Sie nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , ist dies erfolgreich (und scheint danach gut zu funktionieren), obwohl WEBSITE_CONTENTSHARE erforderlich sein soll
  
  
  • wenn Sie beiden Werte liefern, es ‚funktioniert‘, dass der ARM - Teil nicht scheitern, aber es bewirkt , dass das Multiple-Neustart Problem und die Führung MS oben ist nicht Satz WEBSITE_CONTENTSHARE auf dem Updates
  
  

Es scheint also derzeit keine Möglichkeit zu geben, eine einzige ARM-Vorlage zu haben, die für beide Szenarien funktioniert.

Ich sehe auch diese Warnmeldung: Storage is not configured, Function scaling will be limited. Click to learn more . Havent hatte die Website WEBSITE_CONTENTAZUREFILECONNECTIONSTRING oder WEBSITE_CONTENTSHARE. Wie Korkiak erwähnt, gibt es eine aktualisierte oder offizielle Richtlinie?

Seit kurzem sehen wir im Azure-Portal für vorhandene Azure-Funktionen, die vor vier Wochen bereitgestellt wurden, die Meldung „Speicher ist nicht konfiguriert, Funktionsskalierung wird eingeschränkt. Klicken Sie hier, um mehr zu erfahren“. Wir haben weder WEBSITE_CONTENTAZUREFILECONNECTIONSTRING noch WEBSITE_CONTENTSHARE verwendet und das hat bis jetzt gut funktioniert.

@paulbatum Scheint, als würde dieses Problem in den letzten Tagen mehr Aktivität erhalten, da die Meldung "Speicher ist nicht konfiguriert, Funktionsskalierung wird eingeschränkt" im Portal angezeigt wurde. Gibt es eine neue Anleitung zur richtigen Konfiguration von all dem?

Ich habe gerade festgestellt, dass 'WEBSITE_CONTENTSHARE' kein Slot-Einstellungsfehler sein kann, wie oben erwähnt, wenn eine neue Funktions-App zum ersten Mal seit mehreren Monaten mit einer Vorlage bereitgestellt wird, die zuvor einwandfrei funktioniert hat.
Die Vorlage hat "WEBSITE_CONTENTSHARE" als Slot-Einstellung und ist sowohl in den App-Einstellungen der Funktions-App als auch der Bereitstellungs-Slot-App gemäß dem folgenden Artikel definiert, der ebenfalls oben erwähnt wurde:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
Beim Lesen dieses Threads wurde dies als Slot-Einstellung entfernt und verschiedene Kombinationen der Einstellung 'WEBSITE_CONTENTSHARE' ausprobiert, und ich erhalte nicht das gleiche Verhalten wie andere. Ich kann ohne Fehler wie folgt bereitstellen:

• Geben Sie 'WEBSITE_CONTENTSHARE' sowohl für die Funktions-App als auch für den Bereitstellungs-Slot an
• Geben Sie 'WEBSITE_CONTENTSHARE' nur für die Funktions-App an

Wenn ich 'WEBSITE_CONTENTSHARE' im Template überhaupt nicht angebe, erhalte ich die Fehlermeldung "Erforderlicher Parameter WEBSITE_CONTENTSHARE fehlt".

Können wir bitte ein Update zu den tatsächlichen Einstellungen haben, da ich mit diesem aktuellen Verhalten nicht in der Produktion bereitstellen kann.

Hallo zusammen, sorry für die Verwirrung hier. Wir haben versucht, schlau zu sein, indem wir Sie vom Azure-Portal benachrichtigt haben, wenn bei Ihrer Konfiguration Skalierungsprobleme auftreten können, aber wir haben die Logik vermasselt, sodass die Warnung jetzt möglicherweise falsch angezeigt wird. Wir arbeiten an einer Lösung, aber in der Zwischenzeit können Sie so überprüfen, ob Skalierungsprobleme mit Ihrer App auftreten oder nicht:

Wenn Sie mit elastischer Prämie oder Verbrauch arbeiten, müssen Sie eines der folgenden Kriterien erfüllen:

1. Sie müssen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE definiert haben

oder

1. Wenn Sie Run from zip/package verwenden, müssen Sie "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" oder "WEBSITE_RUN_FROM_PACKAGE" auf einen anderen Wert als leer, 0 oder 1 setzen

Wir sollten irgendwann nächste Woche eine Lösung dafür haben.

Danke @ehamai - für # 2, wenn Sie sagen "auf etwas anderes als leer, 0 oder 1 setzen" - ist das richtig? Gibt es keine 0 und 1 Gegensätze? (Wir haben uns auf 1 gesetzt und wir davon aus, dass bedeutete ja / true (do von Paket ausführen) , wie hier dokumentiert: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -Bereitstellungspaket)

Hallo Elliott, vielen Dank für die extrem schnelle Antwort.

Also nur zur Verdeutlichung:
Bei Bereitstellung von einer ARM-Vorlage für den Verbrauchsplan und Verwendung eines Bereitstellungsslots, aber kein ZIP/Paket

• Ich sollte sowohl WEBSITE_CONTENTAZUREFILECONNECTIONSTRING als auch WEBSITE_CONTENTSHARE sowohl im Produktions- als auch im Staging-Slot definieren.

• Ich sollte WEBSITE_CONTENTSHARE NICHT als Bereitstellungs-Slot-Einstellung für einen der Slots definieren.

Mit freundlichen Grüßen

Owain

Von: Elliott Hamai [email protected]
Gesendet: 22. Juni 2020 17:31
An: MicrosoftDocs/ azure -docs
Cc: Owain Winterbone (ITCS - Mitarbeiter) [email protected] ; Handbuch [email protected]
Betreff: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE sollte gemäß Support nicht verwendet werden (#36458)

Warnung: Diese E-Mail stammt von außerhalb des UEA-Systems. Klicken Sie nicht auf Links oder Anhänge, es sei denn, Sie erwarten diese vom Absender und wissen, dass der Inhalt sicher ist.

Hallo zusammen, sorry für die Verwirrung hier. Wir haben versucht, schlau zu sein, indem wir Sie vom Azure-Portal benachrichtigt haben, wenn bei Ihrer Konfiguration Skalierungsprobleme auftreten können, aber wir haben die Logik vermasselt, sodass die Warnung jetzt möglicherweise falsch angezeigt wird. Wir arbeiten an einer Lösung, aber in der Zwischenzeit können Sie so überprüfen, ob Skalierungsprobleme mit Ihrer App auftreten oder nicht:

Wenn Sie mit elastischer Prämie oder Verbrauch arbeiten, müssen Sie eines der folgenden Kriterien erfüllen:

1. Sie müssen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE definiert haben

oder

1. Wenn Sie Run from zip/package verwenden, müssen Sie "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" oder "WEBSITE_RUN_FROM_PACKAGE" auf einen anderen Wert als leer, 0 oder 1 setzen

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an 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 & reserviert = 0 oder abmelden 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 & reserviert = 0 .

@briandunnington - Ja, es tut mir leid, es ist verwirrend.

• 0 bedeutet deaktiviert
• 1 bedeutet, von einer lokalen ZIP-Datei ausgeführt zu werden, aber damit dies ordnungsgemäß funktioniert, müssen Sie auch WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE durch die erste Anweisung definiert haben.

@OwainWin - Entschuldigung, ich bin durch Ihre Frage verwirrt. Sie haben gefragt, ob Sie WEBSITE_CONTENTSHARE einschließen sollen oder nicht.

Ich glaube, Sie sollten WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE sowohl im Produktions- als auch im Staging-Slot definiert haben.

Danke @ehamai - also zurück zur ursprünglichen Frage dieses Threads: Wie lautet die Anleitung zum Festlegen von WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE in einer ARM-Vorlage, die für die anfängliche und nachfolgende Bereitstellung funktioniert? Für den Premium-Plan (nicht 100% sicher über den Verbrauchsplan, aber glaube, es ist derselbe) ist hier die Matrix dessen, was funktioniert/nicht funktioniert:

• Wenn Sie eine neue Ressource bereitstellen:
  
  
  
  • Wenn Sie keine der Einstellungen angeben, ist die Bereitstellung erfolgreich, aber der Speicher ist nicht konfiguriert. Die Meldung "Funktionsskalierung wird eingeschränkt"
  
  
  • Wenn Sie nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING angeben, schlägt dies fehl, da der erforderliche Parameter WEBSITE_CONTENTSHARE fehlt
  
  
  • Wenn Sie beide Werte angeben, funktioniert es
  
  
• wenn Sie für eine vorhandene Ressource bereitstellen
  
  
  
  • Wenn Sie keine der Einstellungen angeben, ist die Bereitstellung erfolgreich, aber der Speicher ist am Ende nicht konfiguriert, die Funktionsskalierung wird eingeschränkt
  
  
  • Wenn Sie nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING angeben, ist dies erfolgreich (und scheint danach einwandfrei zu funktionieren), obwohl WEBSITE_CONTENTSHARE erforderlich sein soll
  
  
  • Wenn Sie beide Werte angeben, "funktioniert" es insofern, als der ARM-Teil nicht fehlschlägt, aber es verursacht das Problem mit mehreren Neustarts und die obige MS-Anleitung lautet, WEBSITE_CONTENTSHARE nicht für die Updates festzulegen
  
  

Es scheint also derzeit keine Möglichkeit zu geben, eine einzige ARM-Vorlage zu haben, die für beide Szenarien funktioniert.

Hallo Elliott

Was ich zum zweiten Punkt sagen wollte, war, dass WEBSITE_CONTENTSHARE als Anwendungseinstellung definiert werden sollte, aber nicht als Einstellung für Bereitstellungsslot.
Es sollte also nicht das Häkchen wie folgt haben:

[cid:[email protected]]

Von: Elliott Hamai [email protected]
Gesendet: 22. Juni 2020 18:38
An: MicrosoftDocs/ azure -docs
Cc: Owain Winterbone (ITCS - Mitarbeiter) [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE sollte gemäß Support nicht verwendet werden (#36458)

Warnung: Diese E-Mail stammt von außerhalb des UEA-Systems. Klicken Sie nicht auf Links oder Anhänge, es sei denn, Sie erwarten diese vom Absender und wissen, dass der Inhalt sicher ist.

@OwainWin https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7C08c65f %7C0%7C637284442665654874&sdata=x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw%3D&reserved=0 - Ihre Frage verwirrt mich leider. Sie haben gefragt, ob Sie WEBSITE_CONTENTSHARE einschließen sollen oder nicht.

Ich glaube, Sie sollten WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE sowohl im Produktions- als auch im Staging-Slot definiert haben.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an 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 & reserviert = 0 oder abmelden 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&reserviert=0 .

@paulbatum

• Beim erstmaligen Anlegen der Ressource über ARM sollte WEBSITE_CONTENTSHARE gesetzt werden. Nach der erstmaligen Erstellung sollte diese Einstellung jedoch aus der ARM-Vorlage weggelassen werden (da, wenn sie enthalten ist, weitere Ausführungen der ARM-Vorlage zu unerwarteten Inhaltswechseln führen können)

Sie wissen, dass diese Art von Unterbrechung den Zweck einer ARM-Vorlage hat, oder?

Dieses Verhalten wird behoben, aber es wird wahrscheinlich 1-2 Monate dauern, bis es herauskommt. In der Zwischenzeit gilt die oben beschriebene Anleitung (in der Sie sie zunächst festlegen und dann aus der ARM-Vorlage entfernen).

Was ist die endgültige erwartete Konfiguration hier?
Können wir eine Ankündigung zu Azure/App-Service-Ankündigungen mit der richtigen Konfiguration und dem offiziellen Zeitplan erhalten, sobald dies alles tatsächlich bereitgestellt wurde?

Dies ist ein großer Blocker für uns. Wir müssen in der Lage sein, dieselbe ARM-Vorlage für die Bereitstellung in einer neuen Ressourcengruppe zu verwenden, die wir für die Bereitstellung in einer vorhandenen Ressourcengruppe verwenden würden. Wir führen unsere ARM-Vorlagen speziell im vollständigen Modus aus, um etwas mehr Kontext bereitzustellen.

Im Moment sieht unser ARM-Template ungefähr so ​​aus:

{
  "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'))]"
  ]
}

Beachten Sie die folgenden Details: Wir geben unsere Konfiguration _im Staging-Slot_ an, nicht im Produktions-Slot. Auf diese Weise können wir zunächst neue Einstellungen (und Aktualisierungen bestehender) für den Staging-Slot bereitstellen. Unsere DevOps-Pipeline tut dies also:

• Schritt 1) ​​Bereitstellen der ARM-Vorlage für die Ressourcengruppe
• Schritt 2) Stellen Sie die Funktions-App im Staging-Slot bereit
• Schritt 3) Führen Sie einige Rauchtests für den Staging-Slot durch
• Schritt 4) Vertauschen Sie die Staging- und Produktions-Slots

Das Problem ist jedoch, dass, da WEBSITE_CONTENTSHARE innerhalb der ARM-Vorlage festgelegt wird, der Produktions-Slot und der Staging-Slot sofort nach Schritt 2 die neue Version der Anwendung übernehmen (bevor ein Swap überhaupt stattfindet). Ich glaube, das ist es, wovon die Leute sprechen, wenn sie von "unbeabsichtigter Wechseloperation" sprechen.

Wir möchten _NICHT_, dass Produktions-Slot-Einstellungen in unserer ARM-Vorlage festgelegt werden, und wir möchten _NICHT_, dass irgendwelche der Produktions-Slot-Einstellungen als Ergebnis der Ausführung unserer ARM-Vorlage entfernt werden. Die Bereitstellung von ARM-Vorlagen im vollständigen Modus funktioniert so, dass alle Einstellungen, die nicht explizit angegeben sind, automatisch entfernt werden, wenn wir Einstellungen für den Produktionsslot angeben.

Ich hoffe das macht alles Sinn. Wir versuchen derzeit, WEBSITE_CONTENTSHARE aus unserem ARM-Template zu entfernen, in der Hoffnung, dass die Laufzeit den Wert in allen Szenarien generiert und nicht mehr zu "unbeabsichtigten Swaps" führt.

Hallo zusammen, ich bin der Hauptentwickler für Bereitstellungsslots und werde Ihre Bedenken bezüglich der Einstellung von WEBSITE_CONTENTSHARE und WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ansprechen:

Hier die offizielle Anleitung:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Dies sollte immer festgelegt werden, da es dem App-Dienst mitteilt, dass Sie Azure-Dateien für die Inhaltsspeicherung verwenden.

WEBSITE_CONTENTSHARE:

• Dies kann jetzt in Ihren ARM-Vorlagen für Verbrauchs-Sku-Funktionen vollständig weggelassen werden, die das Feld automatisch generieren und unbeabsichtigte Auslagerungen vermeiden. Dies bedeutet, dass Sie dieselbe Vorlage für die Erstellung und anschließende Aktualisierung verwenden können.

• Leider haben wir festgestellt, dass diese automatische Generierung von WEBSITE_CONTENTSHARE für den Elastic Premium-Ski übersehen wurde, sodass das Problem, sie während der Erstellung einschließen und bei Updates weglassen zu müssen, weiterhin besteht. Der Fix dafür wird gerade ausgerollt und hat die Hälfte unserer Flotte erreicht. Es sollte in den nächsten 2 Wochen vollständig ausgerollt werden und danach wird die Anleitung für beide skus gleich sein und WEBSITE_CONTENTSHARE kann vollständig weggelassen werden.

Ich hoffe, das löst einige Ihrer Bedenken aus!

@shubDhond Vielen Dank. Können wir ein offizielles Update zur Dokumentation erhalten?

@shubDhond für Windows-Verbrauchspläne Wenn ich nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING anbiete, erhalte ich über die Bereitstellung der Arm-Vorlage eine Fehlermeldung, die besagt, dass WEBSITE_CONTENTSHARE fehlt.
Ich brauche keine Slots. Wenn beide weggelassen werden, wird das Deployment durchgeführt, aber ich erhalte die Warnung "Speicher ist nicht konfiguriert. Funktionsaufruf wird begrenzt".

Was ist die Anleitung zu Verbrauchsplänen in Bezug auf diese beiden Parameter, die ich mit dem .net Core Windows Verbrauchsplan verwende?

Dito! Ich bekomme auch diesen Fehler. Wann wird das behoben?

Ich habe das gleiche Problem mit dem Verbrauch und dem elastischen Plan, es verursacht uns viele Probleme mit automatisierten Bereitstellungen.

Ich hatte einige Erfolge damit, WEBSITE_CONTENTSHARE für Premium wegzulassen, wenn die Einstellungen direkt in den Microsoft.Web/sites Eigenschaften (siteConfig, appSettings) bereitgestellt wurden, aber nicht, wenn die Einstellungen mit Microsoft.Web/sites/config als separate Ressource angegeben wurden. "type": "config" .

@shubDhond Dieses Problem ist definitiv nicht behoben. Wenn Sie im Windows-Verbrauchsplan eine Vorlage nur mit WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und ohne WEBSITE_CONTENTSHARE bereitstellen, erhalten Sie die Fehlermeldung "WEBSITE_CONTENTSHARE fehlt".

Der Versuch, die App Service-Bereitstellungsaufgaben in Azure DevOps zu verwenden und nur den WEBSITE_CONTENTAZUREFILECONNECTIONSTRING festzulegen, führt ebenfalls zu einem HTTP 400-Fehler.

Die Automatisierung von Azure Function-Apps im Verbrauchsplan ist derzeit völlig kaputt.

Habe das gleiche Problem wie

Wir haben auch das gleiche Problem wie @clawrenceks.
Wir können auch nicht nur WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ohne WEBSITE_CONTENTSHARE über das Azure-Portal festlegen. Wir haben auch WEBSITE_RUN_FROM_PACKAGE auf 1 gesetzt.

Ich bin mir auch nicht sicher, wie dies funktioniert, wenn Sie den Bereitstellungsmodus Ihrer ARM-Vorlage auf Complete . Wird die generierte App-Einstellung WEBSITE_CONTENTSHARE ?

Wie die meisten sind auch wir verloren.

Ich habe jetzt meine ARM-Vorlage, die meine Funktions-App erfolgreich in einem Windows-Verbrauchsplan bereitstellt. Bei der Bereitstellung wird die Meldung Storage is not configured, Function scaling will be limited. Click to learn more nicht mehr angezeigt. Slot-Swaps funktionieren auch wie erwartet.

Meine wichtigsten Erkenntnisse aus diesem Prozess sind:

Wenn Sie derzeit über eine Azure Function-App OHNE die Anwendungseinstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE verfügen, können Sie dies meiner Meinung nach nur beheben, indem Sie Ihre App erneut bereitstellen und sicherstellen, dass die WEBSITE_CONTENTAZUREFILECONNECTIONSTRING -Einstellung wird als Teil der App-Diensterstellung verwendet.

Es ist wichtig, dass WEBSITE_CONTENTAZUREFILECONNECTIONSTRING als Teil der Ressourcenerstellung vorhanden ist. Bei der Verwendung von ARM habe ich festgestellt, dass es während der Bereitstellung des Haupt-App-Diensts als App-Einstellung mit einem Ressourcentyp von Microsoft.Web/sites bereitgestellt werden muss. Ein separater Ressourcentyp von Microsoft.Web/sites/config in Ihrer ARM-Vorlage zum Bereitstellen der Anwendungseinstellungen funktioniert nicht.

Ich füge die Einstellung WEBSITE_CONTENTSHARE in meine ARM-Vorlage ein. Dies wird von der Laufzeit erstellt, wenn meine ARM-Vorlage bereitgestellt wird. Dies ist ein Zeichen dafür, dass die Bereitstellung gut funktioniert. Mit dem hier beschriebenen Ansatz kann ich die anfänglichen Ressourcen bereitstellen und die Vorlage dann mehrmals erneut bereitstellen, ohne Fehler im Zusammenhang mit der Einstellung WEBSITE_CONTENTSHARE .

Eine weitere wichtige Anforderung für mich war, dass die Anwendungseinstellungen des Produktionsstandorts nur während der anfänglichen Ressourcenerstellung bereitgestellt werden sollten. Die einzige Möglichkeit, neue (zukünftige) Anwendungseinstellungen in die Produktionsumgebung zu bekommen, ist über einen Slot-Swap. Um dies zu erreichen, habe ich meiner ARM-Vorlage einige Logik hinzugefügt, um Folgendes zu handhaben.

1) App-Einstellungen in der ARM-Vorlage werden nur während der ersten Site-Erstellung auf der Produktions-Site bereitgestellt, sie werden der Produktions-Site bei zukünftigen Bereitstellungen nicht hinzugefügt.

2) App-Einstellungen in der ARM-Vorlage werden immer auf den Staging-Slot angewendet. Sie werden dann über einen Swap-Slot in die Produktion getauscht.

Um das oben Genannte zu erreichen, sind die appSettings für die Produktionssite in meiner ARM-Vorlage bedingt. Wenn die Ressource nicht vorhanden ist, stelle ich den vollständigen Satz der App-Einstellungen in der Vorlage bereit (um sicherzustellen, dass der App-Dienst korrekt erstellt wird). Wenn die Ressource bereits erstellt wurde, übergebe ich eine Null für die App-Einstellungen. Bei der Bereitstellung bleiben die App-Einstellungen erhalten, die bereits für den Produktionsstandort vorhanden sind.

Ich bin auch total verwirrt. Wenn WEBSITE_CONTENTAZUREFILECONNECTIONSTRING für Verbrauchspläne erforderlich ist, aber nicht für die Beibehaltung eines Slots konfiguriert werden kann, wie soll ich dann zwischen einem Staging- und einem Produktionsslot wechseln, bei dem jeder auf einem anderen Speicherkonto ausgeführt werden soll? Dies war mit Web Apps schon immer möglich und scheint ein sehr häufiger Anwendungsfall zu sein. Soweit ich das beurteilen kann, ist das Tauschen von Funktions-App-Slots vollständig defekt / unbrauchbar, bis dies behoben ist. Würde mich freuen, wenn mir jemand sagen würde, warum / wie ich falsch liege! Ich weiß, dass das ursprüngliche Problem auf ARM-Vorlagen verweist, aber dies scheint ein viel umfassenderes Problem zu sein.

Gleiches Problem beim Elastic Premium-Plan. Wenn Sie dieselbe ARM-Vorlage mit demselben WEBSITE_CONTENTSHARE bereitstellen, wird der Produktionsslot auf dieselben Binärdateien wie der Bereitstellungsslot verweisen.
Kann ohne WEBSITE_CONTENTSHARE überhaupt nicht bereitgestellt werden, da ich den 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest' Fehler erhalte

Ich bin verwirrt. Was ist das Richtige?

Wenn Sie mit elastischer Prämie oder Verbrauch arbeiten, müssen Sie eines der folgenden Kriterien erfüllen:

Sie müssen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE definiert haben

oder

Wenn Sie Run from zip/package verwenden, müssen Sie "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" oder "WEBSITE_RUN_FROM_PACKAGE" auf einen anderen Wert als leer, 0 oder 1 setzen

wie @ehmai sagt?

oder

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Dies sollte immer festgelegt werden, da es dem App-Dienst mitteilt, dass Sie Azure-Dateien für die Inhaltsspeicherung verwenden.

WEBSITE_CONTENTSHARE:

Dies kann jetzt in Ihren ARM-Vorlagen für Verbrauchs-Sku-Funktionen vollständig weggelassen werden, die das Feld automatisch generieren und unbeabsichtigte Auslagerungen vermeiden. Dies bedeutet, dass Sie dieselbe Vorlage für die Erstellung und anschließende Aktualisierung verwenden können.

Leider haben wir festgestellt, dass diese automatische Generierung von WEBSITE_CONTENTSHARE für den Elastic Premium-Ski übersehen wurde, sodass das Problem, sie während der Erstellung einschließen und bei Updates weglassen zu müssen, weiterhin besteht. Der Fix dafür wird gerade ausgerollt und hat die Hälfte unserer Flotte erreicht. Es sollte in den nächsten 2 Wochen vollständig ausgerollt werden und danach wird die Anleitung für beide skus gleich sein und WEBSITE_CONTENTSHARE kann vollständig weggelassen werden.

Ich hoffe, das löst einige Ihrer Bedenken aus!

wie @shubDhond sagt?

Ich erhalte eine Fehlermeldung, wenn ich eine Azure-Funktion im Verbrauchsplan ohne WEBSITE_CONTENTSHARE (eigentlich hat der Produktionsslot überhaupt keine Appsettings) auf einem der Slots habe und ich:

1. Bereitstellen von ARM im Staging-Slot
2. Tauschen
3. erneut auf Staging-Slot bereitstellen

Dann sagt es mir, dass ich die WEBSITE_CONTENTSHARE brauche. Es ist, als ob es keinen Anteil für den alten Produktionsslot generieren kann. Ich habe nicht versucht, den WEBSITE_CONTENTAZUREFILECONNECTIONSTRING zu entfernen, weil dieser Thread sagt, dass ich es nicht tun soll, außer @ehamai , das mir sagt, dass ich es tun kann, wenn ich ein "WEBSITE_RUN_FROM_PACKAGE" mache.

Das Lustige ist, dass ich eine Funktion mit diesem Setup habe, aber mit einer Laufzeit von ~2 anstelle von ~3, und sie funktioniert. Gibt es ein Problem mit ~3 und Bereitstellungsslots?
Das ist sehr verwirrend.

Egal, was dieser spontane Slots-Tausch ist, ist sehr beängstigend, da wir diese beiden WEBSITE_ Variablen erstellen müssen, füllen wir ARM auch die letzteren per Definition hier aus . Das Diagnosetool für die Webapp-Konfiguration auf dem Portal zeigt keinen Fehler mehr an.

neu zuweisen: @mattenderson

Gibt es hierzu Neuigkeiten?

Auch wir wurden vom Microsoft-Support darauf hingewiesen, dass die Eigenschaft "WEBSITE_CONTENTSHARE" gesetzt werden muss. Wenn es nicht möglich ist, es als Slot-Einstellung festzulegen, ist dies für unsere Build-Pipelines und ARM-Vorlagen ziemlich problematisch. Bitte um Rat!

Ich stimme auch zu. Es ist wirklich Zeit für einige Erklärungen zur Verwendung von Slots hier!

Ich stimme auch zu, dieser Thread wurde vor über 15 Monaten gestartet und es gibt immer noch keine stabile Auflösung.
Wir können keine Slots verwenden, bis dies mit einer vertrauenswürdigen Lösung richtig gelöst wurde. Slots sind eine fantastische Funktion, aber sie müssen zuverlässig sein.

Hallo zusammen,

Entschuldigung für die Verzögerung der Antwort hier, dieser Thread wurde nicht so überwacht, wie es hätte sein sollen.

Um die Verwirrung zu beseitigen, ist das von sofort korrekt. Für Websites, auf denen der Azure Files-Speicher noch nicht konfiguriert ist, müssen Sie sowohl WEBSITE_CONTENTAZUREFILECONNECTIONSTRING als auch WEBSITE_CONTENTSHARE angeben. Nachdem diese bereitgestellt wurden und Ihre App nun für die Ausführung in Azure Files konfiguriert ist, können Sie WEBSITE_CONTENTSHARE danach aus Ihren Vorlagen weglassen, um ein versehentliches Austauschen Ihrer Inhalte zu vermeiden.

Die API funktioniert derzeit so, dass bei der Websiteerstellung (Ressource "Microsoft.Web/sites"), wenn Sie WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und nicht WEBSITE_CONTENTSHARE angeben, eine Inhaltsfreigabe für Sie generiert wird. Bei Aktualisierungen einer vorhandenen Ressource „Microsoft.Web/sites“ oder einer Ressource „Microsoft.Web/sites/config“ prüft die API jedoch, ob bereits ein Wert für WEBSITE_CONTENTSHARE für die App vorhanden ist und ob dieser nicht vorhanden ist , es wirft einen Fehler.

Ich nehme an, dies diente dem Schutz davor, dass Kunden versehentlich ihre Inhalte löschen, während sie zu Azure-Dateien wechseln, falls sie WEBSITE_CONTENTAZUREFILECONNECTIONSTRING bereitstellen und wir eine neue WEBSITE_CONTENTSHARE für sie generieren (im Wesentlichen ihre Inhalte löschen, da diese Freigabe neu wäre). Dies ist während der Site-Erstellung viel sicherer, da die Site sowieso bei Null beginnen würde und wir nicht riskieren, Ihren Inhalt zu löschen.

Ich kann die Verwirrung jedoch für Sie alle, die Dateien azurieren möchten, völlig verstehen. Ich muss mir überlegen, wie ich dies am besten angehen kann und gleichzeitig unsere Aktualisierungsvorgänge vor dem Löschen Ihrer Inhalte schützen. Die Anleitung für Sie alle, die keine Azure-Dateien konfiguriert haben und den Wechsel vornehmen möchten, müssen sowohl WEBSITE_CONTENTAZUREFILECONNECTIONSTRING als auch WEBSITE_CONTENTSHARE für den ersten Wechsel angeben Vorlage danach.

Wenn Sie Vorschläge haben, wie Sie den Update-Fall behandeln möchten, würden wir uns darüber sehr freuen!

@shubDhond, also müssen wir beim ersten Deployment im Produktionsslot die Verbindungszeichenfolge und contentshare appsettings bereitstellen, aber nicht bei den Deployments danach. Gibt es eine Möglichkeit das automatisch zu machen? Wie zum Beispiel erkennen, ob eine Ressource über ARM bereitgestellt wurde? Oder müssen wir diese Informationen manuell an den ARM übergeben (fx über einen Parameter, der angibt, ob dies die erste Bereitstellung ist?

@mslot Leider glaube ich nicht, dass es innerhalb einer Vorlage möglich ist zu sagen, ob eine Ressource bereits vorhanden ist oder nicht, aber dies sollte damit möglich sein (https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) kombiniert mit einem an die Vorlage übergebenen Parameter, der angibt, ob die Site bereits für Azure Files konfiguriert ist. Dies kann festgestellt werden, indem Sie die Site abrufen und prüfen, ob die App-Einstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE aufweisen.

@mslot Leider glaube ich nicht, dass es innerhalb einer Vorlage möglich ist zu sagen, ob eine Ressource bereits vorhanden ist oder nicht, aber dies sollte damit möglich sein (https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) kombiniert mit einem an die Vorlage übergebenen Parameter, der angibt, ob die Site bereits für Azure Files konfiguriert ist. Dies kann festgestellt werden, indem Sie die Site abrufen und prüfen, ob die App-Einstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE aufweisen.

Ich hoffe sehr, dass das bald behoben wird. Es macht die Verwendung von Slots in meinem Workflow nutzlos. Es muss vollautomatisiert sein. Diese Lösung ist in meinen Augen ein Hack-Workaround und es macht keinen Sinn, sie einzuführen, wenn sie für Webapps funktioniert, da sie zu stark von etwas abweicht, das genauso funktionieren sollte und "schwarze Magie" für andere einführt, die an einem Projekt teilnehmen.

Ich hoffe wirklich, dass dies behoben wird, damit wir es verwenden können. Ich denke, es hält viele Leute davon ab, diese Funktion zu verwenden.

@mslot Ich verstehe Ihren Schmerz vollkommen und es tut mir leid, dass wir dieses Problem nicht früher identifizieren konnten. Ich werde in der kommenden Woche mit den Entwicklern sprechen, die dieses Verhalten ursprünglich implementiert haben, und sehen, ob wir eine sichere Lösung für dieses Problem finden können, die verhindern könnte, dass Kunden versehentlich auf eine leere azurblaue Dateifreigabe für ihre Inhalte umsteigen. Sobald wir einen Lösungsvorschlag haben, werde ich hier aktualisieren.

@shubDhond Ich verstehe den "Teil" von Azure Files nicht wirklich. Ich stelle mein Azure Function-Projekt mithilfe von Azure DevOps bereit, indem ich zuerst einen Bereitstellungsslot erstelle, diesen bereitstelle und dann tausche. Ich verwende die Bereitstellungsmethode "RunFromPackage" und dies scheint bei Verwendung eines klassischen StorageAccounts nicht zu funktionieren. Ich verwende NICHT Azure Files und scheine das gleiche Problem im Zusammenhang mit der Einstellung WEBSITES_CONTENTSHARE für die beiden Slots zu haben.

Hallo @cannehag könntest du bitte eine neue Ausgabe dafür eröffnen? Es kann zu einem seltsamen Verhalten kommen, wenn die RunFromPackage-App-Einstellung als klebrig markiert ist und ähnliche Symptome wie hier beschrieben verursacht. Ich würde ein neues Problem vorschlagen, damit wir hier keine Verwirrung hinzufügen, da die Probleme wahrscheinlich nicht zusammenhängen.