Microsoft продолжает заниматься интересной работой с открытым исходным кодом через свою команду Deis Labs. Здесь вы найдете важные инструменты Kubernetes, такие как Helm и CNAB, а также набор интересных проектов WebAssembly. Наличие такой группы, как Деис, важно для Microsoft. Это позволяет Azure экспериментировать с новыми облачными технологиями без обязательств по их запуску, а также предоставляет полезную точку контакта с организациями по стандартизации и фондами с открытым исходным кодом.
Работа Дейса с WebAssembly особенно интересна. Понятно, что Microsoft обеспокоена ограничениями контейнеров как самого низкого уровня разработки облачных приложений. Значительные накладные расходы делают контейнеры непрактичными для многих периферийных приложений, особенно там, где в игру вступают небольшие устройства. Они представляют собой проблему в крупномасштабных распределенных приложениях, где вам нужна изоляция контейнеров, но вам не нужно запускать полную операционную систему, используя бессерверные модели за пределами традиционных бессерверных инфраструктур.
Расширение распределенных вычислений с помощью WebAssembly
Нам не следует удивляться, если Дейс продолжит экспериментировать с WebAssembly. Эта спецификация двоичной среды выполнения, размещаемой в браузере и движке JavaScript, отвечает многим требованиям, предъявляемым к альтернативе контейнерам. Это стандартная среда выполнения для нескольких языков, предлагающая хорошую изоляцию и быстрый запуск. Нет необходимости запускать целую операционную систему для размещения WebAssembly; все, что вам нужно, — это запустить браузер и разместить среду выполнения JavaScript.
Наряду с WebAssembly, размещаемым в браузере, системный интерфейс WebAssembly (WASI) позволяет ему работать автономно, поддерживая такие технологии, как Krustlets Деиса, которые представляют собой приложения WASI, управляемые Kubernetes. WASI также лежит в основе одного из новых экспериментов — интерфейса шлюза WebAssembly (WAGI).
WAGI может показаться возвратом к более старшему возрасту. В конце концов, он предлагает большую часть функций, которые изначально были предоставлены HTTP Common Gateway Interface (CGI). Знакомый всем, кто работал на заре Интернета, CGI позволял разработчикам расширять функциональность браузера с помощью встроенного кода, вызываемого из HTML. Он был предшественником PHP и JavaScript, обеспечивая раннюю интерактивность в Интернете и предоставляя инструменты, используемые для управления и запуска сайтов и сервисов электронной коммерции.
Кроме того, большую часть середины 1990-х годов я потратил на написание программного обеспечения на основе CGI для запуска одного из первых интернет-провайдеров, ориентированных на контент, прежде чем перейти к созданию более сложных систем электронной коммерции. Моим последним большим проектом CGI был набор скриптов Perl, которые запускали систему веб-карточек AOL UK. Его шаблонный код CGI, рассчитанный на один праздничный сезон, работал несколько лет и добавил в свою библиотеку множество сезонных событий. Так что у меня есть определенный личный интерес в возвращении этой концепции!
Представляем ВАГИ
Дейс взял идею обработчиков HTTP CGI и применил ее к WASI как способ создания серверной реализации поверх WASI. Это позволяет обойти некоторые ключевые архитектурные ограничения WASI, в частности отсутствие сетевого уровня и лежащую в его основе однопоточную природу. Это затрудняет использование WASI, поскольку в настоящее время он представляет собой платформу микросервисов.
У старой модели CGI есть ответ: она позволяет связывать сценарии с сервером и загружать их по мере необходимости. Их можно было написать на любом языке, используя переменные среды и параметры запроса для управления состоянием. Результатом стал гибкий инструмент, который позволил Интернету выйти за рамки базовой модели доставки контента и превратиться в полноценную платформу приложений. Вы, вероятно, оглянетесь на сайты и сервисы, которые мы создали в 1990-х годах, как на примитивные, но они выходили за рамки того, что можно было сделать в то время.
WAGI делает то же самое с WASI, превращая его в платформу, которая может динамически загружать код WASM, предоставляя среду для вызова, загрузки и выполнения модулей. Заголовки загружаются через переменные среды, параметры запроса — как параметры командной строки для модулей, при этом полезные данные HTTP загружаются через стандартный ввод, а выходные данные — через стандартный вывод. Использование этих простых, хорошо понятных методов работы с WASM упрощает проектирование и разработку интерфейса, предоставляя необходимые инструменты для работы WASM в качестве легковесного сервера.
Дейс принял некоторые решения, которые отличают WAGI от CGI, уделяя особое внимание безопасности и контролю доступа к хост-системе и из нее. Целью здесь является предотвращение запуска вредоносного кода, поскольку модули WAGI распространяются в виде двоичных файлов и могут быть получены от третьих лиц. Модули не получают полного доступа к файловой системе; без явных разрешений они не смогут устанавливать исходящие сетевые подключения. Они могут получать доступ только к переменным среды, переданным в среду WASI, и не могут вызывать дополнительные исполняемые файлы.
Настройка сервера WAGI
Начать работу с WAGI довольно просто. Вы можете загрузить двоичный файл сервера со страницы выпусков GitHub или создать свой собственный, скомпилировав его в WebAssembly с помощью Rust. В настоящее время WAGI лучше всего запускать в Linux, хотя доступны сборки для Windows, которые тестируются Deis. Поскольку WAGI — это приложение Rust, у вас есть возможность запустить его из исходного кода, а не создавать двоичный файл.
После сборки и установки вы можете начать экспериментировать с WAGI. Это инструмент командной строки, поэтому вам необходимо изучить его флаги. Одной из полезных функций является поддержка другого проекта Deis, Bindle. Это способ объединения всех объектов, необходимых для запуска приложения, в качестве альтернативы файлу конфигурации его модулей. Bindle — это гибкий и мощный инструмент, но, как и WAGI, он находится в стадии разработки, и вы можете предпочесть настроить WAGI с помощью более традиционного файла конфигурации.
Вам нужно будет настроить имя хоста и используемый порт, а также IP-адрес, используемый для прослушивания запросов. Другие элементы конфигурации включают каталог, используемый для кэширования двоичных модулей WASM, и любые общие переменные среды: например, секреты, необходимые для доступа к удаленным службам.
Большая часть вашей конфигурации находится в файле Modules.toml WAGI. Это определяет маршруты, используемые для доступа к модулям, которые предоставляют пользователям URL-адреса для доступа к вашему коду. Затем вы предоставляете ссылку на локальную файловую систему модуля, чтобы WAGI мог загрузить его при вызове. В то же время файл конфигурации может определять точку входа в модуль, позволяя вызывать определенную функцию. Это позволяет одному модулю содержать несколько функций, каждая из которых определена в отдельной функции. Деис допускает здесь расширение, поскольку для репозиториев есть зарезервированная запись, предполагая, что в будущем вы сможете динамически загружать модули по мере их обновления в центральные репозитории. Уже поддерживается использование реестров OCI для загрузки модулей, если вы хотите сделать WAGI конечной точкой конвейера непрерывной интеграции и непрерывной доставки (CI/CD).
Модули можно даже настроить для получения явного доступа к определенным каталогам, что позволит им работать напрямую с ресурсами сервера. Это можно использовать для предоставления доступа к ресурсам, используемым для создания контента, например изображений. Любые необходимые переменные среды передаются через командную строку как часть вызова WAGI. Переменные среды, которые должны быть общими для всех модулей, можно сохранить в дополнительном файле конфигурации и загрузить во время выполнения.
Написание вашего первого модуля WAGI
Написание модулей так же просто, как и их настройка. Вы не ограничены каким-либо одним языком. Пока он компилируется в Wasm32-Wasi, его можно использовать с WAGI. Здесь очень мало сложностей и нет необходимости в специализированных библиотеках, поскольку все управляется с помощью стандартных операций ввода-вывода. Все, что вам нужно сделать, это прочитать стандартный ввод и вывести вывод на стандартный вывод. Если вы помните, как писать CGI-приложения, вы сможете писать модули WAGI. Единственное реальное ограничение — это форматирование выходных данных таким образом, чтобы их можно было доставлять в виде ответов HTTP. Это означает предоставление заголовка типа контента и пустой строки перед добавлением контента.
Результатом является знакомый и практичный способ расширения веб-серверов, добавляя динамический контент там, где это необходимо, и предоставляя периферийным устройствам возможность доставлять форматированный контент. Последний пункт, пожалуй, самый важный. WAGI — это упрощенный способ доставки веб-контента, а форматированный HTML — это эффективный способ управления выходными данными, который может быть проанализирован любым клиентом. Можно представить себе конечную точку WAGI на периферийном устройстве, которая доставляет отформатированные данные в ответ на запрос приложения управления, или высокораспределенное приложение на основе WAGI, которое использует как можно меньше облачных ресурсов, сводя затраты к минимуму.
Важно иметь относительно простой способ создания и развертывания кода на периферийных устройствах. Все, что необходимо реализовать в прошивке вашего устройства, — это сервер WAGI и среда выполнения WASI; Модули можно загружать через любое IP-соединение из реестра Open Container и кэшировать на вашем устройстве, обновляя по мере выпуска новых выпусков. Будущая поддержка технологий описания пакетов, таких как Bindle, должна еще больше упростить этот процесс за счет общего описания ресурсов и контента, которые можно будет загрузить при запуске.
