Containerization
Write container images and compose setups that are small, reproducible, and safe to run. Use when writing Dockerfiles, docker-compose files, or debugging container behavior.From its SKILL.md
npx -y skills add Amey-Thakur/AI-SKILLS --skill containerizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.5 KB, 529 tokens by cl100k_base, as published. Nobody here has run it
Containerization
An image is a frozen promise: same bits, same behavior, anywhere. Keep it small, deterministic, and unprivileged, and the promise holds.
Method
- Base images: specific and slim. Pin to a concrete version tag (node:22-slim, not node:latest); latest converts every rebuild into a surprise. Slim or distroless variants shrink both download and attack surface; alpine only when its libc quirks are understood.
- Order layers by change frequency. Dependency manifests copy and install first, source copies last, so a code change rebuilds one layer instead of reinstalling the world. One RUN per logical step, cleanup in the same layer it dirtied, or the deleted files still ship in the layer below.
- Multi-stage: build heavy, ship light. Compile and bundle in a builder stage; the final stage copies only artifacts and runtime deps. Compilers, dev dependencies, and test fixtures in a production image are pure liability.
- Run as a non-root user, declare the port, and define a healthcheck that exercises the real serving path. Handle SIGTERM for graceful shutdown; a process that ignores it gets killed mid-write at every deploy.
- State stays out of containers. Data in volumes or external services; the container itself must be disposable at any moment. Configuration and secrets arrive by environment or mounted secret files at runtime, never baked into the image; anything COPYed in is published to everyone who can pull.
- Compose for local truthfulness: service per process, healthcheck- based depends_on so ordering is real, named volumes for anything that must survive, and a .dockerignore that keeps .git, node_modules, and local env files out of the build context (both for speed and secrecy).
Debugging order
Container will not start: read its logs, then run the same image with a shell and try the entrypoint by hand. Works locally, fails in the cluster: compare env, mounts, resources, and user. Image too big: inspect layer sizes and find the layer that smuggled the build tools or cache in.
Litmus tests
- Two builds from the same commit: functionally identical images?
- Does anything secret appear in image history or layers?
- Can the container be killed and replaced at any second without data loss?
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.