Пакет расширения Visual Studio Code Remote Development позволит вам отрыть любую папку в контейнере на удаленной машине (через SSH [2]), или в Windows Subsystem for Linux [4], и получить при этом полный функционал разработки в среде VS Code. Это означает, что VS Code может предоставить при этом такую же среду разработки, как если бы она была запущена локально - включая полную поддержку IntelliSense (с автозавершением ввода кода), отладкой и другими функциями, независимо от того, где находится или размещается ваш код.
Достоинство remote-разработки:
● Можно редактировать, выполнять сборку или отлаживать код на другой операционной системе, отличающейся от той, в которой работаете локально. ● Есть возможность работать в среде, которая соответствует целевой системе распространения продукта. ● Можно использовать более специализированное оборудование, чем то, что есть в наличии на локальной машине. ● Возможность редактирования кода, сохраненного в другом месте, таком как облако или место пользователя. ● Разделение сред разработчиков для того, чтобы избежать конфликтов, повысить безопасность и ускорить вхождение в процесс разработки.
В сравнении с простым общим доступом к файлам через сеть (network share) или синхронизацией файлов, VS Code Remote Development предоставляет повышенную производительность и лучшее управление средой разработки и инструментарием.
GitHub Codespaces [6] это служба, которая предоставляет основанные на облаке среды разработки, к которым можно получить доступ как из VS Code, так и из основанного на браузере редактора. Эта служба также позволяет VS Code и основанному на браузере редактору обращаться рабочим окружениям пользователя (desktop или сервер) без необходимости в сервере SSH или даже прямого сетевого маршрута.
Хотя расширения Remote Development и Codespaces совместно используют одну и ту же технологию и функции, релизы Remote Development выпускаются отдельно, и могут работать независимо от GitHub Codespaces.
Расширение Visual Studio Code Remote Development позволяет локальной инсталляции VS Code прозрачно взаимодействовать с исходным кодом runtime environment на других машинах (виртуальных или физических) путем переноса выполнения определенных команд на remote-сервер. VS Code Server быстро устанавливается средой Code, когда вы подключаетесь к remote endpoint, и может содержать расширения, которые напрямую взаимодействуют с remote workspace, remote-машиной и remote файловой системой.
Visual Studio Code Remote Development использует существующий, хорошо известный транспорт наподобие secure shell для аутентификации и защиты трафика. Никакие дополнительные порты не должны открываться публично, кроме этих хорошо известных.
VS Code Server выполняет инжектированные запуски с правами того же самого пользователя, которые использовались при аутентификации на машине, что гарантирует, что VS Code и его расширения не получат некорректный доступ без специального разрешения. Сервер запускается и останавливается VS Code, и не подключается ни к одному из пользователей или глобальному логину или скриптам startup. VS Code управляет временем жизни сервера, так что вам не нужно беспокоиться о том, работает он или нет.
Нельзя. VS Code Server это компонент расширений Remote Development, и он управляется клиентом VS Code. Он устанавливается и обновляется автоматически средой VS Code, когда происходит подключение к endpoint, и при установке отдельно может быстро устареть. Он не предназначен и не лицензирован для использования другими клиентами.
По умолчанию Remote - SSH будет пытаться выполнить загрузку на remote-хост, но если вы разрешите remote.SSH.allowLocalServerDownload, то расширение откатится к локальной загрузке VS Code Server и передаче его на удаленную машину, когда произведено сетевое подключение.
Расширение Dev Containers всегда загружается локально и передается в контейнер.
Вы можете установить расширения вручную без наличия соединения с Интернет, используя команду Extensions: Install from VSIX..., однако если вы используете панель расширения или devcontainer.json для установки расширений, то ваша локальная машина и VS Code Server потребуют внешнего доступа через HTTPS (port 443) к следующим доменам:
И в завершение, некоторые расширения (наподобие C#) загружают вторичные зависимости из сайта download.microsoft.com или download.visualstudio.microsoft.com. Другие (наподобие Visual Studio Live Share) могут иметь дополнительные требования к соединениям. Если испытываете проблемы, то обратитесь к документации по соответствующему расширению.
Все прочие коммуникации между сервером и клиентом VS Code осуществляются через следующие транспортные каналы, в зависимости от расширения:
SSH: аутентифицированный, защищенный туннель SSH. Containers: сконфигурированный канал коммуникации Docker-а (через docker exec). WSL: случайный локальный порт [4].
Дополнительную информацию по сетевым соединениям, которые нужны VS Code, см. в документации [8].
По умолчанию расширение Docker будет работать удаленно. Это значит, что оно не будет показывать локальные контейнеры, когда VS Code подключен к remote SSH хосту, контейнеру или WSL.
Вот несколько решений этой проблемы:
● Откройте новое локальное окно (File > New Window), и используйте его для работы с локальными контейнерами. ● Установите расширение Dev Containers, и используйте Remote Explorer в ситуациях, когда нужно видеть свои локальные контейнеры. ● Только для WSL: используйте Docker Technical Preview для WSL 2, или сконфигурируйте Docker Desktop для использования в WSL 1. ● Только для Dev Containers: перенаправьте Docker socket, и установите Docker CLI (only) в контейнер. ● Используйте свойство extensionKind для управления графическим интерфейсом расширения. Однако при этом некоторые команды работать не будут.
Remote Development требует kernel >= 3.10, glibc >= 2.17, и libstdc++ >= 3.4.18. Свежие дистрибутивы x86_64, основанные на glibc, имеют самую лучшую поддержку, но точные требования могут зависеть от конкретного дистрибутива.
Поддержка для musl-based Alpine Linux доступна для расширений Dev Containers и WSL, и ARMv7l (AArch32) / ARMv8l (AArch64) доступны в Remote - SSH. Однако native-зависимости в определенных расширениях могут привести к их неработоспособности на дистрибутивах x86_64 glibc. Имейте в виду, что экспериментальное ARMv8l (AArch64) доступно только в VS Code Insiders.
Да. Remote Development extension pack предоставляет удобный способ получить доступ ко всем последним возможностям remote-разработки по мере их выхода в релиз. Однако вы всегда можете установить отдельные расширения из Marketplace или из VS Code Extensions.
Как и все другие части Visual Studio Code [10], Вы можете настроить каждое из расширений Remote Development с помощью их настроек. Например при использовании Dev Containers вы можете просмотреть список всех настроек Dev Containers путем открытия расширения в Extensions view (Ctrl+Shift+X), после чего перейдите в Feature Contributions:
Вы можете представлять себе WSL как машину Linux, работающую на Windows, где вы можете установить специфические для Linux фреймворки и инструменты (например Python, Go, Rust, и т. д.) без влияния на настройку Windows. Затем вы можете использовать VS Code и расширение WSL для разработки в контексте того, что установлено на WSL, изолированно от того, что установлено на Windows.
Например, вы можете установить Go-стек в WSL (компилятор, отладчик, linters, и т. д.). Если вы запустите VS Code только на Windows, то должны также установить такой же стек Go, чтобы получить такие функции, как умное завершение (smart completions), отладка, навигацию по Go-определениям. И поскольку языковые службы работают на Windows, они не знают, что такое WSL.
Верно то, что вы можете запускать бинарники WSL из Windows и наоборот, однако обычные расширения VS Code не знают, как это делать. Поэтому разработчики VSCode начали поддерживать отладку в WSL, но быстро стало ясно, что придется обновить все расширения, чтобы они знали о WSL.
Вместо этого было принято решение сделать части кода VS Code работающими в WSL, и позволить GUI-интерфейсу, работающему на Windows, взаимодействовать с сервером VS Code, работающем на WSL. Эта функция разрешена благодаря расширению WSL, и расширение Go работает в WSL вместе с остальными инструментами Go (компилятор, отладчик, linters), в то время как VS Code работает на Windows.
Благодаря такому подходу языковые функции наподобие smart completions просто работают в WSL без необходимости что-либо настраивать на Windows. Вам не надо беспокоиться о проблемах с путями поиска или настраивать различные версии стеков разработки на Windows. Если вы разрабатываете приложения для Linux, то можете настроить свои экземпляры WSL таким образом, чтобы они выглядели как ваша среда исполнения (runtime environment), сохраняя широкие возможности редактирования на Windows.
Нет. Контейнер разработки определяет окружение, в котором вы разрабатываете свое приложение перед тем, как оно будет готово к распространению. Хотя контейнер развертывания (deployment) и контейнер разработки (development) могут напоминать друг друга, вы можете не захотеть включать инструменты, используемые для разработки, в образ развертывания.
Репозиторий vscode-dev-containers включает набор определений dev container для некоторых общих рабочих окружений разработки. Вы также можете подсоединиться к работающему контейнеру без настройки определения dev container, если предпочитаете использовать альтернативный контейнер для процесса сборки или распространения.
Нет. Концепция Buildpacks фокусируется на том, чтобы взять исходный код и сгенерировать образы распространяемого контейнера через последовательность определенных шагов. Dev container это окружение, в котором вы можете разрабатывать свое приложение перед тем как будете готовы к сборке. Поэтому они являются взаимодополняющими концепциями.
Когда VS Code подключается к удаленному окружению, расширения классифицируются либо как расширение UI, либо как расширение Workspace. Расширения UI работают на локальном хосте расширения, могут использовать функции UI-интерфейса или функции персонализации (например темы), и получают доступ к локальным файлам или API-функциям. Расширения Workspace работают на удаленном хосте расширения с рабочим пространством, и имеют полный доступ к исходному коду, удаленной файловой системе и удаленным API-функциям. Хотя расширения Workspace не фокусируются на кастомизации UI, они могут также использовать explorer, view и другие элементы UI.
Когда пользователь устанавливает расширение, VS Code пытается определить корректное расположение и установить его на основании типа расширения. Расширения, которым не надо работать удаленно, наподобие тем или других кастомизаций UI, автоматически устанавливаются на стороне интерфейса пользователя. Все остальное обрабатывается как расширения Workspace, поскольку они обладают наиболее полным набором функций. Однако разработчики расширения также могут переназначить это место расположения с помощью свойства extensionKind в package.json.
Если ваше расширение не работает так, как ожидалось, возможны шаги для проверки, работает ли оно в правильном месте расположения, или возможно должен быть другое extensionKind. Также см. [7] для дополнительной информации о том, что необходимо знать авторам расширений про Remote Development и Codespaces.
[Ссылки]
1. VSCode Remote Development FAQ site:visualstudio.com. 2. Remote Development using SSH site:visualstudio.com. 3. Developing inside a Container site:visualstudio.com. 4. Developing in WSL site:visualstudio.com. 5. Remote development over SSH site:visualstudio.com. 6. GitHub Codespaces site:github.com. 7. Supporting Remote Development and GitHub Codespaces site:visualstudio.com. 8. Network Connections in Visual Studio Code site:visualstudio.com. 9. Remote Development with Linux site:visualstudio.com. 10. User and Workspace Settings site:visualstudio.com.
