Andromeda Containers Explainer

My approach to handling container-based applications with Andromeda

I absolutely love containers. I love Docker, I love Kubernetes. It was the first sort of technology I was able to deep dive in the context of regular work and it really stepped up my passion for cloud computing. There was a measured difference in how I approached college and other tasks going forward from when I got exposed to the technologies and it is something I continue to embrace and champion since then. If I can put something in a container and have it scheduled by Kubernetes, I will try my best to do it. So, when I started to work more on side projects that involved code, I started realising my own at home processes for container development were a bit rusty. You got to understand that I spend my day more on supporting the platforms we provide as an enterprise for containers, not necessarily the processes around running those containers. When you look at the various levels of cloud, I sit on the platform level and rarely if ever, go above it into the application level.

So, I needed to do several things really. I needed a container environment to work in, I needed a means of building containers and finally deploying those containers. It does not seem like a lot, but it did evolve over time to a considerable chunk of work. That, or I have no personal control when it comes to scope creep. The container environment was properly sorted out when I build an EKS cluster all that while ago now, which I previously talked about. For the last two steps, there is a bit of cross over with another Andromeda service as there would be with the overall Andromeda platform. But Andromeda Containers is what I came up with for my solution and here is how it works.

Something that is consistent throughout all Andromeda solutions is some level of usage of Terraform. Terraform has been an amazing tool and I think it is an amazing way of handling one’s infrastructure. Especially for what I was looking for in terms of consistent infrastructure across multiple applications, it is pretty much perfect. All services with Andromeda are built with the same Terraform remote state configuration which uses S3 for remote storage of state and DynamoDB to support state locking. State locking is more important in the context of a team I feel. But it will get especially important down the line with 2.x and 3.x versions of Andromeda where I have APIs handling things. Then finally with Containers, I am using the Kubernetes provider to write my manifests which today comprise of just Deployment and Service objects. I have plans to include Ingress objects very soon. But I have also created Terraform modules for my development life cycles, which include development, release-candidates and production. So, the bulk of the code is the same, I am just generally changing the application image for the deployment. Using variable replacement is great too since I can just pass in the one name, say “my-app”. Then the Terraform modules will do the replacement for the lifecycles and add to the name “-dev, -rc, -prod” depending on what it is. Same applies with my images where the repository is the same, but the tags are handled in the Terraform code.

The overall service is stored in a dedicated S3 bucket. What this means then is that I can have a shell script locally for creating new Andromeda Container applications. That shell script will also do a few extra things, such as creating the AWS ECR repository for the application. It will also download the necessary files to enable Github Actions support which is a part of Andromeda Build and Deploy. Something that took me anywhere from tens of minutes to a few hours before with extraordinarily little consistency, now only takes a handful of minutes and is now very consistent in its design and configuration.

1.0 of Andromeda Containers is working away fine for me today. My aim is to transition several older, manual Kubernetes deployments and their supporting tools to the Andromeda model. That will include moving their CI/CD to the Build & Deploy component of Andromeda. As talked about previously in the introduction, 2.x and 3.x versions will greatly enhance the features of my little, inner-source platform. Ultimately, I think it will become a major cornerstone of my personal application experience and will help me build more cloud native applications!