@danielstocker Muchas gracias por informarnos sobre esto. Tengo esto asignado al líder del servicio para que se investigue más a fondo y lo actualizaré cuando tengamos mayor claridad.

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

Gracias por mirar en esto.

¿Necesita más información para avanzar en esto?

@danielstocker, ¿ puede proporcionar más antecedentes sobre cuál fue su problema original que lo llevó a este descubrimiento? No estoy seguro de comprender correctamente la implicación de configurarlo incorrectamente (lo que mencionó como unintentional swap )

Hola @ ggirard07 ,

No hay problema. Permítanme resumir.
Esto surgió inicialmente porque nuestra documentación indica que se requiere WEBSITE_CONTENTSHARE. (ver aquí: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

Si exportamos una plantilla de Funciones desde Marketplace (plantilla de exportación en la última página) obtenemos WEBSITE_CONTENTSHARE como configuración estándar de la aplicación. Si usamos esto, entonces puede suceder la siguiente situación.

1) Implementamos una plantilla ARM y obtenemos una función vacía con dos ranuras
2) Desplegamos a la ranura de ensayo
3) Intercambiamos para que el contenido esté disponible en producción
4) INTERCAMBIO INESPERADO cuando se vuelve a implementar la plantilla ARM y se vuelve a aplicar la configuración de la aplicación (esto incluso ocurre durante una implementación de ARM incremental ya que el recurso de configuración de la aplicación siempre sobrescribe y restablece la configuración WEBSITE_CONTENTSHARE)
5) La rutina de implementación ahora implementa el nuevo código en la ranura de prueba y nuestra ranura de producción está vacía en lugar de contener la versión anterior. Nuestra función de producción está inactiva "involuntariamente"

El cliente en este caso particular luego señaló este artículo https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

Esto sugiere que la configuración debe establecerse como una configuración de ranura para corregir el comportamiento. Si bien esto corrige el comportamiento en mis pruebas, parece incorrecto, porque no debería funcionar.

A continuación se muestra una tabla de lo que sucedió en mis pruebas. (después de convertirlo en un ajuste de ranura)

Mi percepción (y la del cliente) es que las tragamonedas ya no deberían intercambiarse, pero como se describe en el artículo, todavía funciona de todos modos.

También planteé esto internamente y la gente encontró un comportamiento inconsistente al cambiar la configuración de la aplicación. (De ahí por qué esto está resaltado en mi cuadrícula de prueba) Para un colega que lo probó, actualizando la configuración de la aplicación, hizo que la configuración de la ranura se volviera a aplicar, lo que nuevamente provocó un cambio no intencional.

Esto finalmente (perdón por la larga respuesta) me llevó a plantear el caso de soporte en el que el resultado fue "simplemente no establezca la configuración en absoluto".
Mis pruebas personales mostraron que esto soluciona el problema, pero no hay una guía en la documentación para confirmar esto, por eso planteé este tema.

Espero que esto ayude.
Avísame si algo no está claro.

@danielstocker definitivamente es una información importante, especialmente para comprender cómo funcionan las ranuras y el intercambio de funciones frente a una aplicación web tradicional con trabajos web.
Además, esto tampoco se explica en la documentación de las una captura de pantalla en el paso 4 que lo representa, donde esos valores se truncan para que las cosas sean aún más claras ...

Hola @ ggirard07 y gracias por leer mi diatriba. Entonces, ¿cuál es el camino a seguir desde aquí? :)

@ ggirard07 @ ggailey777 @ mike-urnun-msft

¿Se requiere más información para crear cierta claridad en la documentación sobre este comportamiento? Estoy trabajando con un cliente que está considerando dejar de usar las ranuras de funciones porque no está seguro de la guía oficial sobre este escenario.

Gracias por tu ayuda

@danielstocker Solo para tener claro lo que crees que abordará los problemas de documentación relacionados con esto:

• Elimine la configuración de implementación WEBSITE_CONTENTSHARE de aquí .
• Agregue una nota en el artículo de referencia de que WEBSITE_CONTENTSHARE solo debe ser establecido por el tiempo de ejecución.

¿Crees que sería suficiente?

cc. @mattchenderson

Hola @ ggailey777
Sí, creo que sería una buena solución.

¿No es WEBSITE_CONTENTSHARE una de las aplicaciones requeridas al implementar una aplicación de función usando ARM?

¿No es WEBSITE_CONTENTSHARE una de las aplicaciones requeridas al implementar una aplicación de función usando ARM?

Si no se aplica, creo que el tiempo de ejecución generará uno para usted.

Implementé un ARM con un plan de consumo y una aplicación de función con una sección _Microsoft.Web / sites / config_ llamada appsettings y las siguientes propiedades

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

La implementación devolvió el siguiente error:

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

Después de que _también_ eliminé el parámetro WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, la implementación se realizó sin errores. Entonces, parece haber alguna relación requerida entre esos dos ajustes.
Aunque tuvo éxito, esta implementación me hizo vagar si y dónde se implementan físicamente las funciones (paquetes) (y si este caso es válido en primer lugar).

Hemos estado viendo el comportamiento exacto que ha descrito

Nuestras aplicaciones de función también incluyen una función activada por temporizador, por lo que especificamos la configuración AzureWebJobsStorage como se sugiere : habríamos adivinado / esperado que el tiempo de ejecución hubiera usado esa misma cadena de conexión para el (ahora implícito) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , pero ese no es el caso: en la cuenta de almacenamiento que especificamos allí, vemos los contenedores de blob azure-webjobs-hosts y azure-webjobs-secrets , pero no hay recursos compartidos de archivos presentes.

He revisado Kudu en busca de pistas y parece que todos los archivos que deben estar allí están en el sistema de archivos (donde sea que esté, marcado en app-name.scm.azurewebsites.net/api/vfs/ ), pero no hay referencia a ninguna de las configuraciones ( WEBSITE_CONTENTSHARE o WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ) se verá en la pestaña de entorno ( appname.scm.azurewebsites.net/Env.cshtml ).

Quizás sea importante mencionar que nuestras aplicaciones están configuradas con WEBSITE_ENABLE_SYNC_UPDATE_SITE=True y WEBSITE_RUN_FROM_PACKAGE=1 .
Las aplicaciones parecen funcionar, pero realmente nos gustaría tener algo de claridad en este punto, ya que estamos portando un servicio comercial principal a Azure Functions y queremos resolverlo antes de implementarlo en producción.

Siguiendo algunos consejos, habíamos establecido WEBSITE_CONTENTSHARE como configuración de espacio para asegurarnos de que los valores fueran distintos entre nuestros espacios de producción y de preparación. Hoy, la plantilla ARM que usamos comenzó a fallar con 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (aunque confirmé que de hecho está configurada como una configuración de espacio en el portal actualmente). ¿Cambió algo en torno a este comportamiento?

Hemos notado este mismo problema en los últimos días y necesitamos orientación sobre cómo proceder. También hemos estado siguiendo el enfoque de configurar WEBSITE_CONTENTSHARE como una configuración de ranura para solucionar el problema de intercambio involuntario, pero ahora no podemos implementar debido a este error. He intentado eliminar retroactivamente tanto esto como la configuración de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING para avanzar hacia lo que parece ser el enfoque recomendado de no usar ninguno, pero estas implementaciones también fallarían.

Siguiendo algunos consejos, habíamos establecido WEBSITE_CONTENTSHARE como configuración de espacio para asegurarnos de que los valores fueran distintos entre nuestros espacios de producción y de preparación. Hoy, la plantilla ARM que usamos comenzó a fallar con 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (aunque confirmé que de hecho está configurada como una configuración de espacio en el portal actualmente). ¿Cambió algo en torno a este comportamiento?

Elimínelo y deje que el tiempo de ejecución elija un nombre. Así es como lo hago.

@jeffhollan, ¿puedes darnos algo de claridad?

Esto dice que WEBSITE_CONTENTSHARE y WEBSITE_CONTENTAZUREFILECONNECTIONSTRING son _required_: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

Los comentaristas aquí piensan que _no_ son obligatorios; ARM cree que son necesarios ?; El soporte técnico de Azure cree que WEBSITE_CONTENTSHARE rompe los escenarios de tragamonedas.

Terminamos verificando el código del host de funciones de Azure y parece que , cuando se ejecuta desde el paquete, la configuración WEBSITE_CONTENTAZUREFILECONNECTIONSTRING no se usa .
Lo verificamos eliminando de nuestra plantilla ARM tanto WEBSITE_CONTENTAZUREFILECONNECTIONSTRING como WEBSITE_CONTENTSHARE y obtuvimos buenos resultados: nuestras aplicaciones de función no tienen esas dos configuraciones en absoluto (ni siquiera asignadas por el tiempo de ejecución) y no utilice archivos compartidos en ninguna cuenta de almacenamiento (al menos eso podemos ver).

Entonces, una cosa a tener en cuenta es que el sistema de archivos para una aplicación web / aplicación de función se parece a esto:

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

Cuando usa ejecutar desde paquete, eso solo reemplaza la carpeta wwwroot en este árbol. Todo lo demás lo proporciona el sistema de archivos principal. Si crea una aplicación de función premium elástica o de consumo sin WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, el sistema de archivos principal no está disponible fuera de la unidad de báscula en la que se creó la aplicación de función. Esta no es una configuración admitida / recomendada. Significa que su aplicación de funciones puede no escalar más allá de los límites de la unidad de escala en la que fue creada, o si lo hace, no podrá confiar en que el estado del sistema de archivos fuera de wwwroot se mantenga consistente.

La guía más reciente que he visto del desarrollador que posee la forma en que WEBSITE_CONTENTSHARE interactúa con las tragamonedas es la siguiente:

• WEBSITE_CONTENTSHARE NO debe ser una configuración de espacio. Un cambio de API que bloquea esto se está implementando en el momento de escribir este artículo.
• En la creación inicial del recurso a través de ARM, se debe configurar WEBSITE_CONTENTSHARE. Sin embargo, después de la creación inicial, esta configuración debe omitirse de la plantilla ARM (porque si se incluyó, las ejecuciones posteriores de la plantilla ARM podrían causar intercambios de contenido inesperados)

Siguiendo mi comentario anterior ... También descubrí que el sistema actualmente tiene un comportamiento inconsistente con respecto a la generación de WEBSITE_CONTENTSHARE, por lo que ni siquiera es necesario especificarlo inicialmente. Algunos de ustedes han dicho que no es necesario que lo especifiquen, mientras que otros reciben un error que dice que es obligatorio. Por lo que puedo decir, este comportamiento funciona correctamente para el consumo (es decir, una plantilla ARM para consumo no necesita esta configuración inicialmente) pero no ocurre lo mismo con la prima elástica. Ese comportamiento se está arreglando, pero probablemente tardará entre 1 y 2 meses en salir. Entonces, mientras tanto, la guía que compartí anteriormente (donde la configura inicialmente y luego la elimina de la plantilla ARM) es aplicable.

@paulbatum

• En la creación inicial del recurso a través de ARM, se debe configurar WEBSITE_CONTENTSHARE. Sin embargo, después de la creación inicial, esta configuración debe omitirse de la plantilla ARM (porque si se incluyó, las ejecuciones posteriores de la plantilla ARM podrían causar intercambios de contenido inesperados)

Te das cuenta de que este tipo de ruptura es el propósito de una plantilla ARM, ¿verdad?

Ese comportamiento se está arreglando, pero probablemente tardará entre 1 y 2 meses en salir. Entonces, mientras tanto, la guía que compartí anteriormente (donde la configura inicialmente y luego la elimina de la plantilla ARM) es aplicable.

¿Cuál es la configuración final esperada aquí?
¿Podemos recibir un anuncio en Azure / app-service-anuncios con la configuración adecuada y el cronograma oficial una vez que todo esto esté realmente implementado?

Hola, no estoy seguro de si ha habido algún avance en esto. Todavía estoy luchando por usar plantillas ARM con la bandera WEBSITE_CONTENTSHARE. @paulbatum ¿cómo puedo omitir una configuración de la plantilla ARM? Tuve que deshabilitar completamente el paso para que funcionara.

@gustavobmichel Lo siento, no entiendo tu pregunta. La plantilla ARM es JSON, edítela según sea necesario. Aparece como parte de la sección de configuración de la aplicación, por ejemplo:

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

Hola @paulbatum , gracias por volver a mí. Pensé que habías mencionado sobre la omisión programática de la configuración de la plantilla JSON, así que esa era mi pregunta.

Como otros dijeron, también pensé que estas dos configuraciones eran necesarias, por lo que eliminé las dos de mi plantilla ARM.

Para probar esta función con tiempo de inactividad cero, creé una prueba simple con la infraestructura mínima para probarla. Eliminé todos los recursos de mi grupo de recursos y ejecuté la plantilla ARM como parte del proceso de lanzamiento para crear los recursos sin WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE y WEBSITE_RUN_FROM_PACKAGE.

Ejecuté un par de pruebas y todavía funciona bien con el plan de consumo. Haré algunas pruebas esta semana con el nivel premium.

También agregué esta configuración WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG a 1 según este enlace: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

He adjuntado mi plantilla ARM de prueba como referencia.
azuredeploy.txt

Hola @paulbatum , gracias por volver a mí. Pensé que habías mencionado sobre la omisión programática de la configuración de la plantilla JSON, así que esa era mi pregunta.

Como otros dijeron, también pensé que estas dos configuraciones eran necesarias, por lo que eliminé las dos de mi plantilla ARM.

Para probar esta función con tiempo de inactividad cero, creé una prueba simple con la infraestructura mínima para probarla. Eliminé todos los recursos de mi grupo de recursos y ejecuté la plantilla ARM como parte del proceso de lanzamiento para crear los recursos sin WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE y WEBSITE_RUN_FROM_PACKAGE.

Ejecuté un par de pruebas y todavía funciona bien con el plan de consumo. Haré algunas pruebas esta semana con el nivel premium.

También agregué esta configuración WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG a 1 según este enlace: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

He adjuntado mi plantilla ARM de prueba como referencia.
azuredeploy.txt

Dejando de lado WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, ¿cómo sabe su función de dónde obtener el código de la aplicación?

Si ayuda, nos hemos decidido por:

• configurando WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en la cuenta de almacenamiento desde la que queremos que se ejecute el código
• no especificar WEBSITE_CONTENTSHARE en absoluto en la plantilla del brazo (permitir que se genere automáticamente para ambas ranuras)
• WEBSITE_RUN_FROM_PACKAGE = 1

Hice muchas pruebas en torno a estos y esta me pareció la mejor configuración para evitar la activación de intercambios involuntarios y saber dónde estaba el código, etc. Tampoco requiere administrar estas configuraciones fuera de la plantilla ARM, lo que no me gustó la idea de (parece que no tiene mucho sentido usar plantillas ARM en ese momento).

La implementación también parece funcionar sin especificar un valor WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en absoluto, pero como se mencionó, no pudimos averiguar dónde estaba el código y el tipo de soporte de MS que maneja mi ticket parecía sugerir que esto era un error y no debería permitirse por la plataforma.

Si ayuda, nos hemos decidido por:

• configurando WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en la cuenta de almacenamiento desde la que queremos que se ejecute el código
• no especificar WEBSITE_CONTENTSHARE en absoluto en la plantilla del brazo (permitir que se genere automáticamente para ambas ranuras)
• WEBSITE_RUN_FROM_PACKAGE = 1

Hice muchas pruebas en torno a estos y esta me pareció la mejor configuración para evitar la activación de intercambios involuntarios y saber dónde estaba el código, etc. Tampoco requiere administrar estas configuraciones fuera de la plantilla ARM, lo que no me gustó la idea de (parece que no tiene mucho sentido usar plantillas ARM en ese momento).

La implementación también parece funcionar sin especificar un valor WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en absoluto, pero como se mencionó, no pudimos averiguar dónde estaba el código y el tipo de soporte de MS que maneja mi ticket parecía sugerir que esto era un error y no debería permitirse por la plataforma.

Esto es exactamente lo que también descubrí. Gracias por confirmar.

Mi función tiene problemas para acceder al almacenamiento después de agregar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_RUN_FROM_PACKAGE. ¿Ustedes agregaron estas dos configuraciones tanto a la aplicación funcional como a la ranura?

El error exacto es: Azure Functions Runtime es inalcanzable.

Eso es después de que hago la primera implementación y luego intento implementar una nueva versión.

También agregué mi archivo yml.
yml file.txt
deploy.txt

También actualicé mi plantilla ARM.

Mi función tiene problemas para acceder al almacenamiento después de agregar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_RUN_FROM_PACKAGE. ¿Ustedes agregaron estas dos configuraciones tanto a la aplicación funcional como a la ranura?

El error exacto es: Azure Functions Runtime es inalcanzable.

Eso es después de que hago la primera implementación y luego intento implementar una nueva versión.

También agregué mi archivo yml.
yml file.txt
deploy.txt

También actualicé mi plantilla ARM.

Lo tengo en ambos. En realidad, no tengo nada en mi espacio de producción y lo cambio todo desde la puesta en escena. He visto esto al definir un WEBSITE_CONTENTSHARE o al no apuntar a la cuenta de almacenamiento correcta donde reside el código con WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. No debe apuntar nada a ninguna parte con WEBSITE_CONTENTSHARE. De hecho, creo que vi ese error al que se refiere porque agrega un WEBSITE_CONTENTSHARE a las variables de entorno. Asegúrate de no tenerlo definido.

Hola @mslot , creo que el problema estaba en mi implementación. Lo estaba configurando en zipDeploy porque leí en este hilo https://stackoverflow.com/a/56205917 sobre cómo configurarlo en Azure DevOps. Después de que lo cambié a la implementación estándar, todo parece estar funcionando. Gracias por tu ayuda.

Ese comportamiento se está arreglando, pero probablemente tardará entre 1 y 2 meses en salir.

¿Alguna actualización sobre este tema? ¿El comportamiento de consumo y prima ahora está alineado? ¿Podemos omitir WEBSITE_CONTENTSHARE de la implementación inicial de ARM y las implementaciones posteriores? ¿Cómo afecta esto a los espacios de preparación? ¿Algún documento actualizado para vincular u orientación?

Básicamente, nos hemos decidido por el mismo enfoque que @thomaswilkin y @mslot, pero solo a través de la experimentación y el ensayo y error. Aún no estoy seguro de cómo el tiempo de ejecución sabe dónde encontrar nuestros archivos, ya que WEBSITE_CONTENTSHARE no está configurado.

Hola. No estoy seguro de cómo pueden hacerlo, pero parece que no puedo implementar con
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sin WEBSITE_CONTENTSHARE. Incluso a través del portal, me dio un error al intentar establecer la configuración;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

En la página de descripción general de la aplicación de funciones, también veo este mensaje de advertencia: Storage is not configured, Function scaling will be limited. Click to learn more. Estoy ejecutando un plan premium. ¿Alguna actualización o pauta oficial sobre cómo debemos configurar nuestras aplicaciones de función?

Para el plan Premium (no estoy 100% seguro sobre el plan de consumo), aquí está la matriz de lo que funciona / no funciona:

• si implementa un nuevo recurso:
  
  
  
  • si no proporciona ninguna configuración, la implementación se realiza correctamente, pero termina con el mensaje Storage is not configured, Function scaling will be limited
  
  
  • si solo proporciona WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , falla con Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • si proporciona ambos valores, funciona
  
  
• si implementa en un recurso existente
  
  
  
  • si no proporciona ninguna configuración, la implementación se realiza correctamente, pero termina con el mensaje Storage is not configured, Function scaling will be limited
  
  
  • si solo proporciona WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , tiene éxito (y parece funcionar bien después) aunque se supone que se requiere WEBSITE_CONTENTSHARE
  
  
  • si proporciona ambos valores, 'funciona' porque la parte ARM no falla, pero causa el problema de reinicio múltiple y la guía de MS anterior es no configurar WEBSITE_CONTENTSHARE en las actualizaciones
  
  

Por lo tanto, no parece haber una forma de tener una sola plantilla ARM que funcione para ambos escenarios en este momento.

También veo este mensaje de advertencia: Storage is not configured, Function scaling will be limited. Click to learn more . Havent tenía el sitio web WEBSITE_CONTENTAZUREFILECONNECTIONSTRING o WEBSITE_CONTENTSHARE. Tal como lo menciona Korkiak, ¿alguna pauta actualizada u oficial?

Recientemente, comenzamos a ver el mensaje "El almacenamiento no está configurado, el escalado de funciones será limitado. Haga clic para obtener más información" en el Portal de Azure para las funciones de Azure existentes que se implementaron hace cuatro semanas. Nunca hemos utilizado WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ni WEBSITE_CONTENTSHARE y eso ha funcionado bien hasta ahora.

@paulbatum Parece que este problema está recibiendo más actividad en los últimos días ya que el mensaje 'El almacenamiento no está configurado, el escalado de funciones será limitado' comenzó a aparecer en el portal. ¿Alguna nueva orientación sobre la forma correcta de configurar todo esto?

Me acabo de encontrar que 'WEBSITE_CONTENTSHARE' no puede ser un error de configuración de ranura como se mencionó anteriormente al implementar una nueva aplicación de función por primera vez en varios meses usando una plantilla que ha funcionado bien antes.
La plantilla tiene 'WEBSITE_CONTENTSHARE' como una configuración de espacio y se define tanto en la aplicación de función como en la configuración de la aplicación de espacio de implementación según el siguiente artículo que también se mencionó anteriormente:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
La lectura de este hilo eliminó esto como una configuración de ranura y probé varias combinaciones de configuración 'WEBSITE_CONTENTSHARE' y no obtengo el mismo comportamiento que los demás. Puedo implementar sin errores como se muestra a continuación:

• Especifique 'WEBSITE_CONTENTSHARE' tanto para la aplicación de función como para la ranura de implementación
• Especifique 'WEBSITE_CONTENTSHARE' solo para la aplicación de función

Si no especifico 'WEBSITE_CONTENTSHARE' en la plantilla, aparece el error "Falta el parámetro obligatorio WEBSITE_CONTENTSHARE".

Entonces, por favor, ¿podemos tener una actualización sobre cuál debería ser la configuración real, ya que no puedo implementar en producción con este comportamiento actual?

Hola a todos, perdón por toda la confusión aquí. Intentamos ser inteligentes al hacer que el Portal de Azure le diga cuándo puede tener problemas de escalado con su configuración, pero equivocamos la lógica y ahora la gente puede ver la advertencia de forma incorrecta. Estamos trabajando en una solución, pero mientras tanto, aquí le mostramos cómo validar si puede tener problemas de escalado con su aplicación o no:

Si utiliza la prima elástica o el consumo, debe cumplir uno de los siguientes criterios:

1. Debe tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos

o

1. Si utiliza ejecutar desde zip / paquete, debe tener "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" o "WEBSITE_RUN_FROM_PACKAGE" configurado en un valor distinto de vacío, 0 o 1

Deberíamos tener una solución para esto la próxima semana en algún momento.

Gracias @ehamai , por el n. ° 2 cuando dices 'establecer en algo que no sea vacío, 0 o 1', ¿es correcto? ¿No son 0 y 1 opuestos? (Nos hemos fijado nuestro a 1 y se asumió que sí significaba / verdadero (se ejecutan desde el paquete) tal como se documenta aquí: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -paquete de implementación)

Hola Elliott, muchas gracias por la rápida respuesta.

Así que solo para aclarar:
Cuando se implementa desde una plantilla ARM al plan de consumo y se usa una ranura de implementación, pero sin zip / paquete

• Debo definir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE tanto en la ranura de producción como en la de puesta en escena.

• NO debería definir WEBSITE_CONTENTSHARE como una configuración de ranura de implementación en ninguna de las ranuras.

Atentamente

Owain

De: Elliott Hamai [email protected]
Enviado: 22 de junio de 2020 17:31
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Owain Winterbone (ITCS - Personal) [email protected] ; Manual [email protected]
Asunto: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE no debe usarse de acuerdo con el soporte (# 36458)

Advertencia: este correo electrónico es de fuera del sistema UEA. No haga clic en enlaces o adjuntos a menos que los espere del remitente y sepa que el contenido es seguro.

Hola a todos, perdón por toda la confusión aquí. Intentamos ser inteligentes al hacer que el Portal de Azure le diga cuándo puede tener problemas de escalado con su configuración, pero equivocamos la lógica y ahora la gente puede ver la advertencia de forma incorrecta. Estamos trabajando en una solución, pero mientras tanto, aquí le mostramos cómo validar si puede tener problemas de escalado con su aplicación o no:

Si utiliza la prima elástica o el consumo, debe cumplir uno de los siguientes criterios:

1. Debe tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos

o

1. Si utiliza ejecutar desde zip / paquete, debe tener "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" o "WEBSITE_RUN_FROM_PACKAGE" configurado en un valor distinto de vacío, 0 o 1

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en 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 y sdata = woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA% 3D y reservado = 0 , o darse de baja https://eur01.safelinks.protection.outlook.com/?url= https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ y de datos = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284402737056941 y sdata = StHshC6EtV6A% 2BLi3g7x0xfNx56POAYnwjMWihEf% 2BCYM% 3D y reservados = 0 .

@briandunnington - Sí, lo siento, es confuso.

• 0 significa deshabilitado
• 1 significa ejecutar desde un zip local, pero para que funcione correctamente, también debe tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos por la primera declaración.

@OwainWin - Lo siento, estoy confundido por tu pregunta. Preguntó si debería y no debería incluir WEBSITE_CONTENTSHARE.

Creo que debería tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos tanto en la producción como en el espacio de ensayo.

Gracias @ehamai , así que volvamos a la pregunta original de este hilo: ¿cuál es la guía para configurar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE en una plantilla ARM que funciona para implementaciones iniciales y posteriores? Para el plan Premium (no estoy 100% seguro sobre el plan de consumo, pero cree que es el mismo), aquí está la matriz de lo que funciona / no funciona:

• si implementa un nuevo recurso:
  
  
  
  • si no proporciona ninguna de las configuraciones, la implementación se realiza correctamente, pero termina con el almacenamiento no configurado, el escalado de funciones será limitado.
  
  
  • si solo proporciona WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, falla y falta el parámetro obligatorio WEBSITE_CONTENTSHARE
  
  
  • si proporciona ambos valores, funciona
  
  
• si implementa en un recurso existente
  
  
  
  • si no proporciona ninguna de las configuraciones, la implementación se realiza correctamente, pero termina con el almacenamiento no configurado, el escalado de funciones será limitado.
  
  
  • si solo proporciona WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, tiene éxito (y parece funcionar bien después) aunque se supone que WEBSITE_CONTENTSHARE es obligatorio
  
  
  • si proporciona ambos valores, 'funciona' porque la parte ARM no falla, pero causa el problema de reinicio múltiple y la guía de MS anterior es no configurar WEBSITE_CONTENTSHARE en las actualizaciones
  
  

Por lo tanto, no parece haber una forma de tener una sola plantilla ARM que funcione para ambos escenarios en este momento.

Hola elliott

Lo que quise decir para el segundo punto es que WEBSITE_CONTENTSHARE debe definirse como una configuración de aplicación, pero no debe establecerse como una configuración de ranura de implementación.
Por lo tanto, no debería tener la marca de la siguiente manera:

[cid: [email protected]]

De: Elliott Hamai [email protected]
Enviado: 22 de junio de 2020 18:38
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Owain Winterbone (ITCS - Personal) [email protected] ; Mencione menció[email protected]
Asunto: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE no debe usarse de acuerdo con el soporte (# 36458)

Advertencia: este correo electrónico es de fuera del sistema UEA. No haga clic en enlaces o adjuntos a menos que los espere del remitente y sepa que el contenido es seguro.

@OwainWin https: //eur01.

Creo que debería tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos tanto en la producción como en el espacio de ensayo.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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 y sdata = ctK99d4qO2YuIN% 2F07lwuHC0wNut% 2Fx8LjgLd7v55rTAM% 3D y reservado = 0 , o darse de baja 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 y reservado = 0 .

@paulbatum

• En la creación inicial del recurso a través de ARM, se debe configurar WEBSITE_CONTENTSHARE. Sin embargo, después de la creación inicial, esta configuración debe omitirse de la plantilla ARM (porque si se incluyó, las ejecuciones posteriores de la plantilla ARM podrían causar intercambios de contenido inesperados)

Te das cuenta de que este tipo de ruptura es el propósito de una plantilla ARM, ¿verdad?

Ese comportamiento se está arreglando, pero probablemente tardará entre 1 y 2 meses en salir. Entonces, mientras tanto, la guía que compartí anteriormente (donde la configura inicialmente y luego la elimina de la plantilla ARM) es aplicable.

¿Cuál es la configuración final esperada aquí?
¿Podemos recibir un anuncio en Azure / app-service-anuncios con la configuración adecuada y el cronograma oficial una vez que todo esto esté realmente implementado?

Este es un gran bloqueador para nosotros. Necesitamos poder usar la misma plantilla ARM para implementar en un nuevo grupo de recursos que usaríamos para implementar en un grupo de recursos existente. Ejecutamos específicamente nuestras plantillas ARM en modo Completo para ayudar a proporcionar un poco más de contexto.

En este momento, nuestra plantilla ARM se parece a esto:

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

Tome nota de los siguientes detalles: Estamos especificando nuestra configuración _en la ranura de preparación_, no la ranura de producción. Lo que esto nos permite hacer es implementar nuevas configuraciones (y actualizaciones de las existentes) en la ranura de ensayo primero. Entonces, nuestra canalización de DevOps hace esto:

• Paso 1) Implementar la plantilla ARM en el grupo de recursos
• Paso 2) Implementar la aplicación de funciones en la ranura de ensayo
• Paso 3) Ejecute algunas pruebas de humo en la ranura de preparación
• Paso 4) Intercambia las ranuras de producción y puesta en escena

El problema, sin embargo, es que debido a que WEBSITE_CONTENTSHARE se está configurando dentro de la plantilla ARM, la ranura de producción y la ranura de preparación toman inmediatamente la nueva versión de la aplicación justo después del Paso 2 (incluso antes de que ocurra un intercambio). Creo que de esto es de lo que habla la gente cuando dice "operación de intercambio no intencionada".

_NO_ queremos establecer la configuración de la ranura de producción en nuestra plantilla ARM, y _NO_ queremos que se elimine ninguna configuración de la ranura de producción como resultado de la ejecución de nuestra plantilla ARM. La forma en que funciona la implementación de la plantilla ARM en el modo Completo es que si especificamos alguna configuración para la ranura de producción, todas las configuraciones que no se especifican explícitamente se eliminan automáticamente.

Espero que todo esto tenga sentido. Actualmente estamos intentando eliminar WEBSITE_CONTENTSHARE de nuestra plantilla ARM, con la esperanza de que el tiempo de ejecución genere el valor en todos los escenarios y ya no dé lugar a "intercambios no deseados".

Hola a todos, soy el desarrollador principal de las ranuras de implementación y abordaré sus inquietudes con respecto a la configuración de WEBSITE_CONTENTSHARE y WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:

Aquí está la guía oficial:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Esto siempre debe establecerse ya que le indica al servicio de aplicaciones que está utilizando archivos azure para el almacenamiento de contenido.

WEBSITE_CONTENTSHARE:

• Esto ahora se puede omitir por completo de sus plantillas ARM para funciones de sku de consumo que generarán automáticamente el campo y evitarán intercambios no deseados. Esto significa que puede utilizar la misma plantilla para la creación y las actualizaciones posteriores.

• Desafortunadamente, descubrimos que esta generación automática de WEBSITE_CONTENTSHARE se pasó por alto para el esquí Elastic Premium, por lo que el problema de tener que incluirlo durante la creación y omitirlo durante las actualizaciones sigue en pie. La solución para esto se está implementando actualmente y ha llegado a la mitad de nuestra flota. Debería implementarse por completo en las próximas 2 semanas y, después, la guía será la misma para ambos skus y WEBSITE_CONTENTSHARE se puede omitir por completo.

¡Espero que aborde algunas de sus inquietudes!

@shubDhond Muchas gracias. ¿Podemos obtener una actualización oficial de la documentación?

@shubDhond para planes de consumo de Windows si solo proporciono WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Recibo un error a través de la implementación de la plantilla de brazo que dice que falta WEBSITE_CONTENTSHARE.
No necesito usar tragamonedas. Si omite ambos, la implementación se realiza, pero aparece la advertencia "el almacenamiento no está configurado. El escalado de funciones será limitado".

¿Cuál es la guía sobre los planes de consumo con respecto a esos dos parámetros que estoy usando el plan de consumo de Windows .net core?

¡Ídem! También recibo este error. ¿Cuándo se va a arreglar esto?

Tengo el mismo problema con el consumo y el plan elástico, nos está causando muchos problemas con las implementaciones automatizadas.

He tenido cierto éxito al omitir WEBSITE_CONTENTSHARE para Premium al implementar la configuración directamente en las propiedades Microsoft.Web/sites (siteConfig, appSettings), pero no al especificar la configuración como un recurso separado usando Microsoft.Web/sites/config con "type": "config" .

@shubDhond Este problema definitivamente no está solucionado. En el plan de consumo de Windows, si implementa una plantilla con solo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y sin WEBSITE_CONTENTSHARE, obtendrá el error "Falta WEBSITE_CONTENTSHARE".

Intentar usar las tareas de implementación de App Service en Azure DevOps y configurar solo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING también producirá un error HTTP 400.

Actualmente, la automatización de las aplicaciones de la función Azure en el plan de consumo está totalmente rota.

Tener el mismo problema que @clawrenceks

También estamos experimentando el mismo problema que @clawrenceks.
Tampoco podemos establecer solo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sin WEBSITE_CONTENTSHARE través del portal de Azure. También tenemos WEBSITE_RUN_FROM_PACKAGE establecido en 1.

Tampoco estoy seguro de cómo funcionará esto cuando tenga el modo de implementación de la plantilla ARM configurado en Complete ? ¿No eliminará la configuración de la aplicación generada WEBSITE_CONTENTSHARE ?

Como la mayoría, también estamos perdidos.

Ahora tengo mi plantilla ARM implementando con éxito mi aplicación de funciones en un Plan de consumo de Windows. Cuando se implementa, el mensaje Storage is not configured, Function scaling will be limited. Click to learn more ya no se muestra. Los intercambios de tragamonedas también funcionan como se esperaba.

Mis principales hallazgos de este proceso son:

Si actualmente tiene una aplicación de función de Azure SIN la configuración de la aplicación WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE , creo que la única forma de solucionar esto es volver a implementar su aplicación, asegurándose de que WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting está en su lugar como parte de la creación del servicio de la aplicación.

Tener el WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en su lugar como parte de la creación de recursos es clave. Al usar ARM, mis conclusiones son que debe implementarse como una configuración de aplicación durante la implementación del servicio de la aplicación principal, con un tipo de recurso de Microsoft.Web/sites . Tener un tipo de recurso separado de Microsoft.Web/sites/config en su plantilla ARM para implementar la configuración de la aplicación no funcionará.

No incluyo la configuración WEBSITE_CONTENTSHARE en mi plantilla ARM. Esto lo crea el tiempo de ejecución cuando se implementa mi plantilla ARM. Esta es una señal de que la implementación está funcionando bien. Con el enfoque que se describe aquí, puedo implementar los recursos iniciales y luego volver a implementar la plantilla varias veces sin recibir errores relacionados con la configuración WEBSITE_CONTENTSHARE .

Otro requisito clave para mí era que la configuración de la aplicación del sitio de producción solo se debería implementar durante la creación inicial de recursos. La única forma en que quería obtener nuevas configuraciones de aplicaciones (futuras) en el sitio de producción es a través de un intercambio de tragamonedas. Para lograr esto, agregué algo de lógica en mi plantilla ARM para manejar lo siguiente.

1) La configuración de la aplicación en la plantilla ARM solo se implementará en el sitio de producción durante la creación inicial del sitio, no se agregará al sitio de producción como parte de implementaciones futuras.

2) La configuración de la aplicación en la plantilla ARM siempre se aplica a la ranura de preparación. Luego se intercambian en producción utilizando una ranura de intercambio.

Para lograr lo anterior, los ajustes de aplicación para el sitio de producción en mi plantilla ARM son condicionales. Si el recurso no existe, implemento el conjunto completo de configuraciones de la aplicación en la plantilla (para asegurarme de que el servicio de la aplicación se crea correctamente). Si el recurso ya se ha creado, paso un nulo para la configuración de la aplicación. Cuando se implementa, conserva la configuración de la aplicación que ya está en su lugar para el sitio de producción.

También estoy totalmente confundido. Si se requiere WEBSITE_CONTENTAZUREFILECONNECTIONSTRING para los planes de consumo, pero no se puede configurar para que se adhiera a una ranura, ¿cómo se supone que debo cambiar entre una ranura de ensayo y una de producción donde quiero que cada una se ejecute en una cuenta de almacenamiento diferente? Esto ha sido posible con las aplicaciones web desde siempre y parece un caso de uso muy común. Por lo que puedo decir, el intercambio de ranuras de aplicaciones de función está completamente roto / inutilizable hasta que esto se solucione. ¡Me encantaría que alguien me dijera por qué / cómo me equivoco! Sé que el problema original hace referencia a las plantillas ARM, pero esto parece un problema mucho más amplio.

El mismo problema en el plan Elastic Premium. La implementación en la ranura de escenario con la misma plantilla ARM con el mismo WEBSITE_CONTENTSHARE hace que la ranura de producción apunte a los mismos binarios que la ranura de escenario.
No puedo implementar sin WEBSITE_CONTENTSHARE en absoluto porque obtengo 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest' error

Estoy confundido. ¿Qué es lo correcto por hacer?

Si utiliza la prima elástica o el consumo, debe cumplir uno de los siguientes criterios:

Debe tener WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE definidos

o

Si utiliza ejecutar desde zip / paquete, debe tener "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" o "WEBSITE_RUN_FROM_PACKAGE" configurado en un valor distinto de vacío, 0 o 1

como dice @ehamai ?

o

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Esto siempre debe establecerse ya que le indica al servicio de aplicaciones que está utilizando archivos azure para el almacenamiento de contenido.

WEBSITE_CONTENTSHARE:

Esto ahora se puede omitir por completo de sus plantillas ARM para funciones de sku de consumo que generarán automáticamente el campo y evitarán intercambios no deseados. Esto significa que puede utilizar la misma plantilla para la creación y las actualizaciones posteriores.

Desafortunadamente, descubrimos que esta generación automática de WEBSITE_CONTENTSHARE se pasó por alto para el esquí Elastic Premium, por lo que el problema de tener que incluirlo durante la creación y omitirlo durante las actualizaciones sigue en pie. La solución para esto se está implementando actualmente y ha llegado a la mitad de nuestra flota. Debería implementarse por completo en las próximas 2 semanas y, después, la guía será la misma para ambos skus y WEBSITE_CONTENTSHARE se puede omitir por completo.

¡Espero que aborde algunas de sus inquietudes!

como dice @shubDhond ?

Recibo un error si tengo una función azul en el plan de consumo sin WEBSITE_CONTENTSHARE (en realidad, la ranura de producción no tiene ninguna configuración de aplicación) en cualquiera de las ranuras y yo:

1. implementar ARM en la ranura de ensayo
2. intercambio
3. redistribuir a la ranura de ensayo

Luego me dice que necesito WEBSITE_CONTENTSHARE. Es como si no pudiera generar una participación para el antiguo espacio de producción. No he intentado eliminar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, porque este hilo dice que no lo haga, excepto @ehamai , que me dice que puedo hacerlo, si hago un "WEBSITE_RUN_FROM_PACKAGE".

Lo curioso es que tengo una función ejecutándose con esta configuración, pero con un tiempo de ejecución ~ 2 en lugar de ~ 3, y está funcionando. ¿Hay algún problema con ~ 3 y las ranuras de implementación?
Esto es muy confuso.

No importa lo que este intercambio espontáneo de tragamonedas sea muy aterrador, de todos modos, ya que necesitamos crear estas dos variables WEBSITE_ que estamos completando en ARM, esta última también según la definición aquí . La herramienta de diagnóstico de configuración de la aplicación web en el portal ya no muestra ningún error.

reasignar: @mattchenderson

¿Algún avance en esto?

El soporte técnico de Microsoft también nos advirtió que se debe establecer la propiedad "WEBSITE_CONTENTSHARE". Cuando no es posible configurarlo como una configuración de ranura, esto es bastante problemático para nuestras canalizaciones de compilación y plantillas ARM. ¡Por favor aconséjame!

Yo también estoy de acuerdo. ¡Es hora de dar una explicación sobre cómo usar las tragamonedas aquí!

También estoy de acuerdo, este hilo se inició hace más de 15 meses y todavía no hay una resolución estable.
No podemos usar las tragamonedas hasta que esto se haya resuelto correctamente con una solución confiable, las tragamonedas son una característica fantástica pero deben ser confiables.

Hola a todos,

Lo sentimos mucho por la demora en la respuesta aquí, este hilo no estaba siendo monitoreado tan bien como debería haber sido.

Para abordar la confusión, el comportamiento descrito por @clawrenceks anteriormente es correcto a partir de ahora. Para los sitios que aún no tienen configurado el almacenamiento de Azure Files, se le pedirá que proporcione WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE. Una vez que se proporcionan estos y su aplicación ahora está configurada para ejecutarse en Azure Files, puede omitir WEBSITE_CONTENTSHARE de sus plantillas a partir de entonces para evitar el intercambio inadvertido de su contenido.

La forma en que la API funciona actualmente es que en la creación del sitio (recurso 'Microsoft.Web / sites') si proporciona WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y no WEBSITE_CONTENTSHARE, se generará un contenido compartido para usted. Sin embargo, en las actualizaciones de un recurso 'Microsoft.Web / sites' existente o un recurso 'Microsoft.Web / sites / config', la API busca ver si ya existe un valor para WEBSITE_CONTENTSHARE para la aplicación y si no está presente , arroja un error.

Supongo que esto fue para proteger a los clientes de que inadvertidamente borren su contenido mientras cambian a archivos azules, en el caso de que proporcionen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y generemos un nuevo WEBSITE_CONTENTSHARE para ellos (esencialmente borrando su contenido ya que esta acción sería nueva). Esto es mucho más seguro durante la creación del sitio porque el sitio comenzaría con una pizarra limpia de todos modos y no nos arriesgamos a borrar su contenido.

Sin embargo, puedo entender totalmente la confusión para todos ustedes que desean archivos azules. Tendré que pensar en la mejor manera de abordar esto y al mismo tiempo mantener nuestras operaciones de actualización a salvo de borrar su contenido. Por ahora, la guía para todos los que no tienen archivos azules configurados y desean hacer el cambio, deberán proporcionar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE para el cambio inicial y luego la guía sería la misma para omitir WEBSITE_CONTENTSHARE de su plantilla a partir de entonces.

Si hay alguna sugerencia sobre cómo le gustaría que se manejara el caso de actualización, ¡también sería muy apreciado!

@shubDhond, por lo que debemos implementar la configuración de la cadena de conexión y el contenido compartido en la primera implementación en la ranura de producción, pero no en las implementaciones posteriores. ¿Hay alguna forma de hacer esto automáticamente? ¿Como detectar si un recurso se ha implementado a través de ARM? ¿O necesitamos pasar esta información manualmente al ARM (fx a través de un parámetro que indica si esta es la primera implementación?

@mslot, desafortunadamente, no creo que sea posible decir dentro de una plantilla si un recurso ya existe o no, pero esto debería ser posible con esto (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) combinado con un parámetro pasado a la plantilla que le indica si el sitio ya está configurado para Azure Files. Esto se puede determinar obteniendo el sitio y viendo si la configuración de la aplicación tiene WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE.

@mslot, desafortunadamente, no creo que sea posible decir dentro de una plantilla si un recurso ya existe o no, pero esto debería ser posible con esto (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) combinado con un parámetro pasado a la plantilla que le indica si el sitio ya está configurado para Azure Files. Esto se puede determinar obteniendo el sitio y viendo si la configuración de la aplicación tiene WEBSITE_CONTENTAZUREFILECONNECTIONSTRING y WEBSITE_CONTENTSHARE.

Realmente espero que esto se solucione pronto. Hace que el uso de las ranuras sea inútil en mi flujo de trabajo. Debe ser completamente automático. Esta solución es una solución de hackeo en mi opinión y no tiene sentido introducirla cuando está funcionando para aplicaciones web porque difiere mucho en algo que debería funcionar igual introduciendo "magia negra" para otros que ingresan a un proyecto.

Realmente espero que esto se solucione para que podamos comenzar a usarlo. Creo que evita que mucha gente use esta función.

@mslot Entiendo totalmente su dolor con esto y lamento que no pudimos identificar este problema antes. Hablaré con los desarrolladores que implementaron inicialmente este comportamiento en la próxima semana y veré si podemos encontrar una solución segura para este problema que podría evitar la posibilidad de que los clientes pasen inadvertidamente a usar un recurso compartido de archivos azul vacío para su contenido. Una vez que tengamos una solución propuesta, la actualizaré aquí.

@shubDhond Realmente no entiendo la "parte" de Azure Files de esto. Implemento mi proyecto de función de Azure usando Azure DevOps creando primero un espacio de implementación, lo implemento en este y luego lo cambio. Estoy usando el método de implementación "RunFromPackage" y esto no parece funcionar cuando utilizo una StorageAccount clásica. NO estoy usando Azure Files y parece que tengo el mismo problema relacionado con la configuración WEBSITES_CONTENTSHARE para las dos ranuras.

Hola @cannehag, ¿ podrías abrir una nueva edición para esto? Es posible que se produzca un comportamiento extraño con la configuración de la aplicación RunFromPackage marcada como pegajosa, lo que provoca síntomas similares a los que se describen aquí. Sugeriría un nuevo problema para que no agreguemos confusión aquí, ya que es probable que los problemas no estén relacionados.