In today's rapidly evolving tech landscape, two technologies have been making waves: WebAssembly (WASM) and OpenShift. While they serve different purposes, their combination can lead to powerful, scalable, and efficient applications. In this blog, we'll explore how WASM and OpenShift can work together and why this pairing is significant for modern developers.

WASM is available as a developer preview feature in OpenShift 4.14.

What is WebAssembly (WASM)?

WebAssembly, often abbreviated as WASM, is a binary instruction format for a stack-based virtual machine. It's designed as a portable target for the compilation of high-level languages like C, C++, and Rust, enabling deployment on the web for client and server applications.

Key Features of WASM:

Performance: WASM is designed to be faster than JavaScript for certain tasks, as it's a low-level binary format.

Security: It runs inside a sandboxed environment, ensuring that applications don't harm the host system.

Portability: WASM can run on any platform that has a suitable virtual machine.

How can WASM and OpenShift work together?

Microservices with WASM: Microservices architectures are becoming the norm, and OpenShift is a leading platform for deploying them. WASM can be used to build lightweight, high-performance microservices that can be containerized and managed by OpenShift.

Edge Computing (MicroShift): As edge computing grows, there's a need for lightweight, efficient, and fast executables. WASM modules can be deployed at the edge, and OpenShift can manage these edge deployments, ensuring scalability and reliability.

Serverless Functions (OpenShift Knative): Serverless architectures allow developers to focus on code, leaving the infrastructure management to platforms. WASM can be used to write serverless functions, and OpenShift can orchestrate these functions, ensuring they're run efficiently and can scale as needed.

Portable Plugins: WASM can be used to write plugins for platforms that support them, ensuring they're portable across different systems. OpenShift can manage the deployment and scaling of these platforms to ensure high availability.

Why is this combination powerful?

Efficiency: WASM's performance benefits combined with OpenShift's auto-scaling means applications can run efficiently, using resources only when necessary.

Cross-platform: Both WASM and OpenShift are designed to be cloud-agnostic. This means applications can be written once and deployed on any cloud.

Flexibility: Developers can write code in multiple languages, compile it to WASM, containerize it, and deploy it using OpenShift. This provides immense flexibility in choosing the right tools for the job.

Running a WASM workload in OpenShift

The ability to run WASM workloads is enabled by updating the configuration of CRI-O on the OpenShift worker nodes to use the crun-wasm runtime.

Create a MachineConfig resource to configure the worker nodes with the necessary crun-wasm configuration. We need a CRI-O drop-in config to configure `crun-wasm` as the default runtime. {%raw %}

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
 labels:
   machineconfiguration.openshift.io/role: worker
 name: 99-workers-wasm-workloads
spec:
 config:
   ignition:
     config: {}
     security:
       tls: {}
     timeouts: {}
     version: 3.2.0
   networkd: {}
   passwd: {}
   storage:
     files:
     - contents:
         source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZV0KZGVmYXVsdF9ydW50aW1lID0gImNydW4td2FzbSIKW2NyaW8ucnVudGltZS5ydW50aW1lcy5jcnVuLXdhc21dCnJ1bnRpbWVfcGF0aCA9ICIvdXNyL2Jpbi9jcnVuIgpwbGF0Zm9ybV9ydW50aW1lX3BhdGhzID0geyJ3YXNpL3dhc20zMiIgPSAiL3Vzci9iaW4vY3J1bi13YXNtIn0K
       mode: 0644
       overwrite: true
       path: /etc/crio/crio.conf.d/99-crun-wasm.conf
 extensions:
   - wasm

The MachineConfig will create a file at /etc/crio/crio.conf.d/99-crun-wasm.conf (base64 string in the MachineConfig example above) containing the following:

[crio.runtime]
default_runtime = "crun-wasm" 
[crio.runtime.runtimes.crun-wasm]
runtime_path = "/usr/bin/crun" 
platform_runtime_paths = {"wasi/wasm32" = "/usr/bin/crun-wasm"}

Apply the MachineConfig using the oc apply -f <filename> command, replacing <filename> with the name of the YAML file.

Run the following command to debug a worker node and check if crun-wasm installed successfully:

oc debug node/<node-name> -- chroot /host && crun-wasm -v

Replace <node-name> with the name of a worker node in your cluster. Once inside the debug session, you can check if crun-wasm is available by running the crun-wasm -v command.

Use the following example to check if wasm bits are enabled appropriately:

In this example, we are applying the label pod-security.kubernetes.io/enforce with the value baseline to the namespace default. By labeling the namespace with baseline, we are ensuring that all pods created within this namespace adhere to a standard set of security policies and configurations designed for the OCP cluster.

$ oc label ns/default pod-security.kubernetes.io/enforce=baseline --overwrite
namespace/default labeled

$ oc apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: http-server
  name: http-server
  namespace: default
spec:
  containers:
    - name: http-server
      image: quay.io/crio/example-wasm-http:latest
      command: ["/http_server.wasm"]
      ports:
        - containerPort: 1234
          protocol: TCP
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      livenessProbe:
        tcpSocket:
          port: 1234
        initialDelaySeconds: 3
        periodSeconds: 30
EOF

$ oc get pod
NAME          READY   STATUS    RESTARTS   AGE
http-server   1/1     Running   0          3m8s
$ oc expose po/http-server
service/http-server exposed
$ oc expose service/http-server
route.route.openshift.io/http-server exposed
$ ROUTE_NAME=$(oc get route http-server -o jsonpath='{.spec.host}')
$ curl $ROUTE_NAME -d "Hello world!"
echo: Hello world!

Following these steps, you can enable crun-wasm in your OCP cluster and test its functionality using the provided example.

We've seen how, with a simple MachineConfig, you can get WASM applications running in OpenShift containers. This is just the first step — be on the lookout for additional enhancements in the future. The developer preview support for WebAssembly workloads in OpenShift 4.14 only scratches the surface of what you can achieve. WebAssembly promises to revolutionize containerization by offering improved density, enhanced security, and increased efficiency. Runtimes like crun-wasm pave the way for exciting opportunities to explore and experiment with WASM-based applications on OpenShift Container Platform (OCP).

Conclusion

The combination of WebAssembly and OpenShift offers a promising path for the future of application development and deployment. As both technologies mature and more tools emerge to bridge the gap between them, we can expect to see even more innovative solutions that leverage the strengths of both. For developers and businesses alike, this duo presents an opportunity to build and scale applications like never before.