Apache OpenWhisk on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and use of Apache OpenWhisk on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Apache OpenWhisk is an open source, distributed serverless / Functions-as-a-Service (FaaS) platform: you write small functions, called actions, and OpenWhisk runs each one inside an isolated container in response to a direct invocation or an event, scaling on demand and charging only for real execution time.

This image is a complete, self-contained OpenWhisk appliance built on the upstream Standalone mode (core/standalone). In Standalone mode the OpenWhisk controller, invoker and datastore run together in a single process, while a local Docker daemon runs the real action containers as functions are invoked. That gives you a working FaaS endpoint on first boot without standing up the full distributed OpenWhisk stack (Kafka, ZooKeeper, CouchDB and separate controller/invoker nodes), which is far too large for a single VM.

What is included:

• The official openwhisk/standalone container — controller, invoker and an in-memory datastore in one process — run under systemd as openwhisk-standalone.service, exposing the OpenWhisk REST API on port 3233 and the Playground UI on port 3232

• A local Docker daemon that runs the action-runtime containers as siblings, with the Node.js action runtime pre-pulled into the image so your first invocation runs fast and offline

• The wsk command line tool (Apache OpenWhisk CLI 1.2.0), preconfigured on the VM to talk to the local platform with this instance's own authentication key

• A per-instance authentication key generated on first boot and written to /root/openwhisk-credentials.txt (mode 0600, root only), so no default or example credential is ever live

• The base OS fully patched, with unattended security upgrades enabled

Security by design — no usable default credential. Standalone OpenWhisk ships a well-known default authentication key for its guest namespace (23bc46b1-...:123zO3xZC..., published in the upstream source). On this image that key is never valid: the platform service is gated so it cannot start until a per-instance users configuration exists, and on the very first boot of every VM a one shot service generates a fresh uuid:key pair unique to that instance, starts the platform for the first time already carrying that key, proves the upstream default key is rejected, and writes the new key to /root/openwhisk-credentials.txt. There is no window in which the well-known default key can be used against your instance.

Prerequisites

• Active Azure subscription, SSH public key, and a VNet + subnet in your target region

• Subscription to the Apache OpenWhisk listing on Azure Marketplace

• A Network Security Group allowing TCP 22 for administration, and TCP 3233 from the hosts that will call the OpenWhisk API (for example your CI runners or a remote wsk client). The API is served over HTTP on port 3233; if you expose it beyond a trusted network, front it with your own TLS-terminating reverse proxy or restrict the NSG source

Recommended virtual machine size: Standard_B2ms (2 vCPU, 8 GB RAM). The OpenWhisk controller/invoker is a JVM process and each action runs in its own container, so 8 GB gives comfortable headroom for concurrent invocations. The image is tuned to boot and run on a 4 GB Standard_B2s for light evaluation, but Standard_B2ms is recommended for real workloads.

Step 1: Deploy from the Azure Portal

Search Apache OpenWhisk in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 22 for administration and TCP 3233 from the hosts that will call the API. Complete the wizard and create the VM.

Step 2: Deploy from the Azure CLI

RG="openwhisk-prod"; LOCATION="eastus"; VM_NAME="openwhisk-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/openwhisk/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Open the API port to the callers that need it:
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 3233 --priority 1010

Step 3: First boot and the per-instance key

On first boot a one shot service generates this instance's own authentication key, starts the platform, and records the details. SSH in as azureuser and read the credentials file (root only):

sudo cat /root/openwhisk-credentials.txt

Expected output (the key half is unique to your VM — shown masked here):

# Apache OpenWhisk (Standalone) — Per-VM Credentials
OPENWHISK_API_HOST=http://<your-vm-ip>:3233
OPENWHISK_GUEST_AUTH=5b636ff8-b85d-4fda-bff9-73306c885edf:********************************

The wsk CLI on the VM is already configured with this key, so you can start using the platform immediately. Confirm the platform is up:

systemctl is-active docker openwhisk-standalone
curl -s http://127.0.0.1:3233/ping
wsk namespace list

curl .../ping returns pong, and wsk namespace list returns your guest namespace, confirming the CLI is authenticated against the local platform with this instance's key.

Step 4: Create and invoke your first function

Create a small Node.js action and invoke it. The result comes back from a real Docker action container executing your function:

cat > hello.js <<'EOF'
function main(params) {
  return { greeting: 'Hello, ' + (params.name || 'world') + '!',
           runtime: process.version };
}
EOF
wsk action delete hello 2>/dev/null || true
wsk action create hello hello.js --kind nodejs:default
wsk action invoke hello --result --param name cloudimg

Expected output:

{
    "greeting": "Hello, cloudimg!",
    "runtime": "v20.19.0"
}

You can also invoke actions over the REST API, expose them as public web actions (wsk action create --web true), chain them into sequences, or attach triggers and rules for event-driven execution. See the Apache OpenWhisk documentation for the full action, trigger and rule model.

Step 5: Verify the security posture

This image ships no usable default credential. A helper on the VM proves the round-trip — that this instance's own key authenticates while the well-known upstream default key is rejected:

sudo /usr/local/sbin/openwhisk-cred-roundtrip.sh

Expected output:

OK

Every invocation is recorded as an activation, and you can see the action-runtime containers the platform actually spawned:

sudo docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'
wsk activation list --limit 3

Step 6: Connect a remote wsk client (optional)

To drive the platform from your workstation or CI, install the wsk CLI and point it at your VM using the API host and key from /root/openwhisk-credentials.txt:

# Run this on your workstation, not the VM. Replace <vm-ip> and the auth key.
wsk property set --apihost http://<vm-ip>:3233 --auth <OPENWHISK_GUEST_AUTH>
wsk action list

Because the API is served over HTTP on port 3233, expose it only to trusted networks, or place a TLS-terminating reverse proxy in front of it and restrict the NSG source ranges accordingly.

Support

This image is maintained by cloudimg and paired with 24/7 support. For deployment help or questions about running Apache OpenWhisk on Azure, contact the cloudimg team via the Azure Marketplace listing.