Вот простой пример из реальной жизни: у разработчиков Федора,
на продакшене CentOS. Баги у первых не воспроизводятся, но присутствуют на центосе из-за разных версий зависимостей (версии системных либ, и, вы будете удивлены, проект на питоне, но проблема всё же во внешних непитоновых зависимостях).Как тут девелопить и дебажить? Юзать центос на десктопе как-то никто не хочет, да и админы, ответственные за рабочие станции, говорят что это плохая идея. Поднимать целую VM не вижу смысла, тем более, это неудобно даже с тем же "упрощающим разработку" Vagrant – не ясно как синхронизировать рабочий каталог в две стороны, да так, чтобы файлы оставались доступными из хоста когда VM остановлена.
Доцкер эту проблему успешно решает. Во время разработки каталог с кодом монтируется волюмом в контейнер и позволяет делать то что нам нужно (бесшовная двусторонняя синхронизация без задержек, т.к. по сути это mount в пределах локальной ФС). Во время сбокри имиджа волюм не используется, а производится чистый git clone всего из репы, куда выкладывается уже готовый код. Имидж собираем сами из того же центоса. А коль уж у нас есть самособранный имидж, куда мы самостоятельно прописали зависимости, и он по максимуму воспроизводит окружение, которое уже есть на проде (который пока ещё без всяких контейнеров), то почему бы эти имиджи не выкатывать сразу на прод вместо ручной установки и настройки всего? Ведь это и так приходится делать во время разработки, почему бы не использовать уже однажды настроенное. Само собой, это позволит оттестировать на машине разработчика не только обновление нашего приложения, а и системного окружения.
Из приятных бонусов это даёт возможность развернуть несколько инстансов для разных нужд (один исполняет только внутренние задачи, другой обслуживает клиентов по http, третий тоже и т.д.) одинаково легко хоть на одной машине, хоть на разных, благо отдельно стоящая БД это позволяет. Так можно было и раньше используя несколько обычных машинок (физических или VM) и какой-нибудь Ansible, но тут профит в том, что контейнер стартует моментально после скачивания имиджа, и не надо ждать пока yum всё поставит. Если машин много, то надо ждать установки и переконфигурации каждой, а в случае с контейнерами достаточно дождаться скачивания имиджа и пересоздания контейнера на нём. При использовании инкрементальных обновлений (т.е. слоёв, базирующихся на предыдущем выкаченном имидже) это происходит очень быстро.
Насчёт оверхеда – его мало в плане цпу и памяти, ведь не используется виртуализация и своё ядро (и да, в плане изоляции это минус). В плане дискового оверхеда – если грамотно собирать имиджи (правильно формировать слои), то он получается небольшой благодаря переиспользованию нижележащих слоёв (если есть три имиджа, которые базируются на четвёртом, то на диске окажется лишь один экземпляр четвёртого).
