LAB navigation

Each tab keeps one lane legible: control plane, workload, modern workloads, cloud terminals, or the microservice fabric.

public site on vercel, private execution through LAB lanes
read-only until sign in
Azure terminal

Azure

Keep the Azure lane focused on live ARM reads and migration workstream commands: inspect the resource group, virtual network, compute inventory, and DB host state from a server-side route without leaking credentials to the browser.

Microsoft Azure
live route + ARM + workstreams
Topology map
numbered workflow junctionslive command highlights active pathFigma ref

Multi-cloud control plumbing

>

Azure live workflow

Expand to see the phase-by-phase operator sequence for this tab.

6 phases
>
phase 011. Read Azure landing zonelive

Start with spend-watch and landing-zone visibility so runaway resources, disks, and public IPs are visible before you touch the workstream host.

3 cmds
  1. 01
    Read the live Azure VM footprint first, including create time and approximate runtime, so any stray compute is visible before new work starts.
    show raw commands
    selected command
    lab azure running vms
    raw step 01
    arm.resources.list(resourceGroup=lab-wm-rg)
    raw step 02
    arm.virtualMachines.get($expand=instanceView)
    raw step 03
    Dependency: use this before provisioning to confirm whether a prior lab host is still running.
  2. 02
    Catch idle public IP exposure early. This is the Azure equivalent of checking for spend leakage before building out the host path.
    show raw commands
    selected command
    lab azure public ips
    raw step 01
    filter(type == Microsoft.Network/publicIPAddresses)
    raw step 02
    Dependency: if a stale public IP exists from an earlier run, clean it up before creating more footprint.
  3. 03
    Read the live Azure operator trail so today’s creates, deletes, and changes have a clear audit baseline before new provisioning begins.
    show raw commands
    selected command
    lab azure activity today
    raw step 01
    az monitor activity-log list --max-events 10
    raw step 02
    Dependency: use this to confirm whether the current host was created earlier today or is carry-over from a prior session.
>
phase 022. Create tiny Azure targetlive

Provision the tiny Azure database target only after the landing zone checks pass, then add the dedicated data disk before guest prep.

4 cmds
  1. 01
    Create the smallest practical Azure VM for the migration lane. This host becomes the anchor for later disk attach, guest prep, and readiness checks.
    show raw commands
    selected command
    lab azure create db-host
    raw step 01
    az vm create -g lab-wm-rg -n lab-db-az-01 --image Ubuntu2404 --size Standard_B1s
    raw step 02
    az vm show -g lab-wm-rg -n lab-db-az-01
    raw step 03
    Dependency: the VM name lab-db-az-01 becomes the anchor for every later Azure command in this lane.
  2. 02
    Create the dedicated PostgreSQL data disk separately so the migration story stays explicit and the root disk stays disposable.
    show raw commands
    selected command
    lab azure create db-disk
    raw step 01
    az disk create -g lab-wm-rg -n lab-db-az-data-01 --size-gb 12 --sku StandardSSD_LRS
    raw step 02
    az disk list -g lab-wm-rg
    raw step 03
    Dependency: create the disk before mount prep so PostgreSQL data does not land on the VM root disk.
  3. 03
    Attach the dedicated data disk to the Azure database VM before any filesystem or PostgreSQL configuration begins.
    show raw commands
    selected command
    lab azure attach db-disk
    raw step 01
    az vm disk attach -g lab-wm-rg --vm-name lab-db-az-01 --name lab-db-az-data-01
    raw step 02
    az vm show -g lab-wm-rg -n lab-db-az-01 --query storageProfile.dataDisks
    raw step 03
    Dependency: guest prep should wait until this disk is visible in Azure and presented to the VM.
  4. 04
    Estimate today’s Azure VM and disk cost from the currently visible live footprint so the workstream has a spend baseline before guest prep.
    show raw commands
    selected command
    lab azure approx cost today
    raw step 01
    arm.virtualMachines.get($expand=instanceView)
    raw step 02
    estimateAzureVmCostToday(vmSize, elapsedHours) = hourlyRate(vmSize) * elapsedHours
>
phase 033. Prepare Azure database hostlive

Only after the VM and dedicated disk exist, use live Azure workstream checks to install, mount, and verify the guest for imported data.

3 cmds
  1. 01
    Run the Azure guest preparation workflow that installs PostgreSQL, mounts the attached data disk, and writes a readiness marker on the host.
    show raw commands
    selected command
    lab azure prepare db-host
    raw step 01
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'sudo apt-get update && sudo apt-get install -y postgresql postgresql-contrib'
    raw step 02
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'sudo mkfs.ext4 /dev/sdc && sudo mkdir -p /var/lib/lab-azure-db && sudo mount /dev/sdc /var/lib/lab-azure-db'
    raw step 03
    Dependency: the VM must be running and the data disk must be attached before guest prep can succeed.
  2. 02
    Confirm the dedicated Azure disk exists and is attached before trusting any guest-side prep output.
    show raw commands
    selected command
    lab azure inspect db-disk
    raw step 01
    az disk list -g lab-wm-rg
    raw step 02
    az vm show -g lab-wm-rg -n lab-db-az-01 --query storageProfile.dataDisks
    raw step 03
    Dependency: disk attach must have completed or the guest preparation workflow cannot mount the dedicated volume.
  3. 03
    Verify the PostgreSQL service, mount status, and preparation marker before attempting any migration step.
    show raw commands
    selected command
    lab azure verify db-host
    raw step 01
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'systemctl is-active postgresql; findmnt /var/lib/lab-azure-db; test -f /var/lib/lab-azure-db/.prepared'
    raw step 02
    Dependency: migration should not begin until PostgreSQL is healthy and the preparation marker is present on the Azure target.
>
phase 044. Migrate VCF database to Azurelive

After Azure guest prep is complete, use real upload and restore commands so the VCF-to-Azure path is explicit and auditable.

4 cmds
  1. 01
    Export the authoritative VCF dataset and stage the SQL artifact on the Azure host before any restore work begins.
    show raw commands
    selected command
    lab azure upload dump
    raw step 01
    lab db export --target-file <run-id>-vcf-to-azure.sql
    raw step 02
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'cat > /tmp/<artifact>.sql <<"EOF" ... EOF'
    raw step 03
    Dependency: run this before restore so the Azure import always starts from a known VCF snapshot.
  2. 02
    Export from VCF, upload the dump, and restore it into the Azure PostgreSQL target in one auditable step.
    show raw commands
    selected command
    lab azure restore into azure
    raw step 01
    lab db export --target-file <run-id>-vcf-to-azure.sql
    raw step 02
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'sudo -u postgres psql -d labapp -v ON_ERROR_STOP=1 -f /tmp/<artifact>.sql'
    raw step 03
    Dependency: use this once the Azure host is ready and the dump needs to be restored into PostgreSQL.
  3. 03
    Review the exact Azure-side workstream status and transfer order before attempting any real upload or restore.
    show raw commands
    selected command
    lab azure migration status
    raw step 01
    Dependency: use this to confirm host, disk, mount, and PostgreSQL state before staging any real transfer artifact.
  4. 04
    Run one aggregated readiness check that reports VM state, disk attach, PostgreSQL health, mount status, and the Azure prep marker.
    show raw commands
    selected command
    lab azure verify migration-ready
    raw step 01
    Dependency: use this before attempting any real dump upload or restore into the Azure database target.
>
phase 055. Migrate Azure database back to VCFlive

Keep the return path explicit so Azure remains a reversible migration story rather than a one-way cutover.

3 cmds
  1. 01
    Dump the Azure PostgreSQL rows into a local migration artifact before restoring back into VCF.
    show raw commands
    selected command
    lab azure dump db
    raw step 01
    az vm run-command invoke -g lab-wm-rg -n lab-db-az-01 --command-id RunShellScript --scripts 'sudo -u postgres psql -d labapp -At -F "|" -c "select ..."'
    raw step 02
    Dependency: the reverse path only makes sense once Azure host prep, attach, and readiness are green.
  2. 02
    Dump Azure rows, build the migration artifact, and restore it back into the VCF PostgreSQL lab instance.
    show raw commands
    selected command
    lab azure restore into vcf
    raw step 01
    lab db import --source-file <run-id>-azure-to-vcf.sql
    raw step 02
    Dependency: run only after the Azure dump exists and the VCF destination is ready to receive it.
  3. 03
    Read back the latest rows on the VCF side after the return migration completes so the operator can prove the round-trip succeeded.
    show raw commands
    selected command
    lab db recent
    raw step 01
    Dependency: use this after restore to confirm the VCF lane is authoritative again.
>
phase 066. Audit spend and clean up Azurelive

End the Azure chapter by checking disks, cost, and public IP leakage, then tear down the LAB-scoped resources explicitly.

3 cmds
  1. 01
    Confirm no orphaned managed disks are still billing after the workstream run.
    show raw commands
    selected command
    lab azure unattached disks
    raw step 01
    filter(type == Microsoft.Compute/disks && (!managedBy || diskState contains Unattached))
  2. 02
    Read the same-day spend approximation before teardown so operators can quantify the session footprint.
    show raw commands
    selected command
    lab azure approx cost today
  3. 03
    Delete the LAB Azure VM, disk, NIC, VNet, and matching public IP resources in the configured resource group.
    show raw commands
    selected command
    lab azure kill all lab resources
    raw step 01
    az vm delete -g lab-wm-rg -n lab-azure-db-host --yes
    raw step 02
    az disk delete -g lab-wm-rg -n lab-azure-db-disk --yes
    raw step 03
    az network nic delete -g lab-wm-rg -n lab-azure-db-nic
    raw step 04
    az network vnet delete -g lab-wm-rg -n lab-azure-db-vnet
live terminalazure@lab

Azure terminal

Live route

command lineidle
azure@lab$
Public visitors can still fill and copy commands. Sign in or create an account to browse with a member session.
operator indexfill command line

Azure

history buffer

Run a command to capture the last five entries here. Each row stays compact until you expand it.