CLI de Azure y PowerShell con la asistencia de GitHub Copilot
Tip
Consulte la pestaña Texto e imágenes para obtener más detalles.
A pesar del aumento de las herramientas declarativas de IaC como Bicep, las herramientas de línea de comandos, como CLI de Azure y Azure PowerShell, siguen siendo esenciales para los ingenieros en la nube. Algunas tareas no encajan perfectamente en una plantilla: comprobaciones previas a la implementación, migraciones de datos, runbooks operativos, solución de problemas no planeada y automatización que implica lógica condicional o bucles.
Los scripts de línea de comandos (CLI) también suelen ser lo primero a lo que recurre un equipo, cuando algo debe resolverse rápidamente. La velocidad a la que puede escribir y ejecutar un script es importante. Exactamente donde GitHub Copilot agrega valor inmediato. En lugar de buscar documentación sobre el comando correcto y sus parámetros, se describe lo que desea en lenguaje sin formato y Copilot genera el script.
CLI de Azure frente a Azure PowerShell
Ayuda a comprender qué herramienta utilizar antes de generar scripts.
CLI de Azure (az) es una herramienta de línea de comandos multiplataforma que se ejecuta en Windows, macOS y Linux. Su salida es JSON de forma predeterminada, lo que facilita la canalización a otras herramientas. CLI de Azure se usa ampliamente en scripts de Bash, agentes de CI/CD basados en Linux y en equipos con un fondo de Linux o DevOps.
Azure PowerShell (Az module) usa el lenguaje powerShell y se ejecuta en Windows, macOS y Linux a través de PowerShell 7+. Su salida es objetos .NET estructurados, lo que hace que sea eficaz para la lógica compleja, el filtrado y la integración con otros servicios Microsoft. PowerShell parece ser preferido por equipos que utilizan mayormente Windows y administradores de sistemas.
Ambas herramientas cubren las mismas operaciones de Azure. Elegir entre ellos es en gran medida una cuestión de con qué idioma se siente más cómodo el equipo y en qué entorno se ejecutan los scripts. GitHub Copilot maneja ambos con fluidez y puede traducir entre ellos.
Generación de scripts de CLI de Azure con Copilot
Inicio sencillo
Para la creación de recursos de manera sencilla, un indicativo directo funciona bien. Copilot conoce la estructura de comandos az y puede generar una sintaxis correcta para las operaciones comunes.
Un mensaje de ejemplo podría tener este aspecto:
Generate an Azure CLI command to create a resource group called "rg-webapp-prod" in the West Europe region, tagged with Environment=Production and Owner=platform-team.
Donde la respuesta de GitHub Copilot podría ser similar a la siguiente:
az group create \
--name rg-webapp-prod \
--location westeurope \
--tags Environment=Production Owner=platform-team
Para un solo comando, la sintaxis es sencilla. El valor real aparece cuando se le pide que GitHub Copilot cree un script completo con varios pasos, variables y control de errores.
Creación de un script de aprovisionamiento completo
En este enfoque más avanzado, el mensaje puede contener más detalles, como el ejemplo siguiente:
Generate an Azure CLI bash script that provisions the following resources:
- Resource group: rg-iaclab in East US
- VNet: vnet-iaclab with address space 10.0.0.0/16
- Subnet: snet-app at 10.0.1.0/24
- NSG: nsg-app with a rule denying all inbound internet traffic
except HTTPS (port 443)
- Associate the NSG with snet-app
Requirements:
- Use variables at the top for all configurable values
- Check if the resource group already exists before creating it
- Print a status message after each successful resource creation
- Exit immediately if any command fails (set -e)
- Tag all resources with Environment=Training and Owner=lab-user
Copilot genera un script con un bloque de variables limpio, comprobaciones de idempotencia y mensajes de estado. Las técnicas clave de instrucción aquí son:
- Variables en la parte superior: impide que los valores codificados de forma rígida se disperse a través del script.
- Comprobación de existencia antes de la creación: hace que el script sea idempotente (seguro para volver a ejecutarse)
-
Salir en caso de error (
set -e): impide que se propaguen errores silenciosos.
Agregar idempotencia
Idempotency significa que el script genera el mismo resultado, ya sea que se ejecute una vez o 10 veces. Es fundamental para los scripts de automatización que pueden ejecutarse de forma programada o como parte de canalizaciones de CI/CD.
Este es un ejemplo de cómo se usa una solicitud para agregar idempotencia a sus scripts:
Refactor this script so that each resource creation command first checks whether the resource already exists. If it exists, print "already exists — skipping" and continue. If it does not exist, create it.
Use az [resource] show with a 2>/dev/null check to test for existence.
Copilot envuelve cada comando az ... create en un patrón de comprobación de existencia.
if ! az network vnet show --name "$VNET_NAME" --resource-group "$RG_NAME" \
--query id -o tsv 2>/dev/null; then
echo "Creating VNet: $VNET_NAME..."
az network vnet create \
--name "$VNET_NAME" \
--resource-group "$RG_NAME" \
--address-prefix "$VNET_PREFIX"
echo "VNet created successfully."
else
echo "VNet $VNET_NAME already exists — skipping."
fi
Adición de validación de parámetros
Otro caso de uso útil es usar la validación de parámetros, como parte de la solicitud. Vea el ejemplo aquí:
Add a validation block at the top of the script that:
- Checks that the az CLI is installed and the user is logged in
- Verifies the target subscription is set correctly
- Accepts RESOURCE_GROUP, LOCATION, and OWNER as command-line arguments
and exits with a usage message if they are not provided
Este patrón hace que los scripts sean adecuados para su uso en canalizaciones de automatización en los que las entradas proceden de variables de entorno o parámetros de CI/CD en lugar de valores codificados de forma rígida.
Generación de scripts de Azure PowerShell con GitHub Copilot
El mismo enfoque de lenguaje natural funciona para PowerShell (Azure). Copilot entiende los cmdlets del módulo Az y genera scripts de PowerShell que suenan naturales en lugar de traducir la sintaxis de la CLI de manera literal.
Al incluir el lenguaje de scripting necesario en una solicitud, se limita el ámbito de GitHub Copilot:
Generate an Azure PowerShell script that:
- Connects to Azure using a service principal (client ID, client secret,
tenant ID passed as parameters)
- Creates a resource group "rg-iaclab" in East US if it does not already exist
- Creates a Storage Account with Standard_LRS SKU, HTTPS-only access,
and blob soft delete enabled (30 days)
- Outputs the storage account's primary connection string at the end
Use proper error handling with try/catch blocks.
GitHub Copilot responde con una sintaxis clara de PowerShell, que comprende los Azure recursos y parámetros:
param(
[Parameter(Mandatory=$true)][string]$TenantId,
[Parameter(Mandatory=$true)][string]$ClientId,
[Parameter(Mandatory=$true)][string]$ClientSecret,
[string]$Location = "eastus",
[string]$ResourceGroupName = "rg-iaclab",
[string]$StorageAccountName = "stiaclab$(Get-Random -Maximum 9999)"
)
# Connect using service principal
$SecureSecret = ConvertTo-SecureString $ClientSecret -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential($ClientId, $SecureSecret)
try {
Connect-AzAccount -ServicePrincipal -Credential $Credential -Tenant $TenantId
Write-Host "Connected to Azure successfully." -ForegroundColor Green
} catch {
Write-Error "Failed to connect to Azure: $_"
exit 1
}
# Create resource group if it does not exist
$RG = Get-AzResourceGroup -Name $ResourceGroupName -ErrorAction SilentlyContinue
if (-not $RG) {
Write-Host "Creating resource group: $ResourceGroupName..."
New-AzResourceGroup -Name $ResourceGroupName -Location $Location `
-Tag @{ Environment = "Training"; Owner = "lab-user" }
}
Tenga en cuenta que Copilot genera naturalmente patrones idiomáticos de PowerShell: param(), try/catch, -ErrorAction SilentlyContinue y la sintaxis de expansión $(...). No intenta replicar patrones de Bash en PowerShell.
Traducción entre la CLI y PowerShell
Uno de los usos más prácticos de GitHub Copilot para el trabajo de infraestructura es convertir scripts entre herramientas. Los escenarios comunes son:
- Un script escrito por un equipo centrado en Linux y debe ejecutarse en Windows
- Los ejemplos de documentación están en la CLI, pero el equipo usa PowerShell
- Quiere estandarizar toda la automatización en un idioma
Un ejemplo de este mensaje de transformación podría ser similar a este ejemplo:
Translate the following Azure CLI bash script to Azure PowerShell.
Use Az module cmdlets throughout. Preserve:
- The same variable/parameter names where possible
- All error handling logic
- The existence check pattern before each resource creation
- Tag application on all resources
Do not add features that are not in the original script.
[paste your CLI script here]
La instrucción Do not add features that are not in the original es importante. Sin ella, Copilot a veces agrega registro, telemetría o funcionalidades adicionales que no se solicitaron. Hacer que sea más difícil comparar los dos scripts y comprobar la equivalencia.
Equivalentes clave de la CLI a PowerShell
Comprender las correspondencias le ayuda a verificar las traducciones de Copilot.
| CLI de Azure | Azure PowerShell |
|---|---|
az group create |
New-AzResourceGroup |
az group show |
Get-AzResourceGroup |
az network vnet create |
New-AzVirtualNetwork |
az network nsg create |
New-AzNetworkSecurityGroup |
az vm create |
New-AzVM |
az storage account create |
New-AzStorageAccount |
az keyvault create |
New-AzKeyVault |
--query + --output tsv |
Select-Object + .PropertyName |
$? (comprobación de código de salida) |
$? o try/catch |
Patrones prácticos para el trabajo con la CLI asistida por Copilot
Generación de comandos para recursos desconocidos
Incluso los ingenieros experimentados en Azure encuentran tipos de recursos de Azure con los que ya han trabajado. Copilot quita la búsqueda de documentación:
Incluir una referencia clara al tipo de recurso Azure en tu indicación es suficiente para que Copilot genere el comando correcto.
Generate an Azure CLI command to create an Azure Container Registry with
Premium SKU, geo-replication to West Europe, admin account disabled,
and a system-assigned managed identity. Output the login server at the end.
Copilot genera el comando correcto az acr create con los nombres de bandera correctos. Incluir marcas fáciles de olvidar, como --sku, --admin-enabled falsey --identity [system].
Creación de scripts de limpieza
Los scripts de limpieza son esenciales en entornos de entrenamiento y desarrollo. Copilot los genera rápidamente. Un ejemplo de este mensaje podría tener este aspecto:
Generate an Azure CLI script that:
- Lists all resource groups with the tag Environment=Training
- Prints each group name and asks for confirmation before deleting
- Deletes confirmed groups with --no-wait for speed
- Reports how many groups were deleted at the end
Generación de scripts entre suscripciones
Los entornos empresariales suelen depender de varias suscripciones de Azure. Con GitHub Copilot, esta complejidad adicional es fácil de controlar. Incluya esa especificación como parte del mensaje, como se muestra aquí:
Generate an Azure CLI script that iterates over all subscriptions in my tenant,
checks each one for storage accounts that have public blob access enabled,
and outputs a CSV report with: SubscriptionName, ResourceGroup, StorageAccountName, Location.
Copilot genera la estructura del bucle porque usa correctamente az account list y az account set, lo que permite gestionar el cambio de contexto de la suscripción, algo que suele plantear dificultades a muchos ingenieros que programan desde cero.
Conclusiones clave
- CLI de Azure y PowerShell son esenciales para la automatización operativa y condicional que no se ajusta a una plantilla declarativa.
- Los avisos eficaces de la CLI incluyen bloques de variables, comprobaciones de existencia, control de errores y requisitos de etiquetas.
- Copilot genera resultados idiomáticos tanto en la CLI como en PowerShell; No es una traducción mecánica de uno al otro.
- Use el patrón de traducción ("Traducir este script de la CLI a PowerShell, conservar toda la lógica, no agregar características") para la conversión confiable entre herramientas.
- Utilice la CLI para tareas operativas y condicionales; utilice Bicep para gestionar el estado persistente de la infraestructura.