问题
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.
I am now trying to move the deployment to a Bamboo deployment server.
I am generally following a process similar to this link how to use azure kudu zipdeploy from a bamboo deployment server
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
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.
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
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.
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.
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.
Any ideas?
回答1:
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.
Try something like this:
$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.
来源:https://stackoverflow.com/questions/49968029/azure-project-kudu-accepts-uploaded-zip-file-to-the-zipdeploy-endpoint-but-does