Отказ не принимается
Представьте себе ситуацию, что у банка в один момент перестает работать приложение, отвечающее за личный кабинет клиента. Если отделений у банка нет, отказ программы фактически означает остановку деятельности. Подобные критические бизнес-приложения (Business Critical Application – BCA) есть у компаний разного масштаба и из различных отраслей, но объединяет их одно: если эти программы дали сбой, то компания не сможет продолжать работу. Поэтому при нынешнем уровне цифровизации бизнесу необходимы решения, которые обеспечат бесперебойную работу ВСА при любых нагрузках и в любых ситуациях.
Контейнеры и виртуальные машины
Понять современный подход к созданию и обслуживанию надежной, производительной и эффективной ИТ-инфраструктуры для критичных бизнес-приложений можно, посмотрев на развитие ИТ-инфраструктуры.
Можно выделить несколько этапов развития ИТ-инфраструктуры. Сперва приложения запускались на физических серверах. Способа установления границ ресурсов для приложений тогда не существовало, поэтому одна из программ при работе могла утилизировать все имеющиеся мощности сервера, а другим программам ресурсов уже не хватало.
Для решения проблемы с ресурсами придумали виртуализацию. С ее помощью на одном физическом сервере можно запускать сразу несколько виртуальных машин (ВМ) с выделенными ресурсами, которых достаточно для решения определенных задач. При этом приложения изолированы друг от друга.
Виртуализация улучшила использование ресурсов, позволила снизить затраты на оборудование, повысить возможности для балансировки нагрузки и отказоустойчивость системы.
Однако виртуализации оказалось недостаточно, потому что в конечном итоге любая ВМ все равно размещается на конкретном физическом сервере и полностью зависит от него. В случае выхода из строя такого узла все ВМ, размещенные на нем, также теряют работоспособность. Требовалось еще больше «отвязать» приложения от инфраструктуры, на которой они запускаются. Для решения этой проблемы появились контейнеры, которые изолируют приложения друг от друга, а также позволяют гибко и оперативно размещать эти контейнеры на любом «свободном» сервере (или ВМ), в том числе и облачном, а также переносить контейнеры с узла на узел без простоя. То есть софт работает уже не на конечной инфраструктуре, а использует промежуточный слой в виде контейнеров, которые позволяют абстрагироваться от конкретной инфраструктурной платформы и дают возможность разработчикам оперировать на уровне контейнеров.
«Программы, которые запускаются внутри контейнера, изолированы друг от друга и не конфликтуют, ‒ поясняет генеральный директор компании «Флант» Александр Баталов. – Например, если одна команда разработчиков делает решение на языке PHP восьмой версии, а другая на PНР версии 7, все будет корректно работать».
С контейнером проще обеспечить непрерывную разработку, интеграцию и развертывание, а также накатывать обновление, отметил эксперт.
После небольшого экскурса в историю становится понятнее, почему для создания надежной, производительной и эффективной ИТ-инфраструктуры для критичных бизнес-приложений подойдет именно использование контейнеров. На сегодняшний день это самый эффективный и производительный способ распределенного управления ресурсами, обеспечивающий высокий уровень безопасности и гибкости.
Оркестр сложился
Однако контейнерами надо управлять, что не просто в случае больших и нагруженных информационных систем. Здесь на помощь приходят так называемые оркестраторы контейнеров, такие, как например Kubernetes (16+). Программы-оркестраторы управляют жизненными циклами контейнеров и запущенных в них приложений, а также автоматизируют различные производственные процессы.
Существуют и другие оркестраторы: Docker Swarm (16+), Apache Mesos (16+), Nomad (16+) ‒ при этом именно Kubernetes де-факто стал стандартом индустрии.
«Если ранее разработанное приложение буквально «прибивали гвоздями» к конкретной машине, то в контейнеризированных средах для эффективного использования ресурсов приложение в один момент располагается на одном сервере, через мгновение средствами оркестратора перемещается на другой, и таких контейнеров может быть сотни и даже тысячи. А обеспечивать эффективную работу столь комплексной динамичной системы как раз и призвана система оркестрации Kubernetes. Если сильно упрощать, то Kubernetes – это робот ‒ системный администратор, для которого DevOps-инженеры пишут алгоритмы и правила эксплуатации развернутых в кластерах приложений: определяют, какое приложение и где запустить, собирают метрики о работе приложений и т. д. В результате эксплуатировать все большее число информационных систем можно силами уже имеющихся в распоряжении инженеров, но к их квалификации предъявляются повышенные требования».
Таким образом, оригинальный Kubernetes позволяет сильно облегчить рутинные операции для службы эксплуатации, но при этом он предполагает очень высокие требования по квалификации DevOps-инженеров, отмечает эксперт, поскольку сам по себе Kubernetes – это базовый функционал, который не дает готовую к промышленной эксплуатации инфраструктурную платформу.
Поэтому если у компании есть BCA и разработка ПО производится под контейрнеры, то есть выбор либо докручивать Kubernetes своими силами, либо использовать готовую платформу, где инженеры и разработчики уже все предусмотрели.
Классика и современники
Основной дистрибутив Kubernetes развивается как Open Source-проект, в котором регулярно выходят официальные релизы от мирового комьюнити. Его называют «ванильным» или оригинальным, то есть без каких-либо фич от вендоров. В нем содержатся только одобренные всем сообществом функции. Вендоры строят собственные платформы на основе «ванили».
«Самостоятельно «докрутить» дистрибутив Kubernetes под цели конкретной компании возможно, но самое сложное тут будет интеграция, и потому самостоятельно и успешно интеграционные решения на основе Kubernetes делают крупные технологические гиганты с сотней инженеров в штате, ‒рассказывает эксперт. – Подавляющему большинству компаний целесообразнее выбрать готовое решение, подготовленное к продакшену и с возможностью экспертной поддержки».
«Флант» стал одним из первых российских разработчиков такого решения ‒платформы Deckhouse (16+). По словам Александра Баталова, «Флант» сделал выбор в пользу Kubernetes практически сразу после его представления сообществу. Тогда еще не было никаких определяющих технологических трендов, но компания поверила в технологию и начала работу с Kubernetes с сервисного обслуживания ИТ-инфраструктур своих клиентов. Позднее накопленный опыт трансформировался в собственный продукт ‒ Kubernetes-платформу Deckhouse. Причем изначально это был внутренний продукт, помогающий самой компании «Флант» строить надёжные решения и эффективно эксплуатировать их.
Созданный в 2017 году Deckhouse является полнофункциональной платформой, которая кроме ванильного Kubernetes включает модули для мониторинга, балансировки трафика, автомасштабирования, безопасного доступа, администрирования, управления множеством кластеров. Кроме того, платформа предоставляет собственную систему виртуализации, то есть может использоваться компаниями как применяющими классическую виртуализацию, так и использующими контейнеры. Такое сочетание позволяет использовать преимущества «облачного подхода» даже в закрытой инфраструктуре организации, то есть фактически позволяет создавать частные «облака».
Deckhouse – это платформа с высокой степенью взаимной интеграции различных технологических компонентов, готовая к работе в production сразу после развёртывания. Управление всеми компонентами кластера и платформы, а также их обновление автоматизированы. Значит, освобождается больше ресурсов для разработки специфичных для бизнеса сервисов и компонентов, а не для докручивания «голого» Kubernetes до рабочего состояния, с постоянным поиском и исправлением возникающих повсеместно багов и сбоев.
«Deckhouse пригоден для компаний разного масштаба: крупных и совсем небольших. Просто платформа применяется в разном формате», ‒ отмечает Александр Баталов. Например, небольшим и маленьким клиентам имеет смысл купить технологии в качестве сервиса (модель аутсорсинга DevOps-услуг), который позволит иметь безотказные ВСА на основе контейнеров с полной поддержкой от DevOps-экспертов. Зачастую клиенту даже не требуется иметь в штате собственных инженеров.
«Для крупных же игроков формат аутсортинга не подходит, однако они готовы покупать продукты, методологию и экспертизу, по которым могут формировать у себя собственные стандарты эксплуатации и создавать собственные платформенные команды, – считает Александр Баталов. – Наш огромный накопленный технологический опыт ‒ более тысячи компаний-клиентов мы упаковали в гарантированно работающий инфраструктурный продукт».
Важно, что сейчас OpenShift (16+), Rancher (16+) и другие зарубежные Kubernetes-платформы официально больше не поддерживаются в России. Что это значит для потребителей? Нужно искать альтернативные решения для управления контейнеризированными средами, например, дорабатывать «ванильный» Kubernetes или использовать российские платформы. Квалифицированные специалисты «Фланта» помогут оперативно переехать с зарубежных платформ на Deckhouse.
На отечественном рынке Deckhouse используется компаниями в production среде уже шесть лет. С помощью платформы только непосредственно «Флант» управляет более 250 Kubernetes-кластерами, где развернуто более 3 тыс. приложений. Компания входит в состав АРПП «Отечественный софт», а продукты зарегистрированы в реестре Российского программного обеспечения, что может быть важно для выполнения регуляторных требований. Кроме того, компания «Флант» входит в ТОП-150 контрибьютеров Kubernetes по всему миру.
Deckhouse используют компании из самых разных сфер, начиная от банков и ритейла, заканчивая промышленным сегментом, телекомом, каршерингом и т. д. Cреди клиентов такие компании, как Leroy Merlin, «Делимобиль», ООО «Альфа-лизинг», Fesco, АО «ОТП-банк» и АО «Первый канал» (16+).