- Home
- Skills
- Williamzujkowski
- Standards
- Containers
containers_skill
- Python
13
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill williamzujkowski/standards --skill containers- SKILL.md6.5 KB
Overview
This skill captures production-ready container practices for fast, secure, and minimal images. It focuses on immutable infrastructure, single-responsibility containers, and image optimization so teams can start projects correctly and avoid common runtime risks. Practical examples, templates, and CI/CD integration patterns accelerate adoption.
How this skill works
The skill inspects and prescribes Dockerfile patterns, build strategies, and runtime configuration. It covers multi-stage builds, layer ordering, minimal base images, non-root execution, healthchecks, resource limits, and vulnerability scanning. It also maps integration points to registries, scanners, and orchestrators for end-to-end workflows.
When to use it
- Starting a new service or refactoring an existing Dockerfile
- Preparing production-ready container images for deployment
- Reducing image size and attack surface before CI/CD builds
- Enforcing runtime safety: non-root, healthchecks, resource limits
- Integrating image scans and signing into pipelines
Best practices
- Use minimal, pinned base images (alpine, distroless) and avoid :latest tags
- Adopt multi-stage builds to separate build dependencies from runtime artifacts
- Run processes as a non-root user and prefer a read-only filesystem when possible
- Order Dockerfile commands to maximise layer cache and use .dockerignore
- Add healthchecks, resource limits, and vulnerability scans to CI/CD
- Avoid embedding secrets in images; use build-time secrets or secret managers
Example use cases
- Quick-start Dockerfile for a small web service using Alpine and a non-root user
- Multi-stage Go or Python builds that produce tiny runtime images (distroless/slim)
- CI pipeline that builds, scans (Trivy/Snyk), and pushes images with pinned tags
- Compose or orchestrator configs that set CPU/memory limits and healthchecks
- Templates for language-specific Dockerfiles and scripts for multi-arch builds
FAQ
:latest yields non-deterministic builds and can cause inconsistent deployments; pin explicit version tags to ensure repeatability.
How do multi-stage builds help?
They separate build-time dependencies from runtime artifacts, producing smaller, leaner images and removing compilers and caches from the final image.
What basic scans and checks should CI run?
Include vulnerability scans (Trivy/Snyk), image size checks, secret scanning (gitleaks/trufflehog), and linting of Dockerfiles; fail builds on high-severity findings.