Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
GitHub Actions и Azure Pipelines позволяют запускать рабочие процессы CI/CD с локальными средствами выполнения и агентами. Вы можете запускать локальные средства выполнения и агенты с помощью заданий приложений контейнеров Azure, управляемых событиями.
Локальные средства выполнения на собственных серверах полезны, если необходимо запускать рабочие процессы, требующие доступа к локальным ресурсам или инструментам, которые недоступны для облачных средств выполнения. Например, самостоятельно размещаемый исполнитель в задании в среде контейнерных приложений позволяет рабочему процессу получить доступ к ресурсам внутри виртуальной сети задания, которая недоступна для запускаемого в облаке исполнителя.
Запуск самохостящихся исполнителей в качестве заданий, основанных на событиях, позволяет воспользоваться бессерверным характером приложений контейнеров Azure. Задания выполняются автоматически, когда рабочий процесс активируется, и завершаются после его выполнения.
Вы оплачиваете только время выполнения задания.
В этом руководстве вы узнаете, как запускать исполнители GitHub Actions в виде заданий контейнерных приложений, работающих на основе событий.
- Создание среды приложений-контейнеров для развертывания локального запуска
- Создание репозитория GitHub для запуска рабочего процесса, использующего локальное средство выполнения
- Создание образа контейнера, на котором выполняется runner GitHub Actions
- Развертывание runner в качестве задания в среде "Приложения контейнеров"
- Создайте рабочий процесс, использующий локальное средство выполнения и убедитесь, что он выполняется.
Внимание
Для частных репозиториев рекомендуется использовать только локальные исполнители. Использование их с общедоступными репозиториями может позволить опасному коду выполняться в локальном средстве выполнения. Дополнительные сведения см. в разделе безопасности локального запуска.
Примечание.
Каждый личный маркер доступа (PAT) имеет дату окончания срока действия. Необходимо убедиться, что PAT регулярно сменяются до их истечения срока действия. Дополнительные сведения об управлении PAT см. в разделе Использование личных маркеров доступа.
В этом руководстве описано, как запускать агенты Azure Pipelines в качестве задачи контейнерных приложений на основе событий.
- Создание среды приложений-контейнеров для развертывания локального агента
- Создание организации и проекта Azure DevOps
- Создание образа контейнера, на котором выполняется агент Azure Pipelines
- Создание агента-заполнителя в среде "Приложения контейнеров" с помощью ручного задания
- Развертывание агента в виде задания в среде контейнерных приложений
- Создайте конвейер, использующий локальный агент и убедитесь, что он выполняется.
Внимание
Агенты, размещенные самостоятельно, рекомендуется использовать только для частных проектов. Использование их с общедоступными проектами может позволить выполнять опасный код на локальном агенте. Дополнительные сведения см. в разделе "Безопасность локального агента".
Примечание.
Каждый личный маркер доступа (PAT) имеет дату окончания срока действия. Необходимо убедиться, что PAT регулярно сменяются до их истечения срока действия. Дополнительные сведения об управлении PAT см. в разделе Использование личных маркеров доступа.
Примечание.
Приложения и задания контейнеров не поддерживают запуск Docker в контейнерах. Все действия в рабочих процессах, использующих команды Docker, завершаются сбоем при выполнении на самостоятельно размещённом исполнителе или агенте в задаче приложения Container Apps.
Предварительные условия
Учетная запись Azure. Если у вас нет, ее можно создать бесплатно.
Azure CLI: установите Azure CLI.
- Организация Azure DevOps. Если у вас нет организации DevOps с активной подпиской, ее можно создать бесплатно.
Посмотрите ограничения заданий для получения списка ограничений.
Настройка
Чтобы войти в Azure из ИНТЕРФЕЙСА командной строки, выполните следующую команду и следуйте инструкциям, чтобы завершить процесс проверки подлинности.
az login
Чтобы убедиться, что вы используете последнюю версию интерфейса командной строки, выполните команду обновления.
az upgrade
Затем установите или обновите расширение "Приложения контейнеров Azure" для интерфейса командной строки.
Если при выполнении команд az containerapp
в Azure CLI или командлетов из модуля Az.App
в PowerShell возникают ошибки об отсутствующих параметрах, убедитесь, что у вас установлена последняя версия расширения для "Приложений контейнеров Azure".
az extension add --name containerapp --upgrade
Примечание.
Начиная с мая 2024 г. расширения Azure CLI больше не поддерживают предварительные версии функций по умолчанию. Чтобы получить доступ к предварительным функциям контейнерных приложений, установите расширение для контейнерных приложений с помощью --allow-preview true
.
az extension add --name containerapp --upgrade --allow-preview true
Теперь, когда установлено текущее расширение или модуль, зарегистрируйте пространства имен Microsoft.App
и Microsoft.OperationalInsights
.
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights
Создание переменной среды
После завершения настройки Azure CLI вы можете определить переменные среды, которые используются в этой статье.
RESOURCE_GROUP="jobs-sample"
LOCATION="northcentralus"
ENVIRONMENT="env-jobs-sample"
JOB_NAME="github-actions-runner-job"
RESOURCE_GROUP="jobs-sample"
LOCATION="northcentralus"
ENVIRONMENT="env-jobs-sample"
JOB_NAME="azure-pipelines-agent-job"
PLACEHOLDER_JOB_NAME="placeholder-agent-job"
Создание среды приложений-контейнеров
Среда Azure Container Apps выступает в качестве безопасной границы для контейнерных приложений и заданий, чтобы они могли совместно использовать ту же сеть и взаимодействовать друг с другом.
Примечание.
Сведения о создании среды приложений контейнеров, интегрированной с существующей виртуальной сетью, см. в статье "Предоставление виртуальной сети для среды приложений контейнеров Azure".
Чтобы создать группу ресурсов, выполните указанную ниже команду.
az group create \ --name "$RESOURCE_GROUP" \ --location "$LOCATION"
Создайте среду приложений контейнеров с помощью следующей команды.
az containerapp env create \ --name "$ENVIRONMENT" \ --resource-group "$RESOURCE_GROUP" \ --location "$LOCATION"
Создание репозитория GitHub для запуска рабочего процесса
Чтобы выполнить рабочий процесс, необходимо создать репозиторий GitHub, содержащий определение рабочего процесса.
Перейдите к GitHub и войдите.
Создайте новый репозиторий, введя следующие значения.
Настройка Значение Владелец Выберите имя пользователя GitHub. Имя репозитория Введите имя репозитория. Видимость Выберите категорию Частное. Инициализируйте этот репозиторий с помощью Выберите параметр Добавить README файл. Оставьте остальные значения выбранными по умолчанию.
Щелкните Create repository (Создать репозиторий).
В новом репозитории выберите "Действия".
Найдите шаблон простого рабочего процесса и выберите "Настроить".
Выберите "Зафиксировать изменения" , чтобы добавить рабочий процесс в репозиторий.
Рабочий процесс выполняется на ubuntu-latest
размещенном в GitHub средстве выполнения и выводит сообщение в консоль. Позже вы замените runner, размещенный на GitHub, на самостоятельный runner.
Получение личного токена доступа GitHub
Чтобы запустить локальное средство выполнения, необходимо создать личный маркер доступа (PAT) в GitHub. Каждый раз, когда запускается runner, персональный токен доступа используется для создания маркера, чтобы зарегистрировать runner в GitHub. PAT также используется правилом масштабирования GitHub Actions для отслеживания очереди рабочих процессов репозитория и запуска обработчиков по мере необходимости.
Примечание.
Личные маркеры доступа (PATS) имеют дату окончания срока действия. Регулярно поворачивайте маркеры, чтобы они оставались действительными (не истекли) для поддержания непрерывной службы.
В GitHub выберите рисунок профиля в правом верхнем углу и выберите "Параметры".
Выберите Параметры разработчика.
В разделе "Личные маркеры доступа" выберите токены с точной настройкой.
Выберите Создать новый маркер.
На экране нового подробного личного токена доступа введите следующие значения.
Настройка Значение Имя токена Введите имя токена. Истечение срока действия Выберите 30 дней. Доступ к репозиторию Выберите только репозитории и выберите созданный репозиторий. Введите следующие значения разрешений репозитория.
Настройка Значение Действия Выберите режим только для чтения. Администрирование Выберите "Чтение и запись". Метаданные Выберите режим только для чтения. Щелкните Создать маркер.
Скопируйте значение токена.
Определите переменные, используемые позже для настройки исполнителя и правила масштабирования.
GITHUB_PAT="<GITHUB_PAT>" REPO_OWNER="<REPO_OWNER>" REPO_NAME="<REPO_NAME>" REGISTRATION_TOKEN_API_URL="<YOUR_REGISTRATION_TOKEN_API_URL>"
Замените значения заполнителей следующими значениями:
Заполнитель Значение <GITHUB_PAT>
Ваш созданный GitHub PAT. <REPO_OWNER>
Владелец созданного ранее репозитория. Обычно это значение является именем пользователя GitHub. <REPO_NAME>
Имя созданного ранее репозитория. Это значение совпадает с именем, введенным в поле имени репозитория. <YOUR_REGISTRATION_TOKEN_API_URL>
URL API токена регистрации в файле entrypoint.sh. Например, "https://myapi.example.com/get-token".
Создание образа контейнера GitHub Actions runner
Чтобы создать самостоятельно размещенное средство выполнения, необходимо собрать образ контейнера, который запускает средство выполнения. В этом разделе описано, как создать образ контейнера и отправить его в реестр контейнеров.
Примечание.
Образ, который вы создаете в этом руководстве, содержит базовый локальный модуль выполнения, подходящий для запуска в качестве задания "Приложения контейнеров". Его можно настроить для включения дополнительных средств или зависимостей, необходимых рабочим процессам.
Определите имя образа контейнера и реестра.
CONTAINER_IMAGE_NAME="github-actions-runner:1.0" CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"
Замените
<CONTAINER_REGISTRY_NAME>
уникальным именем для создания реестра контейнеров. Имена реестра контейнеров должны быть уникальными в Azure и составлять от 5 до 50 символов длиной, содержащей только цифры и строчные буквы.Создайте реестр контейнеров.
az acr create \ --name "$CONTAINER_REGISTRY_NAME" \ --resource-group "$RESOURCE_GROUP" \ --location "$LOCATION" \ --sku Basic
Реестр контейнеров должен разрешить токены аудитории Azure Resource Manager (ARM) для аутентификации, чтобы можно было использовать управляемое удостоверение для извлечения образов.
Используйте следующую команду, чтобы проверить, разрешены ли токены ARM для доступа к реестру контейнеров Azure (ACR).
az acr config authentication-as-arm show --registry "$CONTAINER_REGISTRY_NAME"
Если разрешены маркеры ARM, команда выводит следующую команду.
{ "status": "enabled" }
Если
status
disabled
, разрешите токены ARM с помощью следующей команды.az acr config authentication-as-arm update --registry "$CONTAINER_REGISTRY_NAME" --status enabled
Файл Dockerfile для создания образа runner доступен на сайте GitHub. Выполните следующую команду, чтобы клонировать репозиторий и создать образ контейнера в облаке с помощью
az acr build
команды.az acr build \ --registry "$CONTAINER_REGISTRY_NAME" \ --image "$CONTAINER_IMAGE_NAME" \ --file "Dockerfile.github" \ "https://github.com/Azure-Samples/container-apps-ci-cd-runner-tutorial.git"
Теперь образ доступен в реестре контейнеров.
Создание управляемого удостоверения, назначаемого пользователем
Чтобы избежать использования учетных данных администратора, извлекайте образы из частных репозиториев в Azure Реестре контейнеров Microsoft, используя управляемые удостоверения для аутентификации. Когда это возможно, используйте управляемую идентификацию, назначаемую пользователем, для извлечения изображений.
Создайте назначенное пользователем управляемое удостоверение. Перед выполнением следующих команд выберите имя управляемого удостоверения, заменив
\<PLACEHOLDER\>
на это имя.IDENTITY="<YOUR_IDENTITY_NAME>"
az identity create \ --name $IDENTITY \ --resource-group $RESOURCE_GROUP
Получите идентификатор ресурса сущности.
IDENTITY_ID=$(az identity show \ --name $IDENTITY \ --resource-group $RESOURCE_GROUP \ --query id \ --output tsv)
Развертывание локального runner в качестве задания
Теперь можно создать задание, использующее образ контейнера. В этом разделе вы создаёте задание, которое запускает самообслуживаемый агент и подключается к GitHub, используя PAT, который вы создали ранее. Задание использует github-runner
правило масштабирования для создания заданий на основе количества ожидающих выполнения рабочих процессов.
Создайте задание в среде "Приложения контейнеров".
az containerapp job create \ --name "$JOB_NAME" \ --resource-group "$RESOURCE_GROUP" \ --environment "$ENVIRONMENT" \ --trigger-type Event \ --replica-timeout 1800 \ --replica-retry-limit 0 \ --replica-completion-count 1 \ --parallelism 1 \ --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \ --min-executions 0 \ --max-executions 10 \ --polling-interval 30 \ --scale-rule-name "github-runner" \ --scale-rule-type "github-runner" \ --scale-rule-metadata "githubAPIURL=https://api.github.com" "owner=$REPO_OWNER" "runnerScope=repo" "repos=$REPO_NAME" "targetWorkflowQueueLength=1" \ --scale-rule-auth "personalAccessToken=personal-access-token" \ --cpu "2.0" \ --memory "4Gi" \ --secrets "personal-access-token=$GITHUB_PAT" \ --env-vars "GITHUB_PAT=secretref:personal-access-token" "GH_URL=https://github.com/$REPO_OWNER/$REPO_NAME" "REGISTRATION_TOKEN_API_URL=https://api.github.com/repos/$REPO_OWNER/$REPO_NAME/actions/runners/registration-token" \ --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io" \ --mi-user-assigned "$IDENTITY_ID" \ --registry-identity "$IDENTITY_ID"
В следующей таблице описаны ключевые параметры, используемые в команде.
Конфигурация правила масштабирования определяет источник событий для мониторинга. Правила оцениваются на каждом интервале опроса, чтобы определить, сколько запусков заданий следует инициировать. Дополнительные сведения см. в разделе "Настройка правил масштабирования".
Задание на основе событий теперь создано в среде контейнерных приложений.
Запуск рабочего процесса и проверка задания
Задание настраивается для оценки правила масштабирования каждые 30 секунд. Во время каждой проверки проверяется количество рабочих процессов, которые ожидают выполнения и для которых требуется локальное средство выполнения, и запускается новое выполнение задания для ожидающего рабочего процесса, до 10 выполнений.
Чтобы проверить правильность настройки задания, необходимо изменить рабочий процесс, чтобы использовать локальное средство выполнения и запустить рабочий процесс. Затем можно просмотреть журналы выполнения задания, чтобы увидеть выполнение рабочего процесса.
В репозитории GitHub перейдите к созданному ранее рабочему процессу. Это ФАЙЛ YAML в каталоге
.github/workflows
.Выберите Изменить на месте.
Обновите свойство
runs-on
доself-hosted
:runs-on: self-hosted
Выберите " Зафиксировать изменения...".
Выберите " Зафиксировать изменения".
Перейдите на вкладку "Действия ".
Теперь новый рабочий процесс помещается в очередь. В течение 30 секунд выполнение задания начнется, и рабочий процесс завершится в ближайшее время.
Дождитесь завершения действия, прежде чем перейти к следующему шагу.
Выведите список выполнений задания, чтобы убедиться, что выполнение задания было успешно создано и завершено.
az containerapp job execution list \ --name "$JOB_NAME" \ --resource-group "$RESOURCE_GROUP" \ --output table \ --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'
Создание проекта и репозитория Azure DevOps
Для выполнения конвейера требуется проект и репозиторий Azure DevOps.
Перейдите к Azure DevOps и войдите в учетную запись.
Выберите существующую организацию или создайте новую.
На странице обзора организации выберите новый проект и введите следующие значения.
Настройка Значение Имя проекта Введите имя проекта. Видимость Выберите категорию Частное. Нажмите кнопку создания.
В боковой навигации выберите Repos.
В разделе "Инициализация основной ветви" с помощью README или .gitignore выберите "Добавить README".
Оставьте остальные значения в качестве значений по умолчанию и выберите инициализация.
Создание пула агентов
Создайте пул агентов для запуска локального runner.
В проекте Azure DevOps разверните левую панель навигации и выберите параметры проекта.
В разделе "Конвейеры" в меню навигации "Параметры проекта" выберите пулы агентов.
Выберите " Добавить пул" и введите следующие значения.
Настройка Значение Пул для подключения Выберите Создать. Тип пула Выберите самостоятельный хостинг. Имя Введите контейнер приложения. Предоставление разрешения на доступ ко всем конвейерам Установите этот флажок. Нажмите кнопку создания.
Получите личный токен доступа Azure DevOps
Чтобы запустить локальное средство выполнения, необходимо создать личный маркер доступа (PAT) в Azure DevOps. ПАТ используется для проверки подлинности исполнителя в Azure DevOps. Он также используется правилом масштабирования для определения количества ожидающих запусков конвейера и запуска новых выполнений заданий.
Примечание.
Личные маркеры доступа (PATS) имеют дату окончания срока действия. Регулярно поворачивайте маркеры, чтобы они оставались действительными (не истекли) для поддержания непрерывной службы.
В Azure DevOps выберите параметры пользователя рядом с изображением профиля в правом верхнем углу.
Выберите Личные маркеры доступа.
На странице "Личные маркеры доступа" выберите новый маркер и введите следующие значения.
Настройка Значение Имя Введите имя токена. Предприятие Выберите выбранную или созданную ранее организацию. Области действия Выберите Определённый пользователем. Отображение всех областей Выберите " Показать все области". Пулы агентов (чтение и управление) Выберите Пулы агентов (Чтение и Управление) Оставьте все остальные области не выбранными.
Нажмите кнопку создания.
Скопируйте значение токена в безопасное место.
Вы не можете получить маркер после выхода страницы.
Определите переменные, которые используются для настройки заданий приложений контейнеров позже.
AZP_TOKEN="<AZP_TOKEN>" ORGANIZATION_URL="<ORGANIZATION_URL>" AZP_POOL="container-apps"
Замените значения заполнителей следующими значениями:
Заполнитель Значение Комментарии <AZP_TOKEN>
Созданный вами токен PAT Azure DevOps. <ORGANIZATION_URL>
URL-адрес организации Azure DevOps. Убедитесь, что в конце URL-адреса отсутствует окончательный /
.Например, https://dev.azure.com/myorg
илиhttps://myorg.visualstudio.com
.
Создание образа контейнера агента Azure Pipelines
Чтобы создать самостоятельно размещённого агента, необходимо собрать образ контейнера, в котором будет работать агент. В этом разделе описано, как создать образ контейнера и отправить его в реестр контейнеров.
Примечание.
Образ, создаваемый в этом руководстве, содержит базовый автономный агент, подходящий для запуска в качестве задания "Приложения контейнеров". Вы можете настроить его для добавления дополнительных инструментов или зависимостей, необходимых для ваших конвейеров.
Вернитесь в терминал, определите имя образа контейнера и реестра.
CONTAINER_IMAGE_NAME="azure-pipelines-agent:1.0" CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"
Замените
<CONTAINER_REGISTRY_NAME>
уникальным именем для создания реестра контейнеров.Имена реестра контейнеров должны быть уникальными в Azure и составлять от 5 до 50 символов длиной, содержащей только цифры и строчные буквы.
Создайте реестр контейнеров.
az acr create \ --name "$CONTAINER_REGISTRY_NAME" \ --resource-group "$RESOURCE_GROUP" \ --location "$LOCATION" \ --sku Basic \ --admin-enabled true
Файл Dockerfile для создания образа runner доступен на сайте GitHub. Выполните следующую команду, чтобы клонировать репозиторий и создать образ контейнера в облаке с помощью
az acr build
команды.az acr build \ --registry "$CONTAINER_REGISTRY_NAME" \ --image "$CONTAINER_IMAGE_NAME" \ --file "Dockerfile.azure-pipelines" \ "https://github.com/Azure-Samples/container-apps-ci-cd-runner-tutorial.git"
Теперь образ доступен в реестре контейнеров.
Создайте самостоятельно размещённого агента-заполнителя
Перед тем как запустить самостоятельно размещенного агента в новом пуле агентов, необходимо создать временного агента. Агент заполнителя места обеспечивает доступность пула агентов. Конвейерные процессы, использующие пул агентов, дают сбой при отсутствии агента-заполнителя.
Вы можете вручную запустить задачу, чтобы зарегистрировать автономного агента-заполнителя. Задание выполняется один раз и может быть удалено. Агент заполнителя не использует ресурсы в приложениях контейнеров Azure или Azure DevOps.
Создайте вручную задание в среде "Приложения контейнеров" для создания агента заполнителя.
az containerapp job create -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP" --environment "$ENVIRONMENT" \ --trigger-type Manual \ --replica-timeout 300 \ --replica-retry-limit 0 \ --replica-completion-count 1 \ --parallelism 1 \ --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \ --cpu "2.0" \ --memory "4Gi" \ --secrets "personal-access-token=$AZP_TOKEN" "organization-url=$ORGANIZATION_URL" \ --env-vars "AZP_TOKEN=secretref:personal-access-token" "AZP_URL=secretref:organization-url" "AZP_POOL=$AZP_POOL" "AZP_PLACEHOLDER=1" "AZP_AGENT_NAME=placeholder-agent" \ --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"
В следующей таблице описаны ключевые параметры, используемые в команде.
Параметр Описание --replica-timeout
Максимальная длительность выполнения реплики. --replica-retry-limit
Количество повторных попыток неудачной реплики. --replica-completion-count
Количество реплик, которые должны быть успешно завершены, прежде чем выполнение задания будет считаться успешным. --parallelism
Количество реплик, запускаемых при каждом выполнении задания. --secrets
Секреты для использования в работе. --env-vars
Переменные среды, используемые для задания. --registry-server
Сервер реестра контейнеров, используемый для задания. Для Реестр контейнеров Azure команда автоматически настраивает проверку подлинности. Настройка переменной среды
AZP_PLACEHOLDER
настраивает контейнер агента так, чтобы он регистрировался как автономный временный агент без запуска задания.Выполните задание вручную, чтобы создать подставного агента.
az containerapp job start -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP"
Выведите список выполнений задания, чтобы убедиться, что выполнение задания было успешно создано и завершено.
az containerapp job execution list \ --name "$PLACEHOLDER_JOB_NAME" \ --resource-group "$RESOURCE_GROUP" \ --output table \ --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'
Убедитесь, что агент-заполнитель был создан в Azure DevOps.
- В Azure DevOps перейдите к проекту.
- Выберите параметры проекта>пулы агентов>контейнеры приложений>агенты.
- Убедитесь, что агент-заполнитель под именем
placeholder-agent
указан, и его статус — «не в сети».
Работа больше не требуется. Ее можно удалить.
az containerapp job delete -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP"
Создание локального агента в качестве задания на основе событий
Теперь, когда у вас есть замещающий агент, можно создать саморазмещаемого агента. В этом разделе вы создаете задание, управляемое событиями, которое запускает автономного агента при запуске конвейера.
az containerapp job create -n "$JOB_NAME" -g "$RESOURCE_GROUP" --environment "$ENVIRONMENT" \
--trigger-type Event \
--replica-timeout 1800 \
--replica-retry-limit 0 \
--replica-completion-count 1 \
--parallelism 1 \
--image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME" \
--min-executions 0 \
--max-executions 10 \
--polling-interval 30 \
--scale-rule-name "azure-pipelines" \
--scale-rule-type "azure-pipelines" \
--scale-rule-metadata "poolName=$AZP_POOL" "targetPipelinesQueueLength=1" \
--scale-rule-auth "personalAccessToken=personal-access-token" "organizationURL=organization-url" \
--cpu "2.0" \
--memory "4Gi" \
--secrets "personal-access-token=$AZP_TOKEN" "organization-url=$ORGANIZATION_URL" \
--env-vars "AZP_TOKEN=secretref:personal-access-token" "AZP_URL=secretref:organization-url" "AZP_POOL=$AZP_POOL" \
--registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"
В следующей таблице описываются параметры правила масштабирования, используемые в команде.
Параметр | Описание |
---|---|
--min-executions |
Минимальное количество выполнения заданий для каждого интервала опроса. |
--max-executions |
Максимальное количество выполнения заданий для каждого интервала опроса. |
--polling-interval |
Интервал опроса, с помощью которого необходимо оценить правило масштабирования. |
--scale-rule-name |
Имя правила масштабирования. |
--scale-rule-type |
Тип используемого правила масштабирования. Чтобы узнать больше о скалере Azure Pipelines, см. документацию KEDA. |
--scale-rule-metadata |
Метаданные правила масштабирования. |
--scale-rule-auth |
Проверка подлинности для правила масштабирования. |
Конфигурация правила масштабирования определяет источник событий для мониторинга. Правила оцениваются на каждом интервале опроса, чтобы определить, сколько запусков заданий следует инициировать. Дополнительные сведения см. в разделе "Настройка правил масштабирования".
Задание на основе событий теперь создано в среде контейнерных приложений.
Запуск конвейера и проверка задания
После настройки локального задания агента можно запустить конвейер и убедиться, что он работает правильно.
В левой части навигации проекта Azure DevOps перейдите к Конвейерам.
Выберите Создать конвейер.
Выберите Azure Repos Git в качестве расположения кода.
Выберите созданный ранее репозиторий.
Выберите Стартовый конвейер.
В yamL конвейера измените значение
pool
наvmImage: ubuntu-latest
name: container-apps
.pool: name: container-apps
Выберите Сохранить и выполнить.
Конвейер запускается и использует локальное задание агента, созданное в среде "Приложения контейнеров".
Выведите список выполнений задания, чтобы убедиться, что выполнение задания было успешно создано и завершено.
az containerapp job execution list \ --name "$JOB_NAME" \ --resource-group "$RESOURCE_GROUP" \ --output table \ --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'
Совет
Возникли проблемы? Сообщите нам, создав тикет в репозитории Azure Container Apps на GitHub.
Очистка ресурсов
После завершения выполните следующую команду, чтобы удалить группу ресурсов, содержащую ресурсы приложений контейнеров.
Внимание
Следующая команда удаляет указанную группу ресурсов и все ресурсы, содержащиеся в ней. Если ресурсы вне области этого руководства существуют в указанной группе ресурсов, они также удаляются.
az group delete \
--resource-group $RESOURCE_GROUP
Чтобы удалить репозиторий GitHub, ознакомьтесь с разделом "Удаление репозитория".