Post-Tyranny-Tech-Infrastru.../scripts
Pieter 0c4d536246 feat: Add version tracking and maintenance monitoring (issue #15)
Complete implementation of automatic version tracking and drift detection:

New Scripts:
- scripts/collect-client-versions.sh: Query deployed versions from Docker
  - Connects via Ansible to running servers
  - Extracts versions from container images
  - Updates registry automatically

- scripts/check-client-versions.sh: Compare versions across clients
  - Multiple formats: table (colorized), CSV, JSON
  - Filter by outdated versions
  - Highlights drift with color coding

- scripts/detect-version-drift.sh: Identify version differences
  - Detects clients with outdated versions
  - Threshold-based staleness detection (default 30 days)
  - Actionable recommendations
  - Exit code 1 if drift detected (CI/monitoring friendly)

Updated Scripts:
- scripts/deploy-client.sh: Auto-collect versions after deployment
- scripts/rebuild-client.sh: Auto-collect versions after rebuild

Documentation:
- docs/maintenance-tracking.md: Complete maintenance guide
  - Version management workflows
  - Security update procedures
  - Monitoring integration examples
  - Troubleshooting guide

Features:
 Automatic version collection from deployed servers
 Multi-client version comparison reports
 Version drift detection with recommendations
 Integration with deployment workflows
 Export to CSV/JSON for external tools
 Canary-first update workflow support

Usage Examples:
```bash
# Collect versions
./scripts/collect-client-versions.sh dev

# Compare all clients
./scripts/check-client-versions.sh

# Detect drift
./scripts/detect-version-drift.sh

# Export for monitoring
./scripts/check-client-versions.sh --format=json
```

Closes #15

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2026-01-17 20:53:15 +01:00
..
check-client-versions.sh feat: Add version tracking and maintenance monitoring (issue #15) 2026-01-17 20:53:15 +01:00
client-status.sh feat: Implement client registry system (issue #12) 2026-01-17 20:24:53 +01:00
collect-client-versions.sh feat: Add version tracking and maintenance monitoring (issue #15) 2026-01-17 20:53:15 +01:00
deploy-client.sh feat: Add version tracking and maintenance monitoring (issue #15) 2026-01-17 20:53:15 +01:00
destroy-client.sh feat: Implement client registry system (issue #12) 2026-01-17 20:24:53 +01:00
detect-version-drift.sh feat: Add version tracking and maintenance monitoring (issue #15) 2026-01-17 20:53:15 +01:00
generate-client-keys.sh feat: Implement per-client SSH key isolation 2026-01-17 19:50:30 +01:00
list-clients.sh feat: Implement client registry system (issue #12) 2026-01-17 20:24:53 +01:00
README.md feat: Automate SSH key and secrets generation in deployment scripts 2026-01-17 20:04:29 +01:00
rebuild-client.sh feat: Add version tracking and maintenance monitoring (issue #15) 2026-01-17 20:53:15 +01:00
update-registry.sh feat: Implement client registry system (issue #12) 2026-01-17 20:24:53 +01:00

Management Scripts

Automated scripts for managing client infrastructure.

Prerequisites

Set required environment variables:

export HCLOUD_TOKEN="your-hetzner-cloud-api-token"
export SOPS_AGE_KEY_FILE="./keys/age-key.txt"

Scripts

1. Deploy Fresh Client

Purpose: Deploy a brand new client from scratch

Usage:

./scripts/deploy-client.sh <client_name>

What it does (automatically):

  1. Generates SSH key (if missing) - Unique per-client key pair
  2. Creates secrets file (if missing) - From template, opens in editor
  3. Provisions VPS server (if not exists)
  4. Sets up base system (Docker, Traefik)
  5. Deploys Authentik + Nextcloud
  6. Configures SSO integration automatically

Time: ~10-15 minutes

Example:

# Just run the script - it handles everything!
./scripts/deploy-client.sh newclient

# Script will:
# 1. Generate keys/ssh/newclient + keys/ssh/newclient.pub
# 2. Copy secrets/clients/template.sops.yaml → secrets/clients/newclient.sops.yaml
# 3. Open SOPS editor for you to customize secrets
# 4. Continue with deployment

Requirements:

  • Client must be defined in tofu/terraform.tfvars
  • Environment variables: HCLOUD_TOKEN, SOPS_AGE_KEY_FILE (optional)

2. Rebuild Client

Purpose: Destroy and recreate a client's infrastructure from scratch

Usage:

./scripts/rebuild-client.sh <client_name>

What it does:

  1. Destroys existing infrastructure (asks for confirmation)
  2. Provisions new VPS server
  3. Sets up base system
  4. Deploys applications
  5. Configures SSO

Time: ~10-15 minutes

Example:

./scripts/rebuild-client.sh test

Warning: This is destructive - all data on the server will be lost!


3. Destroy Client

Purpose: Completely remove a client's infrastructure

Usage:

./scripts/destroy-client.sh <client_name>

What it does:

  1. Stops and removes all Docker containers
  2. Removes all Docker volumes
  3. Destroys VPS server via OpenTofu
  4. Removes DNS records

Time: ~2-3 minutes

Example:

./scripts/destroy-client.sh test

Warning: This is destructive and irreversible! All data will be lost.

Note: Secrets file is preserved after destruction.


Workflow Examples

Deploy a New Client (Fully Automated)

# 1. Add to terraform.tfvars
vim tofu/terraform.tfvars
# Add:
#   newclient = {
#     server_type = "cx22"
#     location    = "fsn1"
#     subdomain   = "newclient"
#     apps        = ["authentik", "nextcloud"]
#   }

# 2. Deploy (script handles SSH key + secrets automatically)
./scripts/deploy-client.sh newclient

# That's it! Script will:
# - Generate SSH key if missing
# - Create secrets file from template if missing (opens editor)
# - Deploy everything

Test Changes (Rebuild)

# Make changes to Ansible roles/playbooks

# Test by rebuilding
./scripts/rebuild-client.sh test

# Verify changes worked

Clean Up

# Remove test infrastructure
./scripts/destroy-client.sh test

Script Output

All scripts provide:

  • ✓ Colored output (green = success, yellow = warning, red = error)
  • Progress indicators for each step
  • Total time taken
  • Service URLs and credentials
  • Next steps guidance

Error Handling

Scripts will exit if:

  • Required environment variables not set
  • Secrets file doesn't exist
  • Confirmation not provided (for destructive operations)
  • Any command fails (set -e)

Safety Features

Destroy Script

  • Requires typing client name to confirm
  • Shows what will be deleted
  • Preserves secrets file

Rebuild Script

  • Asks for confirmation before destroying
  • 10-second delay after destroy before rebuilding
  • Shows existing infrastructure before proceeding

Deploy Script

  • Checks for existing infrastructure
  • Skips provisioning if server exists
  • Validates secrets file exists

Integration with CI/CD

These scripts can be used in automation:

# Non-interactive deployment
export HCLOUD_TOKEN="..."
export SOPS_AGE_KEY_FILE="..."

./scripts/deploy-client.sh production

For rebuild (skip confirmation):

# Modify rebuild-client.sh to accept --yes flag
./scripts/rebuild-client.sh production --yes

Troubleshooting

Script fails with "HCLOUD_TOKEN not set"

export HCLOUD_TOKEN="your-token-here"

Script fails with "Secrets file not found"

Create the secrets file:

cp secrets/clients/test.sops.yaml secrets/clients/<client>.sops.yaml
sops secrets/clients/<client>.sops.yaml

Server not reachable during destroy

This is normal if server is already destroyed. The script will skip Docker cleanup and proceed to OpenTofu destroy.

OpenTofu state conflicts

If multiple people are managing infrastructure:

cd tofu
tofu state pull
tofu state push

Consider using remote state (S3, Terraform Cloud, etc.)

Performance

Typical timings:

Operation Time
Deploy fresh 10-15 min
Rebuild 10-15 min
Destroy 2-3 min

Breakdown:

  • Infrastructure provisioning: 2 min
  • Server initialization: 1 min
  • Base system setup: 3 min
  • Application deployment: 5-7 min

See Also