8 причин, по которым вам следует перейти с Jenkins

В мире DevOps мы продолжаем видеть новые и улучшенные программные решения для автоматизации развертывания кода/программного обеспечения. Независимо от того, являетесь ли вы разработчиком или операционным инженером, в этом облачном нативном мире нет места для использования посредственных инструментов. Каждый день появляются инновации, обновленные версии старых инструментов и более доступные сервисы, которые облегчают нашу жизнь как кодеров и операционных специалистов. Сегодня DevOps стал центральным элементом, а каждая компания стала называться софтверной. Непрерывная интеграция становится первым шагом к принятию DevOps как методологии.

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

Необходимость в настоящем инструменте непрерывной интеграции

Все мы знаем, что облачные инструменты развиваются каждый день, и мы видим множество инструментов-заменителей для выполнения одной и той же работы. Для выполнения непрерывной интеграции на рынке существует множество инструментов, но трудно найти тот, который действительно понимает разработчиков и создан для них. Хотя Jenkins может быть хорошей отправной точкой для новичков и организаций, он становится сложным, когда количество развертываний увеличивается. Хотя скорость может быть еще одним фактором для оценки инструмента непрерывной интеграции, он также должен быть прост в настройке на вашем компьютере с минимальными командами. Drone CI обладает всем необходимым, чтобы стать единственным в своем роде инструментом CI, помогающим разработчикам создавать и тестировать свои приложения посредством непрерывной интеграции. Вы можете установить его на свою локальную машину за считанные минуты и начать выполнять непрерывную интеграцию. Drone CI построен на базе Docker & использует возможности контейнеров на каждом этапе.

Далее рассмотрим, чем Drone лучше Jenkins для непрерывной интеграции.

Jenkins

Jenkins — это инструмент непрерывной интеграции с открытым исходным кодом. Он используется для сборки и тестирования программного обеспечения либо на локальной машине разработчика, либо в среде непрерывной интеграции, например, в публичном облаке. С помощью Jenkins вы можете автоматизировать конвейер доставки программного обеспечения от фиксации кода до производства. Jenkins в основном используется для автоматизации сборки и развертывания. Обычно он сочетается с другими инструментами в цепочке DevOps, такими как управление исходным кодом, отслеживание проблем и управление проектами. В дополнение к этим инструментам Jenkins используется для автоматизированного тестирования и развертывания приложений. Возможности Jenkins включают управление различными заданиями, просмотр сводных графиков и получение уведомлений по электронной почте.

Drone CI

Drone CI — это сервер непрерывной интеграции с открытым исходным кодом, приобретенный компанией Harness. Он используется для сборки и тестирования программного обеспечения либо на локальной машине разработчика, либо в среде непрерывной интеграции, например, в публичном облаке. С помощью Drone вы можете автоматизировать конвейер доставки программного обеспечения от фиксации кода до производства. Помимо создания программного обеспечения, Drone позволяет создавать, тестировать и развертывать приложения. Drone CI считается современным инструментом непрерывной интеграции, поскольку использует декларативный подход в виде yaml-файлов для автоматизации тестов и широко применяет контейнеры Docker на каждом этапе. Конвейеры сборки занимают меньше времени, их легко настраивать и запускать.

Drone CI — это инструмент декларативной непрерывной интеграции на основе контейнеров, который широко использует контейнеры Docker на каждом этапе и может легко работать на ваших ноутбуках, в частном центре обработки данных или в публичном облаке. Такой декларативный характер непрерывной интеграции помогает организациям внедрять Gitops.

Вот простой конфигурационный yaml-файл,

kind: pipeline
type: kubernetes
name: default
steps:
- name: test
  image: node
  commands:
  - npm install
  - npm test

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

• Сборка
• Единичное тестирование
• Развертывание в dev
• Интеграционный тест

Конфигурация yaml может быть легко задана следующим образом,

kind: pipeline
name: default
steps:
- name: build
  image: node:8.6.0
  commands:
  - npm install
  - npm run build
  when:
   event:
     - push
- name: unit_test
  image: node:8.6.0
  commands:
  - npm run unit_test
  when:
   event:
     - push
- name: intergration_test
  image: node:8.6.0
  commands:
  - npm run integration_test
- name: deploy_dev
  image: node:8.6.0
  commands:
  - npm run deploy -- --env=dev
  when:
   event:
     - push
  branch:
    - master

Причины, по которым Jenkins не подходит для современного мира Cloud Native,

• Jenkins используется не только для выполнения CI, и именно здесь начинаются проблемы, поскольку экземпляры Jenkins становятся более сложными и создают узкое место. Есть больше преимуществ в том, чтобы делать CI и CD отдельно. Пользователи Jenkins используют его для выполнения CD с помощью пользовательских скриптов, что не является правильным способом реализации DevOps.

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

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

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

• Я серьезно, Jenkins не был разработан с учетом будущих инноваций. Jenkins был создан за несколько лет до появления Docker, поэтому Jenkins никогда не был контейнерно-нативным CI-инструментом.

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

Докер-образ Jenkins занимает ~270 МБ, в то время как докер-образ Drone — ~22 МБ.

Также ознакомьтесь с твитом Джима по этому поводу,

• Jenkins требует крутого обучения, а для сложной настройки CI/CD необходимо изучать Groovy. Groovy — это одно, а Jenkins DSL — другое, и поэтому становится сложно и хаотично для тех, кто пытается настроить его в первый раз.

• Некоторые пользователи сообщали, что запуск сборок с помощью Jenkins CLI зависает, а это не очень хороший знак для инструмента DevOps. В то время как Drone CLI работает быстро, и вы можете запускать сборки локально с помощью простой команды drone exec. Drone также имеет «режим отладки», который может быть включен, что позволяет пользователям интерактивно отлаживать неудачные конвейеры, но есть ли такая возможность у Jenkins? Я сомневаюсь в этом.

Почему вы должны перейти с Jenkins на Drone?

Без сомнения, Jenkins имеет преимущество в области непрерывной интеграции, и он стал популярным благодаря широкому распространению плагинов. Для небольшой команды с базовым использованием Jenkins подходит, но по мере роста вашей команды он становится сложным. Ему не хватает современных «облачных» возможностей. Конфигурация плагинов кажется кошмаром, и в какой-то момент становится трудно поддерживать и масштабировать его, а также поддерживать время безотказной работы. Кроме того, Jenkins известен своей дороговизной в обслуживании. Видимость конвейеров очень плохая при использовании Jenkins, и это превращает отладку в настоящее мучение. Изначально, когда вы настраиваете его, он работает как шарм, но стоит изменить какую-то простую вещь, и он начинает ломаться.

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

Есть много причин рассмотреть возможность перехода с Jenkins на Drone. Вот основные из них, которые мы рассматриваем:

• Простота:

  Drone намного проще, чем Jenkins. Если вам нужно что-то более продвинутое, то у Jenkins больше возможностей. Однако если вы просто хотите быстро приступить к работе и ничего не настраивать, то Drone — лучший выбор.

• Скорость:

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

• Простота использования:

  Drone проще Jenkins по двум параметрам. Во-первых, пользовательский интерфейс намного проще. Во-вторых, процесс установки намного проще.

• Современный подход:

  Jenkins все еще использует старые методологии и выполняет команды напрямую при запуске заданий, а не использует современные подходы, такие как контейнеры.

• Написан на языке Go:

  Go становится подходящим языком из-за его возможностей для облачного нативного пространства, и Drone написан на Go, в то время как Jenkins написан на Java.

• Простые тесты:

  Вам больше не нужно использовать Groovy для создания тестов, как в Jenkins. Все происходит в декларативной форме, а тесты задаются в файле .drone.yaml.

• Просто декларативность:

  В Drone все настраивается с помощью простых YAML-файлов, и это очень легко настроить, даже новичок сможет понять и настроить. Как мы уже говорили, декларативный характер Drone помогает организациям легко внедрять Gitops.

• Полностью контейнерная и облачная основа:

  Каждый шаг представляет собой полностью изолированный Docker-контейнер, так что разработчики могут быстро узнать, какой образ был использован на каждом этапе. Это помогает в отладке, если что-то пойдет не так на любом этапе конвейера. Каждый этап легко воспроизвести на локальной машине.

Кроме того, поскольку GitOps — это более современный подход к развертыванию Kubernetes, сочетание Drone и Argo CD работает удивительно хорошо. Например, вы можете использовать Drone для создания образов, а затем зафиксировать изменение в конфигурации приложения в git, которое Argo распознает и развернет это изменение. Если вам нравится более индивидуальный подход, вы можете использовать Harness GitOps, который хорошо интегрирован с Drone.

Заключение

Не существует универсального решения, когда речь идет об инструментах CI/CD. У разных организаций будут разные потребности. Аналогично, разные организации будут отдавать предпочтение разным функциям. Поэтому при выборе подходящего CI/CD-инструмента для вашей организации очень важно оценить свои потребности и найти продукт, который наилучшим образом им соответствует.

Кроме того, важно учитывать, какие функции необходимы вашей организации, а какие просто приятно иметь. Сегодня каждая организация стремится внедрить DevOps и использовать современные облачные нативные технологии для быстрого развертывания программного обеспечения. Следовательно, становится жизненно важным помнить о выборе платформы/инструмента, который является облачно-нативным и обладает современными возможностями. Учитывая это, если вы в настоящее время используете Jenkins и ищете альтернативу, подумайте о переходе на Drone.

Кроме того, Drone имеет множество замечательных плагинов, которые вы можете использовать для расширения возможностей ваших CI-конвейеров.

Так зачем ждать? Запустите свой собственный Drone CI на своем ноутбуке.

Запустите свой собственный Drone CI

Джим Шелдон ・ Apr 2 ・ 5 min read

#droneci #cicd #devops #docker

Дополнительная литература и тематические исследования по Drone:

• https://levelup.gitconnected.com/moving-ci-from-jenkins-to-drone-deaf7b773583
• https://dizzy.zone/2019/04/16/Moving-from-Jenkins-to-Drone/
• https://webhookrelay.com/blog/2019/02/11/using-drone-for-simple-selfhosted-ci-cd/
• https://blog.kronis.dev/tutorials/moving-from-gitlab-ci-to-drone-ci