Developers can now deploy runtime files to the Action environment prior to invocation.
This makes it much easier to support (almost) any programming language in OpenWhisk. Awesome!
Let’s start by explaining how this new feature works…
The image includes a Python application which implements the HTTP API used to handle platform requests, e.g. invoke the action with these parameters.
This service executes a file (
/action/exec) for each invocation. Replacing this file allows us to control the runtime environment.
Request parameters are passed, using a JSON string, as the first command-line argument. Response values are interpreted as JSON written to
Developers can now include a zip file when creating Docker-based Actions. This archive will be extracted into the
/action directory prior to invocations. If the archive contains a file named
exec this will replace the exectuable file called by the invocation handler.
Testing It Out
wsk command-line, developers can create Actions using this Docker image.
If the archive file is missing, the
/action/exec path contains the the following stub file.
1 2 3 4
Let’s update this stub file to return a custom greeting.
1 2 3 4 5 6 7 8 9 10 11
The archive file could include a static binary, or even a complete runtime, to replace the
All files in the archive file will be available under the
openwhisk/dockerskeleton image exposes a Python-based HTTP server on port 8080.
openwhisk/dockerskeleton image from Docker Hub allows us to run it locally for development.
The platform uses the following HTTP endpoints to initialise and invoke Actions.
POST /init-> Set up Action source from JSON payload.
POST /run-> Invoke Action
Initialising The Environment
Before invoking Actions using this image, we need to deploy and unpack the archive file into the
Reviewing the Python source code, the platform triggers this by sending a HTTP POST with the following JSON to
1 2 3 4 5 6
code contains the archive file as a base64 encoded string.
Let’s try this out using the action archive we created above.
1 2 3 4 5 6 7 8
Now we can issue the HTTP request to push this archive into the container.
1 2 3 4 5 6 7
Accessing the container filesystem allows us to verify the archive has been extracted correctly.
1 2 3 4 5 6 7 8 9 10
Action invocations are triggered by sending a HTTP POST to the
This endpoint expects the following JSON body.
1 2 3 4 5
The inner object parameters under the
value property are passed, as a JSON string, to the executable as the first command-line argument.
Sending this request to our container will trigger the shell script from our archive and return the JSON response.
1 2 3 4 5 6 7 8 9
Recent updates to Docker-based Actions in OpenWhisk make it much easier to customise the runtime environment.
Being able to deploy arbitrary files into the runtime container, prior to invocation, simplifies the process of supporting new runtimes.
Hopefully this blog post has shown you how to get started with this feature.
Over the next few weeks, we’re going to show you how to use this approach to run lots of new programming languages on the platform. Stay tuned for updates…