Расширение непрерывной доставки с помощью Kubernetes и Spinnaker

Дискуссия вокруг контейнеров закончилась тем, какие основные компоненты являются лучшими способами управления этими компонентами. За почти пять лет существования контейнеров было установлено, что спецификация контейнеров Docker станет стандартом для среды выполнения контейнеров, а Kubernetes станет предпочтительным оркестратором контейнеров для большинства организаций. Хотя это большой прогресс, остаются другие вопросы, касающиеся таких аспектов, как сеть контейнеров, безопасность и сквозное управление. Когда дело доходит до развертывания, новичок в блоке — это не Kubernetes, а ориентированный на Kubernetes инструмент развертывания под названием Spinnaker.

Подготовка сцены — Дженкинс

Дженкинс стал популярным почти десять лет назад, когда началось движение DevOps. В центре внимания этого движения была непрерывная интеграция. Действительно, CI был лучшим способом начать работу с DevOps, если вы пришли к модели водопада доставки программного обеспечения. CI сосредоточился на автоматизации начальных этапов конвейера разработки. Это могло бы автоматизировать сборку, тем самым сокращая работу разработчиков, когда они вносят свой код. Это значительно сэкономило время для больших команд и помогло унифицировать операции команды. Дженкинс дополнительно управлял автоматизацией тестирования за счет интеграции с другими средами тестирования с открытым исходным кодом, такими как Selenium.

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

Взгляд на автоматизированное развертывание — Chef и Puppet

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

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

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

Эти инструменты значительно помогли повысить эффективность на протяжении всего жизненного цикла разработки. Дженкинс оптимизировал ранние этапы разработки, в то время как Chef и Puppet управляли экземплярами, поддерживающими различные среды. Jenkins упростил жизнь разработчикам и тестировщикам, а инструменты управления конфигурацией упростили работу операционных групп. Чего не хватало, так это инструмента, который мог бы объединить оба этих подхода для лучшего управления развертыванием.

Хотя такие инструменты, как Jenkins, Chef и Puppet, кое-что упростили, с течением времени ими также стало трудно управлять. Многочисленные подчиненные узлы Jenkins требовательны к ресурсам. Хотя существует множество плагинов Jenkins, управление этими плагинами было не менее сложным. Инструменты управления конфигурацией и их сборники сценариев, кулинарные книги и манифесты были столь же сложными. Кроме того, эти инструменты были созданы в эпоху виртуальных машин и не были естественными при масштабировании до работы на скорости контейнера. Огромный объем и скорость изменений контейнеров могут привести к тому, что эти системы управления конфигурациями будут работать до предела.

Введите Kubernetes

Затем появился Kubernetes, и он сразу же превзошел инструменты управления конфигурацией из-за того, насколько он был ориентирован на контейнеры. Вместо того, чтобы настраивать отдельные экземпляры, Kubernetes сгруппировал несколько экземпляров контейнеров в группы модулей. Затем он управляет этими модулями на более высоком уровне абстракции, чем инструменты управления конфигурацией.

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

Важно отметить, что Kubernetes — это широкомасштабная архитектура с поддержкой подключаемых модулей для работы в сети. В последнее время в сетевом пространстве Kubernetes было много активности с такими надежными инструментами, как Istio, Linkerd, Weave и Flannel, открывающими эру «сервисной сетки». Это идеальный тип сети для контейнеров, в которых службы взаимодействуют по принципу «многие ко многим». Это обеспечивает лучшее управление балансировкой нагрузки, обнаружением сервисов и мониторингом микросервисов.

Последняя миля: развертывание с помощью Spinnaker

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

Созданный в Netflix, Spinnaker родился из инструмента с открытым исходным кодом Asgard, который Netflix разработал для лучшего управления своими ресурсами AWS. Затем Google сотрудничал с Netflix, чтобы вывести Asgard за пределы AWS, чтобы он мог управлять ресурсами и на других облачных платформах. Конечным результатом стал Spinnaker.

Spinnaker находится на пересечении различных инструментов в жизненном цикле контейнера. Он хорошо интегрируется с репозиториями Git, Jenkins и другими инструментами CI, инструментами управления конфигурацией, такими как Chef и Puppet, и инструментами мониторинга, такими как Prometheus. Он не стремится заменить инструменты CI, а скорее использует сильные стороны инструментов CI на начальных этапах разработки, в то время как сам фокусируется на оптимизации последней мили.

Как работает спинакер

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

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

К чему все это приводит? Зрелая культура развертывания. От нечастых крупных выпусков вы, наконец, можете перейти к быстрым, непрерывным обновлениям, характерным для методологий Agile и DevOps. Spinnaker позволяет выполнять последовательные обновления, канареечные выпуски и простой откат, когда выпуски идут не так, как планировалось.

Самое приятное то, что Spinnaker может выполнять развертывание на различных облачных платформах — AWS, Azure, Google Cloud, OpenShift, DC/OS, Oracle и других. Это дает полную свободу от привязки к поставщику и позволяет серьезно подумать о том, как лучше оптимизировать операции и сократить расходы. Первоначальное обещание Kubernetes заключалось не только в улучшении управления контейнерами, но и в нейтральности поставщиков. Spinnaker делает это обещание реальностью.

Улучшенная стратегия развертывания

То, что началось с движения DevOps и таких инструментов, как Jenkins и Chef, достигло совершеннолетия с Docker и Kubernetes. Кульминацией этого прогресса стал такой инструмент, как Spinnaker, который не пытается заново изобретать колесо, а основывается на предыдущих достижениях, чтобы обеспечить гораздо более совершенную стратегию развертывания. Это самая большая победа, и это то, к чему в первую очередь стремились пользователи контейнеров.