Я хотел бы иметь возможность динамически выделять дочерние узлы докера для сборок и сделать так, чтобы конфигурация / настройка этих узлов была частью сценария Jenkinsfile groovy, который он использует.
Ограничения текущей настройки заданий означают, что у Дженкинса есть один узел / исполнитель (master), и я хотел бы поддержать использование Docker для узлов, чтобы устранить это узкое место.
Я заметил, что есть два способа использования контейнера Docker в качестве узла:
- Вы можете использовать раздел агента в файле конвейера , который позволяет вам указать изображение для использования. Как часть этого, вы можете указать целевой узел, который поддерживает запуск образов докера, но я не дошел до того, чтобы увидеть, что происходит.
- Вы можете использовать Подключаемый модуль Jenkins Docker , который позволяет добавлять Docker Cloud в конфигурацию Jenkins. Он позволяет вам указать метку, которая при использовании в качестве части сборки порождает контейнер в этом «облаке» из изображения, выбранного в конфигурации облака. В этом случае «облако» - это экземпляр докера, работающий на сервере Jenkins.
К сожалению, не похоже, что вы можете использовать оба вместе - используя метку, но указание образа докера в конфигурации (1), где метка соответствует конфигурации шаблона облака докера (2), похоже, не работает и вместо этого выдает ошибку метки не найден во время сборки.
В идеале я бы предпочел, чтобы элемент управления находился в файле конвейера groovy, поэтому конфигурация хранится в приложении (1), а не на сервере Jenkins (2). Тем не менее, предлагает , что если я использую раздел agent и предоставлю образ докера, он все равно должен сначала нацелиться на существующего исполнителя (то есть master), что вызовет другие сборки в очередь, пока текущая сборка не будет завершена.
Я нахожусь в стадии миграции сборок, поэтому не все сборки могут поддерживать использование док-контейнера в качестве узла, и сборки будут иметь проблемы при параллельном запуске на узле master.
Есть ли способ для файла конвейера докера определить образ дочернего узла, на котором он работает?
Есть несколько вариантов, которые я рассмотрел, но еще не попробовал:
- Миграция заданий для запуска в «облаке докеров» до тех пор, пока все задания не поддерживаются на дочерних узлах-контейнерах, затем переместите конфигурацию из Jenkins в файл сборки конвейера для каждого задания и включите параллельные сборки на узле
master.
- Попытка добавить новую конфигурацию узла, которая фактически является копией
master (использует тот же сервер, только в другом месте). Сконфигурируйте его для поддержки параллельных сборок, и чтобы все перенесенные задания явно предназначались для узла во время сборок.