Building a Network Source of Truth: Ingesting Production Data into a Local Containerized Nautobot Stack
How I decoupled configurations using a multi-file Docker Compose architecture on WSL2 to replicate live Data Center footprints offline. Managing network inventories, IP allocations, and physical device mappings across spreadsheets is a foundational trap for configuration drift. In contemporary NetDevOps, automation frameworks depend strictly on a reliable, dynamic Source of Truth. To bridge the gap between production safe-keeping and dev-testing, I built a containerized infrastructure simulation. This guide outlines the execution framework for cloning the open-source Nautobot repository blueprint, deploying a localized cluster via decoupled Docker Compose configuration files on WSL2, and restoring a full raw SQL database backup from a production Data Center footprint (Mumbai-DC).
The Core Technical Architecture
Instead of handling a standard monolithic setup, the architecture is decoupled into a distributed microservices environment using Docker containers managed as a collective stack. The architecture consists of:
db-1(PostgreSQL 13): The underlying persistent engine housing our data tables.redis-1: An in-memory cache layer to reduce application overhead.celery_worker&celery_beat-1: Dynamic asynchronous execution engines to process automation jobs without impacting the frontend.nautobot-1: The core web server handling application routing, exposed on local port8080:8080.
Step-by-Step Implementation Flow
1. Preparing System Prerequisites
Before initializing any Docker configurations, ensure that your WSL2 backend and target virtualization layer are aligned:
Confirm your Linux distribution is operating on WSL Version 2:
wsl -l -vNavigate to your Docker Desktop Settings -> Resources -> WSL Integration, and toggle your local Ubuntu target to ON.
2. Bootstrapping the Infrastructure
Clone your fork of the Nautobot community framework locally and spin up the environment components by dynamically merging the necessary environment configurations:
docker compose -f docker-compose.base.yml -f docker-compose.postgres.yml -f docker-compose.local.yml up -d
Note: Using a dedicated docker-compose.local.yml layer allows us to seamlessly inject host-to-container port assignments (8080:8080) without manipulating core upstream configuration files.
Always validate container health checks before attempting application orchestration:
docker ps
Ensure your target database flags read healthy before jumping into the migration phase.
The Migration Strategy (Production Data Ingestion)
When injecting a raw .sql dataset from a production asset tier, legacy system data schemas often conflict with the initial setup hooks of a fresh installation. To resolve constraint collisions during my migration workflow, I followed this precise sequence:
A. Database Purge and Initial Prep
Access the running Postgres container instances directly via interactive CLI execution and drop the default placeholder state:
docker exec -it environments-db-1 psql -U nautobot -d postgres -c "DROP DATABASE nautobot;"
docker exec -it environments-db-1 psql -U nautobot -d postgres -c "CREATE DATABASE nautobot;"
B. Ingesting the Production Footprint
Copy your raw Data Center backup file (my_nautobot_backup.sql) straight into the container environment and pipe the contents directly into our fresh structural database instance:
docker cp my_nautobot_backup.sql environments-db-1:/tmp/backup.sql
docker exec -t environments-db-1 psql -U nautobot -d nautobot -f /tmp/backup.sql
C. Application Layer Synchronization
With structural rows in place, execute schema sync tasks within the core application runtime environment to align legacy structural rows with the running web engine dependencies:
docker exec -it environments-nautobot-1 nautobot-server migrate
docker exec -it environments-nautobot-1 nautobot-server post_upgrade
Finally, bounce the stack or restart your application container to load the freshly integrated assets cleanly:
docker restart environments-nautobot-1
Verifying the Infrastructure Blueprint
Once initialized, firing up http://localhost:8080 drops us into an offline, responsive replica of our production data tier. I verified this migration by establishing structural mappings within the web console UI:
Organization Topology: Configured tenant scopes and designated local site mappings (
Mumbai-DC-01) targeting explicit Data Center location parameters.DCIM Layering: Populated global inventory systems, allocating custom Manufacturers (
Dell), specifying physical Device Types (PowerEdge R740), and assigning operational hardware identities (Web-Server).IPAM Management: Generated live Prefix blocks (
192.168.1.0/24) and mapped individual live interface nodes (eth00) straight to definitive active IP Address assignments (192.168.1.10).
Conclusion: The NetDevOps Advantage
By constructing a fully offline containerized mirror of live production state data on a local computer, network engineers can easily test automated routines without risking unintended production downtime. This local setup serves as the master orchestration baseline. Programmatic frameworks like Ansible playbooks, Terraform scripts, or Python Netmiko routines can now interact directly with this local database repository, treating it as the singular Source of Truth to validate configuration templates before committing code to global operational environments.