Устали от головной боли, связанной с плагинами для поддержки контроллера Jenkins? Избавьтесь от них.
Jenkins имеет множество плагинов, которые охватывают практически все, что вам может понадобиться в «родном» Jenkins. Хотя это может облегчить определенные действия, это может привести к кошмару администрирования, особенно если контроллер Jenkins используется более чем одной командой.
Какие проблемы с администрированием?
Различные функции
Плагины часто версионны, и разрешается устанавливать только отдельные версии каждого плагина. Это может быть проблематично, когда одна команда хочет использовать актуальные функции, например, в плагине языка Groovy, а другая команда полагается на функции, которые были устаревшими и удалены в последних версиях плагина.
Привязка
Привязка к определенной версии плагина является хорошей практикой, поскольку она предотвращает неожиданные изменения в поведении, однако это означает, что кто-то должен вручную следить за плагинами, проверять наличие новых версий, убеждаться, что они совместимы с вашими рабочими процессами, сообщать об изменениях базе пользователей и т.д., и очевидно, что чем больше плагинов у вас установлено, тем больше ручных усилий требуется.
Альтернативой является запуск плагинов без привязки к последним версиям, что работает для многих, но есть риск изменения API плагина или устаревания/удаления надежной функции, что приведет к поломке целого ряда рабочих мест, с которыми никто не хочет иметь дело в понедельник утром или, что еще хуже, быть вызванным в субботу днем.
Примечание: Я не считаю, что оставлять плагины прикрепленными и не проверять их как вариант, так как вы очень быстро получите контроллер Jenkins, полный дыр в безопасности и на версии Jenkins, которую нельзя обновить.
Поддержка плагинов
Большинство плагинов не поддерживаются командой Core Jenkins или Cloudbees, а поддерживаются сообществом или имеют сопровождающих с другой работой и интересами. Поэтому нередки случаи, когда плагины оказываются заброшенными и остаются без сопровождающего. Опять же, операторы Jenkins должны искать такие плагины и затем находить альтернативы, или же в итоге получить дыры в безопасности из-за непропатченных плагинов.
Так что же делать без плагинов?
Docker
Jenkins позволяет запускать этапы в контейнерах Docker, что означает, что вы можете иметь любые инструменты, которые вам нужны, в контейнере, а не в виде плагина или установленного и управляемого на каждом агенте. Нужно запустить Terraform? Используйте контейнер Docker. Нужно собрать проект Maven? Используйте контейнер Docker.
Дополнительную информацию об использовании агентов Docker см. на сайте https://www.jenkins.io/doc/book/pipeline/docker/.
stage("Terraform Testing") {
agent {
docker {
image "hashicorp/terraform"
reuseNode true
args "-v /etc/passwd:/etc/passwd:rw,z -v ${env.WORKSPACE}@tmp:${env.AGENT_HOME}:rw,z -v /etc/group:/etc/group:rw,z"
}
}
stages {
stage("Terraform Format") {
steps {
dir("${working_directory}") {
sh("terraform fmt -check")
}
}
}
}
}
Docker не только позволяет вам использовать любой подходящий вам инструмент без управления плагинами и потенциально нескольких установок одного и того же инструмента, но и позволяет запускать разные версии инструментов в разное время.
Например, в продакшене вы можете использовать текущую стабильную версию инструмента, а в девелопменте вы можете захотеть протестировать обновление версии инструмента, чтобы убедиться, что ваши конвейеры работают.
Можно также создать собственный контейнер Docker, включающий все необходимые инструменты для сборки и выпуска, который можно протестировать, изменить версию и выпустить, как любой другой проект. Это позволяет всем командам работать в унисон друг с другом на поддерживаемом инструментарии.
Использование частного реестра контейнеров также означает отсутствие неприятных сюрпризов, когда что-то меняется, когда вы этого не ожидаете, например, плагин удаляется из центра обновлений.
stage("Terraform Testing") {
agent {
docker {
image "hashicorp/terraform"
registryUrl 'https://my-registry.com'
registryCredentialsId 'registry-jenkins-credential'
reuseNode true
args "-v /etc/passwd:/etc/passwd:rw,z -v ${env.WORKSPACE}@tmp:${env.AGENT_HOME}:rw,z -v /etc/group:/etc/group:rw,z"
}
}
stages { ...
Общие библиотеки
Jenkins Shared Libraries расширяют основные функциональные возможности Jenkins, позволяя создавать функции, которые можно вызывать как шаги Jenkins. Это позволяет вам выполнять действия, которые вы должны делать регулярно (или разделять между командами), но не хотите использовать Docker и хотите обойтись без плагина, например, вызов стороннего API, перемещение некоторых артефактов на S3 или преобразование некоторых данных.
Так какие плагины мне нужны?
Конечно, некоторые плагины будут необходимы, но старайтесь придерживаться Jenkins, Cloudbees или основных провайдеров (Amazon, Google и т.д.), поскольку вероятность того, что они будут отменены, меньше, а вероятность того, что они будут регулярно выпускаться и исправляться, выше.
Я разбил их на четыре раздела плагинов, все из которых я использую ежедневно и только они установлены на моих контроллерах.
Во-первых, основные плагины, которые очень полезны на каждом современном контроллере Jenkins. Затем безопасность, так как повышение уровня безопасности Jenkins (особенно если он общий) очень важно, и, провайдер облака (или VMWare и т.д.). Я использую AWS, поэтому я отметил плагины, которые я использую для этого провайдера, однако я подозреваю, что другие основные игроки имеют подобные плагины, я просто не могу поручиться за них, не используя их в гневе. И наконец, утилиты для тех плагинов, которые я использую для интеграции со сторонними инструментами.
Большинство плагинов вам уже знакомы, если нет, то документация обычно хорошо объясняет их использование.
Сущности
- Ansicolor https://plugins.jenkins.io/ansicolor/
- голубой океан https://plugins.jenkins.io/blueocean/
- конфигурация как код https://plugins.jenkins.io/configuration-as-code/
- copyartifact https://plugins.jenkins.io/copyartifact/
- docker-workflow https://plugins.jenkins.io/docker-workflow/
- git https://plugins.jenkins.io/git/
- job-dsl https://plugins.jenkins.io/job-dsl/
- блокируемые ресурсы https://plugins.jenkins.io/lockable-resources/
- маски-пароли https://plugins.jenkins.io/mask-passwords/
- pipeline-model-definition https://plugins.jenkins.io/pipeline-model-definition/
- pipeline-utility-steps https://plugins.jenkins.io/pipeline-utility-steps/
- таймстампер https://plugins.jenkins.io/timestamper/
- ws-cleanup https://plugins.jenkins.io/ws-cleanup/
Безопасность Jenkins (примеры)
- ldap https://plugins.jenkins.io/ldap/
- role-strategy https://plugins.jenkins.io/role-strategy/
- github-oauth https://plugins.jenkins.io/github-oauth/
Облачный провайдер (я использую AWS)
- ec2 https://plugins.jenkins.io/ec2/
- configuration-as-code-secret-ssm https://plugins.jenkins.io/configuration-as-code-secret-ssm/
- pipeline-aws https://plugins.jenkins.io/pipeline-aws/
- aws-parameter-store https://plugins.jenkins.io/aws-parameter-store/
Утилита
- артефакториум https://plugins.jenkins.io/artifactory/
- github https://plugins.jenkins.io/github/
- slack https://plugins.jenkins.io/slack/
Вот и все. Это единственные плагины на моем Jenkins Controller. Все остальное для запуска заданий, создания различных заданий на различных языках (python, lambdas, maven, ansible, kubernetes, packer, terraform и т.д.) делается через Docker контейнеры и общие либы.
Общие рекомендации
- Используйте множество небольших контроллеров Jenkins, а не большие общие контроллеры.
- Потратьте время на автоматизацию перестройки с помощью Jenkins Config as Code и job-dsl для повторной генерации заданий.
- Иметь тестовые Jenkins, которые перестраиваются с последними плагинами и репрезентативным набором тестовых конвейеров
- Храните домашнюю директорию Jenkins на отдельном диске по отношению к остальному контроллеру.
- Запускайте Jenkins в Docker, чтобы сделать обновление очень простым. Это означает использование внешних агентов сборки для запуска сборок без использования проксированных сокетов Docker и ужасных хаков. Я бы сделал это в любом случае, чтобы сохранить контроллер свободным.