Введение в Spinnaker
1. обзор
В этом руководстве мы рассмотримSpinnaker, платформуcontinuous delivery с открытым исходным кодом, созданную Netflix. Мы можем использовать его для развертывания наших приложений у нескольких облачных провайдеров.
Система построена на базеSpring Boot и поддерживает многих облачных провайдеров.
Посмотрим, как это работает и в каких случаях мы можем его использовать.
2. Фон
Давайте посмотрим на историю разработки программного обеспечения. Во-первых, у нас был Водопад с нечастыми релизами.
После этого мы начали работать над Agile и поставляли функции каждый спринт. However, we still didn’t deploy to production every sprint. К сожалению, пользователи все еще не могли использовать новые функции, которые лежали на полке.
Были некоторые причины, по которым не следует регулярно развертывать. Одним из них было то, что шаги развертывания часто выполнялись вручную и были подвержены человеческим ошибкам.
Кроме того, некоторые люди думали, что развертывание чаще означает больший риск потенциальных проблем. Nowadays, we mostly agree that deploying small changes means less risk for big mistakes. Даже в этом случае, если есть ошибка, мы можем быстро найти ее в небольшом изменении и выпустить новую версию, которая решает проблему.
3. Спинакер
With Spinnaker, we can use continuous delivery or continuous deployment to release our application on production automatically. Непрерывная доставка означает, что все подготовлено к выпуску в производство.
Однако выпуск утверждается вручную перед развертыванием приложения в рабочей среде. Непрерывное развертывание означает, что нет ручного вмешательства. All steps are executed, including the deployment to production. Мы просто отправляем код нашего приложения в систему контроля версий, и все.
От продвижения нашего кода до контроля версий до развертывания в производство мы можем выполнить множество шагов. Мы можем создать наш код, выполнить модульное тестирование кода, развернуть его в тестовой среде и выполнить функциональные тесты. Мы используем так называемый конвейер для настройки всех этих шагов.
С помощью Spinnaker мы можем создать такой конвейер и развернуть наше приложение на большинстве облачных провайдеров.
4. Составные части
Spinnaker в основном состоит из двух частей: уровня абстракции поверх различных облачных провайдеров и инструмента для непрерывной доставки.
4.1. Традиционные облачные развертывания
Когда мы смотрим на облачных провайдеров, все они предлагают более или менее одинаковые услуги. Эти сервисы включают в себя такие вещи, как экземпляры, сервер и поддержка контейнеров.
Однако конфигурация этих сервисов сильно различается у разных поставщиков. Это затрудняет переключение между провайдерами. Требуется некоторое время, чтобы перейти к другому облачному провайдеру и изучить все детали, что означает, что мы в основном имеем привязку поставщика к нашему облачному провайдеру.
Netflix хотел иметь возможность легко переключаться между облачными провайдерами, а не зависеть только от одного. Вот почему они построили уровень абстракции поверх облачных провайдеров.
4.2. Слой абстракции
When we use Spinnaker, it’s the same on all cloud providers. Мы можем использовать его в Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine или Kubernetes. Это позволяет нам перейти к другому облачному провайдеру, если цены будут более конкурентоспособными.
Even more, we can choose to deploy to multiple providers at the same time. Таким образом, мы сможем запускать наше приложение на двух или более провайдерах для дополнительной избыточности.
Another benefit of the abstraction layer is that it focuses on the applications instead of the resources. Обычно облачные провайдеры показывают нам ресурсы, которые мы используем в настоящее время. Однако мы должны сами выяснить, какое приложение использует какие ресурсы.
Но ресурсы нам неинтересны. Мы хотим запустить наше приложение, не тратя время на отслеживание ресурсов. Spinnaker имеет ориентированное на приложение представление. Итак, когда мы смотрим на это, мы сначала видим приложение, а затем мы видим ресурсы, используемые приложением.
4.3. Непрерывная доставка
On top of the abstraction layer, Netflix built a continuous delivery platform. Эта платформа позволяет нам развернуть наше приложение на одном или нескольких облачных провайдерах. Это немного похоже на Jenkins, но предлагает более приятную интеграцию с облачными провайдерами и требует меньше настроек.
Мы можем запустить конвейер непрерывной доставки, например, из Jenkins, загруженного образа Docker или git push. После этого мы можем просто создать изображение или контейнер с нашим приложением и запустить его в производство.
Тем не менее, есть еще много доступных вариантов, таких как автоматические тесты и ручные утверждения перед развертыванием на производстве.
Мы даже можем решить, какой стратегии мы хотим следовать при развертывании новой версии существующего приложения. Таким образом, можно просто заменить старую версию новой. Тем не менее, лучшей стратегией было бы сначала запустить их рядом. Таким образом, мы можем автоматически или вручную проверить, работает ли новая версия, и, если это так, удалить старую версию.
5. Облачная модель Netflix
Every application consists of one or more server groups. Одна и та же версия приложения работает на всех экземплярах в группе серверов. Используется следующее соглашение об именах: <имя-приложения> - <(необязательно) стек> - <(необязательно)> - <номер-версии>. Поле (необязательно) стека используется для указания того, предназначена ли группа серверов для тестирования, производства или других целей. Дополнительное поле сведений используется для дополнительной информации.
Finally, we have the concept of a cluster that contains one or more server groups with the same name, stack, and detail. Однако большую часть времени каждая группа серверов в кластере запускает другую версию приложения. Неудачные экземпляры будут заменены новыми.
Также возможно автоматическое добавление экземпляров в группу серверов, чтобы приспособиться к возросшей нагрузке.
6. Стратегия развертывания
When we deploy a new version of an application, the ‘red/black' strategy is normally chosen. Сначала в кластере развертывается новая группа серверов, содержащая новую версию приложения. После развертывания приложения выполняется проверка для проверки работоспособности новой группы серверов.
Теперь группа серверов включена и доступна для наших клиентов. Наконец, старая группа серверов отключена.
In this scenario, it’s easy to roll back if something goes wrong with the new application server. Мы можем просто снова включить группу серверов со старой версией и сделать ее доступной для наших клиентов.
7. Почему Спинакер
With Spinnaker, we can focus on our application instead of the cloud resources that we use. Это упрощает развертывание и поддержку наших приложений.
Кроме того, Spinnaker позволяет запускать несколько облачных провайдеров одновременно. Более того, мы можем легко переключаться на других облачных провайдеров в зависимости от их ценовой стратегии и доступных функций.
8. Заключение
Spinnaker builds on the experience of Netflix. Мы можем использовать их знания и работать таким же образом с минимальными усилиями. На основе этих инструментов мы можем легко реализовать конвейер развертывания для развертывания наших приложений в рабочей среде.
Чтобы узнать больше о Spinnaker, загрузите бесплатную электронную книгуContinuous Delivery with Spinnaker.