MikroTik – kompleksowa konfiguracja sieci od podstaw do zaawansowanych rozwiązań

Część 20: CI/CD dla infrastruktury MikroTik – GitLab, NetBox i Ansible w praktyce

W poprzedniej części poznaliśmy sposób integracji MikroTik z NetBox oraz użycie Ansible do automatycznej konfiguracji urządzeń. W tej części pójdziemy jeszcze dalej — przedstawimy, jak zbudować pełny pipeline CI/CD (Continuous Integration / Continuous Deployment) dla infrastruktury sieciowej z wykorzystaniem GitLab CI, NetBox i Ansible. Zapewni to nie tylko powtarzalność, ale i kontrolę wersji, automatyczny audyt oraz możliwość błyskawicznego rollbacku konfiguracji w razie awarii.

Dlaczego CI/CD w sieciach?

CI/CD to podejście znane z programowania, jednak coraz częściej stosowane także w infrastrukturze (Infrastructure as Code). Dla administratorów MikroTik oznacza to m.in.:

• testowanie konfiguracji przed wdrożeniem (linting, syntax check),
• audyt i logowanie wszystkich zmian,
• wersjonowanie konfiguracji,
• automatyczne deploymenty i rollbacki,
• skalowanie zarządzania konfiguracją w większych środowiskach.

Komponenty rozwiązania

Aby zbudować CI/CD dla infrastruktury MikroTik, potrzebujemy:

• GitLab CE lub GitLab Cloud jako repozytorium kodu i system CI,
• Ansible z pluginami do MikroTik,
• NetBox jako źródła danych,
• Runner GitLab – najlepiej własny, uruchamiany lokalnie lub w kontenerze,
• SSH/API dostępu do MikroTik – najlepiej przez klucz z ograniczonymi uprawnieniami.

Struktura projektu Git

Przykładowa struktura repozytorium:

mikrotik-configs/
│
├── group_vars/
│   └── all.yml
├── host_vars/
│   └── rb4011-1.yml
│
├── inventories/
│   └── netbox.yml
│
├── playbooks/
│   └── deploy.yml
│   └── check.yml
│   └── backup.yml
│
├── roles/
│   └── common/
│       └── tasks/
│           └── main.yml
│
├── .gitlab-ci.yml
└── README.md

Przykładowy plik .gitlab-ci.yml

stages:
  - validate
  - plan
  - apply
  - audit

validate_yaml:
  stage: validate
  image: python:3.10
  script:
    - pip install yamllint
    - yamllint .
  only:
    - merge_requests

plan_config:
  stage: plan
  image: debian:bullseye
  script:
    - apt-get update && apt-get install -y ansible
    - ansible-playbook playbooks/check.yml --check
  only:
    - merge_requests

apply_config:
  stage: apply
  image: debian:bullseye
  script:
    - ansible-playbook playbooks/deploy.yml
  only:
    - main

backup_config:
  stage: audit
  image: debian:bullseye
  script:
    - ansible-playbook playbooks/backup.yml
  only:
    - main

Automatyczny rollback i bezpieczeństwo

Zarządzanie konfiguracją powinno być nie tylko zautomatyzowane, ale i bezpieczne. Dlatego:

1. Twórz kopię zapasową konfiguracji przed każdą zmianą (export, system backup save).
2. Użyj NetBox do wykrywania odchyleń między stanem aktualnym a pożądanym.
3. W przypadku błędów deploymentu wycofaj zmiany automatycznie – np. przez pre-tasks w Ansible.
4. Monitoruj wszystkie zmiany – logi CI/CD, Git history i monitoring z Grafany.

Przykład workflow

1. Administrator edytuje konfigurację w host_vars/rb4011-1.yml.
2. Tworzy Merge Request, który uruchamia pipeline:
   • waliduje YAML,
   • wykonuje dry-run --check,
   • sprawdza poprawność logiczną.
3. Po zatwierdzeniu MR pipeline aplikuje konfigurację.
4. Następnie tworzy backup i raportuje status wdrożenia.

Integracja z NetBox i webhooki

Aby automatyzacja była pełna:

• użyj webhooków NetBox do uruchamiania pipeline po każdej zmianie,
• synchronizuj dane z NetBox (VLANy, adresy IP, role) do zmiennych Ansible,
• użyj pynetbox do pobierania dynamicznych danych w inventory.

Przykład webhooka:

{
  "url": "https://gitlab.example.com/api/v4/projects/1234/trigger/pipeline",
  "method": "POST",
  "headers": {
    "Content-Type": "application/json",
    "PRIVATE-TOKEN": "xxx"
  },
  "body": {
    "ref": "main"
  }
}

Audyt i compliance

Z CI/CD łatwo wdrożyć polityki bezpieczeństwa:

• sprawdzenie, czy w konfiguracji nie pojawiają się nieautoryzowane adresy IP,
• wykrywanie niedozwolonych usług lub portów otwartych na firewallu,
• kontrola zgodności wersji RouterOS.

Możesz użyć zewnętrznego audytora (np. OpenSCAP, Lynis) lub własnych ról Ansible.

Podsumowanie

Wdrożenie GitLab CI/CD do zarządzania MikroTikami to naturalny krok w stronę nowoczesnej automatyzacji i DevNetOps. Dzięki pełnej integracji z NetBox i Ansible można osiągnąć wysoki poziom automatyzacji, bezpieczeństwa i skalowalności – przy jednoczesnym zachowaniu kontroli nad każdą zmianą.

W kolejnej części pokażemy, jak zbudować system monitoringu stanu urządzeń MikroTik z wykorzystaniem Prometheus + Grafana + SNMP i zautomatyzować reakcję na zdarzenia z użyciem Alertmanagera.

Polecane wpisy

Jak działa ND Proxy na MikroTik dla IPv6?

Jak działa ND Proxy na MikroTik dla IPv6? 🌐 Wprowadzenie IPv6 znacząco różni się od IPv4 nie tylko pod względem Czytaj dalej

Konfiguracja MikroTik — Część 80: MikroTik + SNMP — Monitorowanie sieci i urządzeń

Konfiguracja MikroTik — Część 80: MikroTik + SNMP — Monitorowanie sieci i urządzeń Wprowadzenie Współczesne sieci, zarówno lokalne, jak i Czytaj dalej