Infrastructura containerelor cu GitHub Copilot
Sfat
Consultați fila Text și imagini pentru mai multe detalii!
Containerizarea nu mai este o preocupare separată de infrastructură. Când aplicația ta rulează pe Kubernetes, Dockerfile-ul, manifestele Kubernetes și infrastructura Azure de bază fac toate parte din aceeași stare IaC. Au același control de versiune, același pipeline CI/CD și același proces de revizuire.
GitHub Copilot este foarte potrivit pentru infrastructura containerelor deoarece sintaxa Dockerfile și KAML-ul Kubernetes sunt foarte structurate și bogate în pattern-uri. Aceste caracteristici sunt aceleași care fac producția Bicep eficientă. Majoritatea tiparelor de containerizare apar frecvent în proiecte open-source, oferind Copilot o acoperire puternică a celor mai bune practici.
Generarea Dockerfiles cu GitHub Copilot
Anatomia unui prompt bun de pe Dockerfile
Un prompt Dockerfile eficient specifică tipul aplicației, imaginea de bază, cerințele de runtime și cerințele de securitate. Lipsa oricăruia dintre aceste componente de bază ale containerului determină Copiloții să adopte în mod implicit modele mai simple, dar mai puțin sigure.
Un prompt minim, dar problematic:
Create a Dockerfile for a Node.js app.
Copilot poate produce un fișier Dockerfile cu o singură etapă care rulează ca root, include dependențe de dezvoltare și folosește o etichetă de imagine de bază nefixată. Fiecare dintre acestea reprezintă o problemă de securitate sau eficiență.
Un prompt mai bun:
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
Construcții cu mai multe etape
Un fișier Dockerfile cu o singură etapă copiază totul în imaginea finală, inclusiv uneltele de build, dependențele de dezvoltare, fișierele de test și hărțile sursă. Această abordare poate umfla dimensiunea imaginii și crește suprafața de atac. Construcțiile multi-etapă separă mediul de build de mediul de runtime. Doar artefactele necesare pentru a rula aplicația sunt copiate în imaginea finală.
# 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"]
Folosirea lui Copilot ca evaluator de securitate
După ce generezi un Dockerfile, roagă-l pe Copilot să-l revizuiască:
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 semnalează numerele specifice de linie și explică fiecare problemă. Acest prompt de recenzie funcționează pe orice fișier Dockerfile, nu doar pe cele generate cu Copilot.
Generarea manifestelor Kubernetes cu GitHub Copilot
Ce să incluzi într-un prompt Kubernetes
Manifestele Kubernetes interacționează cu resurse specifice clusterului: controlere de intrare, clase de stocare, spații de nume și sisteme de identitate. Un prompt bun Kubernetes specifică:
- Tipurile de resurse necesare (Deployment, Service, Ingress, ConfigMap și așa mai departe)
- Portul și protocolul aplicației
- Cereri de resurse și limite
- Puncte finale ale sondei de sănătate
- Variabile de mediu și sursa lor (ConfigMap, Secret sau valoare directă)
- Spațiu nume
- Numele clasei de acces, dacă este cazul.
Generarea unui stack complet de implementare
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.
Înțelegerea sondelor de sănătate
Kubernetes folosește două tipuri de sonde pentru a gestiona ciclul de viață al containerelor.
Sonda Liveness răspunde la întrebarea: este acest recipient viu? Dacă sonda de vitalitate eșuează în mod repetat, Kubernetes oprește containerul și pornește unul nou. Folosește-l pentru a detecta când aplicația a intrat într-o stare de nerecuperat, cum ar fi un blocaj sau o buclă de blocare.
Sonda de pregătire răspunde la întrebarea: este acest container pregătit să primească trafic? Dacă sonda de pregătire eșuează, Kubernetes elimină podul din lista de endpoint-uri de serviciu. Traficul se oprește până când sonda își revine. Folosește-l pentru a semnala când aplicația s-a terminat de pornit sau este temporar suprasolicitată.
Pentru a adăuga o sondă de pornire:
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.
Consolidarea cu contexte de securitate
În mod implicit, containerele Kubernetes rulează cu mai multe privilegii decât este necesar. A securityContext la nivel de capsulă și container restricționează ceea ce poate face containerul.
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.
După ce Copilot generează manifestul actualizat, roagă-l să explice fiecare setare:
Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.
Acest tipar funcționează bine pentru învățarea în echipă. Folosește Copilot pentru a genera, apoi folosește Copilot pentru a explica.
Modele specifice AKS
AKS introduce concepte specifice Azure pe care manifestele Kubernetes standard nu le abordează. Copilot cunoaște bine aceste tipare.
Identitatea volumului de lucru:
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 volumul persistent al discului:
Add a PersistentVolumeClaim for 10Gi using the managed-csi storage class
(Azure Disk). Mount it at /data in the container with ReadWriteOnce access mode.
Buget pentru perturbarea podurilor:
Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).
Revizuirea manifestelor existente
Lipește orice manifest Kubernetes în Copilot Chat și cere o recenzie:
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.
Acest prompt de revizuire este util pentru echipele care au acumulat manifeste de-a lungul timpului și doresc să le aducă la standardele actuale fără a audita manual fiecare fișier.
Schelă pentru diagrame de cârmă
Pentru ambalarea aplicațiilor reutilizabile, Copilot poate schela structurile hărților Helm. Folosește un prompt care specifică numele graficului, resursele de inclus, valorile de parametrizat și orice cerințe specifice AKS, cum ar fi clasa de intrare sau identitatea încărcăturii de lucru. Copilot generează fișierele Chart.yaml, values.yaml și șabloanele în structura de director așteptată. Revizuiește cu atenție datele generate values.yaml pentru a te asigura că implicitele sensibile nu sunt supuse controlului surselor.