Většina automatizačních projektů ztroskotá na jediné, banální věci: nikdo přesně neví, co v síti a serverovně reálně běží. IP adresy v Excelu, zapojení v hlavě jednoho admina, dokumentace stará dva roky. Bez zdroje pravdy je automatizace stavění na písku. NetBox to mění.
Co NetBox je
NetBox je open-source nástroj pro IPAM (správa IP adresního prostoru) a DCIM (evidence vybavení datového centra). Jednoduše: jediné místo, kde je zapsáno, co máte, kde to je, jak je to zapojené a jaké to má adresy. Od racku přes kabeláž a VLAN až po virtuální stroje a cloud.
Automatizace je jen tak dobrá, jak dobrá jsou data, ze kterých vychází. NetBox je ten zdroj dat.
Proč je to základ automatizace
Když Ansible nebo Terraform nasazují změnu, potřebují vědět: na který server, do které VLAN, s jakou IP. Pokud tato data tahají z Excelu nebo z hlavy, automatizace je křehká a nedůvěryhodná. NetBox jako single source of truth tohle řeší — playbooky čtou pravdu z API, ne z domněnek.
- Network-as-code — konfigurace sítě se generuje z NetBoxu, ne ručně.
- Provisioning — nový server dostane IP a VLAN automaticky podle pravidel.
- Audit a compliance — kdykoliv víte, co máte. Pro NIS2 i interní audit zásadní.
Reality check
- NetBox je tak dobrý, jak dobře ho plníte. Prvotní naplnění reálným stavem je práce — ale jednorázová a klíčová.
- Není to monitoring. NetBox říká, co má být. Co reálně běží, hlídá Zabbix nebo Logmanager. Spolu tvoří kompletní obraz.
- Integrace se vyplatí. Skutečná síla je v napojení na Ansible, Terraform a CMDB — pak je NetBox srdcem automatizace.
Jak to nasazujeme
Začínáme discovery — sken reálného stavu a jeho import do NetBoxu. Pak napojíme automatizační pipeline (Red Hat Ansible Automation Platform), aby NetBox byl zdroj i cíl. Výsledek: jedno místo pravdy, ze kterého teče celá automatizace.
# NetBox jako zdroj pravdy — konfigurace se generuje z dat, ne ručně
- name: Vygeneruj konfigurace switchů přímo z NetBoxu
hosts: localhost
connection: local
tasks:
- name: Načti aktivní core switche z NetBoxu
ansible.builtin.set_fact:
netbox_devices: "{{ query('netbox.netbox.nb_lookup', 'devices',
api_endpoint='https://netbox.internal',
api_filter='status=active role=core-switch') }}"
- name: Vyrenderuj konfiguraci z šablony + dat
ansible.builtin.template:
src: switch.cfg.j2 # jedna šablona, data z NetBoxu
dest: "configs/{{ item.value.name }}.cfg"
loop: "{{ netbox_devices }}"
- name: Ověř, že každé zařízení má přidělenou IP
ansible.builtin.assert:
that: item.value.primary_ip4 is not none # chybějící IP = chyba v evidenci, ne v produkci
loop: "{{ netbox_devices }}"Klíčový bod: NetBox je zdroj i cíl — automatizace z něj čte a zpět do něj zapisuje reálný stav. Žádný Excel. Lookup plugin viz NetBox docs.
Provisioning nového racku (40 zařízení) trval 3 dny ručního dohledávání IP a VLAN v tabulkách. S NetBoxem jako zdrojem pravdy: 4 hodiny, nula konfliktů IP adres. Ilustrativní hodnoty — ověřte před publikací.
Časté otázky
Jak dostaneme reálný stav do NetBoxu, když máme bordel v Excelu?
Discovery. Naskenujeme reálnou síť a servery, výsledek importujeme do NetBoxu a porovnáme s Excelem — rozdíly bývají překvapivé. Od té chvíle je NetBox zdroj pravdy a Excel jde do archivu.
Co když NetBox a realita se rozejdou?
Proto NetBox používáme jako zdroj i cíl — automatizace pravidelně ověřuje, že realita odpovídá NetBoxu, a hlásí drift. Zařízení, které není v NetBoxu, je buď chyba, nebo neautorizovaná změna.
Funguje to i pro virtuální a cloudovou infrastrukturu?
Ano. NetBox modeluje fyzická i virtuální zařízení, IP prostor, VLANy a propojení napříč on-prem i cloudem. Je vendor-neutrální, takže nesvazuje s jedním výrobcem.
Jak NetBox zapadá do zbytku automatizace?
Je to základ. F5 konfigurace, Zabbix monitoring i provisioning serverů čtou cílový stav z NetBoxu. Jeden zdroj, mnoho konzumentů.
Máte stav sítě v Excelu?
Naplánujte si 20minutový call — ukážeme vám, jak z chaosu udělat jeden zdroj pravdy a co to znamená pro vaši automatizaci. Bez sales pitche.
Naplánovat 20-min call →