Infraestrutura de contêiner com GitHub Copilot
Dica
Consulte a guia Texto e imagens para obter mais detalhes!
A contêinerização não é mais uma preocupação separada da infraestrutura. Quando sua aplicação é executada no Kubernetes, o Dockerfile, os manifestos do Kubernetes e a infraestrutura subjacente do Azure fazem parte do mesmo ambiente de IaC. Eles compartilham o mesmo controle de versão, o mesmo pipeline de CI/CD e o mesmo processo de revisão.
GitHub Copilot é adequado para a infraestrutura de contêiner porque a sintaxe do Dockerfile e o YAML do Kubernetes são altamente estruturados e ricos em padrões. Essas características são as mesmas qualidades que tornam o treino de bíceps eficaz. A maioria dos padrões de contêinerização aparece com frequência em projetos de software livre, proporcionando aos Copilot forte cobertura das práticas recomendadas.
Gerando Dockerfiles com GitHub Copilot
A anatomia de um bom prompt do Dockerfile
Um prompt do Dockerfile eficaz especifica o tipo de aplicativo, a imagem base, os requisitos de runtime e os requisitos de segurança. A ausência de qualquer um desses componentes principais do contêiner faz com que os Copilots recorram a padrões mais simples, porém menos seguros.
Um prompt mínimo, mas problemático:
Create a Dockerfile for a Node.js app.
O Copilot pode gerar um Dockerfile de etapa única que é executado como root, inclui dependências de desenvolvimento e utiliza uma tag de imagem base não fixada. Cada uma delas é uma preocupação de segurança ou eficiência.
Um prompt melhor:
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
Builds de vários estágios
Um Dockerfile de etapa única copia tudo para a imagem final, incluindo ferramentas de compilação, dependências de desenvolvimento, arquivos de teste e mapas de código-fonte. Essa abordagem potencialmente infla o tamanho da imagem e aumenta a superfície de ataque. Compilações em vários estágios separam o ambiente de compilação do ambiente de execução. Somente os artefatos necessários para executar o aplicativo são copiados para a imagem 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"]
Usando Copilot como revisor de segurança
Depois de gerar um Dockerfile, peça a Copilot para revisá-lo:
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 sinaliza números de linha específicos e explica cada preocupação. Este prompt de revisão funciona em qualquer Dockerfile, não apenas nos gerados com Copilot.
Gerando manifestos do Kubernetes com GitHub Copilot
O que incluir em um prompt do Kubernetes
Os manifestos do Kubernetes interagem com recursos específicos do cluster: controladores de entrada, classes de armazenamento, namespaces e sistemas de identidade. Um bom prompt do Kubernetes especifica:
- Os tipos de recursos necessários (Deployment, Service, Ingress, ConfigMap, entre outros)
- A porta e o protocolo do aplicativo
- Solicitações e limites de recursos
- Pontos de extremidade de investigação de integridade
- Variáveis de ambiente e sua origem (ConfigMap, Secret ou direct value)
- Namespace
- O nome da classe de entrada, se aplicável
Gerando uma pilha de implantação completa
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.
Entendendo as investigações de integridade
O Kubernetes usa dois tipos de sondas para gerenciar o ciclo de vida dos contêineres.
A investigação de atividade responde à pergunta: este contêiner está ativo? Se a sonda de liveness falhar repetidamente, o Kubernetes encerra o contêiner e inicia um novo. Use-o para detectar quando o aplicativo inseriu um estado irrecuperável, como um deadlock ou um loop de falha.
Sonda de prontidão responde à pergunta: este contêiner está pronto para receber tráfego? Se a sonda de prontidão falhar, o Kubernetes remove o pod da lista de endpoints do Service. O tráfego deixa de fluir para ela até que a sonda volte a funcionar. Use-o para sinalizar quando o aplicativo terminou a inicialização ou está temporariamente sobrecarregado.
Para adicionar uma sonda de inicialização:
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.
Fortalecimento com contextos de segurança
Por padrão, os contêineres do Kubernetes são executados com mais privilégios do que o necessário. Um securityContext nos níveis de pod e de contêiner restringe o que o contêiner pode fazer.
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.
Depois que Copilot gerar o manifesto atualizado, peça que ele explique cada configuração:
Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.
Esse padrão funciona bem para o aprendizado em equipe. Use Copilot para gerar e use Copilot para explicar.
Padrões específicos do AKS
O AKS apresenta conceitos específicos Azure que os manifestos padrão do Kubernetes não abordam. Copilot conhece bem esses padrões.
Identidade da carga de trabalho:
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.
Volume persistente de disco do 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.
Orçamento para a interrupção do serviço de pods:
Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).
Revisão de manifestos existentes
Cole qualquer manifesto do Kubernetes em Copilot Chat e solicite uma revisão:
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.
Esse prompt de revisão é útil para equipes que acumularam manifestos ao longo do tempo e desejam trazê-los para os padrões atuais sem auditar manualmente cada arquivo.
Estrutura do gráfico Helm
Para o empacotamento de aplicativos reutilizáveis, o Copilot pode gerar estruturas de gráficos Helm. Use um prompt que especifica o nome do gráfico, os recursos a serem incluídos, os valores a serem parametrizados e quaisquer requisitos específicos do AKS, como a classe de entrada ou a identidade da carga de trabalho. Copilot gera os arquivos Chart.yaml, values.yaml e modelo na estrutura de diretório esperada. Analise cuidadosamente values.yaml arquivo gerado para garantir que os dados confidenciais não sejam enviados para o controle de versão.