Докер – Один Файл Дженкинса Или Несколько?

Итак, у меня есть файл Jenkins, определяющий конвейер сборки, а затем задание Jenkins (не конвейер) с очень простым сценарием развертывания для наших стеков Docker.

Видя, что файлы Jenkins могут стать такими же сложными и мощными, как и навыки кодирования (видя, что они могут довольно хорошо работать), буду ли я хранить все в одном файле Jenkins или иметь несколько файлов Jenkins?

Рассмотрим этот теоретический процесс:

 
 "which stages should be performed?
Please specify:
Build artefact,
build Docker Image, ..."
 
 

Будет ли все это помещено в один файл Jenkins и запускать разные этапы конвейера в соответствии с вводом пользователя, например

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

Или этот процесс следует разделить на несколько файлов Jenkins с несколькими заданиями/конвейерами Jenkins для каждого файла Jenkins, чтобы выполнить часть процесса?

#docker #jenkins #jenkins-pipeline #jenkinsfile

Это действительно зависит от личных предпочтений.

Еще один инструмент, о котором вы, возможно, не знали: общие библиотеки для Pipeline. Они позволяют быстро писать собственные шаги конвейера или выделять общий код конвейера без написания плагина Jenkins на Java.

Между несколькими заданиями Pipeline и общими библиотеками существует множество способов разделить код вашего задания, и нет единого правильного ответа, как это сделать. У меня есть одно предложение: определить, какие шаги в вашем процессе являются «атомарными», то есть какова наименьшая группа шагов, которую вы представляете администраторам/операторам/разработчикам/и т. д. возможно, придется бежать самостоятельно? Тогда каждая «атомная единица» должна стать отдельной работой.

Например, предположим, что вы автоматизируете процесс развертывания, и ваш процесс в общем смысле выглядит так:

• строить
• развернуть в разработке
• развернуть в продукте

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

• Вы можете повторно запустить каждое задание отдельно в случае сбоя, вместо того, чтобы перезапускать весь процесс с самого начала. Не удалось развернуть продукт? Вам нужно только повторно запустить задание по развертыванию в продукт. Вам не нужно перестраивать или повторно развертывать в dev.

• Каждый этап процесса разделен, поэтому вы можете видеть, как часто он завершается успешно или неудачно. Некоторые этапы вашего процесса могут быть более надежными или нестабильными, чем другие; такое разделение дает вам понимание этого.

• Этот уровень абстракции позволяет людям, не связанным с эксплуатацией, легко выполнять задачи эксплуатации (если это то, что вы хотите/нужно в вашей организации). Когда все монолитно, единственное, что могут сделать люди, не являющиеся операторами, — это запустить весь процесс с самого начала. Когда все разделено на крошечные задачи, вам нужны глубокие знания в области эксплуатации, чтобы знать, какие части и в каком порядке выполнять. Разделив ваши задания на независимые, простые для понимания и подходящие по размеру фрагменты, человеку, не занимающемуся операциями, достаточно нажать одну кнопку, чтобы запустить автоматизированный операционный процесс.

Пройдя аналогичный путь, вот мои предложения:

Разбейте свои задачи по функциям; Сборка отличается от развертывания, которая отличается от выпуска. Вы можете получить более подробную информацию, но давайте пока остановимся на основах...

Во-вторых, если вы хотите определить, кому разрешено выполнять определенные действия, вы можете разбить эти функции по группам (разработка, тестирование, выпуск).

Построить конвейер:

• Вероятно, это ваша команда разработчиков.
• Одна задача по проверке исходников, компиляции и упаковке.
• Возможно, запустите модульные тесты для этого пакета.
• Возможно, отправьте код в SonarQube для анализа.
• В случае успеха опубликуйте этот артефакт сборки где-нибудь, например Artifactory/Nexus.
• Я автоматически запускаю это задание всякий раз, когда кто-то отправляет запрос в репозиторий.
• Кроме того, у меня есть некоторые правила, которые ограничивают поведение в зависимости от ветки (на самом деле я не хочу публиковать сборки для каждой отдельной ветки функций, но всегда для веток выпуска).

Развертывание конвейера:

• Это задание должно быть общим и принимать параметры, которые задают ему контекст.
• Мы развертываем на сервере разработки? Или протестировать/пререлить/вживую?
• Создайте задание Deploy-dev и задание Deploy-Prod. Оба используют один и тот же файл Jenkins.
• Кто имеет разрешение на выполнение этого действия?
• Что мы внедряем? Это раскрывающийся список артефактов, доступных в Artifactory.
• Я использую JobDSL для создания нескольких заданий, использующих один и тот же конвейер. Один для разработки/тестирования/предварительной/живой работы. Вы можете сначала вручную создать эти задания с соответствующими целями/пользователями развертывания.

Вышеупомянутое позволяет мне писать узконаправленные и конкретные конвейеры, но в то же время дает командам гибкость, необходимую им для повседневной работы. Разработка и тестирование — это самообслуживание. Только команда выпуска имеет доступ к развертыванию на предварительной/живой версии.

Другие трубопроводы:

• Как только это заработает, вы, вероятно, обратите внимание на вакансии, которые могут отключать серверы (самообслуживание для команд) и продвигать сборки из репозиториев моментальных/промежуточных/RC-репозиториев в золотые репозитории в Nexus/Artifactory и т. д.
• Вы используете git-flow? Как насчет заданий по созданию/завершению веток релизов/функций, обновлению версий maven, очистке устаревших веток, выполнению интеграционных сборок и т. д. Все это очень весело.

Надеюсь, это поможет.

Недавно я построил конвейер «сборка-тестирование-публикация-развертывание-откат» и боролся с вопросом об одном или многих каналах. Я решил использовать один канал для выполнения всех задач по той причине, что было бы легко перейти в одно место и указать каналу, что вы хотите сделать, введя параметры. В то время это казалось хорошей идеей, но с момента ее выпуска я почувствовал несколько недостатков:

1. Успех или неудача сборки конкретного конвейера не означает, что код приложения обязательно плох. Например, у нас произошел сбой производства из-за ошибки в коде канала, но это не значит, что сборка приложения плоха. Но значок состояния сборки показывает Failed in our ReadMe. Which isn't true (the way we see it).
2. Это сложнее. В трубе имеется несколько путей, определяемых значениями параметров. Больше шансов на ошибку, труднее проверять и т. д.
3. Грубо нарушает принцип единой ответственности, а также принцип наименьшего изумления. Он не обязательно будет делать то, что можно было бы ожидать, исходя из некоторых правил, которые я встроил в целях защиты пользователей. С более простой трубой вероятность ошибки будет меньше.
4. Наша организация еще не перешла на настоящее непрерывное развертывание, поэтому всегда будет задержка и человек, нажимающий кнопку «развертывание», даже в отделе контроля качества. Возможно, мы перейдем к этапу контроля качества с компакт-дисков раньше или позже, но нам придется доказать безопасность и надежность всего этого, прежде чем начальству будет комфортно использовать компакт-диск в производстве.

Все это говорит об отдельных трубах с четко разграниченными функциями.

Сейчас я создаю еще один конвейер для службы того же типа и планирую провести рефакторинг, чтобы использовать отдельные каналы для сборки и развертывания - так же, как @jayhendren, указанный выше:

1. Сборка, тестирование (на данный момент почти не существует), публикация артефактов.
   1. Я пытаюсь создать кулинарные книги, чтобы развернуть временные машины для развертывания, чтобы предоставить разработчикам изолированные тестовые песочницы.
2. Развертывание в отделе контроля качества
3. Развертывание в продукте

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

Если подумать об этом, пока я пишу это, канал сборки может остаться таким, какой он есть сейчас, как задание многоветвевого конвейера, созданное на основе файла Jenkinsfile, живущего в репозитории приложения, и основанного на любом отправке на github.:

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

Я хочу вернуться к этому и противоречить самому себе. После дальнейшего внутреннего обсуждения дизайна и моего собственного роста как пользователя Jenkins, я вернулся к

одна труба для всех задач

Разница заключалась в использовании меньшего количества параметров и управлении потоком с помощью ветки/PR, которая запускала сборку. Таким образом, хотя задачи могут различаться, выходные данные канала основаны только на его свойствах.