Делаем разработку удобной: как использовать Docker в работе с микросервисами
С появлением Docker разработка серверных веб-приложений сильно изменилась. Благодаря этой платформе создавать и управлять масштабируемыми приложениями на основе микросервисов стало проще. Специалисты компании RubyGarage согласились помочь понять, что такое микросервисы и как Docker помогает их реализовывать. Передаем им слово.
Будущее уже здесь!
Давайте начнем с примера. Представьте, что в вашей команде веб-разработчиков есть некий Иванов, который использует Mac OS. Петров, второй разработчик, работает с Windows. Наконец, Сидоров, третий член вашей команды, решил, что ему лучше работать в Debian. Все три специалиста используют разные среды для разработки одного и того же приложения, и для каждого окружения требуется уникальная установка.
Каждый разработчик просматривает 20 страниц инструкций по установке различных библиотек и языков программирования, после чего начинает работу. Тем не менее, почти неизбежно, что библиотеки и языки будут конфликтовать в этих трех разных окружениях разработки.
Добавьте еще три среды — вспомогательные, тестовые и производственные серверы — и увидите, насколько сложно обеспечить единообразие при разработке, тестировании и на стадии продакшена.
При чем здесь Docker и микросервисы?
Проблема, которую мы только что описали, актуальна, когда вы создаете монолитные приложения. И будет намного хуже, если вы решите идти в ногу с модным трендом и разработать приложение на основе микросервисов.Микросервисы автономны и являются независимыми модулями приложения, каждый из которых выполняет только одну конкретную бизнес-функцию, а значит, каждый из них может считаться мини-приложением.
Что случится, если вы создадите с десяток микросервисов для своего приложения? А что, если вы решите создать несколько микросервисов, используя разные стеки технологий? У вашей команды сразу возникнут проблемы, поскольку разработчикам придется управлять еще большим количеством сред, чем в случае с традиционным монолитным приложением.
Но решение есть: использовать микросервисы и контейнеры для инкапсуляции каждого микросервиса. Docker поможет вам управлять этими контейнерами.
Docker — это инструмент для контейнеризации, который изначально был построен на основе контейнеров Linux, чтобы обеспечить более простой способ обработки контейнерных приложений.
Мы рассмотрим преимущества Docker и посмотрим, как он может помочь нам в реализации микросервисов.
Преимущества Docker для микросервисов
Контейнеризация, как альтернатива виртуализации, всегда обладала потенциалом изменить способ, который мы используем для создания приложений. Docker, как инструмент контейнеризации, часто сравнивают с виртуальными машинами.
Виртуальные машины (VM) были созданы для оптимизации использования вычислительных ресурсов. Вы можете запустить несколько виртуальных машин на одном сервере и развернуть каждый экземпляр приложения на отдельной виртуальной машине.
В этой модели каждая виртуальная машина обеспечивает стабильную среду для одного экземпляра приложения. Но, к сожалению, при масштабировании приложения мы быстро столкнемся с проблемами производительности, поскольку виртуальные машины потребляют много ресурсов.
Гипервизор значительно сокращает ресурсы
На схеме выше показано, что гипервизор используется для запуска нескольких операционных систем на одном сервере. Проще говоря, гипервизор помогает сократить ресурсы, необходимые для запуска нескольких операционных систем.
Поскольку микросервисы напоминают небольшие приложения, мы должны развертывать их на собственных виртуальных машинах, чтобы обеспечить дискретность сред. Логично предположить, что выделять виртуальную машину целиком для разворачивания только небольшой части приложения — не самый эффективный вариант.
Но с помощью Docker можно сократить ресурсы и развернуть тысячи микросервисов на одном сервере, поскольку для контейнеров Docker требуется гораздо меньше вычислительных ресурсов, чем для виртуальных машин.
До сих пор мы говорили об управлении средой для одного приложения. Но предположим, что вы разрабатываете два разных проекта или вам нужно протестировать две разные версии одного и того же приложения. В этом случае неизбежны конфликты между версиями приложений или библиотеками (для проектов), а поддержка двух разных сред на одной виртуальной машине становится настоящей проблемой.
Чем Docker превосходит виртуальные машины?
В отличие от того, как работают виртуальные машины, с Docker нам не нужно постоянно настраивать чистые среды в надежде избежать конфликтов. С Docker мы знаем, что конфликтов не будет. Docker гарантирует, что микросервисы приложений будут работать в своих собственных окружениях, полностью отделенных от операционной системы.
Благодаря Docker каждому разработчику в команде не нужно тщательно следовать инструкциям для конкретной операционной системы, изложенным на десятках страниц. Вместо этого разработчик может создать стабильную среду со всеми необходимыми библиотеками и языками, и просто сохранить эту настройку в Docker Hub (подробнее о нем мы поговорим позже). Другим программистам после этого нужно только скачать настройки, чтобы получить точно такое же окружение. Так Docker может сэкономить нам много времени.
Погуглив, вы, вероятно, прочтете и о других преимуществах использования Docker, таких как высокая скорость разработки и свобода выбора с точки зрения стеков технологий. Но на наш взгляд эти преимущества не имеют ничего общего с Docker. На самом деле именно микросервисная архитектура позволяет быстро разрабатывать новые функции и выбирать любой технологический стек, который вам нравится, для каждого микросервиса.
Подытожим преимущества Docker:
- Быстрый запуск. Контейнер Docker запускается за считанные секунды, потому что это процесс операционной системы. Загрузка виртуальной машины с ОС может занять несколько минут.
- Быстрое развертывание. Нет необходимости создавать новую среду — с Docker членам команды веб-разработчиков нужно только загрузить образ Docker, чтобы запустить его на другом сервере.
- Легкое масштабирование контейнеров и управление ими, поскольку вы можете уничтожать и запускать контейнеры быстрее, чем уничтожать и запускать виртуальные машины.
- Более эффективное использование вычислительных ресурсов, поскольку вы можете запускать больше контейнеров, чем виртуальных машин на одном сервере.
- Поддержка различных операционных систем: Windows, Mac, Debian и других ОС.
Теперь давайте рассмотрим архитектуру Docker, чтобы узнать, как именно она помогает нам разрабатывать приложения на основе микросервисов.
Архитектура Docker
Чтобы лучше понять, как работает Docker и как его использовать, мы рассмотрим очень простой микросервис. Существует множество примеров архитектуры микросервисов, но для этой статьи мы приведем наш собственный:
Приложение из нашей практики
Приложение (микросервис), показанное на схеме, состоит всего из трех сервисов и позволяет вам сделать блог для сайта. Каждая служба — Nginx (веб-сервер), MySQL (база данных) и WordPress (система управления содержимым сайтов) — инкапсулирована в контейнер.
Но приведенный выше пример не демонстрирует всю архитектуру Docker, поскольку контейнеры являются лишь ее частью. Архитектура Docker включает три основных компонента: образы, контейнеры и реестры. Мы рассмотрим каждый компонент по очереди. Но прежде чем использовать Docker для разработки, вам необходимо установить его на свой компьютер.
Чтобы контейнеры Docker работали вместе, мы должны сначала указать каждый из них в файле docker-compose, поскольку Docker Compose координирует все сервисы:
version: '3.9'
services:
nginx:
build: ./nginx
restart: always
depends_on:
- wordpress
volumes:
- demo-wordpress:/var/www/html
ports:
- 80:80
wordpress:
image: wordpress:php7.1-fpm
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_PASSWORD: example
depends_on:
- mysql
volumes:
- demo-wordpress:/var/www/html
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example
volumes:
- demo-db:/var/lib/mysql
volumes:
demo-db:
demo-wordpress:
Давайте проясним, что происходит в docker-compose.yml.
Следует обратить внимание на три элемента этого файла. Во-первых, необходимо указать службы приложения – nginx, wordpress и mysql. Во-вторых, мы должны указать образы — обратите внимание на атрибут image под services. Наконец, следует указать еще один атрибут – volumes.
Образы в Docker
Контейнеры Docker не возникают на пустом месте. Они создаются из образов Docker, которые служат схемами для контейнеров и являются вторым компонентом в архитектуре Docker. Чтобы запустить образ Docker, мы должны использовать Dockerfiles.
Dockerfiles — это текстовые файлы, объясняющие, как следует создавать образы.
Помните, как в docker-compose мы не указали образ для Nginx? Мы не хотели использовать готовый образ Nginx, поэтому написали build. Таким образом, мы указали Docker создать образ Nginx и применить наши собственные конфигурации. А чтобы проинструктировать Docker, какой образ нужно использовать и с какими конфигурациями, мы используем Dockerfiles.
Вот пример файла Nginx Dockerfile в нашем небольшом приложении:
FROM nginx:stable-alpine COPY site.conf /etc/nginx/conf.d/default.conf
Как видите, мы дали Docker всего две инструкции. Первая строка определяет базовый образ, из которого будут созданы контейнеры. В нашем примере базовым образом для контейнера Nginx является nginx:stable-alpine. Можно создавать образы с очень специфическими версиями библиотек или языков. Вторая строка сообщает Docker, где искать конфигурации. Обычно мы помещаем такие файлы в тот же каталог, где хранится Dockerfile.
Важная деталь: образы Docker никогда не меняются после того, как они попадают в реестр. Мы можем только извлечь образ из Docker Hub, изменить его, а затем вернуть обратно новую версию. Каждый новый контейнер будет создан из того же базового образа, который мы указали в docker-compose.yml или Dockerfile.
Поскольку Docker скрывает среду контейнера от операционной системы, вы можете использовать определенную версию библиотеки или языка программирования, которая никогда не будет конфликтовать с системной версией той же библиотеки/языка на вашем компьютере.
Тома в Docker
В файле docker-compose каждая служба также имеет атрибут, называемый volumes (тома).
Тома в Docker — это способ обработки постоянных данных, используемых контейнерами.
Разные контейнеры могут обращаться к одним и тем же томам. В файле docker-compose для службы Nginx мы использовали атрибут volumes, который сообщает контейнеру Nginx, что он должен использовать тома WordPress.
Если несколько контейнеров расположены на разных серверах, но по-прежнему нуждаются в доступе к одним и тем же данным, они могут совместно использовать тома. Вот почему следует использовать атрибут volumes.
Реестры образов (репозитории)
До сих пор мы упоминали только образы и контейнеры — два основных компонента архитектуры Docker. Но, возможно, вас интересует, где находятся эти образы. Все контейнеры в нашем примере приложения построены из стандартных образов, хранящихся в Docker Hub. Вот ссылки на базовые образы Nginx, WordPress и MySQL.
Реестры — еще один компонент экосистемы Docker, а Docker Hub — отличный пример реестра.
Реестры — это места (репозитории), где хранятся все образы.
Мы можем:
- передавать в реестр и извлекать из него образы;
- создавать собственный уникальный реестр для конкретного проекта;
- использовать образы из реестров для создания собственных базовых образов.
Мы рассказали обо всех основных компонентах: контейнерах, образах и репозиториях образов. Но архитектура Docker включает в себя и другие важные компоненты: пространства имен (namespaces), группы управления (control groups) и файловые системы Union (UnionFS).
Пространства имен позволяют нам отделять контейнеры друг от друга, чтобы они не могли получить доступ к состояниям друг друга. Группы управления нужны для управления аппаратными ресурсами среди контейнеров, а UnionFS помогают создавать строительные блоки для контейнеров.
Отметим, что эти дополнительные компоненты на самом деле не были созданы Docker: они были доступны в контейнерах Linux. Docker просто использует те же концепции для управления контейнерами.
Мы изложили много новой информации, поэтому давайте сведем ее к следующим ключевым моментам:
- Dockerfiles содержат важные инструкции по работе с образами Docker, которые используются для создания контейнеров;
- каждый микросервис приложения должен иметь отдельный Dockerfile с конкретными инструкциями для каждого образа;
- контейнеры Docker всегда создаются из указанных образов Docker (именно так Docker обеспечивает согласованность между средами);
- вы можете использовать предварительно созданные образы Docker, которые хранятся в общедоступных реестрах, таких как Docker Hub, и можете изменять эти базовые образы с помощью конфигураций, чтобы адаптировать их для ваших приложений;
- вам необходимо зарегистрировать все микросервисы приложения в файле docker-compose.
Расширение архитектуры приложения на базе микросервисов с помощью Docker
Первоначальную архитектуру приложения, которую мы представили в нашем примере, можно легко расширить с помощью других сервисов. Допустим, мы хотите кэшировать запросы приложению в нашем примере. Добавим сервис Varnish. Он позволит нам кэшировать HTML-страницы, изображения, файлы CSS и JavaScript, которые часто запрашиваются пользователями. Наше обновленное приложение на основе микросервисов будет выглядеть так:
Обновленное приложение на основе микросервисов
В приведенном ниже коде показан расширенный файл Docker Compose с сервисом Varnish:
version: '3.9'
services:
varnish:
build: ./varnish
ports:
- 80:80
depends_on:
- nginx
nginx:
build: ./nginx
restart: always
depends_on:
- wordpress
volumes:
- demo-wordpress:/var/www/html
wordpress:
image: wordpress:php7.1-fpm
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_PASSWORD: example
depends_on:
- mysql
volumes:
- demo-wordpress:/var/www/html
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example
volumes:
- demo-db:/var/lib/mysql
volumes:
demo-db:
demo-wordpress:
Нам нужно включить еще один сервис в файл docker-compose.yml, настроить его и указать порты с томами, через которые мы можем подключиться к приложению. Если мы решим не использовать Varnish, мы можем просто удалить его из docker-compose и обновить наши конфигурации. Опять же, вы можете опираться на проект простого контейнера WordPress на GitHub, чтобы увидеть обновленные части приложения.
Это почти все, что следует знать для управления контейнерами с помощью Docker. Но есть одна вещь, которая может вас интересовать: как мы можем управлять сотнями или тысячами контейнеров Docker на нескольких серверах? Последний раздел поможет вам ответить на этот вопрос.
Управление приложениями на основе Docker с помощью систем оркестрации контейнеров
Docker позволяет нам развертывать микросервисы по одному на одном хосте (сервере). Небольшое приложение (как в нашем примере) с менее чем десятком сервисов не требует сложного управления. Но лучше быть готовым к тому, что ваше приложение станет более сложным. Если у вас несколько серверов, как вы можете развернуть контейнеры на каждом из них? Как вы можете масштабировать эти серверы? Экосистема Docker включает системы оркестрации контейнеров для решения этих проблем.
Система оркестрации контейнеров — это дополнительный инструмент, который следует использовать с Docker. До середины 2016 года Docker фактически не предоставлял каких-либо конкретных способов управления приложениями, созданными из тысяч микросервисов. Но теперь есть Docker Swarm — встроенный фреймворк для оркестрации контейнеров.
В Docker есть специальный режим — Swarm mode, который можно использовать для управления кластерами контейнеров. Docker Swarm позволяет использовать Docker CLI для выполнения команд Swarm, поэтому вы можете легко инициализировать группы контейнеров, а также добавлять и удалять контейнеры из этих групп.
Помимо Docker Swarm, вы также можете рассмотреть несколько других менеджеров оркестрации контейнеров:
- Kubernetes — система управления контейнерами. Вы можете запустить Kubernetes на своих серверах или в облаке.
- DC/OS — специальный проект, предоставляющий расширенный графический пользовательский интерфейс для управления контейнерами Docker.
- Nomad Project — программное обеспечение, которое может работать с Docker, чтобы помочь вам развертывать и управлять вашими приложениями в Amazon ECS, DigitalOcean, службе контейнеров Azure или облачной платформе Google.
Если вас интересуют облачные решения, которые могут помочь вам запускать докеризированные приложения и, что еще важнее, управлять контейнерами, то обратите внимание на:
- Google Cloud Platform с поддержкой Kubernetes. Также есть облачный менеджер Google Container Engine, основанный на Kubernetes.
- Amazon Web Services. AWS позволяют использовать сервис Elastic Compute Cloud (EC2) для запуска и обработки контейнеров Docker. Вы также можете воспользоваться Elastic Kubernetes Service для работы с Kubernetes в AWS.
- Служба контейнеров Azure — это хостинговое решение, аналогичное Amazon ECS, которое поддерживает различные платформы для оркестрации докеризованных приложений, включая Kubernetes, DC/OS с Mesos и Docker Swarm.
Сейчас все три платформы позволяют как просто разворачивать контейнеры с приложениями, так и поддерживают работу с контейнерами через Kubernetes.
Вывод
Использование микросервисов и контейнеров — это эффективный и современный способ создания масштабируемых и управляемых веб-приложений. Если вы не контейнезируете микросервисы, вы столкнетесь с множеством трудностей развертывая их и управляя ими. Чтобы не было проблем с их развертыванием, мы используем Docker. Добавьте систему оркестрации контейнеров и вы сможете с легкостью создавать докеризированные приложения. Удачи!
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: