У Yandex Cloud сейчас идут восстановительные работы после атак на дата-центры. На 13 октября облачная платформа продолжает работать с ограничениями. Ситуация тяжёлая, и делать из неё вывод «вот я бы сделал надёжнее» было бы довольно самоуверенно. Такого вывода здесь не будет.
Но собственную платформу для запуска приложений я действительно делаю. Называется Inquir Compute.
Причём изначально я вообще не собирался заниматься облаками. Хотел сделать поисковый сервис. Примерно через три года обнаружил, что занимаюсь запуском чужого кода, контейнерами, фоновыми задачами и вопросами вроде «а что произойдёт, если пользовательская программа никогда не завершится?».
Расскажу, как до этого дошло и что получилось.
Первоначальный Inquir должен был собирать данные из разных источников и давать поиск по ним. Позже добавились ответы с помощью нейросетей: находишь подходящие документы, передаёшь их модели, получаешь ответ.
Но прежде чем искать по данным, их надо загрузить. Потом очистить, преобразовать, проиндексировать и периодически обновлять. А ещё дать пользователю возможность написать собственную обработку.
Постепенно вокруг поиска появились загрузчики, фоновые обработчики, базы данных и среда для выполнения пользовательского кода. В какой-то момент инфраструктура обходилась почти в 400 долларов в месяц. Проект тогда ничего не зарабатывал.
Проблема была даже не только в деньгах. Я одновременно делал несколько продуктов, каждый из которых требовал отдельного внимания.
В итоге решил сосредоточиться на той части, которая могла пригодиться и за пределами поиска: запуске кода и управлении задачами. Так появился Inquir Compute.
С точки зрения человека, который советовал бы мне начать с чего-нибудь небольшого, результат, конечно, спорный.
Что это вообще такое
Представьте, что вы написали небольшое приложение. Например, Telegram-бота, сервис обработки документов или внутреннюю панель для своей команды.
На вашем компьютере оно работает. Теперь нужно, чтобы работало без вашего компьютера.
Мне хотелось получить место, куда можно принести приложение и дальше заниматься преимущественно им: выпустить новую версию, посмотреть логи, подключить базу, добавить домен. Не собирать каждый раз окружение заново.
Сейчас в Inquir Compute можно запускать обычные приложения из Dockerfile или готового контейнерного образа. Рядом разместить PostgreSQL или Redis, связать сервисы внутренней сетью и открыть нужное приложение наружу. Есть управление ресурсами, реплики, домены с HTTPS и логи.
Отдельно есть функции на Node.js, Python и Go. Их можно вызывать по HTTP, использовать для обработки событий или включать в фоновые процессы. Например, не держать отдельное приложение ради задачи, которая нужна раз в сутки.
Мне интересен именно такой формат: основное приложение живёт постоянно, а небольшие задачи вокруг него запускаются тогда, когда нужны.
Здесь скриншот проекта в Inquir: приложение, база данных и связь между ними.
Например, у меня там работает PDF-редактор
Недавно я с помощью ИИ сделал небольшой PDF-редактор для себя и разместил его на Inquir Compute. Он называется «Правка».
Это довольно понятный пример того, для чего я делаю платформу. У тебя появилась небольшая полезная программа. Ты не знаешь, станет ли она продуктом, будет ли кто-то ею пользоваться и захочется ли тебе вообще развивать её через месяц.
Но уже сейчас хочется открыть её по ссылке и отправить другому человеку.
Здесь скриншот работающего PDF-редактора.
Для контейнерного веб-приложения без записываемых томов процесс в Compute выглядит так: загружаешь исходники с Dockerfile или указываешь готовый образ, платформа запускает новую версию и проверяет её состояние. Новую версию можно посмотреть на отдельном адресе, а затем переключить на неё основной трафик. Предыдущий релиз доступен для отката.
При этом проверка запуска не означает, что приложение правильно считает налоги или что в нём нет ошибок. Она отвечает на гораздо более скромный вопрос: запустилось ли оно и проходит ли заданную проверку. Корректность самого приложения всё равно надо проверять.
Для более сложного проекта можно добавить фоновые задачи. Допустим, пользователь отправляет документ, после чего нужно извлечь текст, обработать его моделью и сохранить результат. Такой процесс можно разделить на этапы и смотреть, на каком именно возникла проблема. В Compute для этого есть пайплайны с историей выполнения и повторными попытками.
«А почему просто не взять VPS?»
Можно. У меня нет аргумента, почему человек с работающим VPS и нормальным Docker Compose должен срочно всё бросить и переехать.
Я бы сам не стал переносить исправно работающую систему только потому, что кто-то сделал ещё одну панель управления.
Вопрос для меня скорее в том, какую часть работы хочется делать самостоятельно.
Кому-то удобно один раз настроить сервер и дальше поддерживать его своими скриптами. Кто-то хочет управлять приложениями через готовую платформу. А кому-то нужен большой облачный провайдер с набором специализированных сервисов и договорными обязательствами.
Я пытаюсь сделать удобный вариант для второго случая.
Причём ценность должна быть заметна не только в первый день, когда приложение красиво запустилось. Мне кажется, гораздо важнее следующий месяц: насколько понятно, почему не прошёл деплой, где посмотреть ошибку, как сменить конфигурацию и что делать после неудачного обновления.
Именно за такие вещи я сам был бы готов пользоваться платформой.
Самое интересное начинается после запуска
Выполнить пользовательский код недостаточно. Надо ещё решить, что делать, когда он завис, занял всю доступную память или продолжил работать после того, как вызывающая сторона уже перестала ждать.
Например, в Node.js есть модуль vm для выполнения JavaScript в отдельном контексте. Но отдельный контекст не равен безопасной песочнице. В документации прямо предупреждают, что этот модуль не предназначен для безопасного запуска недоверенного кода.
Другая задача: сколько держать окружение готовым к следующему запуску? В Compute используются прогретые контейнеры, чтобы повторный вызов не всегда требовал полной подготовки окружения. Но держать их бесконечно тоже нельзя: они занимают ресурсы. Поэтому холодные старты никуда волшебным образом не исчезают.
Или возьмём обновление приложения.
Для веб-сервиса без локальных данных удобно сначала поднять новую версию, проверить её и только потом переключить запросы. С базой данных так просто уже не получится. В текущей реализации Compute приложение с записываемым томом работает в одной реплике, а при обновлении используется перезапуск с остановкой предыдущего контейнера. Это означает перерыв в работе.
Такие детали не очень эффектно смотрятся на главной странице, но именно от них зависит, можно ли использовать платформу для конкретной задачи.
Здесь скриншот реального деплоя: состояние релиза и его логи.
И всё-таки про надёжность
Раз уж в заголовке появился Яндекс, этот вопрос пропустить не получится.
Я не предлагаю считать небольшой проект надёжнее большого облака только потому, что у большого облака случилась авария. И не предлагаю переносить ко мне критичную систему, не разобравшись в ограничениях.
Например, сейчас тома с данными в Compute привязаны к конкретному хосту. Если он недоступен, приложение не поднимется автоматически на другом сервере с теми же данными. Это не отказоустойчивый кластер базы данных.
Есть и ограничения резервного копирования. Сейчас автоматические копии делаются раз в шесть часов, но приложения, у которых суммарный объём данных в томах превышает 2 ГБ, пока не включены в резервное копирование платформы. Для них необходимо отдельно сохранять свои копии.
Я бы проверял любой хостинг, включая свой, простым упражнением: представить, что доступ к нему пропал.
Остались ли у меня исходники, конфигурация и данные? Понимаю ли я, как развернуть приложение заново? Проверял ли восстановление, или просто видел зелёную надпись «резервная копия создана»?
Для личного бота и сервиса, через который проходят заказы бизнеса, ответы и допустимые риски будут разными. Это стоит решить до аварии.
Зачем я пришёл с этим на Пикабу
Мне нравится разрабатывать Inquir, но я не хочу бесконечно придумывать задачи сам для себя.
Хочется посмотреть, как платформой пользуются другие разработчики. Не на подготовленном примере, где всё заранее известно, а со своим приложением, своими зависимостями и своим представлением о том, как вообще должен выглядеть деплой.
Для знакомства есть бесплатный тариф. Его нужно запросить после регистрации и подтверждения почты: он не включается автоматически у каждого нового аккаунта. Условия и ограничения опубликованы на странице тарифов Inquir Compute.
Начинать я бы предлагал с небольшого проекта, на котором можно спокойно проверить запуск, обновление, логи и работу с данными. А уже потом решать, подходит ли платформа для чего-то ещё.
Где вы сейчас держите свои небольшие приложения, ботов и фоновые задачи? И что должно быть у новой платформы, чтобы вы попробовали запустить на ней хотя бы один проект?
Особенно интересно услышать тех, у кого уже всё работает на VPS и кто пока не видит причин что-либо менять.
