Written by 
Tim
In our last post we described the steps necessary to build a Hubot-driven workflow for running Django’s migrate command in an ECS cluster.
Putting Hubot to work requires us to write some Javascript or CoffeeScript that processes commands we send it via Slack along with a response that Hubot sends back to the Slack channel.
Written by Tim
Django’s migration support provides developers with a fairly comprehensive toolset for managing and versioning schema and data changes. Writing migrations in code provides a helpful layer of abstraction and makes testing easier, while at the same time adding an extra layer of safety.
Running Django’s migrate command iterates through an application’s set of ordered migrations and runs each one, as long as it hasn’t already been executed. Fortunately, the migrate command is also idempotent – running it multiple times (but not simultaenously) has no ill effects. One particular area of contention however, is how to automate the running of the migrate command at deployment time without executing in parallel on all deployment targets in a cluster.
Written by Tim
Hosting a private Docker Registry for your container-based application gives you the flexibility to control the storage and accessibility of your Docker images.
While hosting Docker images on 3rd party platforms is recommended for simple deployments, the process of downloading updated images can be time consuming. Removing Internet latency by hosting the images in your own environment can improve download performance dramatically.
Written by Tim
Amazon’s Elastic Beanstalk service supports both single and multi-container Docker environments through Amazon ECS. Despite being in its infancy, Amazon ECS does provide an adequate environment for scaling Docker containers, though debugging those containers can present a challenge.
Written by Tim
Amazon recently announced support for periodic tasks in Elastic Beanstalk. This can be an ideal solution for some users who:
If you’re not already using a worker tier for your Elastic Beanstalk environment, the costs involved with running a dedicated EC2 instance purely for a handful of scheduled tasks isn’t all that enticing. The other issue this creates has to do with how work is sent to the worker tier instances.
Written by Tim
Currently, Cronally does not have a web UI. Instead, we chose to focus on a CLI for a number reasons:
We considered a few different languages for development, including Python and Ruby, but ultimately chose Go.
Written by Tim
pycronally is the latest library created for those who desire a programmatic interface to Cronally without using our CLI. pycronally provides direct access to the underlying API without having to implement your own interface.
Written by Tim
I often see questions on StackOverflow and other Q&A tech sites about running cron jobs on single servers within clusters of AWS instances. Running the same job on each machine tends to be simple – ensure the appropriate crontab exists on every machine (usually through your deployment process, Docker image, or AMI) and you’re good to go.
