Параллельное выполнение входа в систему az

Question

Я использую интерфейс командной строки Azure для проверки работоспособности некоторых виртуальных машин Azure. Проверка работоспособности осуществляется через этап Jenkins с использованием bash. Сам этап может занять несколько часов, в течение которых выполняются несколько команд z 'vm run', для всех из которых требуются надлежащие учетные данные.

У меня также есть несколько конвейеров Jenkins, которые развертывают разные продукты и предполагаютсячтобы иметь возможность работать параллельно. Все они имеют одинаковый этап проверки работоспособности.

Когда я выполняю ' az login ' для создания токена авторизации и ' az account set ' для установки подпискиНасколько я понял, эти данные записываются в файл профиля ( ~ / .azure / azureProfile.json ). Так что это хорошо, но всякий раз, когда я запускаю параллельный конвейер в этом контейнере Jenkins, если я использую другую подписку Azure, файл профиля будет естественным образом перезаписываться различными учетными данными, что приводит к сбою другой проверки работоспособности при получениик следующему выполнению команды запуска vm, так как он ищет группу ресурсов, которая существует в другой подписке.

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

Кроме того, поскольку учетные данные сеанса по умолчанию хранятся в файлах ~ / .azure / accessTokens.json и azureProfile.json, теоретически можно создать другойкаталог для каждого выполнения, но я не смог найти способ изменить эти файлы / расположение по умолчанию в документах Azure.

Как, по вашему мнению, самый лучший / простой способ обойти это?

Answer 1

Я нашел ответ здесь. Установка переменной среды AZURE_CONFIG_DIR делает свое дело. Это описано здесь: https://github.com/Azure/azure-cli/blob/dev/doc/use_cli_effectively.md#concurrent-builds

Answer 2

Я бы попытался сохранить az login как есть, удалить az account set и использовать вместо каждой команды --subscription аргумент.

Вы можете видеть, что ~/.azure/azureProfile.json содержит tenantId и информацию о пользователе для каждой команды. подписка и ~/.azure/accessTokens.json содержит все токены.

Таким образом, если вы будете точно указывать каждый раз свою подписку, вы не будете зависеть от общего пользовательского контекста.

У меня есть Account 1 для подписки xxxx-xxxx-xxxxx-xxxx и Account 2 для подписки yyyy-yyyy-yyyy-yyyy, и я делаю:

az login # Account 1
az login # Account 2
az group list --subscription "xxxx-xxxx-xxxxx-xxxx"
az group list --subscription "yyyy-yyyy-yyyy-yyyy"

, и он хорошо работает под тем же пользователем Unix