Повышение производительности диска в среде контейнера разработки с помощью именованных томов
Что такое контейнеры VS Code Dev?
Удаленные контейнеры Visual Studio Code - это расширение VS Code, которое решает одну из старейших проблем разработки программного обеспечения: Но оно работает на моей машине. Контейнеры Dev также позволяют сократить разрыв между средой разработки и производственной средой, что значительно упрощает отладку производственных проблем.
Если на вашем компьютере установлены Docker и VS Code, вы можете легко настроить свои проекты с помощью файла Dockerfile и файла devcontainer.json. С помощью расширения контейнера разработчика VS Code может открыть рабочую область вашего проекта в изолированной среде со всеми зависимостями, определенными в файле Dockerfile. Таким образом, любой, кто клонирует репозиторий, сможет запустить точно такую же среду разработки - независимо от того, какую операционную систему хоста он использует.
Проблемы с производительностью в Windows
К сожалению, при запуске контейнеров разработки в Windows возникают проблемы с производительностью. В некоторых случаях мне даже не удавалось запустить npm install, чтобы установить необходимые зависимости пакетов для моих проектов. Докер просто зависнет. Для проектов, у которых было меньше зависимостей, установка зависимостей по-прежнему занимала намного больше времени, чем когда я разрабатывал на своем MacBook Pro или даже загружал Linux на том же ПК. Это определенно не было проблемой с оборудованием.
Оказывается, это на самом деле кажется хорошо известной проблемой при запуске контейнеров разработчика в Windows, поскольку документация VS Code дает советы по повышению производительности диска контейнера. В нем конкретно упоминается node_module и указывается на использование именованных томов для решения проблемы.
Вот что они предлагают вам включить в devcontainer.json файл:
Это действительно решает проблему. Вот один из моих небольших проектов до и после создания именованного тома:
Как видите, это резко увеличивает производительность. Я не совсем уверен, в чем заключается основная проблема, но это может быть связано с тем, как Docker Desktop работает в Windows.
WSL2 еще не решает эту проблему
В Windows Docker Desktop до сих пор полагался на то, что по сути является эмулятором - запуск Docker внутри виртуальной машины. С появлением Подсистемы Windows для Linux 2 Linux гораздо глубже интегрирован в экосистему Windows, поэтому производительность файловой системы была значительно улучшена наряду с другими улучшениями производительности.
К сожалению, похоже, что улучшенная производительность файловой системы действительно применима только к файлам, которые хранятся в самой файловой системе Linux, поскольку файловая система Windows по-прежнему монтируется как удаленная файловая система в WSL2. Я очень сильно полагаюсь на файловые наблюдатели для перезагрузки в реальном времени, но, к сожалению, Docker под WSL2 не имеет надлежащей поддержки для этого.
По крайней мере, на данный момент я отключил WSL2 в Docker Desktop, пока эта проблема не будет решена.
Использование именованных томов в нескольких проектах
Как оказалось, именованные тома являются глобальными и могут совместно использоваться контейнерами. В некоторых случаях это может быть полезно, но я хотел изолировать свои среды друг от друга.
Я наткнулся на переменную среды с именем localWorkspaceFolderBasename, которая по сути позволяет мне определять имя тома на основе папки локальной рабочей области (т.е. имени проекта):
Следует отметить несколько моментов, связанных с именованными томами: перестройка контейнера не повлияет на них, но вы также не сможете удалить папку из-за способа их монтирования.
Например, если вы используете rm -rf node_modules, вам следует использовать rm -rf node_modules/*. Это удалит все файлы в папке, не пытаясь удалить саму папку.
Также стоит отметить, что если ваш проект компилирует какие-либо выходные данные сборки, вы, вероятно, можете улучшить скорость сборки, настроив для них именованные тома.
Заключение
Контейнеры Dev чрезвычайно мощны, и я настоятельно рекомендую их использовать. Однако, когда я переключился с разработки на моем MacBook Pro на свой ПК с Windows, я определенно не ожидал, что у меня возникнут серьезные проблемы с производительностью. Пока я не нашел обходной путь именованных томов, я почти прибег к установке Linux на отдельный SSD, чтобы обойти эту проблему.
Если вы используете контейнеры для разработчиков в Windows, надеюсь, этот совет окажется для вас полезным. Если вы еще не знали об этом трюке, мне бы хотелось узнать, насколько он улучшил производительность вашего рабочего пространства.
