Infrastruktura kontenerów z GitHub Copilot

Konteneryzacja nie jest już osobną kwestią od infrastruktury. Gdy aplikacja działa na platformie Kubernetes, plik Dockerfile, manifesty platformy Kubernetes i podstawowa infrastruktura Azure są częścią tej samej infrastruktury IaC. Korzystają z tego samego systemu kontroli wersji, tego samego potoku CI/CD i tego samego procesu recenzji.

GitHub Copilot dobrze nadaje się do infrastruktury kontenerów, ponieważ składnia pliku Dockerfile i kod YAML platformy Kubernetes są wysoce ustrukturyzowane i bogate w wzorce. Te cechy to te same właściwości, które sprawiają, że generowanie w języku Bicep jest skuteczne. Większość wzorców konteneryzacji często pojawia się w projektach open source, co daje Copilotowi szeroką znajomość najlepszych praktyk.

Generowanie plików Dockerfile za pomocą GitHub Copilot

Anatomia dobrego monitu Dockerfile

Skuteczny monit dockerfile określa typ aplikacji, obraz podstawowy, wymagania środowiska uruchomieniowego i wymagania dotyczące zabezpieczeń. Brak dowolnego z tych podstawowych składników kontenera, prowadzi Copilots domyślnie do prostszych, ale mniej bezpiecznych wzorców.

Minimalny, ale problematyczny monit:

Create a Dockerfile for a Node.js app.

Copilot może utworzyć jednoetapowy plik Dockerfile, który jest uruchamiany jako katalog główny, zawiera zależności deweloperskie i używa odpiętego tagu obrazu podstawowego. Każdy z nich jest problemem bezpieczeństwa lub wydajności.

Lepszy monit:

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

Kompilacje wieloetapowe

Jednoetapowy plik Dockerfile kopiuje wszystko do końcowego obrazu, w tym narzędzia kompilacji, zależności deweloperskie, pliki testowe i mapy źródłowe. Takie podejście potencjalnie zwiększa rozmiar obrazu i zwiększa powierzchnię ataku. Kompilacje wieloetapowe oddzielają środowisko kompilacji od środowiska uruchomieniowego. Tylko artefakty potrzebne do uruchomienia aplikacji są kopiowane do obrazu końcowego.

# 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"]

Używanie Copilot jako recenzenta zabezpieczeń

Po wygenerowaniu pliku Dockerfile poproś Copilot o przejrzenie go:

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 oznacza konkretne numery wierszy i wyjaśnia każdy problem. Ten monit do recenzji działa z dowolnym plikiem Dockerfile, nie tylko z plikami wygenerowanymi przez Copilot.

Generowanie manifestów platformy Kubernetes przy użyciu platformy GitHub Copilot

Co powinien zawierać prompt Kubernetes

Manifesty Kubernetes współpracują z zasobami specyficznymi dla klastra: kontrolerami Ingress, klasami pamięci masowej, przestrzeniami nazw i systemami tożsamości. Dobre polecenie Kubernetes określa:

• Wymagane typy zasobów (Deployment, Service, Ingress, ConfigMap i tak dalej)
• Port i protokół aplikacji
• Żądania zasobów i limity
• Punkty końcowe sondy diagnostycznej
• Zmienne środowiskowe i ich źródło (ConfigMap, Secret lub direct value)
• Namespace
• Nazwa klasy Ingress, jeśli dotyczy

Tworzenie pełnego stosu wdrożeniowego

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.

Informacje o sondach kondycji

Platforma Kubernetes używa dwóch typów sond do zarządzania cyklem życia kontenera.

Sonda liveness odpowiada na pytanie: czy ten kontener żyje? Jeśli sonda liveness wielokrotnie kończy się niepowodzeniem, platforma Kubernetes zabija kontener i uruchamia nowy. Służy do wykrywania, kiedy aplikacja wprowadziła nieodwracalny stan, taki jak zakleszczenie lub pętla awarii.

Sonda gotowości odpowiada na pytanie: czy ten kontener jest gotowy do odbierania ruchu? Jeśli sonda gotowości zakończy się niepowodzeniem, platforma Kubernetes usunie zasobnik z listy punktów końcowych usługi. Ruch przestaje być kierowany do niego, dopóki sonda nie odzyska sprawności. Użyj go, aby zasygnalizować, kiedy aplikacja zakończyła uruchamianie lub jest tymczasowo przeciążona.

Aby dodać sondę startową:

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.

Wzmacnianie zabezpieczeń przy użyciu kontekstów zabezpieczeń

Domyślnie kontenery Kubernetes działają z większymi uprawnieniami niż jest to konieczne. securityContext na poziomie poda i kontenera ogranicza to, co kontener może robić.

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.

Po wygenerowaniu zaktualizowanego manifestu poproś Copilota, aby wyjaśnił każde ustawienie:

Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.

Ten wzorzec dobrze sprawdza się w przypadku uczenia zespołowego. Użyj Copilota do wygenerowania, a następnie użyj Copilota, aby to wyjaśnić.

Wzorce specyficzne dla usługi AKS

Usługa AKS wprowadza pojęcia specyficzne dla Azure, których standardowe manifesty platformy Kubernetes nie dotyczą. Copilot dobrze zna te wzorce.

Tożsamość obciążenia:

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 Dysk trwały wolumin:

Add a PersistentVolumeClaim for 10Gi using the managed-csi storage class
(Azure Disk). Mount it at /data in the container with ReadWriteOnce access mode.

Budżet na zakłócenia zasobnika:

Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).

Przeglądanie istniejących manifestów

Wklej dowolny manifest platformy Kubernetes do Copilot Chat i poproś o przegląd:

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.

Ten monit do przeglądu jest przydatny dla zespołów, które nagromadziły manifesty z biegiem czasu i chcą dostosować je do obecnych standardów bez ręcznego audytowania każdego pliku.

Tworzenie szkieletu wykresu programu Helm

Do tworzenia pakietów aplikacji wielokrotnego użytku Copilot może generować szkielety struktur chartów Helm. Użyj monitu, który określa nazwę wykresu, zasoby do uwzględnienia, wartości do sparametryzowania i wszelkie wymagania specyficzne dla usługi AKS, takie jak klasa ruchu przychodzącego lub tożsamość obciążenia. Copilot generuje Chart.yaml, values.yaml i pliki szablonów w katalogach o oczekiwanej strukturze. Dokładnie sprawdź wygenerowane values.yaml, aby upewnić się, że poufne wartości domyślne nie są commitowane do systemu kontroli wersji.