RUDE

Действительно ли Azure WEBSITE_RUN_FROM_PACKAGE означает не распаковывать ZIP-архив?

Я выполняю zip-развертывание веб-приложения .NET Framework в службе приложений Azure через рабочий процесс GitHub.

Я установил WEBSITE_RUN_FROM_PACKAGE на 1 на странице Settings / Configuration / Application settings консоли Azure. Я также пытался установить WEBSITE_RUN_FROM_ZIP на 1 на всякий случай (хотя я думаю, что это устаревший флаг).

Пакет правильно собирается в GitHub, и я вижу, что он отображается в моей консоли отладки Kudu в разделе C:\home\site\wwwroot (как MyPackageName.zip), а также в C:\home\data\SitePackages (например, как 20220512205318.zip).

Часть развертывания моего YAML:

deploy:
  runs-on: windows-latest
  needs: build
  environment:
    name: 'Test'
    url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

  steps:
    - name: Download artifact from build job
      uses: actions/download-artifact@v2
      with:
        name: ASP-app

    - name: Deploy to Azure Web App
      id: deploy-to-webapp
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XYZsecret }}
        package: .

И .PublishSettings, которые я загрузил на GitHub, выглядит так:

<publishData>
    <!-- Which one of these 3 profiles is my YAML using?  I don't actually know. -->
    <publishProfile profileName="mywebappname-test - Web Deploy" publishMethod="MSDeploy"  etc="foobar">
        <databases/>
    </publishProfile>
    <publishProfile profileName="mywebappname-test - FTP" publishMethod="FTP" etc="foobar">
        <databases/>
    </publishProfile>
    <publishProfile profileName="mywebappname-test - Zip Deploy" publishMethod="ZipDeploy" etc="foobar">
        <databases/>
    </publishProfile>
</publishData>

Zip-пакет нет автоматически распаковывается. Представитель службы поддержки MSFT, с которым я разговаривал, предположил, что проблема именно в этом, и действительно, когда я загружаю пакет на свой компьютер и помещаю его на страницу Kudu Tools/Zip Push Deploy, я вижу, что пакет распакован, и я могу заставить сайт работать, установив соответствующий физический путь, соответствующий виртуальному пути '/'. В частности, Kudu Tools Zip Push заставляет мои файлы web.config и favicon.ico и т. д. отображаться в:

C:\home\site\wwwroot\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp

и я могу перейти в консоль Azure для моей службы приложений, перейти к Settings / Configuration/ Path Mappings, Virtual applications and directories и отредактировать существующую запись следующим образом:

Virtual path: /
Physical Path: site\wwwroot\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp
Type: Application

а затем увидеть мой сайт в браузере.

Однако, когда не делает что-либо для распаковки архива, я оставляю запись как:

Virtual path: /
Physical Path: site\wwwroot
Type: Application

Я не вижу свой сайт в браузере, а вместо этого вижу только «У вас нет разрешения на просмотр этого каталога или страницы». Когда я затем копаюсь в журналах в Kudo, я вижу 403.14 — Запрещенные ошибки на моем основном сайте и ошибку 404.0 — Не найдено на C:\home\site\wwwroot\favicon.ico. (Как и остальные мои файлы, favicon.ico все еще находится в zip-архиве по адресу [...]\foo\bar\good\boy\obj\Test\Package\PackageTmp\favicon.ico.)

Мои вопросы:

  1. Должно ли мое веб-приложение вообще работать, если там находится только мой zip-файл, как C:\home\site\wwwroot\MyPackageName.zip? Или его действительно нужно распаковывать, как указал представитель MSFT?
  2. Если он должен работать таким образом, какие-нибудь идеи о том, что мне не хватает? Я предполагаю, что это что-то в моем YAML (какой из трех параметров publishProfile он на самом деле выбирает здесь?), или в Settings / Configuration/ Path Mappings, или в Application settings, но я понятия не имею, что на данный момент, и у меня заканчиваются идеи.

Спасибо, Эрик


1
37
2

Ответы:

Решено
  1. Should my web app be able to run at all with just my zip file sitting there as C:\home\site\wwwroot\MyPackageName.zip?

В значительной степени да, просто не в wwwroot. Когда WEBSITE_RUN_FROM_PACKAGE включен, приложение запускается из архива напрямую как монтирование каталога только для чтения. Ничто не копируется на wwwwroot или куда-либо еще.

  1. If it is supposed to run this way, any ideas on what am I missing?

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


Ответ обитателя был правильным ответом на мой первоначальный вопрос, но я добавлю здесь более подробную информацию о том, как я использовал эту информацию, чтобы мое развертывание работало должным образом. Мне кажется, что невозможность чтения XML-файлов внутреннего индекса zip-архива для поиска правильного относительного пути является недостатком Azure, но пока он не устранен, я надеюсь, что это может оказаться полезным для других.

Моим первым шагом было отказаться от идеи развертывания в виде zip-файла. Возможно, я все еще мог бы выполнить эту работу, выполнив некоторую постобработку, чтобы заархивировать вещи в другом формате без вложенных папок, но в моем случае я решил, что преимущества развертывания с одним файлом не стоят затрат. Чтобы прекратить развертывание в виде zip-файла, я вручную отредактировал файл .pubxml, который передал в качестве параметра msbuild /p:PublishProfile=AzureCI.pubxml. Изменения, которые я внес, заключались в том, чтобы изменить PackageAsSingleFile с true на false и изменить DesktopBuildPackageLocation с пути к файлу zip на путь к папке.

Одного этого было достаточно, чтобы мой сайт был развернут в Azure в виде отдельных файлов, а не zip-архива. Файлы по-прежнему были похоронены в уродливой структуре папок, но я мог, по крайней мере, увидеть их в Kudu и заставить сайт работать, применив ту же настройку Settings / Configuration/ Path Mappings, Virtual applications and directories, которую я описал в своем исходном вопросе.

Я мог бы остановиться на этом, но я хотел иметь возможность просто использовать виртуальный путь по умолчанию, а моя конфигурация Azure не зависела от моих вышестоящих процессов. Другими словами, я хотел, чтобы мои файлы web.config, favicon.ico и т. д. находились непосредственно в C:\home\site\wwwroot, а не глубоко в структуре подпапок. Чтобы это работало, я изменил аргумент package на webapps-deploy в своем YAML с . на соответствующий путь следующим образом:

- name: Deploy to Azure Web App
  id: deploy-to-webapp
  uses: azure/webapps-deploy@v2
  with:
    app-name: ${{ env.AZURE_WEBAPP_NAME }}
    publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XYZsecret }}
    package: .\Archive\Content\D_C\a\foo\bar\good\boy\obj\Test\Package\PackageTmp

Это заставило процесс развертывания выбрать из сборки только те файлы, которые мне нужны, и поместить их в C:\home\site\wwwroot. Затем я мог бы вернуть кладж отображения пути и отправиться в путь.