Начало

Эта глава проводит компонент по пути от исходного кода до ответа на HTTP-запрос. Сначала подготовьте инструменты. Затем соберите компонент и запустите его локально. Платформа понадобится позже — когда компонент будет готов к публикации.

Путь компонента

Компонент проходит три шага.

Сборка. wash build собирает компонент из вашего кода и контракта WIT.

Публикация. Артефакт .wasm уходит в реестр OCI: тег выбирает версию, digest идентифицирует содержимое.

Исполнение. Среда wasmCloud запускает компонент там, где доступны нужные ему интерфейсы WASI.

Дальше работает один цикл. HTTP-запрос — событие или вызов API — приходит в среду. Компонент — ваш код и интерфейсы WASI — обрабатывает его. wasmCloud исполняет компонент и возвращает ответ.

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

Инструменты

Для локальной работы нужны wasmCloud Shell (wash) и тулчейн вашего языка.

Установка wasmCloud Shell

wash — интерфейс командной строки wasmCloud. Он создаёт проекты, собирает компоненты, публикует их в реестр и ведёт цикл разработки. wasmCloud Shell устанавливается официальной командой из документации wasmCloud:

curl -fsSL https://wasmcloud.com/sh | bash

Скрипт печатает следующие шаги: добавить каталог установки в PATH и проверить версию.

wash -V

Тулчейн языка

Компоненты собираются под WebAssembly. Для проекта на Rust добавьте целевую платформу wasm32-wasip2:

rustup target add wasm32-wasip2

Go и TypeScript собираются собственными тулчейнами — wash запускает их по команде из конфигурации проекта.

Проект

wash new создаёт проект из шаблона. Шаблон — Git-репозиторий с готовой структурой; команда принимает ссылку на репозиторий, ветку или тег и имя нового проекта. Шаблоны компонентов перечислены в документации wasmCloud.

В проекте три части:

  • wit/ — контракт компонента: интерфейсы и типы на языке WIT;
  • исходный код — функции, которые исполняет компонент;
  • конфигурация wash — команда сборки и путь к артефакту.

Конфигурация хранится в файле .wash/config.yaml проекта:

build:
  command: cargo build --target wasm32-wasip2 --release
  component_path: target/wasm32-wasip2/release/hello_world.wasm

Поле command — то, что запускает сборка; component_path — где лежит готовый артефакт.

Локальный цикл

Установите wash (см. выше), затем из корня проекта:

wash build

wash читает контракт, подтягивает WIT-зависимости в каталог wit/deps и запускает команду сборки из конфигурации. Результат — артефакт .wasm: двоичный компонент, соответствующий модели компонентов WebAssembly.

Для разработки запустите сервер:

wash dev

wash dev запускает сервер разработки и исполняет компонент на нём; адрес печатается при старте — проверьте ответ любым HTTP-клиентом. После правок исходников цикл перезапускают: сборка не следит за файлами автоматически. Остановите сервер сочетанием Ctrl+C.

Обе команды работают из любого каталога внутри проекта. Извне проекта укажите путь флагом -C:

wash -C ~/projects/hello build

Артефакты и версии инструментов

Отладочная сборка пишется в target/wasm32-wasip2/debug/, релизная — в target/wasm32-wasip2/release/. Какой файл считать артефактом, решает component_path из конфигурации.

wash обновляется одной командой:

wash update

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

От запроса к ответу

Компонент отвечает на HTTP-запросы, когда контракт экспортирует интерфейс wasi:http/handler. Среда передаёт запрос компоненту. Компонент возвращает ответ — статус, заголовки и тело.

Запрос приносит метод, путь, заголовки и тело. Ответ собирается из статуса, заголовков и тела — тех же частей, что вы знаете по любому HTTP-сервису. Никакого платформенного API между вами и запросом нет: контракт объявляет стандартный интерфейс, среда его исполняет.

Так рождается функция: один артефакт, один контракт, одна ответственность. Дальше артефакт можно публиковать — реестр и среды исполнения описаны в главе «Платформа».

Что дальше

  • «Платформа» — реестр компонентов, среды исполнения и GraphQL.
  • «WebAssembly и WASI» — модуль, компонент, контракт WIT и разрешения.
  • «Kubernetes» — запуск рабочей нагрузки в кластере.

Команды этой главы сверены с официальной документацией wasmCloud: установка, справочник команд wash, руководство разработчика.

Платформа

Платформа WasmBox — бессерверные компоненты на wasmCloud и реестр WebAssembly-компонентов. Эта глава описывает технологическое устройство обеих частей.

Компоненты на wasmCloud

Компонент — единица платформы. Код с ясным контрактом определяет, какие возможности нужны от среды исполнения: HTTP, GraphQL, боты и вебхуки.

Поток «От запроса до результата»:

  • HTTP-запрос — событие или вызов API.
  • Компонент — ваш код и интерфейсы WASI.
  • wasmCloud — исполнение и ответ.

Среда связывает компонент с нужными возможностями. Код обрабатывает запрос и возвращает ответ.

Вызов API и событие неразличимы для компонента: оба приходят объявленным интерфейсом, чаще всего wasi:http/handler. Различие лежит за пределами компонента — в том, кто инициировал вызов: пользователь ли нажал кнопку, бот ли прислал сообщение, планировщик ли запустил задачу.

Среды исполнения

wasmCloud исполняет компоненты в облаке, на собственной инфраструктуре и на устройствах.

  • Облако и узлы доступа. Дата-центр — облачная инфраструктура. Региональные узлы — размещение в нескольких регионах. Узлы доступа — исполнение рядом с источником запросов.
  • Своя инфраструктура. Собственные серверы — совместимая среда под вашим управлением.
  • Устройства и клиент. Устройства — локальная среда исполнения. IoT-узлы — исполнение при ограниченных ресурсах. Браузер — встроенный Wasm и адаптеры WASI.

Выбирайте среду с поддержкой нужных интерфейсов WASI. Инфраструктура WasmBox: Yandex Serverless Containers, Cloud Functions и wasmCloud.

Реестр компонентов

Реестр компонентов хранит версии, которые не теряются.

Опубликованный компонент становится артефактом OCI-реестра — того же формата, в котором хранятся контейнерные образы. Push отправляет артефакт в реестр, pull забирает его оттуда. Чтобы запустить компонент, среде wasmCloud достаточно ссылки на артефакт.

Публикация

Собранный файл .wasm уходит в реестр одной командой push. Публикация ничего не исполняет — реестр хранит артефакт и отдаёт его по запросу.

Версии

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

Жизненный цикл версии следует из этих правил. Разработка идёт по свежему тегу: каждая сборка перезаписывает его, и среда всегда берёт последнюю. Эксплуатация закрепляется по digest: байты не поменяются, даже если тег уйдёт на новую сборку. Переход — это смена digest в конфигурации среды, откат — возврат к прежнему.

Совместимость

Компоненты лежат в реестре рядом с контейнерными образами и читаются стандартными клиентами OCI. Среда wasmCloud запускает их прямо из реестра — без отдельного хранилища и конвертации формата.

Реестр не обязан быть специальным. Годится любой OCI-совместимый реестр, поддерживающий артефакты: компонент — не контейнерный образ, но хранится по тем же правилам OCI.

Команды реестра

Публикация и загрузка — команды wash oci. Push принимает ссылку на артефакт (реестр, имя, тег) и путь к файлу .wasm:

wash oci push registry.example/hello-world:0.1.0 ./target/wasm32-wasip2/release/hello_world.wasm

Pull принимает ссылку и записывает артефакт в файл component.wasm:

wash oci pull registry.example/hello-world:0.1.0

Для аутентификации используются учётные данные Docker. Войдите в реестр командой docker login: wash подхватит учётные данные сам.

Тег помогает выбрать версию, digest идентифицирует содержимое.

GraphQL API

GraphQL — язык запросов к данным: один вызов, объявленная схема, читаемые поля. В стеке платформы у GraphQL два применения.

Первое — интерфейс самого компонента. Компонент экспортирует схему и отвечает на GraphQL-запросы так же, как на HTTP-запросы: это ещё один способ описать контракт.

Второе — интерфейс управления. Среда и реестр описывают своё состояние как схему: инвентарь компонентов, версии, статусы исполнения. Запрос читает состояние, мутация изменяет его.

Что дальше

  • «WebAssembly и WASI» — контракт WIT и разрешения компонента.
  • «Kubernetes» — среда исполнения в кластере.
  • «Цены» — из чего складывается стоимость.

Интеграции

Интеграция — это внешний вызов, который приходит в компонент. Мессенджер присылает сообщение, платёжная система — уведомление, чужой сервис — вебхук. Для платформы все они одинаковы: HTTP-запрос, который ждёт ответа. Принцип один: контракт объявляет, среда даёт, код отвечает.

Эта глава — обзор того, как такие интеграции устроены технологически.

HTTP и вебхуки

HTTP — базовый канал. Компонент экспортирует wasi:http/handler и отвечает любому сервису, умеющему вызвать URL.

Вебхук — HTTP-запрос о событии. Отвечайте на него быстро и идемпотентно: подтвердите получение, а обработку выполните отдельно. Отправитель повторяет запрос, если ответа нет.

Проверяйте подпись до разбора тела. У отправителя есть секрет. Заголовок запроса содержит подпись этого тела. Компонент сверяет подпись и только потом доверяет событию.

Шаблон обработки события

Обработка любого входящего события укладывается в пять шагов.

  1. Сверьте подпись или токен из заголовка.
  2. Разберите тело события.
  3. Проверьте идентификатор события в хранилище «ключ — значение»: если событие уже обработано, ответьте подтверждением и завершите обработку.
  4. Запишите идентификатор и подтвердите получение.
  5. Обработайте событие и отправьте исходящий вызов.

Шаги одинаковы для мессенджеров, платёжных систем и навыков. Меняются имена полей — не порядок. Идемпотентность опирается на хранилище «ключ — значение» из контракта: интерфейс объявлен, ключи событий — ваши.

Боты Telegram

Бот Telegram получает обновления вебхуком: Bot API присылает компоненту POST-запрос с JSON. Сокращённый пример тела:

{
  "update_id": 123456,
  "message": {
    "chat": { "id": 789 },
    "text": "привет"
  }
}

Ответ уходит через тот же API: компонент делает исходящий HTTP-запрос к методу sendMessage. Исходящие вызовы объявляются в контракте — без записи в контракте среда их не пропустит.

Telegram подписывает каждый вебхук секретным токеном в заголовке запроса. Сверяйте токен до обработки обновления.

MAX

MAX — мессенджер с открытым API для ботов. Схема та же: события доставки приходят вебхуком, ответы уходят исходящими HTTP-запросами. Отличаются детали — формат событий, правила подписи, повторные доставки. Сверяйтесь с актуальной документацией канала: API мессенджеров меняется быстрее, чем книги.

Навыки Алисы

Навык Алисы — HTTP-сервис диалога. Пользователь произносит запрос. Облако Алисы отправляет навыку POST-запрос с JSON: текст, контекст сессии, идентификаторы пользователя и диалога. Навык возвращает ответ — текст для произнесения и подсказки следующего шага.

Ответ навыка собирается из тех же частей, что любой HTTP-ответ: код, заголовки, тело с JSON. Тело описывает, что произнести, что показать и какие подсказки предложить пользователю.

Компонент с интерфейсом wasi:http годится на роль навыка целиком: контракт объявляет входящие запросы, код формирует ответ диалога. Храните состояние сессии в хранилище «ключ — значение», объявленном в контракте, — тогда повторные запросы диалога находят контекст.

Ограничение исходящих вызовов

Интеграция — это не только входящие события, но и исходящие вызовы. Оба направления видны в контракте.

Список адресатов сужается явно. В среде исполнения настраивается перечень разрешённых хостов для исходящих запросов компонента: вызов мимо списка отклоняется. Компонент бота просит ровно те хосты API, которыми пользуется, — и ни одного больше.

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

Безопасность интеграций

Правила одни для всех каналов.

  • Разрешено только объявленное. Исходящие вызовы перечислены в контракте. Среда предоставляет ровно эти интерфейсы — и ничего больше.
  • Секреты — в конфигурации среды. Токены и ключи приходят значением из конфигурации, а не из артефакта. Конфигурация, секреты и разрешения остаются на стороне среды.
  • Подпись проверяется первой. Непроверенное событие не открывает базу данных и не меняет состояние.
  • Запрет по умолчанию. Файловая система, сеть, переменные окружения, системные часы запрещены, пока не объявлены в контракте.

Проверяемая интеграция — безопасная интеграция: правила видны в контракте до запуска.

Что дальше

  • «WebAssembly и WASI» — как контракт WIT объявляет возможности.
  • «Платформа» — реестр, из которого среда берёт компонент.

WebAssembly и WASI

Единица исполнения платформы — компонент. Вокруг него три понятия: модуль, компонент и среда. Эта глава раскладывает их по местам, объясняет WASI и WIT и описывает модель разрешений.

Модуль, компонент, среда

Модуль WebAssembly — двоичный формат: функции над линейной памятью. Модуль ничего не знает о файлах, сети и времени: у него есть только вычисления и память. Память линейная и своя: модуль не видит ни памяти других модулей, ни памяти среды.

Структура модуля читается в текстовой форме — WAT. Так выглядит минимальный модуль с памятью и данными:

(module
  (memory (export "memory") 1)
  (data (i32.const 0) "привет"))

Пример на главной странице сайта — консоль с модулем Hello World. Модуль собирается из исходного текста WAT, не имеет ни импортов, ни доступа к сети. Строки вывода модуль собирает сам, в собственной памяти; команда run исполняет его прямо в браузере.

Компонент — модуль плюс контракт. Модель компонентов WebAssembly описывает, как модуль соединяется с внешними интерфейсами. wash build собирает компонент из вашего кода и контракта WIT.

Среда исполнения предоставляет интерфейсы и запускает компонент. Среда wasmCloud запускает компонент там, где доступны нужные ему интерфейсы WASI. Одна и та же среда обслуживает множество компонентов; каждый компонент видит только собственный контракт.

WASI

WASI (WebAssembly System Interface) — стандартные интерфейсы между компонентом и средой. Компонент не обращается к операционной системе напрямую: он вызывает интерфейсы WASI, а среда решает, что за ними стоит.

Интерфейсы собираются в пакеты по назначению. wasi:http — обработка HTTP-запросов. wasi:keyvalue — хранилище «ключ — значение». Версия интерфейса фиксируется в контракте — например, wasi:http/handler@0.3.0.

WASI развивается версиями. Переносимость начинается с интерфейсов: проверьте требования компонента и поддержку WASI в выбранной среде.

WIT

Контракт записывается на WIT — текстовом языке интерфейсов компонента. Контракт перечисляет импорты и экспорты. Минимальный мир (world) HTTP-обработчика:

world hello {
  export wasi:http/handler@0.3.0;
}

Экспорт wasi:http/handler превращает компонент в HTTP-обработчик: среда передаёт запрос, компонент возвращает ответ.

Импорты записываются так же — словом import. Импорт означает «компоненту нужна эта возможность среды»; экспорт — «среда может вызвать это у компонента». Свои интерфейсы — помимо пакетов WASI — описываются в том же контракте: функции, типы и записи (record) составляют словарь, на котором говорят компонент и среда.

Сборка фиксирует контракт в артефакте. После сборки объявление компонента расширить нельзя — список возможностей известен до запуска и неизменен.

Зависимости контракта подтягиваются при сборке в wit/deps. Этот каталог стоит исключить из системы контроля версий: это восстанавливаемый кеш, а не исходный код.

Сборка и проверка

Сборка описана в главе «Начало»: wash читает контракт из wit/, подтягивает зависимости в wit/deps и пишет артефакт .wasm.

Проверьте артефакт до публикации. Команда wash inspect печатает WIT, встроенный в компонент:

wash inspect ./target/wasm32-wasip2/release/hello_world.wasm

Вывод показывает, какие интерфейсы компонент импортирует и экспортирует. Так вы узнаёте требования компонента до запуска: список возможностей — часть самого артефакта.

Команда wash inspect принимает и ссылку на артефакт в реестре: контракт видно ещё до того, как компонент попал в среду. Проверка чужого артефакта перед запуском — та же одна команда.

Разрешения

Компонент исполняется в песочнице. Запрет действует по умолчанию.

Компонент исполняется в изолированной среде WebAssembly. Доступ к внешнему миру — только через WASI: интерфейсы, объявленные в его контракте. Среда предоставляет ровно те возможности, что перечислены в объявлении; всё остальное запрещено по умолчанию.

Что разрешено

Только объявленное. Если контракт требует исходящих HTTP-запросов и хранилища ключ-значение, среда даёт эти два интерфейса — и ничего больше. Список возможностей известен до запуска — он часть самого артефакта.

Что запрещено

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

Как объявить возможности

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

Что дальше

  • «Платформа» — реестр компонентов и среды исполнения.
  • «Kubernetes» — среда wasmCloud в кластере.

Kubernetes

wasmCloud работает в Kubernetes как оператор: среда исполнения разворачивается в кластер, а компоненты планируются как рабочие нагрузки. Эта глава излагает устройство по документации wasmCloud — без условий обслуживания платформы.

Два способа запустить Wasm в кластере

Первый способ — RuntimeClass и шим (shim). Kubernetes исполняет контейнеры через CRI — интерфейс контейнерного рантайма. Шим с поддержкой WebAssembly исполняет модуль Wasm как контейнер. Ресурс RuntimeClass выбирает шим: под с полем runtimeClassName уходит не в обычный рантайм, а в шим. Для таких подов Wasm-модуль и есть контейнер.

Второй способ — оператор wasmCloud. Хосты wasmCloud работают обычными подами. Оператор планирует компоненты по хостам и связывает их с сервисами кластера. Отдельный шим на узлах не нужен: исполнение остаётся внутри подов-хостов.

Платформа WasmBox строится на wasmCloud, поэтому дальше речь о втором способе.

Оператор wasmCloud

Оператор устанавливается Helm-чартом и вводит ресурсы группы runtime.wasmcloud.dev/v1alpha1:

  • WorkloadDeployment — развёртывание и масштабирование рабочих нагрузок;
  • Workload — отдельная рабочая нагрузка;
  • WorkloadReplicaSet — реплики, которыми управляет WorkloadDeployment;
  • Host — хост wasmCloud;
  • Artifact — артефакт компонента в реестре.

Pod и Deployment

В модели оператора Deployment не нужен: его роль играет WorkloadDeployment. Ресурс держит нужное число реплик компонента и обновляет их по политике из поля deployPolicy. По умолчанию это последовательное обновление (rolling update): новые реплики поднимаются, затем замещают старые.

Обновление версии — смена ссылки image на новый тег или digest. Оператор обновляет реплики по этой политике. Откат — возврат прежней ссылки; digest не меняется, поэтому откат воспроизводим байт в байт.

Поды в этой модели — хосты. Чарт оператора поднимает группу подов-хостов с меткой hostgroup; рабочая нагрузка выбирает группу селектором hostSelector. Разные группы хостов изолируют нагрузки друг от друга или дают особые возможности — селектор решает, где жить компоненту.

Масштабирование — штатное. WorkloadDeployment реализует подресурс /scale, поэтому kubectl scale, Horizontal Pod Autoscaler и KEDA работают без специальных надстроек.

Service и Ingress

HTTP-трафик принимает обычный Service. Оператор поддерживает EndpointSlice этого сервиса: записи указывают на поды-хосты, где исполняется компонент. Стандартные DNS и маршрутизация кластера доводят запрос до компонента.

Ingress остаётся стандартным: правила маршрутизации HTTP лежат поверх Service. Оператору достаточно ссылки на сервис в спецификации нагрузки — поле kubernetes.service.name.

Пример манифеста

Минимальная нагрузка — один артефакт в реестре и один интерфейс:

apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: WorkloadDeployment
metadata:
  name: hello-world
spec:
  replicas: 1
  template:
    spec:
      hostSelector:
        hostgroup: default
      kubernetes:
        service:
          name: hello-world
      components:
        - name: hello-world
          image: registry.example/hello-world:0.1.0
      hostInterfaces:
        - namespace: wasi
          package: http
          interfaces:
            - incoming-handler

Прочтите поля так:

  • hostSelector.hostgroup — группа хостов, на которой планируется нагрузка; чарт оператора создаёт группу default;
  • kubernetes.service.name — сервис, чей EndpointSlice ведёт к компоненту;
  • components.image — ссылка на артефакт в реестре OCI: wash oci push из главы «Платформа» кладёт компонент именно туда;
  • hostInterfaces — интерфейсы WASI, которые хост предоставляет компоненту. Без явной записи интерфейс недоступен.

Конфигурация

Конфигурация приходит из среды, не из артефакта. Интерфейсу сопоставляется значение конфигурации — например, имя хоста, на котором компонент отвечает:

      hostInterfaces:
        - namespace: wasi
          package: http
          interfaces:
            - incoming-handler
          config:
            host: hello.example.com

Секреты хранятся в среде: в переменных, томах и внешних хранилищах секретов кластера. Артефакт .wasm секретов не содержит — это же правило действует в любой среде исполнения.

Ресурсы и масштабирование

Ресурсы компонента настраиваются в описании компонента нагрузки:

  • poolSize — число инстансов компонента в пуле хоста;
  • maxConcurrency — предел одновременных вызовов;
  • maxInvocations — предел вызовов на инстанс;
  • reclaimWindowSeconds — окно возврата неиспользуемых инстансов в пул.

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

Поды-хосты ограничиваются штатно — запросами и лимитами контейнера.

Диагностика

Начните с состояния нагрузки и хостов:

kubectl get workloaddeployments
kubectl get workloads
kubectl get pods

События планирования покажет kubectl describe — по ресурсу нагрузки или поду. Журналы хоста читает kubectl logs. Контракт артефакта перед запуском проверяет wash inspect — неожиданные импорты видны до развёртывания.

Открытый стек

Инфраструктура WasmBox: Yandex Serverless Containers, Cloud Functions и wasmCloud — описание технологии, не партнёрства. Эта глава описывает открытый стек, на котором платформа построена: манифесты Kubernetes из главы работают в любом кластере с оператором wasmCloud.

Цены

Два слагаемых: тариф платформы и счётчик реестра. Тариф платформы — фиксированная плата в месяц; реестр считается по потреблённым гигабайтам. Эта глава объясняет модель. Числа — на странице цен; модель между книгой и страницей одна.

Тариф платформы

Тариф платформы — виртуальная машина с песочницами WebAssembly. В тариф входят вычислительные ресурсы, пакет исходящего трафика и ширина канала:

  • vCPU, RAM, NVMe. Ресурсы машины: процессор, память и диск под компоненты и их данные.
  • Трафик. Пакет исходящего трафика на месяц; потреблённое сверх пакета — по ставке за гигабайт.
  • Канал. Потолок скорости одной машины; между песочницами он не делится.

Гостевая система — Ubuntu 22.04 LTS или Ubuntu 24.04 LTS: обе версии LTS доступны на любом тарифе без доплаты. Смена тарифа — в любой момент: стоимость пересчитывается пропорционально остатку месяца.

Тарифы — «Старт», «Бизнес», «Максимум»: от первой машины под первые публикации до машины под тяжёлые нагрузки. Ресурсы и цены — на странице цен.

Реестр по счётчику

Реестр хранит версии и раздаёт артефакты. Хранилище и исходящий трафик реестра считаются по счётчику: базовые объёмы включены в месяц, потреблённое сверх них — по ставкам страницы цен. Публикация версий не ограничена: каждая сборка — отдельный артефакт OCI-реестра.

Как управлять счётом

Счёт управляется двумя рычагами.

Выбирайте тариф под нагрузку. Пиковая нагрузка определяет ресурсы: память под компоненты, канал под трафик, диск под данные. Тариф меняется вместе с нагрузкой.

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

Частые вопросы

Чем отличаются версии Ubuntu? Для цены — ничем: обе версии LTS доступны на любом тарифе.

Как считается трафик? Исходящий трафик суммируется за месяц: пакет тарифа плюс потреблённое сверх него.

Что считается отдельно от тарифа? Хранение и исходящий трафик реестра — по счётчику; включённые объёмы и ставки — на странице цен.

Где смотреть тарифы

Тарифы, ставки реестра и ответы на частые вопросы — на странице цен.

Книга держит модель, страница цен — числа. Числа в книге устаревали бы первыми; модель живёт дольше.

Источники и лицензии

Сайт и платформа собраны из открытых технологий. Приложение перечисляет источники и лицензии. Прозрачность — правило платформы: читатель должен найти происхождение каждого чужого фрагмента. Чего нет в перечне — написано для этого сайта. Тексты лицензий приложены к файлам в комплекте сайта; внешняя ссылка в приложении одна — документация wasmCloud для сверки команд.

Форматы и стандарты

Платформа объединяет открытые форматы: WebAssembly — формат байт-кода, WASI — системные интерфейсы, OCI — хранение артефактов, wasmCloud — среда исполнения, wash — инструмент разработки, GraphQL — язык запросов. Форматы принадлежат сообществам и развиваются открыто; главы книги опираются на документацию wasmCloud и названные стандарты.

Графика карточек бенчмарков

Фигуры на карточках бенчмарков — SVG-сетки точек и CSS-контур с блоком памяти. Стоимость и прошедшее время обновляются через Anime.js. Разметка и подписи доступны без JavaScript; WebGPU для этих иллюстраций не требуется.

Шрифт Science Gothic

Заголовки и текст сайта набраны шрифтом Science Gothic. Авторские права — Font Detective LLC, © 2024; лицензия — SIL Open Font License 1.1, без зарезервированного имени шрифта. Текст лицензии лежит рядом с файлами шрифта в комплекте сайта.

Шрифт вариативный и разложен на подмножества письменностей: кириллицу, расширенную кириллицу, латиницу и расширенную латиницу. Каждая страница грузит только нужные подмножества.

Код, терминал и метки набраны системным моноширинным стеком — отдельной загрузки шрифта нет.

Библиотеки

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

  • Anime.js 4.5.0 — движение интерфейса; лицензия MIT.

В комплекте сайта также поставляются Chart.js 4.5.1 и @kurkle/color 0.6.0 (обе — под лицензией MIT); страницы сайта их не подключают. Модули поставляются по версиям и отдаются с сайта; исходные файлы пакетов сохранены без изменений, за исключением удалённой последней строки со ссылкой на source map. Каждой версии отведён свой каталог, поэтому обновление библиотеки не затрагивает остальное.

Логотипы инфраструктуры

Полоса технологий под первым экраном показывает официальные знаки технологий, на которых построена платформа:

  • WebAssembly — официальный знак из репозитория логотипов WebAssembly; CC0 1.0;
  • WASI — знак из репозитория wasi-logo, принятый рабочей группой WASI; CC0 1.0;
  • wasmCloud — официальный знак wasmCloud — инкубационного проекта CNCF; используется для идентификации проекта;
  • Yandex — словесная марка из общественного достояния (Wikimedia Commons).

Знаки нормализованы для полосы технологий: обрезаны поля viewBox, округлены координаты путей, сняты метаданные редакторов. Формы знаков не менялись. В тёмной теме словесная марка Yandex лежит на светлой плашке — чёрные буквы нечитаемы на графитовом фоне.

Товарные знаки

WebAssembly, WASI, wasmCloud и Yandex — товарные знаки их правообладателей. Знаки на сайте обозначают технологии, на которых построена платформа, и не означают поддержки или партнёрства.

Строка «Инфраструктура: Yandex Serverless Containers, Cloud Functions и wasmCloud.» описывает технологическую основу платформы — не партнёрство и не совместное предложение.

Команды wash

Команды wasmCloud Shell в главах «Начало» и «Платформа» сверены с официальной документацией wasmCloud — wasmcloud.com/docs. Сверка сделана при написании книги; за актуальными аргументами команд обращайтесь к справочнику команд wash той же документации.

Пример Hello World

Модуль Hello World на главной странице написан для этого сайта. Модуль собирается из исходного текста WAT, не имеет ни импортов, ни доступа к сети; чужой код в нём не используется.

Права на сайт

Тексты сайта, книга и иллюстрации бенчмарков — работа авторов WasmBox. © 2026 WasmBox. Книга открыта для чтения как часть документации платформы и не требует регистрации. Ошибки в атрибуции исправляются в следующих выпусках сайта.