Не удается изменить подключение к службе в задаче конвейера выпуска Azure DevOps

У меня есть конвейер выпуска в Azure DevOps с одним этапом. Этап содержит задачу Kubectl для входа в кластер AKS. Ожидается, что в качестве параметра будет установлено служебное соединение. Моя проблема в том, что я получаю подключение к службе из предыдущей задачи, которая считывает значение из конфигурации приложения. Значение, которое я получаю из конфигурации приложения, устанавливается как переменная среды, которую я затем передаю таким образом echo "##vso[task.setvariable variable=SC]$AKS_SERVICECONNECTION". Итак, переменная SC, и я установил соединение с сервисом в Kubectl-login с $(SC). $AKS_SERVICECONNECTION имеет правильное значение, я распечатал его, чтобы проверить.

Это не работает. Значение не установлено, хотя переменная среды SC теперь имеет правильное значение. Итак, я протестировал его с параметром namespace, и он работает, только не с подключением к службе. Мой вопрос и предположение заключается в том, что соединение службы должно быть установлено во время выполнения и не может быть установлено в предыдущей задаче, которую будет использовать следующая задача?


person Sven Malvik    schedule 05.09.2020    source источник
comment
SC это имя или идентификатор службы?   -  person Shayki Abramczyk    schedule 06.09.2020
comment
$(SC) - это имя переменной, которую я установил в поле для подключения службы. Это означает, что я назначил ему переменную SC в задаче Bash после задачи конфигурации приложения с именем подключения службы и перед задачей kubectl-login, которая использует $ (SC).   -  person Sven Malvik    schedule 06.09.2020
comment
Это я понял, но каково значение этой переменной? имя подключения службы или идентификатор подключения службы?   -  person Shayki Abramczyk    schedule 06.09.2020
comment
Ах, извините, значение - это имя подключения службы   -  person Sven Malvik    schedule 06.09.2020
comment
Если есть возможность, попробуйте поставить id   -  person Shayki Abramczyk    schedule 06.09.2020
comment
Установка id вместо name тоже не сработала. Я получил идентификатор из списка всех сервисных подключений с помощью dev.azure.com/ ‹ORGANIZATION› / ‹PROJECT› / _apis /   -  person Sven Malvik    schedule 06.09.2020
comment
Привет, @SvenMalvik. У вас была возможность проверить решение, приведенное ниже. Как прошло?   -  person Levi Lu-MSFT    schedule 11.09.2020


Ответы (1)


Кажется, что соединение службы для задачи Kubectl извлекается во время компиляции перед выполнением задачи. Я создал переменную тестирования в разделе переменных конвейера выпуска и изменил значение переменной тестирования в задаче сценария, используя echo "##vso[task.setvariable... Я видел в журнале задач, что всегда выбиралось исходное значение для тестовой переменной.

См. Эту аналогичную проблему здесь.

Однако вы можете использовать rest api в качестве временного решения. См. Шаги ниже:

1. Добавьте второй этап в конвейер выпуска. Выберите триггер как Manual Only. Переместите задачу Kubectl и связанные задачи на втором этапе (т.е. Kubetcl stage на скриншоте ниже) введите описание изображения здесь

2. Определите переменную ServiceCon в разделе Variables. Выберите переменную Scope на втором этапе (т.е.Kubetcl). Проверить Settable at release time

введите описание изображения здесь

3. Добавьте задачу сценария для вызова update освободить окружение rest api на первом этапе (т.е. SetServiceCon этапе). См. Ниже встроенный сценарий PowerShell: переменной SC присвоено имя подключения службы в предыдущей задаче.

$url = "https://vsrm.dev.azure.com/Org/Project/_apis/Release/releases/$(Release.ReleaseId)/environments/$($(Release.EnvironmentId)+1)?api-version=6.1-preview.7"

#override the variable ServiceCon by referencing to variable $(SC) from your previous task
$body = @{
  status= "inProgress";
  variables= @{ ServiceCon= @{value= $(SC)}}
}

Invoke-RestMethod -Uri $url -Headers @{Authorization = "Bearer $(System.AccessToken)"} -Method patch -Body (ConvertTo-Json $body) -ContentType "application/json"

Вышеупомянутый скрипт запустит второй этап (т.е. этап kubetcl) с обновленным именем подключения к службе.

4. Чтобы получить доступ к токену $(System.AccessToken) на предыдущем этапе, вам необходимо перейти на страницу редактирования первого этапа и проверить параметр Allow scripts to access the OAuth token См. Снимок экрана ниже.

введите описание изображения здесь

5. Вам также необходимо allow права Manage deployments и edit release stage для учетной записи службы сборки. См. Снимок экрана ниже.

На странице редактирования конвейера выпуска. Щелкните 3 точки в правом верхнем углу. И выберите Security.

введите описание изображения здесь

Allow разрешения Manage deployments и edit release stage для учетной записи (ProjectName)build service (OrgName).

введите описание изображения здесь

После выполнения вышеуказанных шагов и при срабатывании вашего релиза pieline сначала будет выполнен первый этап, и задача скрипта вызовет среду выпуска обновлений rest api. Затем будет запущен второй этап с обновленным именем подключения к сервису.

person Levi Lu-MSFT    schedule 07.09.2020
comment
Я протестировал ваше решение в классическом редакторе, оно работает, спасибо! Вы знаете, можно ли это сделать на конвейере YAML? Мне не удалось найти rest api для конвейеров обновления: / - person MoonHorse; 17.01.2021