Подписаться
Читать в телеграм
От "Монолита" к микросервисам
Большая часть приложений, которые разрабатывались вплоть до середины 2000-х гг., можно отнести к классу так называемых монолитных систем. Все компоненты этого ПО тесно связаны между собой, «заточены» друг под друга и не могут функционировать раздельно. С точки зрения разработки и эксплуатации вся система рассматривается как единое целое, соответственно, все задачи по модернизации, обновлению, исправлению и т.п. зачастую решаются в масштабах всего приложения. Например, обновление функционала одного модуля может потребовать остановки работы всей системы.
«Монолитный» подход и сейчас оправдывает себя в целом ряде случаев, подобные системы используются в банках, ритейле, промышленности. Типичными представителями этого вида считаются различные базы данных или комплексные системы классов ERP или CRM от Oracle, SAP и т.д.
В начале 2000-х гг. появился другой подход, ставший логическим продолжением развития виртуализации и облачных технологий, — микросервисная архитектура. Микросервис — это небольшое приложение, которое выполняет четко определенную, простую функцию. То есть ПО при разработке разбивается на множество маленьких и максимально простых сервисов.
Такой подход имеет определенные преимущества как для разработчиков, так и для пользователей. Если один из сервисов в какой-то момент перестанет отвечать, пользователи приложения, скорее всего, этого не заметят, поскольку микросервисы хорошо масштабируются. При сбоях приложение может потерять часть производительности или функциональности, но работоспособность в целом сохранится, а время его восстановления будет намного меньшим, чем у «монолитов». Более того, у микросервисов нет общих данных, и, даже если один из них был взломан или, например, функционирует некорректно (утечки памяти и т.д.), это не откроет доступа к остальной информации — имеет место изоляция компонентов системы.
Упакованные в контейнеры
Для того чтобы обеспечить работоспособность микросервисов, их обычно «заворачивают» в контейнеры. Контейнер — это «обертка», в которую запаковано все необходимое для успешного запуска и работы конкретного микросервиса. По своей сути это «набор туриста»: куда бы вы ни отправились, у вас с собой должны быть палатка, газовая горелка и небольшой запас провизии. Точно так же разработчик может взять контейнер и перенести его в любое место — на другой сервер, в облако и т.д., и он сразу будет работать: для него не нужно настраивать среду, окружение, добавлять пакеты или иные компоненты.
Несколько разных контейнеров могут запускаться в рамках одной операционной системы, но при этом они работают со своими библиотеками и изолируют сервисы друг от друга. Сбой одного контейнера не приводит к каким-либо последствиям для других, к тому же его можно практически мгновенно перезапустить, например, на другой «машине» в кластере.
Контейнеры могут работать как в физическом окружении, так и в виртуальной среде. Второй вариант в последнее время становится все более распространенным, особенно с учетом востребованности контейнеризированных сервисов на базе ресурсов облачных провайдеров. В этом отношении контейнеры расширяют парадигму виртуализации, поскольку могут использовать единую операционную систему и при этом изолировать процессы друг от друга, а также выделять для них ресурсы.
Обычно один контейнер обслуживает один микросервис, такой подход позволяет добиться максимальной гибкости системы.
Почему востребован Kubernetes
Обычно один контейнер обслуживает один микросервис, такой подход позволяет добиться максимальной гибкости системы. Возьмем, к примеру, систему приема заказов в интернет-магазине, которая собирает данные и передает их на обработку. Если количество пользователей внезапно возрастет, во избежание отказа сервиса можно увеличить число контейнеров, отвечающих за указанную функцию. И даже если один из них перестанет отвечать, остальные продолжат работу, а пользовательская нагрузка будет перераспределена между оставшимися экземплярами. Для сложных приложений характерно наличие десятков и сотен контейнеров, причем они могут дублировать друг друга. И всеми ими необходимо управлять. Нужна платформа для так называемой оркестрации контейнеров, которая автоматизирует их развертывание, масштабирование и управление жизненным циклом в кластере из множества серверов. Одно из подобных решений, в настоящее время лидирующее на рынке, — Kubernetes.
Что дает вам решение, подобное Kubernetes? Система оркестрации определяет, где и как разместить контейнеры на имеющихся ресурсах, как их масштабировать, по каким признакам останавливать, переносить и перезагружать, какие именно вычислительные ресурсы и в каком количестве выделять. Kubernetes задает конфигурацию приложения, позволяет устанавливать правила доступа внутренних и внешних пользователей к сервисам внутри контейнеров. Также можно настроить автоматическое выполнение мониторинга состояния, добавления/уменьшения числа контейнеров. Таким же образом происходит диспетчеризация ресурсов серверов, обеспечивающая выделение каждому контейнеру необходимого количества ресурсов. Сделать это вручную крайне сложно (а для больших приложений из сотен контейнеров — невозможно в принципе), поскольку изменение нагрузки происходит постоянно и диспетчеризация осуществляется в реальном времени.
В числе других преимуществ решения — группировка микросервисов, выполняющих какую-либо единую, связную функцию. Например, если ваша веб-служба работает с помощью 5 контейнеров, которые собирают данные, обрабатывают их и т.д., всеми ими можно управлять как единым объектом — так называемым pod. Отдельные наборы pod, представляющие собой целое приложение, объединяются в единый объект — Deployment, управление которым упрощается с использованием оркестратора.
Kubernetes обеспечивает высокую доступность систем. В каждой конфигурации есть один главный узел (Master-node), который распределяет задачи, хранит конфигурации, осуществляет планирование и мониторинг. Рабочие узлы (Worker-nodes) выполняют полезную нагрузку, т.е. непосредственно исполняют контейнеры с вашим приложением. Если один исполнительный узел дает сбой, кластер продолжает работать, а «пропавшие» контейнеры легко создаются заново на других рабочих узлах. Система при этом позволяет строить конфигурации с несколькими Master-node. Контейнеры в силу своей архитектуры обычно запускаются достаточно быстро, так что повторная загрузка не создает дополнительных задержек.
Наконец, средства оркестрации дают возможность использовать в качестве кластера не только ваши собственные (On-Premises) ресурсы, но и ресурсы публичных облаков. Это удобно, например, в том случае, если вы хотите использовать для разработки сторонние мощности, а продуктив запускать в своем ЦОДе. Вы работаете в публичном облаке, а когда нужно, переносите написанное приложение к себе — просто проводите миграцию всех контейнеров в корпоративную ИТ-инфраструктуру. О сценариях применения Kubernetes мы подробнее расскажем ниже.
Kubernetes, конечно, не единственная система с таким функционалом на рынке, но именно она является лидером на текущий момент, и сообщество Open Source активно развивает именно этот продукт. Кроме того, многие вендоры используют Kubernetes для создания на его основе своих коммерческих оркестраторов. Изначально эта технология вышла из стен Google, где с ее помощью решались задачи распределения огромного количества мелких сервисов в рамках гигантской экосистемы. Прообразом Kubernetes стала система управления кластерами Google Borg. Позже продукт был вынесен в сообщество Open Source и стал активно развиваться: для него было создано наибольшее количество дополнений по сравнению с другими платформами для оркестрации контейнеров. Так, под Kubernetes разработано множество готовых контейнеров для решения ряда популярных задач последнего времени — того же машинного обучения. Вы можете просто запустить их у себя, не тратя лишнего времени и ресурсов.
Варианты использования технологии
Как уже было сказано, одна из популярных бизнес-задач, которую позволяет решать Kubernetes как прослойка между оборудованием и приложениями, — это поддержка процессов разработки, развертывания и эксплуатации ПО (практики DevOps). Kubernetes может стать основой инфраструктуры для приложения, которое вы разрабатываете с использованием подхода cloud native.
В контейнерах иногда имеет смысл запускать даже традиционные приложения. Так, наша служба мониторинга в Сервисном центре использует Zabbix. Каждый раз они устанавливали систему у заказчиков с нуля. Запаковав ее в контейнер, специалисты добились сокращения времени установки. Теперь не нужно настраивать переменные окружения, параметры запуска, базы данных и т.д. Можно просто запускать контейнер с готовой средой. Аналогичным путем пошла одна из ведущих российских страховых компаний: она также использует систему мониторинга «из контейнеров» под управлением Kubernetes.
Сегодня контейнеры используются в том числе для поддержки работы веб-сервисов: мобильных банков, приложений онлайн-магазинов, систем взаимодействия с пользователем (HelpDesk), в целом при обработке онлайн-заявок и заказов. Например, пользователь сделал запрос на сайте — агрегаторе авиабилетов на определенные дату и рейс: первый сервис отвечает за обработку этих данных, второй «смотрит» наличие билетов, третий предоставляет дополнительную информацию (об альтернативных рейсах) и т.д.
И все же не панацея
При всех достоинствах у Kubernetes есть определенные ограничения, они сводятся к ограничениям самой контейнерной технологии. Например, не всегда целесообразно размещать в контейнерах СУБД — это зачастую не дает никакого положительного эффекта. Дело в том, что такие системы медленно запускаются и требуют большого количества ресурсов для своей работы. То есть они не являются такими «легкими» и «переносимыми», как, например, веб-сервисы, поэтому и не встраиваются в общую парадигму контейнеризации. Кроме того, традиционные СУБД часто требуют использования решения по репликации данных для обеспечения их надежного хранения. Эти задачи Kubernetes не решает, оставляя их администраторам системы.
Более того, если вы думаете, что, установив Kubernetes, автоматически «закроете» все вопросы, связанные с управлением контейнерами, то лучше его вообще не использовать. В системе оркестрации существует большое количество функциональных особенностей, которые нужно учитывать, чтобы правильно «завернуть» приложения в контейнер. Необходимо хорошо понимать DevOps-подходы, чтобы подготовить среду и сами приложения. Только тогда, когда разработка и администрирование в достаточной степени интегрированы друг с другом, использование инструментов наподобие Kubernetes приобретает смысл. Иначе вы столкнетесь с большой дополнительной работой, которая может принести пользу в будущем, но в настоящем ничего не даст.
75% приложений к 2025 г. будут не приобретаться, а создаваться с нуля самими компаниями цифрового бизнеса с учетом их индивидуальных потребностей.
Вывод
По прогнозам Gartner, 75% приложений к 2025 г. будут не приобретаться, а создаваться с нуля самими компаниями цифрового бизнеса с учетом их индивидуальных потребностей. Практика такова, что при разработке приложений целесообразно применять облачный (Cloud-native) подход. Контейнеры и их оркестрация будут все более востребованы. Поэтому сегодня необходимо задуматься о том, как в вашей компании разрабатывают, внедряют и обслуживают ПО, чтобы по возможности оптимизировать этот процесс с помощью таких технологий, как Kubernetes.
Лилия ГОРОШКО,
В прошлом – руководитель направления консалтинга Центра информационной безопасности компании «Инфосистемы Джет»
Комментарий
Понятие виртуализации всем нам давно знакомо, мы знаем, как с ней работать и защищать. Контейнеризация же появилась сравнительно недавно. И хотя мы уже успели разобраться в принципах ее работы, вопросы безопасности контейнеров по-прежнему остаются актуальными. На начальных этапах развития этой технологии ее безопасность не была вопросом первого приоритета. Но времена меняются, и сегодня известен целый ряд мер по обеспечению защиты контейнеров. Ниже мы приводим основные ИБ-правила в этой сфере.
Первое правило — «Доверие». Используйте только проверенные образы из официального списка поддерживаемых репозиториев, например Alpine, Redis, Ubuntu, Oracle и др. Эти образы безопасны, вероятность уязвимостей в них крайне мала. Прочие образы из приватных репозиториев перед использованием необходимо просканировать на наличие вредоносного кода, например, с помощью Clair — сканера с открытым исходным кодом, работающего по принципу статического анализатора, который проверяет файловую систему образа. Сканирования полезно проводить на регулярной основе.
Платформы для оркестрации, такие как Kubernetes, позволяют развернуть систему обнаружения вторжений, которая будет отслеживать аномальные ситуации в контейнере. Это снижает риск эксплуатации уязвимостей.
Второе правило — «Обновление». Обновляйте образы и пересобирайте контейнеры в случае изменения базового или последующих образов. Это правило, с одной стороны, простое и понятное, а с другой — очень важное с точки зрения безопасности. При большом количестве контейнеров бывает сложно отследить процесс обновления. Здесь поможет автоматизация процесса сборки, которую можно привязать, например, к событию изменения базового образа.
Третье правило — «Ничего личного лишнего». Не запускайте контейнеры и приложения в них с привилегиями root. Злоумышленник через скомпрометированный контейнер с правами root-пользователя может добраться до root основной системы, даже несмотря на механизмы изоляции контейнеров. Если нет возможности отказаться от root, уменьшите количество привилегий, оставьте только самое необходимое для работы содержимого контейнера. В вашем «наборе туриста» не должно быть ничего лишнего: только используемые порты и нужные доступы.
Отсюда вытекает следующее, четвертое, правило, касающееся содержимого контейнеров. Вряд ли вы «потянете» с собой в поход, скажем, хлебопечь: она лишь займет место и добавит вашему рюкзаку веса. Так же и с контейнерами: не перегружайте их лишним содержимым, оно может повысить риск возникновения уязвимостей.
И наконец, пятое правило — «Управление». Используйте платформы для оркестрации контейнеров, например вышеупомянутый Kubernetes. Это позволит повысить не только удобство управления контейнерами, но и их безопасность. Например, в Kubernetes есть встроенные утилиты для статического анализа конфигураций: kubesec и kubetest, которые обеспечивают безопасность во время запуска. Таких утилит безопасности достаточно много.
Этот список правил можно развивать и дальше, углубляясь в отдельные пункты и детализируя возможные дополнительные инструменты. При грамотном подходе контейнеризация может быть безопасной. Достаточно лишь уделить этому чуть больше времени и внимания.