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