Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

Контейнеры: Поиски «магического фреймворка» и почему им стал Kubernetes

Предыстория

Инженерная команда проекта изначально использовала методологию непрерывного развертывания (continuous delivery) Jenkins для каждого сервиса. Это позволяло запускать по каждому коммиту интеграционные тесты, генерировать артефакт и образ Docker, после чего разворачивать его не тестовом сервере. С помощью одного клика любой образ можно было развернуть на "боевом" сервере. Схема выглядела примерно так:


В ячейках под названием John и Doe содержатся наборы Docker-контейнеров, развернутых на конкретном узле. Кроме того для провижининга применяется Ansible. В итоге создать новый облачный сервер и установить на него корректную версию Docker/Docker-Compose, сконфигурировать правила межсетевого экрана и выполнить прочие настройки можно в помощью одной команды. Для каждого работающего в Docker-контейнере сервиса есть сторожевые скрипты, которые «поднимают» его в случае сбоя. Но в такой конфигурации возможны и проблемы.


Если сервер Doe "сгорит" однажды ночью (или просто на нем призойдет кратковременный серьезный сбой), технической команде проекта придется подниматься среди ночи, чтобы вернуть систему в работоспособное состояние. Сервисы, установленные на Doe, автоматически не перемещаются на другой сервер — например, John, поэтому на некоторое время работа системы была бы прекращена.

Есть и другие сложности — расположение на одном узле максимального количества контейнеров, обнаружение сети (service discovery), "заливка" обновлений, агрегирование лог-данных. Нужно было как-то со всем этим справиться.


Нужен был некий волшебный фреймворк оркестрации (orchestration framework), с помощью которого можно было бы распределять контейнеры по узлам кластера. Нужно было добиться того, чтобы работать с множеством узлов можно было бы, как с одним-единственным. Нужно было, чтобы этому волшебному фреймворку можно было сказать «разверни 3 экземпляра вот такого Docker-контейнера где-нибудь в кластере и проследи, чтобы все работало». Отличный план! Дело оставалось за малым — найти такой фреймворк.

Список пожеланий

Технологии развиваются очень быстро, так что даже для соответствия весьма умеренным стандартам, все равно необходимо выбирать инструменты таким образом, чтобы они были живы и поддерживались на протяжении какого-то времени. Инженеры Haleby хотели бы, чтобы их «фреймворк мечты» использовал что-то вроде уже применявшегося ими docker-compose — это позволило бы избавиться от необходимости проведения большого количества работ по реконфигурации и настройке.

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

Помимо этого члены команды Haleby хотели бы, чтобы в выбранном инструменте присутствовала поддержка работы с контейнерами в нескольких облаках одновременно, а также наличие функциональности сетевого обнаружения. Также инженерам не хотелось тратить много времени на настройку, поэтому предпочтительным был бы вариант использования модели «framework as service».

Выбор фреймворка

Анализ существующих на рынке вариантов позволил выделить несколько фреймворков-кандидатов. В их числе:

 

AWS ECS

AWS ECS Container Service — это высокомасштабируемый и быстрый инструмент управления контейнерами, с помощью которого их можно запускать, останавливать и работать с контейнерами Docker в кластере инстансов Amazon EC2. Если какой-либо проект уже работает в этом облаке, то не рассмотреть данный вариант просто странно. Однако Haleby не работал на Amazon, поэтому переезд показался инженерам компании не самым лучшим решением. 

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

Docker Swarm

Docker Swarm — это нативный инструмент кластеризации для Docker. Поскольку Swarm использует Docker API, то любое средство, умеющее работать с демоном Docker, может быть масштабировано с его помощью. Поскольку Haleby использует docker-compose, последняя опция звучала очень заманчиво. Кроме того, использование нативного инструмента знакомой технологии означало, что команде не придется изучать что-то новое.

Однако не все было так радужно. Несмотря на то, что Swarm поддерживает несколько движков для сетевого обнаружения, но настроить работоспособную интеграцию — непростое занятие. Кроме того, Swarm — это не managed-сервис, поэтому настраивать и поддерживать его работу пришлось бы самостоятельно, что изначально не входило в планы команды проекта.

Более того, обновление контейнеров также невозможно было бы провести в автоматическом режиме. Для этого пришлось бы, к примеру, настраивать Nginx в качестве балансировщика нагрузки на различные группы контейнеров. Также многие инженеры в интернете выражали сомнения в работоспособности Swarm — среди них, к примеру, сотрудники Google.

Mesosphere DCOS



После настройки DCOS (операционной системы дата-центра) на AWS и старта работы, Mesosphere кажется неплохим вариантом. С помощью удобного интерфейса можно получить всю информацию о кластере, включая запущенные сервисы, загрузку процессора и потребление памяти. DCOS может работать в любом облаке и сразу с несколькими облаками. Mesos же — это инструмент, проверенный работой в крупных кластерах. Также DCOS позволяет запускать не только контейнеры, но и отдельные приложения, вроде Ruby, а устанавливать важные сервисы можно с помощью простой команды dcos install (это как apt-get для дата-центра). 

Более того, с помощью этого инструмента можно работать с несколькими кластерами одновременно — можно запустить Marathon, Kubernetes, Docker и Swarm в рамках одной системы.

Однако наряду с плюсами, у этого варианта были и свои недостатки. К примеру, поддержка работы с несколькими облаками присутствует только в Enterprise-версии Mesosphere DCOS, однако цена этой версии не указана на сайте, а на запросы никто не ответил.

Также в документации на тот момент (октябрь/ноябрь 2015 года) не было информации о том, как переехать на новый кластер без необходимости прерывания работы системы — тут важно понимать, что это также не managed-сервис, так что во время переезда могут возникнуть проблемы. 

Tutum

Команда проекта описывает его как «Docker-платформа для Dev и Ops», а слоган звучит как «стройте, разворачивайте и управляйте своими приложениями в любом облаке». Интерфейс выглядит вот так:


Кому-то он может показаться не столь эффектным, как у DCOS, но тем не менее система позволяет производить большинство нужных манипуляций с помощью простых кликов мышкой, хотя у Tutum есть и хорошая поддержка командной строки. Для начала работа с системой нужно установить Tutum-агент на каждом узле кластера, после чего узел начинает отображаться в административной панели. Интересный момент — Tutum использует формат объявления стэков из нескольких сервисов или контейнеров, который похож на docker-compose — поэтому специалистам, знакомым с Docker будет еще проще начать работу.

Кроме того, Tutum поддерживает тома с помощью интеграции в кластер Flocker. Тесты, в ходе которых определенные контейнеры «убивались» были пройдены успешно — они воссоздавались в том же состоянии (иногда на разных узлах). Еще одним плюсом стала функция создания ссылок между контейнерами — с ее помощью можно связывать определенные контейнеры в группе.

Для балансировки нагрузки используется HAProxy, который поддерживает виртуальные хосты, так что за одним экземпляром HAProxy можно размещать несколько сервисов. Развертывание сервисов также можно осуществлять разными способами, а для обновления Docker во всем кластере достаточно сделать пару кликов. В дальнейшем компания Docker купила сервис Tutum, так что в будущем он будет полностью интегрирован в экосистему.

Однако на момент поисков лучшего фреймворка Tutum находился в стадии бета-тестирования. И все же главным аргументом против этого варианта стал инцидент, когда в ходе теста инженеры специально добились полной недоступности узла — загрузка CPU 100% не позволяла даже подключиться к машине по SSH, контейнеры с него не были перенесены на другой узел. Техподдержка Tutum заявила о том, что знакома с этой проблемой, но она еще не устранена. Нужно было искать дальше.

Kubernetes



Команда Kubernetes описывает проект как инструмент для «управления кластером Linux-контейнеров в качестве единой системы для ускорения Dev и упрощения Ops». Это открытый проект, который поддерживает Google, также его развитием занимается ряд других компаний, в числе которых Red Hat, Microsoft, SaltStack, Docker, CoreOS, Mesosphere, IBM. 

Что по-настоящему хорошо в Kubernetes, так это то, что в нем объединен десятилетний опыт Google по построению и работе с кластерами — и все это бесплатно! Запустить Kubernetes можно на своем железе или на мощностях облачных провайдеров вроде AWS для которого даже есть специальные шаблоны формаций.

Кроме того, Google предлагает managed-версию Kubernetes под названием Google Container Engine. Из-за недостатков интерфейса начать работать с ней не так легко, как к примеру с Tutum, однако после того, как пользователю удастся разобраться в системе, работать с ней становится просто.

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

Еще одним существенным плюсом Kubernetes стала возможность обновления всего кластера без прерывания работы. Также тесты подтвердили работоспособность сетевого обнаружения — нужно лишь вбить в адресную строку имя нужного сервиса (http://my-service), и Kubernetes создать подключение к нужному контейнеру. Kubernetes представляет собой модульную систему, компоненты которой можно комбинировать. 

Есть у фреймворка и свои минусы — при работе с Google Container Engine система ограничивается одним дата-центром. Если с ним что-нибудь случится, ничего хорошего не будет. Из любой ситуации можно выйти, например, организовав несколько кластеров с помощью балансировщика нагрузки, но «из коробки» решения нет. Однако поддержка работы с несколькими ЦОД планируется в новых версиях более легкой версии фреймворка Ubernetes. Кроме того, Kubernetes использует свой yaml-формат, что приводит к необходимости конвертации файлов docker-compose. Помимо этого, проект еще не настолько развит, как тот же Mesos, который позволяет работать с большим количеством узлов.

Заключение

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

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

12.03.2016

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.