Projector

Projector это способ запускать IntelliJ IDEA на удалённом сервере. Недавно я писал об этом статью, но умолчал о важной для любого параноика вещи шифровании данных на вебсокете.

Генерация и подкладывание ключей довольно муторный кусок работы. Тут придётся познакомиться с особенностями Docker и криптографии в Java. К сожалению, убежать от этого никуда нельзя, потому что это Java, и ребята из JetBrains совершенно не виноваты.

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

Герерация ключей

Вначале нам нужно сгенерировать набор ключей. Для этого нужно установить OpenJDK и использовать инструмент keytool.

Генерация ключей задача, состоящая из кучи шагов. Для себя я написал скрипт, и призываю вас воспользоваться им.

mkdir ~/keystorecd ~/keystorecurl https://raw.githubusercontent.com/projectile-ide/projectile-keymaker/master/projectile-keymaker --output ./keymakerchmod 755 ./keymaker./projectile-keymaker projector idea true IP 192.168.1.1 mypassword

Впрочем, ничего не мешает сделать это самостоятельно. Главное, чтобы на выходе получились два важных файла: ca.crt и server.jks.

• ca.crt это наш Certificate Authority, которым подписаны серверные ключи. Нужно будет заставить браузер доверять ему.
• server.jks это сертификат конкретного сервера с запущенной IDEA.

Восход Солнца вручную

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

Вначале нам нужно сгенерить наш собственный Certificate Authority (CA), который мы дальше подпихнём во все браузеры.

keytool -genkeypair -v \  -alias ca \  -dname "CN=myCA, OU=Development, O=myCA, L=SPB, S=SPB, C=RU" \  -keystore ca.jks \  -keypass:env PW \  -storepass:env PW \  -keyalg RSA \  -keysize 4096 \  -ext KeyUsage:critical="keyCertSign" \  -ext BasicConstraints:critical="ca:true" \  -validity 9999

Небольшое отступление про пароли

Обратите внимание на вот эту строчку: -keypass:env PW. Это означает, что пароль мы вписываем не в консоли (иначе он затеряется в bash history), а берем из переменных окружения.

Можно написать export PW=mypassword и этого достаточно, но тогда он тоже потеряется в bash history. Куда логичней положить его в файл.

Например, вот так можно сгенерить случайный пароль и положить его в файл:

export PW=`pwgen -Bs 10 1`echo $PW > password

А вот так можно высосать его назад в переменную окружения:

export PW=`cat password`

Красиво, правда? Конечно, такой файл всё ещё можно украсть с жесткого диска сервера, но это совсем другая история. На протяжении этой статьи я выпью свои таблеточки и представлю, что хранить пароли в текстовом файле это нормально. Тем более, что нам нужен не файл, а только содержимое переменной окружения PW.

Возвращаемся назад к генерации ключей...

CA мы сгенерили, но в каком-то богомерзком формате JKS, который браузеры не поймут. Чтобы его можно было скормить браузеру, вначале нужно перегнать его в привычный crt:

keytool -export -v \  -alias ca \  -file ca.crt \  -keypass:env PW \  -storepass:env PW \  -keystore ca.jks \  -rfc

Настала пора сгенерировать ключ для нашего сервера (того, который будет показывать Идею):

keytool -genkeypair -v \  -alias server \  -dname "CN=myServer, OU=Development, O=myServer, L=SPB, S=SPB, C=RU" \  -keystore server.jks \  -keypass:env PW \  -storepass:env PW \  -keyalg RSA \  -keysize 2048 \  -validity 385

Сертификат есть, но пока не подписанный и поэтому в браузере работать не станет. Продолжая церемонию, создаём запрос на подпись:

keytool -certreq -v \  -alias server \  -keypass:env PW \  -storepass:env PW \  -keystore server.jks \  -file server.csr

Теперь сертификат сервера можно подписать тем CA, который мы создали в самом начале:

keytool -gencert -v \  -alias ca \  -keypass:env PW \  -storepass:env PW \  -keystore ca.jks \  -infile server.csr \  -outfile server.crt \  -ext KeyUsage:critical="digitalSignature,keyEncipherment" \  -ext EKU="serverAuth" \  -ext SAN="IP:192.168.1.1" \  -rfc

Заметьте, что SAN может быть в двух вариантах: либо "DNS:website.com", если у вас есть зарегистрированное доменное имя. Либо "IP:192.168.1.1", если домена нет. Если нет ни IP, ни домена, то остаётся только забиться в угол и плакать, без этой записи браузер вам не поверит.

Дальше, в обратную сторону, нужно заставить наш JKS доверять самоподписанному CA (иначе следующий шаг сломается):

keytool -import -v \  -alias ca \  -file ca.crt \  -keystore server.jks \  -storetype JKS \  -storepass:env PW << EOFyesEOF

Берем подписанный ранее сертификат и упаковываем внутрь JKS:

keytool -import -v \  -alias server \  -file server.crt \  -keystore server.jks \  -storetype JKS \  -storepass:env PW

Ну и наконец, результат своих мучений можно посмотреть прямо в консоли:

keytool -list -v \  -keystore server.jks \  -storepass:env PW

На мой скромный взгляд, мучения с набором этих кодов в консоли того не стоят. Лучше возьмите готовый скрипт и поправьте его как вам удобней.

Прописываем файлы конфигурации

Для хранения настроек нужно сделать файл /home/olegchir/keystore/ssl.properties с таким содержимым:

STORE_TYPE=JKSFILE_PATH=/tmp/server.jksSTORE_PASSWORD=mypasswordKEY_PASSWORD=mypassword

Пароль, очевидно, нужно указывать точно такой же, который вы использовали при создании кейстора.

В этой статье я пишу полный путь до моего домашнего каталога (/home/olegchir) чтобы вам не казалось, что я где-то вас обманул и кусок текста пропустил. Критически относитесь к тому, что читаете, и вписывайте свои пути. Ну или можете поменять имя и фамилию на olegchir, хотя мне будет немного неуютно.

Почему /tmp/server.jks, а не /home/olegchir/keystore/server.jks? Потому что мы в таком виде, во временную папку, будем монтировать его внутрь докерного образа. Сейчас всё увидите.

Теперь нам нужно сказать Projector, чтобы он начал использовать эти файлы. Для этого нужно устанавить специальные переменные окружения с негуманоидными названиями в параметрах docker run, а файлы смонтировать внутрь образа.

Идём в скачанный заранее репозиторий, открываем файл run-container.sh и ищем строчку:

docker run --rm -p 8080:8080 -p 8887:8887 -it "$containerName" bash -c "nginx && ./run.sh"

Туда нужно добавить две переменные окружения:

• ORG_JETBRAINS_PROJECTOR_SERVER_SSL_PROPERTIES_PATH указывает на файл с настройками;
• ORG_JETBRAINS_PROJECTOR_SERVER_HANDSHAKE_TOKEN задает пароль, который нужно указывать в URL, чтобы успешно подключиться;
• Оба файла (настройки и кейстор) монтируем в /tmp.

docker run --rm \    -v /home/olegchir/keystore/ssl.properties:/tmp/ssl.properties \    -v /home/olegchir/keystore/server.jks:/tmp/server.jks \    --env ORG_JETBRAINS_PROJECTOR_SERVER_SSL_PROPERTIES_PATH=/tmp/ssl.properties \    --env ORG_JETBRAINS_PROJECTOR_SERVER_HANDSHAKE_TOKEN=mypassword \    -p 8080:8080 -p 8887:8887 -it "$containerName" bash -c "nginx && ./run.sh"

Теперь контейнер можно запускать!

./run-container.sh

При запуске могут быть какие-то ошибки. Желательно прочитать лог и найти строчки типа:

[INFO] :: ProjectorServer :: WebSocket SSL is enabled: /tmp/ssl.properties[INFO] :: ProjectorServer :: Server started

Установка сертификата в браузеры

Скопируйте файл ca.crt на то устройство, откуда собираетесь соединяться. Дальше нужно открыть браузер и установить сертификат.

Установка сертификата на разных сочетаниях барузера и операционной системы может выглядеть по-разному. Я не могу в этой статье рассказать о всех возможных сочетаниях, но упомяну самые популярные.

Firefox:

1. Настройки
2. Вкладка Privacy & Security
3. В самом низу настроек кнопка View Certificates
4. Вкладка Authorities
5. Кнопка Import...
6. Ищем сертификат в диалоговом окне выбора файлов
7. Прощёлкиваем, все доступные галки.
8. Заканчиваем импорт.

Chrome для Windows:

1. Настройки
2. Раздел Privacy and security
3. Раздел Securty
4. Кнопка Manage certificates
5. Вкладка Trusted Root Certification Authorities
6. Кнопка Import...
7. Открывается мастер, выбираем файл, соглашаемся импортировать именно в Trusted Root Certification Authorities.
8. После импорта обязательно закрываем Chrome. На Windows это может оказаться совсем непросто. Когда вы закрыли Chrome, откройте Диспетчер задач и посмотрите, не осталось ли процессов с именем Chrome. Все такие процессы нужно убить кнопкой Delete.
9. После перезапуска Chrome всё должно работать.

Chrome для Linux:

1. Настройки
2. Раздел Privacy and security
3. Раздел Securty
4. Кнопка Manage certificates
5. Вкладка Authorities
6. Кнопка Import...
7. Выбираем файл ca.crt,
8. Прощёлкиваем, все доступные галки.
9. Заканчиваем импорт.

Chrome и Fully Kiosk Browser для Android:

Установка под Android может быть очень разной. На Huawei MediaPad M5 мне достаточно было щелкнуть пальцем на сертификат в файловом менеджере Solid Explorer и он установился почти как на компьютере.

На других устройствах можно попробовать вот такой путь:

1. Settings
2. Security & privacy
3. More Settings
4. Encription and credentials
5. Install from storage
6. Выбрать ca.crt
7. Заканчиваем импорт.

Важно понимать, что каждый производитель Android-устройства сам себе хозяин, и пункт "Install from storage" может оказаться в любом месте настроек, и называться любым именем. Придется повозиться.

Подключаемся из браузера

Для локальной машины: https://localhost:8080/projector/?wss&token=mypassword

Для облачного сервера: https://hostname:8080/projector/?wss&host=hostname&port=8887&token=mypassword

Поиск проблем

Если ничего не помогло, попробуйте открыть адрес https://hostname:8887 и посмотрите, что напишет браузер. Вомзожно, там будет кнопка типа "всё равно доверять этому серверу навсегда" или что-то в этом роде. Возможно, там будет говорящее сообщение об ошибке.

Выводы

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

С другой стороны, один раз сделал и живи спокойно.

Обнаружил секретный репозиторий на гитхабе JetBrains под названием Projector. Благодаря нему написал кусок кода в IntelliJ IDEA, запущенной на Android-планшете. Рассказываю, как это повторить.

Проблема

Все мы любим IntelliJ IDEA, но есть с ней неувязочка она жрёт ресурсы компьютера. Может, крипту майнит, никто не знает.

У всех нас есть что-то вроде старого ноутбука, который ты очень любишь, но работать на нём уже не получается уж слишком он слабый. На некоторых девайсах Идеи и не было никогда. Например, на Android-планшетах. Зайдите на сайт нет там сборки под Arm.

В отдельном аду жарятся последователи секты DevOps. Если ты разработчик в среде с кучей современных DevOps-инструментов, то твоя среда исполнения локально на макбуке и на проде это две совершенно разные вещи. Отсюда возникают всякие миникубы, тиллеры, лупбэк прокси и прочие костыли. Остюда ноут, обжигающий коленки во время билда.

Примерно те же проблемы у пользователей C++. Большие проекты вроде браузера Chromium могут занимать на жестком диске десятки гигабайт и компилироваться сутками напролёт. Когда ноутбук уходит в троттлинг от перегрева, пользоваться им не очень удобно. SSD протираются до дыр, а если SSD напаян и гарантия закончилась выбрасывать его придется вместе с ноутбуком.

Решением было бы разделить фронтенд и бэкенд IDE. Запускаем тяжелый вычислительный бэкенд в дата-центре, или просто на своём домашнем Threadripper 3990X. Соединяемся с бэкендом из локального приложения, написанного на Java.

К сожалению, IntelliJ IDEA так сдизайнена, что до последнего времени сделать этого было нельзя. Ну, почти. Не надо быть гением, чтобы догадаться, что в Rider как-то общаются между собой Java-фронт и .NET-бэк, но использовать это в своих корыстных целях никак нельзя.

Удалённый рабочий стол отстой

Конечно, многие пытались запускать Идею через TeamViewer, Microsoft Remote Desktop, VNC, и так далее. Существуют компании, которые только так и работают сотрудники сидят на удалёнке и кодят через Remote Desktop.

Видите в этом проблему? Вот, посмотрите:

Теперь я должен вам новые глаза!

Это то, что вы видите при соединении через удалённый рабочий стол. Все ощущения изящества интерфейсов, чёткости шрифтов, вся магия Идеи куда-то улетучиливается, и во рту остаётся только горечь от пожатого джипегом мыла.

Из этого можно вынести какой-то опыт. Например, TeamViewer тормозит меньше, но изображение больше артефачит. RDP выдает лучше картинку, но безбожно тормозит. И там и там есть вопросы к качеству мобильных приложений если хочется запускать на планшете.

Что же делать? Сколько надо полоскать рот, чтобы извести оттуда привкус мыла?

Ваше слово, товарищ Projector!

Вот как выглядит картинка на моем планшете Huawei MediaPad M5:

Вначале я хотел сфотографировать шрифты с близкой дистанции, но неспособность камеры Sony RX100 v5 сфокусироваться на таком расстоянии похоронила эту идею. Вместо этого держите нотариально заверенный скриншот:

Видите косяки в шрифтах, покорёженных джипегом?

Не трудитесь, их там нет. Это настоящие векторные шрифты, и Идея тоже настоящая. Ну, почти.

Магия заключается в том, что в репозитории проекта Projector на GitHub лежит запускатор IntelliJ IDEA в серверном режиме.

Почему это работает?

Судя по всему, Projector работает на переписанном изнутри рендерере AWT из OpenJDK. Теперь AWT рисует всё не на обычных поверхностях из операционной системы, а прямо в браузере. Как именно эта магия работает я сейчас быстро описать затрудняюсь это тема для отдельной статьи.

Но эффект потрясающий любое приложение, написанное на Java и Swing, автоматически начинает работать в браузере без переписывания кода!

Хочу! Что нужно делать?

Сразу видно, что проект очень экспериментальный. Эта штука для тех, кто очень любит всё новое и хочет попробовать использовать в повседневной жизни. Но ставить на эту штуку свою жизнь я бы не стал.

Расскажу о том, как всё это запустить и начать разбираться. Дальше вы уже сами.

Общие инструкции есть вот в официальном репозитории.

Алгоритм действий:

• Подготовить сервер (только для использования в облаке)
• Сбилдить и запустить докерные образы
• Открыть IDEA в браузере
• PROFIT

Подготовка сервера

Вам понадобится компьютер с Docker.

Завести всё это можно и без Docker, но конкретно эта статья подразумевает его наличие, ибо без Docker всё становится куда сложнее.

"Сервер" может быть как машиной в облаке, так и вашим обычным компьютером неважно.

Я всё тестировал в двух конфигурациях: Linux на десктопе и Linux на удалённой виртуалке с четырьмя ядрами и 4 гигабайтами оперативной памяти. Для других операционных систем могут потребоваться корректировки.

В Ubuntu 16.04 установка докера делается вот по этой инструкции. Если у вас другая операционная система придется погуглить самостоятельно.

Краткое содержание установки Docker на Ubuntu 16.04:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"sudo apt-get updatesudo apt-get install -y docker-cesudo usermod -aG docker ${USER}sudo reboot

Дальше нужно немного поднастроить саму операционку. Если вы используете Linux-десктоп как рабочую машину в графическом режиме, то ничего делать не нужно.

Если же вы хотите развернуть что-нибудь вроде тестового сервера в облаке (благо сейчас это делается двумя щелчками мыши в Amazon и других облачных сервисах), нужно будет поставить пару пакетов.

Суть в том, чтобы у вас в командной строке появились xvfb (виртуальный фреймбуфер) и dbus-launch. Зачем нужен фреймбуфер я сказать затрудняюсь, но без этого не работают скрипты сборки. Вероятно, тяжелое наследие AWT.

Вот что нужно установить для Ubuntu 16.04:

apt install xvfb dbus dbus-x11 gnome-keyring

Устанавливать gnome-keyring приходится по внутренним убунтовым причинам. Иначе окажется, что у вас проблемы с секретами для десктопа. Если у вас не Ubuntu, то скорей всего, это не нужно.

Дальше нужно создать фреймбуфер:

Xvfb :99export DISPLAY=:99

Скрипт этот стоит засунуть куда-нибудь в автозагрузку. Например, в юнит systemd. Ну или просто руками каждый раз набирать заново.

Собираем и запускаем образ Projector

Скачиваем репозиторий со сборочными скриптами:

git clone https://github.com/JetBrains/projector-docker.gitcd ./projector-docker

Собираем и запускаем образ:

./clone-projector-core.sh./build-container.sh./run-container.sh

Заходим в IntelliJ IDEA из браузера

Если вы всё это время работали на своём (локальном) компьютере, то ссылка выглядит так: http://localhost:8080/projector/.

Если же вы запускаете всё это на удалённой машине (например, в облаке), то ссылка выглядит так: http://hostname:8080/projector/?host=hostname&port=8887.

Вместо hostname нужно ввести IP-адрес вашего сервера или доменное имя. Обратите внимание, что hostname в URL встречается два раза. Без этого не заработает.

Проблемы:

• Если вы используете прокси (именно прокси, а не VPN), временно отключите. Проблемы с пробросом вебсокетов через прокси всё ещё существуют в 21 веке.
• Если вы используете Google Chrome в качестве браузера, он может начать перебрасывать вас с HTTP на HTTPS. Попробуйте вот такую ссылку: http://host:8080/projector/?host=//hostname&port=8887. Заметьте, что слева от hostname появилось два слеша (//). В Firefox все должно работать без этого хака. Предупреждая вопрос, частично включить шифрование можно (для вебсокета), но это настолько муторно, что я не стал бы этим заморачиваться прямо сейчас.

Как работать в Android

Стандартный браузер Google Chrome в Android тратит слишком много места на всякие ненужные вещи вроде адресной строки. Для решения этой проблемы поможет бепсплатное приложение Fully Kiosk Browser.

Если вам не мешает адресная строка, но мешают органы управления Android, то можно использовать бесплатное приложение Fullscreen Immersive.

Одновременно и то и другое использовать не имеет смысла, т.к. FUlly Kiosk Browser уже умеет отключать органы управления Android-оболочки и делает это по-умолчанию.

Как работать в iOS

Понятия не имею! Из всех эппловских девайсов у меня есть только служебный макбук и личный айфон. На айфоне проверять всё это бессмысленно (экран слишком маленький), а на макбуке никаких проблем не существует.

Как запаролить соединение?

Идём в файлы проекта, которые мы скачали ранее, открываем файл run-container.sh и ищем строчку:

docker run --rm -p 8080:8080 -p 8887:8887 -it "$containerName" bash -c "nginx && ./run.sh"

И добавляем туда ещё один параметр с негуманоидным именем, значение которого ваш пароль:

docker run --rm \    --env ORG_JETBRAINS_PROJECTOR_SERVER_HANDSHAKE_TOKEN=mypassword \    -p 8080:8080 -p 8887:8887 -it "$containerName" bash -c "nginx && ./run.sh"

Теперь контейнер можно запускать!

./run-container.sh

Теперь можно пойти в браузер и подключиться по новому URL. Новый отличается от старого наличием параметра token с вашим паролем.

Для локальной машины: https://localhost:8080/projector/?token=mypassword

Для облачного сервера: https://hostname:8080/projector/?host=//hostname&port=8887&token=mypassword

Как сделать безопасное соединение?

Про это я написал на Хабре отдельную статью. Приготовьтесь к тому, что придется сделать кучу нудной работы в консоли.

Перспективы

Можно мгновенно придумать множество областей, где поможет этот проект:

• Удалённая разработка;
• Коллаборативная разработка;
• Комфортная удалённая отладка;
• Ускорение раундтрипа в приложениях с большими данными;
• Работа в защищенном контуре;
• Мгновенное разворачивание рабочего места;
• Работа с Очень Большими Монорепозиториями;
• Интеграция в инфраструктуру облачных компаний;

Кто знает, что ещё нас ждёт! Перспективы безграничные.

Проблемы

Надо сказать, что MediaPad M5 двухлетней давности на чипсете Kirin 960 не самая мощная машина в истории. (Зато это толстый надежный кирпич металла, которым можно копать землю в огороде!) И конечно, при редактировании большого количества текста появляются тормоза перерисовки. Браузеру сложно рисовать столько графики быстро.

Тем не менее, чтобы что-то отлаживать этого уже вполне достаточно. Отладчик будет красивый, четкий и приятный, а не как через Remote Desktop.

Если же запускать всё это на ноутбуке, тормозов почти нет. Особенно если там есть видеокарта, а не как у планшета MediaPad M5, где вместо видеокарты работает Mali-G71.

Выводы

Найдено чудесное решение для запуска IntelliJ IDEA (и всех IDE от JetBrains) на удалённом сервере.

Если честно, это чуть ли не лучшая новость про IDEA за последние годы. Новый хоткей это приятно, но в целом ничего не меняет. Projector же меняет всё. Удивительно, что об этом никто ничего не пишет, что из каждого утюга не доносится победная песнь проекта Projector.

Сам я сейчас занимаюсь тем, что пытаюсь упаковать запускатор IDEA в качестве нативного приложения для Windows, Android и iOS с помощью нативных для платформы средств (Electron и WebView). Некоторое время еще нужно писать код, а потом публикация на сторы может занять длительное время. Как чего получится напишу статью на Хабр.

Где-то в богом забытом репозитории на GitHub обнаружилось настоящая гора золота. К сожалению, чудес не бывает, и наверняка, это золото охряняют драконы. Посмотрим, кто выйдет на свет!