agentsclimarketplace
Sign in

Containerization

Skill agent-packs/registry/skills/containerization

Build, configure, and operate containerized workloads with Docker and Kubernetes. Use when creating Dockerfiles, writing Kubernetes manifests, or debugging container runtime issues.From its SKILL.md

Install
npx -y skills add agent-packs/registry --skill containerization

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 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.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.4 KB, 718 tokens by cl100k_base, as published. Nobody here has run it

Containerization

Containers are unit boundaries. Build them small, run them immutably, and treat them as cattle — not pets.

Dockerfile Best Practices

  • Use pinned, minimal base images: node:22-alpine not node:latest. Re-pin regularly on a schedule.
  • Order layers from least-to-most volatile: FROM → RUN apt-get → COPY package.json → RUN npm install → COPY . .. Build cache is invalidated at the first changed layer.
  • Combine RUN steps that share a logical operation into one to minimize layer count and leak of intermediate files.
  • Use multi-stage builds: compile/install in one stage, copy only artifacts to the final stage. Excludes dev tools, source code, and build caches from the image.
  • Run the final process as a non-root user: RUN adduser --disabled-password app && USER app.
  • Use COPY --chown=app:app instead of a separate RUN chown.
  • Set ENTRYPOINT to the process, CMD to its default arguments — so callers can override args without replacing the binary.

Image Hygiene

  • Keep images under 200 MB where feasible. Audit with docker image history and dive.
  • .dockerignore must exclude: node_modules, .git, build artifacts, .env files, and test directories.
  • Never bake secrets into image layers. Use build secrets (--secret id=...) or mount at runtime.
  • Tag images with the git commit SHA in CI: myapp:$GIT_SHA. latest is a debugging alias, not a deployment target.
  • Scan images with docker scout or Trivy before pushing to a registry.

Kubernetes Manifests

  • Set resources.requests and resources.limits on every container. Missing requests prevent the scheduler from placing pods correctly.
  • Use livenessProbe and readinessProbe on all long-running containers. readinessProbe gates traffic; livenessProbe restarts stuck processes.
  • Set terminationGracePeriodSeconds high enough for in-flight requests to drain (30s is often too low for HTTP services).
  • Use PodDisruptionBudget for stateful sets and critical services to prevent zero-availability during rolling updates.
  • Apply labels consistently: app.kubernetes.io/name, app.kubernetes.io/version, app.kubernetes.io/component.
  • Never use hostNetwork: true or privileged: true unless the workload genuinely requires it.

ConfigMaps and Secrets

  • Mount secrets as files, not environment variables — env vars appear in crash dumps and ps output.
  • Rotate secrets by updating the Secret object and rolling the Deployment — pods do not automatically reload mounted secrets.
  • Use SecretProviderClass (CSI driver) or an operator to sync secrets from a vault into Kubernetes rather than storing them in etcd.

Checklist

  • Dockerfile uses pinned base image and multi-stage build.
  • Image runs as non-root with read-only root filesystem where possible.
  • .dockerignore excludes secrets, .git, and build artifacts.
  • Image scanned for CVEs before pushing.
  • All pods have resource requests/limits, liveness, and readiness probes.
  • Secrets mounted as files, not env vars.
  • PodDisruptionBudget in place for critical workloads.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most containers cloud skills give in 718 tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildshere, and in 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • combine RUN steps sharing a logical operation
  • use build secrets or mount at runtime

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,782. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.