1. Обзор
В этом руководстве мы рассмотрим Spinnaker , платформу непрерывной доставки с открытым исходным кодом , созданную Netflix. Мы можем использовать его для развертывания наших приложений в нескольких облачных провайдерах.
Система построена на основе Spring Boot и поддерживает множество облачных провайдеров.
Посмотрим, как это работает и в каких случаях мы можем его использовать.
2. Фон
Давайте взглянем на историю разработки программного обеспечения. Во-первых, у нас был Водопад с нечастыми выпусками.
После этого мы начали работать с Agile и добавляли фичи в каждый спринт. Тем не менее, мы по-прежнему не запускали производство в каждом спринте. К сожалению, пользователи так и не смогли воспользоваться новыми функциями, которые лежали на полке.
Были некоторые причины для нерегулярного развертывания. Одним из них был тот факт, что этапы развертывания часто выполнялись вручную и были подвержены человеческим ошибкам.
Кроме того, некоторые считали, что более частое развертывание означает больший риск потенциальных проблем. В настоящее время мы в основном согласны с тем, что развертывание небольших изменений означает меньший риск крупных ошибок. Тем не менее, если есть ошибка, мы можем быстро найти ее в небольшом изменении и выпустить новую версию, которая решает проблему.
3. Спинакер
С помощью Spinnaker мы можем использовать непрерывную доставку или непрерывное развертывание для автоматического выпуска нашего приложения в производство. Непрерывная поставка означает, что все готово к выпуску в производство.
Однако выпуск утверждается вручную перед развертыванием приложения в рабочей среде. Непрерывное развертывание означает отсутствие ручного вмешательства. Выполняются все шаги, включая развертывание в рабочей среде. Мы просто отправляем код нашего приложения в систему контроля версий и все.
От отправки нашего кода в систему управления версиями до развертывания в рабочей среде мы можем выполнить множество шагов. Мы можем создать наш код, выполнить модульное тестирование кода, развернуть его в тестовой среде и выполнить функциональные тесты. Мы используем так называемый конвейер для настройки всех этих шагов.
С помощью Spinnaker мы можем создать такой конвейер и развернуть наше приложение на большинстве облачных провайдеров.
4. Компоненты
Spinnaker в основном состоит из двух частей: уровня абстракции поверх различных облачных провайдеров и инструмента для непрерывной доставки.
4.1. Традиционные облачные развертывания
Когда мы смотрим на облачных провайдеров, все они предлагают более или менее одинаковые услуги. Эти услуги включают в себя такие вещи, как экземпляры, бессерверная поддержка и поддержка контейнеров.
Однако конфигурация этих услуг сильно различается у разных поставщиков. Это затрудняет переключение между провайдерами. Требуется некоторое время, чтобы перейти к другому облачному провайдеру и узнать все подробности, а это означает, что у нас в основном есть привязка поставщика к нашему облачному провайдеру.
Netflix хотел иметь возможность легко переключаться между облачными провайдерами, а не зависеть только от одного. Вот почему они построили уровень абстракции поверх облачных провайдеров.
4.2. Уровень абстракции
Когда мы используем Spinnaker, он одинаков для всех облачных провайдеров. Мы можем использовать его в Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine или Kubernetes. Это позволяет нам перейти к другому поставщику облачных услуг, если цены будут более конкурентоспособными.
Более того, мы можем выбрать развертывание у нескольких поставщиков одновременно. Таким образом, мы можем запустить наше приложение на двух или более провайдерах для дополнительной избыточности.
Еще одно преимущество уровня абстракции заключается в том, что он фокусируется на приложениях, а не на ресурсах. Обычно облачные провайдеры показывают нам ресурсы, которые мы используем в данный момент. Однако мы должны сами выяснить, какое приложение использует какие ресурсы.
Но ресурсы нас не интересуют. Мы хотим запустить наше приложение, не тратя время на отслеживание ресурсов. Spinnaker ориентирован на приложения. Итак, когда мы смотрим на него, мы сначала видим приложение, а затем видим ресурсы, используемые приложением.
4.3. Непрерывная доставка
Поверх уровня абстракции Netflix построил платформу непрерывной доставки. Эта платформа позволяет нам развернуть наше приложение на одном или нескольких облачных провайдерах. Он немного похож на Jenkins, но предлагает лучшую интеграцию с облачными провайдерами и требует меньше настроек.
Например, мы можем запустить конвейер непрерывной доставки из Jenkins, загруженного образа Docker или git push. После этого мы можем просто создать образ или контейнер с нашим приложением и запустить его в продакшн.
Однако доступно гораздо больше вариантов, таких как автоматические тесты и ручное утверждение перед развертыванием в рабочей среде.
Мы даже можем решить, какой стратегии мы хотим придерживаться при развертывании новой версии существующего приложения. Таким образом, можно просто заменить старую версию новой версией. Тем не менее, лучшей стратегией было бы сначала запускать их бок о бок. Таким образом, мы можем автоматически или вручную проверить, работает ли новая версия, и если да, то удалить старую версию.
5. Облачная модель Netflix
Каждое приложение состоит из одной или нескольких групп серверов. Одна и та же версия приложения работает на всех экземплярах в группе серверов. Используется следующее соглашение об именах: <имя-приложения>-<(необязательный) стек>-<(необязательный элемент)>-<номер-версии>. Поле стека (необязательное) используется для указания того, предназначена ли группа серверов для тестирования, производства или других целей. Необязательное поле сведений используется для дополнительной информации.
Наконец, у нас есть концепция кластера, который содержит одну или несколько групп серверов с одинаковыми именами, стеком и деталями. Однако большую часть времени каждая группа серверов в кластере работает с разными версиями приложения. Неудачные экземпляры будут заменены новым экземпляром.
Также можно автоматически добавлять экземпляры в группу серверов, чтобы справиться с возросшей нагрузкой.
6. Стратегия развертывания
Когда мы развертываем новую версию приложения, обычно выбирается стратегия «красное/черное». Сначала в кластере развертывается новая группа серверов, содержащая новую версию приложения. После развертывания приложения выполняется проверка работоспособности новой группы серверов.
Теперь группа серверов включена и доступна для наших клиентов. Наконец, старая группа серверов отключена.
В этом сценарии легко выполнить откат, если что-то пойдет не так с новым сервером приложений. Мы можем просто снова включить группу серверов со старой версией и сделать ее доступной для наших клиентов.
7. Почему спинакер
С помощью Spinnaker мы можем сосредоточиться на нашем приложении, а не на облачных ресурсах, которые мы используем. Это упрощает развертывание и обслуживание наших приложений.
Кроме того, Spinnaker позволяет работать с несколькими облачными провайдерами одновременно. Более того, мы можем легко переключиться на других облачных провайдеров в зависимости от их ценовой стратегии и доступных функций.
8. Заключение
Spinnaker опирается на опыт Netflix. Мы можем использовать их знания и работать таким же образом с минимальными усилиями. На основе этих инструментов мы можем легко реализовать конвейер развертывания для развертывания наших приложений в рабочей среде.
Чтобы узнать больше о Spinnaker, загрузите бесплатную электронную книгу Continuous Delivery with Spinnaker .