Сравните Spinnaker с Jenkins 2.0 в качестве инструмента непрерывной доставки

Я активно работаю над интеграцией Jenkins в Spinnaker и функциональностью Pipelines в Netflix.

Spinnaker никогда не задумывался как комплексный инструмент сборки. Есть вещи, которые Дженкинс будет делать лучше с точки зрения управления SCM, запуска тестов, создания пакетов, наличия огромного количества плагинов и т. д., и т. д., и т. д.

То, что Spinnaker пытается сделать хорошо, — это взять часть программного обеспечения, которое вы опубликовали (будь то пакет Debian, образ докера или развертываемый JAR), и запустить его через предсказуемый цикл развертывания программного обеспечения, который легко настраивается. Другими словами, каждая функция в Spinnaker создана для того, чтобы упростить высокодоступное развертывание артефактов с несколькими учетными записями и несколькими облаками.

Конвейеры Spinnaker ориентированы на облако. Большинство этапов конвейера и элементов управления API связаны с созданием новых групп серверов и изменением существующих групп серверов предсказуемым и удобным для пользователя способом. Если есть сомнения, оптимизируем именно для этого случая.

У нас более твердое мнение о том, как выглядит облачное развертывание, и у нас часто будет пользовательский интерфейс «укажи и щелкни» при работе с задачами облачного развертывания в наших конвейерах компакт-дисков — найти образ в кластере x, отключить этот кластер, изменить размер группы серверов. , уменьшить этот кластер, заставить этот кластер принимать трафик, уничтожить этот старый кластер и т. д.

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

В Netflix есть команды, которые не используют функциональность конвейера Spinnaker, а вместо этого используют API Spinnaker в своих заданиях Jenkins в качестве ярлыка для развертывания в AWS. Если вы используете конвейеры Jenkins или аналогичные инструменты CD, Spinnaker делает этап развертывания действительно гибким.

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

Конвейеры Дженкинса довольно аккуратны. Я не думаю, что Spinnaker когда-либо полностью заменит Jenkins и миллион вещей, которые он делает. Наша цель — сделать шаг «развертывание в облаке» более простым и расширяемым. Выбор использовать один над другим, вместе или не использовать вообще, зависит от вас.

Есть несколько причин, по которым вы можете выбрать Spinnaker вместо Jenkins (2.0) Pipeline в качестве инструмента компакт-диска:

1. Spinnaker включает в себя веб-интерфейс, который может фактически предоставлять ресурсы и делать это в нескольких облачных средах. Таким образом, для создания базовых ресурсов, таких как виртуальные машины, балансировщики нагрузки, кластеры и т. д., вы можете сделать это из того же пользовательского интерфейса, что и средство доставки.
2. Если ваша архитектура похожа на архитектуру Netflix, Netflix использует ее в качестве всей своей облачной платформы управления, поэтому практически нет необходимости в разрозненных инструментах для поддержки доставки и управления инфраструктурой.

С другой стороны, есть много причин выбрать Jenkins Pipeline вместо Spinnaker.

1. Spinnaker по-прежнему требует инструмента сборки, поэтому вам все равно может понадобиться поддерживать Jenkins. Так что, если Jenkins Pipeline станет вашим CD-инструментом, он уже может изначально выполнять задачи, специфичные для вашего исполнителя.
2. Spinnaker не имеет детальных элементов управления доступом (и только недавно была добавлена ​​проверка подлинности любого рода), тогда как Jenkins имеет множество плагинов и собственных конфигураций в Pipeline, обеспечивающих контроль доступа на уровне ресурсов.
3. Все управляется одним заводным сценарием, так что это настоящая конфигурация как код. Это позволяет использовать простой поток/логику/управление, которое невозможно (или, по крайней мере, просто) в других инструментах CD.
4. Поддержка нескольких веток, легкое создание/удаление/изменение веток
5. Уже есть обширная поддержка подключаемых модулей для Jenkins. Например, мы используем плагин AWS ECS, чтобы разрешить динамический докер. узлы для наших трубопроводов.
6. Легко делитесь/совместно работайте над кодом для конвейеров. У вас обязательно будут многократно используемые функции, которые вы захотите использовать в нескольких конвейерах. Jenkins упрощает это с помощью таких инструментов, как плагин удаленного загрузчика< /а>
7. Большая поддержка сообщества

Мы используем Maven для упаковки всей кодовой базы вместе с конфигами, свойствами (то есть всем, что имеет версию в GitHub) и создаем из этого RPM. На этом поток заканчивается — мы запускаем конвейеры Spinnaker в AWS или любом другом облаке, чтобы инициировать часть CD.

Spinnaker очень уникален с этим прицелом CD.

1. Продвижение кода: тот же RPM, который мы будем продвигать, гарантирует, что мы делаем наш базовый код / ​​env неизменяемым.

2. Мы можем управлять изменением размера экземпляров из самой консоли Spinnaker.

3. Откат — всего один клик.

4. Все современные концепции развертывания, такие как сине-зеленый / красно-черный, канарейка, горец и т. Д., Здесь являются OOB.

5. Журналы конвейера дают очень информативное представление как на высоком, так и на низком уровне.

6. Развертывание в нескольких регионах (стратегическое аварийное восстановление)

если кому-то нужна помощь (бесплатная помощь!) по установке Spinnaker в RHEL, вы можете сообщить мне.

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