WebAssembly: Docker sin contenedores

​Este artículo
está autorizado para ser traducido del blog de Wasm Labs @ VMware OCTO: WebAssembly: Docker sin contenedor. Esta es una transcripción de la charla de Wasm Labs sobre Docker+WebAssembly en Winter Docker Community All Hands 7 el 15 de diciembre de 2022.
Por Asen Alexandrov, ingeniero de Wasm Labs
Todas las referencias a nosotros en este artículo son al autor o a Wasm Labs. Este artículo primero explica conceptos, como qué es Wasm y cuál es la relación entre Wasm y Docker, y luego toma PHP como ejemplo para llevar a todos a practicar Docker + Wasm.

Recientemente, Docker anunció una asociación con WasmEdge para respaldar WebAssembly.

https://github.com/WasmEdge/WasmEdge

Este artículo explicará qué es WebAssembly (Wasm), por qué es relevante para el ecosistema Docker y le brindará algunos ejemplos prácticos para que los pruebe. Suponemos que ya está familiarizado con las herramientas de Docker. Usaremos nuestro trabajo en el puerto WebAssembly de PHP para demostrar cómo construir un intérprete PHP, empaquetarlo como parte de una imagen OCI y ejecutarlo con Docker.

Tenga en cuenta que este artículo se centra en la experiencia práctica en lugar de discutir detalles técnicos.

¿Qué es WebAssembly? ¿Por qué elegirlo?
Esta sección es una introducción muy básica a WebAssembly. Los amigos que ya estén familiarizados con Wasm pueden revisarlo rápidamente.

¿Qué es WebAssembly?
WebAssembly es un estándar abierto que define un formato de instrucción binaria que permite la creación de ejecutables binarios portátiles desde diferentes lenguajes fuente. Estos binarios se pueden ejecutar en varios entornos. Se originó en la Web y es compatible con los principales navegadores.

¿Cómo funciona Wasm en el navegador?
Los motores de navegador integran una máquina virtual Wasm, a menudo llamada tiempo de ejecución de Wasm, que puede ejecutar instrucciones binarias de Wasm. Las cadenas de herramientas del compilador como Emscripten pueden compilar el código fuente en objetivos Wasm. Esto permite que las aplicaciones existentes se transfieran al navegador y se comuniquen directamente con el código JS que se ejecuta en la aplicación web del cliente.

Estas tecnologías permiten que las aplicaciones de escritorio tradicionales se ejecuten en el navegador. Ahora pueden ejecutarse en cualquier dispositivo con un navegador. Algunos ejemplos notables incluyen Google Earth y la biblioteca Open CV para visión por computadora.

¿Cómo funciona Wasm en el servidor?
Además de los navegadores, también existen tiempos de ejecución de Wasm que pueden ejecutarse fuera de los navegadores, incluidos los sistemas operativos tradicionales como Linux, Windows y macOS. Como no pueden confiar en el motor JavaScript disponible, utilizan una interfaz diferente para comunicarse con el mundo exterior, como WASI (WebAssembly System Interface). Estos tiempos de ejecución permiten que las aplicaciones Wasm interactúen con su sistema host de una manera similar (pero no idéntica) a POSIX. Proyectos como WASI SDK y wasi-libc ayudan a las personas a compilar aplicaciones existentes compatibles con POSIX en WebAssembly.

Solo necesita compilar su aplicación una vez en un módulo Wasm y luego este mismo binario se puede ejecutar en cualquier lugar.

¿Qué tiene de bueno Wasm?
Las siguientes características hacen que Wasm brille en el navegador y también lo hacen ventajoso para el desarrollo del lado del servidor:

Abierto: es un estándar ampliamente adoptado en la industria. A diferencia de batallas de navegadores pasadas, las empresas están colaborando activamente para estandarizar las aplicaciones WASI y WebAssembly.

Rápido: puede proporcionar una velocidad similar a la nativa a través de las capacidades JIT/AOT de la mayoría de los tiempos de ejecución. A diferencia del inicio de una máquina virtual o de un contenedor, no existe un inicio en frío.

Seguridad: de forma predeterminada, el tiempo de ejecución de Wasm está protegido, lo que permite el acceso seguro a la memoria. Un modelo basado en capacidades garantiza que las aplicaciones Wasm solo puedan acceder a lo que está explícitamente permitido. La cadena de suministro de software es más segura.

Portátil: varios de los principales tiempos de ejecución de Wasm son compatibles con la mayoría de las CPU (x86, ARM, RISC-V) y la mayoría de los sistemas operativos, incluidos Linux, Windows, macOS, Android, ESXi e incluso sistemas operativos que no son Posix.

Eficiente: huella de memoria mínima y umbral de CPU más bajo para ejecutar aplicaciones Wasm.

️ Soporte multilingüe: más de 40 lenguajes de programación se pueden compilar en Wasm, con una cadena de herramientas moderna y en constante mejora.

¿Qué sigue en la evolución de las plataformas de servidores?
Quizás hayas visto esta cita de Solomon Hykes (uno de los creadores de Docker):

Si ya existiera WASM+WASI en 2008, no habríamos necesitado crear Docker en absoluto. Wasm es así de importante. WebAssembly en el lado del servidor es el futuro de la informática.
De hecho, WASM+WASI parece ser el siguiente paso en la evolución de la infraestructura de software del lado del servidor.

Al principio teníamos hardware físico con el que trabajar. Instalaremos cuidadosamente el sistema operativo y las aplicaciones para cada servidor en la sala de computadoras y los mantendremos uno por uno.
Luego se volvió más fácil con la adopción de máquinas virtuales de la que VMware fue pionera. Se pueden copiar, clonar y mover máquinas virtuales entre máquinas de hardware. Pero esto aún requiere que el sistema operativo y las aplicaciones estén instalados en la VM.
Luego vinieron los contenedores popularizados por Docker, que facilitaron la ejecución de configuraciones de aplicaciones en un contexto mínimamente empaquetado sin afectar ninguna otra aplicación en el sistema operativo host. Sin embargo, todavía es necesario distribuir la aplicación junto con su tiempo de ejecución y las bibliotecas necesarias. Los límites de seguridad los proporciona el kernel de Linux.
Ahora con WebAssembly. Sus características técnicas y portabilidad permiten distribuir aplicaciones sin dependencias a nivel de sistema operativo y ejecutarlas bajo estrictas restricciones de seguridad.
Teniendo en cuenta todo esto, los desarrolladores suelen ver a WebAssembly como el "sucesor" de los contenedores y el siguiente paso natural para la implementación de infraestructura.

Sin embargo, otra forma de ver WebAssembly es como otra opción de "backend" para las herramientas de Docker. Se pueden utilizar las mismas herramientas de línea de comandos y flujo de trabajo para reemplazar los contenedores de Linux con el equivalente de contenedores basados ​​en WebAssembly. El resto de este artículo explora este concepto, que es lo que el título llama "Docker sin contenedores".

¿Cómo funciona Wasm con Docker?
Docker Desktop ahora incluye soporte para WebAssembly. Se implementa a través de un shim contenedor que puede ejecutar aplicaciones Wasm utilizando un tiempo de ejecución de Wasm llamado WasmEdge. Esto significa que ahora es posible ejecutar aplicaciones Wasm dentro del tiempo de ejecución de WasmEdge (que emula un contenedor), en lugar de que un contenedor típico de Windows o Linux ejecute un proceso separado del binario en la imagen del contenedor.

Por lo tanto, una imagen de contenedor no necesita contener el sistema operativo o el contexto de tiempo de ejecución de una aplicación en ejecución; un único binario Wasm es suficiente.

Esto se explica en detalle en el artículo de Docker's Wasm Technology Preview.

¿Qué es WasmEdge?
WasmEdge es un tiempo de ejecución de WebAssembly de alto rendimiento:

Es de código abierto y pertenece a CNCF.
Se admiten todas las arquitecturas de CPU principales (x86, ARM, RISC-V).
Se admiten todos los principales sistemas operativos (Linux, Windows, macOS), así como otros como seL4 RTOS y Android.
Optimizado para aplicaciones perimetrales y nativas de la nube.
Escalable y compatible con la inferencia de IA de tecnologías estándar y emergentes
utilizando Tensorflow, OpenVINO y
la red asíncrona de PyTorch Tokio. Admite microservicios, clientes de bases de datos, colas de mensajes y más.
Integre perfectamente con el ecosistema de contenedores, Docker y Kubernetes (¡como se muestra en este artículo!). ¿
Qué pasa con los lenguajes interpretados?
Hasta ahora solo hemos mencionado que los lenguajes compilados como C y Rust pueden compilarse en WebAssembly. Para lenguajes interpretados como Python, Ruby y PHP, el enfoque es diferente: sus intérpretes están escritos en C y se compilan en WebAssembly. El Wasm compilado en este intérprete se puede usar para ejecutar archivos de código fuente, que generalmente terminan en .py, .rb, .php, etc. Una vez compilado en Wasm, cualquier plataforma con un tiempo de ejecución de Wasm podrá ejecutar estos lenguajes interpretados, incluso si el intérprete real nunca se compiló de forma nativa para esa plataforma.

A continuación se presentará cómo compilar Wasm con el intérprete PHP, empaquetarlo en una imagen OCI y ejecutar la imagen OCI usando Docker Desktop con WasmEdge integrado. También presentaremos las diferencias entre los contenedores tradicionales y los contenedores Wasm.

Ejemplo práctico ¡
Comencemos! En nuestro ejemplo práctico, usaremos el intérprete PHP compilado en Wasm. Lo haremos:

Construye un contenedor Wasm.
Compare Wasm y los binarios nativos.
Compare los contenedores tradicionales y los contenedores Wasm. Demostración de los requisitos previos
de portabilidad de Wasm Para reproducir estos ejemplos localmente, deberá preparar su entorno con algunos o todos los siguientes elementos:

WASI SDK: crea aplicaciones WebAssembly a partir de código C
PHP: ejecuta binarios PHP nativos para comparar
WasmEdge Runtime: ejecuta aplicaciones WebAssembly
Docker Desktop + Wasm (disponible como versión beta estable en Docker Desktop 4.15 en el momento de escribir este artículo): capacidad para ejecutar contenedores
Wasm También aproveche el repositorio webassembly-language-runtimes, que proporciona una forma de crear un intérprete PHP como una aplicación WebAssembly. La rama de demostración se puede ver así:

git clone -- Depth=1 -b php-wasmedge-demo
https://github.com/vmware-labs/webassembly-language-runtimes.git wlr-demo
cd wlr-demo
Construya un contenedor Wasm
El primer ejemplo, lo haremos muestre cómo construir una aplicación basada en C, como un intérprete de PHP.

La compilación utiliza el conjunto de herramientas WASI-SDK. Incluye un compilador clang que puede compilarse en el destino wasm32-wasi y wasi-libc que implementa la interfaz básica de llamadas al sistema POSIX sobre WASI. Usando WASI SDK, podemos construir un módulo Wasm escrito en C a partir del código base PHP. Después de eso, necesitamos un Dockerfile muy simple basado en scratch para crear una imagen OCI que pueda ejecutarse con Docker+Wasm.

Construyendo un binario WASM
Suponiendo que ahora está en la carpeta wlr-demo, como parte de los preliminares, puede ejecutar el siguiente comando para construir el binario Wasm.

exportar WASI_SDK_ROOT=/opt/wasi-sdk/
exportar WASMLABS_RUNTIME=wasmedge

./wl-make.sh php/php-7.4.32/ && árbol build-output/php/php-7.4.32/bin/

... (unos minutos y cientos de líneas de registro de compilación)

build-output/php/php-7.4.32/bin/
├── php-cgi-wasmedge
└── php-wasmedge
PHP está construido con autoconf y make. Entonces, si echa un vistazo al script scripts/wl-build.sh, notará que configuramos todas las variables relevantes como CC, LD, CXX, etc. para usar el compilador de WASI_SDK.

exportar WASI_SYSROOT=" $WAS{I}_{}DK{\_}_{}OOT/compartir/wasi\_\_-sysroot"expotCC\_=$ {WASI_SDK_ROOT}/bin/clang
export LD=$WAS{I}_{}DK{\_}_{}OOT/bin/wasm-ldexpotCXX=$ {HOME_SDK_ROOT}/bin/clang++
exportar NM=$WAS{I}_{}DK{\_}_{}OOT/bin/llvm-nmexpotAR=$ {WASI_SDK_ROOT}/bin/llvm-ar
export RANLIB=${WASI_SDK_ROOT}/bin/llvm-ranlib
Luego, profundizando en php/php-7.4.32/wl-build.sh, puedes ver que, como de costumbre, Utilice el proceso de compilación de autoconf.

./configure --host=wasm32-wasi host_alias=wasm32-musl-wasi
–target=wasm32-wasi target_alias=wasm32-musl-wasi
${PHP_CONFIGURE} || salida 1
…
make -j ${MAKE_TARGETS} || salida 1
WASI es un trabajo en progreso y muchas llamadas POSIX aún no se pueden implementar sobre él. Por lo tanto, para construir PHP, tuvimos que aplicar varios parches además del código base original.

Vemos arriba que el binario de salida va a build-output/php/php-7.4.32. En los ejemplos siguientes, usaremos el binario php-wasmedge creado específicamente para WasmEdge, ya que proporciona soporte de socket del lado del servidor, que aún no forma parte de WASI.

Binarios optimizados
Wasm es un conjunto de instrucciones virtuales, por lo que el comportamiento predeterminado de cualquier tiempo de ejecución es interpretar esas instrucciones sobre la marcha. Por supuesto, esto podría ralentizar el proceso en algunos casos. Entonces, para obtener lo mejor de ambos mundos con WasmEdge, puede crear un binario optimizado AOT (compilado con anticipación) que se ejecute de forma nativa en la máquina actual pero que aún pueda interpretarse en otras máquinas.

Para crear archivos binarios optimizados, ejecute el siguiente comando:

wasmedgec --enable-all --optimize 3
build-output/php/php-7.4.32/bin/php-wasmedge
build-output/php/php-7.4.32/bin/php-wasmedge-aot
estamos en el El siguiente ejemplo utiliza este código binario build-output/php/php-7.4.32/bin/php-wasmedge-aot. Para obtener más información sobre los archivos binarios optimizados para WasmEdge AOT, consulte aquí.

Construyendo la imagen OCI
Ahora que tenemos un binario, podemos envolverlo en una imagen OCI. Echemos un vistazo a estas imágenes/php/Dockerfile.cli. Todo lo que tenemos que hacer es copiar el binario Wasm y configurarlo como PUNTO DE ENTRADA.

DESDE cero
ARG PHP_TAG=php-7.4.32
ARG PHP_BINARY=php
COPIAR build-output/php/ $P.H.P.\_{\_}_{}AG/bin/$ {PHP_BINARY} /php.wasm

PUNTO DE ENTRADA [ “php.wasm” ]

También podemos agregar más contenido a la imagen al que el binario Wasm puede acceder cuando Docker lo ejecuta. Por ejemplo, en images/php/Dockerfile.server también agregamos contenido de docroot, que php.wasm proporciona cuando se inicia el contenedor.

DESDE cero
ARG PHP_TAG=php-7.4.32
ARG PHP_BINARY=php
COPIAR build-output/php/ $P.H.P.\_{\_}_{}AG/bin/$ {PHP_BINARY} /php.wasm
COPIAR imágenes/php/docroot /docroot

ENTRYPOINT [ "php.wasm", "-S", "0.0.0.0:8080", "-t", "/docroot"]
Basándonos en los archivos anteriores, podemos construir fácilmente nuestra imagen php-wasm localmente.

docker build --build-arg PHP_BINARY=php-wasmedge-aot -t ghcr.io/vmware-labs/php-wasm:7.4.32-cli-aot -f images/php/Dockerfile.cli.docker
build --build -arg PHP_BINARY=php-wasmedge-aot -t ghcr.io/vmware-labs/php-wasm:7.4.32-server-aot -f images/php/Dockerfile.server
Nativo vs Wasm
Ahora conviertamos el binario PHP nativo Los archivos se comparan con el binario Wasm tanto localmente como en el contenedor Docker. Usaremos el mismo archivo index.php y compararemos lo que obtenemos cuando lo ejecutamos con lo siguiente:

php
php-wasmedge-aot
php ejecutándose en contenedores tradicionales
php-wasmedge-aot ejecutándose en contenedores Wasm

En todos los ejemplos siguientes utilizamos el mismo archivo images/php/docroot/index.php, echemos un vistazo. En resumen, el guión:

Utilice phpversion y php_uname para mostrar la versión del intérprete y la plataforma en la que se está ejecutando.
Imprima los nombres de todas las variables de entorno a las que el script tiene acceso.
Imprima un mensaje de saludo con la hora y fecha actuales.
Enumere el contenido de la carpeta raíz /

Hola desde PHP <?php echo phpversion() ?> ejecutándose en "<?php echo php_uname()?>"

Listar nombres de variables ambientales

<?php $php_env_vars_count = contar(getenv()); echo "Ejecutando con variables de entorno $php_env_vars_count:\n"; foreach (getenv() as $clave => $valor) { echo $clave. " "; } eco "\n"; ?>

Hola

<?php $fecha = getdate();

$mensaje = "Hoy", . $fecha['día laborable'] . ", ". $fecha['año'] . "-" . $fecha['mon'] . "-" . $fecha['mday'];
$mensaje .= “, a las " . $fecha['horas'] . “:” . $fecha['minutos'] . “:” . $fecha['segundos']; $mensaje .= " te saludamos
con este mensaje!\n”;
eco $mensaje;
?>

Contenido de '/'

<?php foreach (array_diff(scandir('/'), array('.', '..')) as $clave => $valor) { echo $valor . " "; } eco "\n"; ?>

PHP nativo ejecutando index.js
Vemos una plataforma basada en Linux mientras usamos el binario php nativo.

Lista de 58 variables de entorno a las que los scripts pueden acceder si es necesario
Lista de todos los archivos y carpetas en / a los que los scripts pueden acceder nuevamente si es necesario
$ php -f images/php/docroot/index.php

Hola desde PHP 7.4.3 ejecutándose en "Linux alexandrov-z01 5.15.79.1-microsoft-standard-WSL2 #1 SMP miércoles 23 de noviembre 01:01:46 UTC 2022 x86_64"

Listar nombres de variables ambientales

Ejecutándose con 58 variables de entorno: SHELL NVM_INC WSL2_GUI_APPS_ENABLED rvm_prefix WSL_DISTRO_NAME TMUX rvm_stored_umask TMUX_PLUGIN_MANAGER_PATH MY_RUBY_HOME NOMBRE RUBY_VERSION PWD NIX_PROFILES LOGNAME rvm_version rvm_user_install_flag MOTD_SHOWN HOME LANG WSL_INTEROP LS_COLORS WASMTIME_HOME WAYLAND_DISPLAY NIX_SSL_CERT_FILE PROMPT_COMMAND NVM_DIR rvm_bin_path GEM_PATH GEM_HOME LESSCLOSE TERM CPLUS_INCLUDE_PATH LESSOPEN USER TMUX_PANE LIBRARY_PATH rvm_loaded_flag DISPLAY SHLVL NVM_CD _FLAGS LD_LIBRARY_PATH XDG_RUNTIME_DIR PS1 WSLENV XDG_DATA_DIRS PATH DBUS_SESSION_BUS_ADDRESS C_INCLUDE_PATH NVM_BIN HOSTTYPE WASMER_CACHE_DIR IRBRC PULSE_SERVER rvm_path WASMER_DIR OLDPWD BASH_FUNC_cr-open%% _

Hola

¡Hoy miércoles 14-12-2022 a las 12:0:36 los saludamos con este mensaje!

Contenido de '/'

aplicaciones bin boot dev docroot etc inicio inicio lib lib32 lib64 libx32 medios perdidos+encontrados mnt nix opt path proc root run sbin snap srv sys tmp usr var wsl.localhost php-aot-wasm ejecute index.js si usamos php-aot en WasmEdge -cómo vemos

Una plataforma wasi/wasm32
no tiene variables de entorno porque no está expuesta explícitamente a las aplicaciones Wasm.
Las aplicaciones Wasm no tienen acceso explícito a /, por lo que los intentos de enumerar su contenido fallan con errores.
Naturalmente, para que php-wasmedge-aot pueda Para leer el archivo index.php, debemos declarar explícitamente a WasmEdge que queremos abrir previamente imágenes/php/docroot para acceder como /docroot en el contexto de la aplicación Wasm. Esto demuestra claramente una de las mayores fortalezas de Wasm además de la portabilidad. Obtenemos una mayor seguridad porque no se puede acceder a nada a menos que se indique explícitamente.

$ wasmedge --dir /docroot:$(pwd)/images/php/docroot
build-output/php/php-7.4.32/bin/php-wasmedge-aot -f /docroot/index.php

Hola desde PHP 7.4.32 ejecutándose en "wasi (ninguno) 0.0.0 0.0.0 wasm32"

Listar nombres de variables ambientales

Ejecutando con 0 variables de entorno:

Hola

¡Hoy miércoles 14-12-2022 a las 10:8:46 los saludamos con este mensaje!

Contenido de '/'

Advertencia: scandir(/): no se pudo abrir el directorio: Capacidades insuficientes en /docroot/index.php en la línea 27

Advertencia: scandir(): (errno 76): Capacidades insuficientes en /docroot/index.php en la línea 27

Advertencia: array_diff(): Se espera que el parámetro 1 sea una matriz, bool dado en /docroot/index.php en la línea 27

Advertencia: Argumento no válido proporcionado para foreach() en /docroot/index.php en la línea 27

PHP en un contenedor ejecutando index.js
Cuando usamos php desde un contenedor tradicional vemos

Plataformas basadas en Linux
Lista de 14 variables de entorno a las que el script
tiene acceso Mensaje de saludo con fecha y hora actuales
Lista con el contenido de la carpeta raíz /
En comparación con ejecutarlo con php en el host, ya es notablemente diferente y tiene un mejor rendimiento. Dado que las variables de entorno y el contenido de / son "virtuales" y solo existen dentro del contenedor.

ventana acoplable ejecutar --rm
-v $(pwd)/images/php/docroot:/docroot
php:7.4.32-cli
php -f /docroot/index.php

Hola desde PHP 7.4.32 ejecutándose en "Linux 227b2bc2f611 5.15.79.1-microsoft-standard-WSL2 #1 SMP miércoles 23 de noviembre 01:01:46 UTC 2022 x86_64"

Listar nombres de variables ambientales

Ejecutando con 14 variables de entorno: HOSTNAME PHP_INI_DIR HOME PHP_LDFLAGS PHP_CFLAGS PHP_VERSION GPG_KEYS PHP_CPPFLAGS PHP_ASC_URL PHP_URL PATH PHPIZE_DEPS PWD PHP_SHA256

Hola

¡Hoy miércoles 14-12-2022 a las 10:15:35 los saludamos con este mensaje!

Contenido de '/'

bin boot dev docroot etc home lib lib64 media mnt opt ​​proc root run sbin srv sys tmp usr var php-aot-wasm para ejecutar index.js en un contenedor si usamos php-aot-wasm en WasmEdge vemos

Una plataforma wasi/wasm32
con solo 2 variables de entorno de infraestructura, utiliza la corrección WasmEdge que se ejecuta en contenedor para preestablecer
una lista de todos los archivos y carpetas dentro del contenedor, abierta previamente explícitamente para el acceso de la aplicación Wasm (lógica en el Parte de la cuña WasmEdge)
NOTA: Si observa detenidamente, para ejecutar un contenedor desde esta imagen, tenemos que:

Pasar argumentos de línea de comandos directamente a php.wasm mediante --runtime=io.containerd.wasmedge.v1 declara explícitamente el tiempo de ejecución, sin incluir el binario en sí. Haciendo arriba podemos ver que podemos escribir explícitamente el comando completo, incluido el binario php (no requerido), usando un contenedor PHP tradicional.
Como nota final, incluso con Docker, Wasm refuerza la seguridad al ejecutar index.php porque hay mucho menos expuesto a él.

ejecución de la ventana acoplable --rm
–runtime=io.containerd.wasmedge.v1
-v $(pwd)/images/php/docroot:/docroot
ghcr.io/vmware-labs/php-wasm:7.4.32-cli-aot
- f /docroot/index.php

Hola desde PHP 7.4.32 ejecutándose en "wasi (ninguno) 0.0.0 0.0.0 wasm32"

Listar nombres de variables ambientales

Ejecutando con 2 variables de entorno: PATH HOSTNAME

Hola

¡Hoy miércoles 14-12-2022 a las 11:33:10 los saludamos con este mensaje!

Contenido de '/'

docroot, etc. php.wasm

Contenedores tradicionales versus contenedores Wasm
Construimos y ejecutamos un binario Wasm y lo ejecutamos como un contenedor. Vimos la diferencia en la producción entre Wasm y los contenedores tradicionales y el avanzado "aislamiento de zona de pruebas" que ofrece Wasm. Otras diferencias entre ambos contenedores que podemos ver fácilmente.

Primero, ejecutaremos dos contenedores de demonios y veremos cómo podemos interpretar algunas estadísticas sobre ellos. Luego comprobaremos la imagen del contenedor para detectar diferencias.

Datos del contenedor
Ejecutemos dos contenedores demonio: uno desde la imagen php tradicional y el otro desde la imagen php-wasm.

docker run --rm -d
-p 8083:8080 -v $(pwd)/images/php/docroot:/docroot
php:7.4.32-cli
-S 0.0.0.0:8080 -t /docroot
docker run --rm -d
–runtime=io.containerd.wasmedge.v1
-p 8082:8080 -v $(pwd)/images/php/docroot:/docroot
ghcr.io/vmware-labs/php-wasm:7.4.32-cli- aot
-S 0.0.0.0:8080 -t /docroot
pero si miramos las estadísticas de Docker solo vemos datos de contenedores heredados. Esto puede cambiar más adelante, ya que Docker+Wasm ahora es una función beta. Entonces, si realmente quieres ver qué está pasando, puedes monitorear el grupo de control. Cada contenedor tradicional tiene su propio grupo de control como docker/ee44…. Por otro lado, los contenedores Wasm se incluyen como parte de los grupos de control podruntime/docker, y su consumo de CPU o memoria se puede observar de forma indirecta.

$ systemd-cgtop -kP --profundidad=10

Tareas del grupo de control %CPU Memoria
podruntime 145 0.1 636.3M
podruntime/docker 145 0.1 636.3M
docker 2 0.0 39.7M
docker/ee444b… 1 0.0 6.7M
Tamaño de imagen
Primero, explorando las imágenes, vemos que las imágenes del contenedor Wasm son mucho más pequeñas que las tradicionales. imágenes. Incluso la versión alpina del contenedor php es más grande que el contenedor Wasm.

Imágenes de $docker

ETIQUETA DEL REPOSITORIO ID DE IMAGEN TAMAÑO CREADO
php 7.4.32-cli 680c4ba36f1b Hace 2 horas 166 MB
php 7.4.32-cli-alpine a785f7973660 Hace 2 minutos 30,1 MB
ghcr.io/vmware-labs/php-wasm 7.4.32-cli-aot 63460740f6d 5 Hace 44 minutos 5.35MB

Esto es de esperarse porque con Wasm solo necesitamos agregar binarios ejecutables dentro del contenedor, mientras que con los contenedores tradicionales todavía necesitamos algunas bibliotecas y archivos básicos del sistema operativo en el que se ejecutan los binarios. Esta diferencia de tamaño es muy útil para la velocidad de extracción de la primera imagen y el espacio que ocupa en el repositorio local.

Portabilidad de Wasm
Una de las mayores fortalezas de Wasm es su portabilidad. Docker ya ofrece contenedores tradicionales como una opción cuando la gente quiere una aplicación portátil. Sin embargo, además de ser imágenes extremadamente grandes, los contenedores tradicionales también están vinculados a la arquitectura de la plataforma en la que se ejecutan. Como programadores, muchas personas han experimentado estos altibajos: para diferentes arquitecturas, es necesario crear versiones de software compatibles y empaquetar las imágenes correspondientes para cada arquitectura.

WebAssembly ofrece verdadera portabilidad. Cree un binario una vez y ejecútelo en cualquier lugar. Como demostración de esta portabilidad, preparamos varios ejemplos de ejecución de WordPress a través del intérprete PHP que creamos para WebAssembly.

Cuando PHP se ejecuta como una aplicación Wasm independiente, sirve a WordPress. También puede ejecutarse en un contenedor Docker+Wasm. Además, puede ejecutarse en cualquier aplicación que incorpore el tiempo de ejecución de Wasm. En nuestro caso, se trata de Apache httpd, que puede utilizar aplicaciones Wasm como controladores de contenido a través de mod_wasm. Finalmente, PHP.wasm también se puede ejecutar en el navegador.

Sirviendo WordPress a través de WasmEdge
Hemos preparado un ejemplo compacto de WordPress+Sqlite para esta demostración. Dado que es parte de la imagen del contenedor ghcr.io/vmware-labs/php-wasm:7.4.32-server-wordpress, primero la descargamos localmente.

Este comando simplemente creará un contenedor temporal (extrayendo la imagen), copiará los archivos de WordPress a /tmp/wp/docroot y eliminará el contenedor.

contenedor_id=$(docker create ghcr.io/vmware-labs/php-wasm:7.4.32-server-wordpress) &&
mkdir /tmp/wp &&
docker cp $container_id:/docroot /tmp/wp/ &&
docker rm $container_id
Ahora que tenemos WordPress, agreguemos el servidor:

wasmedge --dir /docroot:/tmp/wp/docroot
build-output/php/php-7.4.32/bin/php-wasmedge-aot
-S 0.0.0.0:8085 -t /docroot
puede visitar http://localhost :8085, utilizando WordPress servido por el intérprete PHP Wasm.

Servir WordPress a través de Docker+Wasm
Naturalmente, será mucho más fácil con Docker.

ejecución de la ventana acoplable --rm --runtime=io.containerd.wasmedge.v1
-p 8086:8080 -v /tmp/wp/docroot/:/docroot/
ghcr.io/vmware-labs/php-wasm:7.4.32- cli-aot
-S 0.0.0.0:8080 -t /docroot

Puede visitar http://localhost:8086 y utilizar WordPress servido por el intérprete PHP Wasm, esta vez ejecutándose en un contenedor Docker.

Sirviendo WordPress con mod_wasm en Apache HTTPD
Apache HTTPD es uno de los servidores HTTP más utilizados. Ahora con mod_wasm también puede ejecutar aplicaciones WebAssembly. Para evitar tener que instalarlo y configurarlo localmente, preparamos un contenedor que contiene Apache HTTPD, mod_wasm y WordPress.

docker run -p 8087:8080 proyectos.registry.vmware.com/wasmlabs/containers/php-mod-wasm:wordpress
puede acceder a http://localhost:8087 y usar WordPress servido por el intérprete PHP Wasm, que es servido por Apache HTTPD mod_wasm en carga.

Para servir WordPress directamente en su navegador,
visite https://wordpress.wasmlabs.dev para ver ejemplos. Verá un marco donde el intérprete PHP Wasm muestra WordPress en vivo.

Conclusión
Gracias por leer este artículo. Es mucho para digerir, pero esperamos que este artículo le ayude a comprender de qué es capaz WebAssembly y cómo funciona con su código base y sus herramientas existentes, incluido Docker. ¡Esperamos verte programar con Wasm!

https://github.com/WasmEdge/WasmEdge

​