โครงสร้างพื้นฐานคอนเทนเนอร์ด้วย GitHub Copilot
Tip
ดูแท็บ ข้อความและรูปภาพ สําหรับรายละเอียดเพิ่มเติม!
การบรรจุคอนเทนเนอร์ไม่ได้เป็นปัญหาแยกต่างหากจากโครงสร้างพื้นฐานอีกต่อไป เมื่อแอปพลิเคชันของคุณทํางานบน Kubernetes Dockerfile, รายการ Kubernetes และโครงสร้างพื้นฐาน Azure พื้นฐานทั้งหมดจะเป็นส่วนหนึ่งของทรัพย์สิน IaC เดียวกัน พวกเขาใช้ตัวควบคุมเวอร์ชันเดียวกัน ไปป์ไลน์ CI/CD เดียวกัน และกระบวนการตรวจสอบเดียวกัน
GitHub Copilot เหมาะอย่างยิ่งสําหรับโครงสร้างพื้นฐานคอนเทนเนอร์ เนื่องจากไวยากรณ์ Dockerfile และ Kubernetes YAML มีโครงสร้างสูงและมีรูปแบบมากมาย ลักษณะเหล่านี้เป็นคุณสมบัติเดียวกับที่ทําให้การสร้าง Bicep มีประสิทธิภาพ รูปแบบคอนเทนเนอร์ส่วนใหญ่ปรากฏบ่อยในโครงการโอเพ่นซอร์ส ทําให้ Copilot ครอบคลุมแนวทางปฏิบัติที่ดีที่สุดอย่างชัดเจน
การสร้าง Dockerfiles ด้วย GitHub Copilot
กายวิภาคของพรอมต์ Dockerfile ที่ดี
พรอมต์ Dockerfile ที่มีประสิทธิภาพจะระบุประเภทแอปพลิเคชัน อิมเมจพื้นฐาน ข้อกําหนดรันไทม์ และข้อกําหนดด้านความปลอดภัย การขาดส่วนประกอบคอนเทนเนอร์หลักเหล่านี้จะทําให้ Copilots มีค่าเริ่มต้นเป็นรูปแบบที่เรียบง่ายกว่าแต่มีความปลอดภัยน้อยกว่า
ข้อความแจ้งที่น้อยที่สุดแต่มีปัญหา:
Create a Dockerfile for a Node.js app.
Copilot อาจสร้างไฟล์ Dockerfile ขั้นตอนเดียวที่ทํางานเป็นรูท รวมถึงการพึ่งพานักพัฒนา และใช้แท็กอิมเมจพื้นฐานที่ไม่ได้ตรึงไว้ สิ่งเหล่านี้เป็นข้อกังวลด้านความปลอดภัยหรือประสิทธิภาพ
ข้อความแจ้งที่ดีกว่า:
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
บิลด์หลายขั้นตอน
Dockerfile ขั้นตอนเดียวจะคัดลอกทุกอย่างลงในภาพสุดท้าย รวมถึงเครื่องมือสร้าง การพึ่งพานักพัฒนา ไฟล์ทดสอบ และแผนที่ต้นทาง วิธีนี้อาจขยายขนาดภาพและเพิ่มพื้นผิวการโจมตี การสร้างแบบหลายขั้นตอนจะแยกสภาพแวดล้อมการสร้างออกจากสภาพแวดล้อมรันไทม์ เฉพาะสิ่งประดิษฐ์ที่จําเป็นในการเรียกใช้แอปพลิเคชันเท่านั้นที่จะถูกคัดลอกไปยังภาพสุดท้าย
# 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"]
การใช้ Copilot เป็นผู้ตรวจสอบความปลอดภัย
หลังจากสร้าง Dockerfile แล้ว ขอให้ Copilot ตรวจสอบ:
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 ตั้งค่าสถานะหมายเลขบรรทัดเฉพาะและอธิบายข้อกังวลแต่ละข้อ พรอมต์การตรวจสอบนี้ใช้ได้กับ Dockerfile ใดๆ ไม่ใช่แค่ไฟล์ที่สร้างขึ้นด้วย Copilot เท่านั้น
การสร้างรายการ Kubernetes ด้วย GitHub Copilot
สิ่งที่ต้องรวมไว้ในพรอมต์ Kubernetes
รายการ Kubernetes โต้ตอบกับทรัพยากรเฉพาะคลัสเตอร์: ตัวควบคุมขาเข้า คลาสที่เก็บข้อมูล เนมสเปซ และระบบข้อมูลประจําตัว พรอมต์ Kubernetes ที่ดีจะระบุ:
- ประเภททรัพยากรที่จําเป็น (การปรับใช้, บริการ, ขาเข้า, ConfigMap และอื่นๆ)
- พอร์ตและโปรโตคอลของแอปพลิเคชัน
- คําขอทรัพยากรและขีดจํากัด
- อุปกรณ์ปลายทางโพรบสุขภาพ
- ตัวแปรสภาพแวดล้อมและแหล่งที่มา (ConfigMap, Secret หรือค่าโดยตรง)
- Namespace
- ชื่อคลาสขาเข้า (หากมี)
การสร้างสแต็กการปรับใช้เต็มรูปแบบ
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.
ทําความเข้าใจเกี่ยวกับโพรบสุขภาพ
Kubernetes ใช้โพรบสองประเภทเพื่อจัดการวงจรชีวิตของคอนเทนเนอร์
โพรบความมีชีวิต ตอบคําถาม: ภาชนะนี้มีชีวิตอยู่หรือไม่? หากโพรบความมีชีวิตล้มเหลวซ้ําๆ Kubernetes จะฆ่าคอนเทนเนอร์และเริ่มคอนเทนเนอร์ใหม่ ใช้เพื่อตรวจจับเมื่อแอปพลิเคชันเข้าสู่สถานะที่ไม่สามารถกู้คืนได้ เช่น การชะงักงันหรือลูปการขัดข้อง
โพรบความพร้อม ตอบคําถาม: ตู้คอนเทนเนอร์นี้พร้อมที่จะรับการจราจรหรือไม่? หากโพรบความพร้อมล้มเหลว Kubernetes จะลบพ็อดออกจากรายการปลายทางบริการ การจราจรหยุดไหลไปจนกว่าโพรบจะฟื้นตัว ใช้เพื่อส่งสัญญาณเมื่อแอปพลิเคชันเริ่มต้นเสร็จหรือโอเวอร์โหลดชั่วคราว
เมื่อต้องการเพิ่มโพรบเริ่มต้น:
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.
เสริมความแข็งแกร่งด้วยบริบทความปลอดภัย
ตามค่าเริ่มต้น คอนเทนเนอร์ Kubernetes จะทํางานด้วยสิทธิ์มากกว่าที่จําเป็น A securityContext ที่ระดับพ็อดและคอนเทนเนอร์จะจํากัดสิ่งที่คอนเทนเนอร์สามารถทําได้
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.
หลังจากที่ Copilot สร้างรายการที่อัปเดตแล้ว ให้ขอให้อธิบายการตั้งค่าแต่ละรายการ:
Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.
รูปแบบนี้ใช้ได้ดีกับการเรียนรู้เป็นทีม ใช้ Copilot เพื่อสร้าง จากนั้นใช้ Copilot เพื่ออธิบาย
รูปแบบเฉพาะของ AKS
AKS แนะนําแนวคิดเฉพาะ Azure ที่รายการ Kubernetes มาตรฐานไม่ได้กล่าวถึง Copilot รู้จักรูปแบบเหล่านี้เป็นอย่างดี
ข้อมูลประจําตัวของปริมาณงาน:
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 ดิสก์ปริมาณถาวร:
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:
Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).
การตรวจสอบรายการที่มีอยู่
วางรายการ Kubernetes ลงใน Copilot Chat และขอรับการตรวจสอบ:
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.
ข้อความแจ้งการตรวจสอบนี้มีประโยชน์สําหรับทีมที่สะสมรายการเมื่อเวลาผ่านไป และต้องการทําให้รายการเหล่านั้นเป็นไปตามมาตรฐานปัจจุบันโดยไม่ต้องตรวจสอบแต่ละไฟล์ด้วยตนเอง
นั่งร้านแผนภูมิหางเสือ
สําหรับบรรจุภัณฑ์ที่นํากลับมาใช้ใหม่ได้ Copilot สามารถนั่งร้านโครงสร้างแผนภูมิ Helm ได้ ใช้พร้อมท์ที่ระบุชื่อแผนภูมิ ทรัพยากรที่จะรวม ค่าที่จะกําหนดพารามิเตอร์ และข้อกําหนดเฉพาะของ AKS เช่น คลาสขาเข้าหรือข้อมูลประจําตัวของปริมาณงาน Copilot สร้างไฟล์ Chart.yaml, values.yaml และเทมเพลตในโครงสร้างไดเรกทอรีที่คาดไว้ ตรวจสอบที่สร้างขึ้น values.yaml อย่างรอบคอบเพื่อให้แน่ใจว่าค่าเริ่มต้นที่ละเอียดอ่อนไม่ได้ผูกมัดกับการควบคุมแหล่งที่มา