New Amazon Linux Dev Container Features
Published: 2022-10-31 01:48:24

🆕 **Want to use [Codespaces](https://github.com/features/codespaces) with Amazon Linux 2?** Check out [customink/codespaces-features](https://github.com/customink/codespaces-features) for two custom features. 1) [common-amzn](https://github.com/customink/codespaces-features/tree/main/src/common-amzn) 2) [docker-in-docker-amzn](https://github.com/customink/codespaces-features/tree/main/src/docker-in-docker-amzn).

So, last year I shared how we could [integrate Codespaces](https://dev.to/aws-heroes/getting-started-with-github-codespaces-from-a-serverless-perspective-171k) into our AWS Lambda [docker compose patterns](https://dev.to/aws-heroes/lambda-containers-with-rails-a-perfect-match-4lgb). Since then Microsoft's Development Containers specification has come a LONG way. Everything is wrapped up nice and neatly at the [containers.dev](https://containers.dev) site. Take a look if you have not already seen it.

## Dev Containers?

So why are Development Containers & Codespaces such a big deal? I can illustrate some Lambda & Kubernetes use cases below, but first I would like to spell out a few features that may be new to some. Including existing Codespaces users.

1. The Dev Container [specification](https://containers.dev) at the lowest level of Codespaces is open to everyone and lots of tooling exists around it by a growing community.
2. The specification has a reference implementation via a node [Command Line Interface](Dev Container CLI). Think of this `devcontainer` CLI as a higher order docker compose. You can use this to run Codespaces projects locally!
3. Atop of the CLI, there is CI tooling for [GitHub Actions](https://github.com/devcontainers/ci). This means you can use the same development container as your CI/CD environment.

## Containers Usage Areas

So where are containers used in your organization or projects?  Here are some phases that most of us can identify with. Where projects move from the left to the right.

![Container Areas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mfaiqd32kl7juqatzkgt.png)

**Development:** Most of us have tried to use docker or compose at some point. For example, the most common use of this area would be running a database like MySQL. Docker makes this easy.

**CI/CD:** Typically where we run tests and hopefully build and/or deploy our code to production. If you have used CircleCI before, again a database container here might feel familiar. 

**Runtime:** Which is often our final container environment. We can think of this as production for most of us but it could be any container orchestration like Kubernetes, Lambda, or Fargate.

## Old AWS SAM Patterns with Docker Compose

Today our Lambda SAM cookiecutters leverage SAM's build image via docker compose to ensure local development is within the same environment for our CI/CD tooling. We ended up with something like this image

![AWS Lambda Before Dev Containers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/brm2tkldsfln5adf75oy.png)

At the bottom we can see the host platform typically associated with each of these stages. Because we use Docker, we can be cross-platform and consistent. **The problem?** ⚠️ Making up your own docker/compose patterns are a huge drag. From SSH patterns to Docker-in-Docker gotchas. 

## New AWS SAM Patterns with Dev Containers

In the coming weeks the [Lamby Cookiecutter](https://github.com/customink/lamby-cookiecutter/tree/master/%7B%7Bcookiecutter.project_name%7D%7D) will be updated to use Development Containers so folks with (or without) Codespaces can easily work with the project. The result will be something like this.

![AWS Lambda After Dev Containers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9jxmjokl4nm48mehgzpm.png)

With Development Containers, so much docker compose boilerplate can be removed. Thanks in huge part to our newly released [common & docker-in-docker Amazon Linux 2 features](https://github.com/customink/codespaces-features) work. If you want to see an example of how this helps everyone including running Codespaces locally with VS Code, checkout our [Crypteia Project's Development](https://github.com/customink/crypteia#development) section. You can even use all this without VS Code & GitHub Codespaces. For example:

```shell
devcontainer build --workspace-folder .
devcontainer up --workspace-folder .
devcontainer run-user-commands --workspace-folder .
devcontainer exec --workspace-folder . ./bin/setup
devcontainer exec --workspace-folder . ./bin/test-local
```

## Unexplored Development Container Space

So can Development Containers be used in your projects without the Lambda patterns above? Yes! Consider the following diagram that has a Platform Engineering team building base images. 

![Where could Development Container fit into your Kubernetes/K8s Projects](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fklx3ef7j0ypbnf3fff7.png)

These teams typically approach containers from the right to the left. Where base OS images are made into language specific images with variants for CI/CD. Just like SAM has build and runtime images. Technically for them "Runtime" is some container registry like Amazon ECR, but you get the idea.

At [Custom Ink](https://www.customink.com) we are using our CircleCI images for our Kubernetes projects with Codespaces. The Microsoft team makes this easy since all of their features work with Ubuntu out of the box.

If your development stages look something like the image above. Please consider adopting Development Containers based on your CI/CD images and explore that big purple space by connecting your container value chain in a beautiful little circle. Thanks for reading!