Средний

10 мин

3

Обычно разработчики пользуются локальными IDE вроде VS Code или IDE от JetBrains со своим набором плагинов, настроек и собранным под себя окружением. Иногда — удалённой машиной. Но есть третий вариант, который пока многим непривычен и потому вызывает настороженность, — Cloud IDE, или CDE. 

Закономерно возникают вопросы: а точно ли мои данные в безопасности? Есть ли в CDE все нужные компоненты для полноценной работы или это просто способ быстро заглянуть в код?

Мы смотрим на облачную IDE не как на замену привычным инструментам, а как на отдельный способ работы с кодом. Это изолированное рабочее пространство, в котором уже есть нужное окружение, с быстрым доступом и возможностью сохранять состояние между сессиями. Для разработчика это не «посмотреть код через браузер», а полноценная среда там, где важны скорость настройки проекта, изолированность от локального окружения и возможность работать над несколькими задачами разом.

Меня зовут Сергей Бабенко, я ведущий разработчик в команде SourceCraft, и в этой статье я попытаюсь развеять сомнения по поводу перехода на CDE. Вас ждут реверсивные сетевые туннели, мультизональный роутинг, натягивание совы serverless на глобус CDE и прочая хардкорная инфра. Облачная IDE внутри нашей платформы называется SourceCraft Spaces, и она уже доступна для пользователей.

Почему облачная IDE вызывает недоверие у разработчиков и как всё на самом деле 

Когда речь идёт о коде, настройках окружения, доступе к репозиториям и сохранности данных, любое новое решение автоматически сравнивают с тем, что уже хорошо знакомо и предсказуемо. И это не абстрактное предположение: мы изучили этот вопрос, поговорили с разработчиками и выяснили, что именно их останавливает от перехода на CDE.

Cloud IDE у многих не ассоциируется с полноценным циклом разработки: её скорее видят как инструмент для быстрого и поверхностного доступа к коду, когда нужно что-то посмотреть на ходу. Из-за этого сам формат кажется не очень серьёзным. 

Например, в нашем исследовании часто всплывало опасение, что облачная IDE окажется слабее локальной. Разработчики ожидают, что в «облегчённой» версии не будет рефакторинга или доступа к привычным инструментам. Но на самом деле в CDE есть всё, что и в локальной IDE: 

• базовые инструменты разработки;

• возможность установить нужные утилиты и расширения из VS Marketplace;

• запуск тестов и отладки.

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

Большие опасения у разработчиков вызывают зависимость от интернета и отсутствие офлайн-режима — это ограничение, которое может сильно повлиять на работу в поездках или при ограниченном доступе к сети. К сожалению, с этим мы не можем ничего поделать: сам формат CDE предполагает работу онлайн.

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

В CDE удобно работать над несколькими проектами параллельно, вайбкодить, быстро проверять гипотезы. Встроенные SourceCraft CLI и SourceCraft Code Assistant ускоряют и облегчают разработку. И, конечно, окружение можно использовать как «песочницу», в которой не страшно дать волю ИИ-агенту. Он может работать автономно, а если вдруг что-то сломает, всегда можно просто запустить новое окружение. 

Мы заботимся о безопасности пользователей, поэтому регулярно обновляем весь предустановленный в CDE SourceCraft Spaces инструментарий и закрываем все найденные уязвимости.

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

Базовые принципы, от которых мы отталкивались, и требования к облачной IDE 

Cloud IDE появилась не из абстрактных «хотелок», а из довольно приземлённых задач: что должно быть у разработчика под рукой и что может дать облачная инфраструктура.

Cloud IDE должна была запускаться быстро. Не за минуту, не «ну подождите чуть-чуть», а так, чтобы пользователь мог за 5 секунд получить рабочее пространство и начать работать. 

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

При этом нужны были доступ в интернет для работы с зависимостями и внешними сервисами и стриминговые протоколы: 

• веб-сокеты;

• протокол LSP для навигации по коду;

• DAP для отладки. 

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

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

• изменения в коде;

• пользовательские настройки;

• установленные плагины и утилиты. 

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

Если совсем коротко, наши базовые требования к CDE выглядели так:

• быстрый старт;

• изоляция окружений;

• авторизация всех запросов;

• воспроизводимость;

• поддержка стриминговых протоколов;

• долгоживущее рабочее пространство;

• сохранение состояния между сессиями.

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

Почему было сложно найти подходящий хост и на чём мы остановились в итоге

Первым делом мы смотрели в сторону serverless. Очень хотелось проверить, можно ли запустить IDE на облегчённой виртуалке, которая поднимается за несколько секунд, то есть полностью соответствует нашему требованию. 

Но на момент, когда мы прорабатывали архитектуру CDE, serverless не поддерживал в релизном качестве долгие подключения, не было персистентного диска для хранения данных. Это значило, что пришлось бы периодически переносить состояние в стороннее хранилище и потом поднимать обратно. Технически мы могли бы заставить работать такой вариант, но ценой большого количества костылей. Для коротких сессий вайбкодинга это могло бы подойти, а вот для полноценной Cloud IDE — уже нет. Хотя serverless сам по себе удобен, конкретно для нашей задачи он не подошёл.

Второй вариант, который мы рассматривали, — «коммуналка» из контейнеров на одной машине. Идея была такая: берём один мощный сервер или виртуалку, запускаем на ней Docker‑контейнеры с окружениями разных пользователей. 

Контейнеры стартуют быстро, ресурсы используются плотно — в теории всё красиво. Но у этого подхода есть архитектурная проблема, и она же — потенциальная огромная дыра в безопасности: из контейнера можно выбраться на хост и дальше добраться до данных других пользователей. Как ни усиливай безопасность, полная изоляция на уровне Docker-контейнеров невозможна. 

Так что мы решили вернуться к классическим виртуальным машинам. С точки зрения изоляции и безопасности это самый прямой и понятный вариант: у пользователя своя VM, свой диск, всё работает как обычная машина в облаке. Можно держать длительные сессии, спокойно хранить состояние на диске, не придумывать сложные схемы персистентности. 

Очевидный минус — скорость старта. Обычная виртуалка поднимается 2–3 минуты в зависимости от конфигурации, и это не считая времени, которое уходит на клонирование репозитория и настройку окружения. Такого мы себе позволить не могли, поэтому придумали, как объединить безопасность и надёжность VM с быстрым стартом serverless.

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

Когда пользователю нужно рабочее пространство, мы берём уже готовую VM из пула и запускаем на ней окружение CDE. Время старта при этом укладывается в целевые 5 секунд для небольших репозиториев, причём уходит в основном на git clone и запуск IDE, а не на старт самой машины. На этом варианте мы и остановились. 

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

Дальше была чистая инженерия: как вокруг пула предпрогретых виртуальных машин собрать архитектуру CDE.

Как устроена облачная IDE на уровне компонентов и архитектуры

В качестве базы для рабочего места пользователя в CDE мы используем предустановленный Code Server с базовыми плагинами и тулингом. Окружение воспроизводится через конфигурацию devcontainer. В репозитории можно указать:

• расширения;

• утилиты;

• конкретные зависимости для проекта;

• настройки VS Code;

• открытые порты;

• переменные окружения. 

Запуск рабочего окружения происходит по одному из двух сценариев. 

1. Дефолтный CDE-образ и CDE-шаблоны. Компоненты SourceCraft (плагин SourceCraft Code Assistant, SourceCraft CLI, Yandex CLI) упакованы в OCI‑образы в формате devcontainer-фичей. При сборке базовых дисков для виртуальных машин из CDE-пула эти образы подтягиваются и встраиваются в них. За счёт этого при запуске дефолтного CDE-образа не нужно скачивать тяжёлые образы из внешнего хранилища и рабочее пространство стартует быстрее. 

2. Devcontainer-конфиг в пользовательском репозитории. При запуске рабочего пространства эта конфигурация читается, и рабочее окружение дообогащается нашими компонентами до нужного состояния автоматически. Репозиторий пользователя, на котором запущено рабочее пространство, клонируется и настраивается для работы с ним.

Жизненный цикл рабочего пространства

Для управления рабочими пространствами мы сделали отдельный сервис. Через него пользователь:

• запускает новые инстансы;

• смотрит существующие;

• ставит на паузу; 

• удаляет. 

Этот же сервис по времени последнего запроса через прокси понимает, когда рабочее пространство запускали в последний раз.

Если рабочее пространство не использовали больше часа, оно переходит в режим паузы: виртуальная машина останавливается, но диск пока сохраняется. Если активности нет больше двух недель, инстанс удаляется — и ресурсы освобождаются. Это позволяет не держать висящие машины, о которых все забыли, и не заставлять пользователя вручную вычищать старые окружения.

Всё, что важно для разработки, мы держим на диске виртуальной машины: 

• код;

• расширения;

• утилиты;

• настройки.

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

Оперативная память VM очищается во время остановки, сохраняются только данные на диске. Для IDE этого достаточно — важнее, чтобы не пропадали код, настройки и установленный инструментарий.

Аутентификация и авторизация

Рабочие пространства живут на отдельном верхнеуровневом домене sourcecraft.space, не на том же, что основной сайт SourceCraft. Это сделано для безопасности: всё, что выполняется внутри CDE, не должно иметь доступа к основной платформе. Обратная сторона в том, что мы не можем взять сессионную куку с основного домена sourcecraft.dev из-за другой зоны. Именно поэтому аутентификацию пришлось делать прямо в Reverse Proxy (GoLang-сервис в Managed K8S в Yandex Cloud), а не на фронте. Схема нетипичная, но по‑другому здесь просто не складывалось. Если делать аутентификацию на стороне Backend for Frontend, то придётся использовать его в качестве прозрачного прокси, а это плохая идея с точки зрения безопасности.

Снаружи к виртуальным машинам подключиться нельзя. Все запросы из браузера сначала приходят на Application Load Balancer, а оттуда попадают в Kubernetes‑кластер, где работает прозрачный Reverse Proxy. Он не разбирает содержимое запросов, но знает, от какого пользователя они пришли и к какому рабочему пространству их можно пускать.

Когда пользователь заходит в CDE, прокси по OpenID Connect аутентифицирует его через IAM, получает куки сессии, привязывает её к домену конкретного рабочего пространства. Дальше все запросы приходят уже с этими куки, а прокси по ним авторизует пользователя и перекидывает запрос на нужную виртуальную машину.

Мультизональность

Ещё одна задача, которую нам важно было решить для устойчивости CDE, — работа сразу в нескольких зонах доступности. В нашей архитектуре Reverse Proxy и виртуальная машина, к которой он проксирует трафик, должны находиться в одном ЦОД. Если запрос случайно прилетит в прокси из другой зоны, он свою машину просто не увидит. 

При этом мы хотели, чтобы CDE умела «жить» сразу в нескольких дата-центрах. Для этого нашли довольно простое решение. 

Каждый прокси при деплое знает, в какой зоне он работает. Когда пользователь запускает новое рабочее пространство, прокси явно передает CI указание, в какой зоне создать VM. Для доступа к каждому рабочему пространству генерируется URL. В качестве поддомена в него добавляется буква, которая обозначает зону доступности, а на балансировщике мы настраиваем маршрутизацию по этим поддоменам. В итоге запрос от пользователя сразу прилетает в нужный ЦОД, к тому прокси, который «видит» свою VM, и дальше трафик идёт по короткому пути.

Есть важная особенность, о которой не могу не упомянуть: если одна зона сбоит, размещённые в ней рабочие пространства временно недоступны, а после восстановления связности их снова можно будет запускать. Это крайне редкая ситуация и неидеальный сценарий, но по сравнению с вариантом «все яйца в одной корзине» переносится гораздо легче. К тому же во время сбоя можно свободно запускать виртуальные машины в других зонах. 

Ограничения облачной IDE, которые мы планируем исправить 

CDE уже активно используют разработчики внутри Яндекса, поэтому у нас есть отзывы и направления для будущей работы. И да, часть отзывов о том, что работает не так, как хотелось бы. Это нормальная история: когда система начинает жить, сразу становится понятно, чего в ней не хватает.

Например, разработчики просят доступ к виртуальной машине по SSH и другим TCP-протоколам. Такой доступ даёт практически полный контроль над окружением: позволяет проводить детальную диагностику, тонко настраивать IDE или даже заменить её на другую IDE или другие инструменты по своему выбору. 

Кроме того, разработчикам нужна возможность запускать Cloud IDE в пользовательских сетях или сетях других облачных провайдеров, интегрировать Cloud IDE с внешними сервисами для тестирования end-to-end сценариев. Чтобы сохранить безопасность CDE и при этом открыть доступ к виртуальным машинам извне, мы планируем использовать архитектуру Reverse Tunnel Proxy. Она сочетает обратное проксирование с принципом туннельного соединения. 

В основе Reverse Tunnel Proxy лежат агент туннеля, который развёрнут на виртуальной машине с CDE, и сервис туннелирования. Агент инициирует и поддерживает долгоживущее TCP‑соединение с сервисом, а тот, в свою очередь:

• принимает входящие подключения от агентов;

• аутентифицирует и авторизует агентов;

• идентифицирует агента по метаданным;

• поддерживает пул активных TCP‑соединений.

Архитектура Reverse Tunnel Proxy устраняет ключевое ограничение классического Reverse Proxy — зависимость от прямой сетевой доступности целевых ресурсов. 

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

Веб-IDE закрывает не все сценарии работы, поэтому мы планируем расширить Spaces и на десктопную версию.

Я не ставлю вопрос, заменит ли наша облачная IDE привычные JetBrains или VS Code. Мы и не добивались такой цели. Но я бы хотел, чтобы больше коллег, не только в Яндексе, попробовали новый инструмент, оценили его возможности. Давайте обсудим, какие ещё сомнения есть у вас, что вы хотели бы знать о CDE, прежде чем начать работать в ней?