Как запустить среду Cloudflare Workers на своем сервере

Вы когда-нибудь задумывались, как Cloudflare умудряется выполнять тысячи микроскопических функций (воркеров) с такой бешеной скоростью и минимальным оверхедом? Секрет не в Docker-контейнерах и даже не в стандартном Node.js. Ребята из Cloudflare используют собственный рантайм, который теперь полностью открыт под названием workerd.

Что это вообще такое

Если коротко: workerd — это серверный рантайм для JavaScript и WebAssembly, на котором крутится весь Cloudflare Workers. Это не замена Node.js или Deno в привычном смысле. Проект создавался с прицелом на «наносервисы». Это когда вы дробите приложение на десятки компонентов, которые работают изолированно, но при вызове друг друга не тратят время на сетевой стек. Они живут в одном процессе и одном потоке, поэтому вызов соседнего воркера по скорости сопоставим с обычным вызовом локальной функции.

Зачем это разработчику

Первая и самая очевидная причина — локальная разработка. Если вы пишете под Cloudflare Workers, вам больше не нужно гадать, как поведёт себя код в облаке. Раньше для этого использовали симуляторы, но теперь у нас есть тот же самый бинарник, что стоит на серверах Cloudflare.

Вторая причина интереснее: self-hosting. Если вам нравится модель программирования Workers (fetch-события, стриминг ответов, Web Standards API), вы можете развернуть свои воркеры на обычном VPS или внутри своей инфраструктуры.

Третья роль — программируемый прокси. Workerd отлично справляется с перехватом, модификацией и маршрутизацией трафика. Это гораздо гибче, чем писать конфиги для Nginx.

Главные фишки рантайма

Наносервисы вместо микросервисов

В обычной микросервисной архитектуре каждый чих — это HTTP-запрос между контейнерами. Здесь всё иначе. Вы можете развернуть десятки воркеров, и они будут общаться между собой напрямую. Cloudflare называет это гомогенным деплоем: вместо того чтобы раскидывать разные сервисы по разным машинам, вы деплоите всё везде. Балансировка нагрузки при таком подходе упрощается в разы.

Обратная совместимость через даты

Это, пожалуй, самая крутая инженерная находка. В конфиге воркера вы указываете compatibilityDate. Если вы обновите сам workerd через три года, ваш старый код не сломается. Рантайм посмотрит на дату и будет эмулировать именно то поведение API, которое было актуально на тот момент. Больше никаких мучительных миграций из-за того, что в новой версии библиотеки поменяли сигнатуру метода.

Безопасность через Capability Bindings

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

Как это выглядит в коде

Конфигурация описывается на языке Cap'n Proto. Выглядит непривычно, но логика простая. Вот пример минимального конфига:

using Workerd = import "/workerd/workerd.capnp";

const config :Workerd.Config = (
  services = [
    (name = "main", worker = .mainWorker),
  ],
  sockets = [
    ( name = "http",
      address = "*:8080",
      http = (),
      service = "main"
    ),
  ]
);

const mainWorker :Workerd.Worker = (
  serviceWorkerScript = embed "hello.js",
  compatibilityDate = "2023-02-28",
);

А сам воркер в hello.js — это стандартный JavaScript, знакомый любому фронтенд-разработчику:

addEventListener("fetch", event => {
  event.respondWith(new Response("Привет, это мой локальный воркер!"));
});

Нюансы и предостережения

Важный момент: разработчики честно предупреждают, что сам по себе workerd — это не «бронированная» песочница. Он изолирует воркеры друг от друга на уровне ресурсов, но если вы планируете запускать в нём чужой вредоносный код, его всё равно нужно упаковывать в виртуальную машину. Cloudflare в своем облаке использует дополнительные слои защиты, которые не входят в этот опенсорс-пакет.

Сборка проекта тоже может заставить попотеть. Используется Bazel, и вам понадобится свежий LLVM (минимум 19-й версии). На Windows процесс чуть сложнее, чем на Linux или macOS, но в репозитории есть готовые скрипты для установки зависимостей.

Стоит ли пробовать

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

Проект активно развивается, и хотя документация местами суховата (многое приходится подсматривать в комментариях к .capnp файлам), за ним стоит огромный опыт эксплуатации в продакшене под колоссальными нагрузками. Это не просто очередная игрушка, а проверенная в боях технология.

Начать проще всего с готовых бинарников через npm: npx workerd serve my-config.capnp. Попробуйте запустить на нем какой-нибудь небольшой прокси-сервис, и вы почувствуете, насколько это быстрее привычных решений.