Introducción

Completado

La infraestructura como código (IaC) es la práctica de definir y gestionar recursos en la nube mediante archivos de configuración legibles por máquina, en lugar de hacer selecciones manuales en el portal o utilizar scripts no planificados. En lugar de iniciar sesión en el portal de Azure para crear una red virtual, escriba un archivo que describa la red. A continuación, una herramienta lee ese archivo y crea el recurso automáticamente.

Este enfoque aporta un cambio fundamental en la forma en que se administra la infraestructura. Los cambios se realizan en el control de versiones, las implementaciones se pueden repetir y los entornos se pueden volver a crear desde cero en cualquier momento. Si algo se rompe, puedes revertir a un estado anterior. Si necesita un entorno de ensayo que refleje la producción, aplique los mismos archivos con parámetros diferentes.

IaC también incluye la infraestructura en la misma materia de ingeniería que el código de aplicación. Los mismos flujos de trabajo de solicitud de incorporación de cambios, revisiones de código y prácticas de prueba automatizadas que se aplican a la aplicación ahora se pueden aplicar a los sistemas en los que se ejecuta la aplicación.

Sin asistencia de IA, el ciclo de creación de infraestructura como código (IaC) tiene este aspecto:

1. Escribir plantilla
2. Consulta la documentación
3. Corrección de la sintaxis
4. Validar localmente
5. Ejecución hipotética
6. Implementación en entorno de ensayo
7. Revisión de los cambios
8. Implementación en producción

Y repita lo mismo para cada implementación, ya sea nueva o actualizada.

Objetivos de aprendizaje

Al final de este módulo, usted podrá:

• Explicar qué infraestructura como código es y por qué es importante en las operaciones modernas en la nube
• Describir la diferencia entre los enfoques declarativos e imperativos de IaC
• Identificar el flujo de trabajo de creación tradicional de IaC y sus puntos de fricción
• Explicar cómo GitHub Copilot cambia el bucle interno de IaC
• Describir las funcionalidades de GitHub Copilot más relevantes para el trabajo de infraestructura

Desafíos de Infraestructura como Código

Cada paso tiene fricción. Escribir una plantilla de Bicep desde cero requiere conocimientos sobre tipos de recursos, versiones de API, propiedades necesarias y convenciones de nomenclatura específicas de Azure. Buscar la versión de API correcta para Microsoft.Network/virtualNetworks significa navegar por la documentación o copiar desde proyectos anteriores. Los errores de sintaxis se detectan después de ejecutar un comando de compilación. Y mantener actualizadas las plantillas a medida que evolucionan las API de Azure, es una carga de mantenimiento continua.

El resultado es que IaC a menudo se considera una habilidad especializada. Los ingenieros que no escriben plantillas con regularidad recurren a la selección del portal, lo que rompe la coherencia que se pretende conseguir con IaC.

Enfoque declarativo frente a imperativo

Hay dos estilos fundamentales de IaC. Comprender la diferencia le ayuda a elegir la herramienta adecuada y a crear mejores solicitudes de GitHub Copilot.

IaC declarativo

En un enfoque declarativo, se describe el estado final deseado de la infraestructura. La herramienta determina cómo llegar allí.

"Quiero una red virtual con espacio de direcciones 10.0.0.0/16 y dos subredes".

Azure Bicep y las plantillas de ARM son declarativas. Defina qué recursos deben existir y Azure Resource Manager controla la secuenciación y la creación. Si el recurso ya existe en el estado correcto, no se aplicará ningún cambio. Si no existe, se crea. Si es diferente, se actualiza.

IaC imperativo

En un enfoque imperativo, se describen los pasos necesarios para alcanzar el estado deseado. Está escribiendo un procedimiento, no una declaración.

"Compruebe si existe la red virtual. Si no es así, ejecute az network vnet create...".

los scripts CLI de Azure y Azure PowerShell suelen ser imperativos. Controla el flujo, controla los errores y administra el orden usted mismo. Darle más control, pero también más responsabilidad. Esto incluye controlar la idempoencia, lo que significa que el script debe ser seguro para ejecutarse varias veces.

¿Cuál debe usar?

La elección correcta depende del escenario. Las herramientas declarativas como Bicep son mejores para administrar recursos de infraestructura de larga duración porque controlan el estado y el desfase automáticamente. Las herramientas imperativas, como los scripts de la CLI, son mejores para las tareas operativas, los pasos de configuración única o la automatización que implica lógica, condiciones y bucles.

En la práctica, la mayoría de los ingenieros en la nube usan ambos. Y GitHub Copilot también ayuda con ambos.

Cómo GitHub Copilot cambia el proceso de creación de plantillas

GitHub Copilot acorta y simplifica cada paso del ciclo de creación de IaC.

En la etapa de redacción, Copilot genera definiciones de recursos completas a partir de descripciones de lenguaje natural. En lugar de buscar la sintaxis de Bicep para un recurso de Azure, se describe lo que necesita y Copilot genera un punto de partida en segundos.

At the review stage, Copilot puede analizar una plantilla existente e identificar brechas de seguridad, propiedades que faltan o patrones obsoletos. Actúa como un segundo conjunto de ojos antes de implementar la plantilla.

At the transform stage, Copilot puede convertir entre CLI de Azure y PowerShell, entre Azure Resource Manager JSON y Bicep, o entre Azure Pipelines y Acciones de GitHub. Reducir el coste de cambiar herramientas o adaptar ejemplos de documentación.

En la etapa de documentación, Copilot puede leer una plantilla completada y generar explicaciones legibles para humanos, referencias de parámetros y descripciones de arquitectura. Trabajo que a menudo se omite por completo porque es tedioso hacer manualmente.

El cambio no se trata solo de velocidad. Se trata de reducir la barrera de entrada. Los ingenieros que no son especialistas en Bicep ahora pueden generar plantillas correctas y bien estructuradas describiendo su intención en lenguaje claro.

GitHub Copilot funcionalidades para el trabajo de infraestructura

GitHub Copilot se integra de varias formas en VS Code, cada una de ellas adaptada a diferentes partes del flujo de trabajo de IaC.

Sugerencias en línea

A medida que escribes en un archivo .bicep, .yaml, .ps1 o .sh, Copilot ofrece finalizaciones en tiempo real. Si escribe el principio de una definición de recurso, Copilot predice el resto. Incluir propiedades necesarias, valores predeterminados y patrones comunes. Acepta con Tab o descarta con Escape.

Las sugerencias en línea son más efectivas para continuar patrones ya establecidos en el archivo. Si define correctamente un recurso, Copilot recoge la estructura y sugiere recursos similares con el mismo estilo.

Copilot Chat

Copilot chat (Ctrl+Alt+I) es una interfaz de conversación donde puede formular preguntas, describir lo que desea compilar, pegar código existente para su revisión o solicitar explicaciones.

El chat es mejor que las sugerencias en línea para las tareas que requieren más contexto. Ejemplos como generar una plantilla completa desde cero, refactorizar un archivo complejo o pedir una explicación de cómo funciona un recurso.

Copilot con MCP (Model Context Protocol)

MCP permite Copilot conectarse a herramientas externas y orígenes de datos. El servidor MCP de Bicep proporciona a Copilot acceso a definiciones de tipos de Bicep activas, versiones actuales de API y reglas de validación. Los resultados de Bicep son más precisos que los que se obtendrían usando únicamente datos de entrenamiento.

¿Por qué IaC es adecuada para la asistencia de inteligencia artificial?

Las definiciones de infraestructura tienen cualidades que les hacen buenos candidatos para la generación asistida por IA:

• Son muy estructurados: las definiciones de recursos siguen esquemas. Las propiedades se basan en tipos conocidos, valores válidos y designaciones obligatorias o opcionales. Esta naturaleza estructurada facilita que un modelo genere una salida sintácticamente correcta.
• Están llenos de patrones: La mayoría de las implementaciones de Azure usan un conjunto relativamente pequeño de tipos de recursos comunes: redes virtuales, cuentas de almacenamiento, recursos de cómputo e identidad. Estos patrones aparecen con frecuencia en los datos de entrenamiento, lo que significa que Copilot se basa en muchos ejemplos.
• Son costosos de investigar manualmente: la búsqueda de la combinación correcta de la versión de API, las propiedades necesarias y las SKU válidas para un tipo de recurso desconocido puede tardar mucho tiempo. Copilot comprime esa investigación en una sugerencia.
• Son seguros para iterar: valide antes de realizar la implementación. Se ha detectado una sugerencia incorrecta de Copilot en az bicep build o what-if antes de tocar los recursos reales. Esta red de seguridad fomenta la experimentación.

Conclusiones clave

• IaC trata la infraestructura como código: controlada por versiones, repetible y revisable.
• Herramientas declarativas como Bicep describen el estado final deseado; las herramientas imperativas, como la CLI, describen los pasos para llegar allí.
• El flujo de trabajo tradicional de IaC tiene una fricción significativa en cada fase. Copilot reduce esa fricción.
• GitHub Copilot ayuda a través de sugerencias en línea, Copilot Chat y contexto mejorado de MCP.
• IaC es adecuado para la asistencia de IA porque está estructurada, enriquecida con patrones y es segura para iterar.

Nota:

Reconocemos que a diferentes personas les gusta aprender de diferentes maneras. Puede optar por completar este módulo en formato basado en vídeo o puede leer el contenido como texto e imágenes. El texto contiene más detalle que los vídeos, por lo que, en algunos casos, es posible que desee hacer referencia a él como material complementario para la presentación de vídeo.