agentleFS
CowboyLogicCowboyLogic/ai-dev/skills/docker-image-management/SKILL.md

docker-image-management

Skill4 starsChanged 11 days agoMITView on GitHub

Guide for creating, building, and managing Docker images and containers. Use this skill when working with Dockerfiles, containerization, image building, registry operations, container runtime, storage mounts, image security, Docker Compose, or any Docker-related task including optimization, debugging, and best practices.

  • Reads credentials
  • Installs packages

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always load the relevant reference file before giving guidance on that topic.

    line 20
  2. Very specific:

    Run as a non-root USER — always.

    line 25
  3. Very specific:

    Never embed secrets in image layers.

    line 26
  4. Very specific:

    Use official or verified publisher base images.

    line 27
  5. Distinctive:

    Use multi-stage builds to keep production images free of build tools.

    line 33
  6. Very specific:

    Use docker buildx build for advanced features (multi-platform, custom builders).

    line 43
  7. Distinctive:

    Before writing a Dockerfile, identify:

    line 48
  8. Very specific:

    Read references/build.md for Dockerfile instruction guidance and patterns.

    line 56
  9. Very specific:

    Read references/run.md for full runtime options.

    line 84
  10. Very specific:

    Read references/registry.md for authentication, tagging strategy, and vulnerability scanning.

    line 91

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Docker Image Management Skill

This skill covers the full lifecycle of Docker container images: authoring Dockerfiles, building with BuildKit, running containers, managing storage, pushing to registries, and scanning for vulnerabilities.

Quick Decision Guide

TaskLoad
Writing or optimizing a Dockerfile, multi-stage builds, build cache, build secretsreferences/build.md
Running containers, networking, mounts, resource limits, capabilitiesreferences/run.md
Tagging, pushing/pulling, Docker Hub auth, image scanning (Scout)references/registry.md
Multi-container appsreferences/docker-compose-examples.yml
Dockerfile templates for Node, Python, Go, Java, etc.references/dockerfile-templates.md

Always load the relevant reference file before giving guidance on that topic.

Core Principles

Security first

  • Run as a non-root USER — always. Docker Scout flags containers running as root.
  • Never embed secrets in image layers. Use build-time --secret mounts or runtime env vars.
  • Use official or verified publisher base images. Pin to a specific tag (e.g. node:22-alpine) or digest for reproducibility.

Layer efficiency

  • Order COPY/RUN instructions from least-to-most frequently changed to maximize cache reuse.
  • Install dependencies before copying app code.
  • Combine apt-get update && apt-get install in a single RUN; clean up in the same layer.
  • Use multi-stage builds to keep production images free of build tools.

BuildKit is the default

BuildKit is enabled by default in Docker Engine 23.0+ and Docker Desktop. It provides:

  • Parallel stage execution
  • Efficient layer caching
  • Secret mounts (--secret)
  • SSH forwarding (--ssh)
  • Inline cache export

Use docker buildx build for advanced features (multi-platform, custom builders). docker build wraps Buildx.

Standard Workflow

1. Analyze requirements

Before writing a Dockerfile, identify:

  • Runtime vs. build-only dependencies
  • Exposed ports
  • Required env vars and config
  • Persistent data (volumes)
  • Security context (user, capabilities)

2. Write the Dockerfile

Read references/build.md for Dockerfile instruction guidance and patterns. Copy a starter from references/dockerfile-templates.md and customize.

3. Create .dockerignore

Exclude node_modules/, .git/, .env, *.log, build output dirs, and test files. See references/dockerignore-template for language-specific patterns.

4. Build the image

# Standard build
docker build -t myapp:1.0 .

# Build + push in one step
docker build --push -t registry.example.com/myapp:1.0 .

# Pull fresh base, bypass cache
docker build --pull --no-cache -t myapp:1.0 .

# Pass a build secret (never use --build-arg for secrets)
docker build --secret id=mysecret,src=.env -t myapp:1.0 .

5. Run and test

docker run --rm -p 3000:3000 myapp:1.0
docker logs <container>
docker exec -it <container> sh

Read references/run.md for full runtime options.

6. Tag and push

docker tag myapp:1.0 myorg/myapp:1.0
docker push myorg/myapp:1.0

Read references/registry.md for authentication, tagging strategy, and vulnerability scanning.

Debugging Checklist

SymptomAction
Container exits immediatelydocker logs <container>
Port not reachableCheck -p HOST:CONTAINER, verify EXPOSE
File not found in containerCheck .dockerignore, verify COPY paths
Permission deniedCheck USER and file ownership
Large image sizeUse multi-stage build, alpine base, .dockerignore
Build cache not workingVerify COPY order; check if files changed
Secret exposed in layerUse --secret mount, not --build-arg

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.