Ingeniería de solicitudes para infraestructura como código
Tip
Consulte la pestaña Texto e imágenes para obtener más detalles.
GitHub Copilot solo es tan útil como las instrucciones que le des. En el caso de las tareas de infraestructura, un mensaje impreciso genera una plantilla genérica que puede no coincidir con las convenciones de nomenclatura, los estándares de seguridad o los patrones arquitectónicos. Una solicitud bien elaborada genera un resultado que está prácticamente listo para producción.
Esto no es una diferencia menor. Un mensaje como create a Bicep template for a Virtual Network podría generar un ejemplo mínimo sin subredes, sin etiquetas y una región codificada. Un mensaje como el que escriba hacia el final de esta unidad puede producir una Red Virtual de subred múltiple, completamente parametrizada, etiquetada, con asociaciones de NSG y configuraciones de diagnóstico. Correctamente estructurado y listo para ser validado.
Aprender a escribir buenos prompts es una habilidad adquirible. En esta unidad se tratan las técnicas que de manera consistente producen mejores resultados de infraestructura a partir de GitHub Copilot.
Anatomía de una solicitud de IaC eficaz
Cada solicitud de infraestructura segura contiene una combinación de cuatro elementos:
Context
El contexto te dice a Copilot qué tipo de trabajo estás haciendo y qué restricciones se aplican. Sin contexto, Copilot realiza suposiciones. Es posible que esas suposiciones no coincidan con su entorno.
Solicitud no tan buena: "Crear una cuenta de almacenamiento con Bicep".
Optimized prompt: "Crear una definición de recurso Bicep para una cuenta de almacenamiento de Azure. Se ejecuta en un entorno de producción en la región de Australia Oriental. La cuenta debe usar Standard_LRS y requerir acceso de solo HTTPS".
El contexto incluye el entorno de destino (dev/staging/production), la región, la herramienta o el idioma, las restricciones existentes (convenciones de nomenclatura, directivas de etiquetado) y los estándares que desee seguir.
Requirements
Los requisitos son las funcionalidades, propiedades o comportamientos específicos que debe tener el recurso. Ser explícito acerca de los requisitos impide que Copilot omita las cosas que no se pueden deducir.
Por ejemplo:
The storage account must: have soft delete enabled for blobs (7 days), use a private endpoint, disable public blob access, and be tagged with Environment, Owner, and CostCenter.
Enumera los requisitos como puntos de viñeta o elementos numerados cuando hay varios. Copilot controla bien las listas estructuradas y es menos probable que omita los elementos.
Formato de salida
Indique Copilot qué tipo de salida espera. Para IaC, normalmente significa especificar el idioma o la herramienta, tanto si desea un archivo completo como simplemente un fragmento de código, y cómo se deben controlar los parámetros.
Por ejemplo:
Output a complete Bicep file with parameters at the top, a resource block in the middle, and outputs at the bottom. Use decorators to add descriptions to all parameters.
Si no especifica un formato, Copilot elige uno. Puede elegir valores codificados en línea cuando desea parámetros o un fragmento de código cuando se desea un archivo completo.
Restricciones
Las restricciones indican a Copilot qué debe evitar. Fácil de pasar por alto, pero importante, especialmente para la seguridad o el cumplimiento.
Por ejemplo:
Do not use any deprecated API versions. Do not expose any management ports (22, 3389) in NSG rules. Do not hardcode any subscription IDs or tenant IDs.
Solicitud sin muestras
La solicitud sin ejemplos significa que describe lo que desea sin proporcionar ejemplos. Es el enfoque más común y funciona bien para los patrones de infraestructura estándar, basado en los datos con los que Copilot ha sido entrenado.
Por ejemplo:
Generate a Bicep template for an Azure Key Vault with the following requirements:
- SKU: Standard
- Soft delete enabled with a 90-day retention period
- Purge protection enabled
- RBAC authorization model (not access policies)
- Public network access disabled
- A private endpoint connected to a subnet parameter
- Tags: Environment, Owner, CostCenter (all as parameters)
Use descriptive parameter names and add @description() decorators to each.
El enfoque zero-shot funciona mejor cuando el tipo de recurso es común y sus requisitos son específicos. Si está trabajando con un tipo de recurso menos común o si necesita una estructura determinada, considere la posibilidad de proporcionar un ejemplo.
Solicitud con pocas muestras
La solicitud con pocas muestras significa que proporciona uno o varios ejemplos en las solicitudes para que Copilot comprenda el patrón o estilo deseado. Resulta útil cuando tiene un código base existente con convenciones que Copilot no sabría de lo contrario.
Un ejemplo de solicitud con pocas muestras podría tener este aspecto:
Here is an example of how we define storage accounts in our Bicep codebase:
[paste your existing storage account resource block]
Using the same naming convention, parameter style, and tag structure, generate
a similar resource block for an Azure Service Bus namespace with these requirements:
- Standard SKU
- Geo-redundant disaster recovery enabled
- Minimum TLS 1.2
- Same tagging pattern as the example
Al mostrar Copilot el patrón existente, obtendrá la salida que se combina con el código base en lugar de la salida que sigue al estilo predeterminado de Copilot. Reduciendo significativamente el tiempo de limpieza al integrar código generado con plantillas existentes.
Indicación basada en roles
La solicitud basada en roles le pide a Copilot que adopte una perspectiva específica antes de generar el resultado. Es eficaz para las revisiones de seguridad y las instrucciones arquitectónicas.
Un ejemplo en el contexto de seguridad podría tener este aspecto:
You are a senior Azure security engineer reviewing Bicep templates for enterprise
production deployments. Review the following template and identify:
- Any security misconfigurations or missing security controls
- Resources that expose public endpoints unnecessarily
- Missing diagnostic settings or logging configuration
- RBAC assignments that are too broad
- Any deprecated API versions
For each issue found, explain the risk and provide the corrected Bicep snippet.
Las solicitudes basadas en roles hacen que los resultados de Copilot pasen de ser "aquí tienes un código que funciona" a "aquí tienes un código que funciona, es seguro y sigue el principio del privilegio mínimo". La diferencia de calidad es notable.
Refinamiento iterativo
La manera más eficaz de trabajar con GitHub Copilot en Infraestructura como Código no es escribir una solicitud perfecta. Se trata de empezar con un enfoque amplio y ir concretando poco a poco.
Un proceso de creación de ejemplo recorrería en bucle las siguientes fases:
Paso 1: Empezar con el recurso principal
Generate a Bicep template for a hub-spoke VNet topology with one hub and one spoke.
Revise el resultado. ¿La estructura básica es correcta? ¿Son sensibles los espacios de direcciones?
Paso 2: Agregar requisitos de seguridad
Add an NSG to the application subnet in the spoke that blocks all inbound
internet traffic except HTTPS (port 443). Add a deny-all rule at the end.
Paso 3: Agregar observabilidad
Add diagnostic settings to the NSG that send flow logs to a Log Analytics
workspace. Add the Log Analytics workspace as a new parameter.
Paso 4: Agregar parametrización
Replace all hardcoded values (address spaces, location, resource names)
with parameters. Add @description() and @allowed() decorators where appropriate.
Paso 5: Agregar etiquetas
Add tag parameters for Environment, Owner, and CostCenter. Apply tags to
every resource in the template using a tags object parameter.
Este enfoque de cinco pasos genera de forma coherente una salida mejor que una sola solicitud compleja porque cada paso se basa en la salida validada de la anterior. Revise y acepte cada incremento antes de agregar la siguiente capa de requisitos.
Errores comunes en las solicitudes
Ser demasiado impreciso
Problem: usando un prompt como Create a Bicep template for my infrastructure
Resultado: Una plantilla mínima con valores adivinados, tipos de recursos incorrectos y ninguna configuración de seguridad.
Corrección: Sea específico sobre qué recursos necesita, qué SKU, qué regiones y qué requisitos de seguridad se aplican.
Olvidar las restricciones de seguridad
Problema: Generar una plantilla de máquina virtual sin especificar que los puertos de administración no deben estar abiertos
Resultado: Un NSG que permite SSH entrante y RDP desde la Internet. Que es una configuración incorrecta de seguridad crítica
Corrección: Expresar explícitamente los requisitos de seguridad como parte de cada solicitud de infraestructura. No dé por sentado que Copilot está configurado de forma predeterminada en modo seguro
No especificar preferencias de versión de API
Problem: usando un prompt como Use the latest API version
Result: Sin MCP, Copilot puede seguir usando versiones de sus datos de entrenamiento, que podrían estar obsoletas.
Fix: Habilite el servidor MCP de Bicep o indique explícitamente la versión de la API si se conoce. Como mínimo, pida a Copilot marcar si no está seguro de la versión de la API.
Pedir demasiado en un mensaje
Problema: una sugerencia de 20 líneas que pide una zona de aterrizaje completa de Azure con redes, identidad, gobernanza y supervisión. Todo a la vez.
Resultado: Una plantilla extensa con muchos huecos, referencias entre recursos que faltan y propiedades que Copilot ha adivinado.
Corrección: Usa refinamiento iterativo. Compile la plantilla en capas y valide cada capa antes de agregar la siguiente.
No proporcionar contexto para los códigos base existentes
Problema: Preguntar a Copilot add a subnet to the Virtual Network sin compartir la definición existente del recurso Red Virtual.
Resultado: Nuevo recurso de subred que puede entrar en conflicto con la estructura o nomenclatura de la definición existente.
Corrección: Pegue siempre el código existente pertinente en el cuadro de entrada al extender o modificar las plantillas existentes.
Patrones de solicitudes para infraestructura
Los patrones siguientes se aplican directamente a las tareas de este módulo.
Patrón de generación
Use al empezar desde cero:
Generate a [tool: Bicep/CLI/YAML] [resource type] with the following requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]
Parameterize: [list of values to parameterize]
Tag every resource with: [tag names]
Do not: [constraints]
Patrón de extensión
Use al agregar a una plantilla existente:
Given this existing [tool] [resource definition]:
[paste existing code]
Add the following:
- [addition 1]
- [addition 2]
Maintain the existing naming convention and parameter style.
Patrón de revisión
Use al auditar una plantilla existente:
Review this [tool] template for:
- Security misconfigurations
- Missing required properties
- Deprecated API versions
- Resources exposed to the public internet unnecessarily
- Missing tags or diagnostic settings
For each issue, explain the problem and provide the corrected snippet.
[paste template]
Patrón de traducción
Use al convertir entre herramientas:
Translate this [source tool] [script/template/pipeline] to [target tool].
Preserve:
- The same variable/parameter names where possible
- Error handling logic
- The same resource naming and tagging
Do not add features that are not in the original.
[paste source code]
Patrón de explicación
Use cuando necesite comprender la infraestructura existente:
Explain what this [tool] template deploys in plain language.
Describe each resource, its purpose, and how the resources relate to each other.
Identify any security controls that are configured.
Highlight anything that looks unusual or that might cause problems in production.
[paste template]
Mentalidad de revisión
GitHub Copilot es un colaborador, no una autoridad. Todas las salidas que genera deben revisarse antes de usarlas. Especialmente para la infraestructura, donde una configuración incorrecta puede exponer sistemas a Internet, bloquearle los recursos o incurrir en costos inesperados.
Las preguntas que se deben formular al revisar la salida de la infraestructura de Copilot:
- ¿La versión de la API está actualizada? Compruebe la documentación de Azure o use Bicep MCP.
- ¿Están presentes todas las propiedades necesarias? Ejecute
az bicep buildpara detectar los campos obligatorios que faltan. - ¿Son adecuados los valores predeterminados de seguridad? Compruebe el acceso a la red pública, la exposición del puerto de administración y la configuración de cifrado.
- ¿Se hace referencia correctamente a los recursos? Asegúrese de que los nombres simbólicos, no los identificadores codificados de forma codificada, se usan para las referencias de recursos.
- ¿Es idempotente? ¿La ejecución de esta plantilla crea dos veces conflictos o duplicados?
Tratar la salida de Copilot como primer borrador, no una respuesta final, es la mentalidad que genera los mejores resultados.
Conclusiones clave
- Los avisos de IaC efectivos incluyen contexto, requisitos, formato de salida y restricciones.
- La solicitud sin muestras funciona para los tipos de recursos comunes; la solicitud con pocas muestras funciona mejor cuando tiene patrones de código existentes para que coincidan.
- Las solicitudes basadas en roles ("Eres un ingeniero de seguridad sénior de Azure...") mejoran la calidad de la orientación arquitectónica y de las revisiones.
- El perfeccionamiento iterativo, mediante la compilación por capas, ofrece mejores resultados que una sola indicación extensa.
- Revise siempre la salida de Copilot antes de usarla: compruebe las versiones de API, las propiedades necesarias, la configuración de seguridad y las referencias de recursos.