Введение

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

Может ли формат доставки рабочих мест в виде Termidesk VDI быть рабочим решением для разработки? В статье будем разбираться, утопия это или вполне себе приятная реальность.

Кстати, данная статья продолжает начатую здесь тему.

В этой части я расскажу о технологиях, которые мы используем в процессе создания Termidesk, а также поделюсь опытом выхода из курьезных рабочих ситуаций на примере трех кейсов. Например, что мы делаем, если во время работы через ВРМ (виртуальное рабочее место) пропал интернет. Или как обстоят дела с задержками при наборе с клавиатуры.

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

Технологии, которые мы используем

Как в самом продукте, так и в процессе разработки, мы имеем дело с самыми разными технологиями и инструментами. Среди них Python, GitLab, Ansible, Docker, Terraform, D-Bus и WMI, PostgreSQL, PyCharm, а также разнообразный софт для локальной виртуализации.

В работе мы регулярно сталкиваемся с вызовами, решение которых не получится просто нагуглить. Порой мы и становимся теми, кто в комментариях на StackOverflow оставляет единственный ответ на, казалось бы, давно забытый и безнадежный вопрос о проблеме многомониторного режима для протокола RDP (вы тоже раньше об этом не слышали?). Заглядывая немного вперед, именно этот протокол я буду использовать в качестве транспорта во всех демонстрациях.

Не обходится и без классических подходов к отладке в процессе разработки. Для нас в порядке вещей использовать по максимуму доступные возможности IDE: линтеры, тонкую конфигурацию под наш проект с разметкой каталогов Sources Root и Resource Root, синхронизацию проекта и отладку с использованием RemoteSSH.

Причем некоторых возможностей бывает попросту недостаточно. Например, как RemoteSSH в PyCharm, который все еще не поддерживает работу с Windows, а у нас есть мультиплатформенные компоненты. Тот же сессионный агент, который работает не только на Astra Linux, но и на ОС Windows.

Как использование Termidesk в работе помогает нам делать его лучше

Первый кейс: Удаленный стенд для разработки

Мы используем тот способ, когда в роли администратора системы осуществляем полный цикл разработки и настройки Termidesk. Чаще всего мы используем инфраструктуру Termidesk для разработки и проведения разных экспериментов.

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

• Диспетчер Termidesk на машине с Astra Linux;

• Astra Linux или Windows Server в качестве целевой ОС, на которую мы подключаемся через клиент Termidesk;

• Клиент Termidesk на машине с Astra Linux.

Наряду с ПК СВ «Брест» и VMmanager мы используем oVirt для развертывания такой конфигурации.

В процессе разработки этот подход дает нам ряд удобств:

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

2. Мощности стенда достаточно, чтобы непрерывно поддерживать, выделять ресурсы, клонировать и делать снимки состояний виртуальных машин. Такое не всегда может обеспечить даже очень мощный рабочий компьютер.

3. Легко оставлять после работы полезные артефакты в виде золотых образов ОС или заранее подготовленных конфигураций, которые могут быть полезны не только мне, но и ребятам, с которыми я работаю.

Конечно, у такого подхода есть и свои минусы:

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

2. Зависимость от сети. По понятным причинам работать с виртуальными машинами на облачной платформе затруднительно, если интернет медленный или сеть нестабильна.

Подобный подход оправдывает себя, когда мы заканчиваем работу над очередным улучшением и в целях тестирования проходим весь процесс установки и настройки Termidesk так же, как это делает в итоге администратор. Так нам проще определять точки роста продукта. И даже если они выходят за рамки ответственности нашего отдела, мы все равно можем передать информацию ключевым коллегам, что позволяет нам развивать Termidesk с разных сторон.

Например, так было с логированием. Когда однажды мы столкнулись с высоким потребления памяти и дубликатами записей в журнал, то обратили на это внимание. Проблема была исправлена и вошла в релиз 5.0.

Второй кейс: Доставка основной среды разработки - VS Code

Следующий кейс — доставка приложений. Обычно для меня это VS Code, через который в том числе и ведется разработка. Хотя на самом деле это не так важно, доставлять можно любое установленное приложение.

Какую пользу дает такой сценарий для разработки?

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

А уже сравнивать поведение можно либо через браузер хоста, либо точно так же получать нужное количество клиентских приложений Termidesk — зависит от задачи.

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

Третий кейс: Полностью виртуальное рабочее место

А теперь самый интересный кейс, к которому у вас может возникнуть больше всего вопросов.

Что если перенести всю разработку на удаленную машину и работать полностью через Termidesk VDI?

Рабочие процессы — это довольно чувствительная область для разработчика. Здесь недопустимы спонтанные обрывы сессий или существенные задержки отклика во время работы с кодом.

Разделим этот кейс на два типичных процесса разработки: набор в IDE и переключение между несколькими приложениями в режиме реального времени.

Ввод текста в IDE

Итак, насколько ощущается задержка во время работы в таком формате? Она, конечно же, есть по сравнению с печатью в локальном варианте VS Code. Но если говорить о субъективном ощущении во время работы, задержка между нажатием клавиши и ее отображением на удаленной машине настолько минимальна, что совсем не приносит ощущения какого-то дискомфорта. Спустя примерно 10-15 минут уже совсем не замечаешь, что для работы используется VDI.

Стоит отметить, что в демонстрации для честности и чистоты эксперимента я использовал публичный Wi-Fi, который не отличается показателями скорости и пинга.

Многозадачность

А вот по части многозадачности эффекты отрисовки окон в разрешении 1920 x 1200 порой были довольно заметными. С учетом качества интернет-соединения, на котором проводился эксперимент, работа в режиме многозадачности ощущается вполне нормально, хотя и не так идеально, как хотелось бы после перехода с локального рабочего места. Коллеги из смежного отдела уже работают над подобной задачей — нормализацией полосы пропускания при использовании протокола TERA, подробнее см. в нашем справочном центре. 

Бонус-трек: разрыв с интернет-соединением

Работа над Termidesk тесно связана с виртуализацией и сетью. Но что происходит, когда по каким-либо причинам случается разрыв соединения и удаленная сессия неожиданно прерывается?

Хотя лично для меня такие сценарии практически исключены: если что-то случается с моим Wi-Fi, я практически сразу могу переключиться на мобильную точку доступа — скорость сети не уступает домашнему роутеру:

В свою очередь клиент Termidesk автоматически восстановит подключение после обрыва.

Но даже при этом я конфигурирую Termidesk так, чтобы мое рабочее место не удалялось при отключении сеанса:

Даже в ситуации полной потери доступа к сети работа может быть продолжена, но над другим задачами, которые могут выполняться офлайн. Синхронизация результатов работы после восстановления доступа к сети происходит классическим способом — через git.

Заключение

Итак, есть ли место VDI в работе разработчика? Однозначно да.

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

Работа в формате VDI чувствительна и к качеству соединения и, очевидно, к протоколу доставки, который при этом используется.

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

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