Lesson 3: Server Fleet Management

Hands On FullStack Development Course with Infrastructure Management Product implementation ~7 min read 60 min hands-on

Lesson 3: Server Fleet Management

Hands-On Full Stack Development with Infrastructure Management

What We Are Building

This lesson delivers a production-grade server fleet control plane for InfraWatch:

  1. Inventory domain — Rich server models with lifecycle state, health telemetry, tags, dependencies, and audit history

  2. Operations API — CRUD with pagination, soft-delete, advanced search, bulk actions, groups, and templates

  3. Validation layer — IP/hostname checks, TCP connectivity, HTTP health, SSL expiry, and network discovery

  4. Credential plane — SSH key generation, encrypted storage, rotation, and connection testing

  5. Live console — Datadog-style React dashboard with real-time WebSocket health updates

Core Concept: Inventory as the Source of Truth

Every metrics pipeline, alert rule, and automation workflow in a platform like Datadog or PagerDuty starts with one question: which servers exist right now, and are they reachable? Server inventory is not a spreadsheet—it is the authoritative graph that downstream systems query before they act.

The insight most tutorials skip: lifecycle state and health state are different axes. A server can be active in provisioning terms but degraded in health terms. Mixing them into one status field breaks autoscaling logic (which cares about lifecycle) and paging logic (which cares about health). InfraWatch Fleet keeps both dimensions explicit.

Where This Fits in the Overall System

Code

You are building the inventory spine that metrics agents attach to and alert engines evaluate against. Without it, alerts fire on hostnames nobody registered—or worse, on hosts that were decommissioned last week.

Component Architecture

Presentation — Dark-theme React console: fleet overview metrics, searchable inventory grid, validation tools, credential manager. Polls REST every 15 seconds; WebSocket pushes health deltas instantly.

API — Flask blueprints under /api/v1. Thin routes delegate to services: server_service, health_service, ssh_service, bulk_service.

State — PostgreSQL stores servers, tags, groups, templates, audit logs, SSH keys. Redis caches health snapshots and increments check counters.

Runtime — Background health monitor runs every 30 seconds. Docker Compose orchestrates Postgres 16, Redis 7, API, and UI.

Control and Data Flow

Create path: form → POST /api/v1/servers/ → validate fields → persist → audit log → WebSocket server_created → dashboard refresh.

Health path: scheduler → TCP/HTTP/SSL probes → update server metrics → write HealthCheck row → Redis cache → WebSocket health_update → metric cards and CPU bars animate.

Server State Machine

Lifecycle transitions: unknown → provisioning → active → draining → decommissioned (soft delete). Health transitions run in parallel: unknown → healthy / degraded / failed / offline.

Success Criteria

You have succeeded when:

  • ./build.sh test passes backend and frontend suites

  • Dashboard shows non-zero server count and health percentages after seed

  • Manual health check updates CPU/memory bars within seconds

  • WebSocket indicator shows Live when backend is running

  • Bulk health-check processes multiple servers and updates metrics

Assignment

Keep going with the full lesson

The rest of this lesson — plus its implementation guide, runnable scripts and source code — is included with the course or an All Access plan. Create a free account to start the free lessons in every course.

Unlock the full lesson Create free account

Already a member? Sign in