DevOPS заметки
Облачная ориентированность
Облачно-ориентированные приложения работают в облаке, с этим никто не спорит. Но если мы возьмем существующее приложение и просто запустим его на облачном вычислительном сервере, от этого оно не станет облачно-ориентированным. То же самое можно сказать о запуске в контейнере или использовании таких облачных сервисов, как Cosmos DB от Azure или Pub/Sub от Google. Хотя это можно назвать важными аспектами облачной ориентированности.
Рассмотрим несколько характеристик облачно-ориентированных систем, с которыми может согласиться большинство людей.
Автоматизируемость
Если приложения должны развертываться и управ- ляться компьютерами, а не людьми, им следует использовать общепринятые стандарты, форматы и интерфейсы. Kubernetes предоставляет эти стандартные интерфейсы таким образом, что разработчики приложений могут о них не бес- покоиться.
Универсальность и гибкость
Поскольку контейнеризированные микросервисы отвязаны от физических ресурсов, таких как диски, и не имеют никакой конкретной информации о вычислительных узлах, на которых они работают, их можно легко переносить с узла на узел или даже между кластерами.
Устойчивость и масштабируемость
У традиционных приложений обычно есть единая точка отказа: программа перестает работать в случаях сбоя в главном процессе, неполадок в оборудовании компьютера или перегруженности сети. Облачно-ориентированные приложения являются распределенными по своей природе, поэтому их можно сделать высокодоступными с помощью избыточности и плавной деградации.
Динамичность
Система оркестрации, такая как Kubernetes, может планировать контейнеры для максимально эффективного использования доступных ресурсов. Она может запускать множество копий контейнера, чтобы достичь высокой доступности, и выполнять плавающие обновления, чтобы плавно переходить на новые версии сервисов, не теряя трафика.
Наблюдаемость
Облачно-ориентированные приложения по своей природе труднее поддаются исследованию и отладке. Поэтому наблюдаемость является ключевым требованием к распределенным системам: мониторинг, ведение журнала, трассирование и сбор показателей помогают инженерам понять, чем занимаются их системы (и что они делают не так).
Распределенность
Облачная ориентированность — это подход к построению и выполнению приложений, основанный на использовании преимущества от распределенной и децентрализованной природы облаков. Он определяет то, как ваше приложение работает, а не то, где оно запущено. Вместо развертывания кода в виде единой сущности, известной как монолит, облачно-ориентированные приложения обычно состоят из нескольких распределенных микросервисов, которые взаимодействуют между собой. Микросервис — это просто самодостаточный сервис, делающий что-то одно. Если соединить необходимое количество микросервисов, получится приложение.
Принципы
До появления DevOps разработка и системное администрирование ПО представляли собой, в сущности, два отдельных направления, и занимались ими две разные группы людей. Разработчики (developers) писали код и передавали его коллегам-администраторам (operations), которые занимались запуском и эксплуатацией этого кода (то есть предоставляли услуги реальным пользователям, а не просто работали в режиме тестирования). Как и размещение компьютеров на отдельном этаже, это разделение корнями уходит в середину прошлого века. Написание программного обеспечения было узкоспециализированным направлением, равно как и администрирование компьютеров.
Нюансы управления системой (восстановление после сбоев, реагирование по истечении времени ожидания, плавный переход на новые версии) не так-то легко отделить от ее проектирования, архитектуры и реализации.
Более того, в наши дни под системой подразумевается не только ваш код: это и внутреннее ПО, и облачные сервисы, и сетевые ресурсы, и балансировщики нагрузки, и инструменты мониторинга, и сети доставки содержимого, и брандмауэры, и DNS и т. д. Все эти компоненты тесно связаны между собой и зависят друг от друга.
Люди, пишущие программное обеспечение, должны понимать, как оно соотносится с остальной частью системы, а люди, администрирующие систему, должны понимать, как это ПО работает (или не работает). Движение DevOps началось с попыток свести две группы воедино: для сотрудничества, налаживания взаимопонимания, разделения ответственности за надежность системы и корректность программного кода, для улучшения масштабируемости как программного обеспечения, так и команд разработчиков, которые его пишут.
Четыре кита
Джон Уиллис, авторитетный автор книг о DevOps, определяет четыре ключевых аспекта, на которых основана данная концепция: культура, автоматизация, измерение и обмен знаниями (culture, automation, measurement, sharing, вместе CAMS). Брайан Доусон предлагает другое определение, которое он называет троицей DevOps: люди и культура, процесс и практика, инструменты и технологии.
NoOps
Кто-то считает, что благодаря облаку и контейнерам DevOps нам больше не нужен — эту точку зрения иногда называют NoOps. Ее суть в том, что все системное администрирование делегируется облачному провайдеру или другому стороннему сервису, поэтому компаниям не нужны штатные системные администраторы.
Цитаты
Джордан Бах (AppDynamics)
Благодаря DevOps большая часть традиционного системного администрирования выполняется до того, как код достигает промышленной среды. Выпуск каждой версии подразумевает мониторинг, ведение журнала и A/B-тестирование. Конвейеры CI/CD автоматически выполняют модульные тесты, сканирование безопасности и проверку политик при каждой фиксации изменений. Развертывание происходит автоматически. Контроль, задачи и нефункциональные требования теперь прорабатываются перед выпуском версии, а не во время или после критического сбоя в работе.
Джеральд М. Вайнберг
Неважно, как это выглядит на первый взгляд, но проблема всегда в людях.
Брайан Доусон (Cloudbees) (Computer Business Review)
DevOps — это не причуда, а, скорее, способ, с помощью которого успешные организации в наши дни индустриализируют доставку качественного программного обеспечения; уже завтра и на ближайшие годы это станет новой нормой.
Келси Хайтауэр
Kubernetes занимается тем же, чем и самые лучшие системные администраторы: автоматизацией, централизованным ведением журнала, мониторингом, обеспечивает отказоустойчивость. Данная платформа берет то, чему мы научились в сообществе DevOps, и делает из этого готовое решение по умолчанию.
Некоторые из этих возможностей, такие как балансировка нагрузки и автомасштабирование, встроены в ядро Kubernetes, другие предоставляются в виде дополнений, расширений и сторонних инструментов с использованием стандартного API. Kubernetes отличается обширной и постоянно растущей экосистемой.
Ог Мандино
Чтобы сделать что-то по-настоящему стоящее, мне надо не отступать и трястись при мыслях о холоде и опасности, а с радостью дерзать и идти вперед изо всех сил.
Тезисы
Внедрение DevOps требует от компании глубокого культурного преобразования, которое должно начинаться на руководящем, стратегическом уровне и постепенно распространяться на каждый отдел организации. Скорость, динамичность, взаимодействие, автоматизация и качество ПО являются ключевыми целями DevOps, что для многих компаний означает существенные изменения в образе мышления.
Движение DevOps привносит навыки написания ПО в мир системного администрирования: дает инструменты и рабочие процессы для быстрого и динамичного совместного построения сложных систем. С этой концепцией неразрывно переплетается идея инфраструктуры как кода.
Вместо того чтобы физически размещать компьютеры и коммутаторы на стойках и прокладывать к ним кабели, облачную инфраструктуру можно выделять автоматически программным способом. Вместо того чтобы вручную устанавливать и обновлять аппаратное обеспечение, системные администраторы теперь пишут код, который автоматизирует облако.
Но это не односторонний процесс. Разработчики учатся у команд администраторов, как предупреждать сбои и проблемы, неизбежные в распределенных облачных системах, как смягчать их последствия и как проектировать программы, способные самостоятельно понижать свою производительность и контролируемо отключаться.
Огромный масштаб облачных вычислений и совместная, ориентированная на код природа движения DevOps перевели системное администрирование в область программного обеспечения. Вместе с тем ПО теперь является заботой администраторов.
В мире, где программное обеспечение играет центральную роль, способность писать, понимать и поддерживать код становится критически важной. Тот, кто не может или не желает учиться чему-то новому, остается за бортом — и так было всегда.
Есть ли у DevOps предел? Или традиционные централизованные отделы IT и системного администрирования полностью исчезнут, превратившись в группу внутренних консультантов, которые обучают персонал и решают инфраструктурные задачи?
Мы считаем, что этого не произойдет. Многое по-прежнему лучше работает при централизованном управлении. Например, нет никакого смысла поддерживать параллельные способы обнаружения и обсуждения производственных инцидентов, системы ведения тикетов или инструментов развертывания для каждого отдельного приложения или обслуживающей команды. Если все начнут изобретать свой собственный велосипед, ничего хорошего не получится.
Наличие DevOps — это признание того, что разработка современного ПО не заканчивается доставкой кода. Данный подход завершает цикл обратной связи между теми, кто этот код пишет, и теми, кто его использует.
Несмотря на облачную революцию, владеть навыками системного администрирования и работы с инфраструктурой все еще нужно - они становятся еще более важными, чем раньше.
Эволюция Devops методик
Более ранние попытки решить эту проблему включали в себя использование систем управления конфигурациями, таких как Puppet и Ansible, которые состояли из кода для установки, запуска, настройки и обновления поставляемого ПО. В качестве альтернативы некоторые языки предоставляют собственные механизмы управления пакетами, такие как JAR-файлы в Java, eggs в Python и gems в Ruby.
Однако они работают в пределах одного конкретного языка и не могут полностью решить проблему зависимостей — например, прежде, чем вы сможете запустить JAR-файл, вам все равно нужно установить среду выполнения Java.
Omnibus
Еще одним решением является универсальный (omnibus) пакет, который, как следует из его названия, пытается вместить все нужное приложению в единый файл. Такой пакет содержит программное обеспечение, его конфигурацию, программные компоненты, от которых оно зависит, их конфигурацию, их зависимости и т. д. (например, универсальный пакет Java содержал бы среду выполнения JRE, а также все JAR-файлы для приложения).
Образы ВМ
Некоторые поставщики пошли еще дальше — начали предоставлять целую компьютерную систему, необходимую для запуска приложения, в виде образа виртуальной машины. Но такая система слишком громоздкая, занимает много места и времени для построения и обслуживания, легко ломается во время работы, медленно загружается и развертывается, а также является крайне неэффективной с точки зрения производительности и потребления ресурсов.
Контейнеры
Чем контейнер отличается от образа виртуальной машины? Тот тоже содержит все необходимое для работы приложения — но еще и много чего сверх. Типичный образ занимает около 1 ГиБ1. Для сравнения: хорошо спроектированный образ контейнера может оказаться в сто раз меньше.
Контейнеры работают непосредственно на реальном ЦПУ и без дополнительных расходов на виртуализацию — точно так же, как обычные исполняемые файлы.
И поскольку контейнеры содержат только нужные им файлы, их размер куда меньше, чем у образов ВМ. Они также используют продуманную методику адресуемых слоев файловой системы, которые можно разделять и задействовать в разных контейнерах.
Сама платформа Kubernetes написана на Go, так же как и Docker, Terraform и многие другие популярные проекты с открытым исходным кодом.
Kubernetes
К концу 2017 года война оркестраторов закончилась победой Kubernetes. И хотя другие системы все еще используются, компаниям, желающим перевести свою инфраструктуру на контейнеры, теперь стоит рассматривать лишь одну платформу -Kubernetes.
Не все проблемы решает k8s
Будет ли инфраструктура будущего полностью базироваться на Kubernetes? Наверное, нет. Прежде всего, Kubernetes просто не очень хорошо подходит для некоторых структур (таких как базы данных).
К тому же некоторые задачи не требуют Kubernetes и могут работать на платформах, которые иногда называют бессерверными (serverless). У них есть более подходящее название: функции как сервис (functions as a service, FaaS).
В качестве примера платформы FaaS можно привести AWS Lambda. Она позволяет выполнять код, написанный на Go, Python, Java, Node.js, C# и других языках, не требуя при этом никакой компиляции или развертывания вашего приложения. Amazon сделает это все за вас.
Следует также отметить, что облачные функции не ограничиваются публичными платформами FaaS, такими как Lambda или Azure Functions: если у вас уже есть кластер Kubernetes и вы хотите запускать на нем FaaS-приложения, это можно сделать с помощью OpenFaaS (www.openfaas.com) и других открытых проектов. Такой гибрид функций и контейнеров иногда называют фунтейнерами (funtainers).
Литература
- “Kubernetes for Devops” Arundel, Domingus