agentleFS
MicrosoftKnown publishermicrosoft/sre-agent/labs/zava-aks-postgres/.github/skills/deploying-demo/SKILL.md

deploying-demo

Skill187 starsChanged 6 months agoMITView on GitHub

Deploy the SRE Agent demo end-to-end. Use when asked to set up, deploy, or get this demo running.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run these and install anything missing:

    line 9
  2. Very specific:

    Check if user has a subscription: az account show

    line 26
  3. Distinctive:

    Wait for completion (~25 min).

    line 29
  4. Distinctive:

    If the LB IP is not reachable from your machine (corporate VPN, etc.), verify from inside the cluster instead:

    line 49
  5. Very specific:

    If azd outputs are complete, run .\scripts\setup-sre-agent.ps1.

    line 71
  6. Distinctive:

    Never substitute the SRE Agent resource name while using the UMI client ID.

    line 85
  7. Very specific:

    Run teardown from the same azd environment.

    line 110
  8. Distinctive:

    If the command fails, inspect the reported AMPLS link or role assignment before retrying.

    line 112

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deploying the Demo

Prerequisites Check

Run these and install anything missing:

  • az version — need 2.60+
  • azd version — need 1.9+
  • pwsh -v — need 7.4+
  • Azure permission: Owner, User Access Administrator, or equivalent Microsoft.Authorization/roleAssignments/write at subscription scope. The template grants the agent runtime identity subscription Reader for correlation context and removes it during azd down.
  • The responsible owner and expiry date, using the tag keys required by the target subscription. If deployment policy does not apply them, tag the resource group immediately after azd up.

Note: kubectl is not required on your local workstation. The cluster is private. Operator scripts in this repo go through az aks command invoke (wrapped by scripts/_aks-helpers.ps1). The SRE Agent uses its built-in RunKubectlReadCommand and RunKubectlWriteCommand tools instead.

Phase 1: Azure Deployment

  1. Check if user has a subscription: az account show
  2. Set azd environment: azd env set AZURE_SUBSCRIPTION_ID <sub-id> and azd env set AZURE_LOCATION swedencentral
  3. Run azd up --no-prompt
  4. Wait for completion (~25 min). Monitor progress. The post-provision hook handles image build, k8s manifest apply (via command invoke), workload identity federation, and SRE Agent data-plane sync.

Phase 2: Verify Deployment

The AKS API server is private (enablePrivateCluster: true) — local kubectl will not work. Human operators use the Azure-proxied command-invoke path:

. .\scripts\_aks-helpers.ps1
$ctx = Resolve-AksContext
$r = Invoke-AksCommand -ResourceGroup $ctx.ResourceGroup -ClusterName $ctx.ClusterName `
    -Command "kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'" -Quiet
$ip = ($r.logs -replace '[^\d\.]','').Trim()
"Storefront: http://$ip"
  1. Open http://<ip>/ in a browser — verify products load, status shows healthy.
  2. Hit the health endpoint from your local workstation: Invoke-RestMethod "http://<ip>/api/health" (the storefront LoadBalancer IP is public; only the cluster API server is private).
  3. If the LB IP is not reachable from your machine (corporate VPN, etc.), verify from inside the cluster instead:
    Invoke-AksCommand -ResourceGroup $ctx.ResourceGroup -ClusterName $ctx.ClusterName `
        -Command "kubectl exec -n zava-demo deploy/zava-api -- wget -qO- http://localhost:3001/api/health"

For SRE Agent operations, use the built-in RunKubectlReadCommand and RunKubectlWriteCommand tools. See docs/aks-access-and-auth.md for other operator and automation access options.

Phase 3: Configure + verify SRE Agent

Bicep provisions the agent, identity, networking, autonomous mode, and Azure Monitor binding. The setup script waits for the authenticated configuration API, then applies the separate connector Bicep template. It applies custom skills and response plans from the repository, uploads knowledge files, syncs global instructions, enables the Microsoft Learn tools, and verifies the result.

azd up runs setup-sre-agent.ps1 through the post-provision hook. Run it manually only to retry or apply later configuration changes:

  1. If azd outputs are complete, run .\scripts\setup-sre-agent.ps1.
  2. For standalone recovery after partial provisioning, pass the values explicitly:
    .\scripts\setup-sre-agent.ps1 `
        -ResourceGroup <resource-group> `
        -AgentName <sre-agent-name> `
        -PostgresHost <server>.postgres.database.azure.com `
        -PostgresDatabase zava_store `
        -SreAgentClientId <attached-umi-client-id> `
        -SreAgentPrincipalName <attached-umi-resource-name>
    PostgresHost must be the Flexible Server FQDN. The principal name must be the resource name of the same attached/action UMI selected by the client ID. Never substitute the SRE Agent resource name while using the UMI client ID.
  3. For missing connectors, skills, or response plans, inspect the reported failure and rerun setup-sre-agent.ps1. If core agent infrastructure is missing, rerun azd provision. Do not add sleeps to hide readiness failures: -ReadinessTimeoutSeconds and -ConnectorTimeoutSeconds bound the existing readiness/deployment gates. A timed-out connector deployment is canceled on a best-effort basis; inspect its status before retrying.

Post-provision waits for the operator's Kubernetes access before applying manifests and fails if ingress installation, application rollout, or endpoint lookup fails. After correcting a transient failure, retry .\scripts\post-provision.ps1 -SkipImageBuild only if both image builds already succeeded. Do not treat ARM provisioning success as proof that the app is ready.

Optional: confirm the agent is reachable

Sanity-check the agent's data-plane API before running break/fix scenarios:

.\scripts\watch-agent.ps1     # lists incident threads (empty on a fresh deploy is fine)

This is the same script the running-demo skill uses to tail the agent live during scenarios.

Teardown

azd down --force --purge

Run teardown from the same azd environment. Confirm that the resource group is absent and the runtime identity's subscription Reader assignment was removed. If the command fails, inspect the reported AMPLS link or role assignment before retrying. Use a new environment name for the next deployment.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.