@danielstocker Muito obrigado por nos chamar a atenção para isso. Eu tenho isso atribuído ao líder de serviço para ser investigado mais profundamente e farei uma atualização quando tivermos maior clareza.

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

Obrigado por investigar isso.

Você precisa de mais informações para progredir?

@danielstocker, você pode fornecer mais informações sobre qual foi o seu problema original que levou a essa descoberta? Não tenho certeza de entender corretamente a implicação de defini-lo incorretamente (o que você mencionou como unintentional swap )

Olá @ ggirard07 ,

Sem problemas. Deixe-me resumir.
Isso surgiu inicialmente porque nossa documentação afirma que WEBSITE_CONTENTSHARE é necessário. (veja aqui: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

Se exportarmos um modelo de funções do Marketplace (modelo de exportação na última página), obteremos WEBSITE_CONTENTSHARE como uma configuração de aplicativo padrão. Se usarmos isso, a seguinte situação pode acontecer.

1) Implementamos um modelo ARM e obtemos uma função vazia com dois slots
2) Nós implantamos no slot de teste
3) Trocamos para disponibilizar o conteúdo em produção
4) SWAP involuntário quando o modelo ARM é reimplantado e as configurações do aplicativo são reaplicadas (isso acontece até mesmo durante uma implantação ARM incremental, pois o recurso appsettings sempre substitui e redefine a configuração WEBSITE_CONTENTSHARE)
5) A rotina de implantação agora implanta o novo código no slot de teste e nosso slot de produção está vazio em vez de conter a versão anterior. Nossa função de produção está "involuntariamente" desligada

O cliente, neste caso específico, apontou para este artigo https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

Isso sugere que a configuração deve ser definida como uma configuração de slot para corrigir o comportamento. Embora isso corrija o comportamento em meus testes, parece errado, porque não deve funcionar.

Abaixo está uma tabela do que aconteceu nos meus testes. (depois de fazer uma configuração de slot)

Minha percepção (e a do cliente) é que os slots não devem mais ser trocados, mas, conforme descrito no artigo, ainda funciona de qualquer maneira.

Eu levantei isso internamente também e as pessoas encontraram um comportamento inconsistente ao alterar as configurações do aplicativo. (Daí porque isso está destacado na minha grade de teste) Para um colega testá-lo, atualizar as configurações do aplicativo fez com que as configurações de slot se reaplicassem, causando novamente uma troca não intencional.

Isso, então, finalmente (desculpe pela longa resposta) me levou a levantar o caso de suporte em que o resultado era "simplesmente não defina a configuração".
Meus testes pessoais mostraram que isso corrige o problema, mas não há orientação na documentação para confirmar isso, por isso eu levantei este item.

Espero que isto ajude.
Avise-me se houver alguma dúvida.

@danielstocker definitivamente uma informação importante, especialmente para entender como os slots e a troca estão funcionando para Functions versus um webapp tradicional com webjobs.
Isso também não é explicado na documentação dos uma única captura de tela na etapa 4 que o representa, onde esses valores são truncados para tornar as coisas ainda mais claras ...

Olá @ ggirard07 e obrigado por ler minha crítica. Então, qual é o caminho a seguir a partir daqui? :)

@ ggirard07 @ ggailey777 @ mike-urnun-msft

São necessárias mais informações para criar alguma clareza na documentação em torno desse comportamento? Estou trabalhando com um cliente que está pensando em parar de usar slots de função porque não tem certeza sobre a orientação oficial em torno deste cenário.

Obrigado pela ajuda

@danielstocker Apenas para que eu tenha claro o que você acha que resolverá os problemas de documentação relacionados a isso:

• Remova a configuração de implantação WEBSITE_CONTENTSHARE daqui .
• Adicione uma observação no artigo de referência de que WEBSITE_CONTENTSHARE só deve ser definido pelo tempo de execução.

Você acha que isso seria suficiente?

cc @mattchenderson

Olá @ ggailey777
Sim, acho que seria uma boa solução

Não é WEBSITE_CONTENTSHARE um dos appsetting necessários ao implantar um aplicativo de função usando ARM?

Não é WEBSITE_CONTENTSHARE um dos appsetting necessários ao implantar um aplicativo de função usando ARM?

Se não for aplicado, o runtime irá gerar um para você, eu acho.

Implantei um ARM com um plano de consumo e um aplicativo de função com uma seção _Microsoft.Web / sites / config_ chamada appsettings e as seguintes propriedades

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

A implantação retornou o seguinte erro:

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

Depois que eu _também_ removi o parâmetro WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, a implantação ocorreu sem erros. Portanto, parece haver alguma relação necessária entre essas duas configurações.
Embora bem-sucedida, essa implantação me fez vagar se e onde as funções (pacotes) são implantadas fisicamente (e se este caso é válido em primeiro lugar).

Temos visto o comportamento exato que @tjgalama descreveu e também nos perguntando onde os compartilhamentos de arquivos com os pacotes de funções são armazenados.

Nossos aplicativos de função também incluem uma função disparada por temporizador, então especificamos a configuração AzureWebJobsStorage conforme sugerido : teríamos adivinhado / esperado que o tempo de execução usasse essa mesma string de conexão para o (agora implícito) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , mas esse não é o caso: na conta de armazenamento que especificamos lá, vemos os contêineres de blob azure-webjobs-hosts e azure-webjobs-secrets , mas nenhum compartilhamento de arquivo está presente.

Eu verifiquei no Kudu por pistas e parece que todos os arquivos que precisam estar lá estão no sistema de arquivos (onde quer que esteja, verificado em app-name.scm.azurewebsites.net/api/vfs/ ), mas nenhuma referência a nenhuma das configurações ( WEBSITE_CONTENTSHARE ou WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ) deve ser visto na aba de ambiente ( appname.scm.azurewebsites.net/Env.cshtml ).

Talvez seja importante mencionar que nossos aplicativos são configurados com WEBSITE_ENABLE_SYNC_UPDATE_SITE=True e WEBSITE_RUN_FROM_PACKAGE=1 .
Os aplicativos parecem funcionar, mas realmente gostaríamos de alguma clareza neste ponto, pois estamos portando um serviço de negócios principal para o Azure Functions e queremos descobrir isso antes de lançar para a produção.

Seguindo alguns conselhos, definimos WEBSITE_CONTENTSHARE como uma configuração de slot para garantir que os valores fossem distintos entre nossos slots de produção e de teste. Hoje, o modelo ARM que usamos começou a falhar com 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (embora eu tenha confirmado que ele está realmente definido como uma configuração de slot no portal atualmente). Algo em torno desse comportamento mudou?

Percebemos esse mesmo problema nos últimos dias e precisamos de orientação sobre como proceder. Também temos seguido a abordagem de definir WEBSITE_CONTENTSHARE como uma configuração de slot para contornar o problema de troca não intencional, mas agora não podemos implantar devido a esse erro. Eu tentei remover retroativamente essa configuração e as configurações de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING para seguir em direção ao que parece ser a abordagem recomendada de não usar nenhuma delas, mas essas implantações também falhariam.

Seguindo alguns conselhos, definimos WEBSITE_CONTENTSHARE como uma configuração de slot para garantir que os valores fossem distintos entre nossos slots de produção e de teste. Hoje, o modelo ARM que usamos começou a falhar com 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (embora eu tenha confirmado que ele está realmente definido como uma configuração de slot no portal atualmente). Algo em torno desse comportamento mudou?

Remova-o e deixe o runtime escolher um nome. É assim que eu faço.

@jeffhollan você pode nos dar alguma clareza por favor

Isso diz que WEBSITE_CONTENTSHARE e WEBSITE_CONTENTAZUREFILECONNECTIONSTRING são _requeridos_: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

Os comentadores aqui pensam que _não_ são necessários; ARM acha que eles são necessários ?; O suporte do Azure pensa que WEBSITE_CONTENTSHARE quebra os cenários de slot.

Acabamos verificando o código do host de funções do Azure e parece que , ao executar a partir do pacote, a configuração WEBSITE_CONTENTAZUREFILECONNECTIONSTRING não é
Verificamos removendo de nosso modelo ARM WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE e obtendo bons resultados: nossos aplicativos de funções não têm essas duas configurações (nem mesmo atribuídas pelo tempo de execução) e eles não use compartilhamentos de arquivos em nenhuma conta de armazenamento (pelo menos isso podemos ver).

Portanto, uma coisa a ter em mente é que o sistema de arquivos para um aplicativo web / aplicativo de função se parece com isto:

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

Quando você usa run from package, isso apenas substitui a pasta wwwroot nesta árvore. Todo o resto é fornecido pelo sistema de arquivos principal. Se você criar um aplicativo de função premium elástica ou de consumo sem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, o sistema de arquivos principal não estará disponível fora da unidade de escala em que o aplicativo de função foi criado. Esta não é uma configuração compatível / recomendada. Isso significa que seu aplicativo de funções não pode ser dimensionado além dos limites da unidade de escala em que foi criado ou, se for, você não poderá confiar que o estado do sistema de arquivos fora de wwwroot permanecerá consistente.

A orientação mais recente que vi do dev que controla como WEBSITE_CONTENTSHARE interage com os slots é a seguinte:

• WEBSITE_CONTENTSHARE NÃO deve ser uma configuração de slot. Uma alteração da API que bloqueia isso está sendo implementada no momento da escrita.
• Na criação inicial do recurso via ARM, WEBSITE_CONTENTSHARE deve ser definido. No entanto, após a criação inicial, esta configuração deve ser omitida do modelo ARM (porque se foi incluída, outras execuções do modelo ARM podem causar trocas de conteúdo inesperadas)

Seguindo do meu comentário acima .. Eu também descobri que o sistema atualmente tem algum comportamento inconsistente em relação à geração de WEBSITE_CONTENTSHARE de forma que você nem precisa especificá-lo inicialmente. Alguns de vocês têm dito que não precisam especificá-lo, enquanto outros estão recebendo um erro dizendo que é obrigatório. Pelo que eu posso dizer, esse comportamento funciona corretamente para o consumo (ou seja, um modelo ARM para consumo não precisa dessa configuração inicialmente), mas o mesmo não é verdadeiro para o prêmio elástico. Esse comportamento está sendo corrigido, mas provavelmente levará de 1 a 2 meses para ser solucionado. Nesse ínterim, a orientação que compartilhei acima (onde você define inicialmente e, em seguida, remove do modelo ARM) é aplicável.

@paulbatum

• Na criação inicial do recurso via ARM, WEBSITE_CONTENTSHARE deve ser definido. No entanto, após a criação inicial, esta configuração deve ser omitida do modelo ARM (porque se foi incluída, outras execuções do modelo ARM podem causar trocas de conteúdo inesperadas)

Você percebe que esse tipo de quebra o propósito de um template ARM, certo?

Esse comportamento está sendo corrigido, mas provavelmente levará de 1 a 2 meses para ser solucionado. Nesse ínterim, a orientação que compartilhei acima (onde você define inicialmente e, em seguida, remove do modelo ARM) é aplicável.

Qual é a configuração final esperada aqui?
Podemos obter um anúncio sobre Azure / app-service-announcements com a configuração adequada e cronograma oficial depois que tudo isso for realmente implantado?

Olá, não tenho certeza se houve algum desenvolvimento nisso. Ainda estou lutando para usar os modelos ARM com a sinalização WEBSITE_CONTENTSHARE. @paulbatum como posso omitir uma configuração do modelo ARM? Tive que desabilitar completamente a etapa para fazê-la funcionar.

@gustavobmichel Desculpe, não entendi sua pergunta. O modelo ARM é JSON, você o edita conforme necessário. Ele aparece como parte da seção de configurações de aplicativos, por exemplo:

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

Oi @paulbatum , obrigado por voltar para mim. Achei que você mencionou sobre omitir programaticamente as configurações do modelo JSON, então essa foi a minha pergunta.

Como outros afirmaram, também pensei que essas duas configurações eram necessárias, então removi as duas do meu modelo ARM.

Para testar esse recurso com tempo de inatividade zero, criei um teste simples com a infraestrutura básica do mininum para testá-lo. Removi todos os recursos do meu grupo de recursos e executei o modelo ARM como parte do pipeline de liberação para criar os recursos sem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE e WEBSITE_RUN_FROM_PACKAGE.

Fiz alguns testes e ainda está funcionando bem usando o plano de consumo. Farei alguns testes esta semana com o nível premium.

Também adicionei esta configuração WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG a 1 conforme este link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Anexei meu modelo ARM de teste para referência.
azuredeploy.txt

Oi @paulbatum , obrigado por voltar para mim. Achei que você mencionou sobre omitir programaticamente as configurações do modelo JSON, então essa foi a minha pergunta.

Como outros afirmaram, também pensei que essas duas configurações eram necessárias, então removi as duas do meu modelo ARM.

Para testar esse recurso com tempo de inatividade zero, criei um teste simples com a infraestrutura básica do mininum para testá-lo. Removi todos os recursos do meu grupo de recursos e executei o modelo ARM como parte do pipeline de liberação para criar os recursos sem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE e WEBSITE_RUN_FROM_PACKAGE.

Fiz alguns testes e ainda está funcionando bem usando o plano de consumo. Farei alguns testes esta semana com o nível premium.

Também adicionei esta configuração WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG a 1 conforme este link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Anexei meu modelo ARM de teste para referência.
azuredeploy.txt

Deixando de fora WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, como sua função sabe de onde obter o código do aplicativo?

Se ajudar, decidimos:

• definindo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING para a conta de armazenamento a partir da qual queremos que o código seja executado
• não especificando WEBSITE_CONTENTSHARE no modelo arm (permitir que seja gerado automaticamente para ambos os slots)
• WEBSITE_RUN_FROM_PACKAGE = 1

Eu fiz muitos testes em torno deles e esta parecia ser a melhor configuração para evitar o acionamento de trocas não intencionais e saber onde o código estava localizado, etc. Também não requer o gerenciamento dessas configurações fora do modelo ARM, o que eu não gostei a ideia de (parece que não há muito sentido em usar modelos ARM nesse ponto).

A implantação também parece funcionar sem especificar um valor WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, mas, como mencionado, não conseguimos descobrir onde o código estava localizado e o cara de suporte da MS que lidou com meu tíquete pareceu sugerir que isso era um bug e não deveria ser permitido pela plataforma.

Se ajudar, decidimos:

• definindo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING para a conta de armazenamento a partir da qual queremos que o código seja executado
• não especificando WEBSITE_CONTENTSHARE no modelo arm (permitir que seja gerado automaticamente para ambos os slots)
• WEBSITE_RUN_FROM_PACKAGE = 1

Eu fiz muitos testes em torno deles e esta parecia ser a melhor configuração para evitar o acionamento de trocas não intencionais e saber onde o código estava localizado, etc. Também não requer o gerenciamento dessas configurações fora do modelo ARM, o que eu não gostei a ideia de (parece que não há muito sentido em usar modelos ARM nesse ponto).

A implantação também parece funcionar sem especificar um valor WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, mas, como mencionado, não conseguimos descobrir onde o código estava localizado e o cara de suporte da MS que lidou com meu tíquete pareceu sugerir que isso era um bug e não deveria ser permitido pela plataforma.

Isso é exatamente o que descobri também. Obrigado por confirmar.

Minha função está tendo problemas para acessar o armazenamento após adicionar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_RUN_FROM_PACKAGE. Vocês adicionaram essas duas configurações tanto ao functionapp quanto ao slot?

O erro exato é: O Azure Functions Runtime está inacessível.

Isso é depois de fazer a primeira implantação e, em seguida, tento implantar uma nova versão.

Eu adicionei meu arquivo yml também.
arquivo yml.txt
deploy.txt

Eu também atualizei meu modelo ARM.

Minha função está tendo problemas para acessar o armazenamento após adicionar WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_RUN_FROM_PACKAGE. Vocês adicionaram essas duas configurações tanto ao functionapp quanto ao slot?

O erro exato é: O Azure Functions Runtime está inacessível.

Isso é depois de fazer a primeira implantação e, em seguida, tento implantar uma nova versão.

Eu adicionei meu arquivo yml também.
arquivo yml.txt
deploy.txt

Eu também atualizei meu modelo ARM.

Eu tenho em ambos. Na verdade, não tenho nada no meu slot de produção e troco tudo do teste. Eu vi isso ao definir um WEBSITE_CONTENTSHARE ou não apontar para a conta de armazenamento correta onde o código reside com WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Você não precisa apontar nada para lugar nenhum com WEBSITE_CONTENTSHARE. Na verdade, acho que vi aquele erro ao qual você se refere por causa de adicionar um WEBSITE_CONTENTSHARE às variáveis ​​de ambiente. Certifique-se de que não está definido.

Olá @mslot , acho que o problema estava na minha implantação. Eu estava configurando para zipDeploy porque li neste thread https://stackoverflow.com/a/56205917 sobre como configurá-lo no Azure DevOps. Depois que mudei para implantação padrão, tudo parece estar funcionando. Obrigado pela ajuda.

Esse comportamento está sendo corrigido, mas provavelmente levará de 1 a 2 meses para ser solucionado.

Alguma atualização sobre este problema? O comportamento de Consumo e Prêmio está agora alinhado? Podemos omitir WEBSITE_CONTENTSHARE da implantação inicial do ARM e das implantações subsequentes? Como isso afeta os slots de teste? Algum documento atualizado para vincular ou orientação?

Basicamente , @thomaswilkin e @mslot, mas apenas por meio de experimentação e tentativa e erro. Ainda não tenho certeza de como o runtime sabe onde encontrar nossos arquivos já que WEBSITE_CONTENTSHARE não está definido.

Oi. Não sei como vocês podem fazer isso, mas parece que não consigo implantar com
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sem WEBSITE_CONTENTSHARE. Mesmo através do portal, ocorreu um erro ao tentar definir a configuração;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

Na página de visão geral do aplicativo de funções, também vejo esta mensagem de aviso: Storage is not configured, Function scaling will be limited. Click to learn more. Estou executando um plano premium. Alguma atualização ou orientação oficial sobre como devemos configurar nossos aplicativos de funções?

Para o plano Premium (não tenho 100% de certeza sobre o plano de Consumo), aqui está a matriz do que funciona / não funciona:

• se você implantar um novo recurso:
  
  
  
  • se você não fornecer nenhuma configuração, a implantação será bem-sucedida, mas você terminará com a mensagem Storage is not configured, Function scaling will be limited
  
  
  • se você fornecer apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , ele falhará com Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • se você fornecer os dois valores, funciona
  
  
• se você implantar em um recurso existente
  
  
  
  • se você não fornecer nenhuma configuração, a implantação será bem-sucedida, mas você terminará com a mensagem Storage is not configured, Function scaling will be limited
  
  
  • se você fornecer apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , será bem-sucedido (e parecerá funcionar bem depois), embora WEBSITE_CONTENTSHARE deva ser necessário
  
  
  • se você fornecer os dois valores, 'funciona' no sentido de que a parte ARM não falha, mas causa o problema de reinicialização múltipla e a orientação da MS acima é não definir WEBSITE_CONTENTSHARE nas atualizações
  
  

Portanto, não parece haver uma maneira de ter um único modelo ARM que funcione para os dois cenários no momento.

Também vejo esta mensagem de aviso: Storage is not configured, Function scaling will be limited. Click to learn more . Não tinha o site WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ou WEBSITE_CONTENTSHARE. Como Korkiak mencionou, alguma diretriz atualizada ou oficial?

Recentemente, começamos a ver a mensagem "O armazenamento não está configurado, o dimensionamento da função será limitado. Clique para saber mais" no Portal do Azure para funções do Azure existentes que foram implantadas há quatro semanas. Nunca usamos WEBSITE_CONTENTAZUREFILECONNECTIONSTRING nem WEBSITE_CONTENTSHARE e isso tem funcionado bem até agora.

@paulbatum Parece que este problema está ganhando mais atividade nos últimos dias, uma vez que a mensagem 'O armazenamento não está configurado, o dimensionamento da função será limitado' começou a aparecer no portal. Alguma nova orientação sobre a maneira correta de configurar tudo isso?

Acabei de descobrir que o 'WEBSITE_CONTENTSHARE' não pode ser um erro de configuração de slot, conforme mencionado acima, ao implantar um novo aplicativo de função pela primeira vez em vários meses usando um modelo que funcionou bem antes.
O modelo tem 'WEBSITE_CONTENTSHARE' como uma configuração de slot e definido no aplicativo de função e nas configurações de aplicativos de slot de implantação de acordo com o artigo a seguir, que também deve ser mencionado acima:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
Ler este tópico removeu isso como uma configuração de slot e tentei várias combinações de configuração 'WEBSITE_CONTENTSHARE' e não estou obtendo o mesmo comportamento que os outros. Posso implantar sem erros conforme abaixo:

• Especifique 'WEBSITE_CONTENTSHARE' para o aplicativo de função e o slot de implantação
• Especifique 'WEBSITE_CONTENTSHARE' apenas para aplicativos de funções

Se eu não especificar 'WEBSITE_CONTENTSHARE' no modelo, recebo o erro "O parâmetro obrigatório WEBSITE_CONTENTSHARE está ausente".

Então, por favor, podemos ter uma atualização sobre quais devem ser as configurações reais, já que não posso implantar para produção com este comportamento atual.

Olá a todos, desculpem por toda a confusão aqui. Estávamos tentando ser inteligentes fazendo com que o Portal do Azure avisasse quando você pode ter problemas de dimensionamento com sua configuração, mas erramos a lógica e agora as pessoas podem estar vendo o aviso incorretamente. Estamos trabalhando em uma correção, mas, por enquanto, veja como validar se você pode ter problemas de dimensionamento com seu aplicativo ou não:

Se você está operando com premium elástico ou consumo, deve atender a um dos seguintes critérios:

1. Você deve ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos

ou

1. Se estiver usando run from zip / package, você deve ter "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" definido como algo diferente de vazio, 0 ou 1

Devemos resolver isso na próxima semana.

Obrigado @ehamai - por # 2 quando você diz 'definir como algo diferente de vazio, 0 ou 1' - correto? não são 0 e 1 opostos? (Definimos nosso para 1 e assumimos que sim significava / true (não executado a partir do pacote) como documentado aqui: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -deployment-package)

Olá Elliott, muito obrigado pela resposta extremamente rápida.

Então, apenas para esclarecer:
Ao implantar a partir de um modelo ARM para o plano de consumo e usar um slot de implantação, mas sem zip / pacote

• Devo definir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE nos slots de Produção e Preparação.

• Eu NÃO devo definir WEBSITE_CONTENTSHARE como uma configuração de slot de implantação em qualquer slot.

Atenciosamente

Owain

De: Elliott Hamai [email protected]
Enviado: 22 de junho de 2020 17:31
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Owain Winterbone (ITCS - Staff) [email protected] ; Manual [email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE não deve ser usado para suporte (# 36458)

Aviso: Este e-mail é de fora do sistema UEA. Não clique em links ou anexos, a menos que você os espere do remetente e saiba que o conteúdo é seguro.

Olá a todos, desculpem por toda a confusão aqui. Estávamos tentando ser inteligentes fazendo com que o Portal do Azure avisasse quando você pode ter problemas de dimensionamento com sua configuração, mas erramos a lógica e agora as pessoas podem estar vendo o aviso incorretamente. Estamos trabalhando em uma correção, mas, por enquanto, veja como validar se você pode ter problemas de dimensionamento com seu aplicativo ou não:

Se você está operando com premium elástico ou consumo, deve atender a um dos seguintes critérios:

1. Você deve ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos

ou

1. Se estiver usando run from zip / package, você deve ter "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" definido como algo diferente de vazio, 0 ou 1

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% & 7C637284402737046987 sdata = woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA% 3D & reservados = 0 , ou de cancelamento https://eur01.safelinks.protection.outlook.com/?url= https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ & dados = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% & 7C637284402737056941 sdata = StHshC6EtV6A% 2BLi3g7x0xfNx56POAYnwjMWihEf% 2BCYM% 3D & = reservados 0

@briandunnington - Sim, desculpe, é confuso.

• 0 significa desativado
• 1 significa executar a partir de um zip local, mas para que funcione corretamente, você também precisa ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos pela primeira instrução.

@OwainWin - Desculpe, estou confuso com sua pergunta. Você perguntou se deveria ou não incluir WEBSITE_CONTENTSHARE.

Acredito que você deva ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos no slot de produção e de teste.

Obrigado @ehamai - então, de volta à pergunta original deste tópico: qual é a orientação para definir WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE em um modelo ARM que funciona para implantações iniciais e subsequentes? Para o plano Premium (não tenho 100% de certeza sobre o plano de Consumo, mas acredito que seja o mesmo), aqui está a matriz do que funciona / não funciona:

• se você implantar um novo recurso:
  
  
  
  • se você não fornecer nenhuma configuração, a implantação será bem-sucedida, mas você terminará com o armazenamento não configurado, o dimensionamento da função será mensagem limitada
  
  
  • se você fornecer apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, ele falhará com o parâmetro obrigatório WEBSITE_CONTENTSHARE ausente
  
  
  • se você fornecer os dois valores, funciona
  
  
• se você implantar em um recurso existente
  
  
  
  • se você não fornecer nenhuma configuração, a implantação será bem-sucedida, mas você terminará com o armazenamento não configurado, o dimensionamento da função será mensagem limitada
  
  
  • se você fornecer apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, ele terá êxito (e parecerá funcionar bem depois), embora WEBSITE_CONTENTSHARE deva ser obrigatório
  
  
  • se você fornecer os dois valores, 'funciona' no sentido de que a parte ARM não falha, mas causa o problema de reinicialização múltipla e a orientação da MS acima é não definir WEBSITE_CONTENTSHARE nas atualizações
  
  

Portanto, não parece haver uma maneira de ter um único modelo ARM que funcione para os dois cenários no momento.

Oi elliott

O que eu quis dizer em relação ao segundo ponto é que WEBSITE_CONTENTSHARE deve ser definido como uma configuração de aplicativo, mas não deve ser definida como uma configuração de slot de implantação.
Portanto, não deve ter o carrapato conforme abaixo:

[cid: [email protected]]

De: Elliott Hamai [email protected]
Enviado: 22 de junho de 2020 18:38
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Owain Winterbone (ITCS - Staff) [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE não deve ser usado para suporte (# 36458)

Aviso: Este e-mail é de fora do sistema UEA. Não clique em links ou anexos, a menos que você os espere do remetente e saiba que o conteúdo é seguro.

@OwainWin https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f4f42d84108a770d570d570d4108d87165f435667d84108d87165f4f467d84108d87165f4f467d84108a895d87165f4f42d84108d87 % 7C0% 7C637284442665654874 & sdata = x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw% 3D & reserved = 0 - Desculpe, estou confuso com sua pergunta. Você perguntou se deveria ou não incluir WEBSITE_CONTENTSHARE.

Acredito que você deva ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos no slot de produção e de teste.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cafedec71775f4f42d84108d816d2f967% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% & 7C637284442665664832 sdata = ctK99d4qO2YuIN% 2F07lwuHC0wNut% 2Fx8LjgLd7v55rTAM% 3D & reservados = 0 , ou de cancelamento 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 & reserved = 0 .

@paulbatum

• Na criação inicial do recurso via ARM, WEBSITE_CONTENTSHARE deve ser definido. No entanto, após a criação inicial, esta configuração deve ser omitida do modelo ARM (porque se foi incluída, outras execuções do modelo ARM podem causar trocas de conteúdo inesperadas)

Você percebe que esse tipo de quebra o propósito de um template ARM, certo?

Esse comportamento está sendo corrigido, mas provavelmente levará de 1 a 2 meses para ser solucionado. Nesse ínterim, a orientação que compartilhei acima (onde você define inicialmente e, em seguida, remove do modelo ARM) é aplicável.

Qual é a configuração final esperada aqui?
Podemos obter um anúncio sobre Azure / app-service-announcements com a configuração adequada e cronograma oficial depois que tudo isso for realmente implantado?

Este é um grande bloqueador para nós. Precisamos ser capazes de usar o mesmo modelo ARM para implantar em um novo grupo de recursos que usaríamos para implantar em um grupo de recursos existente. Executamos especificamente nossos modelos ARM no modo Completo para ajudar a fornecer um pouco mais de contexto.

No momento, nosso modelo ARM se parece com isto:

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

Observe os seguintes detalhes: Estamos especificando nossa configuração _no slot de teste_, não no slot de produção. O que isso nos permite fazer é implantar novas configurações (e atualizações para as existentes) no slot de teste primeiro. Portanto, nosso pipeline de DevOps faz isso:

• Etapa 1) Implantar o modelo ARM para o grupo de recursos
• Etapa 2) Implantar aplicativo de funções no slot de teste
• Etapa 3) Execute alguns testes de fumaça contra o slot de teste
• Etapa 4) Troque os slots de preparação e produção

O problema, porém, é que, como WEBSITE_CONTENTSHARE está sendo definido dentro do modelo ARM, o slot de produção e o slot de teste estão imediatamente recebendo a nova versão do aplicativo logo após a Etapa 2 (antes mesmo de ocorrer uma troca). Acredito que é disso que as pessoas estão falando quando dizem "operação de troca não intencional".

Nós _NÃO_ queremos definir as configurações de slot de produção em nosso modelo ARM e _NÃO_ queremos que nenhuma das configurações de slot de produção seja removida como resultado da execução de nosso modelo ARM. A maneira como a implantação do modelo ARM no modo Completo funciona é que, se especificarmos quaisquer configurações para o slot de produção, todas as configurações que não forem explicitamente especificadas serão removidas automaticamente.

Espero que isso tudo faça sentido. No momento, estamos tentando remover WEBSITE_CONTENTSHARE de nosso modelo ARM, na esperança de que o tempo de execução gere o valor em todos os cenários e não leve mais a "trocas não intencionais".

Olá a todos, sou o desenvolvedor principal de slots de implantação e tratarei de suas preocupações em relação à configuração de WEBSITE_CONTENTSHARE e WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:

Aqui está a orientação oficial:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Isso sempre deve ser definido, pois informa o serviço de aplicativo que você está usando arquivos azure para armazenamento de conteúdo.

WEBSITE_CONTENTSHARE:

• Isso agora pode ser omitido completamente de seus modelos ARM para funções de sku de consumo, que irão gerar automaticamente o campo e evitar trocas não intencionais. Isso significa que você pode usar o mesmo modelo para criação e atualizações posteriores.

• Infelizmente, descobrimos que esta geração automática de WEBSITE_CONTENTSHARE foi negligenciada para o esqui Elastic Premium, então a questão de ter que incluí-lo durante a criação e omiti-lo durante as atualizações ainda permanece. A correção para isso está em andamento e atingiu metade da nossa frota. Ele deve ser totalmente implementado nas próximas 2 semanas e, depois disso, a orientação será a mesma para ambos os skus e WEBSITE_CONTENTSHARE pode ser omitido completamente.

Espero que isso resolva algumas de suas preocupações!

@shubDhond Muito obrigado. Podemos obter uma atualização oficial da documentação?

@shubDhond para planos de consumo do Windows se eu fornecer apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Recebo um erro por meio da implantação do modelo arm informando que está faltando WEBSITE_CONTENTSHARE.
Não preciso usar slots. Se omitido, a implantação é realizada, mas recebo o aviso "o armazenamento não está configurado. A seleção de funções será limitada".

Qual é a orientação sobre os planos de consumo em relação a esses dois parâmetros que estou usando .net principal plano de consumo do Windows?

Idem! Eu também recebo esse erro. Quando isso vai ser corrigido?

Eu tenho o mesmo problema de consumo e plano elástico, está nos causando muitos problemas com implantações automatizadas.

Tive algum sucesso ao omitir WEBSITE_CONTENTSHARE para Premium ao implantar configurações diretamente nas propriedades Microsoft.Web/sites (siteConfig, appSettings), mas não ao especificar as configurações como um recurso separado usando Microsoft.Web/sites/config com "type": "config" .

@shubDhond Esse problema definitivamente não foi corrigido. No plano de Consumo do Windows, se você implantar um modelo apenas com WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e sem WEBSITE_CONTENTSHARE, receberá o erro "WEBSITE_CONTENTSHARE está faltando".

Tentar usar as tarefas de implantação do Serviço de Aplicativo no Azure DevOps e definir apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING também produzirá um erro HTTP 400.

A automação de aplicativos do Azure Function no plano de consumo está totalmente interrompida.

Tendo o mesmo problema de @clawrenceks

Também estamos enfrentando o mesmo problema que @clawrenceks.
Também não podemos definir apenas WEBSITE_CONTENTAZUREFILECONNECTIONSTRING sem WEBSITE_CONTENTSHARE por meio do portal do Azure. Também temos WEBSITE_RUN_FROM_PACKAGE definido como 1.

Também não tenho certeza de como isso funcionará quando você tiver o modo de implantação do modelo ARM definido como Complete ? Não removerá a configuração de aplicativo gerada WEBSITE_CONTENTSHARE ?

Como a maioria, também estamos perdidos.

Agora tenho meu modelo ARM implantando com sucesso meu aplicativo de funções em um Plano de Consumo do Windows. Quando implementado, a mensagem Storage is not configured, Function scaling will be limited. Click to learn more não é mais exibida. As trocas de slots também estão funcionando conforme o esperado.

Minhas principais conclusões desse processo são:

Se você atualmente tem um aplicativo Azure Function SEM as configurações de aplicativo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE , acredito que a única maneira de corrigir isso é reimplantar seu aplicativo, garantindo que o WEBSITE_CONTENTAZUREFILECONNECTIONSTRING configuração

Ter o WEBSITE_CONTENTAZUREFILECONNECTIONSTRING no lugar como parte da criação do recurso é fundamental. Ao usar o ARM, minhas descobertas são que ele deve ser implantado como uma configuração de aplicativo durante a implantação do serviço de aplicativo principal, com um tipo de recurso de Microsoft.Web/sites . Ter um tipo de recurso separado de Microsoft.Web/sites/config em seu modelo ARM para implantar as configurações do aplicativo não funcionará.

Não incluo a configuração WEBSITE_CONTENTSHARE em meu modelo ARM. Isso é criado pelo tempo de execução quando meu modelo ARM é implantado. Isso é um sinal de que a implantação está funcionando bem. Com a abordagem descrita aqui, posso implantar os recursos iniciais e, em seguida, reimplantar o modelo várias vezes sem receber erros relacionados à configuração WEBSITE_CONTENTSHARE .

Um requisito-chave separado para mim era que as configurações do aplicativo do site de produção só deveriam ser implantadas durante a criação inicial do recurso. A única maneira de obter novas (futuras) configurações de aplicativos no site de produção é por meio de uma troca de slot. Para conseguir isso, adicionei alguma lógica em meu modelo ARM para lidar com o seguinte.

1) As configurações do aplicativo no modelo ARM só serão implantadas no site de produção durante a criação inicial do site; elas não serão adicionadas ao site de produção como parte de implantações futuras.

2) As configurações do aplicativo no modelo ARM são sempre aplicadas ao slot de teste. Eles são então colocados em produção usando um slot de troca.

Para conseguir o que foi dito acima, os appSettings para o site de produção em meu modelo ARM são condicionais. Se o recurso não existir, implanto o conjunto completo de configurações do aplicativo no modelo (para garantir que o serviço do aplicativo seja criado corretamente). Se o recurso já foi criado, passo um nulo para as configurações do aplicativo. Quando implantado, isso retém as configurações do aplicativo que já estão em vigor para o site de produção.

Também estou totalmente confuso. Se WEBSITE_CONTENTAZUREFILECONNECTIONSTRING for necessário para planos de consumo, mas não puder ser configurado para ficar em um slot, como vou trocar entre um slot de teste e de produção onde quero que cada um seja executado em uma conta de armazenamento diferente? Isso sempre foi possível com os aplicativos da Web e parece um caso de uso muito comum. Pelo que eu posso dizer, a troca de slots de aplicativos de função está completamente quebrada / inutilizável até que isso seja corrigido. Adoraria que alguém me dissesse por que / como estou errado! Eu sei que o problema original faz referência a modelos ARM, mas esse parece ser um problema muito mais amplo.

Mesmo problema no plano Elastic Premium. Implementar no slot de estágio o mesmo modelo ARM com o mesmo WEBSITE_CONTENTSHARE torna o slot de produção apontando para os mesmos binários do slot de estágio.
Não consigo implantar sem WEBSITE_CONTENTSHARE porque recebo o erro 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest'

Estou confuso. Qual é a coisa certa a fazer?

Se você está operando com premium elástico ou consumo, deve atender a um dos seguintes critérios:

Você deve ter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE definidos

ou

Se estiver usando run from zip / package, você deve ter "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP" ou "WEBSITE_RUN_FROM_PACKAGE" definido como algo diferente de vazio, 0 ou 1

como @ehamai diz?

ou

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: Isso sempre deve ser definido, pois informa o serviço de aplicativo que você está usando arquivos azure para armazenamento de conteúdo.

WEBSITE_CONTENTSHARE:

Isso agora pode ser omitido completamente de seus modelos ARM para funções de sku de consumo, que irão gerar automaticamente o campo e evitar trocas não intencionais. Isso significa que você pode usar o mesmo modelo para criação e atualizações posteriores.

Infelizmente, descobrimos que esta geração automática de WEBSITE_CONTENTSHARE foi negligenciada para o esqui Elastic Premium, então a questão de ter que incluí-lo durante a criação e omiti-lo durante as atualizações ainda permanece. A correção para isso está em andamento e atingiu metade da nossa frota. Ele deve ser totalmente implementado nas próximas 2 semanas e, depois disso, a orientação será a mesma para ambos os skus e WEBSITE_CONTENTSHARE pode ser omitido completamente.

Espero que isso resolva algumas de suas preocupações!

como @shubDhond diz?

Recebo um erro se eu tiver uma função azul no plano de consumo sem WEBSITE_CONTENTSHARE (na verdade, o slot de produção não tem configurações de aplicativos) em qualquer slot e eu:

1. implantar ARM no slot de teste
2. troca
3. reimplantar no slot de teste

Em seguida, ele me diz que preciso do WEBSITE_CONTENTSHARE. É como se ele não pudesse gerar um compartilhamento para o slot de produção antigo. Eu não tentei remover o WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, porque este tópico diz para não fazer isso, exceto @ehamai , que me diz que eu posso fazer isso, se eu fizer um "WEBSITE_RUN_FROM_PACKAGE".

O engraçado é que tenho uma função em execução com esta configuração, mas com um tempo de execução de ~ 2 em vez de ~ 3, e está funcionando. Há um problema com ~ 3 e slots de implantação?
Isso é muito confuso.

Não importa o que esta troca espontânea de slots seja muito assustadora, de qualquer forma, como precisamos criar essas duas variáveis WEBSITE_ , estamos preenchendo o último ARM nós mesmos, conforme a definição aqui . A ferramenta diagonóstica de configuração do webapp no ​​portal não mostra mais erros.

reatribuir: @mattchenderson

alguma atualização disso?

Nós também fomos informados pelo suporte da Microsoft de que a propriedade "WEBSITE_CONTENTSHARE" deve ser definida. Quando não é possível defini-lo como uma configuração de slot, isso é bastante problemático para nossos pipelines de construção e modelos ARM. Conselho por favor!

Também concordo. É realmente hora de alguma explicação sobre como usar slots aqui!

Também concordo, este tópico foi iniciado há mais de 15 meses e ainda não há uma resolução estável.
Não podemos usar slots até que isso tenha sido devidamente resolvido com uma solução confiável. Os slots são um recurso fantástico, mas precisam ser confiáveis.

Olá a todos,

Sentimos muito pelo atraso na resposta aqui, este tópico não estava sendo monitorado tão bem quanto deveria.

Para resolver a confusão, o comportamento descrito por @clawrenceks acima está correto a partir de agora. Para sites que ainda não têm o armazenamento de Arquivos do Azure configurado, você será solicitado a fornecer WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE. Depois que eles forem fornecidos e seu aplicativo estiver configurado para ser executado em Arquivos do Azure, você pode omitir WEBSITE_CONTENTSHARE de seus modelos para evitar a troca inadvertida de seu conteúdo.

A maneira como a API funciona atualmente é que na criação do site (recurso 'Microsoft.Web / sites'), se você fornecer WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e não WEBSITE_CONTENTSHARE, um compartilhamento de conteúdo será gerado para você. No entanto, nas atualizações de um recurso existente 'Microsoft.Web / sites' ou 'Microsoft.Web / sites / config', a API verifica se já existe um valor para WEBSITE_CONTENTSHARE para o aplicativo e se ele não está presente , ele gera um erro.

Suponho que isso foi para proteger contra os clientes apagando inadvertidamente seu conteúdo ao mudar para arquivos azure, no caso de eles fornecerem WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e gerarmos um novo WEBSITE_CONTENTSHARE para eles (essencialmente limpando seu conteúdo, pois esse compartilhamento seria novo). Isso é muito mais seguro durante a criação do site porque ele começaria do zero de qualquer maneira e não corremos o risco de apagar seu conteúdo.

Eu posso entender totalmente a confusão para todos vocês que desejam arquivos azuis. Terei que pensar em como resolver isso da melhor maneira, mantendo nossas operações de atualização protegidas contra a exclusão de seu conteúdo. Por enquanto, a orientação para todos vocês que não têm arquivos azure configurados e desejam fazer a troca, você precisará fornecer WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE para a troca inicial e então a orientação seria a mesma para omitir WEBSITE_CONTENTSHARE de seu modelo posteriormente.

Se houver alguma sugestão de como você gostaria de ver o caso de atualização tratado, isso também seria muito apreciado!

@shubDhond, portanto, precisamos implantar as configurações de conexão e compartilhamento de conteúdo na primeira implantação no slot de produção, mas não nas implantações depois disso. Existe alguma maneira de fazer isso automaticamente? Como detectar se um recurso foi implantado por meio do ARM? Ou precisamos passar essas informações manualmente para o ARM (fx por meio de um parâmetro que informa se esta é a primeira implantação?

@mslot, infelizmente, não acho que seja possível dizer em um modelo se um recurso já existe ou não, mas isso deve ser possível com isso (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) combinado com um parâmetro passado ao modelo informando se o site já está configurado para Arquivos do Azure. Isso pode ser determinado obtendo o site e ver se as configurações do aplicativo têm WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE.

@mslot, infelizmente, não acho que seja possível dizer em um modelo se um recurso já existe ou não, mas isso deve ser possível com isso (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) combinado com um parâmetro passado ao modelo informando se o site já está configurado para Arquivos do Azure. Isso pode ser determinado obtendo o site e ver se as configurações do aplicativo têm WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE.

Eu realmente espero que isso seja corrigido em breve. Ele torna o uso de slots inútil no meu fluxo de trabalho. Ele precisa ser totalmente automatizado. Esta solução é uma solução alternativa aos meus olhos e não faz sentido introduzi-la quando está funcionando para webapps porque diverge muito em algo que deveria funcionar da mesma forma, introduzindo "magia negra" para outras pessoas que entram em um projeto.

Eu realmente espero que isso seja corrigido para que possamos começar a usá-lo. Acho que isso impede muitas pessoas de usar esse recurso.

@mslot Eu entendo totalmente sua dor com isso e lamento não ter sido capaz de identificar esse problema antes. Falarei com os desenvolvedores que inicialmente implementaram esse comportamento na próxima semana e veremos se podemos encontrar uma solução segura para esse problema que possa evitar a possibilidade de os clientes inadvertidamente passarem a usar um compartilhamento de arquivos azul vazio para seu conteúdo. Assim que tivermos uma solução proposta, atualizarei aqui.

@shubDhond Eu realmente não entendo a "parte" dos Arquivos do Azure. Implanto meu projeto do Azure Function usando o Azure DevOps criando primeiro um espaço de implantação, implanto nele e depois troco. Estou usando o método de implantação "RunFromPackage" e isso não parece funcionar ao usar um StorageAccount clássico. NÃO estou usando Arquivos do Azure e parece que tenho o mesmo problema relacionado à configuração WEBSITES_CONTENTSHARE para os dois slots.

Olá @cannehag, poderia abrir um novo problema para isso? Pode haver algum comportamento estranho acontecendo com a configuração do aplicativo RunFromPackage sendo marcada como fixa, causando sintomas semelhantes aos descritos aqui. Eu sugeriria um novo problema para não adicionar confusão aqui, pois os problemas provavelmente não estão relacionados.