Azure-docs: Aplicativo da Web com imagem docker personalizada no registro de contêiner azure - variáveis ​​de ambiente

@timmydo Obrigado pelo feedback. Estamos investigando ativamente e entraremos em contato com você em breve.

Ei @timmydo - vou analisar isso hoje e compartilhar todas as descobertas relevantes. Apenas para esclarecer, você não está definindo variáveis ​​de ambiente em seu Dockerfile usando ENV antes de enviar sua imagem personalizada para o Azure Container Registry? Além disso, verifique os seguintes documentos, caso não os tenha visto:

Definir variáveis ​​de ambiente em suas instâncias de contêiner
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-using-azure-container-registry
Implantar em instâncias do Azure Container do Azure Container Registry
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-environment-variables

Obrigado pelos links. Acho que eles podem ser mais voltados para o funcionamento de contêineres de forma independente. Em meu cenário, estou executando um contêiner dentro do serviço de aplicativo da web, portanto, não posso usar alguns desses comandos. (Suponho que o serviço de aplicativo da web inicia meu contêiner e encaminha as solicitações http para a porta 80 nele)

Não estou definindo env vars em meu dockerfile porque meu dockerfile é verificado em um repositório git público e não quero colocar segredos lá. Suponho que eu poderia contornar isso criando outro dockerfile secreto com variáveis ​​de ambiente, mas seria mais conveniente colocá-lo no portal azure (talvez na seção de configurações do aplicativo da web azure?).

@timmydo Sim, definitivamente não é o ideal quando em um repo público. Portanto, os valores de configuração (chave, pares de valor) definidos por meio das configurações do aplicativo são disponibilizados para o seu aplicativo em seu tempo de execução como environment variáveis, não durante o tempo de implantação . Você pode usar o serviço Azure Key Vault em seu Dockerfile para buscar os valores de configuração, mas você ainda precisa expor tenant_id , subscription_id etc em seu Dockerfile (a menos você escolhe defini-los em um arquivo env separado que não é verificado em seu repo). Aqui está um exemplo, caso este cenário seja útil:

Com isso dito, verifique o seguinte documento, onde discute a definição de uma implantação personalizada (processo de construção) com VSTS para Web App for Containers:

Por que usar uma definição de versão separada em vez do recurso de implantação automática disponível no Web App for Containers?
https://docs.microsoft.com/en-us/vsts/build-release/apps/cd/deploy-docker-webapp?view=vsts

Esse documento está vinculado a um documento que informa como construir um contêiner usando VSTS, mas aquele documento que explica como construir um contêiner com uma etapa do VSTS não menciona nada sobre como manipular segredos / variáveis ​​de ambiente. A tarefa do VSTS para construir uma imagem do docker requer um dockerfile com check-in no repositório.

Eu poderia fazer um script do powershell embutido gerar um dockerfile em algum lugar antes de executar a etapa de compilação do docker, mas parece um hack. Acho que isso é principalmente culpa do docker

Talvez uma alternativa seja usar uma definição de pod yaml de kubernetes no aplicativo da web no portal azure para definir as variáveis ​​de ambiente, mas não consigo encontrar nenhum bom documento sobre isso. Não parece o lugar certo para colocar a configuração, pois acho que essas definições de pod fazem mais sentido verificadas no controle de origem.

Quem seria a pessoa certa para fazer uma solicitação de recurso para permitir a passagem de env vars para o comando docker run no portal azure?

@neilpeterson teria

Eu não trabalhei com aplicativos da web, no entanto, uma varredura rápida do documento mostra que podemos usar --settings ao usar a CLI.

--settings WEBSITES_PORT=8000

Olhando para o portal, não vejo uma maneira muito direta de fazer isso. Como @timmydo apontou, parece que podemos consumir um arquivo de manifesto do Docker Compose ou Kubernetes, que devem resolver o problema.

Portanto, um arquivo de composição como este deve funcionar (eu confirmei).

version: '3'
services:
  demo-env:
    image: microsoft/sample-aks-helloworld
    container_name: aks-helloworld
    environment:
      TITLE: test-environment-var

Dito isso, eu também esperaria algo mais básico, semelhante ao argumento --settings CLI.

@ SyntaxC4 e ideias sobre este?

@timmydo resolvemos isso usando o azure cli para definir nossas variáveis ​​de configuração do aplicativo. Todas essas variáveis ​​acabam no ambiente do docker cmd / entrypoint lançado. por exemplo
az webapp config appsettings set --name webapp-name --resource-group dev --settings DB_NAME = dbname DB_HOST = ourhost.database.windows.net DB_USER = dbuser DB_PASSWD = passwd WEBSITES_ENABLE_APP_SERVICE_STORAGE = true

Então, pelo menos, eles não estão no controle de origem.

@saschwarz Não acho que as configurações do aplicativo azul sejam passadas para -e options no comando docker run para aplicativos da web de contêiner?

@timmydo Talvez estejamos falando sobre maneiras diferentes de executar contêineres docker no Azure? Em WebApps para contêineres, não emito docker run . Eu envio a imagem para nosso registro privado do azure, seleciono a tag na instância do WebApp c / no portal (ou através do azure cli) e ela é implementada / executada com as configurações do aplicativo injetadas no ambiente:

https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/#SetEnvVar

@timmydo Envie uma solicitação de recurso no site de Comentários do Azure para que a comunidade possa votar a favor desse recurso e nossa equipe de produto possa revisar para implementação futura.

Agora prosseguiremos para fechar este tópico. Se houver mais perguntas sobre este assunto, reabra-o e teremos o prazer de continuar a discussão.

Este tópico é exatamente o que eu estava / procuro há dias. No final, coloquei uma pergunta sobre stackoverflow (https://stackoverflow.com/questions/50681821/deploy-azure-webapp-with-custom-container-environment-variables) para obter uma resposta à minha pergunta.
Minha solução alternativa também foi usar um arquivo docker-compose, mas com docker-compose não é (ainda) possível usar imagens ACR.

A mesma pergunta aqui. Por enquanto, só quero dizer: estúpido azul!

Olá a todos,

Alguma solução alternativa para este tópico? Estamos enfrentando o mesmo problema em 2019 ao tentar passar variáveis ​​de ambiente (parâmetros) para minha imagem docker privada por meio de um serviço de aplicativo, aplicativo da Web para contêiner ou contêineres simples no Azure ... é sempre o mesma saída com falha

Use as configurações do aplicativo na guia de configuração nas configurações de seção no serviço de aplicativo. Cada configuração do aplicativo é passada para o contêiner como uma variável env.

Ainda estamos vendo um problema em que nosso aplicativo .nercore em um contêiner que está sendo retirado do ACR não está pegando as configurações do aplicativo do Serviço de Aplicativo no portal do Azure. Os valores não são injetados automaticamente em tempo de execução, conforme sugere a documentação.

Sinto que poder adicionar variáveis ​​de ambiente ao comando docker run é um recurso muito básico e essencial.

Não estou surpreso que novamente o Azure consegue transformar algo trivial em um problema que me leva muito tempo para corrigir.

Estamos usando configurações de aplicativos para injetar variáveis ​​em imagens docker personalizadas e aplicativos docker compose por 5 meses sem nenhum problema ...

Ao seguir o log stream do meu contêiner, posso ver o comando real que é executado para girar o contêiner. Embora contenha os seguintes ENV_VARS , os que defini como configurações do aplicativo ainda estão faltando.

docker run -d -p 7312:80 --name container_name -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=appservice-name -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=appservice-name.azurewebsites.net -e WEBSITE_INSTANCE_ID=INSTANCE_ID -e HTTP_LOGGING_ENABLED=1 repo.azurecr.io/container:tag

Parece que as variáveis ​​de ambiente são injetadas quando o entrypoint é executado, mas depois elas não estão mais acessíveis. Muito irritante.

Tendo o mesmo problema após uma implantação e não consigo colocá-lo novamente online. a produção caiu por 5 horas