Nuts and Bolts

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.

The 10X Engineer “He’s a 10X engineer.” I remember hearing this expression from recruiters and product managers a few years ago. It’s a funny term but quickly conveys the point. A 10X engineer is someone who can get 10X more done than the average engineer. Let’s think through this logically. How many hours are there in a normal working day? 8 hours. So does a 10X engineer work 80 hours a day? No, of course not. That’s silly and impossible to do unless you have a tardis. So it’s not about how much you work but how you focus your efforts. A 10X engineer is smarter about how about he choses to spend his time and is better able to focus on higher leveraged activities. He or she focuses on things that make the most difference. This is nicely explained in Edmond Lau’s The Effective Engineer book, which I recommend.

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.

This a continuation of the last post: Under the Hood of Elastic Beanstalk Part 1 We’ll go over the EB nginx setup for the docker container in this post.

Elastic Beanstalk, EB, is a bit of a magic box. I’d thought it would be good to poke around a little bit under the hood, see how things actually work and learn from it. Understanding just enough of how EB works is extremely helpful for debugging. For this example I’m using a “64bit Amazon Linux 2017.03 v2.7.0 running Docker 17.03.1-ce” EB solution stack.

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.