Введение в контейнерные приложения с Docker

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

Краткий урок истории

Поколение 1

Лет пять-шесть назад наши приложения должны были быть развернуты на физическом сервере. Вы можете спросить, сейчас мы тоже делаем то же самое, но что изменилось. Представьте, что у нашего приложения 3 слоя. Уровень на стороне клиента, который будет использоваться клиентом, бизнес-логика или серверная часть, которая выполняет основные процессы, и, наконец, уровень базы данных, который мы используем для хранения данных. Если мы хотим реализовать этот тип системы на веб-архитектуре, мы использовали 3 отдельных веб-сервера (физические машины) для размещения 3 уровней / компонентов. Это само по себе принесло много недостатков.

В целом физическая коробка предназначена для одного компонента, много памяти и вычислительная мощность тратятся впустую. (Он не использует 100% физической мощности коробки)
Нам нужно иметь отдельные сетевые подключения для каждого из наших серверов.
Нам нужно купить и иметь лицензию на операционную систему, на которой будет работать сервер.
Стоимость будет высокой, так как мы покупаем более 1 ОС и физических устройств для размещения нашего приложения.
Техническое обслуживание сложно, так как нам нужно заботиться о 3 отдельных серверах.

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

Поколение 2 (гипервизор)

Некоторые люди называют это поколением виртуальных машин, но это не так, как следует называть. Это следует назвать генерацией гипервизора. В этом поколении мы по-прежнему размещаем наше приложение в Интернете, но вместо того, чтобы иметь разные физические машины для разных компонентов, мы будем размещать компоненты на одной физической машине с помощью гипервизора. Гипервизор - это монитор виртуальных машин (VMM), программное обеспечение, помогающее создавать и запускать виртуальные машины (ВМ). Посмотрите на диаграмму ниже.

Как видно из приведенной выше диаграммы. Мы возьмем мощную аппаратную машину, а затем установим на нее гипервизор. А затем с помощью гипервизора мы сможем создавать виртуальные машины, на которых будут работать наши приложения. Как показано на приведенной выше диаграмме, каждая виртуальная машина может иметь свою собственную ОС и размещать наше приложение. В примере, который я привел в поколении 1, мы можем реализовать все приложение на одной машине и иметь запасную вычислительную мощность для работы. Имея дополнительное пространство, мы можем запускать прокси или балансировщик нагрузки для нашего приложения.

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

Стоимость лицензии на используемую нами операционную систему. (Конечно, не Linux 😅)
Предстоит проделать большую управленческую работу. Нам нужно исправить и обновить каждую из операционных систем, работающих на виртуальной машине.
Запуск виртуальной машины - это не быстрый процесс, нам нужно загрузить операционную систему, что займет некоторое время.
Если мы хотим создать новую виртуальную машину, нам нужно получить лицензию на новую ОС и проделать большую работу по настройке. Эта работа по настройке - это не 2 часа 3 часа работы, на создание и запуск новой виртуальной машины уходит много времени. (Образы ВМ могут сократить время на установку новой ВМ.)

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

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

Контейнерные приложения

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

Как показано на диаграмме выше, наш контейнер будет поверх операционной системы. И мы будем создавать контейнеры, которые будут создавать и запускать наше приложение. Наличие только одной ОС дает несколько преимуществ;

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

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

Примечание. Контейнерный движок будет объяснен, когда я расскажу о докере.

Докер

Docker был создан в 2010 году компанией dotCloud как внутренний проект. Этот проект был создан при сотрудничестве Docker inc и получил название Docker. Он был выпущен примерно в 2013 году как проект с открытым исходным кодом, поддерживаемый лицензией Apache 2.0. Несмотря на то, что Docker inc является основным игроком в создании Docker, он по-прежнему является проектом с открытым исходным кодом и не принадлежит Docker inc. Докер был создан с использованием языка программирования Google Go. Посмотрите на изображение ниже, чтобы увидеть архитектуру Docker.

Так будет нормально работать Docker. Клиент - это то место, где мы запускаем команды на стороне клиента, которые будут отправлены демону докера, который находится на стороне сервера. Демон докера будет выполнять тяжелую работу по запуску процессов. Реестр - это часть, где хранятся образы Docker. Эти процессы будут выполняться с помощью движка докеров (реестр и образ будут объяснены ниже).

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

Docker Engine (Контейнерный движок)

Движок Docker - это не проект докера. Это часть проекта докера. Как я уже сказал ранее, вышеупомянутые компоненты, а также безопасность и оркестровка построены вокруг движка докеров. Давайте взглянем на некоторые важные компоненты.

Реестр

Реестр - это место, откуда мы получаем изображения Docker для создания контейнеров Docker. Мы можем создать наш собственный частный реестр или использовать публичный реестр для хранения и извлечения наших изображений. Некоторые из наиболее часто используемых общедоступных реестров:

Докер Хаб
Реестр контейнеров Google
Реестр контейнеров Amazon EC2

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

Примечание. Самый большой и наиболее часто используемый реестр докеров на рынке - это Docker Hub. Существует более 250 тысяч репозиториев, созданных пользователями, к которым можно получить доступ из концентратора докеров.

Картинки

Некоторым из вас, должно быть, интересно, что это за изображение, о котором я говорю, это какой-то файл в формате jpg или mpeg. Сожалею, что разочаровываю вас, говоря, что изображение означает файл с инструкциями по созданию контейнера. Изображения похожи на шаблон. Мы можем взять их и использовать прямо из коробки или изменить конфигурацию в соответствии с нашими требованиями. Это просто делается путем создания файла докера.

Примечание. Эти образы делают докеры (контейнеры) быстрее, чем гипервизоры. Если мы изменим некоторые строки в нашем файле докеров, будут восстановлены только изменения. Не все изображение.

Оркестровка

В реальном оркестре есть парень, который будет махать палочкой. Музыканты будут играть по его приказу. Точно так же приложение, которое мы создаем, может иметь множество служб в отдельных контейнерах. Затем этим контейнерам может потребоваться общаться друг с другом, обмениваться данными и работать вместе, чтобы достичь более крупной цели. Для этого, как и в реальном оркестре, нам понадобится кто-то, кто справится с этой сложной задачей. Микроуправление этой задачей - оркестровка.

Если мы рассмотрим монолитное приложение, мы будем упоминать все зависимости и какой компонент должен взаимодействовать с каким. Но когда мы используем докеры, каждая служба создается в изолированной среде. Таким образом, оркестровка - это процесс, который поможет нам определить, что идет первым, каковы зависимости и маршрут, по которому сервисы должны следовать для достижения цели.

Инструменты, которые помогают нам в оркестровке, известны как оркестраторы. На рынке представлены два оркестратора с открытым исходным кодом;

Kubernetes: предоставлено Google

Docker Swarm: предоставляется Docker Project.

Примечание. Чтобы узнать больше об оркестровке, щелкните здесь.

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

Ключевые моменты о докерах

Постоянство Docker: некоторые программисты думают, что Docker не является постоянным. Постоянный означает, что при выключении и перезапуске докера все сделанные нами изменения будут потеряны. Это полностью ложное заявление. Так же, как виртуальные машины сохраняют свою конфигурацию после перезапуска, докеры также сохранят свою конфигурацию и данные после перезапуска, что означает, что докер ПРОДОЛЖАЕТСЯ.
Переход на Docker. Программисты могут сказать, что Dockers предназначены только для новых приложений, а не для устаревших приложений. Это может быть истина или ложь в зависимости от ситуации. Когда мы перешли с 1-го поколения на 2-е (ВМ), мы можем просто выполнить миграцию. Но с докерами мы используем более мелкие сервисы, а затем объединяем их вместе для достижения общей задачи (микросервисная архитектура: скоро выйдет статья об этом😉). Например, архитектура, построенная с использованием докеров, будет предоставлять гораздо более полезные услуги, чем старшее поколение. Например, если контейнер выходит из строя, мы можем легко создать новый контейнер с этим изображением и развернуть его. Мы можем переписать и перепроектировать устаревшие приложения в соответствии с этой архитектурой, чтобы получить все функции и преимущества докеров.

Инициатива открытого контейнера

После того, как Docker Inc выпустила проект докера, какая-то компания использовала его. У них были некоторые проблемы с его архитектурой, поэтому они решили внести в нее некоторые изменения и выпустить собственное приложение-поставщик контейнеров, назвав его RKT (круто написано Rocket). Теперь есть две разные структуры, использующие два разных подхода. Таким образом, чтобы иметь стандартизированную структуру на рынке, две стороны пришли к соглашению и начали имитацию открытых контейнеров 2015 июня .

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