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
GCP terminal

GCP

Keep the GCP lane focused on live Google Cloud reads and workstreams without leaking credentials to the browser.

Google Cloud
live route
Topology map
numbered workflow junctionslive command highlights active pathFigma ref

Multi-cloud control plumbing

>

GCP live workflow

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

6 phases
>
phase 011. Read GCP landing zonelive

Start with live compute, disk, and event visibility so runaway GCP spend is visible before provisioning or migration work begins.

3 cmds
  1. 01
    Read the live GCP compute footprint first so any existing VM spend is visible before you create or attach anything.
    show raw commands
    selected command
    lab gcp running instances
    raw step 01
    compute.instances.aggregatedList(project=<project>)
  2. 02
    Surface orphaned persistent disks before the workstream creates more storage footprint.
    show raw commands
    selected command
    lab gcp unattached disks
    raw step 01
    compute.disks.aggregatedList(project=<project>)
  3. 03
    Read the recent GCP operator trail so today’s activity is visible before new provisioning begins.
    show raw commands
    selected command
    lab gcp logging today
    raw step 01
    logging.entries.list(project=<project>, filter='resource.type="gce_instance"')
>
phase 022. Create tiny GCP targetlive

Stage the smallest practical VM plus a dedicated disk for PostgreSQL data.

4 cmds
  1. 01
    Provision the tiny GCP migration target.
    show raw commands
    selected command
    lab gcp create db-host
    raw step 01
    gcloud compute instances create lab-db-gcp-01 --zone us-central1-a --machine-type e2-micro --image-family ubuntu-2404-lts
    raw step 02
    gcloud compute instances describe lab-db-gcp-01 --zone us-central1-a
  2. 02
    Create the dedicated PostgreSQL data disk for the GCP lane.
    show raw commands
    selected command
    lab gcp create db-disk
    raw step 01
    gcloud compute disks create lab-db-gcp-data-01 --size 12GB --zone us-central1-a
    raw step 02
    gcloud compute disks list --filter=name:lab-db-gcp-data-01
  3. 03
    Attach the dedicated data disk to the GCP database VM before guest prep starts.
    show raw commands
    selected command
    lab gcp attach db-disk
    raw step 01
    gcloud compute instances attach-disk lab-db-gcp-01 --disk lab-db-gcp-data-01 --zone us-central1-a
    raw step 02
    gcloud compute instances describe lab-db-gcp-01 --zone us-central1-a
  4. 04
    Estimate today’s GCP VM and disk cost from the live footprint before guest prep begins.
    show raw commands
    selected command
    lab gcp approx cost today
    raw step 01
    estimateGcpVmCostToday(machineType, elapsedHours) = hourlyRate(machineType) * elapsedHours
    raw step 02
    estimateGcpDiskCostToday(type, sizeGiB, elapsedHours) = monthlyRate(type) * sizeGiB * elapsedHours / 730
>
phase 033. Prepare GCP database hostlive

Use live GCP workstream checks to stage guest preparation, inspect the dedicated disk, and verify the database host.

3 cmds
  1. 01
    Stage the GCP guest-prep workflow so the host advertises how PostgreSQL and disk prep should proceed.
    show raw commands
    selected command
    lab gcp prepare db-host
    raw step 01
    gcloud compute ssh lab-db-gcp-01 --zone us-central1-a --command 'sudo apt-get update && sudo apt-get install -y postgresql postgresql-contrib'
  2. 02
    Confirm the dedicated disk exists and is attached before trusting any guest-prep state.
    show raw commands
    selected command
    lab gcp inspect db-disk
    raw step 01
    gcloud compute disks list --filter=name:lab-db-gcp-data-01
    raw step 02
    gcloud compute instances describe lab-db-gcp-01 --zone us-central1-a
  3. 03
    Verify the GCP VM, disk attach state, and modeled guest prep state before migration begins.
    show raw commands
    selected command
    lab gcp verify db-host
    raw step 01
    gcloud compute instances describe lab-db-gcp-01 --zone us-central1-a
>
phase 044. Migrate VCF database to GCPlive

Keep the same export and restore structure visible so GCP stays comparable to AWS and Azure.

4 cmds
  1. 01
    Export the PostgreSQL rows from the VCF-backed Traditional Workloads database and upload the artifact to the GCP guest.
    show raw commands
    selected command
    lab gcp upload dump
    raw step 01
    lab db export --target-file migration-notes.sql
    raw step 02
    scp migration-notes.sql <gcp-host>:/tmp/migration-notes.csv
  2. 02
    Apply the uploaded migration artifact into the GCP PostgreSQL guest.
    show raw commands
    selected command
    lab gcp restore into gcp
    raw step 01
    sudo -u postgres psql -d labapp -f /tmp/migration-notes.csv
  3. 03
    Review the exact GCP-side workstream status and transfer order before attempting any real upload or restore.
    show raw commands
    selected command
    lab gcp migration status
  4. 04
    Run one aggregated readiness check that reports VM state, disk attach, and migration prerequisites for the GCP target.
    show raw commands
    selected command
    lab gcp verify migration-ready
>
phase 055. Migrate GCP database back to VCFlive

Keep the return path explicit so the GCP lane remains reversible and comparable to the other clouds.

4 cmds
  1. 01
    Keep the GCP return order visible without pretending the reverse transfer is fully automated yet.
    show raw commands
    selected command
    lab gcp migration status
  2. 02
    Create the GCP-side backhaul artifact from the live guest database.
    show raw commands
    selected command
    lab gcp dump db
    raw step 01
    sudo -u postgres pg_dump labapp > /tmp/labapp-backhaul.csv
  3. 03
    Restore the GCP export back into the VCF PostgreSQL lab instance.
    show raw commands
    selected command
    lab gcp restore into vcf
    raw step 01
    lab db import --source-file labapp-backhaul.csv
  4. 04
    Read back the latest rows on the VCF side after the return migration completes.
    show raw commands
    selected command
    lab db recent
>
phase 066. Audit spend and clean up GCPlive

End the GCP chapter by checking unattached disks, same-day cost, and then deleting the LAB-scoped GCP resources explicitly.

3 cmds
  1. 01
    Check for idle reserved addresses before teardown so public-IP spend does not linger unnoticed.
    show raw commands
    selected command
    lab gcp reserved addresses
  2. 02
    Read the same-day spend approximation before cleanup so the session footprint is visible.
    show raw commands
    selected command
    lab gcp approx cost today
  3. 03
    Delete the LAB GCP VM, disk, and matching reserved addresses in the configured project.
    show raw commands
    selected command
    lab gcp kill all lab resources
    raw step 01
    gcloud compute instances delete lab-db-gcp-01 --zone us-central1-a --quiet
    raw step 02
    gcloud compute disks delete lab-db-gcp-data-01 --zone us-central1-a --quiet
    raw step 03
    gcloud compute addresses delete <lab-address> --region us-central1 --quiet
live terminalgcp@lab

GCP terminal

Live route

command lineidle
gcp@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

GCP

history buffer

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