Azure项目Kudu接受上载的zip文件到Zipdeploy终结点,但不部署 [英] Azure project Kudu accepts uploaded zip file to the Zipdeploy endpoint but does not deploy

查看:135
本文介绍了Azure项目Kudu接受上载的zip文件到Zipdeploy终结点,但不部署的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个ASP.NET Core 2.0 API作为Azure应用服务,具有我几个月来一直在使用的QA部署槽。我使用VS2017开发,并使用项目的内置发布到Azure应用服务组件发布到Azure。这很好。

I have an ASP.NET Core 2.0 API as an Azure App Service with a deployment slot for QA that I have been using for a few months. I develop in VS2017 and I publish to Azure using the built in Publish to Azure App Service component of the project. This is working just fine.

我现在正在尝试将部署移至Bamboo部署服务器。

I am now trying to move the deployment to a Bamboo deployment server.

我通常会遵循以下流程类似于此链接如何使用Azure kudu zipdeploy从Bamboo部署服务器中

I am generally following a process similar to this link how to use azure kudu zipdeploy from a bamboo deployment server

在我的Bamboo构建中,我运行Powershell脚本调用dotnet publish将发布文件放置在输出文件夹中,然后将这些文件压缩为单个zip文件,并将其用作工件。然后,在我的Bamboo部署项目中,我引用该工件并运行一个Powershell脚本,该脚本使用Invoke-WebRequest调用Kudu端点,如下所示;

In my Bamboo build, I run a Powershell script to call dotnet publish to put the publish files in an output folder and I then zip those files into a single zip file and use that as an artifact. Then, in my Bamboo deployment project, I reference that artifact and run a Powershell script that calls the Kudu endpoint using Invoke-WebRequest like what is shown below;

Invoke-WebRequest -Uri "https://userName:userPassword@MySiteDeploymentSlot.scm.azurewebsites.net/api/zipdeploy" `
-InFile zipfileName -ContentType "multipart/form-data" -Method Post -UseBasicParsing   

用户名和UserPassword是我从Azure中部署槽的发布配置文件中获得的门户网站,ZipFileName是工件中的zip文件,该工件是我项目的压缩发布输出。

Username and UserPassword are the ones I got from the deployment slot's publish profile in the Azure portal, ZipFileName is the zip file in the artifact that is the zipped published output of my project.

注意:我现在使用的是Kudu URL中的实际值,只是为了使该过程正常运行,而不必在通过时回勾用户名和密码属性作为Powershell的参数,其他人在使用Powershell进行此过程时已经报告过。

Note: I am using the actual values in the Kudu URL right now just to get the process working without the issues with having to back tick the username and password properties when passed in as arguments to Powershell that others have reported when using Powershell for this process.

脚本运行时,我得到以下内容

When the script runs, I get the following

StatusCode        : 200
StatusDescription : OK
Content           : 

                    <!DOCTYPE html>
                    <html dir="ltr" class="" lang="en">
                    <head>
                        <title>Sign in to your account</title>
                        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
                        <meta http-eq...
RawContent        : HTTP/1.1 200 OK
                    Pragma: no-cache
                    Strict-Transport-Security: max-age=31536000; includeSubDomains
                    X-Content-Type-Options: nosniff
                    X-Frame-Options: DENY
                    x-ms-request-id: 31607f18-c30a-46f3-bdaf-d84a...
Forms             : 
Headers           : {[Pragma, no-cache], [Strict-Transport-Security, max-age=31536000; includeSubDomains], 
                    [X-Content-Type-Options, nosniff], [X-Frame-Options, DENY]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : 
RawContentLength  : 34599

得到状态码200,我假设它已上传,但是当我查看Kudu部署端点时,它没有出现在部署列表中。

Since I get a status code 200, I assume that is was uploaded but it doesn't appear in the list of deployments when I look at the Kudu deployment endpoint.

我的理解是您只需将一个zip文件上传到Kudu zipdeploy终结点,并将其部署到指定的Azure部署插槽。但是,当我查看Kudo中站点的文件日期时,它们都表明我一周前在VS2017中进行的最后一次发布。

My understanding was that you just upload a zip file to the Kudu zipdeploy endpoint and it gets deployed to the specified Azure deployment slot. But when I look at the file dates for the site in Kudo, they are all indicative of the last publish I did in VS2017 a week ago.

很显然,我在这里丢失了一些东西。

Obviously, I am missing something here.

从ZipDeploy返回的响应(即使状态为200)在标题部分的标题部分中具有文本登录到您的帐户。我还看到了单词DENY(X帧选项:DENY),但我不知道这是否与我看到的问题有关。

The response back form the ZipDeploy, even though it is a status 200, has the text "Sign in to your account" in the Head section, Title property. I also see the word DENY (X-Frame-Options: DENY) but I do not know if that is related to the problem I am seeing.

有什么想法吗?

推荐答案

我认为问题在于 Invoke-WebRequest 不接受URL中传递的凭据。相反,您需要显式传递基本的auth标头。

I think the problem is that Invoke-WebRequest doesn't honor creds passed in the URL. Instead, you need to pass the basic auth header explicitly.

尝试如下操作:

$webapp = "MyApp"
$username = "`$MyApp"
$password = "ThePasswordFromPublishProfile"
# Note that the $username here should look like `SomeUserName`, and **not** `SomeSite\SomeUserName`
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username, $password)))

$apiUrl = "https://$webapp.scm.azurewebsites.net/api/zipdeploy"
$filePath = "C:\Temp\books.zip"
Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -Method POST -InFile $filePath -ContentType "multipart/form-data"

另请参见此处获取相关信息。

See also here for related info.

这篇关于Azure项目Kudu接受上载的zip文件到Zipdeploy终结点,但不部署的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆