Комментарии 15
Подскажите, чем старый 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 контейнеры же легко позволяют устанавливать расширения именно в контейнер.
I/O примонтированного volume гораздо медленнее и неэффективнее, чем простой clone репозитория внутрь контейнера
на windows используется в лучшем случае WSL под капотом которого старый добрый Hyper-v. Используете вы скорее всего docker desktop, который в свою очередь требует лицензионного соглашения. Да и в целом он всегда был тормозным и весьма глючным. У себя использую rancher desktop, при прочих равных куда меньше проблем с ним.
https://learn.microsoft.com/en-us/windows/wsl/wsl-config - Стоит почитать по кастомной настройке WSL.
У меня стройкое предубеждение, что докер на windows использует не все ядра с хоста при запуске.
Но в любом случае, существуют накладные расходы на виртуализацию. А еще при долгой работе появляется куча мусора, старые контейнеры, слои, кеши. Виртуальный диск WSL разрастается и с удивлением видим забитый диск C.
Этот плагин же поддерживает работу в удаленной среде, проще завести на вашем гипервизоре виртуалку на Linux с докером. Не нужно будет мощное железо, да регламентную очистку будет проще делать. А то и вообще в кубере запускать.
Да, действительно используем docker desktop. Посмотрим в сторону rancher desktop, спасибо :)
Попробовали? Если да, то как впечатления? По производительности в сравнении с Docker Desktop пошустрее? Я наоборот на арме (М1) сейчас играюсь с dev контейнерами под проект на x86 с линуксом, впечатления положительные, но компиляция простеньких тулов происходит по времени не очень конечно и разницы по времени компиляции в контейнере, запущенного в ранчере или докере, пока не вижу.
Около года активно использую devcontainers как дома, так и на работе. Devcontainer стал для меня спасением из-за мультиязычности проекта. Сам я Питонист и пишу на Python. периодически мне нужно работать с проектами на java, c++ и js
Плюсы:
Великолепная переносимость. Если devcontainer запустился и собрался у тебя, то скорее всего он соберется где угодно где есть vscode и docker (если вы запускаетесь локально)
Великолепное разделение контекстов. В devcontainer ты собираешь ровно тот набор плагинов, утилит и настроек которые нужны именно для этого стека
Скрипты автоматизации на проекте становятся проще, ты точно знаешь вплоть до отдельного файла что и где у тебя находится, тебе не нужно учитывать разницы операционных систем, у тебя она всегда одинаковая
Ты можешь раскатывать и работать со своим окружением удаленно через Remote SSH или GitHub Workspace и оно везде идентичное. Это оказалось очень удобно особенно если приходится скакать между разными компами.
Несколько вещей которые я извлек для себя пока работал:
Если вы на windows то моунтинг папки в devcontainer это боль и очень медленная работа. Если вы клонируете репозиторий локально то клонируйте его в WSL и запускаетесь от туда. А лучше вообще не клонируйте репозиторий локально а используйте "clone repository in container volume"
Если вам нужны разные утилиты раз от разу, особенно если они занимают кучу места, то лучше использовать эти утилиты через docker, управляя ими находясь же в контейнере (фича docker outside of docker)
Очень удобно когда вы собирайте свой docker контейнер на основе своего docker файла с мультисборкой. Приведу пример для poetry проекта:
FROM python:3.11 as base
# Install poetry
FROM base as devcontainer
# Install dev utils
FROM base as runner
# COPY . .
# Entrypoint.sh
Dev контейнеры и с чем их едят