Azure-docs: Derechos de acceso al archivo compartido

Creado en 9 oct. 2018  ·  29Comentarios  ·  Fuente: MicrosoftDocs/azure-docs

Probé este flujo de trabajo en https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files con grafana

contenedor az crear --resource-group--nombre--image grafana/ grafana:último --dns-name-label--ports 3000 --azure-file-volume-account-name $STORAGE_ACCOUNT --azure-file-volume-account-key $STORAGE_KEY --azure-file-volume-share-name $ACI_PERS_SHARE_NAME --azure-file-volume -ruta-de-montaje /var/lib/grafana --cpu 1 --memoria 1

El contenedor sigue reiniciando, probablemente debido a que grafana no puede actualizar los archivos en el recurso compartido persistente. ¿Cómo puedo asegurarme de que los derechos de acceso estén configurados correctamente en el recurso compartido? ¿Puedo conectarme usando una política establecida en el recurso compartido de archivos?


Detalles del documento

No edite esta sección.

Pri2 assigned-to-author container-instancesvc doc-enhancement triaged

Comentario más útil

Microsoft, solucione el hecho de que el almacenamiento compartido de archivos montado requiere que el contenedor se ejecute como root, ya que esto va en contra de las mejores prácticas de Docker. Además, elimina muchos contenedores que no se ejecutan como root y necesitan almacenamiento de archivos.

Creo que el problema subyacente con Grafana es que la imagen de la ventana acoplable no se ejecuta como root.

Fileshare parece estar montado como root:root 777. Que es el valor predeterminado.

Cuando el usuario de Grafana intente acceder al almacenamiento montado, fallará. Tampoco puede CHOWN el almacenamiento montado, he escalado al usuario de nuevo a ROOT y en un scipt init.sh intenté asignar permisos al usuario de Grafana. Sin suerte.

No tiene suficientes permisos dentro de un contenedor ACI para montar otros archivos compartidos, cifs mount falla.

Solución propuesta: haga flotar la capacidad de especificar opciones de montaje, igual que en Azure AKS.
En Kubernetes/AKS, puede montar un recurso compartido de archivos de Azure, pero puede especificar opciones de montaje, como GID, UID y los permisos predeterminados.

Todos 29 comentarios

¡Gracias por la respuesta! Actualmente estamos investigando y lo actualizaremos en breve.

@ gs9824 ¿ puede proporcionar más información sobre grafana? No estoy familiarizado con este servicio.

@MicahMcKittrick-MSFT, Grafana es una herramienta para visualizar datos de diferentes fuentes a través de paneles. El problema de ejecutar Grafana como un contenedor acoplable es que la configuración no se conserva al reiniciar el contenedor acoplable.
La solución para esto es almacenar la configuración en un almacenamiento persistente, de modo que un reinicio no provoque la pérdida de la configuración.
Intento usar un recurso compartido de archivos de Azure para esto y montarlo en el contenedor (/var/lib/grafana). De esa manera se conserva la configuración.
Parece que Grafana puede crear archivos dentro de ese almacenamiento (puedo verlo a través del explorador de almacenamiento), pero parece que no puede actualizar ningún archivo

t=2018-10-09T14:20:36+0000 lvl=eror msg=“Cierre del servidor” logger=razón del servidor=“Falló el inicio del servicio: Falló la migración err: la base de datos está bloqueada”

La base de datos se almacena en el recurso compartido de archivos.

En el recurso compartido de archivos es posible crear derechos de acceso para los usuarios, pero no veo cómo puedo especificarlos en el comando de creación de contenedores.

@gs9824 ¿Ha mirado el uso de un disco persistente con AKS?

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

@ gs9824 ¿ alguna actualización sobre esto?

@ MicahMcKittrick-MSFT, lo siento, todavía no. Primero intenté que el recurso compartido de archivos funcionara al intentar ejecutar algunos comandos chmod durante la creación del contenedor. Hasta ahora sin suerte.

@ MicahMcKittrick-MSFT Según tengo entendido, esto implicaría configurar un clúster completo de AKS. Solo quería ejecutar Grafana como una instancia de Azure Container simple, sin modificar nada en el contenedor.

@seanmck. @iainfoulds, ¿alguno de ustedes tiene alguna idea sobre esto?

@gs9824 solo para su información, estoy trabajando sin conexión para obtener una respuesta a esto. Te actualizaré una vez que tenga más información.

@gs9824 dado que se pretende que sea una instancia de ejecución prolongada y que vea muchos reinicios, es posible que deba agregar una línea de comando de ejecución prolongada al comando az container create , como --command-line "tail - f /dev/null".

Además, consulte esta guía para obtener opciones adicionales de solución de problemas.

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

@ gs9824 ¿ alguna actualización sobre esto?

Hola

Coincidentemente, tengo exactamente el mismo problema para exactamente el mismo caso de uso (Grafana).

Grafana registra el siguiente error:
lvl=eror msg="Server shutdown" logger=server reason="Service init failed: Migration failed err: database is locked"
Y como resultado, el contenedor termina.
--command-line "tail -f /dev/null" para mí solo evita que se muestre el registro, pero grafana aún no se inicia y el contenedor finaliza.

Comenzando sin apuntar grafana a la montura, usará una carpeta local, que funciona. En Azure Portal, intenté escribir carpetas y archivos en el soporte manualmente, lo que funciona bien.

Aquí hay una plantilla ARM para que pueda reproducir el problema. Simplemente reemplace algunos de los marcadores de posición que agregué y debería estar listo para comenzar.

{ "$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 Perdón por no responder antes; es bueno saber que no soy el único con el problema :). Mientras tanto, tengo Grafana ejecutándose en una VM como solución alternativa (instalada a través de Market Place - Grafana de Grafana Labs). Lo más probable es que el reinicio ocurra porque grafana no se inicia debido a que la base de datos está bloqueada como dice @orendin .

Gracias a todos por los detalles adicionales.

No estoy seguro de si esta es información que podemos incluir en este documento, pero de todos modos, asignaré al autor para que revise y vea si podemos agregar algún detalle.

Hola, tengo el mismo problema con Prometheus esta vez.

mismo escenario de caso, estoy usando una imagen de Prometheus para crear un ACI montado con un recurso compartido de archivos.

lo que hice: comienzo del guión

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 del guion

agregué un archivo YAML en el archivo compartido 'prometheus.yml'

lo que esperaba

esperaba que ACI se iniciara y leyera el archivo YAML que creé en el archivo compartido cuando monté /etc/prometheus en él

que paso de verdad

el ACI no podía dejar de reiniciar, porque necesita obtener la configuración de '/etc/prometheus/prometheus.yml' y el error es
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

lo que traté de hacer

Me las arreglé para bash access en el sistema de archivos para agregar los permisos yo mismo,
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 puede ver, incluso con chmod como root en el archivo, no pude cambiar los permisos. entonces puede ser por eso que no puedo hacer que ACI lea el archivo de configuración YAML

Gracias por cualquier ayuda.

Hola tios,
arreglé mi problema.

lo que faltaba

az storage share policy create --help

lo que hice

Agregué una política de uso compartido con todos los permisos (lista de lectura y escritura) necesarios y funcionó.
ya no tengo el problema de permisos en el ACI

espero que esto ayude

Hola,
Me enfrento al mismo problema al implementar la imagen neo4j como instancia de contenedor.
Gracias por todo el trabajo mencionado anteriormente. Los probé todos.
Problema

  • Tengo un recurso compartido de archivos, creado para el contenedor en el mismo grupo de recursos. El recurso compartido de archivos debe montarse como disco persistente en el contenedor.
  • Como era de esperar, se ha montado el recurso compartido de archivos, pero no se pueden leer los datos.
  • Problemas de derechos de acceso.
    image
    image
    image

_ Referencias _

{
    "....": [],
    "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>"
            }
        }
    ],
    "....": []
}

El problema original parece estar resuelto. Agregar @dkkapur para el segundo si tiene comentarios. Gracias.

¿Alguien ha solucionado el problema de Grafana? Desafortunadamente, todavía recibo el error.

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

He creado una "Política de acceso" con todos los derechos, pero no sé si tengo que especificar esto de alguna manera al montar el volumen

"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, solucione el hecho de que el almacenamiento compartido de archivos montado requiere que el contenedor se ejecute como root, ya que esto va en contra de las mejores prácticas de Docker. Además, elimina muchos contenedores que no se ejecutan como root y necesitan almacenamiento de archivos.

Creo que el problema subyacente con Grafana es que la imagen de la ventana acoplable no se ejecuta como root.

Fileshare parece estar montado como root:root 777. Que es el valor predeterminado.

Cuando el usuario de Grafana intente acceder al almacenamiento montado, fallará. Tampoco puede CHOWN el almacenamiento montado, he escalado al usuario de nuevo a ROOT y en un scipt init.sh intenté asignar permisos al usuario de Grafana. Sin suerte.

No tiene suficientes permisos dentro de un contenedor ACI para montar otros archivos compartidos, cifs mount falla.

Solución propuesta: haga flotar la capacidad de especificar opciones de montaje, igual que en Azure AKS.
En Kubernetes/AKS, puede montar un recurso compartido de archivos de Azure, pero puede especificar opciones de montaje, como GID, UID y los permisos predeterminados.

@dlepow @dkkapur ¿ Alguna noticia sobre este tema?

Asignación a Deep para el seguimiento. ¡Gracias!

asignar:@dkkapur

@dkkapur alguna actualización?

hola gente!
finalmente encontré este problema... pasé 10 horas tratando de encontrar una solución

alguna noticia al respecto? parece asignado hace más de un año pero no hay respuesta

Lo mismo sucede con una imagen estándar de Docker de Postgresql: si intenta que la base de datos sea persistente montando un recurso compartido de archivos, no se inicia.

@ MicahMcKittrick-MSFT Hola Micah, ¿alguna actualización sobre esto?

@dkkapur ¿Hay algún plan para permitir que el contenedor ACI monte el recurso compartido de archivos de Azure con opciones como AKS de la siguiente manera?

opciones de montaje:
- dir_mode=0777
- modo_archivo=0777
-uid=1000
-gid=1000
- enlaces simbólicos mf
- nobrl
- caché=ninguno

Creo que el problema subyacente con Grafana es que la imagen de la ventana acoplable no se ejecuta como root.

Exactamente. Utiliza un usuario de permiso limitado llamado grafana (si no se cambia deliberadamente).

Básicamente, este problema evita cualquier enlace de almacenamiento persistente en producción porque no podemos confiar en el estado del contenedor Docker, que es exactamente la razón por la que usamos contenedores Docker en primer lugar. ¿Hay algún almacenamiento habilitado para el usuario no elevado al que podamos adjuntar?

Hola,
Algún avance en esto ?

Me enfrento al mismo problema con un contenedor postgreSQL en el que me gustaría montar un recurso compartido de archivos en /var/lib/postgresql/data para conservar una pequeña base de datos en varias versiones de contenedores, pero la base de datos no tiene permiso para utilice el recurso compartido de archivos montado.

Estos son los registros que se generan en Azure Container Instance:

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 ...

Y entonces el contenedor se detiene.

También soy bastante nuevo en la implementación de contenedores en Azure, por lo que si esta no es la forma prevista de hacerlo, me complacería aprender algo nuevo.
(PD: me acabo de dar cuenta de que alessiostalla ya mencionó que esto también afecta a las imágenes postgreSQL)

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

varma31 picture varma31  ·  3Comentarios

spottedmahn picture spottedmahn  ·  3Comentarios

mrdfuse picture mrdfuse  ·  3Comentarios

bdcoder2 picture bdcoder2  ·  3Comentarios

monteledwards picture monteledwards  ·  3Comentarios