Обложка: Пример создания домашнего микрокластера minicube

Пример создания домашнего микрокластера minicube

3
Руслан Кондратьев
Руслан Кондратьев

backend-разработчик

Система Docker призвана решить ряд проблем, возникающих при использовании виртуальных машин, например, поглощения вычислительных ресурсов. Она прочно вошла в обиход многих разработчиков программного обеспечения, инженеров DevOps.

Появившаяся в 2008 году компания Docker (или dotCloud, как она тогда именовалась), воплотила в своей разработке лучшие моменты системы LXC (Linux Containers).

Благодаря системе Docker можно в два щелчка локально разворачивать необходимые для разработки базы данных, тестировать собственные микросервисные модули, объединять их в сеть и даже связывать сети между собой через глобальную паутину. Работать с Docker в OS Linux – одно удовольствие.

Например, команда:

создаёт рабочий контейнер базы данных MariaDB, доступ к которой можно осуществлять через порт 3306. Так же легко объединять контейнеры в сеть.

В результате мы имеем запущенный изолированный контейнер на основе скачанного образа MariaDB, работающий на определенном порте и потребляющий ровно столько ресурсов, сколько необходимо для работы БД в конкретный момент времени. Просто, удобно, продуктивно.

На сайте Docker подробно описано, как установить последнюю версию для различных операционных систем. В Linux — добавить себе нужный репозиторий с ключом, добавить пользователя в группу Docker, чтобы не дёргать каждый раз sudo, и установить контейнеризатор.

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

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

К счастью, есть интересное решение, описание к которому я почерпнул в книге Марко Лукши «Kubernetes in Action». Это – одноузловой кластер Minikube. Однако есть две проблемы:

  • не описано, как его устанавливать в Windows;
  • указано, что для работы микрокластера нужен VirtualBox.

Ставить виртуальную машину для использования Docker-контейнеров и кластера в OS Windows уже тянет на overhead.

Слишком много действий. Формулируем задачу: нужен простой, но функциональный локальный кластер, который можно развернуть без применения внешних виртуальных машин.

Если «загуглить», то можно найти интересное решение. Предлагаю его рассмотреть. Я Docker-контейнеры в Windows использую теперь именно так.

Буквально пара слов об объекте исследования. Существует множество систем оркестрации контейнеров. Среди них есть система Kubernetes. Сама система довольно интересна, подробнее о ней можно почитать, например, здесь. В частности, Kubernetes предлагает одноузловой микрокластер под названием Minikube.

Чем он интересен? Тем, что позволяет разворачивать на компьютере нечто вроде продуктового кластера из одного узла, поднимать в нем контейнеры, мониторить их через встроенный Dashboard, следить за жизненным циклом, автоматически переподнимать и так далее. И всё это — в рамках локальной разработки.

Решение использовать такой одноузловый кластер, учитывая всё вышесказанное, выглядит интересно. Проведем процесс инсталляции и проверим результат.

  • Первое, что необходимо сделать — скачать стандартный инструментарий Kubernetes kubectl. Заходим по ссылке, скачиваем exe-файл. Это инструмент командной работы с нашим будущим кластером.
  • Второе — скачать инсталлятор самого Minikube по ссылке и устанавливаем.
  • Третье — запустить кластер локально.

Это не займёт много времени.

Тут стоит на минуту отвлечься и сказать несколько слов о том, как стартует кластер. Для запуска ему нужен драйвер. Драйверов он поддерживает множество (рис.1).

Рисунок 1. Поддерживаемые драйверы

Рисунок 2. Используемая OS в примере

Ни VirtualBox-VM, ни VMware-VM, ни Docker-VM не подходят, так как для них нужно устанавливать виртуальную машину. Остаётся только Hyper-V, он уже встроен в Windows. Поддержка этой технологии началась ещё с Windows 8 Pro, однако в полной мере ееёразвернули «из коробки» лишь в Windows 10 Pro и выше. В данном примере взята Windows 8.1 Pro (рис.2).

Перед запуском необходимо убедиться, что в системе активирован Hyper-V (рис.3):

Рисунок 3. Расположение настроек Hyper-V

В Hyper-V-менеджере создаем внешний виртуальный коммутатор на базе встроенной сетевой карты (у меня в системе их две + Wifi адаптер) (рис.4):

Рисунок 4. Виртуальный адаптер

Коммутатор необходим микрокластеру для запуска. Стоит отметить, что в Windows 10 создавать коммутатор мне не пришлось, заработало на «default»-коммутаторе.

Кластер запускается следующей командой в PowerShall от имени администратора (рис.5):

Рисунок 5. Развёртывание кластера

Где: ключ –driver задает драйвер управления, –hyperv-use-external-switch принуждает использовать внешний виртуальный коммутатор, а –hyperv-external-adapter задаёт адаптер внешнего коммутатора (в данном случае это встроенная сетевая карта #2). Также на слайде виден создаваемый кластер, обозначенный в секции Virtual Machines с именем minikube.

После окончания старта у нас имеется поднятый одноузловой кластер, в котором можно проводить развёртывание (development) любых docker-контейнеров (рис.6).

Рисунок 6. Развёртывание кластера завершено успешно

На слайдах можно заметить, что при подъёме кластера выкидывается ошибка на привилегии. Это проблема Windows 8.1. В десятке подобной проблемы не наблюдается. По этой причине применен флаг игнорирования привилегий –force

Проверим, что развёрнутый кластер откликается (рис.7):

Рисунок 7. Проверка статуса кластера

Чтобы остановить кластер, вызываем stop (рис.8):

Иллюстрация: микрокластер

Рисунок 8. Остановка кластера

Чтобы запустить – start (опять же с ключом –force в моем случае) (рис.9):

Иллюстрация: микрокластер

Рисунок 9. Запуск кластера

Создать Pod (Pod — это группа из одного или нескольких контейнеров приложения и совместно используемых ресурсов для этих контейнеров) в кластере проще простого. Необходимо сделать развёртывание (Deployment) и создать под это развёртывание сервис (Service). При необходимости можно создать переменную, например, в начале статьи была приведена команда создания контейнера MariaDB. Воспроизведём её в созданном кластере (рис.10):

Иллюстрация: микрокластер

Рисунок 10. Запуск Pod MariaDB в кластере

Что я сделал:

  • создано развёртывание образа MariaDB с именем mariadb-server;
  • задана переменная окружения MARIADB_ROOT_PASSWORD;
  • создан сервис для прокидывания порта 3306 с именем mariadb-local и типом NodePort (есть ещё 3 типа);
  • запрошена информация о созданном Pod.

Стоит отметить, что Pod поднимается не сразу, необходима пара минут, чтобы все собралось и «взлетело» (рис.11).

Иллюстрация: микрокластер

Рисунок 11. Запрос информации о Pod

Посмотрим на дашборд кластера. Он открывается в браузере по умолчанию. В нём много различной информации о том, какие Pod’ы запущены, сколько существует развёртываний и так далее (рис.12).

Иллюстрация: микрокластер

Рисунок 12. Dashboard кластера в браузере

Убедимся, что развёрнутая база данных доступна извне для использования в разработке. Запросим информацию о развёрнутом сервисе у кластера (рис.13, 14).

Иллюстрация: микрокластер

Рисунок 13. Запрос информации о развёрнутом сервисе

Иллюстрация: микрокластер

Рисунок 14. Окно DataSource and Drivers Intellij Idea

Сервис наружу прокинул другой порт. Если требуется именно 3306, то нужен другой тип сервиса, например, LoadBalancer.

В итоге удалось реализовать локальный микрокластер в OS Windows без привлечения сторонних виртуальных машин. В качестве основы задействована аппаратная виртуализация на базе технологии Hyper-V, являющаяся компонентом OS Windows 8.1-10 версий Pro и выше и не требующая установки. Полученная конфигурация позволяет проводить испытания контейнеров в условиях продуктовой кластеризации, пусть и на несколько примитивном уровне.

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

Спасибо.

Что думаете?