Nautobot Source of Truth: Docker Deployment Guide

A network source of truth earns its keep when automation reads from it instead of from a spreadsheet. Nautobot is the Network-to-Code fork of NetBox with a stronger plugin and job framework, which makes it attractive when you want the source of truth to also generate configuration or run validation. This guide deploys Nautobot with Docker Compose, populates a minimal dataset, and sets out the practical differences that decide between Nautobot and NetBox.

Deployment options

Nautobot requires PostgreSQL and Redis; Docker Compose provisions both.

Step 1: bring up the stack

git clone https://github.com/nautobot/nautobot-docker-compose.git
cd nautobot-docker-compose
cp environments/creds.env.example environments/creds.env
# edit creds.env: SUPERUSER_PASSWORD, NAUTOBOT_SECRET_KEY, DB password
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f nautobot | tail -20

The web UI appears on port 8080 (or 8443 for TLS) once the initial migration completes. Sign in as the superuser created from creds.env.

Step 2: model the network

Organization > Locations        -> create "HQ-DC1" (type: Data Center, parent: HQ)
Organization > Manufacturers    -> Cisco, Juniper, Arista, Huawei
Devices > Device Types          -> C9300-48P (48 interfaces), EX4400-48F
Devices > Platforms             -> ios-xe, junos, eos
Devices > Devices               -> core-sw1 (location HQ-DC1, role: Core, platform ios-xe)
IPAM > Prefixes                 -> 10.10.10.0/24 (status: Active)
IPAM > VLANs                    -> VLAN 10 "Users"
Devices > Interfaces            -> GigabitEthernet1/0/1 (type: 1000base-t, mode: Access, untagged VLAN 10)

Two modelling habits pay off later: assign a role to every device (core, distribution, access, edge) so queries can filter, and put the management IP on the correct interface rather than a free-text primary IP, so reachability tooling has a target.

Step 3: consume it from automation

curl -s -H "Authorization: Token $NAUTOBOT_TOKEN" \
  "https://nautobot.example.net/api/dcim/devices/?role=core&limit=100" | jq '.results[] | {name, platform: .platform.name}'

# GraphQL is usually a better fit for structured inventory
curl -s -X POST -H "Authorization: Token $NAUTOBOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"query":"{ devices(role: \"core\") { name platform { name } primary_ip4 { address } } }"}' \
  https://nautobot.example.net/api/graphql/ | jq

Nautobot or NetBox?

• Choose Nautobot when you want Jobs and plugins to run inside the platform, when configuration generation lives in the source of truth, or when you need features such as the Golden Config and Device Lifecycle apps.
• Choose NetBox when you want a mature, widely supported DCIM/IPAM with a very large integration ecosystem and no custom job framework.
• Either way, keep the API token scoped and read-only for monitoring tools, and treat the database as authoritative — any manual change outside the UI/API should be rejected in review.

Related reading: NetBox IPAM: prefixes, VLANs and IP addresses, Nornir network automation inventory and tasks, and Network configuration backup with Oxidized.

原文链接：https://docs.nautobot.com/projects/core/en/stable/user-guide/administration/installation/