I’m a big fan of AWS ECS Fargate. I’ve written in the past about managing ECS clusters, and with Fargate — all of that work disappears and is managed by AWS instead. I like to refer to this as quasi-serverless. Sorta-serverless? Almost-serverless? I’m open to better suggestions. 😂
There are a few limitations of running in Fargate, and this blog post will focus on working around one limitation: there’s easy way to get an interactive command line shell within a running Fargate container.
The way I’m going to establish an interactive session inside Fargate is similar to how CircleCI or Heroku does this: start a SSH server in the container. This requires two components: the SSH server itself, which will be running in Fargate, and a tool to automate launching the SSH server. Most of this blog post will be about the tool to automate launching the server, called ecs-fargate-login.
If you want to skip to the code, I’ve made it available on GitHub using the MIT license, so feel free to use it as you wish.
How it works
This is what ecs-fargate-login does for you, in order:
- Generate a temporary SSH key pair.
- Use the ECS API to start a one-time task, setting the public key as an environment variable.
- When the SSH server boots, it reads this environment variable and adds it to the list of authorized keys.
- Poll the ECS API for the IP address of the running task.
ecs-fargate-loginsupports both public and private IPs. - Start the
sshcommand and connect to the server.
When the SSH session finishes, ecs-fargate-login will make sure the ECS task is stopping.
Use cases
Most of my clients use Rails, and Rails provides an interactive REPL (read-eval-print loop) within the Rails environment. This REPL is useful for running one-off commands like creating new users or fixing some data in the database, checking and/or clearing cache items, to mention a few common tasks. Rails developers are accustomed to using the REPL, so while not entirely necessary (in the past, I usually recommended fixing data using direct database access or with one-time scripts in the application repository), it is a nice-to-have feature.
In conclusion
I don’t use this tool daily, but probably a few times a week. A few clients of mine use it as well, and they’re generally happy with how it works. However, if you have any recommendations about how it could be improved, or how the way the tool itself is architected could be improved, I’m always open to discussion. This was my first serious attempt at writing Golang code, so there are probably quite a few beginner mistakes in the code, but it should work as expected.
