Для кого написано
Это уникальная статься про Docker: в ней нет консольных команд, сложных терминов и смс на короткий номер. Я написал ее для тех, кто работает в сфере ИТ, но не является разработчиком или DevOps-специалистом: для менеджеров, аналитиков и дизайнеров.
Был такой мем.
Учимся говорить правильно: не "я в этом почти ничего не понимаю", а "абстракция понятна, в детали реализации не вникал"
Статья как раз поможет разобраться в абстракции под названием "контейнеризация". Попутно вы узнаете, какие проблемы решает Docker. В качестве бонуса вы наконец-то поймете, о чем между собой говорят разработчики и DevOps.
Что такое Docker
Docker – это платформа для разработки, развертывания и запуска приложений в контейнерах. Помимо Docker’а есть и другие платформы контейнеризации.
Чтобы понять, что такое контейнеры и для чего они нужны, нужно понять концепцию виртуальных машин. А для этого необходимо сделать еще один шажок назад во времена «физических» серверов.
В стародавние времена
До появления платформ контейнеризации и виртуализации, разработка велась на обычных физических серверах. Тогда их еще не называли «физическими» – название появилось позднее, чтобы отличать физические сервера от виртуальных.
Давайте пофантазируем: мы разрабатываем более или менее сложное приложение. Прикинем, сколько серверов нам нужно.
Сложная система обычно включала в себя несколько серверов:
- Сервер или сервера баз данных;
- Сервер или сервера Back End – там находится большая часть бизнес-логики работы с данными;
- Сервер или сервера Front End – отвечает за отображение страниц которые вы видите в браузере.
Наличие множества серверов объяснялось несколькими факторами:
- Многие сервисы были реализованы таким образом, что плохо уживались на одном сервере,
- Во время пиковых нагрузок сервисы могли начать потреблять значительно больше ресурсов, чем обычно. Поэтому каждый сервис располагался на сервере с избытком мощностей.
Приложение на физическом сервере в вакууме выглядело с точки зрения эффективности потребления ресурсов примерно так:
Если мы работали над крупным проектом, у нас были отдельные выделенные среды для разработчиков и для пользователей. Это позволяло разработчикам ставить эксперименты без риска того, что пользователи не смогут работать с нашим сервером. Среда разработчиков требовала отдельных серверов.
Типичные проблемы, с которыми сталкивались команды разработки в то время были следующими:
- Нужно много серверов. Их покупка или аренда стоят дорого;
- Каждый сервер обычно использует только 20-30% своих ресурсов, но платим мы за 100%;
- Настройка каждого сервера требует много усилий: нужно установить ОС, настроить конфигурацию под конкретный сервис и т.д.;
- При масштабировании сервиса нужно покупать и настраивать новые сервера;
- Разработчики часто сталкиваются с проблемой, когда на их компьютере все работает, а на сервере нет.
Пока я описывал все проблемы того времени, мне на ум пришла метафора.
Разработка раньше была похода на ситуацию, когда вы заказали в доставке бургер и картофель фри. И сервис доставки направил вам два курьера: первый несет в своем прямоугольном рюкзаке пластиковый контейнер с бургером, другой – тащит картошку. Оба рюкзака почти пустые, доставка стоит дорого, но обед вы все равно получите.
Резюмируя все вышесказанное, разрабатывать во времена физических серверов было дорого и больно. Чтобы избавиться от части этой боли придумали виртуальные машины.
Коробка с коробками
Проведем мысленный эксперимент: представьте большую картонную коробку (как от пылесоса), и поместите в нее несколько коробочек поменьше (от мобильных телефонов).
Если вы смогли такую картинку, то поздравляю вас - вы уже почти разобрались с тем, как работают виртуальные машины. Коробка от пылесоса в данном случае - это обычный физический сервер (также его называют хост). А маленькие коробочки внутри - виртуальные машины.
Если не вдаваться в технические дебри, то виртуальная машина "считает" себя вполне реальной машиной:
- У нее есть своя собственная операционная система. Эта операционная система может отличаться от той, что стоит на хосте (например, на хосте установлен Linux, а на виртуальной машине - Windows);
- У нее свой собственный IP-адрес, не такой, как у хоста;
- У нее свои собственные процессор, память и жесткий диск - она сама того не зная, арендует их у хоста.
Самое замечательное, что на одном хосте может быть сразу несколько виртуальных машин с разными операционными системами, памятью, процессором и так далее.
Теоретически, внутри виртуальной машины можно запустить другие виртуальные машины. На практике это обычно не нужно, но сама возможность поражает.
Еще более интересно, что хостовая машина может динамически распределять ресурсы (например, оперативную память) между виртуальными машинами. Если одной из машин сейчас требуется больше памяти на обработку большого запроса пользователя, а другая - наоборот простаивает, хост выделит первой больше памяти, а второй - меньше. И все это в реальном времени. В результате ресурсы хоста используются более оптимальным способом.
За реализацию функционала виртуальных машин, а также за управление ими отвечает специальная система на хосте - Гипервизор.
При всех своих преимуществах, виртуальные машины имеют ряд недостатков.
Первый и самый главный - каждая виртуальная машина требует отдельной операционной системы. Это операционную систему нужно установить, настроить и поддерживать. Это стоит денег.
Второй недостаток также состоит в том, что у каждой виртуальной машины есть своя операционная система - на ее работу тратятся ресурсы. иными словами, чтобы запустить в виртуальной машине наш сервис, мы должны заложить ресурсы не только на само приложение, но и на работу операционной системы.
Использование ресурсов в мире виртуальных машин выглядит так:
Проводя пищевую аналогию, мы снова заказали бургер и картошку. Курьер стал умнее. В этот раз он взял большой рюкзак и положил в него два рюкзака поменьше: в одном из них лежит картошка, а в другом - бургер. С одной стороны, отпала нужда во втором курьере, с другой - курьер таскает с собой много ненужных рюкзаков.