У меня есть служба приложений Azure, в которой работает настраиваемый контейнер. Когда я привязываю путь к общему ресурсу файлов Azure, мой контейнер перестает работать. Глядя на Проблемы с контейнером журналы, я вижу ошибку: [BYOS] Не удалось инициализировать пользовательские тома(ы) хранилища: [/var/LWASFiles/Sites/my-app/a3484543-39f9-45a3-816b-9524640dfd50].
В моем пользовательском контейнере определен объем /var/www/html/v3/загрузки.
Я пытаюсь сопоставить это с общим ресурсом файлов Azure, который находится в учетной записи хранения в той же виртуальной сети, что и размещающая ASE, с правилами, разрешающими трафик между подсетью ASE и файловым ресурсом через порты 137, 138, 138 и 445. .
Хостинг ASE настроен с внутренним балансировщиком нагрузки (т. е. это частная ASE).
Для учетной записи хранения настроена частная конечная точка.
Том сопоставляется в разделе Параметры > Конфигурация > Сопоставления путей службы приложений с использованием действительного ключа и пути подключения, который соответствует пути к тому в контейнере.
Перед добавлением сопоставления пути служба приложения работает должным образом.
После добавления сопоставления пути контейнер не запускается / единственная информация об исключении, которую я могу найти, находится в Проблемы с контейнером журналы, как указано выше.
Если я удалю сопоставление путей, проблема не исчезнет даже после принудительного перезапуска. Единственный способ решить проблему — удалить и повторно развернуть службу приложений.
Он успешно подключается к базе данных MySql (база данных Azure для серверов MySQL) через частную конечную точку.
С использованием копать {privateEndpointFqdn} Я могу доказать, что частная конечная точка учетной записи хранения разрешена правильно (как и MySQL, как и следовало ожидать).
С использованием tcptraceroute {privateEndpointFqdn} {порт назначения} Я могу доказать, что могу подключиться к учетной записи хранения через порт 445 (и к базе данных MySQL через порт 3306).
Примечание. Я не могу подключиться к учетной записи хранения через порты 137, 138 или 139, несмотря на то, что они разрешены через NSG по тем же правилам входящего и исходящего трафика, которые используются для порта 445 выше; хотя я подозреваю, что эти порты больше не требуются для CIFS (я добавил их только на всякий случай после того, как впервые столкнулся с проблемой, на случай, если они были каким-то образом актуальны, поскольку они упоминались в некоторых сообщениях).
Я запускаю вышеуказанные тесты с помощью SSH в контейнере, поэтому команды запускаются из его контекста. Примечание. Поскольку я не могу запустить контейнер после добавления сопоставления пути, эти тесты выполняются после создания службы приложения, но до добавления сопоставления пути.
я увеличил ВЕБ-САЙТЫ_CONTAINER_START_TIME_LIMIT до максимального значения: 1800
Мой контейнер предоставляет порт 80 (т. е. один из портов по умолчанию, поддерживаемых службой приложений для контейнера); и веб-сайт работает, когда сопоставление путей не существует, так что это не должно быть проблемой. Я также установил ВЕБ-САЙТЫ_ПОРТ к 80, только для ремней и подтяжек.
ВЕБ-САЙТЫ_ENABLE_APP_SERVICE_STORAGE установлен на ЛОЖЬ (хотя я также экспериментировал с установкой истинный, на всякий случай / это не имело значения, поэтому я вернулся к ЛОЖЬ).
В моей общей папке есть несколько ГБ данных. Я попытался создать идентичный общий файловый ресурс без содержимого и сопоставить его (сразу после воссоздания службы приложений и доказательства того, что это сработало; чтобы убедиться, что на мои тесты не повлияло похмелье более крупного общего файлового ресурса). Это дает ту же проблему, что и с большим файловым ресурсом.
Образ моего контейнера загружается из репозитория контейнеров Azure.
Образ основан на Убунту: 21.04
я включил лазурный кли и cifs-утилиты пакеты (я думаю, это требуется только при выполнении операции монтирования из контейнера, а не из конфигурации AppService, но я хотел охватить все предположения)
Хостинг ASE находится в Юг Великобритании регион (как и учетная запись хранения/все ресурсы).
Примечание. Это мой первый опыт запуска контейнеров в службе приложений. так что PEBKAC определенно возможен.
Любые предложения или рекомендации по устранению неполадок будут высоко оценены. Спасибо.
