RouterOS API ile Toplu MikroTik Cihaz Yönetimi: Sahadan Mimari Notları

Kısa cevap: Onlarca cihazı elle tek tek yönetebilirsiniz; yüzlerce ya da binlerce cihazda bu imkânsız hale gelir. Ölçekte doğru yol RouterOS API’si üzerinden, yapılandırılmış veriyle çalışan, iş kuyruğuna dayalı ve idempotent bir otomasyon kurmaktır. Binary API metin tabanlı SSH’a göre hem hızlı hem ayrıştırması güvenlidir.

Bu içerik ürün tanıtımı değil; benzer bir sistem kuracak mühendislere yol haritası ve MikroTik altyapısını dışarıya yönettirmeyi düşünen kurumlara “bu işin altında ne var” cevabıdır. MikroTik’e yeni başlıyorsanız önce MikroTik nedir rehberini okumanızı öneririz.

RouterOS’u programatik yönetmenin yolları: API, SSH ve REST

RouterOS’a dışarıdan üç yoldan otomasyon uygulanabilir; ölçekte tercih nettir:

• Binary API (8728 / api-ssl 8729): RouterOS’un kendi ikili protokolü. Komutlar ve dönen kayıtlar yapılandırılmıştır; yani interface, ip address, firewall filter gibi menülerden alan-değer çiftleri olarak veri alırsınız, metin parse etmezsiniz. Toplu yönetimin doğru katmanı budur.
• REST API (v7, HTTP/HTTPS): RouterOS 7 ile geldi, JSON döner. Basit entegrasyonlar için pratiktir; biz binary API’yi tercih ettik çünkü v6 cihazları da desteklememiz ve tek bir istemci soyutlamasında kalmamız gerekiyordu (REST yalnızca v7’de var).
• SSH: En esnek ama en kırılgan yol: çıktı serbest metindir, sürümden sürüme değişir, parse etmek zahmetlidir. SSH’ı yalnızca API’nin karşılamadığı dar işler için tutuyoruz (bkz. aşağıdaki /export bölümü).

Kararımız: birincil yöntem binary API, ikincil ve dar amaçlı yöntem SSH. Python tarafında bunu librouteros kütüphanesiyle yapıyoruz; olgun, protokolü doğru uygulayan ve binary API’nin login akışını sizin yerinize halleden bir istemci.

Yüzlerce cihaza aynı anda komut göndermek: iş kuyruğu mimarisi

En sık yapılan hata, “bin cihaz varsa bin bağlantıyı aynı anda açayım” refleksidir. Bu, tek bir sunucuyu ve ağ yığınını hızla dize getirir; üstelik tek yavaş cihaz bütün süreci bekletir. Ölçekte çalışan desen farklıdır:

1. Fan-out: Toplu bir işlem (ör. “tüm cihazların yedeğini al”) tetiklendiğinde, her cihaz için ayrı bir iş üretilir.
2. Öncelikli kuyruk: Bu işler bir Redis kuyruğuna yazılır. Farklı iş tipleri farklı önceliklerde tutulur; acil bir reconcile, rutin bir monitoring taramasının önüne geçer.
3. Yatay worker ölçekleme: Kuyruğu, birbirinden bağımsız çok sayıda worker process’i paralel tüketir. Paralellik derecesini artırmak, tek bir dev döngüyü hızlandırmakla değil, worker replika sayısını artırmakla olur. Bu, sistemi Docker/Kubernetes’te doğal olarak yatay ölçeklenebilir yapar.

Bu mimarinin üç kritik güvencesi var:

• Reliable queue (ACK/NACK): İş alınınca “işleniyor” olarak işaretlenir. Worker çökerse, iş belirli bir süre sonra otomatik olarak kuyruğa geri döner; hiçbir cihaz sessizce atlanmaz.
• Cihaz başına dağıtık kilit: Her cihaz için Redis’te bir kilit (lock:device:<id>) alınır. Böylece aynı MikroTik’e iki worker aynı anda yapılandırma yazamaz. Kilit alınamazsa iş kısa bir exponential backoff ile (5 → 10 → 20 → 40 sn) tekrar denenir.
• Circuit breaker: Kapalı ya da erişilemeyen bir cihaza her seferinde boşuna bağlanmaya çalışmak, hem zaman hem kuyruk israfıdır. Üst üste belirli sayıda (bizde 3) bağlantı hatasından sonra o cihaz için “devre açılır” ve bir soğuma süresi (5 dk) boyunca denenmez. Cihaz geri geldiğinde devre otomatik kapanır.

Dürüst bir sınır: Her toplu iş “gerçek fan-out” değildir. Örneğin binlerce cihazlık bir health-check’i tek bir iş olarak kuyruğa koyup worker’ın içinde sırayla dönmek de mümkündür; bu basit ama seridir. Gerçek paralellik, işi cihaz başına parçaladığınızda ortaya çıkar. Hangi işin fan-out, hangisinin seri olacağı bilinçli bir tasarım kararıdır.

Bu tür bir merkezi yönetim, izleme katmanıyla birlikte anlam kazanır; biz envanteri Zabbix ile ağ izleme tarafına da bağlıyoruz. Çok şubeli ve ISP tipi yapılar için ISP ağ yönetimi rehberi tamamlayıcı bir okumadır.

Senkron kütüphaneyi async dünyaya sokmak: asyncio.to_thread köprüsü

librouteros senkron bir kütüphanedir: bir komut gönderdiğinizde cevap gelene kadar bloklar. Worker’larımız ise asyncio tabanlı. Bu ikisini saf haliyle karıştırmak, tek yavaş cihazın bütün event loop’u (dolayısıyla o worker’ın işlediği tüm cihazları) kilitlemesi demektir.

Çözüm, her cihaz I/O çağrısını bir thread’e taşımaktır:

# Senkron librouteros çağrısını event loop'u bloklamadan çalıştır
api = await asyncio.to_thread(librouteros.connect, host=ip, username=user,
                              password=pw, port=8728, timeout=10)
data = await asyncio.to_thread(lambda: tuple(api.path("interface")))

Bu küçük görünen köprü, ölçekte kritik: bağlantı, okuma, komut, yani cihazla konuşan her adım to_thread içinde. Aksi halde sistem “async” görünür ama pratikte tek cihazın hızında akar.

Not: Go gibi dillerde binlerce cihaza eşzamanlı erişim goroutine’lerle daha doğal kurulur. Biz platformun geri kalanı (FastAPI, veri modeli, ekip aşinalığı) Python olduğu için Python’da kaldık ve bu köprüyle telafi ettik. Dil seçimi bir doğru-yanlış değil, bağlam kararıdır.

API’nin en sinsi tuzağı: “print” ile “action” farkı

RouterOS API’de bir menüyü okumak ile ona bir aksiyon göndermek farklı çağrılardır ve bu, otomasyona yeni başlayanı en çok yakalayan tuzaktır.

• api.path("interface") üzerinde iterasyon yapmak arka planda /interface/print çalıştırır, yani okur.
• Ama reboot, upgrade, backup save gibi komutlar bu yolla gönderilemez; bunlar için komutu doğrudan çalıştıran ayrı bir çağrı (api(cmd="/system/reboot") gibi) gerekir.

Bu farkı bilmeden “reboot neden çalışmıyor” diye saatler harcanır. Kodumuzda bu ayrım her aksiyon fonksiyonunun başında yorumla işaretli; çünkü altı ay sonra aynı tuzağa düşmemek için.

İlişkili bir gerçek: reboot sonrası bağlantının düşmesi normaldir. Cihaz yeniden başlarken API oturumu doğal olarak kopar; bu istisnayı hata saymayıp yutmak (ve “cihaz reboot edildi” olarak kaydetmek) gerekir.

/export neden API’de yok ve SSH’a düşmek zorunda kaldık

Bir MikroTik’in tam ve okunabilir yapılandırma dökümünü almanın klasik yolu /export komutudur. Ama binary API /export döndürmez. Bu, otomasyon kurarken çarptığımız en somut duvarlardan biriydi.

İki çözüm var, ikisini de kullanıyoruz:

1. Gerçek /export için SSH: Yapılandırmanın birebir dökümü gerektiğinde (ör. denetim ya da arşiv), paramiko ile SSH açıp /export çıktısını alıyoruz. Bu, “SSH’ı sadece dar işler için tut” ilkesinin tam örneği.
2. API’den “pseudo-export”: Menüleri bölüm bölüm okuyup RSC benzeri bir metin üretmek. SSH gerektirmez ama /export kadar eksiksiz değildir.

Ders: Binary API güçlüdür ama her şeyi kapsamaz; olgun bir otomasyon, API’nin bittiği yerde SSH’a temiz bir şekilde geçebilmelidir.

Güvenli toplu değişiklik: desired state → diff → idempotent komut → doğrulama

Toplu yapılandırma değişikliğinin korkutucu olması gerekmez; korkutucu olan kör değişikliktir. Bizim reconcile (uzlaştırma) döngümüz şu adımlardan geçer:

1. Desired state: Cihazın olması gereken hâli bir YAML şablonundan üretilir (NTP, SNMP, firewall temeli, yönetim kullanıcıları vb.).
2. Actual state: Cihazdan API ile mevcut yapılandırma okunur.
3. Diff: İki durum bölüm bölüm karşılaştırılır; yalnızca fark (drift) hesaplanır.
4. Ön yedek: Değişiklik uygulanmadan önce cihazın yapılandırma yedeği alınır (geri dönüş garantisi).
5. Idempotent uygulama: Komutlar “varsa dokunma, yoksa ekle” (add-if-missing), “bul ve güncelle” (set-by-find) mantığıyla üretilir. Aynı reconcile iki kez çalışsa da sonuç değişmez.
6. Doğrulama: Cihaz tekrar okunur, drift’in sıfırlandığı teyit edilir.

Idempotency’nin pratik değeri şudur: Bir reconcile ağ kesintisi yüzünden yarım kalırsa, panik yok: işi yeniden çalıştırmak, zaten uygulanmış adımları tekrarlamadan eksikleri tamamlar. Kısmi başarı da açıkça partial olarak işaretlenir; bir komut patlasa bile diğerleri denenmeye devam eder ve sonuç dürüstçe raporlanır.

Bu disiplin, firewall kurallarını, VLAN yapılandırmasını ya da merkezi kablosuz (CAPsMAN) ayarlarını yüzlerce cihazda tutarlı tutmanın tek sürdürülebilir yoludur.

RouterOS v6 ve v7 farkları: otomasyonun en çok kod harcadığı yer

Tek bir komut şablonuyla hem RouterOS 6 hem 7 cihazlarını yönetmek mümkün değil; sürüm farkları otomasyonun içine gömülmek zorunda. Sahada en çok karşılaştıklarımız:

Konu	RouterOS v6	RouterOS v7
BGP	/routing/bgp/peer	/routing/bgp/connection
NTP	primary-ntp / secondary-ntp (ayrı alanlar)	servers= (virgüllü liste)
Bridge VLAN filtreleme	Sınırlı / olgunlaşmamış	Tam destekli
WireGuard	Yok	Var (v7 ile geldi)

Pratik yaklaşım: Cihaza bağlanınca önce RouterOS sürümünü oku, major sürümü belirle ve komut üretimini buna göre dallandır. “v7 yolunu dene, olmazsa v6 yoluna düş” tipi fallback’ler kaçınılmaz. Bu, kodu şişiren ama sahada olmazsa olmaz bir katmandır. Sürüm geçişini bir hizmet olarak ele alıyorsanız MikroTik Destek sayfamızda RouterOS 6→7 geçişine ayrı değiniyoruz.

Kimlik bilgileri ve denetim: ölçekte güvenlik

Bir cihaza değil de yüzlerce cihaza erişim tutan bir sistem, sızması hâlinde çok daha değerli bir hedeftir. Bizim tuttuğumuz asgari çizgiler:

• Şifreler şifreli saklanır: Cihaz parolaları veritabanında düz metin değil, simetrik şifreleme (Fernet) ile ciphertext olarak durur; anahtar ortam değişkeninde tutulur ve repoya asla girmez. Şifre yalnızca worker bir cihaza bağlanacağı an, bellekte çözülür. (Dürüst sınır: bu bir HashiCorp Vault / KMS değil, env tabanlı bir çözümdür; güvenlik tek anahtara bağlıdır ve olgunlaşma alanıdır.)
• Audit log: Her iş “kim tetikledi” bilgisiyle (created_by: kullanıcı / scheduler / otomatik) kaydedilir. Her cihaz aksiyonu (yedek alındı, reconcile uygulandı/başarısız, reboot algılandı) kim-ne-ne zaman detayıyla ayrı bir olay tablosuna yazılır.
• En az yetki: Uygulama tarafında rol bazlı erişim (viewer varsayılan, yönetim işlemleri admin gerektirir) ve grup bazlı çok kiracılılık var. Cihaz tarafında otomasyonun eklediği SNMP community salt-okunur (read-access=yes, write-access=no) yapılır. (Cihaz-tarafı yönetim kullanıcılarının yetkisini daraltmak ise sürekli iyileştirdiğimiz bir alan; dürüst olmak gerekirse burada her zaman “en az yetki” ideali kolay değil.)

Peki bu ölçek gerçekten ne kadar?

Platformu 50.000+ cihaz hedefiyle tasarladık; mimariyi (kuyruk, yatay worker, dağıtık kilit, circuit breaker) bu büyüklüğü kaldıracak şekilde kurguladık. Burada dürüst olmak önemli: 50.000, kanıtlanmış canlı bir rakam değil, tasarım hedefidir. Mimarinin bu ölçeği kaldıracak biçimde boyutlandırılmış olması ile o ölçekte fiilen çalıştırılmış olması aynı şey değildir; ikincisi ancak gerçek yükle doğrulanır.

Sizin için pratik çıkarım şu: 10-20 cihazda elle yönetim ya da basit script’ler yeter. 100+ cihaza, çok şubeye ya da MikroTik’i müşterilerine yöneten bir servis sağlayıcı konumuna geçtiğinizde, yukarıdaki mimari (yapılandırılmış API + iş kuyruğu + idempotent reconcile + denetim) “lüks” değil, sürdürülebilirliğin ön koşuludur.

Kendiniz mi kurmalısınız, yönettirmeli mi?

Bu yazıdaki her şey uygulanabilir ve açık kaynak araçlarla (Python, librouteros, Redis, PostgreSQL) kurulabilir. Ama dürüst tabloyu görmek gerek: v6/v7 farkları, idempotency, reliable queue, circuit breaker ve güvenli credential yönetimi ciddi bir mühendislik yatırımıdır ve bakımı süreklidir.

Kendi ekibinizle kuracaksanız bu yazı size gerçekçi bir yol haritası ve tuzak listesi sunar. Bu yükü taşımak istemiyorsanız, çok sayıda MikroTik’i merkezi ve denetlenebilir biçimde yönetmeyi bizim gibi ekiplerden bir hizmet olarak alabilirsiniz; Network Altyapı ve MikroTik Destek sayfalarımız buraya bakıyor. Her iki durumda da anahtar ilke aynı: cihazlarınızı elle değil, tekrarlanabilir ve doğrulanabilir bir sistemle yönetin.