Full Docker Support for IronWorker
Overview
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, they 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.
Table of Contents
Achieve Cloud Elasticity with Iron
Speak to us to find how you can achieve cloud elasticity with a serverless messaging queue and background task solution with free handheld support.
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 is 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.
Iron.io Serverless Tools
Speak to us to learn how IronWorker and IronMQ are essential products for your application to become cloud elastic.
Thanks for subscribing! Please check your email for further instructions.
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 to 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 they need.
Unlock the Cloud with Iron.io
Find out how IronWorker and IronMQ can help your application obtain the cloud with fanatical customer support, reliable performance, and competitive pricing.
Hi, the example snippets are missing from the article.