Easily deploy CloudFormation stacks

In my last project, I added a root CloudFormation stack that contains a few things. Following that post, I wanted to start doing things a little cleanly. The main thing I want to fix is the fact that I use a role with a lot more privilege than I should. In order to fix that, I wanted each of my services deployed through Serverless to also have a CloudFormation stack. This stack will contain mostly two roles: deploy and runner. While playing around with that, I got annoyed by the AWS cli for handling CloudFormation stacks. Therefore, I did a small tool to wrap that part of the tool. Here is how I now easily deploy CloudFormation stacks.

I know I could probably use Ansible instead of doing my own tool. But I strongly feel that understanding the underlying technology is a good thing, so I prefer to dig deeper to learn it!

As always, all the code I wrote is available on my GitHub page.

The goal of the tool

Deploying a CloudFormation stack manually is not complex per se. But the command lines to use to do the actions are quite long and you need to use the right one at the right moment. For example, a basic flow would be:

  1. Create the CloudFormation stack: aws cloudformation create-stack --stack-name MyStack --template-body file://myCFStack.yml
  2. Wait for the stack to be created: aws cloudformation wait stack-create-complete --stack-name MyStack
  3. Update your stack: aws cloudformation update-stack --stack-name MyStack --template-body file://myCFStack.yml
  4. Wait for the stack to be updated: aws cloudformation wait stack-update-complete --stack-name MyStack

And this was only the basic, non-safe, no advanced features, flow. If you want to create IAM roles in your stack, you’ll need to add some –capabilities CAPABILITY_IAM to the creation and update commands.

If you want to make things a bit safer, you’ll want to use changesets. These will allow you to see and approve the actions when you do an update. Basically, you need to create a changeset (create-change-set) and wait for it to be ready (wait change-set-create-complete). Once it is created, you’ll be able to list the changes (describe-change-set). You’ll then be able to decide if you want to execute the change (execute-change-set) or scrap them (delete-change-set). Again, each of these needs multiple parameters.

The aim of my tool is to abstract all of that. You don’t need to remember which AWS profile to use, your stack name or if that stack is even deployed. It will check if the stack is deployed, create a changeset, show you the change and allow you to execute.

Using the tool

The tool is meant to be as easy to use as possible. Define your stacks and how you want them to be deployed, then call the tool saying which one you want to be deployed.

The tool is written in python, therefore it can be installed through pip: pip install cloudformation-helper.

Here is a sample of the configuration file:

With this file, you’ll be able to deploy your stack using cfhelper deploy MyStackAlias. By default, it will look in the current directory for a configuration file named stacks.cfh. This can be overridden using a flag on the command line (cfhelper –config ../path/to/stacks.cfh deploy MyStackAlias) or with the CFHELPER_CONFIG environment variable.

A lot of things are still missing from the tool for it to be ready for production, but the basis is there!

Automating bleed addition to tilesets

After my findings from my other post, where I manually modified a tileset to add a bleed around my tiles, I got lazy and decided never to do that again. From that decision rose a small project to handle various changes to tilesets, aptly named: tileset tooling. My first use case: automating bleed addition to tilesets. In this post, I’ll go over a few of the details on how I built the tool and a few usage examples.

Getting the tool

The tool relies on imagemagick. The first thing to do is to install that library: sudo apt-get install imagemagick.

Then there are two ways of getting the tool:

  1. the easiest way is by adding the tool directly in your path by installing through RubyGems: gem install tileset_tooling
  2. follow the documentation in the project readme and setup as a developer to run directly the checked-out code

Usage scenarios

As previously said, the tool only has one real feature: adding a bleed to a tileset. The tool handles two use cases:

  1. a tileset that already has a margin, where one pixel of said margin will be replaced with the bleed
  2. a tileset that does not have any margin, where the tool will add a 1-pixel margin and put the bleed there

Running the tool for both of these scenarios is done the same way:  tileset_tooling bleed insert test/data/simple_no_margin.png.

Right now, there is not much more to say. More information can be found in the tool’s wiki and a rdoc file contains all arguments and commands.

Future of the tool

Right now, nothing specific is planned for the tool. I do plan on playing with Unity, and tilesets, so a few more features might come from there. Users are also free to request features directly through GitHub.

Helping around

As a developer, I do not have any real Ruby experience. Also, I’m quite new to the whole Unity/tileset world. Any help is welcome, from anyone with any background 🙂

First project: Handling recurrent tasks in GoogleTasks

When I started this blog, one of my goals was to push myself to work on more personal projects. While setting things up for the blog I wanted to start tracking things I need to do using Google Tasks but had trouble handling recurrent tasks. Basically: they don’t support recurrent tasks.

That gave me the idea for my first little project: a simple script to handle recurrent tasks. Basically, I want to go for a flow that roughly looks like:

  1. Build a configuration file to describe the recurrent tasks I want; In there, I’ll describe at least:
    1. The task, aka name, description, etc.
    2. The period (every month, every first Monday of the month, etc.) and the deadline;
  2. Have a script to ensure that the tasks that are currently needed are created (or completed already);
  3. Run said script in a cron task on my RaspberryPi;

I did try to find a clean way of doing this. Some people do it through recurrent events in their calendar, but I really wanted tasks, not a weird workaround. I know I could use some other tool, but I’m trying to get in touch with Google services and I felt like this was a nice-enough reason to start looking into these.

Once I get the basic flow working, I’ll also be able to piggyback on this small project to do a little something with my GPIO setup or play with an Android App. I’ll see once I get there, there are still quite a few things I want to do before getting to these subjects.

I haven’t even created the GitHub project yet, I’ll do this and the basis of the script this week and update my blog next week!

Do you know of anything that allows recurrent tasks in Google Tasks? Is there anything you’d like in a tool like this?

Thanks for reading!

* Update: more information about the project in a new post: Introducing RTasker basis and vision