Промты для Docker: Dockerfile, Compose, оптимизация образов

{
"title": "10 Prompts for Docker: From Dockerfile to Multi‑Stage Builds (and Beyond)",
"content": "## Introduction\n\nIf you use Docker daily, you know that writing clean Dockerfiles, optimising image sizes, and debugging Compose setups can eat up hours. As a developer who relies on AI assistants to accelerate tasks, I compiled this collection of 10 battle‑tested prompts that I plug into ChatGPT, Claude, or any code‑focused LLM. Each prompt is crafted to produce production‑ready output – from a minimal Python container to a multi‑stage Go build. I’ve included the exact AI response (with minor formatting) so you can copy‑paste and adapt.\n\nLet’s dive in.\n\n---\n\n## 1. Generate a Minimal Dockerfile for a Flask API\n\nPrompt: “Write a Dockerfile for a Python Flask application using pip. The app listens on port 5000. Use python:3.11-slim as the base. Copy only requirements first to leverage caching, then copy the rest. Run as a non‑root user. Include HEALTHCHECK that curls /health.”\n\nResult:\n\ndockerfile\nFROM python:3.11-slim AS builder\nWORKDIR /app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\nFROM python:3.11-slim\nCOPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages\nRUN addgroup --system flask && adduser --system --ingroup flask flask\nUSER flask\nWORKDIR /app\nCOPY . .\nHEALTHCHECK --interval=30s --timeout=3s \\\n CMD curl -f http://localhost:5000/health || exit 1\nEXPOSE 5000\nCMD [\"gunicorn\", \"-w\", \"4\", \"-b\", \"0.0.0.0:5000\", \"app:app\"]\n\n\nWhy it works: The two‑stage layout keeps the final image small; using --no-cache-dir and a non‑root user follows Docker’s security guidelines. The health check ensures orchestrators can monitor the container.\n\n---\n\n## 2. Multi‑Stage Dockerfile for a Go Service\n\nPrompt: “Create a multi‑stage Dockerfile for a Go application. Use golang:1.22 as the build stage, compile with CGO_ENABLED=0, then copy the binary to a scratch image. Add CA certificates for TLS. Expose port 8080 and run as non‑root.”\n\nResult:\n\ndockerfile\nFROM golang:1.22 AS build\nWORKDIR /src\nCOPY go.mod go.sum ./\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 GOOS=linux go build -o /app ./cmd/server\n\nFROM scratch\nCOPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/\nCOPY --from=build /app /app\nEXPOSE 8080\nUSER 1001\nCMD [\"/app\"]\n\n\nWhy it works: Scratch images are minimal (~5 MB) and reduce attack surface. Copying CA certs enables HTTPS calls. The static binary avoids runtime dependencies.\n\n---\n\n## 3. Compose File for a LAMP Stack with Volumes\n\nPrompt: “Write a docker‑compose.yml for a local LAMP stack: Apache with PHP 8.2, MySQL 8.0, and phpMyAdmin. Use named volumes for database persistence, set environment variables for MySQL root password, and expose ports 80 and 8080 for phpMyAdmin.”\n\nResult:\n\nyaml\nversion: '3.9'\nservices:\n web:\n image: httpd:alpine\n ports:\n - \"80:80\"\n volumes:\n - ./src:/usr/local/apache2/htdocs\n depends_on:\n - db\n\n db:\n image: mysql:8.0\n environment:\n MYSQL_ROOT_PASSWORD: rootpass\n volumes:\n - db_data:/var/lib/mysql\n healthcheck:\n test: [\"CMD\", \"mysqladmin\", \"ping\", \"-h\", \"localhost\"]\n interval: 10s\n\n phpmyadmin:\n image: phpmyadmin:latest\n ports:\n - \"8080:80\"\n environment:\n PMA_HOST: db\n depends_on:\n db:\n condition: service_healthy\n\nvolumes:\n db_data:\n\n\nWhy it works: Named volumes survive container restarts; the health check prevents phpMyAdmin from connecting before MySQL is ready. This setup mirrors many real‑world dev environments.\n\n---\n\n## 4. Optimize a Dockerfile (Layer Caching & .dockerignore)\n\nPrompt: “Here’s a Dockerfile that installs dependencies after copying everything. Rewrite it to maximise layer caching. Also generate a .dockerignore for a Node.js project.”\n\nResult (optimised Dockerfile):\n\ndockerfile\nFROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=production\nCOPY . .\nEXPOSE 3000\nCMD [\"node\", \"index.js\"]\n\n\n.dockerignore:\n\n\nnode_modules\nnpm-debug.log*\n.git\n.gitignore\n.env\n*.md\n\n\nWhy it works: By copying package*.json before the rest of the source, Docker can cache the npm ci layer unless dependencies change. The .dockerignore prevents unnecessary files from being sent to the daemon, speeding up builds.\n\n---\n\n## 5. Debug Networking in Compose\n\nPrompt: “My docker‑compose.yml has two services: ‘api’ and ‘db’. The API cannot connect to the database. List the most common reasons and give me a command to diagnose the issue from inside the API container.”\n\nResult (diagnostic command):\n\nbash\ndocker exec -it <api-container> sh -c \"getent hosts db\"\n\n\nCommon causes:\n- Containers not on the same network (custom network missing from networks: in Compose).\n- depends_on without condition: service_healthy – the API starts before MySQL is accepting connections.\n- Hardcoded localhost instead of the service name db.\n- Firewall inside the container or SELinux rules blocking traffic.\n\nWhy it works: getent hosts uses the DNS resolver configured by Docker Compose. If the service name isn’t resolved, the network configuration is wrong.\n\n---\n\n## 6. Convert docker run Command to Compose YAML\n\nPrompt: “Convert this docker run command to a docker‑compose.yml:\ndocker run -d --name redis -p 6379:6379 -v redis-data:/data --restart unless-stopped redis:7-alpine”\n\nResult:\n\nyaml\nservices:\n redis:\n image: redis:7-alpine\n container_name: redis\n ports:\n - \"6379:6379\"\n volumes:\n - redis-data:/data\n restart: unless-stopped\n\nvolumes:\n redis-data:\n\n\nWhy it works: This keeps the same behaviour while making the configuration declarative and version‑controlled. The named volume redis-data will be created automatically.\n\n---\n\n## 7. Security Hardening for a Production Dockerfile\n\nPrompt: “Apply security best practices to this Dockerfile: use a distroless base, run as non‑root, drop all capabilities, and add a read‑only root filesystem. The app is a Java JAR that runs on port 8080.”\n\nResult:\n\ndockerfile\nFROM gcr.io/distroless/java17-debian12\nWORKDIR /app\nCOPY target/app.jar .\nEXPOSE 8080\nUSER nobody\nCMD [\"java\", \"-jar\", \"app.jar\"]\n\n\nFor Kubernetes deployment (annotations):\nyaml\nsecurityContext:\n runAsNonRoot: true\n readOnlyRootFilesystem: true\n capabilities:\n drop: [\"ALL\"]\n\n\nWhy it works: Distroless images contain only the JRE and the app, drastically reducing the attack surface. Dropping all capabilities and using a read‑only filesystem align with the CIS Docker Benchmark.\n\n---\n\n## 8. Write a .dockerignore for a Monorepo\n\nPrompt: “My monorepo has multiple packages (frontend, backend, shared). Write a .dockerignore that excludes everything except the backend package and shared dependencies.”\n\nResult:\n\n\n**/node_modules\n.git\n.gitignore\n.env\nfrontend/\ndocs/\n*.md\n*.log\n\n\nWhy it works: The pattern **/node_modules catches node_modules in any subdirectory. Explicitly listing frontend/ prevents copying the entire frontend code when building the backend image – crucial for monorepo CI pipelines.\n\n---\n\n## 9. Set Up Health Checks in Compose with Dependencies\n\nPrompt: “Write a docker‑compose.yml for a web app that depends on PostgreSQL. Use health checks to ensure the web service only starts after Postgres is ready. Include a restart policy.”\n\nResult:\n\nyaml\nservices:\n db:\n image: postgres:16-alpine\n environment:\n POSTGRES_USER: app\n POSTGRES_PASSWORD: secret\n healthcheck:\n test: [\"CMD-SHELL\", \"pg_isready -U app\"]\n interval: 5s\n timeout: 3s\n retries: 5\n restart: unless-stopped\n\n web:\n build: .\n ports:\n - \"3000:3000\"\n depends_on:\n db:\n condition: service_healthy\n restart: unless-stopped\n\n\nWhy it works: Using condition: service_healthy replaces the unreliable depends_on with a proper readiness check. The pg_isready command is the canonical way to test Postgres availability.\n\n---\n\n## 10. Use BuildKit for Faster Builds\n\nPrompt: “How do I enable BuildKit and use a cache mount to speed up npm installs in a Docker build?”\n\nResult (Dockerfile with cache mount):\n\ndockerfile\n# syntax=docker/dockerfile:1\nFROM node:20-alpine\nRUN --mount=type=cache,target=/root/.npm \\\n npm install\n\n\nEnable BuildKit: DOCKER_BUILDKIT=1 docker build . or set "features": {"buildkit": true} in /etc/docker/daemon.json.\n\nWhy it works: BuildKit’s cache mounts persist between builds without being part of the final image. This can cut build times by 50–70% for dependency‑heavy projects. Official Docker docs recommend BuildKit for production CI.\n\n---\n\n## Conclusion\n\nThese ten prompts cover the most frequent Docker tasks I face daily: crafting secure, slim images, debugging networking, and speeding up builds. Copy, paste, and tweak them to fit your stack. The key is to be specific in your prompt – specify base images, ports, health checks, and security requirements. The AI will then generate code that follows Docker best practices (layer caching, multi‑stage builds, non‑root users).\n\nTry the prompts in your next project. You’ll ship smaller containers and spend less time reading Stack Overflow.\n\nReferences:* Dockerfile best practices, Compose specification, BuildKit.",
"excerpt": "A curated collection of 10 battle-tested AI prompts for Docker workflows – from writing efficient Dockerfiles to multi-stage builds, debugging Compose, and optimizing images. Each prompt includes a real-world example and production-ready output."
}