Azure CLI i pomoc programu PowerShell w GitHub Copilot

Pomimo wzrostu deklaratywnych narzędzi IaC, takich jak Bicep, narzędzia wiersza polecenia, takie jak Azure CLI i Azure PowerShell, pozostają niezbędne dla inżynierów chmury. Niektóre zadania nie pasują łatwo do szablonu: sprawdzanie przed wdrożeniem, migracje danych, operacyjne runbooki, nieplanowane rozwiązywanie problemów i automatyzacja obejmująca logikę warunkową lub pętle.

Skrypty wiersza polecenia są również często pierwszą rzeczą, dla której zespół sięgnie, gdy coś musi się zdarzyć szybko. Szybkość pisania i uruchamiania skryptu ma znaczenie. Dokładnie tam, gdzie GitHub Copilot od razu dodaje wartość. Zamiast przeszukiwać dokumentację w poszukiwaniu odpowiedniego polecenia i jego parametrów, opisujesz to, czego potrzebujesz, prostymi słowami, a Copilot generuje skrypt.

Azure CLI i Azure PowerShell

Pomaga to zrozumieć, które narzędzie ma być dostępne przed wygenerowaniem skryptów.

Azure CLI (az) to wieloplatformowe narzędzie wiersza polecenia, które działa w systemach Windows, macOS i Linux. Jego dane wyjściowe są domyślnie w formacie JSON, co ułatwia łatwe przekazywanie danych do innych narzędzi. Azure CLI jest powszechnie używany w skryptach bash, przez agentów CI/CD na systemie Linux oraz zespoły z doświadczeniem w Linuxie lub DevOps.

Azure PowerShell (moduł Az) używa języka programu PowerShell i działa w systemie Windows, macOS i Linux za pośrednictwem programu PowerShell 7+. Jego dane wyjściowe to ustrukturyzowane obiekty .NET, co umożliwia złożoną logikę, filtrowanie i integrację z innymi usługami Microsoft. Program PowerShell wydaje się preferowany przez zespoły Windows i administratorów systemu.

Oba narzędzia obejmują te same operacje Azure. Wybór między nimi jest w dużej mierze pytaniem, w jakim języku twój zespół jest najbardziej wygodny w pracy i w którym środowisku działają skrypty. GitHub Copilot obsługuje oba przypadki płynnie i może tłumaczyć między nimi.

Generowanie skryptów Azure CLI za pomocą Copilot

Rozpocznij od prostego

W przypadku prostego tworzenia zasobów dobrze sprawdza się bezpośredni monit. Copilot zna strukturę poleceń az i może wygenerować poprawną składnię typowych operacji.

Przykładowy monit może wyglądać następująco:

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.

Gdzie odpowiedź GitHub Copilot może być podobna do następującej:

az group create \
  --name rg-webapp-prod \
  --location westeurope \
  --tags Environment=Production Owner=platform-team

W przypadku pojedynczego polecenia składnia jest prosta. Rzeczywista wartość jest wyświetlana, gdy poprosisz GitHub Copilot o utworzenie kompletnego skryptu z wieloma krokami, zmiennymi i obsługą błędów.

Tworzenie pełnego skryptu udostępniania zasobów

W tym bardziej zaawansowanym podejściu monit może zawierać więcej szczegółów, takich jak w tym przykładzie:

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 generuje skrypt z czystym blokiem zmiennej, sprawdzaniem idempotentności i komunikatami o stanie. Poniżej przedstawiono kluczowe techniki monitowania:

• Zmienne u góry: zapobiega zakodowanym na stałe wartościom rozrzuconym za pośrednictwem skryptu
• Sprawdzanie istnienia przed utworzeniem: sprawia, że skrypt staje się idempotentny (bezpieczny do ponownego uruchomienia)
• Zakończ po awarii (set -e): uniemożliwia propagację cichych niepowodzeń

Dodaj idempotentność

Idempotency oznacza, że skrypt generuje ten sam wynik, niezależnie od tego, czy jest uruchamiany raz, czy 10 razy. Co ma kluczowe znaczenie dla skryptów automatyzacji, które mogą być działające zgodnie z harmonogramem lub w ramach potoków CI/CD.

Oto przykład użycia promptu, aby dodać idempotentność do generowania skryptu:

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 opakowuje każde polecenie az ... create we wzorcu sprawdzania istnienia:

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

Dodawanie walidacji parametru

Innym przydatnym przypadkiem użycia jest użycie weryfikacji parametrów w ramach monitu. Zobacz przykład tutaj:

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

Ten schemat sprawia, że skrypty są odpowiednie do użycia w pipelinach automatyzacji, w których dane wejściowe pochodzą ze zmiennych środowiskowych lub parametrów CI/CD, a nie wartości zakodowanych na sztywno.

Generowanie skryptów Azure PowerShell za pomocą GitHub Copilot

To samo podejście języka naturalnego działa w programie PowerShell (Azure). Copilot rozumie cmdlety modułu Az i generuje typowy dla PowerShell kod zamiast tłumaczyć składnię CLI dosłownie.

Uwzględniając wymagany język skryptów w wierszu polecenia, należy zawęzić zakres 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 odpowiada za pomocą jasnej składni programu PowerShell, rozumienia zasobów i parametrów Azure:

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" }
}

Zwróć uwagę, że Copilot naturalnie tworzy wzorce idiomatyczne programu PowerShell: param() bloki, try/catch, -ErrorAction SilentlyContinue i rozszerzenia składnia $(...). Nie próbuje replikować wzorców powłoki bash w programie PowerShell.

Tłumaczenie między interfejsem wiersza polecenia i programem PowerShell

Jednym z najbardziej praktycznych zastosowań GitHub Copilot do pracy infrastruktury jest konwertowanie skryptów między narzędziami. Typowe scenariusze to:

• Skrypt napisany przez zespół skoncentrowany na systemie Linux i musi działać w Windows
• Przykłady dokumentacji znajdują się w interfejsie wiersza polecenia, ale twój zespół korzysta z programu PowerShell
• Chcesz standandaryzować całą automatyzację do jednego języka

Przykład takiego monitu przekształcenia może być podobny do tego przykładu:

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]

Instrukcja Do not add features that are not in the original jest ważna. Bez niego Copilot czasami dodaje rejestrowanie, dane telemetryczne lub dodatkowe funkcje, których nie zażądano. Utrudnianie porównywania dwóch skryptów i weryfikowania równoważności.

Kluczowe odpowiedniki poleceń CLI w PowerShell

Zrozumienie mapowań pomaga zweryfikować tłumaczenia Copilot:

Praktyczne wzorce pracy interfejsu wiersza polecenia Copilot-Assisted

Generowanie poleceń dla nieznanych zasobów

Nawet doświadczeni inżynierowie Azure napotykają Azure typy zasobów, z którymi wcześniej pracowali. Copilot usuwa wyszukiwanie dokumentacji:

Dołączenie wyraźnego odwołania do typu zasobu Azure w podpowiedzi jest wystarczające, aby Copilot wygenerował poprawne polecenie.

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 generuje poprawne polecenie az acr create z odpowiednimi nazwami flag. Dołączanie flag, które są łatwe do zapomnienia, takie jak --sku, --admin-enabled falsei --identity [system].

Kompilowanie skryptów oczyszczania

Skrypty oczyszczania są niezbędne w środowiskach szkoleniowych i programistycznym. Copilot szybko je generuje. Przykład takiego monitu może wyglądać następująco:

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

Generowanie skryptów między subskrypcjami

Środowiska przedsiębiorstwa często korzystają z wielu subskrypcji Azure. Dzięki GitHub Copilot ta dodatkowa złożoność jest łatwa do obsługi. Dołącz tę specyfikację jako część polecenia, jak pokazano tutaj:

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 generuje strukturę pętli przy użyciu az account list i az account set poprawnie, obsługując przełącznik kontekstu subskrypcji, który stanowi wyzwanie dla wielu inżynierów piszących kod od podstaw.

Najważniejsze wnioski

• Azure CLI i program PowerShell są niezbędne w przypadku automatyzacji operacyjnej i warunkowej, która nie pasuje do szablonu deklaratywnego.
• Skuteczne monity interfejsu wiersza polecenia obejmują bloki zmiennych, kontrole istnienia, obsługę błędów i wymagania dotyczące tagów.
• Copilot generuje idiomatyczne dane wyjściowe zarówno w interfejsie wiersza polecenia, jak i w programie PowerShell; nie jest to mechaniczne tłumaczenie z jednego na drugi.
• Użyj wzorca tłumaczenia ("Przetłumacz ten skrypt interfejsu wiersza polecenia na program PowerShell, zachowaj całą logikę, nie dodawaj funkcji") w celu niezawodnej konwersji między narzędziami.
• Użyj interfejsu wiersza poleceń do zadań operacyjnych i warunkowych; stosuj Bicep do zarządzania stanem trwałej infrastruktury.