az_deploy: Building and Shipping Both Images

• Azure CLI installed, and az login already done — the script never logs you in.
• The resources from az_create_resources must already exist; this script only updates them.
• Run it from the repository root, not from inside utility_scripts/ — it locates the build contexts relative to the project.
• No Docker needed. The images are built by Azure Container Registry, not on your machine.

Push-Location $webApp.Context
try {
    Invoke-Az acr build --registry $RegistryName --resource-group $resourceGroup `
        --image "$($webApp.Image):$ImageTag" --file $webApp.DockerfilePath .
}
finally { Pop-Location }

One command per image. It packs the build context into an archive, uploads it, and asks the registry to run the Dockerfile on a managed build agent — the finished image is pushed into the registry without ever existing on your machine.

The Push-Location isn't decoration. az acr build validates --file against the current directory rather than the source argument, so the API (context: repo root, file: metals_api/Dockerfile) and the UI (context: metals_ui, file: Dockerfile) each have to run from their own context.

Invoke-Az webapp config container set --name $name --resource-group $resourceGroup `
    --container-image-name $image `
    --container-registry-url "https://$($registry.loginServer)" --output none

Sets which image the app should run. Strictly it's only needed when the tag changes, but running it every time makes the script idempotent — and it's what converts an app that was previously configured for something else.

No registry credentials appear here. The Web App authenticates to the registry with its own managed identity, configured back in az_create_resources.

Invoke-Az webapp restart --name $name --resource-group $resourceGroup --output none

Because this project reuses the latest tag, step 2 usually sets the image name to the value it already had — so Azure sees no change and keeps running the old container indefinitely. An explicit restart forces a fresh pull. Skip this and the deployment silently does nothing.

for ($attempt = 1; $attempt -le 10; $attempt++) {
    try {
        $response = Invoke-WebRequest -Uri "https://$hostName/health" -TimeoutSec 10 -UseBasicParsing
        if ($response.StatusCode -eq 200) { $healthy = $true; break }
    }
    catch { Start-Sleep -Seconds 10 }
}

webapp restart returns immediately, long before the new container is serving traffic. The script polls each app's /health endpoint up to ten times, ten seconds apart, and warns clearly if one never comes up — so a broken rollout looks like a failure rather than a success.

• Installing Docker on every machine that might deploy, including CI runners.
• A separate registry login. Your existing az login is the only authentication involved.
• Uploading image layers. Only the source is sent; the built layers never leave Azure.
• Architecture mismatches. The image is always built on the platform it will run on, so an ARM laptop can't accidentally produce an image the x86 Web App can't start.

You lose the local build cache — each az acr build starts fresh, so a small code change costs a full rebuild rather than a few cached seconds. For a deployment step that's an acceptable price; for the tight edit-and-test loop you'd still use Compose locally.