Full Docker Support for IronWorker

A couple of months ago, we announced a new workflow for IronWorker based on Docker that enabled you to test your worker code locally on the exact same environment as it is when running on the IronWorker cloud. The initial feedback we received was pretty consistent: “This is great, but can you make it more flexible when it comes to using images?”

Up until now, you had to use one of our predefined Iron.io images (or stacks as we used to call them). Although these images cover most major languages and OS packages that you might want, that didn’t match the needs of all users.  At Iron.io, we know empowering the developer is key. That includes enabling developers to make choices about how they use Docker.

Today, we’re announcing full Docker support allowing you to use any Docker image, including your own custom images. This feature is in beta and is only available on dedicated accounts to begin with, please contact us if you’d like to try it out.

How to Use a Custom Docker Image

Now on to the fun stuff. You can use any image that is available on Docker Hub and it’s almost no different than what you’re doing now with the DockerWorker workflow, you just need to tell us which image to use. To read more about the workflow and to run your first IronWorker, see here. The following explains the changes required to use your own custom image. Most of the changes apply to the upload function when you upload your worker code.

The current way (which still works just fine) is:

For example:

The new way changes the format a bit to be more like docker run:

For example:

You can still use our existing Iron.io stacks by using their full docker image name, for example the following is equivalent to the command above that uses –stack):

It’s also possible to include your code inside the Docker image as a self contained runnable image and not upload it separately;

Notice that one takes the docker image name only; there is no code package uploaded. See this example repository for a full example with code and Dockerfile.

New Environment Variables

Task information that was previously passed in as program arguments are now available as environment variables. The following environment variables are now set inside the container when it’s run:

TASK_ID
PAYLOAD_FILE
CONFIG_FILE

So to load the payload for your task in a custom image, look up the PAYLOAD_FILE env variable and read in the file. The old way where this is passed in as parameters is deprecated.

Versioning and Updating Your Images

In order for IronWorker to know about an update to your image, you should always version your images using Docker tags, then use the tag when uploading. For example

 

Push it to docker hub:

Then upload it to IronWorker WITH the tag.

 

Summary

Full Docker support allows us meet the requests for custom images and image use flexibility. This also removed Iron.io from being a gatekeeper for runtime images. With this new feature, new users can have a seamless experience, while users with more demanding needs have the flexibility the need.