Comments 11
Подскажите, чем старый docker compose хуже dev containers?
Тем что не надо ничего делать руками
Это немного разные технологии с разным фокусом: docker compose – средство для запуска и управления контейнерами, dev containers – средство для контейнерной разработки. Да, можно настроить контейнер через docker compose и использовать его для контейнерной разработки, но это будет сложнее. Dev контейнеры уже интегрированы в среду разработки, их использовать проще.
А в чем сложность с docker-compose? Там нельзя прокинуть volume с хоста?
Конечно, можно. Но зачем, если в dev контейнерах это уже автоматизировано?
Что нужно делать с docker-compose: прокидывать volume с хоста, устанавливать расширения, настраивать IDE в контейнере.
Что нужно сделать с dev контейнером: кликнуть на кнопку.
А какие расширения нужно устанавливать?
Зачем настраивать ide в контейнере?
Зависит от того, что вам нужно. Мы, например, используем расширения VS Code для поддержки синтаксиса языка, для удобного взаимодействия с Cmake, для написания документации и поддержки Mermaid и многие другие. Удобно, когда нужное расширение одним кликом можно добавить в контейнер.
А в рамках контейнера, какие вы плагины ставите, которые нельзя поставить в связке ide+docker-compose?
Можно поставить любые расширения в связке ide+docker-compose, но тогда их либо придется ставить внутрь контейнера + vs code туда же, либо, если использовать docker-compose чисто для сборки и билда, расширения придется ставить локально. Dev контейнеры же легко позволяют устанавливать расширения именно в контейнер.
на windows используется в лучшем случае WSL под капотом которого старый добрый Hyper-v. Используете вы скорее всего docker desktop, который в свою очередь требует лицензионного соглашения. Да и в целом он всегда был тормозным и весьма глючным. У себя использую rancher desktop, при прочих равных куда меньше проблем с ним.
https://learn.microsoft.com/en-us/windows/wsl/wsl-config - Стоит почитать по кастомной настройке WSL.
У меня стройкое предубеждение, что докер на windows использует не все ядра с хоста при запуске.
Но в любом случае, существуют накладные расходы на виртуализацию. А еще при долгой работе появляется куча мусора, старые контейнеры, слои, кеши. Виртуальный диск WSL разрастается и с удивлением видим забитый диск C.
Этот плагин же поддерживает работу в удаленной среде, проще завести на вашем гипервизоре виртуалку на Linux с докером. Не нужно будет мощное железо, да регламентную очистку будет проще делать. А то и вообще в кубере запускать.
Dev контейнеры и с чем их едят