Containerinfrastruktur med GitHub Copilot
Tip
Se fanen Tekst og billeder for flere detaljer!
Containerisering er ikke længere en separat bekymring fra infrastruktur. Når din applikation kører på Kubernetes, er Dockerfile, Kubernetes-manifesterne og den underliggende Azure-infrastruktur alle en del af samme IaC-netværk. De deler samme versionskontrol, samme CI/CD-pipeline og samme gennemgangsproces.
GitHub Copilot egner sig godt til containerinfrastruktur, fordi Dockerfile-syntaks og Kubernetes YAML er meget strukturerede og mønstrerige. Disse egenskaber er de samme egenskaber, der gør Bicep-generering effektiv. De fleste containeriseringsmønstre optræder ofte i open source-projekter, hvilket giver Copilot stærk dækning af bedste praksis.
Generering af Dockerfiles med GitHub Copilot
Anatomien af en god Dockerfile-prompt
En effektiv Dockerfile-prompt specificerer applikationstypen, basisbilledet, runtime-kravene og sikkerhedskravene. Hvis nogen af disse kernekomponenter i beholderen mangler, får Copilots til at gå over til simplere, men mindre sikre mønstre.
En minimal, men problematisk prompt:
Create a Dockerfile for a Node.js app.
Copilot kan producere en enkelt-trins Dockerfile, der kører som root, inkluderer udviklingsafhængigheder og bruger et ufastgjort basebilledtag. Hver af disse er et sikkerheds- eller effektivitetsproblem.
En bedre prompt:
Generate a production-grade multi-stage Dockerfile for a Node.js Express application.
Requirements:
- Build stage: node:20-alpine, install all dependencies, no build step needed (pure JS)
- Runtime stage: node:20-alpine
- Copy only node_modules and application files to the runtime stage
- Do not include devDependencies in the runtime image
- Create a non-root user with UID 1001 and run the process as that user
- Set NODE_ENV=production
- Expose port 3000
- Add a HEALTHCHECK that polls GET /health every 30 seconds
- Pin the base image to a specific digest for reproducibility
Flertrinsbyggerier
En enkelt-trins Dockerfile kopierer alt ind i det endelige billede, inklusive build-værktøjer, udviklingsafhængigheder, testfiler og kildekort. Denne tilgang kan potentielt øge billedstørrelsen og øge angrebsfladen. Flertrinsbyggerier adskiller byggemiljøet fra runtime-miljøet. Kun de artefakter, der er nødvendige for at køre applikationen, kopieres ind i det endelige billede.
# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Stage 2: Runtime
FROM node:20-alpine AS runtime
WORKDIR /app
# Create non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup -u 1001
# Copy only what is needed from the build stage
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/package.json ./
COPY --from=builder --chown=appuser:appgroup /app/server.js ./
COPY --from=builder --chown=appuser:appgroup /app/routes ./routes
ENV NODE_ENV=production
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "server.js"]
Brug af Copilot som sikkerhedsgennemgang
Efter at have genereret en Dockerfile, bed Copilot om at gennemgå den:
Review this Dockerfile for security vulnerabilities and best practices.
Check for:
1. Processes running as root
2. Sensitive files or environment variables that might be copied into the image
3. Unpinned or mutable image tags (e.g., "latest")
4. Unnecessary packages or capabilities included in the runtime image
5. Missing HEALTHCHECK instruction
6. Layer caching inefficiencies that could expose secrets in build history
Copilot markerer specifikke linjenumre og forklarer hver bekymring. Denne anmeldelsesprompt virker på enhver Dockerfile, ikke kun på dem, der er genereret med Copilot.
Generering af Kubernetes-manifester med GitHub Copilot
Hvad skal inkluderes i en Kubernetes-prompt
Kubernetes-manifest interagerer med klyngespecifikke ressourcer: ingress-controllere, lagringsklasser, navnerum og identitetssystemer. En god Kubernetes-prompt specificerer:
- De nødvendige ressourcetyper (Deployment, Service, Ingress, ConfigMap osv.)
- Applikationens port og protokol
- Ressourceanmodninger og begrænsninger
- Sundhedsprobe-endepunkter
- Miljøvariabler og deres kilde (ConfigMap, Secret eller direkte værdi)
- Navneområde
- Navnet på indgangsklassen, hvis relevant
Generering af en fuld deployment-stack
Generate Kubernetes YAML manifests for a Node.js API application on AKS.
Include the following resources separated by ---:
Deployment:
- 3 replicas
- Image: iaclab-api:v1 (from a private ACR registry acr-iaclab.azurecr.io)
- Resource requests: 100m CPU, 128Mi memory
- Resource limits: 500m CPU, 512Mi memory
- Liveness probe: GET /health on port 3000, initialDelaySeconds 10, periodSeconds 15
- Readiness probe: GET /ready on port 3000, initialDelaySeconds 5, periodSeconds 10
- Environment variable APP_ENV sourced from a ConfigMap named "iaclab-config"
- Pod anti-affinity: prefer to spread replicas across different nodes
(preferredDuringSchedulingIgnoredDuringExecution)
Service:
- ClusterIP type
- Port 80 mapping to container port 3000
Ingress:
- Ingress class: nginx
- Host: iaclab.training.azure.com
- Path: / (prefix)
- TLS: reference a secret named "iaclab-tls"
ConfigMap:
- Name: iaclab-config
- Key APP_ENV with value "staging"
Apply namespace: iaclab to all resources.
Forståelse af sundhedsprober
Kubernetes bruger to typer probes til at styre containerens livscyklus.
Liveness-sonden besvarer spørgsmålet: er denne beholder levende? Hvis liveness-proben fejler gentagne gange, dræber Kubernetes containeren og starter en ny. Brug den til at opdage, når applikationen gik ind i en tilstand uden genoprettelighed, såsom en deadlock eller crash-loop.
Readiness probe besvarer spørgsmålet: er denne container klar til at modtage trafik? Hvis readiness probe fejler, fjerner Kubernetes pod'en fra Service-endpointlisten. Trafikken stopper med at strømme til den, indtil sonden er kommet sig. Brug den til at signalere, når applikationen er færdig med opstart eller midlertidigt er overbelastet.
For at tilføje en startup-probe:
Add a startupProbe to the Deployment container spec. The startup probe should
call GET /health on port 3000, with a failureThreshold of 30 and
periodSeconds of 10. This gives the container up to 5 minutes to start before
liveness probes begin checking.
Hærdning med sikkerhedskontekster
Som standard kører Kubernetes-containere med flere privilegier end nødvendigt. A securityContext på pod- og containerniveau begrænser, hvad beholderen kan gøre.
Add security contexts to the Deployment in this manifest:
Pod-level securityContext:
- runAsNonRoot: true
- seccompProfile type: RuntimeDefault
Container-level securityContext:
- runAsUser: 1001
- runAsGroup: 1001
- readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false
- capabilities: drop ALL
Also add an emptyDir volume mounted at /tmp so the application can write
temporary files despite the read-only root filesystem.
Efter Copilot har genereret det opdaterede manifest, bed det forklare hver indstilling:
Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.
Dette mønster fungerer godt til teamlæring. Brug Copilot til at generere, og brug derefter Copilot til at forklare.
AKS-specifikke mønstre
AKS introducerer Azure-specifikke koncepter, som standard Kubernetes-manifest ikke adresserer. Copilot kender disse mønstre godt.
Arbejdsbyrdeidentitet:
Add Azure Workload Identity annotations to the Deployment and ServiceAccount.
The workload should use a managed identity with client ID
"00000000-0000-0000-0000-000000000000".
Add the required azure.workload.identity/client-id annotation to the
ServiceAccount and the azure.workload.identity/use: "true" label to the pod spec.
Azure diskpersistent volumen:
Add a PersistentVolumeClaim for 10Gi using the managed-csi storage class
(Azure Disk). Mount it at /data in the container with ReadWriteOnce access mode.
Pod-forstyrrelsesbudget:
Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).
Gennemgang af eksisterende manifest
Indsæt enhver Kubernetes-manifest i Copilot Chat og bed om en anmeldelse:
Review this Kubernetes manifest for:
1. Security issues (missing security context, running as root, privileged containers)
2. Missing resource requests or limits
3. Missing health probes
4. Configurations that would cause problems in a production AKS cluster
5. Any deprecated API versions (e.g., apps/v1beta is deprecated)
For each issue, identify the line, explain the risk, and provide the corrected YAML.
Denne gennemgangsprompt er nyttig for teams, der har samlet manifest over tid og ønsker at bringe dem op på nuværende standarder uden manuel revision af hver fil.
Stillads til rorkortet
Til genanvendelig applikationspakning kan Copilot støtte Helm-diagramstrukturer. Brug en prompt, der angiver diagramnavnet, ressourcerne der skal inkluderes, værdierne der skal parametriseres og eventuelle AKS-specifikke krav såsom ingress-klasse eller arbejdsbelastningsidentitet. Copilot genererer Chart.yaml, values.yaml og skabelonfilerne i den forventede mappestruktur. Gennemgå de genererede values.yaml nøje for at sikre, at følsomme standardindstillinger ikke er overført til versionskontrol.