В этой статье представлен обзор и выводы о том, почему миграция с собственного хостинга CI/CD на SaaS CI/CD — это правильный путь!
Давайте сначала разберемся в истории.
Инженеры-программисты из поколения X, поколения Millennials наверняка хотя бы раз в жизни работали с Jenkins (в те времена это был Hudson). Java Stack CI/CD развивался вокруг Jenkins. Большинство из нас хотя бы раз использовали Jenkins. И Artifactory позже Nexus прекрасно дополняют друг друга.
Как может выглядеть наша установка Jenkins и Nexus на собственном хостинге.
Jenkins в основном используется для CI/CD и в некоторых случаях как пакетный процессор. Для удовлетворения этого требования правильным выбором будут саморазмещающиеся экземпляры Jenkins, работающие на AWS или саморазмещающиеся pods на Kubernetes(K8S), в основном в конфигурации MASTER -> SLAVE (агенты).
Экземпляр Nexus также может быть размещен на AWS или в K8S.
Некоторые из многих проблем с этой конфигурацией и некоторые решения для устранения некоторых из них.
Проблема 1. Безопасность
- Решение 1: Первый подход к обеспечению безопасности — использование VPN. Конечно, это обеспечивает безопасность за счет производительности и накладных расходов на поддержание экземпляра VPN.
- Решение 2: Для преодоления проблем с Open VPN можно использовать сертификаты на стороне клиента. Эта настройка включает в себя написание небольшого кода, который создаст сертификат и отправит информацию в репозиторий сертификатов. Но поддержание сертификата является довольно мучительной задачей.
Проблема 2. Случайные перезапуски Jenkins, автоматические обновления
- Решение: Отключение функции автоматического обновления.
Проблема 3. Устаревшие плагины
- Решение: Сообщество Jenkins в наши дни не растет, как другие сообщества, поэтому некоторые плагины не поддерживаются и не работают с новыми версиями Jenkins. Поэтому имеет смысл придерживаться устаревших плагинов.
Проблема 4. Конвейерные сборки
- Снова поддержка и написание
Jenkinsfileбез особой документации — это довольно сложно.
Проблема 5. Обслуживание Nexus — это кошмар
- Команда DevOps должна быть начеку, чтобы исправлять и чинить экземпляр Nexus, поскольку хранение данных часто может быть проблемой. Поэтому хранилище приходится поддерживать вручную. Кроме того, удаление старых артефактов — это еще одна проблема, которую нужно решать.
И последнее, но не менее важное: Jenkins может подвести в самый нужный момент. Поскольку большинство команд полагаются на Jenkins для CI/CD, эти проблемы могут расти в геометрической прогрессии, а их обслуживание отнимает у DevOps драгоценное время.
Чтобы облегчить всем жизнь, решением может стать переход на GitHub Actions и GitHub Packages!
Как может выглядеть CI/CD с помощью GitHub Action.
Преимуществом перехода на GitHub Action является использование YAML вместо различных способов определения задания в Jenkins. Эти файлы YAML хранятся в папке .github в соответствующем проекте, что дает право собственности на потоки владельцу проекта/модуля. Ниже приведены некоторые примеры рабочих процессов, которые можно определить.
Некоторые выводы после перехода на GitHub Actions and Packages.
- Стабильный CI /CD — это не миф!
- Теперь проект CI/CD поддерживается соответствующей командой, а не командой DevOps.
- Сэкономлено много времени разработчиков на устранение проблем с Jenkins и Nexus.
- Экономия ресурсов, так как вместо собственного хостинга используется экземпляр GitHub.
- Экономия средств, поскольку самая базовая подписка на GitHub предоставляет доступ к Actions и Packages.
- Стабильность и эффективность по сравнению с Jenkins и Nexus.
- Большой рынок.
- Большое сообщество разработчиков, все больше и больше бесплатных действий (например, Slack Notification и т.д.).
- Очень короткое время миграции.
Заключение
Миграция на GitHub Actions and Packages может спасти от многих разочарований, связанных с комбинацией Jenkins-Nexus. Это даст вам возможность попробовать новейшие инструменты, а не использовать старые и устаревшие технологии. Этот процесс может быть не идеальным для всех, но он решает большинство проблем с Jenkins.
Как я уже говорил, стабильный CI/CD — это не миф!
Ссылки
- Переход с Jenkins на GitHub Actions
- Введение в GitHub Actions
- Github Actions или Jenkins? Правильный выбор для вас
- Уведомление из Slack
- Торговая площадка GitHub
- Фото Aleksejs Bergmanis с сайта Pexels