
I tend to create environments for my labs using containers. These containers would hold the resources I need for a certain job. Here's a guide on how I usually create them from scratch.

## Project Structure

Let’s assume we have a folder named `lab-container` with the following structure:

lab-container/ ├── Dockerfile ├── build │ └── binaries.sh ├── .dockerignore ├── Makefile ├── .github │ └── workflows │ └── ci.yml ├── README.md └── zshrc

We'll walk through each file step by step.

---

## The Dockerfile

Here’s a **multi-stage Dockerfile** that compiles and strips binaries in a builder stage, then copies them into a smaller final image:

```bash
FROM alpine:3.19 AS builder

WORKDIR /build

ARG TERRAFORM_VERSION="1.3.9"
ARG VAULT_VERSION="1.12.4"
ARG HELM_VERSION="3.11.2"
ARG KUBECTL_VERSION="v1.26.1"
ARG KIND_VERSION="v0.17.0"
ARG TRAEFIK_VERSION="2.9.6"
ARG TASK_VERSION="3.19.0"

RUN apk update && apk add --no-cache \
      bash \
      curl \
      wget \
      unzip \
      git \
      tar \
      ca-certificates \
      upx \
      binutils  # `strip` and `upx` to reduce binary sizes

COPY build/binaries.sh /build/binaries.sh
RUN chmod +x /build/binaries.sh && /build/binaries.sh

# Optionally strip and compress
RUN strip --strip-unneeded /usr/local/bin/* || true
RUN upx --best --lzma /usr/local/bin/* || true

################################################################################
# Final image
################################################################################
FROM alpine:3.19

LABEL maintainer="YourName" \
      description="A lightweight DevOps toolbox container."

WORKDIR /labs
ENV PATH="/labs/bin:$PATH"

RUN apk update && apk add --no-cache \
      bash \
      ca-certificates \
      python3 \
      py3-pip \
      aws-cli \
      zsh \
      jq \
      fzf \
      eza

COPY --from=builder /build/bin/ /usr/local/bin/

COPY zshrc /root/.zshrc

SHELL ["/bin/zsh", "-c"]

CMD ["zsh"]
```

### Explanation

Builder Stage:

- Installs dependencies (bash, curl, tar, etc.) needed to fetch and install binaries.

- Copies binaries.sh which downloads and installs Terraform, Vault, Helm, etc.

- Uses strip and upx to reduce final binary sizes.

### Final Stage:

- Starts with a fresh Alpine base.

- Installs additional packages (e.g., AWS CLI, zsh, jq, fzf).

- Copies the compiled binaries from the builder stage.

- Sets up a default shell (zsh) and copies a zshrc config file for a nice shell environment.

## build/binaries.sh

This script downloads and installs each DevOps tool. For example:

```bash
#!/usr/bin/env bash
set -euxo pipefail

# In this script, you can use $TERRAFORM_VERSION, $VAULT_VERSION, etc.
# to download each tool. For instance:
wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip
unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip -d /usr/local/bin
rm terraform_${TERRAFORM_VERSION}_linux_amd64.zip

# Similarly for Vault:
wget https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_amd64.zip
unzip vault_${VAULT_VERSION}_linux_amd64.zip -d /usr/local/bin
rm vault_${VAULT_VERSION}_linux_amd64.zip

# ... repeat for Helm, kubectl, kind, Traefik, Task, etc.
# e.g. for kubectl:
curl -L "https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl" -o /usr/local/bin/kubectl
chmod +x /usr/local/bin/kubectl

# For kind:
curl -Lo /usr/local/bin/kind "https://kind.sigs.k8s.io/dl/${KIND_VERSION}/kind-linux-amd64"
chmod +x /usr/local/bin/kind

# For Task CLI:
curl -L https://github.com/go-task/task/releases/download/v${TASK_VERSION}/task_linux_amd64.tar.gz | tar -zx -C /usr/local/bin
```

Tip: Keep the script idempotent. If you run it twice, it shouldn’t break anything.

## .dockerignore

The .dockerignore helps exclude files you don’t want in your build context (like .git, logs, local environment files, etc.):

```bash
.env
.DS_Store
*.log
.git
.gitignore
README.md
node_modules/
```

Adjust to your needs.

## Makefile

A simple Makefile can streamline common Docker tasks:

```makefile
IMAGE_NAME = your-dockerhub-username/devops-toolbox
VERSION = v1.0.0
LATEST = latest

.PHONY: build
build:
	docker build -t $(IMAGE_NAME):$(LATEST) .

.PHONY: run
run:
	docker run --rm -it $(IMAGE_NAME):$(LATEST) zsh

.PHONY: test
test:
	docker run --rm $(IMAGE_NAME):$(LATEST) sh -c ' \
		echo "Checking installed tools..."; \
		terraform --version && \
		vault --version && \
		aws --version && \
		kubectl version --client && \
		helm version && \
		kind version && \
		traefik version && \
		task --version && \
		docker version \
	'

.PHONY: push
push:
	docker tag $(IMAGE_NAME):$(LATEST) $(IMAGE_NAME):$(VERSION)
	docker push $(IMAGE_NAME):$(VERSION)
	docker push $(IMAGE_NAME):$(LATEST)

.PHONY: clean
clean:
	docker image prune -f

.PHONY: deploy-k8s
deploy-k8s:
	kubectl run toolbox --image=$(IMAGE_NAME):$(LATEST) -- sleep infinity

.PHONY: exec-k8s
exec-k8s:
	kubectl exec -it toolbox -- zsh

```

## Explanation

build: Builds the Docker image locally with the latest tag.

run: Launches the container in an interactive shell.

test: Runs each tool’s --version to confirm they’re installed.

push: Tags and pushes the image to Docker Hub.

deploy-k8s: Runs the container in a Kubernetes pod.

exec-k8s: Opens a shell into that running pod.

## zshrc

For a better shell experience, add your Zsh config:

```bash
export PATH="/usr/local/bin:$PATH"
export EDITOR=vim

# Enable autocompletion
autoload -Uz compinit
compinit

# Enable fzf for fuzzy search
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh

# Some aliases
alias ls="eza --icons=always"
alias la="eza -al --icons"

# Theme or prompt settings (e.g. powerlevel10k)
ZSH_THEME="powerlevel10k/powerlevel10k"
[[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh
```

More aliases for kubectl, terraform, etc. as desired

## GitHub Actions (Optional)
 
If you want automatic builds when you push changes, create .github/workflows/ci.yml:

```yaml
name: devops-toolbox

on:
  push:
    paths:
      - .github/workflows/ci.yml
      - Dockerfile
      - build/binaries.sh

jobs:
  build-and-publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write

    steps:
    - name: Check out
      uses: actions/checkout@v2

    - name: Log in to Docker Hub
      uses: docker/login-action@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKERHUB_TOKEN }}

    - name: Build and Publish
      run: |
        registry="your-dockerhub-username"
        sha=$(git rev-parse --short HEAD)
        primary_tag="${registry}/devops-toolbox:${sha}"

        docker build -t $primary_tag -f Dockerfile .
        docker push $primary_tag

        current_branch=$(git rev-parse --abbrev-ref HEAD)
        if [ "$current_branch" = "main" ]; then
          retention_tag="${registry}/devops-toolbox:rc-${sha}"
          docker tag $primary_tag $retention_tag
          docker push $retention_tag
        else
          retention_tag="${registry}/devops-toolbox:alpha-${sha}"
          docker tag $primary_tag $retention_tag
          docker push $retention_tag
        fi
```

When you push changes to GitHub, this workflow will build your Docker image and push it to your Docker Hub account.

## Building and Testing Locally

Build:

```bash
make build
```

`docker build -t your-dockerhub-username/devops-toolbox:latest .`

Test:

```bash
make test
```

This checks each installed tool’s version.

Run:
```bash
make run
```

You should see a Zsh prompt with Terraform, Vault, AWS CLI, Helm, kubectl, etc. available.

## Pushing to Docker Hub
Assuming you’re logged in to Docker Hub (docker login), run:

`make push`

This tags the image with v1.0.0 and latest, then pushes both to your Docker Hub repository.

## Deploying in Kubernetes

If you want to spin up this container in a Kubernetes cluster:

`make deploy-k8s`

It creates a pod named toolbox that sleeps indefinitely. To open a shell inside that pod:

`make exec-k8s`

You’ll then see the same environment as the local container—handy for on-cluster troubleshooting or dev tasks.

## Conclusion

By following these steps, you’ve built a DevOps Toolbox container from scratch. You learned how to:

- Use a multi-stage Dockerfile to install and strip binaries.

- Write a script (binaries.sh) for easy updates to Terraform, Vault, Helm, etc.

- Set up a Zsh environment with helpful aliases.

- Automate builds with Makefile and optionally GitHub Actions.

- Push your image to Docker Hub and deploy it on Kubernetes.

This container simplifies DevOps tasks, letting you quickly spin up a consistent environment anywhere Docker or Kubernetes runs. 


An end-to-end guide for creating a lab container for DevOps training.

Creating a Lab Container


Containerising applications has become the norm in the IT/DevOps industry, allowing developers to condense their application code and all its dependencies in a lightweight and portable environment so that these applications can be deployed anywhere virtually.

Before going into containers, we must first understand why they were designed.

Let’s just say a Python application has been developed, the next logical step would be to deploy it; this can be complex as well as time-consuming. This is because a running app requires a myriad of configurations, ranging from the allocation of resources to setting up environmental variables.

Another consideration for the application is the ability of it being portable. If a developer needs to change the deployment environment or move to another cloud provider, they will need to repeat many steps of the deployment process. Once again, this can be a mundane process.

Containers efficiently solve the issues by packaging the codebase for the application with all the required dependences — including tools, libraries, config files and run-times. This process of containerisation ensures a lightweight and secure package (depending on how it’s done) known as a container image.

This image can then be used to deploy a containerised application in any environment required, thus giving the developers the much-needed freedom to design and develop apps without having to think about other constraints. Some common container runtimes are Docker, containerd and CRI-O.


![Cargo ships in reference to containers](/images/containers-intro.png)

Many large IT organisations became frustrated with 4–6 month releases and sluggish deployments. Organisations like Netflix and many others began to embrace microservices, thus helping them overtake their fellow competitors — who also had a similar plan. So applications began being built using microservices, heavily transforming into a more DevOps and Agile culture; larger teams were split into smaller ones to allow for this transformation.


DevOps cycle releases
Then came along issues whilst building microservices. Amongst those issues was containerising applications so that they are deployable on any environment, including a Dev’s one. As mentioned before, it was the idea of containers that solved this issue and then this lead to another issue which was managing these containers. This is where the story of Kubernetes began.

So, Kubernetes is a container orchestration platform or in simple terms, an application management platform.

Fun fact: The name Kubernetes itself stems from an ancient Greek word for “helmsman”, meaning he who steers a ship thus telling the story behind the K8s logo. Another name for Kubernetes (you hear it quite often) is “K8s” — the reason for this name is, the 8 letters between the “k” and the “s” in Kubernetes.

Note: From now on, K8s may be used to refer to Kubernetes sporadically.


![The Galver depicting the Kubernetes control mechanism](/images/ship.png)

## Why Kubernetes overtook its competitor OpenStack?

Although K8s and OpenStack have produced similar level of interests, they are slightly different from each other. In the end, Kubernetes has succeeded where OpenStack fell behind. The reason being, Kubernetes’ ability to provide business value and focus on the bigger picture which is the Enterprise IT applications. On the other hand, OpenStack orchestrated infrastructure and no matter how good your infrastructure management is, if you are not solving business problems, what use is it?

## Okay, so how does Kubernetes help me or my company ?

As mentioned before, Kubernetes enables a “microservice” approach to building modern application and larger teams can be split into smaller ones — leading to a much faster time to market, deployments of applications are always being updated and later versions are released.

**Costs of IT infrastructure are more optimised**. K8s can help your organisation largely cut infrastructure costs especially if they’re operating at a huge scale. Prior to the introduction of K8s, IT and Sys Admin, commonly over-provisioned their infrastructure to handle unexpected spikes. K8s is wise enough to schedule and put together containers, while taking into consideration available resources.

Nowadays, the success of applications doesn’t merely depend on features, but also on the scalability of the application. For indeed, if an app cannot scale properly, it will not perform at its best. Kubernetes is critical in this process as it scales and improves app performance. Let’s say we have a service which takes up high-CPU and its quite dynamic, meaning it changes based on business conditions; the solution required here would be something that can scale up the app so that new VMs are automatically created or scaled down when the load is reduced. Kubernetes offers just that capability by scaling up the app as the CPU usage goes above a certain threshold and scales back as a result, optimising the infrastructure utilisation. This feature of K8s auto-scaling known as Horizontal Pod Autoscaler (HPA) is not limited to managed metrics and custom metrics can also be used to trigger the auto-scaling process.

This article mentions only a few of the main benefits of Kubernetes and its various benefits can be spoken about for days.

What is next?

I’m currently on a journey to learn more about the ever-growing ecosystem of containers, container orchestration and the DevOps culture. Expect to see more articles and open-source contributions. Stay tuned for more!

A look at the ever-changing landscape of modern applications

Posts tagged with: docker