Спасибо за ответ! В настоящее время мы проводим расследование и вскоре сообщим вам об этом.

@ gs9824 gs9824, можете ли вы предоставить дополнительную информацию о графане? Я не знаком с этим сервисом.

@MicahMcKittrick-MSFT, Grafana — это инструмент для визуализации данных из разных источников с помощью информационных панелей. Проблема с запуском Grafana в качестве док-контейнера заключается в том, что настройки не сохраняются при перезапуске док-контейнера.
Решение для этого состоит в том, чтобы сохранить конфигурацию в постоянном хранилище, чтобы перезапуск не привел к потере конфигурации.
Я пытаюсь использовать для этого файловый ресурс Azure и монтировать его в контейнере (/var/lib/grafana). Таким образом, конфигурация сохраняется.
Кажется, Grafana может создавать файлы в этом хранилище (я вижу это через проводник хранилища), но, похоже, не может обновлять какие-либо файлы.

t = 2018-10-09T14: 20: 36 + 0000 lvl = ошибка msg = «Отключение сервера» logger = причина сервера = «Ошибка инициализации службы: ошибка миграции: ошибка: база данных заблокирована»

База данных хранится в общей папке.

На файловом ресурсе можно создать права доступа для пользователей, но я не вижу, как я могу указать их в команде создания контейнера.

@ gs9824 вы рассматривали возможность использования постоянного диска с AKS?

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

@ gs9824 есть поводу ?

@MicahMcKittrick-MSFT, извините, еще нет. Сначала я пытался заставить файловый ресурс работать, пытаясь выполнить некоторые команды chmod во время создания контейнера. Пока без везения.

@MicahMcKittrick-MSFT Насколько я понимаю, это потребует настройки полного кластера AKS. Я просто хотел запустить Grafana как простой экземпляр контейнера Azure, ничего не изменяя в контейнере.

@seanmck. @iainfooulds , у кого-нибудь из вас есть какие-нибудь мысли по этому

@ gs9824 к вашему сведению, я работаю в автономном режиме, чтобы получить ответ на этот вопрос. Обновлю вас, как только у меня будет больше информации.

@ gs9824 gs9824, поскольку этот экземпляр предназначен для длительного выполнения и имеет много перезапусков, вам может просто понадобиться добавить долговременную командную строку в команду az container create , например --command-line "tail - f /dev/ноль".

Кроме того, проверьте это руководство для дополнительных вариантов устранения неполадок.

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

@ gs9824 есть поводу ?

всем привет

По совпадению, у меня точно такая же проблема для точно такого же варианта использования (Grafana).

Grafana регистрирует следующую ошибку:
lvl=eror msg="Server shutdown" logger=server reason="Service init failed: Migration failed err: database is locked"
И в результате контейнер завершается.
--command-line "tail -f /dev/null" для меня просто предотвращает отображение журнала, но графана по-прежнему не запускается, и контейнер завершается.

Запустив без указания графаны на монтирование, она будет использовать локальную папку, что работает. Затем на портале Azure я попытался записать папки и файлы на монтирование вручную, и это работает нормально.

Вот шаблон ARM, чтобы вы могли воспроизвести проблему. Просто замените некоторые из заполнителей, которые я добавил, и все будет хорошо.

{ "$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 Извините, что не ответил раньше - приятно знать, что я не единственный, у кого есть проблема :). Тем временем у меня есть Grafana, работающая на виртуальной машине в качестве обходного пути (устанавливается через Marketplace — Grafana от Grafana Labs). Перезапуск, скорее всего, происходит из-за того, что grafana не запускается из-за блокировки базы данных, как указывает @orendin .

Спасибо всем за дополнительные подробности.

Я не уверен, что эту информацию мы можем включить в этот документ, но, тем не менее, я поручу автору просмотреть и посмотреть, сможем ли мы добавить какие-либо детали.

Привет, у меня такая же проблема, на этот раз с прометеем.

В том же сценарии я использую образ prometheus для создания ACI, смонтированного с помощью общего доступа к файлам.

Что я сделал: Скрипт начал

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/

конец сценария

я добавил файл YAML в общий файл «prometheus.yml»

чего я ожидал

я ожидал, что ACI запустится и прочитает файл YAML, который я создал в файле общего доступа, когда я смонтировал на нем /etc/prometheus

что на самом деле произошло

ACI не мог остановить перезапуск, потому что ему нужно получить конфигурацию из «/etc/prometheus/prometheus.yml», и ошибка
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

что я пытался сделать

мне удалось получить доступ к файловой системе, чтобы добавить разрешения для себя,
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

как вы можете видеть, даже с chmod как root в файле я не мог изменить разрешения. возможно, поэтому я не могу заставить ACI прочитать файл конфигурации YAML

спасибо за любую помощь.

Привет, ребята,
я исправил свою проблему.

чего не хватало

az storage share policy create --help

что я сделал

я добавил политику общего доступа со всеми необходимыми разрешениями (список чтения-записи), и это сработало.
у меня больше нет проблемы с разрешением на ACI

надеюсь, это поможет

Привет,
Я столкнулся с той же проблемой при развертывании образа neo4j в качестве экземпляра контейнера.
Спасибо за всю работу, упомянутую выше. Пробовал все.
Проблема

• У меня есть файловый ресурс, созданный для контейнера в той же группе ресурсов. Файловый ресурс должен быть подключен к контейнеру как постоянный диск.
• Как и ожидалось, общий файловый ресурс был смонтирован, но не может прочитать данные.
• Проблемы с правами доступа.
  
  
  

_ Ссылки _

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

Первоначальная проблема, похоже, решена. Добавление @dkkapur на секунду, если у вас есть комментарии. Спасибо.

Кто-нибудь решил проблему для Grafana? К сожалению, я все еще получаю ошибку

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

Я создал «Политику доступа» со всеми правами, но не знаю, нужно ли это как-то указывать при монтировании тома

"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, исправьте тот факт, что подключенное хранилище Fileshare требует запуска контейнера от имени пользователя root, так как это противоречит рекомендациям Docker. Кроме того, он устраняет множество контейнеров, которые не запускаются от имени пользователя root и нуждаются в хранении файлов.

Я думаю, что основная проблема с Grafana заключается в том, что образ докера не запускается с правами root.

Fileshare, похоже, смонтирован как root:root 777. Это значение по умолчанию.

Когда пользователь Grafana попытается получить доступ к подключенному хранилищу, произойдет сбой. Вы также не можете CHOWN смонтированное хранилище, я перевел пользователя обратно в ROOT и в сценарии init.sh попытался назначить разрешения пользователю Grafana. Не повезло.

У вас недостаточно прав внутри контейнера ACI для монтирования любых других файловых ресурсов, монтирование cifs завершается неудачно.

Предлагаемое решение: возможность указать параметры монтирования так же, как в Azure AKS.
В Kubernetes/AKS можно подключить общую папку Azure, но можно указать параметры подключения, такие как GID, UID и разрешения по умолчанию.

@dlepow @dkkapur Есть новости по этой теме?

Назначение Deep для последующего наблюдения. Спасибо!

назначить:@dkkapur

@dkkapur есть обновления?

эй народ!
наконец, я нашел эту проблему ... потратьте 10 часов, пытаясь найти обходной путь

есть новости по нему? похоже, назначено больше года назад, но нет ответа

То же самое происходит со стандартным образом Postgresql Docker — если вы попытаетесь сделать базу данных постоянной, подключив общий файловый ресурс, она не запустится.

@MicahMcKittrick-MSFT Привет, Мика, есть новости по этому поводу?

@dkkapur Есть ли какой-либо план, позволяющий контейнеру ACI монтировать файловый ресурс

Параметры монтирования:
- dir_mode=0777
- file_mode=0777
- ид=1000
- Гид=1000
- мфсимлинки
- благородный
- кеш=нет

Я думаю, что основная проблема с Grafana заключается в том, что образ докера не запускается с правами root.

Точно. Он использует пользователя с ограниченными правами доступа, именуемого grafana (если он не изменен преднамеренно).

Эта проблема в основном предотвращает любую постоянную привязку хранилища в рабочей среде, потому что мы не можем полагаться на работоспособность контейнера Docker, и именно поэтому мы используем контейнеры Docker в первую очередь. Есть ли какое-либо пользовательское хранилище без повышенных прав, к которому мы можем подключиться?

Привет,
какие-либо обновления по этому поводу?

Я столкнулся с той же проблемой с контейнером postgreSQL, на котором я хотел бы смонтировать общий файловый ресурс в /var/lib/postgresql/data, чтобы сохранить небольшую базу данных в нескольких версиях контейнера, но у базы данных нет разрешения на используйте смонтированный файлообменник.

Вот журналы, которые выводятся в экземпляре контейнера 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 ...

И тогда контейнер останавливается.

Я также новичок в развертывании контейнеров в Azure, поэтому, если это не предполагаемый способ сделать это, я был бы рад узнать что-то новое.
(PS: я только что заметил, что alessiostalla уже упоминала, что это также влияет на образы postgreSQL)