使用“azwebapp deployment source config-zip”部署azure web app工作不正常

6psbrbz9  于 2023-06-24  发布在  其他
关注(0)|答案(1)|浏览(111)

我有一个简单的web.api,我想把它扩展到Azure。我使用Github来做这个。
如果我使用azure/webapps-deploy@v2步骤,所有工作都很顺利。

deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
    - name: Download artifact from build job
      # published previously via `dotnet publish` and 
      #  uses: actions/upload-artifact@v3
      #   with:
      #     name: webapp
      uses: actions/download-artifact@v3
      with:
        name: webapp
        path: webapp
    - name: Login via Azure CLI
      uses: azure/login@v1
      with:
        # secret in json form are added into repository settings
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - name: Deploy web app
      id: deploywebapp
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        package: webapp

我可以部署应用程序,然后可以通过https://% AZURE_WEBAPP_NAME %. azurewebsites. net/swagger/index.html访问它。现在,我想使用普通的azure CLI命令并替换上面的步骤(我做的唯一更改):

deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
    - name: Download artifact from build job
      uses: actions/download-artifact@v3
      with:
        name: webapp
        path: webapp
    - name: Azure Login
      uses: azure/CLI@v1
      with:
        azcliversion: 2.30.0
        inlineScript: |
          az login --service-principal \
          -u ${{ secrets.DEPLOYMENT_AZURE_CLIENT_ID }} \
          -p ${{ secrets.DEPLOYMENT_AZURE_CLIENT_SECRET }} \
          -t ${{ secrets.DEPLOYMENT_AZURE_TENANT_ID }}        
    - name: Deploy to Azure WebApp
      uses: azure/CLI@v1
      with:
        azcliversion: 2.30.0
        inlineScript: |
          zip -r webapp.zip .
          az webapp deployment source config-zip --resource-group ${{ env.AZURE_WEBAPP_RG }} --name ${{ env.AZURE_WEBAPP_NAME }} --src "webapp.zip"

这一步也不会失败,但部署的应用程序不可访问(使用以前的URL)并返回404错误。部署步骤输出为:

WARNING: Getting scm site credentials for zip deployment
WARNING: Starting zip deployment. This operation can take a while to complete ...
WARNING: Deployment endpoint responded with status code 202
{
  "active": true,
  "author": "N/A",
  "author_email": "N/A",
  "build_summary": {
    "errors": [],
    "warnings": []
  },
  "complete": true,
  "deployer": "Push-Deployer",
  "end_time": "..",
  "id": "..",
  "is_readonly": true,
  "is_temp": false,
  "last_success_end_time": "..",
  "log_url": "https://%AZURE_WEBAPP_NAME%.scm.azurewebsites.net/api/deployments/latest/log",
  "message": "Created via a push deployment",
  "progress": "",
  "received_time": "..",
  "site_name": "%AZURE_WEBAPP_NAME%",
  "start_time": "...",
  "status": 4,
  "status_text": "",
  "url": "https://%AZURE_WEBAPP_NAME%.scm.azurewebsites.net/api/deployments/latest"
}

az script ran successfully.

这两个步骤之间有什么区别?

    • 更新1**:我已经将--debug参数添加到az webapp deployment ..命令中,并且在详细输出中没有看到任何错误或失败
    • 更新2**:当我ssh到Azure服务器时,我看到所需的文件:
root@..:~/site/wwwroot/webapp# ls
DeploymentTemplates                 Swashbuckle.AspNetCore.SwaggerGen.dll  WebApiDemo.deps.json  WebApiDemo.runtimeconfig.json  web.config
Microsoft.OpenApi.dll               Swashbuckle.AspNetCore.SwaggerUI.dll   WebApiDemo.dll        appsettings.Development.json
Swashbuckle.AspNetCore.Swagger.dll  WebApiDemo
    • 更新3**:看起来这可能与这样一个事实有关,即当我使用普通CLI命令时,实际生成的文件被放置在更深的一层(请参阅前面的ssh输出,并注意webapp文件夹)。在正确部署的应用程序中,部署的文件被放置在wwwroot的根目录中:
root@..:~/site/wwwroot# ls
DeploymentTemplates                 Swashbuckle.AspNetCore.SwaggerGen.dll  WebApiDemo.deps.json  WebApiDemo.runtimeconfig.json  web.config
Microsoft.OpenApi.dll               Swashbuckle.AspNetCore.SwaggerUI.dll   WebApiDemo.dll        appsettings.Development.json
Swashbuckle.AspNetCore.Swagger.dll  WebApiDemo
z31licg0

z31licg01#

这两个任务之间的主要区别是azure/web-apps-deploy@v2将文件复制到底层存储到home/site/wwwroot,而az webapp deployment config-zip将zip文件复制到home/data/SitePackages。如果您有WEBSITE_RUN_FROM_PACKAGE="1",那么平台将把zip文件挂载到SitePackages中作为home/site/wwwroot目录,否则,zip文件的内容将被提取,这与azure/web-apps-deploy@v2的操作类似。
diagnostic logs将帮助确定导致您的应用出现404的原因。根据你提供的信息我将确保zip命令实际上是从actions/download-artifact@v3压缩正确的工件。由于压缩的是根目录,因此可能压缩的是文件夹而不是构建的二进制文件。

相关问题