Преимущества использования Docker в микросервисах

Докер, какая польза, кто прав тот ему и даст!

С появлением Docker разработка веб-приложений на стороне сервера претерпела коренные изменения. Благодаря Docker стало проще разрабатывать масштабируемые управляемые приложения на основе микросервисов. Чтобы помочь понять, что такое микросервисы и что делает Docker, давайте возьмем практически реальный пример.

Предположим, в вашей команде веб-разработки есть Джон Доу, использующий Mac, и его коллега Джейн Доу, использующая Windows. Наконец, Джейсон Доу, третий член вашей команды, решил, что будет работать над Debian. Невероятно, но эти три разработчика используют разные среды для разработки одного и того же приложения, и каждая среда требует собственной настройки. Каждый разработчик изучает 20 страниц инструкций по установке различных библиотек, а также языков программирования, чтобы все заработало. Эти библиотеки и языки неизбежно конфликтуют в разных средах. Добавьте еще три среды — подготовительный, тестовый и рабочий серверы. Затем вы узнаете, насколько сложно быть единым в средах разработки, тестирования и производства.

Как микросервисы и Docker связаны с описанным выше сценарием?

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

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

Docker — это инструмент контейнеризации, изначально созданный на основе контейнеров Linux, чтобы обеспечить простой способ обработки контейнерных приложений. Далее мы рассмотрим преимущества Docker и роль, которую он играет в реализации микросервисов.

Преимущества Docker в микросервисах в 2019 году

Контейнеризация — вариант виртуализации, который может изменить способ разработки приложений. Docekr часто сравнивают с виртуальными машинами в качестве инструмента контейнеризации.

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

На приведенной выше диаграмме показано использование гипервизора для запуска нескольких операционных систем на одном сервере. Гипервизор сокращает ресурсы, необходимые для запуска нескольких операционных систем.

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

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

Как Docker побеждает виртуальные машины

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

Благодаря Docker каждому разработчику не нужно читать 20-страничное руководство. Разработчик создает стабильную среду с необходимыми библиотеками и языками и сохраняет настройки в Docker Hub. Затем другим разработчикам просто нужно загрузить настройки и получить точно такую же среду. Docker экономит нам много времени.

Погуглите, и вы найдете другие преимущества использования Docker, такие как более высокая скорость разработки, свободный выбор стека технологий и т. д. Однако следует сказать, что эти другие преимущества, о которых говорят люди, не имеют ничего общего с самим Docker. Это архитектура на основе микросервисов, которая позволяет быстрее разрабатывать новые функции и выбирать предпочитаемый стек технологий.

Преимущества Docker резюмируются следующим образом:

Более быстрое время запуска. Запуск контейнера Docker — дело нескольких секунд, потому что контейнер — это всего лишь процесс операционной системы. Загрузка виртуальной машины с полной операционной системой занимает несколько минут.
Разверните быстрее. Нет необходимости создавать новую среду. С Docker команде веб-разработчиков нужно только загрузить образ Docker и запустить его на другом сервере.
Контейнерами проще управлять и масштабировать. Потому что уничтожить и запустить контейнер быстрее, чем уничтожить и запустить виртуальную машину.
Лучшее использование вычислительных ресурсов, поскольку вы можете запускать больше контейнеров, чем виртуальных машин на сервере.
Поддержка различных операционных систем, Windows, Mac, Debian и так далее.

Теперь давайте взглянем на архитектуру Docker и выясним, как она на самом деле помогает нам разрабатывать приложения на основе микросервисов.

Архитектура докера

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

Приложение на рисунке выше содержит всего три сервиса и реализует блог-сайт. (пример этого приложения находится вGitHubначальство. ) Каждая служба — Nginx (веб-сервер), MySQL (база данных) и Wordpress (движок блога) — инкапсулирована в контейнер.

Приведенный выше пример не содержит полной архитектуры Docekr, поскольку контейнеры являются лишь частью архитектуры. Архитектура Docker состоит из трех основных компонентов — образов, контейнеров и реестров. Мы рассмотрим три компонента один за другим. Однако, прежде чем вы сможете разрабатывать с помощью Docker, вам необходимо установитьDocker.

Чтобы контейнеры Docker могли работать вместе, их сначала необходимо зарегистрировать в файле docker-compose, а Docker Compose отвечает за координацию всех сервисов.

Сначала объясните файл docker-compose.yml.

version: '2'

services:
  nginx:
    build: nginx
    restart: always
    volumes_from:
      - wordpress

  wordpress:
    image: wordpress:php7.1-fpm
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_PASSWORD: example
    depends_on:
      - mysql

  mysql:
    image: mariadb
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes:
      - ./demo-db:/var/lib/mysql

Мы должны сосредоточиться на трех элементах этого файла. Во-первых, должны быть указаны сервисы — «nginx», «wordpress» и «mysql». Во-вторых, необходимо указать изображение — обратите внимание на свойство «image» в службе. Наконец, необходимо указать свойство "volumes".

Докер-образ

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

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

В нашем приложении есть пример Nginx Dockerfiles:

FROM nginx:alpine

COPY site.conf  /etc/nginx/conf.d/default.conf

Как видите, даны только две инструкции.В первой указывается базовый образ для создания контейнера.В нашем случае базовый образ для контейнера Nginx — «nginx:alpine». Изображения можно создавать с использованием определенной версии библиотеки или языка. Второй сообщает Docker, где искать файлы конфигурации. Обычно эти файлы размещаются в том же каталоге, что и Dockerfile.

Одна важная деталь: после того, как образ зарегистрирован, образ Docker нельзя изменить. Мы можем только получить образ из Docker Hub, изменить его и отправить новую версию. Каждый новый контейнер создается из базового образа, указанного в файле docker-compose.yml или Dockerfile. Поскольку Docker скрывает среду контейнера от операционной системы, вы можете использовать определенную версию библиотеки или языка программирования, не конфликтуя с версией в системе.

Docker Volumes

В файле docker-compose каждая служба имеет свойство под названием «тома». В Docker «тома» — это средства работы с постоянными данными. Различные контейнеры могут получить доступ к одним и тем же «томам» в файле компоновки докеров, для службы Nginx мы используем свойство «volumes_from», чтобы сообщить контейнеру Nginx, что он должен получить доступ к томам WordPress.

Тома можно использовать совместно, когда нескольким контейнерам на разных серверах требуется доступ к одним и тем же данным. Вот почему используется «volumes_from». Docker будет управлять томами за нас.

Зеркальный регистрационный центр

До сих пор мы обсуждали образы и контейнеры — два фундаментальных компонента архитектуры Docker. Но вам может быть интересно, где все эти изображения? В нашем примере приложения все контейнеры взяты из стандартных образов Docker Hub. ЭтоNginx,Wordpress,MySQLСсылка на базовое зеркало для .

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

Теперь мы обсудили все три компонента — контейнер, образ и реестр. Архитектура Docker также включает в себя другие важные компоненты — пространства имен, контрольные группы и файловую систему Union (UnionFS). Пространства имен позволяют нам отделять контейнеры друг от друга, они не могут получить доступ к состоянию друг друга, контрольные группы необходимы для управления аппаратными ресурсами в контейнерах, а федеративные файловые системы создают строительные блоки для контейнеров.

Эти дополнительные компоненты на самом деле не созданы Docker. Они были доступны в контейнерах Linux задолго до Docker. Docker просто использует ту же философию в управлении контейнерами.

Мы рассмотрели много новых концепций, давайте подытожим:

Файлы Docker содержат важные инструкции о том, как работают образы Docker, используемые для создания контейнеров.
У каждого микросервиса должен быть отдельный Dockerfile, содержащий инструкции для каждого образа.
Контейнеры Docker всегда создаются из определенного образа Docker (так Docker сохраняет согласованность в разных средах).
Чтобы создать или удалить контейнер, команды Docker должны выполняться с использованием интерфейса командной строки Docker. Docker можно управлять только с помощью интерфейса командной строки Docker, так как встроенный пользовательский интерфейс отсутствует.
Вы можете использовать готовые образы Docker из общедоступных репозиториев, таких как Docker Hub, и изменять конфигурацию этих образов в соответствии с вашим приложением.
Все микросервисы должны быть зарегистрированы в файле docker-compose.

Масштабирование архитектуры приложений на основе микросервисов с помощью Docker

Приложение, представленное в примере, можно легко расширить с помощью других сервисов. Предположим, мы хотим кэшировать ответы. Создайте сервис под названием Varnish. Varnish поможет нам кэшировать часто запрашиваемые HTML-страницы, изображения, файлы CSS и JavaScript. Обновленное приложение выглядит так:

Вот файл Docker Compose с добавленным сервисом Varnish:

version: '2'

services:
  varnish:
    build: varnish
    ports:
      - 80:80
    depends_on:
      - nginx

  nginx:
    build: nginx
    restart: always
    volumes_from:
      - wordpress

  wordpress:
    image: wordpress:php7.1-fpm
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_PASSWORD: example
    depends_on:
      - mysql

  mysql:
    image: mariadb
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes:
      - ./demo-db:/var/lib/mysql

Нужно добавить сервис в файл docker-compose.yml, настроить и указать порт. Если вы больше не хотите использовать Varnish, просто удалите его из docker-compose и обновите конфигурацию. можно посмотреть на GitHubsimple WordPress containeпроект.

Это почти все, что нам нужно знать об управлении контейнерами с помощью Docker. Однако меня все еще беспокоит один вопрос: как нам управлять тысячами контейнеров Docker на таком количестве серверов? Последний подраздел ответит на этот вопрос.

Управление приложениями на базе Docker с помощью Container Orchestration (CO)

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

Система координации контейнеров является дополнительным инструментом. До середины 2016 года Docker не позволял управлять тысячами микросервисов. Но теперь с Docker Swarm, встроенной структурой координации контейнеров.

В Docker появился специальный режим — режим роя, который можно использовать для управления кластерами контейнеров. Docker Swarm позволяет запускать команды swarm с помощью интерфейса командной строки Docker, упрощая инициализацию группы контейнеров и добавление или удаление контейнеров из группы. Помимо Docker Swarm, есть еще несколько менеджеров координации контейнеров:

Kubernetes, менеджер кластера контейнеров. Может работать на собственном сервере или в облаке.
Специальный проект DC/OS предоставляет расширенный пользовательский интерфейс для управления контейнерами Docker.
Nomad Project, программное обеспечение для развертывания и управления приложениями, работающее на Amazon ECS, DigitalOcean, Azure Container Service или Google Cloud Platform.

Если вас интересуют облачные решения, обратите внимание на следующее:

Google Cloud Platform поддерживает Kubernetes. Существует также облачный менеджер на основе Kubernetes под названием Google Container Engine.
Amazon ECS, Amazon Web Services может запускать контейнеры Docker и управлять ими с помощью сервиса Elastic Compute Cloud (EC2).
Служба контейнеров Azure похожа на Amazon ECS и поддерживает такие платформы, как Kubernetes, DC/OS с Mesos и Docker Swarm.

Хотя все эти облачные решения позволяют запускать контейнерные приложения, у каждого из них есть свои нюансы. Google Cloud Platform специально создана для Kubernetes, а Azure Container Service может работать с Kubernetes, DC/OS или стандартным Swarm Docker. Amazon ECS — это скорее сервисная платформа: она автоматически масштабирует контейнеры Docker и управляет ими.

Использование микросервисов и контейнеров рассматривается как современный способ создания масштабируемых и управляемых веб-приложений. Если вы не контейнеризуете свои микросервисы, вы столкнетесь со многими трудностями при их развертывании и управлении. Вот почему мы используем Docker: чтобы избежать проблем при развертывании микросервисов. Добавьте систему оркестровки контейнеров, и вы сможете управлять своими контейнерными приложениями без ограничений.