Переустановка после истечения оценочного периода WebStorm

$ ./uninstall.sh
$ env UID=$UID HOST_IP=192.168.1.10 HOST_USER_PASS=<user_pass> ./install.sh
$ ./start.sh
# в терминале открывшегося WebStorm
$ doas apk add nodejs yarn
# далее через меню Settings отключить плагины GitHub, GitLab

Инструкция по запуску GUI приложений в докер-контейнере, используя SSH-доступ к хосту

Дано:

• локальная машина пользователя user_host (10.31.228.137), например, домашний ноутбук;
• удаленная машина с установленным Docker, docker_host (192.168.1.10), c рабочим аккаунтом user;
• на удаленной машине docker_host не запущен X-сервер;

• JetBrains WebStorm, который нужно запустить в контейнере, чтоб можно было каждый месяц продлевать trial.

  ---

  1. Подключаемся к docker_host

  Таким способом подключения (используя обратный туннель, опция R) мы одновременно прокидываем unix сокет X-сервера локальной машины user_host на удаленную машину docker_host, где установлен Docker

$ ssh -CR localhost:6000:/tmp/.X11-unix/X0 user@192.168.1.10
# проверить работоспособность прокидки unix-сокета можно сразу
$ DISPLAY=:0 xeyes
# на экране пользователя должны появится "следящие глаза", маленькая тестовая програмка

Полезные опции:

• -C запросить сжатие данных
• -g использовать внешние интерфейсы (на удаленном хосте должна быть включена опция GatewayPorts clientspecified в /etc/ssh/sshd_config),
• -R создавать обратный туннель (т.е. порт локальной машины становится доступным на сервере)

• -N не входить в оболочку (туннель просто будет “висеть” в консоли, пока не нажмешь CTRL+C)

  ---

  2. Подготовка к установке

  Полагаем, что WebStorm будет установлен по пути ~/programs/webstorm, а проекты пользователя находятся по пути ~/projects.
  Клонируем данный репозиторий:

$ cd ~/programs
$ git clone git@gitlab.lpr.jet.msk.su:bn.nazar/docker-gui-app-via-ssh.git
$ mv docker-gui-app-via-ssh webstorm
$ cd webstorm

Загружаем из интернета свежую версию WebStorm
https://www.jetbrains.com/webstorm/download/#section=linux

$ wget https://download.jetbrains.com/webstorm/WebStorm-2024.1.3.tar.gz
$ tar -xf WebStorm-2024.1.3.tar.gz
$ ln -s WebStorm-241.17011.90 webstorm

Строго говоря исходники WebStorm можно скачать в любую директорию, главное потом правильно создать ссылку на них командой ln:

$ ln -s /absolute/path/to/WebStorm-241.17011.90 webstorm
$ ln -s ../../relative/path/to/WebStorm-241.17011.90 webstorm

Также создаем ссылку на директорию с проектами:

$ ln -s ~/projects projects

3. Установка

Под установкой понимается сборка docker-образа и последующий его запуск, собственно 3 команды:

$ ip a
$ env UID=$UID HOST_IP=192.168.1.10 HOST_USER_PASS=<user_pass> ./install.sh
# где:
#  - HOST_IP - IP адрес внешнего интерфейса машины docker_host, можно посмотреть командой ip a
#  - HOST_USER_PASS - пароль пользователя, с которым прокидывался туннель на docker_host
$ ./start.sh

Полностью удалить контейнер из системы можно командой:

$ ./uninstall.sh

Скрипт для остановки контейнера не нужен, так как после закрытия GUI контейнер остановится автоматически. Если же по каким-то причинам нужно принудительно остановить контейнер, то можно выполнить:

$ docker-compose -f docker/webstorm.yml stop

4. Пояснения

Образ alpine был выбран потому, что он минималистический и не имеет предустановленного пользователя UID=1000. В то время как, например, образ Ubuntu, имеет предустановленного пользователя [ubuntu:uid:1000].

В контейнере намеренно создается пользователь с тем же именем и uid, от имени которого работает пользователь хоста. Это делается с той целью, чтобы не было проблем доступа из контейнера к файловой системе хоста.

При сборке параметр env UID=$UID задается явно (в отличие, например, от $USER) потому, что он отсутствует в переменных среды. Но он присутствует в переменных оболочки, echo $UID выведет имя пользователя.

Переменные среды UID, HOST_IP, HOST_USER_PASS нужны только для сборки образа. А переменная среды DISPLAY нужна только для старта, она захардкоджена в скрипте start.sh.

Прокидка X-сервера пользователя через unix-сокет /tmp/.X11-unix/X0 делается потому, что подключения к нему не требуют аутентификации (xauth). Иначе бы пришлось выполнять многочисленные танцы с бубном вокруг ~/Xauthority, коих множество описано в интернете. Мне так и не удалось найти рабочий способ из всех описанных, не иначе как создают эти описания гуру, и исключительно для других гуру.

Изнутри докера для GUI приложений прокидывается прямой туннель на хост localhost:6000. На этом порту обычно принимает соединения X-сервер, но в нашем случае он выключен, и мы используем этот порт для дальнейшей прокидки на машину пользователя (обратный туннель).

Если требуется пробросить соединение к X-серверу пользователя на машину user_host в то время, когда на удаленной машине docker_host запущен свой X-сервер или возможны параллельные “ssh X”-соединения, которые используют порты начиная с 6010, - в данной ситуации порт 6000 лучше заменить на, скажем, 6100. Т.е. при смене порта мы должны переподключиться к удаленной машине с новым портом (см. выше, п. “**1. Подключаемся к docker_host”**):

$ ssh -CR localhost:6100:/tmp/.X11-unix/X0 user@192.168.1.10

а также мы должны поправить порт хоста в прямом туннеле контейнера (см. docker/run.sh этого репозитория, второе значение):

$ sshpass -p $ENV_HOST_USER_PASS ssh -o StrictHostKeyChecking=no -CNL 6000:localhost:6100 $ENV_HOST_USER@$ENV_HOST_IP

При этом значение DISPLAY в start.sh, менять не нужно, так как оно используется внутри контейнера и не меняется при прокидке (порт 6000 прямого туннеля).