The New Docker Based IronWorker Development Workflow
Overview
Creating a simple IronWorker worker can be quick and easy. But if you’ve used IronWorker to build a complex worker, you may have found the experience a bit cumbersome.
The reason is that sometimes you just don’t know if your worker will run the same way it does when you run it locally, due to the local environment or perhaps missing dependencies.
The typical development process for building an IronWorker looked something like this:
- Write/debug your worker.
- Upload your worker – this can take some time large with a lot of dependencies - even more so if you are doing remote builds (remote builds are sometimes required to ensure your code or dependencies with native extensions are built on the right architecture).
- Queue a task to run your worker.
- Wait for it to run (may take a few seconds).
- View the log on the Iron.io console, aka HUD (another few seconds to pull it up).
- Repeat... over and over until it works right.
If you have to do a lot of debugging, this can waste a lot of time and cause some serious pain.
Table of Contents
Related Reading: What is a docker container?
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.
Introducing a New Workflow
This upload process has changed because now you can test your worker locally in the exact same environment as when running on the IronWorker platform using Iron.io’s public Docker images. Plus, you can upload workers and interact with the system with a new CLI tool written in Go.
The new workflow is only slightly different:
- Ensure all dependencies for your worker are in the current directory or in sub-directories.
- Create an input/payload example file (check this into source control as an example).
- Build/run/test your worker inside an Iron.io image container.
- Debug/test until you get it working properly.
- Once it works as expected, upload it to IronWorker.
That's it. You should only need to do this process once unless you want to make changes. The reason being is that if your worker works inside our Docker images, it will work the same way when it’s running on the IronWorker platform.
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.
The process may similar on paper, but it’s a big change in practice. There are a number of benefits you get from this new workflow:
- No Ruby dependency to use the command line tools. The new cli tool is written in Go.
- No remote builds necessary. You can build it locally no matter what operating system you are using.
- No packaging “magic.” The iron_worker_ng cli tool did a lot of work to create IronWorker code packages that worked across languages and operating systems.
- No.worker files to define your dependencies.
- Faster development.
Try It Using Some New Examples
We’ve created a repository with examples in a bunch of different languages so you can try it out: https://github.com/iron-io/dockerworker
Note: you can still do things as you've always been doing, but we believe this provides a better, more consistent, and quicker development process.
Give it a try and let us know what you think!
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.