Cómo instalar Apache OpenWhisk con Docker en Ubuntu 24.04

Apache OpenWhisk es una plataforma serverless de código abierto que ejecuta pequeñas funciones, llamadas actions, en contenedores efímeros como respuesta a eventos o peticiones HTTP. En este tutorial pondrás en marcha OpenWhisk en modo standalone con Docker en Ubuntu 24.04, instalarás la CLI wsk y crearás actions en JavaScript y Python, un trigger con su rule, un paquete con parámetros por defecto y una web action accesible por HTTP.

Requisitos previos

Para seguir esta guía necesitas:

Un servidor con Ubuntu 24.04 LTS de 64 bits (x86_64), por ejemplo un VPS de CubePath.
Un usuario no root con privilegios sudo.
Al menos 2 vCPU y 4 GB de RAM.
Docker Engine instalado desde el repositorio oficial, con tu usuario en el grupo docker.

Nota

el modo standalone reúne todos los componentes de OpenWhisk (controlador, invoker y almacenamiento) en un único contenedor. Es la forma más sencilla de trabajar con OpenWhisk en un servidor, pero guarda las actions en memoria: si el contenedor se reinicia, tendrás que volver a crearlas. Para producción, OpenWhisk se despliega en Kubernetes con el chart de Helm del proyecto openwhisk-deploy-kube.

Paso 1: Comprobar Docker

OpenWhisk standalone usa el socket de Docker para lanzar un contenedor por cada runtime (Node.js, Python...). Comprueba que Docker funciona sin sudo:

docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Si recibes permission denied, ejecuta sudo usermod -aG docker "$USER", cierra la sesión y vuelve a entrar.

Paso 2: Arrancar OpenWhisk standalone

Lanza el contenedor oficial openwhisk/standalone. El puerto 3233 es la API de OpenWhisk y el 3232 una interfaz web (playground) para probar actions:

docker run -d \
  --name openwhisk \
  -h openwhisk \
  -p 127.0.0.1:3233:3233 \
  -p 127.0.0.1:3232:3232 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  openwhisk/standalone:nightly

Ambos puertos se publican solo en 127.0.0.1. La instalación standalone usa una clave de invitado que es pública y está documentada, así que nunca debes exponer la API directamente a Internet. Ten en cuenta que Docker gestiona sus propias reglas de iptables y un puerto publicado en todas las interfaces quedaría abierto aunque UFW lo bloquee.

El primer arranque tarda uno o dos minutos porque descarga las imágenes de los runtimes. Puedes seguir el progreso con docker logs -f openwhisk (sal con Ctrl+C, el contenedor sigue funcionando). Cuando termine, comprueba que la API responde:

curl -s http://127.0.0.1:3233/api/v1 | head -c 300; echo

{"api_paths":["/api/v1"],"description":"OpenWhisk","runtime":{...

Paso 3: Instalar la CLI wsk

wsk es la CLI oficial de OpenWhisk y se distribuye como binario en GitHub. Descarga la versión 1.2.0, extrae el binario e instálalo en /usr/local/bin:

curl -fLO https://github.com/apache/openwhisk-cli/releases/download/1.2.0/OpenWhisk_CLI-1.2.0-linux-amd64.tgz
mkdir wsk-cli
tar -xzf OpenWhisk_CLI-1.2.0-linux-amd64.tgz -C wsk-cli
sudo install -m 0755 wsk-cli/wsk /usr/local/bin/wsk
rm -r wsk-cli OpenWhisk_CLI-1.2.0-linux-amd64.tgz
wsk --help | head -n 3

Configura la CLI para usar tu instancia local con la clave de invitado del modo standalone:

wsk property set \
  --apihost 'http://127.0.0.1:3233' \
  --auth '23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP'

La configuración se guarda en ~/.wskprops. Verifica la conexión listando las entidades del namespace:

wsk list

Entities in namespace: default
packages
actions
triggers
rules

Paso 4: Crear tu primera action

Una action es una función sin estado que recibe un objeto JSON de parámetros y devuelve otro. Crea una en JavaScript:

mkdir -p ~/openwhisk && cd ~/openwhisk
nano hola.js

function main(params) {
  const nombre = params.nombre || "mundo";
  return { mensaje: `Hola, ${nombre}` };
}

Registra la action e invócala de forma bloqueante con --result para ver solo el resultado:

wsk action create hola hola.js
wsk action invoke hola --param nombre CubePath --result

ok: created action hola
{
    "mensaje": "Hola, CubePath"
}

La primera invocación tarda un poco más porque arranca el contenedor del runtime (cold start). Las siguientes reutilizan ese contenedor mientras esté caliente.

Una action en Python

OpenWhisk detecta el runtime por la extensión del archivo. Crea una action en Python que calcule estadísticas de una lista:

nano estadisticas.py

def main(params):
    datos = params.get("datos", [])
    if not datos:
        return {"error": "No se han recibido datos"}
    return {
        "total": sum(datos),
        "media": sum(datos) / len(datos),
        "cantidad": len(datos),
    }

Créala e invócala pasando los parámetros desde un archivo JSON:

wsk action create estadisticas estadisticas.py
echo '{"datos": [10, 20, 30, 40, 50]}' > datos.json
wsk action invoke estadisticas --param-file datos.json --result

{
    "cantidad": 5,
    "media": 30.0,
    "total": 150
}

Límites de memoria y tiempo

Cada action tiene un límite de memoria (MB) y un tiempo máximo de ejecución (milisegundos). Ajústalos con wsk action update:

wsk action update estadisticas --memory 256 --timeout 30000
wsk action get estadisticas | grep -A 5 '"limits"'

Paso 5: Consultar activaciones y logs

Cada invocación genera una activación con su resultado, duración y logs. Lista las más recientes:

wsk activation list --limit 5

Datetime            Activation ID                    Kind      Start Duration   Status   Entity
2026-09-25 10:12:04 4f1c2d...                        python:3  warm  4ms        success  guest/estadisticas:0.0.2
2026-09-25 10:11:40 9ab7e3...                        nodejs:20 cold  512ms      success  guest/hola:0.0.1

Para ver el resultado y los logs de una activación concreta, usa su ID:

wsk activation result activation_id
wsk activation logs activation_id

Todo lo que la action escriba con console.log (JavaScript) o print (Python) aparece en wsk activation logs.

Paso 6: Conectar eventos con triggers y rules

Un trigger es un canal de eventos con nombre y una rule lo asocia a una action: cada vez que el trigger se dispara, la action se ejecuta con los parámetros del evento. Crea ambos:

wsk trigger create nuevo-pedido
wsk rule create pedido-a-hola nuevo-pedido hola

Dispara el trigger con un parámetro:

wsk trigger fire nuevo-pedido --param nombre "pedido 1042"

ok: triggered /_/nuevo-pedido with id 7c2e...

Comprueba en las activaciones que la action hola se ha ejecutado:

wsk activation list --limit 3

Verás una activación del trigger nuevo-pedido, otra de la rule y otra de la action hola. Puedes desactivar temporalmente la conexión sin borrar nada con wsk rule disable pedido-a-hola y volver a activarla con wsk rule enable pedido-a-hola.

Paso 7: Agrupar actions en paquetes

Los paquetes agrupan actions relacionadas y permiten definir parámetros por defecto que reciben todas ellas. Crea un paquete con un parámetro compartido y añade una action:

wsk package create utilidades --param entorno produccion
wsk action create utilidades/hola hola.js
wsk package get utilidades --summary

package /guest/utilidades
   (parameters: *entorno)
 action /guest/utilidades/hola

Invoca la action dentro del paquete; recibirá entorno además de los parámetros que le pases:

wsk action invoke utilidades/hola --param nombre paquete --result

Paso 8: Publicar una web action por HTTP

Una web action se puede llamar con una petición HTTP normal, sin credenciales de OpenWhisk. Recibe el método y la ruta en los parámetros __ow_method y __ow_path y puede devolver código de estado, cabeceras y cuerpo:

nano api.js

function main(params) {
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: {
      metodo: params.__ow_method,
      ruta: params.__ow_path,
      nombre: params.nombre || null,
    },
  };
}

Créala con --web true y obtén su URL:

wsk action create api api.js --web true
wsk action get api --url

ok: got action api
http://127.0.0.1:3233/api/v1/web/guest/default/api

Pruébala con curl:

curl -s "http://127.0.0.1:3233/api/v1/web/guest/default/api?nombre=web"

{"metodo":"get","nombre":"web","ruta":""}

Si más adelante quieres exponer una web action a Internet, publícala a través de un proxy inverso (Nginx o Caddy) con TLS que reenvíe solo la ruta /api/v1/web/ de esa action, nunca la API completa.

Paso 9: Detener y volver a arrancar OpenWhisk

El contenedor no se ha creado con política de reinicio, así que no arrancará solo tras reiniciar el servidor. Para detenerlo o arrancarlo de nuevo:

docker stop openwhisk
docker start openwhisk

Recuerda que en modo standalone las actions, triggers y rules se guardan en memoria. Mantén el código y los comandos wsk de creación en un repositorio o script para poder recrearlos.

Solución de problemas

wsk devuelve connection refused. El servidor todavía está arrancando o el contenedor se ha detenido. Revisa docker ps --filter name=openwhisk y docker logs --tail 50 openwhisk.

Las actions fallan con errores al crear contenedores. El contenedor de OpenWhisk no puede usar Docker. Comprueba que el socket está montado con docker inspect openwhisk --format '{{json .Mounts}}' y que el servicio Docker está activo con systemctl status docker.

Una action termina con The action exceeded its time limits. Aumenta el tiempo máximo con wsk action update nombre --timeout 60000 y revisa los logs de la activación para localizar la parte lenta.

Las actions desaparecen. Es el comportamiento esperado del modo standalone tras un reinicio del contenedor. Vuelve a crearlas o despliega OpenWhisk en Kubernetes para disponer de almacenamiento persistente.

Conclusión

Tienes Apache OpenWhisk funcionando en modo standalone en Ubuntu 24.04, con la CLI wsk configurada y ejemplos de actions, triggers, rules, paquetes y web actions. A partir de aquí puedes empaquetar actions con dependencias en un archivo ZIP, encadenar varias actions en una secuencia con wsk action create nombre --sequence a,b, o desplegar OpenWhisk en un clúster de Kubernetes con Helm cuando necesites persistencia y alta disponibilidad.

On this page