Builds Docker images and configures Compose, Kubernetes, Helm and container security.
npx skills add https://github.com/Lynricsy/HyperSkills --skill containers-lynricsy
Please help me install this Agent Skill. Skill: containers Source: https://github.com/Lynricsy/HyperSkills/tree/main/skills/containers Command: npx skills add https://github.com/Lynricsy/HyperSkills --skill containers-lynricsy
docker history cannot see, liveness probes that turn one database outage into a fleet-wide restart storm, removed Kubernetes API versions that make manifests undeployable, and Compose files whose depends_on never actually waits. This Skill encodes verified, version-gated rules for the full container lifecycle so reviews and builds catch these failures before production does. ## Core Features & Use Cases - Dockerfile authoring and slimming: multi-stage structure, cache ordering, .dockerignore, secret mounts instead of build args, distroless runtime bases, and digest pinning, with measured before/after evidence. - Kubernetes manifest review: probe semantics, resource limits and QoS, PodDisruptionBudgets, restricted Pod Security Standards, NetworkPolicy, and offline validation with kubeconform against the target cluster version. - Compose development environments: healthcheck-gated dependencies, profiles for one-shot jobs, develop.watch instead of whole-tree bind mounts, and a cold-start validation gate. - Helm, Kustomize, devcontainers and GPU workloads: chart versus overlay decision rules, devcontainer lifecycle and prebuild boundaries, and NVIDIA/AMD device-plugin sharing contracts including time-slicing, MPS and MIG isolation limits. - Use Case: A pod stuck in CrashLoopBackOff is diagnosed by reading events, previous-container logs and exit codes, quoting the evidence before naming the root cause, then verifying the fix with the same command. ## Quick Start Ask the agent to review your Dockerfile and Kubernetes manifests for security and reliability issues using the containers skill.High-intent search queries and answers about installing and using this skill.
Split the Dockerfile into dependency, build and runtime stages, then copy only named artefacts into a minimal runtime base such as distroless or scratch. Order instructions by rate of change so dependency installs stay cached, and add a .dockerignore to keep .git and host dependencies out of the build context.
Use RUN --mount=type=secret,id=<name> and read /run/secrets/<name> inside the instruction. A credential passed as a build ARG is recorded verbatim in the BuildKit provenance attestation even if the stage is discarded, and docker history will not reveal the leak.
The short form depends_on only waits for the container to be created, not for the process to accept connections. Use the long form with condition: service_healthy plus a real healthcheck on the dependency, or service_completed_successfully for migration jobs.
Liveness answers whether the process is wedged and triggers a restart; readiness answers whether it can serve traffic right now. Dependency checks belong in readiness only, because a liveness probe that queries a database turns one outage into a simultaneous restart of every replica.
Always set a memory limit, but prefer leaving CPU unlimited unless the workload is batch, multi-tenant or deliberately Guaranteed. A CPU limit is enforced as a CFS quota, throttling the container at the ceiling every scheduling window even when the node is idle.
Yes, use kubeconform with -kubernetes-version and -strict, plus kubectl kustomize or helm template to render first. Note that kubectl apply --dry-run=client still requires a reachable cluster because it fetches the OpenAPI schema and performs discovery.
mf-dynatraceMonitor and analyze service performance and runtime metrics using DQL and OneAgent.
fajshahProvision and manage multi-cloud GKE clusters with kubectl connectivity.
vertivolatamImplement an observability stack with Prometheus, Grafana, OpenTelemetry, and Loki.
darellchua2Provision Kubernetes infrastructure and deploy Helm charts using OpenTofu.