Руководство по развертыванию локально размещенных модулей CI/CD и агентов с помощью заданий приложений контейнеров Azure

  • Статья

GitHub Actions и Azure Pipelines позволяют запускать рабочие процессы CI/CD с локальными средствами выполнения и агентами. Вы можете запускать локальные средства выполнения и агенты с помощью заданий приложений контейнеров Azure, управляемых событиями.

Локальные средства выполнения полезны, если необходимо запускать рабочие процессы, требующие доступа к локальным ресурсам или средствам, которые недоступны для облачного runner. Например, локальный модуль выполнения в задании "Приложения контейнеров" позволяет рабочему процессу получать доступ к ресурсам в виртуальной сети задания, которая недоступна для облачного запуска.

Запуск локальных runners в качестве заданий на основе событий позволяет воспользоваться бессерверным характером приложений контейнеров Azure. Задания выполняются автоматически, когда рабочий процесс активируется и завершает работу после завершения задания.

Вы оплачиваете только время выполнения задания.

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

  • Создание среды приложений-контейнеров для развертывания локального запуска
  • Создание репозитория GitHub для запуска рабочего процесса, использующего локальное средство выполнения
  • Создание образа контейнера, на котором выполняется runner GitHub Actions
  • Развертывание runner в качестве задания в среде "Приложения контейнеров"
  • Создайте рабочий процесс, использующий локальное средство выполнения и убедитесь, что он выполняется.

Внимание

Для частных репозиториев рекомендуется использовать только локальные модули выполнения. Использование их с общедоступными репозиториями может позволить опасному коду выполняться в локальном средстве выполнения. Дополнительные сведения см. в разделе безопасности локального запуска.

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

  • Создание среды приложений-контейнеров для развертывания локального агента
  • Создание организации и проекта Azure DevOps
  • Создание образа контейнера, на котором выполняется агент Azure Pipelines
  • Создание агента-заполнителя в среде "Приложения контейнеров" с помощью ручного задания
  • Развертывание агента в качестве задания в среде "Приложения контейнеров"
  • Создайте конвейер, использующий локальный агент и убедитесь, что он выполняется.

Внимание

Для частных проектов рекомендуется использовать только локальные агенты. Использование их с общедоступными проектами может позволить выполнять опасный код на локальном агенте. Дополнительные сведения см. в разделе "Безопасность локального агента".

Примечание.

Приложения и задания контейнеров не поддерживают запуск Docker в контейнерах. Все действия в рабочих процессах, использующих команды Docker, завершаются ошибкой при запуске на локальном сервере или агенте в задании приложений контейнеров.

Необходимые компоненты

  • Организация Azure DevOps. Если у вас нет организации DevOps с активной подпиской, ее можно создать бесплатно.

Ознакомьтесь с ограничениями заданий для списка ограничений.

Настройка

Чтобы войти в Azure из ИНТЕРФЕЙСА командной строки, выполните следующую команду и следуйте инструкциям, чтобы завершить процесс проверки подлинности.

az login

Чтобы убедиться, что вы используете последнюю версию интерфейса командной строки, выполните команду обновления.

az upgrade

Затем установите или обновите расширение "Приложения контейнеров Azure" для интерфейса командной строки.

az extension add --name containerapp --upgrade

Теперь, когда установлено текущее расширение или модуль, зарегистрируйте Microsoft.App пространства имен и Microsoft.OperationalInsights пространств имен.

Примечание.

Ресурсы Контейнеров приложений Azure перенесены из пространства имен Microsoft.Web в пространство имен Microsoft.App. Дополнительные сведения см. в статье о миграции пространства имен из Microsoft.Web в Microsoft.App в марте 2022 г..

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" выступает в качестве безопасной границы для приложений и заданий контейнеров, чтобы они могли совместно использовать ту же сеть и взаимодействовать друг с другом.

Примечание.

Сведения о создании среды приложений-контейнеров, интегрированной с существующей виртуальной сетью, см. в статье "Предоставление виртуальной сети для внутренней среды приложений контейнеров Azure".

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

    az group create \
    --name "$RESOURCE_GROUP" \
    --location "$LOCATION"

  2. Создайте среду приложений контейнеров с помощью следующей команды.

    az containerapp env create \
    --name "$ENVIRONMENT" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION"

Создание репозитория GitHub для запуска рабочего процесса

Чтобы выполнить рабочий процесс, необходимо создать репозиторий GitHub, содержащий определение рабочего процесса.

  1. Перейдите к GitHub и войдите.

  2. Создайте новый репозиторий, введя следующие значения.

    Параметр Значение
    Ответственный Выберите имя пользователя GitHub.
    Имя репозитория Введите имя репозитория.
    Visibility Выберите категорию Частное.
    Инициализация этого репозитория с помощью Выберите параметр Добавить файл сведений.

    Оставьте остальные значения выбранными по умолчанию.

  3. Щелкните Create repository (Создать репозиторий).

  4. В новом репозитории выберите "Действия".

  5. Найдите шаблон простого рабочего процесса и выберите "Настроить".

  6. Выберите "Зафиксировать изменения" , чтобы добавить рабочий процесс в репозиторий.

Рабочий процесс выполняется на ubuntu-latest размещенном в GitHub средстве выполнения и выводит сообщение в консоль. Позже вы замените размещенного на сайте GitHub средство выполнения на локальное средство выполнения.

Получение личного маркера доступа GitHub

Чтобы запустить локальное средство выполнения, необходимо создать личный маркер доступа (PAT) в GitHub. Каждый раз, когда запускается средство выполнения, ПАТ используется для создания маркера для регистрации бегуна в GitHub. Pat также используется правилом масштабирования GitHub Actions для отслеживания очереди рабочих процессов репозитория и запуска runner по мере необходимости.

  1. В GitHub выберите рисунок профиля в правом верхнем углу и выберите Параметры.

  2. Выберите Параметры разработчика.

  3. В разделе "Личные маркеры доступа" выберите точные маркеры.

  4. Выберите Создать новый маркер.

  5. На экране нового детального личного маркера доступа введите следующие значения.

    Параметр Значение
    Имя токена Введите имя маркера.
    Истечение срока действия Выберите 30 дней.
    Доступ к репозиторию Выберите только репозитории и выберите созданный репозиторий.

    Введите следующие значения разрешений репозитория.

    Параметр Значение
    Действия Выберите только для чтения.
    Администрирование Выберите "Чтение и запись".
    Метаданные Выберите только для чтения.

  6. Щелкните Создать маркер.

  7. Скопируйте значение маркера.

  8. Определите переменные, используемые для настройки средства выполнения и правила масштабирования позже.

    GITHUB_PAT="<GITHUB_PAT>"
REPO_OWNER="<REPO_OWNER>"
REPO_NAME="<REPO_NAME>"

    Замените значения заполнителей следующими значениями:

    Заполнитель Значение
    <GITHUB_PAT> Созданный GitHub PAT.
    <REPO_OWNER> Владелец созданного ранее репозитория. Обычно это значение является именем пользователя GitHub.
    <REPO_NAME> Имя созданного ранее репозитория. Это значение совпадает с именем, введенным в поле имени репозитория.

Создание образа контейнера runner GitHub Actions

Чтобы создать локальное средство выполнения, необходимо создать образ контейнера, который выполняет средство выполнения. В этом разделе описано, как создать образ контейнера и отправить его в реестр контейнеров.

Примечание.

Образ, который вы создаете в этом руководстве, содержит базовый локальный модуль выполнения, подходящий для запуска в качестве задания "Приложения контейнеров". Его можно настроить для включения дополнительных средств или зависимостей, необходимых рабочим процессам.

  1. Определите имя образа контейнера и реестра.

    CONTAINER_IMAGE_NAME="github-actions-runner:1.0"
CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"

    Замените <CONTAINER_REGISTRY_NAME> уникальным именем для создания реестра контейнеров. Имена реестра контейнеров должны быть уникальными в Azure и составлять от 5 до 50 символов длиной, содержащей только цифры и строчные буквы.

  2. Создайте реестр контейнеров.

    az acr create \
    --name "$CONTAINER_REGISTRY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION" \
    --sku Basic \
    --admin-enabled true

  3. Файл 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"

    Теперь образ доступен в реестре контейнеров.

Развертывание локального runner в качестве задания

Теперь можно создать задание, которое используется для использования образа контейнера. В этом разделе описано, как создать задание, которое выполняет локальное средство выполнения и выполняет проверку подлинности с помощью GitHub, созданного ранее. Задание использует github-runner правило масштабирования для создания заданий на основе количества ожидающих выполнения рабочих процессов.

  1. Создайте задание в среде "Приложения контейнеров".

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

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

    Параметр Описание
    --replica-timeout Максимальная длительность реплика может выполняться.
    --replica-retry-limit Количество повторных попыток неудачного реплика.
    --replica-completion-count Число реплика успешно завершено до успешного выполнения задания.
    --parallelism Количество реплика для запуска каждого задания.
    --min-executions Минимальное количество выполнения заданий для каждого интервала опроса.
    --max-executions Максимальное количество выполнения заданий для каждого интервала опроса.
    --polling-interval Интервал опроса, с помощью которого необходимо оценить правило масштабирования.
    --scale-rule-name Имя правила масштабирования.
    --scale-rule-type Тип используемого правила масштабирования. Дополнительные сведения о масштабировщике runner GitHub см. в документации ПО KEDA.
    --scale-rule-metadata Метаданные правила масштабирования. Если вы используете GitHub Enterprise, обновите githubAPIURL его URL-адрес API.
    --scale-rule-auth Проверка подлинности для правила масштабирования.
    --secrets Секреты, используемые для задания.
    --env-vars Переменные среды, используемые для задания.
    --registry-server Сервер реестра контейнеров, используемый для задания. Для Реестр контейнеров Azure команда автоматически настраивает проверку подлинности.

    Конфигурация правила масштабирования определяет источник событий для мониторинга. Он вычисляется по каждому интервалу опроса и определяет, сколько выполнения заданий необходимо активировать. Дополнительные сведения см. в разделе "Настройка правил масштабирования".

Задание на основе событий теперь создается в среде "Приложения контейнеров".

Запуск рабочего процесса и проверка задания

Задание настраивается для оценки правила масштабирования каждые 30 секунд. Во время каждой оценки он проверка количество ожидающих выполнения рабочих процессов, требующих локального запуска, и запускает новое выполнение задания для ожидающего рабочего процесса до настроенного максимум 10 выполнений.

Чтобы проверить правильность настройки задания, необходимо изменить рабочий процесс, чтобы использовать локальное средство выполнения и запустить рабочий процесс. Затем можно просмотреть журналы выполнения задания, чтобы увидеть выполнение рабочего процесса.

  1. В репозитории GitHub перейдите к созданному ранее рабочему процессу. Это ФАЙЛ YAML в каталоге .github/workflows .

  2. Выберите " Изменить" на месте.

  3. Обновите свойство self-hostedдо runs-on :

    runs-on: self-hosted

  4. Выберите " Зафиксировать изменения...".

  5. Выберите " Зафиксировать изменения".

  6. Перейдите на вкладку "Действия ".

    Теперь новый рабочий процесс помещается в очередь. В течение 30 секунд выполнение задания начнется, и рабочий процесс завершится в ближайшее время.

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

  7. Выведите список выполнений задания, чтобы убедиться, что выполнение задания было создано и выполнено успешно.

    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.

  1. Перейдите к Azure DevOps и войдите в учетную запись.

  2. Выберите существующую организацию или создайте новую.

  3. На странице обзора организации выберите новый проект и введите следующие значения.

    Параметр Значение
    Имя проекта Введите имя проекта.
    Видимость Выберите категорию Частное.

  4. Нажмите кнопку создания.

  5. В боковой навигации выберите Repos.

  6. В разделе "Инициализация основной ветви" с помощью README или .gitignore выберите "Добавить README".

  7. Оставьте остальные значения в качестве значений по умолчанию и выберите инициализация.

Создание пула агентов

Создайте пул агентов для запуска локального runner.

  1. В проекте Azure DevOps разверните левую панель навигации и выберите параметры проекта.

    Снимок экрана: кнопка

  2. В разделе "Конвейеры" в меню навигации "Параметры проекта" выберите пулы агентов.

    Снимок экрана: кнопка пулов агентов Azure DevOps.

  3. Выберите " Добавить пул" и введите следующие значения.

    Параметр Значение
    Пул для ссылки Выберите Создать.
    Тип пула Выберите локальное размещение.
    Имя Введите контейнер-приложения.
    Предоставление разрешения на доступ ко всем конвейерам Выберите этот проверка box.

  4. Нажмите кнопку создания.

Получение личного маркера доступа Azure DevOps

Чтобы запустить локальное средство выполнения, необходимо создать личный маркер доступа (PAT) в Azure DevOps. ПАТ используется для проверки подлинности средства выполнения с помощью Azure DevOps. Он также используется правилом масштабирования для определения количества ожидающих запусков конвейера и запуска новых выполнений заданий.

  1. В Azure DevOps выберите параметры пользователя рядом с изображением профиля в правом верхнем углу.

  2. Выберите Личные маркеры доступа.

  3. На странице "Личные маркеры доступа" выберите новый маркер и введите следующие значения.

    Параметр Значение
    Имя Введите имя маркера.
    Предприятие Выберите выбранную или созданную ранее организацию.
    Области действия Выберите "Настраиваемый".
    Показать все область Выберите "Показать все область".
    Пулы агентов (чтение и управление) Выберите пулы агентов (чтение и управление)

    Оставьте все остальные область не выбраны.

  4. Нажмите кнопку создания.

  5. Скопируйте значение маркера в безопасное расположение.

    Вы не можете получить маркер после выхода страницы.

  6. Определите переменные, которые используются для настройки заданий приложений контейнеров позже.

    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

Чтобы создать автономный агент, необходимо создать образ контейнера, который запускает агент. В этом разделе описано, как создать образ контейнера и отправить его в реестр контейнеров.

Примечание.

Образ, создаваемый в этом руководстве, содержит базовый автономный агент, подходящий для запуска в качестве задания "Приложения контейнеров". Его можно настроить для включения дополнительных средств или зависимостей, необходимых конвейерам.

  1. Вернитесь в терминал, определите имя образа контейнера и реестра.

    CONTAINER_IMAGE_NAME="azure-pipelines-agent:1.0"
CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>"

    Замените <CONTAINER_REGISTRY_NAME> уникальным именем для создания реестра контейнеров.

    Имена реестра контейнеров должны быть уникальными в Azure и составлять от 5 до 50 символов длиной, содержащей только цифры и строчные буквы.

  2. Создайте реестр контейнеров.

    az acr create \
    --name "$CONTAINER_REGISTRY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --location "$LOCATION" \
    --sku Basic \
    --admin-enabled true

  3. Файл 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.

  1. Создайте задание вручную в среде "Приложения контейнеров", создающей агент заполнителя.

    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 Настройка переменной среды настраивает контейнер агента для регистрации в качестве автономного агента заполнителя без выполнения задания.

  2. Выполните задание вручную, чтобы создать агент заполнителя.

    az containerapp job start -n "$PLACEHOLDER_JOB_NAME" -g "$RESOURCE_GROUP"

  3. Выведите список выполнений задания, чтобы убедиться, что выполнение задания было создано и выполнено успешно.

    az containerapp job execution list \
    --name "$PLACEHOLDER_JOB_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --output table \
    --query '[].{Status: properties.status, Name: name, StartTime: properties.startTime}'

  4. Убедитесь, что агент заполнителя был создан в Azure DevOps.

    1. В Azure DevOps перейдите к проекту.
    2. Выберите агенты контейнеров-приложений> для пулов>>параметров проекта.
    3. Убедитесь, что именованный placeholder-agent агент заполнителя указан и его состояние находится в автономном режиме.

  5. Задание не требуется снова. Ее можно удалить.

    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 Проверка подлинности для правила масштабирования.

Конфигурация правила масштабирования определяет источник событий для мониторинга. Он вычисляется по каждому интервалу опроса и определяет, сколько выполнения заданий необходимо активировать. Дополнительные сведения см. в разделе "Настройка правил масштабирования".

Задание на основе событий теперь создается в среде "Приложения контейнеров".

Запуск конвейера и проверка задания

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

  1. В левой части навигации проекта Azure DevOps перейдите к Конвейерам.

  2. Выберите Создать конвейер.

  3. Выберите Azure Repos Git в качестве расположения кода.

  4. Выберите созданный ранее репозиторий.

  5. Выберите Простейший конвейер.

  6. В yamL конвейера измените значение pool на vmImage: ubuntu-latestname: container-apps.

    pool:
  name: container-apps

  7. Выберите Сохранить и выполнить.

    Конвейер запускается и использует локальное задание агента, созданное в среде "Приложения контейнеров".

  8. Выведите список выполнений задания, чтобы убедиться, что выполнение задания было создано и выполнено успешно.

    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, ознакомьтесь с разделом "Удаление репозитория".

Следующие шаги

Задания контейнерных приложений