Obrigado pelo feedback! Estamos investigando no momento e atualizaremos você em breve.

@gs9824 você pode fornecer mais algumas informações sobre grafana? Não conheço este serviço.

@MicahMcKittrick-MSFT , Grafana é uma ferramenta para visualizar dados de diferentes fontes através de dashboards. O problema de executar o Grafana como um contêiner docker é que as configurações não são mantidas ao reiniciar o contêiner docker.
A solução para isso é armazenar a configuração em armazenamento persistente, para que uma reinicialização não resulte em perda de configuração.
Eu tento usar um compartilhamento de arquivos do Azure para isso e montá-lo no contêiner (/var/lib/grafana). Dessa forma, a configuração é mantida.
Parece que o Grafana pode criar arquivos dentro desse armazenamento (posso ver isso através do gerenciador de armazenamento), mas não parece ser capaz de atualizar nenhum arquivo

t=2018-10-09T14:20:36+0000 lvl=eror msg=“Server shutdown” logger=server reason=“Service init failed: Migration failed err: database is lock”

O banco de dados é armazenado no compartilhamento de arquivos.

No compartilhamento de arquivos é possível criar direitos de acesso para usuários, mas não vejo como posso especificá-los no comando de criação de contêiner.

@ gs9824 você olhou para usar um disco permanente com AKS?

https://docs.microsoft.com/en-us/azure/aks/azure-disks-dynamic-pv

@ gs9824 alguma atualização sobre isso?

@MicahMcKittrick-MSFT , desculpe ainda não. Primeiro, tentei fazer o compartilhamento de arquivos funcionar tentando executar alguns comandos chmod durante a criação do contêiner. Até agora sem sorte.

@MicahMcKittrick-MSFT Pelo que entendi, isso envolveria a configuração de um cluster AKS completo. Eu só queria executar o Grafana como uma instância de contêiner do Azure simples, sem modificar nada no contêiner.

@seanmck. @iainfolds algum de vocês teria alguma opinião sobre isso?

@ gs9824 apenas para sua informação, estou trabalhando offline para obter uma resposta para isso. Vou atualizá-lo assim que tiver mais informações.

@ gs9824, uma vez que se destina a ser uma instância de longa execução e ver muitas reinicializações, talvez seja necessário adicionar uma linha de comando de longa duração ao comando az container create , como --command-line "tail - f /dev/null".

Além disso, verifique este guia para opções adicionais de solução de problemas

https://docs.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting#container -continually-exits-and-restarts-no-long-running-process

@ gs9824 alguma atualização sobre isso?

Olá

Coincidentemente, tenho exatamente o mesmo problema para exatamente o mesmo caso de uso (Grafana).

O Grafana registra o seguinte erro:
lvl=eror msg="Server shutdown" logger=server reason="Service init failed: Migration failed err: database is locked"
E, como resultado, o contêiner termina.
--command-line "tail -f /dev/null" para mim apenas impede que o log seja exibido, mas o grafana ainda não inicia e o contêiner termina.

Começando sem apontar o grafana para o mount, ele usará uma pasta local, que funciona. No Portal do Azure, tentei escrever pastas e arquivos na montagem manualmente, o que funciona bem.

Aqui está um modelo ARM para que você possa reproduzir o problema. Basta substituir alguns dos espaços reservados que adicionei e você deve estar pronto.

{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "SOME_CONTAINER_GROUP_NAME": { "defaultValue": "CONTAINER_GROUP_NAME", "type": "String" } }, "variables": {}, "resources": [{ "comments": "Generalized from resource: '/subscriptions/SUBSCRIPTION_ID/resourceGroups/grafana-test/providers/Microsoft.ContainerInstance/containerGroups/CONTAINER_GROUP_NAME'.", "type": "Microsoft.ContainerInstance/containerGroups", "name": "[parameters('SOME_CONTAINER_GROUP_NAME')]", "apiVersion": "2018-04-01", "location": "westeurope", "scale": null, "properties": { "containers": [{ "name": "[parameters('SOME_CONTAINER_GROUP_NAME')]", "properties": { "image": "grafana/grafana", "command": [], "ports": [{ "protocol": "TCP", "port": 3000 },{ "protocol": "TCP", "port": 80 } ], "environmentVariables": [{ "name": "GF_INSTALL_PLUGINS", "value": "grafana-azure-monitor-datasource" },{ "name": "GF_PATHS_DATA", "value": "/mnt/grafana" } ], "resources": { "requests": { "memoryInGB": 1.5, "cpu": 1 } }, "volumeMounts": [{ "name": "grafana-storage", "mountPath": "/mnt/grafana", "readOnly": false } ] } } ], "volumes": [{ "name": "grafana-storage", "azureFile": { "shareName": "grafana-test", "readOnly": false, "storageAccountName": "SOMESTORAGE_ACCOUNT", "storageAccountKey": "SOMESTORAGE_KEY" } } ], "restartPolicy": "Always", "ipAddress": { "ports": [{ "protocol": "TCP", "port": 3000 },{ "protocol": "TCP", "port": 80 } ], "type": "Public" }, "osType": "Linux" }, "dependsOn": [] } ] }

@MicahMcKittrick-MSFT Desculpe por não responder antes - é bom saber que não sou o único com o problema :). Enquanto isso, tenho o Grafana em execução em uma VM como solução alternativa (instalado pelo Market Place - Grafana do Grafana Labs). A reinicialização provavelmente acontece porque o grafana falha ao iniciar devido ao banco de dados bloqueado como estados @orendin .

Obrigado a todos pelos detalhes extras.

Não tenho certeza se esta é uma informação que podemos incluir neste documento, mas, independentemente disso, atribuirei ao autor para revisar e ver se podemos adicionar algum detalhe.

Olá, estou com o mesmo problema, com o prometheus desta vez.

mesmo cenário de caso, estou usando uma imagem do prometheus para criar uma ACI montada com um compartilhamento de arquivos.

o que eu fiz: início do script

echo" parameters"
ACI_PERS_RESOURCE_GROUP=ftp-group-container
ACI_PERS_LOCATION=some_location
ACI_PERS_SHARE_NAME=some_share

echo" Create the storage account with the parameters "
az storage account create \
--resource-group $ACI_PERS_RESOURCE_GROUP \
--name $ACI_PERS_STORAGE_ACCOUNT_NAME \
--location $ACI_PERS_LOCATION \
--sku Standard_LRS

echo " create file share"
az storage share create --name $ACI_PERS_SHARE_NAME --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME

echo" get the storage key " STORAGE_KEY=$(az storage account keys list --resource-group $ACI_PERS_RESOURCE_GROUP --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME --query "[0].value" --output tsv)
echo "storage key : "$STORAGE_KEY

echo" create a container instance "
az container create -g some-container-group \
--name prometheus-instance \
--image prom/prometheus \
--restart-policy OnFailure \
--ports 9090 \
--dns-name-label some-label \
--ip-address public \
--azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
--azure-file-volume-account-key $STORAGE_KEY \
--azure-file-volume-share-name $ACI_PERS_SHARE_NAME \
--azure-file-volume-mount-path /etc/prometheus/

final do roteiro

eu adicionei um arquivo YAML no arquivo de compartilhamento 'prometheus.yml'

o que eu esperava

eu esperava que a ACI iniciasse e lesse o arquivo YAML que criei no arquivo de compartilhamento enquanto montava o /etc/prometheus nele

o que realmente aconteceu

a ACI não conseguiu parar de reiniciar, porque precisa obter a configuração de '/etc/prometheus/prometheus.yml' e o erro é
err="error loading config from \"/etc/prometheus/prometheus.yml\": couldn't load configuration (--config.file=\"/etc/prometheus/prometheus.yml\"): open /etc/prometheus/prometheus.yml: permission denied

o que eu tentei fazer

consegui acessar o sistema de arquivos para adicionar as permissões,
drwx------ 2 root root 0 Nov 15 21:33 prometheus.yml
chmod a+rwx prometheus.yml
drwx------ 2 root root 0 Nov 15 21:34 prometheus.yml

como você pode ver, mesmo com chmod como root no arquivo, não consegui alterar as permissões. então pode ser por isso que não consigo fazer com que o ACI leia o arquivo YAML conf

Obrigado por qualquer ajuda.

Oi pessoal,
consertei meu problema.

o que estava faltando

az storage share policy create --help

o que eu fiz

Eu adicionei uma política de compartilhamento com todas as permissões (ler-escrever-lista) necessárias e funcionou.
não tenho mais o problema de permissão na ACI

espero que isso ajude

Ei,
Estou enfrentando o mesmo problema ao implantar a imagem neo4j como instância de contêiner.
Obrigado por todo o trabalho em torno mencionado acima. Tentei todos eles.
Problema

• Eu tenho um compartilhamento de arquivos, criado para o contêiner no mesmo grupo de recursos. O compartilhamento de arquivos deve ser montado como disco permanente no contêiner.
• Conforme esperado, o compartilhamento de arquivos foi montado, mas não foi possível ler os dados.
• Problemas de direitos de acesso.
  
  
  

_ Referências _

{
    "....": [],
    "properties": {
        "containers": [
            {
                "....": [],
                "environmentVariables": [],
                "resources": {
                    "requests": {
                        "memoryInGB": 4,
                        "cpu": 1
                    }
                },
                "volumeMounts": [
                    {
                        "name": "data",
                        "mountPath": "/var/lib/neo4j/data/"
                    }
                ]
            }
        ]
    },
    "....": [],
    "volumes": [
        {
            "name": "data",
            "azureFile": {
                "shareName": "neo4jfiles",
                "storageAccountName": "neo4jcontainerstorage",
                "storageAccountKey": "<I-REVEALED-MY-SECRET-KEY>"
            }
        }
    ],
    "....": []
}

O problema original parece estar resolvido. Adicionando @dkkapur por segundo se você tiver comentários. Obrigado.

Alguém resolveu o problema do Grafana? Infelizmente ainda recebo o erro

„lvl=eror msg="Server shutdown" logger=server reason="Service init failed: Migration failed err: database is locked"

Criei uma "Política de Acesso" com todos os direitos, mas não sei se preciso especificar isso de alguma forma ao montar o volume

"resources": [
    {
      "apiVersion": "2018-10-01",
      "type": "Microsoft.ContainerInstance/containerGroups",
      "location": "[parameters('location')]",
      "name": "[parameters('containerName')]",
      "properties": {
        "containers": [
          {
            "name": "[parameters('containerName')]",
            "properties": {
              "image": "[parameters('imageName')]",
              "ports": "[parameters('ports')]",
              "environmentVariables": [
                {
                  "name": "GF_PATHS_DATA",
                  "value": "/mnt/grafana/data"
                },
                {
                  "name": "GF_PATHS_LOGS",
                  "value": "/mnt/grafana/logs"
                },
                {
                  "name": "GF_DASHBOARDS_PATH",
                  "value": "/mnt/grafana/dashboards"
                }
              ],
              "volumeMounts": [
                {
                  "name": "grafana-storage",
                  "mountPath": "/mnt/grafana",
                  "readOnly": false
                }
              ],
              "resources": {
                "requests": {
                  "cpu": "[int(parameters('numberCpuCores'))]",
                  "memoryInGB": "[float(parameters('memory'))]"
                }
              }
            }
          }
        ],
        "volumes": [
          {
            "name": "grafana-storage",
            "azureFile": {
              "shareName": "grafana",
              "readOnly": false,
              "storageAccountName": "_NAME_",
              "storageAccountKey": "_ACCESS_KEY_"
            }
          }
        ],
        "restartPolicy": "[parameters('restartPolicy')]",
        "osType": "[parameters('osType')]",
        "ipAddress": {
          "type": "[parameters('ipAddressType')]",
          "ports": "[parameters('ports')]",
          "dnsNameLabel": "[parameters('dnsNameLabel')]"
        }
      },
      "tags": {}
    }
  ]

Microsoft, corrija o fato de que o armazenamento de compartilhamento de arquivos montado exige que o contêiner seja executado como root, pois isso vai contra as práticas recomendadas do docker. Além disso, elimina muitos contêineres que não são executados como root e precisam de armazenamento de arquivos.

Acho que o problema subjacente com o Grafana é que a imagem do docker não é executada como root.

Fileshare parece estar montado como root:root 777. Qual é o padrão.

Quando o usuário do Grafana tentar acessar o armazenamento montado, ele falhará. Você também não pode CHOWN o armazenamento montado, eu escalei o usuário de volta para ROOT e em um init.sh scipt tentei atribuir permissões ao usuário do Grafana. Sem sorte.

Você também não tem permissões suficientes dentro de um contêiner ACI para montar outros compartilhamentos de arquivos, a montagem cifs falha.

Solução proposta: flutuar a capacidade de especificar opções de montagem, da mesma forma que no Azure AKS.
No Kubernetes/AKS, você pode montar um compartilhamento de arquivos do Azure, mas pode especificar opções de montagem, como GID, UID e as permissões padrão.

@dlepow @dkkapur Alguma notícia sobre este tópico?

Atribuindo ao Deep para acompanhamento. Obrigado!

atribuir:@dkkapur

@dkkapur alguma atualização?

oi gente!
finalmente encontrei esse problema ... gaste 10 horas tentando fazer uma solução alternativa

alguma novidade sobre isso? parece atribuído há mais de um ano, mas sem resposta

O mesmo acontece com uma imagem padrão do Postgresql Docker - se você tentar tornar o banco de dados persistente montando um compartilhamento de arquivo, ele não será iniciado.

@MicahMcKittrick-MSFT Ei Micah, alguma atualização sobre isso?

@dkkapur Existe algum plano para permitir que o contêiner ACI monte o compartilhamento de arquivos do

opções de montagem:
- modo_dir=0777
- modo_arquivo=0777
- uid=1000
- gi = 1000
- mfsymlinks
- nobrl
- cache=nenhum

Acho que o problema subjacente com o Grafana é que a imagem do docker não é executada como root.

Exatamente. Ele usa um usuário de permissão limitada chamado grafana (se não for alterado deliberadamente).

Esse problema está basicamente impedindo qualquer vinculação de armazenamento persistente na produção porque não podemos confiar na integridade do contêiner do Docker, que é exatamente o motivo pelo qual usamos os contêineres do Docker em primeiro lugar. Existe algum armazenamento habilitado para usuário não elevado ao qual possamos anexar?

Oi,
alguma atualização disso ?

Estou enfrentando o mesmo problema com um contêiner postgreSQL no qual gostaria de montar um compartilhamento de arquivos em /var/lib/postgresql/data para persistir um pequeno banco de dados em várias versões de contêiner, mas o banco de dados não tem permissão para use o compartilhamento de arquivos montado.

Aqui estão os logs que são gerados na Instância de Contêiner do Azure:

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 20
selecting default shared_buffers ... 400kB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
2020-08-28 07:12:06.201 UTC [83] FATAL:  data directory "/var/lib/postgresql/data" has wrong ownership
2020-08-28 07:12:06.201 UTC [83] HINT:  The server must be started by the user that owns the data directory.
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/data"
running bootstrap script ...

E então o recipiente para.

Também sou bastante novo na implantação de contêineres no azure, portanto, se essa não for a maneira pretendida de fazer isso, ficaria feliz em aprender algo novo.
(PS: Acabei de notar que alessiostalla já mencionou que isso também afeta as imagens do postgreSQL)