Есть ли способ определить контейнер, в котором могут выполняться все этапы и задания конвейера от начала до конца, не останавливая контейнер между этапами.
Я создаю конвейер Azure для создания каждого микросервиса (который включает этапы развертывания mvn, сборки и выпуска докера, выпуска ecr, выпуска mvn). Для сборки Docker необходимы артефакты сборки, созданные на этапе развертывания mvn для создания образа Docker. Я попытался использовать контейнеры в конвейере, которые я написал внутри микросервиса, чтобы запустить конвейер для создания микросервисов.
Кажется, что контейнер инициализируется и работает, но он останавливается после каждого этапа. Сборки, созданные на этапе сборки, отсутствуют, когда выполняется этап сборки и выпуска докера.
в триггерном конвейере:
containers:
- container: dockerContainer
image: image name
endpoint: dockerhubcreds
options: --user 0:0
конвейер для создания микросервисов:
- stage: Build
dependsOn: SetupMaven
jobs:
- job: Build_job
displayName: Build
container: dockerContainer
Когда я попробовал описанный выше метод, контейнер останавливался после каждого этапа. Также я использую локальный агент Ubuntu для тестирования и агент Microsoft (Ubuntu-последняя версия) для производства.
@bryanbcook У меня есть этапы (развертывание mvn, сборка докера, выпуск, выпуск ecr и выпуск mvn). Для сборки Docker необходимы артефакты сборки, созданные на этапе развертывания mvn для создания образа Docker. В этом случае контейнер останавливается после развертывания mvn, поэтому артефакты сборки из развертывания mvn недоступны на этапе сборки Docker.
ОК, проблема в том, что файлы, созданные задачами mvn, не сохраняются между этапами (что происходит независимо от того, является ли это контейнером или стандартными задачами). каковы пути к файлам артефактов сборки, созданных mvn?
Target/project-name.jar, созданный mvn, используется на этапе «сборки докера». Но теперь я сгруппировал все задачи в одну работу. теперь это работает. Когда я попробовал использовать автономный агент в контейнере Docker, я получил ошибку ##[ошибка]ОШИБКА: невозможно подключиться к демону Docker по адресу unix:///var/run/docker.sock. Демон докера запущен? ##[ошибка]Процесс «/usr/bin/docker» завершился с ошибкой с кодом завершения 1.
Если вы используете локальный агент как образ Docker и пытаетесь запустить Docker внутри него, требуется дополнительная настройка вашего агента сборки.
Вы не можете использовать один и тот же экземпляр контейнера во всех заданиях в конвейере. Имейте в виду, что каждое задание может выполняться несколькими агентами сборки, которые могут работать на разных машинах.
Контейнеры используются на уровне задания, а не на этапе. Контейнеры можно использовать для запуска списка задач внутри задания, а не этапа. Если вам нужен детальный контроль на уровне отдельного шага, цели шага позволяют вам выбирать контейнер или хост для каждого шага.
Дополнительные сведения см. в разделе Определить задания контейнера.
Я думаю, важно понимать, что это ограничение касается не только контейнеров. Задания привязаны к агенту, и в зависимости от вашей настройки у вас будет свой агент для каждого задания.
@bryanbcook да, это правильно.
Как упомянул @Rui Jarimba, контейнеры используются на уровне заданий. Если вы используете агент, размещенный на MS, каждое задание получает новый агент, и контейнер также будет совершенно новым.
Если вы хотите, чтобы все ваши этапы/задания выполнялись в одном контейнере, вы можете настроить автономный агент в Docker и использовать его для запуска вашего конвейера. Подробные инструкции см. в разделе Запуск автономного агента в Docker.
Примечание. При запуске изображения НЕ добавляйте --once
в docker run
. В противном случае, используя флаг --once
, вы получите новый контейнер агента для каждого задания конвейера.
Большое спасибо за ответ. Если я настрою автономный агент в контейнере Docker, все ли, кому нужно запустить конвейер, также установят автономный агент?
Нет. После того как вы настроили автономный агент, вы сможете увидеть его в пуле агентов. Любой, у кого есть разрешения на доступ к пулу агентов, может использовать его в конвейере. Подробные сведения о разрешениях см. в разделе Настройка безопасности пула агентов в Azure Pipelines.
Основная концепция конвейеров не выполняется сквозным образом как единый процесс. Конвейер может выполнять несколько заданий последовательно или одновременно в различных операционных системах. Задания ограничены агентами, и каждое задание потенциально может использовать другого агента. Если вы разделите свой процесс на различные этапы или задания, вы не сможете делать предположения о результатах работы файловой системы из предыдущих заданий.
Если у вас многоэтапный конвейер и вы хотите сделать предположения о файловой системе, вам необходимо гарантировать состояние файловой системы для этого задания. Это достигается путем создания артефактов конвейера, которые можно переносить с одного этапа на другой.
Задача download
загружает артефакты в папку $(Pipeline.Workspace)/<artifact-name>
. В идеале вы должны смонтировать эту папку в свой контейнер, но папка должна существовать заранее. Поскольку контейнер уже монтирует рабочую область, вы можете скопировать артефакт в желаемое предполагаемое место.
Например, если вы хотите использовать maven для создания артефакта сборки, который будет развернут позже на другом этапе. Этот процесс тот же, если вы используете контейнеры.
stages:
- stage: build
jobs:
- job: build
steps:
# steps to build artifact located in /target/project-name.jar
- ...
# publish /target folder as artifact to be available for next stage
- publish: $(Build.SourcesDirectory)/target
artifact: build
displayName: 'Publish Build Artifact'
- stage: deploy
jobs:
- job: deploy
steps:
# download build artifact
- download: current
artifact: build
displayName: 'Download Build Artifact'
- task: CopyFiles@2 # move artifact into the original folder
inputs:
sourceFolder: $(Pipeline.Workspace)/build
taregetFolder: $(Build.SourcesDirectory)/target
# steps to work with the artifact like it was already there
- ...
какой аспект остановки контейнера влияет на вас?