taegost/devops-toolbox repository overview

⁠DevOps Toolbox

A self-contained development environment image providing consistent, versioned DevOps tooling across any machine or IDE that supports the Dev Container specification⁠.

Built and published automatically via GitHub Actions. Pull it on any machine with Docker and VS Code — no local setup required.

⁠What's Inside

⁠Ansible Collections

⁠Python Packages (Ansible)

⁠Cloud CLI Authentication

The four cloud CLIs require credentials to interact with their respective platforms. None of these are baked into the image — credentials are always provided at runtime via mounts or environment variables.

AWS CLI — mount your credentials file, or pass environment variables:

"mounts": [
"source=${localEnv:HOME}/.aws,target=/home/vscode/.aws,type=bind,readonly"
]

Or use environment variables in devcontainer.json:

"containerEnv": {
  "AWS_ACCESS_KEY_ID": "${localEnv:AWS_ACCESS_KEY_ID}",
  "AWS_SECRET_ACCESS_KEY": "${localEnv:AWS_SECRET_ACCESS_KEY}",
  "AWS_DEFAULT_REGION": "${localEnv:AWS_DEFAULT_REGION}"
}

Azure CLI — run az login interactively inside the container after it starts. The credentials are cached in ~/.azure inside the container session.

gcloud CLI — run gcloud auth login interactively inside the container after it starts. The credentials are cached in ~/.config/gcloud inside the container session. For service account authentication, mount your key file:

"mounts": [
  "source=/path/to/sa-key.json,target=/home/vscode/sa-key.json,type=bind,readonly"
],
"containerEnv": {
  "GOOGLE_APPLICATION_CREDENTIALS": "/home/vscode/sa-key.json"
}

GitHub CLI — run gh auth login interactively inside the container after it starts, or mount your hosts configuration:

"mounts": [
  "source=${localEnv:HOME}/.config/gh,target=/home/vscode/.config/gh,type=bind,readonly"
]

⁠Using This Image in a Project

Add the Dev Containers⁠ extension from Microsoft to VS Code.

NOTE: If you're running this in WSL through VS Code, you should change these settings:

Enable Dev › Containers: Execute In WSL
Enable Dev › Containers: Forward WSL Services if you use things like X, Wayland, or SSH Agents such as Bitwarden

Then, add a .devcontainer/devcontainer.json to your project repository with the proper updates (if necessary). VS Code will detect it automatically and offer to reopen the project inside the container.

NOTE: This is just a quick example. For the latest, fully detailed version of the sample, please see the devcontainer.json in source control⁠

{
  "name": "My Project",
  "image": "taegost/devops-toolbox:latest",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached",
  "remoteUser": "vscode",
  "customizations": {
    "vscode": {
      "extensions": [
        // Add project-specific extensions here
      ]
    }
  }
}

⁠Project-Specific Dependencies

The container provides the toolbox. Project-specific dependencies are installed after the container starts using postCreateCommand:

Python project:

"postCreateCommand": "pip install -r requirements.txt"

Ansible project with additional collections:

"postCreateCommand": "ansible-galaxy collection install -r requirements.yml"

Both can be combined:

"postCreateCommand": "pip install -r requirements.txt && ansible-galaxy collection install -r requirements.yml"

⁠Image Tags

Images are published to Docker Hub at taegost/devops-toolbox.

⁠Why No Date or "Weekly" Tag?

A weekly tag would be a moving pointer, semantically identical to latest. It would add noise to Docker Hub without adding meaning — anyone pinning to weekly gets the same behavior as pinning to latest. The tags above cover all real use cases:

• Staying current: use latest
• Stability: pin to a semver tag (1.2.3)
• Traceability: use the sha-<commit> tag to trace any image back to its exact source commit

The weekly scheduled pipeline rebuild ensures latest always incorporates the most recent base image security patches, even without a code change.

⁠Updating Tool Versions

Tool versions are pinned as ARG declarations directly above each tool's install block in the Dockerfile⁠, rather than grouped at the top of the file. This is intentional — it ensures that changing one tool's version only invalidates the Docker layer cache from that tool downward, leaving unrelated tools fully cached.

1. Find the tool's ARG declaration in the Dockerfile — it will be immediately above its install block, with a comment header identifying the tool
2. Update the matching entry in .env.example⁠
3. Open a pull request — the pipeline will build and validate the image
4. Merge and tag a new release (ex. v1.1.0) to publish semver tags

To find a tool's current version quickly without reading the full Dockerfile, check .env.example⁠ — it mirrors all version pins and includes links to each tool's release page.

⁠Local Builds

To build the image locally without pushing:

# Copy the example env file
cp .env.example .env

# Edit .env if you want to test different versions
# Then build:
docker build \
  $(grep -v '^#' .env | grep -v '^$' | sed 's/^/--build-arg /') \
  -t devops-toolbox:local .

⁠Repository Structure

devops-toolbox/
├── .github/
│   └── workflows/
│       └── build-and-push.yml    # CI/CD pipeline
├── .devcontainer/
│   └── devcontainer.json         # VS Code config for this repo
├── dependencies/
│   ├── ansible-requirements.yml  # Toolbox-level Ansible collections
│   ├── python-ansible-requirements.txt  # Packages injected into Ansible venv
│   └── python-dev-requirements.txt      # Python development tooling
├── Dockerfile                    # Image definition
├── .dockerignore                 # Build context exclusions
├── .env.example                  # Local build variable reference
├── .gitignore
└── README.md

⁠Required Secrets

The pipeline requires the following secrets configured in GitHub:

Generate a Docker Hub access token at: hub.docker.com → Account Settings → Security → New Access Token