Terraspace is a Terraform framework. It provides an organized structure, conventions over configurations, keeps your code DRY, and adds convenient tooling. It makes it easier and more fun to work with Terraform.

Kubes is a deployment tool that makes it easier and more fun to work with Kubernetes. Kubes automates 3 main steps. Build a Docker image. Create the YAML files that declare the Kubernetes resources. Run kubectl apply to create the resources on the cluster. It boils everything down to one single command: kubes deploy

If you are working with AWS heavily, you should look into a powerful tool called CloudFormation. Taking the time to learn CloudFormation is an investment that is easily returned to you in the form of powerful automation. In this guide, we’ll provide a gentle introduction to CloudFormation, and by the end, you’ll have the skills to start using it in your own AWS workflow.

The common advice to speeding up your Docker development workflow focuses on reducing your Docker image size. At the surface, the logic makes a lot of sense. By making your Docker images smaller, you win. With smaller image sizes, there are fewer bytes to pull down and push up to the registry, thus saving you a boatload of time. Smaller images = solution. What the advice does not take into account is a precious resource: developer’s time.

One way to think about Docker image layers is to think of them as git commits. While the two are technically different, this article uses this analogy to point out an interesting commonality between both of them.

There are a ton of ssh tips out there, and I thought that I surface 3 of them. Here are 3 ssh tips that I’ve learned over the years. Hope you find them useful 🎉

It can be difficult to understand the CloudFormation resources and their dependencies when working with a complicated CloudFormation template. We’ll run through some commands to try to help understand their dependencies.

In the previous posts, we went over some jq tips with CloudFormation. We used jq to quickly summarize CloudFormation template parameters and resources. lono summary automates that process and makes the command short and sweet.

Shortly after the last video CloudFormation Templates and jq Tips, I wanted to know what the required parameters in a CloudFormation template were. This is also an easy task with jq. I’ll show you how to use jq to quickly summarize the required and optional parameters in a CloudFormation template in this post. It’s a one-liner 😁

I’ll go over a useful way to summarize CloudFormation templates resources with jq. This is useful when you are looking at a CloudFormation template and trying to understand it. We’ll download an example CloudFormation template and use run through some useful jq commands summarize the resources defined in a CloudFormation template. Note, I’ll only show the output that is useful for understanding.

I don’t remember exactly where I got these one-liners from anymore. It’s been in my expander for a while. Here are useful oneliners to convert JSON to YAML and vice versa.

Embarrassingly, I’ve been converting raw CloudFormation templates to lono CloudFormation templates manually. Probably one of the reasons why it’s been neglected is because this process is so simple, but it is ripe for automation. This should have been done this a long ago.

Update 9/5/2018: The video is old and demos the older version of the tool called thor_template. The new tool is called cli-template. I’ve updated the blog post but not the video. These two tools seem pretty cool too: http://piotrmurach.github.io/tty/: Thor based also. davetron5000.github.io/methadone/: Has it’s own CLI parser. Thanks @eashman for showing me the tools. In this post, we’ll build a CLI project that is based on Thor in under a second. The cli-template tool builds a fully functional CLI command based on Thor. The commands immediately work and there are even specs.

Once a developer came up to me and told me that he was ready to deploy, but the deploy required migrations be run. He asked me an innocent question, how should he run migrations. Embarrassingly, because we were still evolving our tooling for the new infrastructure, we did not have a process for this simple task. We came up with an ad-hoc process that was honestly pretty terrible. It went like this:

ECS is the AWS Docker container service that handles the orchestration and provisioning of Docker containers. This is a beginner level introduction to AWS ECS. I’ve seen some nightmare posts and some glowing reviews about the ECS service, so I knew it was going to interesting to get my hands dirty and see what ECS was all about.

Task Definition — This a blueprint that describes how a docker container should launch. If you are already familiar with AWS, it is like a LaunchConfig except instead it is for a docker container instead of an instance. It contains settings like exposed port, docker image, CPU shares, memory requirement, the command to run and environmental variables. Task — This is a running container with the settings defined in the Task Definition. It can be thought of as an “instance” of a Task Definition. Service — Defines long-running tasks of the same Task Definition. This can be one running container or multiple running containers all using the same Task Definition. Cluster — A logic group of EC2 instances. When an instance launches the ecs-agent software on the server registers the instance to an ECS Cluster. This is easily configurable by setting the ECS_CLUSTER variable in /etc/ecs/ecs.config described here. Container Instance — This is just an EC2 instance that is part of an ECS Cluster and has docker and the ecs-agent running on it.

I’m excited to say that a ton of great features has been added to lono with this major version bump. At this point, lono has grown to become a framework for managing CloudFormation templates. Let jump right into it and cover the major improvements.

Software is often more of an art form than it is a science. This is one of the reasons software tends to vary substantially between tools and developers. By following guidelines and design patterns though it can help keep the code consistent and clean. This allows the code to be understandable between engineers and allow them to move between tools efficiently. In this post, I’ll talk about what some of the best practices and software design patterns followed in the BoltOps tools.

A common misconception is that Elastic Beanstalk is difficult to work with because it is not customizable. I fell into this trap myself when I first took a look at AWS Elastic Beanstalk. After working with AWS Elastic Beanstalk directly and looking at it more closely though, there are plenty of ways to customize Elastic Beanstalk. I’ll cover the main ways to customize AWS Elastic Beanstalk environments in this post.

As with most AWS services, Elastic Beanstalk is great and simply require some tooling on top of the service to speed up the flow. This post covers the jack tool that be use to quickly create and manage Elastic Beanstalk environments.

As I’ve covered in Jack and the Elastic Beanstalk, Elastic Beanstalk is a great PaaS offering from AWS that allows developers to deploy and run their applications on EC2 instances. I been tinkering with a few different ways to speed up the eb deploy command from my local machine and was able to speed it up somewhat. Though honestly I was hoping for better results. I will detailed the results to show what I learned. Note, the project and all it’s files are available on GitHub at tongueroo/hi under the docker-cache branch.

Amazon EC2 Container Service, ECS, is an AWS service that provisions and manages Docker containers on a cluster of EC2 instances. As with most of AWS services, it is great and simply requires a little tooling wrapped around it to create a smooth flow. Ufo is a simple tool that makes building and shipping Docker containers to AWS ECS super easy.

In the last CloudFormation post, Generating CloudFormation Templates with Lono, the stack was intentionally designed simple to allow focus on learning and understanding CloudFormation basics. The stack was not that useful in real life. Today, I’ll walk through a CloudFormation template that is practical and useful for real life use cases: an AutoScaling App Tier.

Recently, I’ve made some major improvements and updates to the lono tool. I thought it would be nice to provide a post detailing the changes for everyone.

When using lono if you sometimes forgot to regenerate the templates after making changes you can use lono with guard to never have to remember again.

Writing CloudFormation templates becomes difficult to manage once you start using it heavily. Whether it is one complicated template or multiple simple templates, maintaining the templates are a decent amount of work. This post covers a tool I wrote called lono to that manages and generates CloudFormation templates.

I’ve covered lono cfn in Easily Manage CloudFormation Templates with lono cfn. After learning about AWS CloudFormation Change Sets, I was decided to add a dry-run mode to the lono tool. This dry-run command simplifies the usage of change sets to a single command: lono cfn preview 😁

Lono is a tool that generates CloudFormation templates from smart ERB templates. With it, you can use variables and simplify managing your raw CloudFormation templates greatly.

Writing CloudFormation templates becomes difficult to manage once you start using it heavily. Whether it is one complicated template or multiple simple templates, maintaining the templates are a decent amount of work. This post talks about why I built a tool called lono to help manage and generate a large amount of CloudFormation templates.

UPDATE 2022/8/12: Check out the improved CloudFormation Fundamentals Introductory Course. I am a big fan of AWS CloudFormation because it gives you the power to codify the infrastructure and provision it in a repeatable way. One thing that I’ve always wished that CloudFormation had was the ability to see the what changes would be applied ahead of time before hitting that update-stack button. Who wants to hit a big scary red button without knowing what is about to happen? I don’t.

UPDATE 2022/8/12: Check out the improved CloudFormation Fundamentals Introductory Course. In the last 2 stories, we created an EC2 instance and a Route53 record successfully with CloudFormation. We have yet to walk through the useful update-stack command though. In this post, we’ll use the 2 templates created in the first 2 posts to play around with the update-stack command.

UPDATE 2022/8/12: Check out the improved CloudFormation Fundamentals Introductory Course. This is a continuation of A Simple Introduction to AWS CloudFormation. We will build on top of the first simple CloudFormation template from Part 1, which provisions an EC2 instance and Security Group. We will add to it a Route53 record that points to the EC2 instance’s DNS public hostname. This demonstrates CloudFormation’s ability to “orchestrates” the components of the stack. CloudFormation will wait until the EC2 instance’s DNS public hostname is ready and then create the Route53 record pointing to it.

The easiest way to describe what CloudFormation is that it is a tool from AWS that allows you to spin up resources effortlessly. You define all the resources you want AWS to spin up in a blueprint document, click a button, and then AWS magically creates it all. This blueprint is called a template in CloudFormation speak.

CircleCI is one of my goto hosted Continuous Integration, CI, providers. They make it very easy to quickly connect your GitHub account and set up CI. This story covers how to set up Continuous Deployment to ECS on CircleCI.

I’m not the one who usually buys into the single killer feature hype. However, in the case of CircleCI they have a feature that blew my mind when I first saw it and still does today: ssh login. Being able to ssh into the machine to debug and poke around the environment is a godsend.