AI Tools for DevOps — Generate Dockerfiles, CI/CD Pipelines, and Kubernetes Manifests

Sanjeev SharmaSanjeev Sharma
5 min read

Advertisement

Introduction

Why This Matters

DevOps configuration files — Dockerfiles, CI/CD pipelines, Kubernetes manifests, and infrastructure-as-code — follow well-established patterns that are well-represented in AI training data. Generating a GitHub Actions workflow for a Python service, writing a multi-stage Dockerfile, or scaffolding a Helm chart are tasks that AI handles accurately on the first try. For DevOps engineers who switch between technology stacks, AI eliminates the need to memorize the exact syntax of every tool in a complex pipeline.

Dockerfile Generation

Prompt:

Generate a production-ready Dockerfile for a Python FastAPI application.
Requirements:
- Python 3.12
- Multi-stage build (builder and runtime stages)
- Non-root user
- Health check endpoint at /health
- Dependencies installed from requirements.txt
- Minimize image size

AI-generated Dockerfile:

# Build stage
FROM python:3.12-slim AS builder
 
WORKDIR /build
 
# Install build dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*
 
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
 
# Runtime stage
FROM python:3.12-slim AS runtime
 
# Create non-root user
RUN groupadd -r appuser && useradd -r -g appuser appuser
 
WORKDIR /app
 
# Copy installed packages from builder
COPY --from=builder /install /usr/local
 
# Copy application code
COPY --chown=appuser:appuser . .
 
USER appuser
 
EXPOSE 8000
 
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
    CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"
 
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

GitHub Actions CI/CD Pipeline

Prompt:

Generate a GitHub Actions workflow for a Node.js application that:
- Runs on push to main and pull requests
- Uses Node.js 20
- Installs dependencies, runs tests, builds the app
- On merge to main: builds a Docker image, pushes to Docker Hub,
  and deploys to a server via SSH
- Caches node_modules between runs

AI-generated workflow:

name: CI/CD
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
 
      - name: Install dependencies
        run: npm ci
 
      - name: Run tests
        run: npm test
 
      - name: Build
        run: npm run build
 
  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
 
      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ secrets.DOCKERHUB_USERNAME }}/myapp:latest
            ${{ secrets.DOCKERHUB_USERNAME }}/myapp:${{ github.sha }}
 
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          script: |
            docker pull ${{ secrets.DOCKERHUB_USERNAME }}/myapp:latest
            docker stop myapp || true
            docker rm myapp || true
            docker run -d \
              --name myapp \
              --restart unless-stopped \
              -p 3000:3000 \
              ${{ secrets.DOCKERHUB_USERNAME }}/myapp:latest

Kubernetes Deployment Manifests

Prompt:

Generate Kubernetes manifests for a web API deployment with:
- 3 replicas, rolling update strategy
- Resource limits: 256Mi memory, 250m CPU
- Liveness and readiness probes on /health
- ConfigMap for non-secret config
- Service of type ClusterIP
- HorizontalPodAutoscaler scaling from 3 to 10 based on CPU
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: web-api
          image: myapp/web-api:latest
          ports:
            - containerPort: 8000
          resources:
            requests:
              memory: "128Mi"
              cpu: "125m"
            limits:
              memory: "256Mi"
              cpu: "250m"
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 5
            periodSeconds: 5
          envFrom:
            - configMapRef:
                name: web-api-config
---
apiVersion: v1
kind: Service
metadata:
  name: web-api
spec:
  selector:
    app: web-api
  ports:
    - port: 80
      targetPort: 8000
  type: ClusterIP
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Troubleshooting with AI

Paste a failing CI log or kubectl describe pod output and ask what is wrong:

This pod keeps crashing with OOMKilled. Here is kubectl describe pod output:
[paste output]
What is happening and how do I fix it?

AI reads the resource limits, restart count, and last exit code to diagnose the issue.

Common Mistakes

  • Deploying AI-generated infrastructure without security review: Default configurations often expose ports or use root users. Review generated Dockerfiles and manifests for security before use.
  • Not pinning image versions: AI often generates image: myapp:latest. Pin to a specific digest in production.
  • Missing resource limits in Kubernetes: AI sometimes omits resource requests/limits. Always specify them explicitly.
  • Not testing CI/CD changes in a branch first: Push pipeline changes to a test branch before merging to main.

Best Practices

  • Specify security requirements explicitly in the prompt (non-root user, multi-stage build, minimal base image)
  • Always pin Docker base image versions to specific tags, not latest
  • Run AI-generated Kubernetes manifests through kubectl apply --dry-run=client before applying to a cluster
  • Use docker scan or Trivy to scan AI-generated images for known CVEs
  • Ask AI to explain each section of a generated config — this builds understanding for when things break

Key Takeaways

  • AI generates production-ready Dockerfiles with multi-stage builds, non-root users, and health checks when explicitly requested
  • GitHub Actions workflow generation is one of the highest-accuracy AI DevOps tasks due to consistent YAML syntax
  • Kubernetes manifests for standard deployments (Deployment, Service, HPA) are generated accurately with explicit requirements
  • Security defaults in AI-generated configs are often insufficient — specify non-root users, read-only filesystems, and network policies
  • Never deploy AI-generated infrastructure code without running it through a staging environment first
  • AI is excellent for translating failing CI logs and kubectl describe output into actionable diagnoses
  • Pin all image versions in generated configs — AI defaults to latest, which is unsafe for production
  • The time saving is largest when switching between infrastructure tools (Terraform to Pulumi, CircleCI to GitHub Actions)

Advertisement

Sanjeev Sharma

Written by

Sanjeev Sharma

Full Stack Engineer · E-mopro

Related reading