Проект Azure Kudu принимает загруженный zip-файл в конечную точку Zipdeploy, но не развертывает

У меня есть API ASP.NET Core 2.0 в качестве службы приложений Azure со слотом развертывания для QA, который я использую в течение нескольких месяцев. Я разрабатываю в VS2017 и публикую в Azure с помощью встроенного в проект компонента публикации в службе приложений Azure. Это работает нормально.

Сейчас я пытаюсь переместить развертывание на сервер развертывания Bamboo.

Обычно я следую процессу, аналогичному этой ссылке как использовать azure kudu zipdeploy с сервера развертывания Bamboo

В моей сборке Bamboo я запускаю сценарий Powershell для вызова dotnet publish, чтобы поместить файлы публикации в выходную папку, а затем заархивирую эти файлы в один zip-файл и использую его как артефакт. Затем в моем проекте развертывания Bamboo я ссылаюсь на этот артефакт и запускаю сценарий Powershell, который вызывает конечную точку Kudu с помощью Invoke-WebRequest, как показано ниже;

Invoke-WebRequest -Uri "https://userName:[email protected]/api/zipdeploy" `
-InFile zipfileName -ContentType "multipart/form-data" -Method Post -UseBasicParsing

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

Примечание. Я использую фактические значения в URL-адресе Kudu прямо сейчас, чтобы процесс работал без проблем, связанных с необходимостью обратной отметки свойств имени пользователя и пароля при передаче в качестве аргументов в Powershell, о которых другие сообщали при использовании Powershell для этого процесса. .

Когда скрипт запускается, я получаю следующее

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.

Насколько я понимаю, вы просто загружаете zip-файл в конечную точку Kudu zipdeploy, и он развертывается в указанном слоте развертывания Azure. Но когда я смотрю на даты файлов для сайта в Kudo, все они указывают на последнюю публикацию, которую я сделал в VS2017 неделю назад.

Очевидно, мне здесь чего-то не хватает.

Ответ от ZipDeploy, даже если он имеет статус 200, имеет текст «Войдите в свою учетную запись» в разделе «Заголовок» свойства «Заголовок». Я также вижу слово DENY (X-Frame-Options: DENY), но я не знаю, связано ли это с проблемой, которую я вижу.

Любые идеи?


azure powershell kudu azure-app-service-envrmnt bamboo
person whiskytangofoxtrot    schedule 22.04.2018    source источник
comment
не уверен, поможет это или нет ... Я написал статью о загрузке в приложения kudu здесь: powershellposse.com/2017/09/04/   -  person thom schumacher    schedule 22.04.2018

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, проблема в том, что Invoke-WebRequest не учитывает кредиты, переданные в URL. Вместо этого вам нужно явно передать основной заголовок аутентификации.

Попробуйте что-то вроде этого:

$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"

См. Также здесь для получения сопутствующей информации.

person David Ebbo    schedule 23.04.2018
comment
Мне пришлось изменить параметр -Method с PUT на POST, но в остальном пример в предоставленной вами ссылке работал. Спасибо за вашу помощь. Странно, что когда я использовал Invoke-WebRequest, он давал мне 401, если я использовал недопустимые учетные данные и передавал код состояния 200, когда я давал правильные учетные данные, но все еще не загружал файл. - person whiskytangofoxtrot; 23.04.2018
comment
@whiskytangofoxtrot Думаю, я вас запутал. Я указал вам на этот пример только потому, что он выполняет аутентификацию. В остальной части этого примера используется / zip API, который не подходит для общего развертывания. Таким образом, вам действительно нужно использовать /api/zipdeploy API (который является POST), но просто измените способ аутентификации. - person David Ebbo; 23.04.2018
comment
@whiskytangofoxtrot Я отредактировал свой ответ, чтобы получить полный образец использования zipdeploy. - person David Ebbo; 23.04.2018
comment
@David_Ebbo Я предположил, что вы не хотели, чтобы я действительно использовал zip API, и использовал ZipDeploy в моем решении. Но спасибо за дополнительные разъяснения. - person whiskytangofoxtrot; 24.04.2018
comment
@whiskytangofoxtrot круто, просто убедился! Некоторые люди использовали zip API для развертывания, и это не лучший выбор. - person David Ebbo; 24.04.2018