Функция Azure, работающая из контейнера Docker, содержит разные файлы внутри
Как видно на изображении ниже, содержимое локального контейнера Docker не соответствует содержимому, отправленному в приложение-функцию Azure. Я изучаю приложение функции Azure с Kudu и использую docker run для взаимодействия с локальным контейнером.
Это проблема, так как у меня есть внешняя библиотека, которую я импортирую с помощью DllImport, поэтому код никогда не сможет найти фактический файл библиотеки, независимо от того, куда я его поместил.
Чем это вызвано и какое решение?
Это последний слой моего Dockerfile:
FROM mcr.microsoft.com/azure-functions/dotnet:2.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true
COPY --from=installer ["/home/site/wwwroot", "/home/site/wwwroot"]
COPY --from=compile_engine ["/app/tmp/src/libml_inference_engine.so", "/azure-functions-host"]
COPY --from=compile_engine ["/app/tmp/src/libml_inference_engine.so", "/bin"]
COPY --from=compile_engine ["/app/tmp/src/libml_inference_engine.so", "/home/site/wwwroot"]
Ответы 1
Когда вы создаете приложение-функцию из пользовательского образа докера, путь /home/site/wwwroot внутри контейнера не совпадает с путем /home/site/wwwroot в куду. Между куду и контейнером из вашего пользовательского образа есть два разных контейнера. Таким образом, вы не можете видеть одни и те же вещи на обоих одинаковых путях.
Решение состоит в том, что вы можете установить переменную среды WEBSITES_ENABLE_APP_SERVICE_STORAGE как true. Затем функция будет использовать путь /home/site/wwwroot, покрывающий тот же путь внутри пользовательского контейнера. Таким образом, вы увидите одни и те же вещи в обоих местах. Он также показывает все вещи этого пути в портале:
Я попытался установить для WEBSITES_ENABLE_APP_SERVICE_STORAGE значение true, теперь wwwroot содержит «host.json», но ни одна из исходных dll, которые я ожидал увидеть, как в образе докера. Кроме того, функций теперь нет.
@EduardG Как я уже сказал в ответе, куду — это другой контейнер, отличный от вашего пользовательского контейнера изображений. И когда вы установите для переменной среды WEBSITES_ENABLE_APP_SERVICE_STORAGE значение true, тогда путь куду /home/site/wwwroot будет охватывать тот же путь в вашем пользовательском контейнере изображений.
Поскольку других ответов нет, а ваш проливает некоторый свет на тему, я принял его как ответ. Я все еще не понимаю, почему после включения этого параметра конфигурации локальный образ докера не соответствует тому, который был загружен в Azure, поскольку из вашего комментария я понимаю, что если для него установлено значение true, то так и должно быть.
@EduardG Вам нужно понять смысл. Путь в Kudu будет охватывать путь в вашем пользовательском контейнере изображений. Итак, вам нужно загрузить файлы в путь в куду. Затем вы можете увидеть файлы внутри вашего пользовательского контейнера изображений.
Я гонялся за красными селедками. Часть моего вопроса заключалась в том, почему DllImport не находит файлы, которые я туда вставил, и я подумал, что вы имели в виду, что Kudu каким-то образом заменил эти файлы, но на самом деле он находил их, но я скомпилировал их неправильно. Для тех, кто читает это: в моем случае приложение находилось в /home/site/wwwroot/bin, а узел функции azure — в /azure-functions-host/something.dll, DllImport просматривал папку bin, но однажды вы запускаете функцию, она запустится в корне "/" в качестве рабочего каталога. DllImport не сможет сказать, что не может найти файл, если он скомпилирован для неправильной архитектуры.
@EduardG Я знаю, что ваше приложение находится по пути /home/site/wwwroot контейнера. Как вы понимаете, что я сказал в ответ?
Думаю, мы где-то разошлись, так как вы посоветовали мне загружать файлы в путь в куду, а я в итоге просто добавил их в образ докера.
Почему куду видит на этом пути что-то другое? Он просто игнорирует файлы или создает свой собственный контейнер?