Про контейнеризацию в разработке софта.
Порой имеется несколько разных #
linux (и дистрибутивов и версий) под которые надо разрабатывать приложения (собирая, отлаживая). Либо локально на машине разработчика или же на серверах каких-то.
Как вариант, берётся #
VSCode с
предлагаемым подходом и даже есть более-менее
подробная информация для освоения процесса.
Для чего берётся вот это расширение
Dev Containers. И в контейнер ходит не через #
SSH, а производит установку внутрь контейнера такой вещи как «VSCode Server». Выполняется установка прозрачно для пользователя, в процессе «подключения» к заданному контейнеру (на локальной машине). #
VSCode берёт идентификатор своей версии (commit id) и по нему скачивает «VSCode Server» со специального сайта #
Microsoft.
А само окно #
VSCode становится чем-то вроде удалённого GUI для того сервера, что теперь запущен в контейнере.
Приколов несколько:
- В таком открывшемся окне #VSCode на вкладке расширений придётся включить уже имеющиеся/установленные расширения, чтобы они скопировались внутрь контейнера. Т.е. работают он реально там на сервере, а не тут локально.
- Некоторым расширениям нужны всякие вещи, вроде #LSP сервера, #lldb / #gdb, иногда lldb-mi. Всё это внутрь контейнера придётся устанавливать самостоятельно, ручками.
- Использовать расширение Dev Containers получится лишь на официальной Visual Studio Code — в таких вариантах как #Code-OSS, #VSCodium и #Uncoded оно просто не доступно. А если его установить через скаченный #VSIX, то работать не будет.
Хорошо или плохо?Официальный #
VSCode конечно же шлёт телеметрию в #
Microsoft «со страшной силой» да и вообще, является проприетарным вариантом дистрибьюции #
Code-OSS, который тоже, в свою очередь, страдает телеметрией (из-за чего и появились #
VSCodium да #
Uncoded ).
Однако, именно в силу проприетарности #
VSCode и позволяет из галереи устанавливать проприетарное же расширение
Dev Containers. А в галереи у #
Code-OSS этого расширения нет и понятно почему — не сможет скачать серверную часть, которую нужно устанавливать внутри контейнера (в качестве агента) и которая тоже проприетарная.
В целом: - Работать с кодом получается, равно как и обычным образом, как если бы тулчейн и библиотеки не находились внутри контейнера;
- Поддерживаются как обычные #Docker -контейнеры так и #rootless варианты контейнеров — соответственно, и #Podman -контейнеры тоже (которые априори #rootless );
- Не обязательно заморачиваться с
.devcontainer/devcontainer.json в проекте, можно подключаться из #VSCode к любому контейнеру — запустится новое окно редактора.
Нормальный проприетарный продукт, охватывает разные сценарии. В том числе и для любителей сидеть на #
Windows и вести разработку через #
WSL (Windows Subsystem for Linux v2).
Чтобы работало с #
rootless контейнерами надо в:
~/.config/Code/User/settings.jsonпрописать параметры вида:
"dev.containers.dockerSocketPath": "unix:///run/user/100500/docker.sock",
"docker.environment": {
"DOCKER_HOST": "unix:///run/user/100500/docker.sock"
},
Подсмотреть unix-socket можно через:
$ systemctl status --user docker.socket
...
Listen: /run/user/100500/docker.sock (Stream)
#
vscode #
containerization #
containers #
softwaredevelopment #
software #
lang_ru @
Russia @
Programming Feed
