06.07.2025 11:13
Rilkener 22 6400 Источник

Предисловие

Иногда нужно запустить nvim на старом сервере. Но тут сразу куча проблем: одно не поставить, другое не собрать, а если что-то обновить — можно развалить весь проект.

Этот подход удобен и для новых систем. Docker позволяет поднять nvim с последним Python, nvim-treesitter и своим конфигом прямо в контейнере, не засоряя основную ОС.

При этом можно редактировать локальные файлы на сервере так, как будто nvim установлен на самой системе. В статье показано, как всё это запустить на CentOS 7.
А если заработало там — значит, на любом современном Linux тем более проблем не будет.

Установка и запуск докера

Можно пропустить, если у вас и так есть докер или у вас не centos.

Мне пришлось для установки пакетов обновить /etc/yum.repos.d/CentOS-Base.repo - на столько все там было уже мертво. Далее я поставил докер:

sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager  --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo systemctl start docker
sudo systemctl enable docker

Просто hello-world контейнер тоже поставил, чтобы убедиться, что докер работает: 

sudo yum install -y docker-ce docker-ce-cli containerd.io

Запустил sudo docker run hello-world увидел там Hello from Docker! Значит все ок. Можно ехать дальше.

Я еще добавил своего юзера в группу, чтобы можно было без sudo запускать всё хозяйство: sudo usermod -aG docker $USER и от лица своего юзера newgrp docker

Подготовка завершена. Можно теперь создать контейнер для nvim и попробовать с его помощью начать редактировать код на нашем стареньком Centos.

Контейнер для neovim с готовой сборкой AstroNvim

AstroNvim
AstroNvim

Создал папочку

mkdir ~/devcontainer
cd ~/devcontainer

И положил туда файл Dockerfile с таким содержимым

Dockerfile Astro
FROM ubuntu:22.04

# Обновляем и ставим все зависимости
RUN apt update && apt install -y \
    ninja-build gettext cmake unzip curl git \
    python3 python3-pip python3-venv \
    nodejs npm \
    ripgrep fzf

# Устанавливаем свежий Neovim из исходников
RUN git clone https://github.com/neovim/neovim.git /tmp/neovim && \
    cd /tmp/neovim && \
    git checkout stable && \
    make CMAKE_BUILD_TYPE=Release && \
    make install

# Python и Node tooling
RUN pip3 install --upgrade pip pynvim
RUN npm install -g pyright typescript typescript-language-server

# Создаем пользователя и директории для конфига
RUN useradd -ms /bin/bash dev
USER dev
ENV HOME=/home/dev
WORKDIR /home/dev

# Гарантируем создание .config
RUN mkdir -p /home/dev/.config

# Клонируем AstroNvim template и core в явные пути
RUN git clone https://github.com/AstroNvim/template /home/dev/.config/nvim && \
    git clone https://github.com/AstroNvim/AstroNvim /home/dev/.config/nvim/lua/astro

# Headless установка плагинов AstroNvim
RUN NVIM_APPNAME=nvim nvim --headless "+AstroUpdate" +qa

CMD ["bash"]

Я в данном случае добавил туда просто готовую сборку AstroNvim со всеми пирогами.

Собрал контейнер

docker build -t astro-nvim-dev .

И запустил командой

docker run -it \
  -v /home/you/project:/home/dev/project \
  astro-nvim-dev

И вот здесь /home/you/project — путь к директории с моим кодом, который я хочу на старом CentOS редактировать.

Контейнер запустил. Далее я ввел команду nvim и увидел:

Астра готова к работе
Астра готова к работе

Нажал f увидел весь свой код в fzf на centos 7. Всё работает!

Контейнер для neovim со своим nvim-конфигом

В основном все же хочется свой собственный конфиг nvim-а подгружать, а не юзать готовые сборки. Тут еще проще. Создаем папочку и заходим:

mkdir ~/devcontainer-my-conf
cd  ~/devcontainer-my-conf

Кладем туда файл с таким именем и содержимым:

Dockerfile
FROM ubuntu:22.04

# Обновляем систему и ставим всё для сборки Neovim
RUN apt update && apt install -y \
    ninja-build gettext cmake unzip curl git \
    build-essential

# Собираем последний Neovim
RUN git clone https://github.com/neovim/neovim.git /tmp/neovim && \
    cd /tmp/neovim && \
    git checkout stable && \
    make CMAKE_BUILD_TYPE=Release && \
    make install

# Ставим Python и pynvim
RUN apt install -y python3 python3-pip && \
    pip3 install --upgrade pip && \
    pip3 install pynvim

# Ставим Node и LSP
RUN apt install -y nodejs npm && \
    npm install -g pyright typescript typescript-language-server

# Добавляем ripgrep и git для удобства
RUN apt install -y ripgrep git

# Создаём юзера
RUN useradd -ms /bin/bash dev
USER dev
WORKDIR /home/dev

CMD ["bash"]

Собираем:

docker build -t my-dev-nvim .

И далее запускаем: 

docker run -it \
        -v /home/user/www/my_app:/home/dev/www/my_app \
        -v /home/user/.config/nvim:/home/dev/.config/nvim \
        -v /home/user/.local/share/nvim:/home/dev/.local/share/nvim \
        -v /home/user/.cache/nvim:/home/dev/.cache/nvim \ 
        my-dev-nvim

Первый путь /home/user/www/my_app — это папка с кодом на хосте, которую нужно редактировать. /home/dev/www/my_app — путь к этой же папке внутри контейнера.

Второй путь /home/user/.config/nvim — папка с конфигурацией nvim, подключаемая в Docker для работы в том же окружении, что и на хосте.

Третий путь используется для хранения установленных пакетов nvim, а последний — для кеша, чтобы он не сбрасывался при каждом запуске контейнера.

Скорость работы. Что мы теряем?

Запуск Neovim и LSP внутри Docker — вполне жизнеспособный путь. Это не будет “тупить” значительно, по сравнению с локальной установкой:

  • Docker использует изоляцию на уровне ядра, почти без накладных расходов на производительность.

  • На r/neovim народ пишет, что "не так много overhead при запуске процесса в namespace". Короче, docker-daemon добавляет немного, но ничего критичного

Заключение

Все что осталось, это прописать алиас в ~/.bashrc, чтобы запускать nvim одной командой в консоли.

Для Астры:

alias av='docker run -it \
  -v /home/user/www/my_app/:/home/dev/project \
  astro-nvim-dev  nvim'

И для своей сборки: 

alias v='docker run -it \
        -v /home/user/www/my_app:/home/dev/www/my_app \
        -v /home/user/.config/nvim:/home/dev/.config/nvim \
        -v /home/user/.local/share/nvim:/home/dev/.local/share/nvim \
        -v /home/user/.cache/nvim:/home/dev/.cache/nvim \ 
        my-dev-nvim'

Применяем изменения source ~/.bashrc и запускаем Астру командой: av, а свою собственную сборку командой v.

Всё, можно пользоваться.

P.S.

LazyVim
LazyVim

А напоследок — готовый Dockerfile для LazyVim, который сейчас тоже очень модный и современный.

Dockerfile
FROM ubuntu:22.04

# Устанавливаем все зависимости
RUN apt update && apt install -y \
    ninja-build gettext cmake unzip curl git \
    python3 python3-pip python3-venv \
    nodejs npm \
    ripgrep fzf

# Устанавливаем Neovim последней стабильной версии
RUN git clone https://github.com/neovim/neovim.git /tmp/neovim && \
    cd /tmp/neovim && \
    git checkout stable && \
    make CMAKE_BUILD_TYPE=Release && \
    make install

# Устанавливаем Python tooling
RUN pip3 install --upgrade pip pynvim

# Устанавливаем Node tooling и LSP
RUN npm install -g pyright typescript typescript-language-server

# Создаём пользователя
RUN useradd -ms /bin/bash dev
USER dev
ENV HOME=/home/dev
WORKDIR /home/dev

# Создаём папку для конфигов
RUN mkdir -p /home/dev/.config

# Клонируем LazyVim template
RUN git clone https://github.com/LazyVim/starter /home/dev/.config/nvim

# Выполняем headless init чтобы установить все плагины
RUN nvim --headless "+Lazy! sync" +qa

CMD ["bash"]

Собирается он точно так же, как сборка с AstroNvim.

Комментарии (22)


  1. olgir
    06.07.2025 14:54
    #28535606

    А вы знаете толк и взвращениях!


  1. sperson
    06.07.2025 14:54
    #28535636

    Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.


    1. pcdesign
      06.07.2025 14:54
      #28535906

      sh <(curl -L https://nixos.org/nix/install), потом home-manager, потом сборка environment (а это тянет store и может качать 1–2 ГБ, особенно если много нестандартного).

      С Docker всё быстрее: docker build кешируется, rebuild разных сборок происходит моментально и без дубликатов.

      По производительности — она одинаковая. Можно даже microbenchmark запустить и убедиться.

      Возможно для каких-то долгоиграющих или mission-critical систем я бы действительно выбрал nix. Трудно сказать.

      Спасибо за коммент :)


      1. jbourne
        06.07.2025 14:54
        #28539156

        Тоже тут склоняюсь в сторону Docker хотя бы потому, что более обкатаный вариант и меньше всего грузить нужно.

        Но пару раз видел у ThePrimeagen, что он бы хотел дать шанс и попробовать nix для этого (не помню в каком видео). Типа может быть легковесней и быстрее.


  1. 13werwolf13
    06.07.2025 14:54
    #28536200

    Иногда нужно запустить nvim на старом сервере. Но тут сразу куча проблем: одно не поставить, другое не собрать

    поэтому мы запускаем nvim локально открывая файлы по ssh и не занимаемся фигнёй с установкой docker и запуском в нём контейнеров.

    а если что-то обновить — можно развалить весь проект.

    а вообще если у вас в проде такое то скажите где вы работаете чтобы я избегал пользоваться услугами этой конторы..


    1. Rilkener Автор
      06.07.2025 14:54
      #28536486

      Да, открывать файлы по ssh и запускать nvim локально — это удобно, когда нужен просто редактор.

      Но если проект требует LSP, линтеров, сборок — то серверное окружение (gcc, system includes, venv, специфические пакеты) должно совпадать.

      Запуская nvim локально через scp://, ты получаешь autocomplete и проверки на своей машине, которые могут отличаться от того, что есть на сервере.

      Поэтому docker здесь — не про «фигню», а про то, чтобы поднять точную среду сборки и анализа прямо на сервере, и получать LSP-диагностику ровно под ту систему, где это реально работает.

      Остальное - это эмоции.


      1. ugenk
        06.07.2025 14:54
        #28537514

        Вроде как раз докер придумали для того что бы на локальном комрьютере разработчика получать такую же среду, как и на продуктовом сервере


        1. Rilkener Автор
          06.07.2025 14:54
          #28537534

          Просто в моём случае он нужен на сервере. Одно другому не мешает.


  1. dim0xff
    06.07.2025 14:54
    #28536660

    Я не понял один момент (или невнимательно прочёл): почему не передаёте айдишники пользователя внутрь контейнера? Вы ведь не сможете сохранять локальные файлы, если айдишники пользователя внутри контейнера и снаружи отлючаются. Или у вас там 666 по умолчанию?


    1. pcdesign
      06.07.2025 14:54
      #28536728

      .


    1. Rilkener Автор
      06.07.2025 14:54
      #28536740

      Да, всё верно, по-хорошему стоило бы сразу добавить -u $(id -u):$(id -g), чтобы uid/gid совпадали и файлы создавались с нужными правами. Что-то вроде: 

      docker run -it -u $(id -u):$(id -g)

      В моём случае я для статьи просто поленился это прописывать — хотел сосредоточиться на nvim в docker. Но да, для «боевого» сценария с общей рабочей папкой или CI это было бы правильнее.


  1. Soulskill
    06.07.2025 14:54
    #28537598

    На старом сервере работает просто vim. пулишь из своей репы .vimrc (старый можно сохранить чтобы откатить) апдейтиш плагины и все работает. И не надо ещё допом тянуть докер и засирать систему ещё одним контейнером на пару гигов (поработай на одноплатниках с максимальным объемом в 32гб поймёшь боль)


    1. Rilkener Автор
      06.07.2025 14:54
      #28537620

      Когда нужен просто старый vim — тогда  хватает старого .vimrc, без докера и LSP.

      Иногда  нужен современный Neovim с LSP, treesitter и прочими фишками прямо на сервере, где локальная среда важна (тот же gcc, venv, include headers).

       

      А одноплатники тут вообще не при чём — задача не в том, чтобы экономить, а чтобы получить определенную dev-среду.

       

      Старый vim я и так могу поднять за 5 минут с git clone .vimrc. Но когда нужен современный nvim с lua + LSP — проще кинуть в докер.

      Вот и все дела. Ничего тут нет особенного.


      1. Soulskill
        06.07.2025 14:54
        #28538218

        А что на счёт sshfs? Локально можно настроить любую среду. И что самое важное сервер ничего лишнего не увидит.


        1. Rilkener Автор
          06.07.2025 14:54
          #28538264

          https://habr.com/ru/articles/696700/

          • Очень медленный

          • Когда LSP обращается к удаленным модулям, чтобы считать, то беспощадно тупит


          1. Rilkener Автор
            06.07.2025 14:54
            #28538418

            От себя добавлю. sshfs для LSP — это боль: он бесконечно тормозит, treesitter и autocompletion умирают на latency.

            Плюс, если на одном сервере python 3.2, а на другом 3.10 — локально придётся держать весь зоопарк, чтобы LSP / linters совпадали.

            А так запускаешь docker прямо на сервере, и получаешь точно ту среду, в которой реально работает код — без костылей. Сразу же.


  1. jbourne
    06.07.2025 14:54
    #28539142

    Я бы на сервере такое вот не разворачивал. Но что бы иметь на девелоперской машине легко воссоздаваемое одинаковое окружение - нормальный вариант. Думал тоже пару раз такое сделать. Ваш опыт интересен и статья хорошая.

    Вопрос: задержка, что с ней? Вы написали кратко, но ее заметно по сравнению с нативным вариантом по вашим ощущениям? Как то можете оценить? (понимаю что это сложный вопрос).


    1. Rilkener Автор
      06.07.2025 14:54
      #28539190

      Спасибо, рад что статья полезна.

      По задержке могу сказать так: на Linux разницы почти нет, потому что Docker использует тот же kernel, только в отдельных namespaces.

      Я делал microbenchmark запуска Neovim (nvim --headless +qall) — получалось ~0.0170s нативно и ~0.0172s в docker, то есть разница <1%, что полностью в рамках погрешности.

      На глаз и по ощущениям (открытие файлов, LSP hints, Telescope) тоже одинаково.

      Так что на Linux это почти «натив», зато плюс: среда всегда повторяемая и можно быстро rebuild для другой конфигурации.


  1. FSA
    06.07.2025 14:54
    #28539530

    А почему докер? Для CentOS роднее Podman. К тому же у него нет постоянно работающего демона. Запускать подобные штуки через него лучше.


    1. Rilkener Автор
      06.07.2025 14:54
      #28539570

      Согласен, podman для CentOS/RedHat-дистров роднее и no-daemon у него круто реализован.

      Тут docker просто уже стоял (исторически на CentOS 7 так чаще), а для задач типа dev-containers они почти одинаковы, тем более CLI совместим.

      Но есть нюанс: образ с моей сборкой nvim можно легко забрать через docker save и кинуть на другой сервер (через docker load), и он там сразу заработает в том же виде.
      С podman это чуть сложнее для mix-инфраструктуры.


  1. Roman_Cherkasov
    06.07.2025 14:54
    #28539642

    С каждым днём мы все дальше от Бога.... (Статью плюсанул. Может быть даже когда-нибудь пригодится)


    1. Rilkener Автор
      06.07.2025 14:54
      #28539748

      Спаси Господи!