VS Code Remote SSH и Dev Containers: работа на сервере и в контейнере

Коротко о двух режимах

Оба режима устроены одинаково: интерфейс VS Code остаётся у вас на компьютере, а файлы, терминал, языковые серверы и большинство расширений работают там, где лежит код.

• Remote SSH — код и процессы на удалённом сервере или мощной рабочей машине. Подключение по SSH, на сервер автоматически ставится серверная часть VS Code.
• Dev Containers — код открывается внутри Docker-контейнера. Что в нём установлено, описывает файл devcontainer.json в репозитории.

Режимы можно комбинировать: подключиться к серверу по SSH и уже там открыть проект в контейнере.

Когда что выбирать

Настройка Remote SSH

1. Установите расширение Remote - SSH от Microsoft.
2. Убедитесь, что к серверу можно подключиться из обычного терминала по ключу.
3. Добавьте хост в ~/.ssh/config:

Host staging
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

4. В палитре команд выберите Remote-SSH: Connect to Host... и укажите staging.
5. Откройте папку проекта на сервере.

Порты, которые слушает приложение на сервере, можно пробросить на локальную машину через панель Ports, и открыть сайт в браузере по localhost.

Учтите: расширения, работающие с кодом (линтеры, отладчики, языковые плагины), нужно установить заново уже на сервер — редактор предложит это сделать.

Настройка Dev Containers

Понадобятся расширение Dev Containers и установленный Docker (Docker Desktop или Docker Engine). В корне проекта создайте .devcontainer/devcontainer.json:

{
  "name": "web-app",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/node:1": { "version": "lts" }
  },
  "forwardPorts": [3000],
  "postCreateCommand": "npm ci",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Что здесь происходит:

• image — базовый образ. Вместо него можно указать свой Dockerfile через поле build.
• features — готовые блоки, которые доустанавливают инструменты: язык, CLI, клиенты баз данных.
• forwardPorts — порты, доступные с вашей машины.
• postCreateCommand — команда после создания контейнера, обычно установка зависимостей.
• customizations.vscode.extensions — расширения, которые поставятся внутрь контейнера у каждого участника.

Затем выполните Dev Containers: Reopen in Container. После изменения конфигурации — Rebuild Container.

Если проекту нужны база данных и кэш, используйте dockerComposeFile и service вместо image: VS Code поднимет весь набор сервисов из Docker Compose и подключится к нужному.

Производительность

• Remote SSH зависит от сети. Ввод текста локальный и не тормозит, но операции с файлами и терминал идут через соединение. Выбирайте сервер с хорошей связью до вас.
• Dev Containers на macOS и Windows работают через виртуальную машину, и общие папки с хоста бывают медленными на проектах с большим числом файлов (например, node_modules). Помогает команда Clone Repository in Container Volume — код хранится сразу в Docker-томе.
• На Windows держите проект внутри файловой системы WSL 2, а не на диске C:.
• Тяжёлые шаги (установка системных пакетов) выносите в образ или features, чтобы они кэшировались, а не выполнялись при каждом запуске.

Польза для команды

• Онбординг за минуты: клонировать репозиторий, открыть в контейнере — и всё работает.
• Нет «у меня работает»: версии языка, утилит и расширений зафиксированы в репозитории.
• Изменения среды проходят ревью, как обычный код.
• Тот же devcontainer.json понимают облачные среды вроде GitHub Codespaces и консольный инструмент devcontainer для CI. Спецификация открыта: containers.dev.

Частые ошибки

• Хранить секреты прямо в devcontainer.json — он попадает в Git. Передавайте их через переменные окружения или локальные файлы вне репозитория.
• Указывать образ с плавающим тегом latest — среда начнёт меняться без вашего ведома.
• Забывать про права файлов: если в контейнере вы работаете от root, на хосте могут появиться файлы, которые нельзя изменить без sudo. Используйте remoteUser.