xD на дворе был 2023, народ интересуется докером спустя ~10 лет массового распространения, когда сам докер загибается. Ну и нужно разделить понятия технологии от конкретного продукта. У докера сейчас достаточно узкая ниша, потому что в современном мире и продакшене он не нужен уже давно, а на рабочих станциях многие предпочитают podman, а кто-то вообще не использует какие-то менеджеры.
Когда-то докер получил массовое распространение, в те времена, когда особых альтернатив не было, да и сам докер использовал LXC. Потом была реализована библиотека libcontainer. Из-за необходимости хоть как-то рулить зависимостями между сервисами и описовать по принципам IaC был реальзован проект (изначально сторонний, на python) примитивный оркестратор docker-compose, который сейчас перетек в поставку самого докера и является частью клишного инструментария. По тем же причинам, в попытке создать что-то подходящее для использование в продакшене был мертворожден на свет swarm (в последствии замененный docker swarm mode). Но все это было достаточно убого.
Затем получил широкое распространение Kubernetes, который использовал докер как среду запуска контейнеров. Продлилось это достаточно долго. Тут нужно помнить, что под всем этим располагается среда запуска, CRI и набор плагинов, реализующих сетевую функциональность, реальзацию хранения данных и пр. K8S использовал дополнительную не нужную прослойку, с говорящим названием Dockershim, которая была посредником в коммуникации с containerd. Но это все задепрекейтили в 1.20 версии куба, более трех лет назад. Потому докер перестал быть нужен вообще. Тут важно понимать, что Kubernetes сейчас это не просто очень функциональная платформа, это стандарт, это единый язык для разработчиков, позволяющий в коде описать весь пайплайн доставки и запуска приложений в продакшене и сейчас этот проект диктует то что будет актуально на ближайшие годы в этом направлении.
Собственно, containerd не единственный, можно посмотреть, например, на CRI-O и другие проекты, реализующие среду запуска и исполнения контейнеров, совместимые с OCI Image specification.
С одной стороны докером все еще можно пользоваться для локальной разработки и каких-то мельких задач по запуску сервисов, не требующих надежности и отказоустойчивости. С другой стороны, если работаете в команде где Kubernetes это основная платформа для запуска приложений, то непременно столкнетесь с ситуацией, когда нужно организовывать локальное окружение, максимально идентичное продовым. Тут появляется ряд новых проблем, из-за ограничений, которые накладывает локальная разработка даже при использовании таких инструментов как kind, minikube, k3s. Но это уже другая история как это обустраивать правильно.
Кмк, если кто-то только заходит в тему контейнеризации, докер должен быть лишь ознакомительной частью, в продакшене его нет и не будет уже. Тут важнее разобраться со OCI, CRI интерфейсом и как это работает. Тут докер может быть сподручным иструментом, но не обязательным.
Ну и вообще еще нужно иметь хорошее представление об этом
https://12factor.net/, а еще массу терпения и желания, потому что темы очень объемные и далько не всегда такие простые, как может показаться.
