Comments 22
А вы знаете толк и взвращениях!
Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.
sh <(curl -L https://nixos.org/nix/install), потом home-manager, потом сборка environment (а это тянет store и может качать 1–2 ГБ, особенно если много нестандартного).
С Docker всё быстрее: docker build кешируется, rebuild разных сборок происходит моментально и без дубликатов.
По производительности — она одинаковая. Можно даже microbenchmark запустить и убедиться.
Возможно для каких-то долгоиграющих или mission-critical систем я бы действительно выбрал nix. Трудно сказать.
Спасибо за коммент :)
Иногда нужно запустить
nvimна старом сервере. Но тут сразу куча проблем: одно не поставить, другое не собрать
поэтому мы запускаем nvim локально открывая файлы по ssh и не занимаемся фигнёй с установкой docker и запуском в нём контейнеров.
а если что-то обновить — можно развалить весь проект.
а вообще если у вас в проде такое то скажите где вы работаете чтобы я избегал пользоваться услугами этой конторы..
Да, открывать файлы по ssh и запускать nvim локально — это удобно, когда нужен просто редактор.
Но если проект требует LSP, линтеров, сборок — то серверное окружение (gcc, system includes, venv, специфические пакеты) должно совпадать.
Запуская nvim локально через scp://, ты получаешь autocomplete и проверки на своей машине, которые могут отличаться от того, что есть на сервере.
Поэтому docker здесь — не про «фигню», а про то, чтобы поднять точную среду сборки и анализа прямо на сервере, и получать LSP-диагностику ровно под ту систему, где это реально работает.
Остальное - это эмоции.
Я не понял один момент (или невнимательно прочёл): почему не передаёте айдишники пользователя внутрь контейнера? Вы ведь не сможете сохранять локальные файлы, если айдишники пользователя внутри контейнера и снаружи отлючаются. Или у вас там 666 по умолчанию?
.
Да, всё верно, по-хорошему стоило бы сразу добавить -u $(id -u):$(id -g), чтобы uid/gid совпадали и файлы создавались с нужными правами. Что-то вроде:
docker run -it -u $(id -u):$(id -g) В моём случае я для статьи просто поленился это прописывать — хотел сосредоточиться на nvim в docker. Но да, для «боевого» сценария с общей рабочей папкой или CI это было бы правильнее.
На старом сервере работает просто vim. пулишь из своей репы .vimrc (старый можно сохранить чтобы откатить) апдейтиш плагины и все работает. И не надо ещё допом тянуть докер и засирать систему ещё одним контейнером на пару гигов (поработай на одноплатниках с максимальным объемом в 32гб поймёшь боль)
Когда нужен просто старый vim — тогда хватает старого .vimrc, без докера и LSP.
Иногда нужен современный Neovim с LSP, treesitter и прочими фишками прямо на сервере, где локальная среда важна (тот же gcc, venv, include headers).
А одноплатники тут вообще не при чём — задача не в том, чтобы экономить, а чтобы получить определенную dev-среду.
Старый vim я и так могу поднять за 5 минут с git clone .vimrc. Но когда нужен современный nvim с lua + LSP — проще кинуть в докер.
Вот и все дела. Ничего тут нет особенного.
А что на счёт sshfs? Локально можно настроить любую среду. И что самое важное сервер ничего лишнего не увидит.
https://habr.com/ru/articles/696700/
Очень медленный
Когда LSP обращается к удаленным модулям, чтобы считать, то беспощадно тупит
От себя добавлю. sshfs для LSP — это боль: он бесконечно тормозит, treesitter и autocompletion умирают на latency.
Плюс, если на одном сервере python 3.2, а на другом 3.10 — локально придётся держать весь зоопарк, чтобы LSP / linters совпадали.
А так запускаешь docker прямо на сервере, и получаешь точно ту среду, в которой реально работает код — без костылей. Сразу же.
Я бы на сервере такое вот не разворачивал. Но что бы иметь на девелоперской машине легко воссоздаваемое одинаковое окружение - нормальный вариант. Думал тоже пару раз такое сделать. Ваш опыт интересен и статья хорошая.
Вопрос: задержка, что с ней? Вы написали кратко, но ее заметно по сравнению с нативным вариантом по вашим ощущениям? Как то можете оценить? (понимаю что это сложный вопрос).
Спасибо, рад что статья полезна.
По задержке могу сказать так: на Linux разницы почти нет, потому что Docker использует тот же kernel, только в отдельных namespaces.
Я делал microbenchmark запуска Neovim (nvim --headless +qall) — получалось ~0.0170s нативно и ~0.0172s в docker, то есть разница <1%, что полностью в рамках погрешности.
На глаз и по ощущениям (открытие файлов, LSP hints, Telescope) тоже одинаково.
Так что на Linux это почти «натив», зато плюс: среда всегда повторяемая и можно быстро rebuild для другой конфигурации.
А почему докер? Для CentOS роднее Podman. К тому же у него нет постоянно работающего демона. Запускать подобные штуки через него лучше.
Согласен, podman для CentOS/RedHat-дистров роднее и no-daemon у него круто реализован.
Тут docker просто уже стоял (исторически на CentOS 7 так чаще), а для задач типа dev-containers они почти одинаковы, тем более CLI совместим.
Но есть нюанс: образ с моей сборкой nvim можно легко забрать через docker save и кинуть на другой сервер (через docker load), и он там сразу заработает в том же виде.
С podman это чуть сложнее для mix-инфраструктуры.
С каждым днём мы все дальше от Бога.... (Статью плюсанул. Может быть даже когда-нибудь пригодится)
Docker + Neovim: поднимаем конфиг на любом сервере и не засоряем систему