MikroTik’in Cloud Hosted Router (CHR) ürünü, fiziksel donanım dünyasında uzun süredir lider olan RouterOS’u bulut çağına taşıyan ilginç bir adımdır. CHR’yi diğer “VPN appliance” türü ürünlerden ayıran şey, RouterOS’un tüm özelliklerini (BGP, OSPF, MPLS, queue, firewall, hotspot) hipervisor üzerinde bir x86_64 sanal makinesi olarak sunmasıdır. Bu yazıda CHR’yi DevOps perspektifinden ele alacağız: VMware, Proxmox, AWS, Hetzner ve Vultr üzerinde nasıl dağıtacağımızı, lisanslamanın inceliklerini ve en önemlisi Terraform ile bu altyapıyı nasıl kodla yöneteceğimizi inceleyeceğiz.

Sekiz yıllık DevOps deneyimimde, MikroTik’in bulut benimsemesi en yavaş ürün katmanlarından biri olarak kaldı. Genelde “edge cihaz” mantığıyla düşünüldüğü için, bulutta var olabileceği fikri network mühendislerine zor geliyor. Oysa modern multi-cloud topolojilerinde CHR, on-prem ile bulut arasında konuşan ideal bir bridge’tir; doğru otomasyonla 50 farklı bölgede 50 dakikada deploy edilebilir.

Cloud Hosted Router Nedir, Ne Değildir?

CHR; tam olarak x86_64 hipervisor üzerinde çalışacak şekilde paketlenmiş bir RouterOS imajıdır. RouterOS 6.x’ten beri sunulan ve şu özellikleri olan bir sanal makine olarak düşünebilirsiniz:

• 1 vCPU + 128 MB RAM ile başlayabilir, 16 vCPU + 16 GB RAM’e kadar ölçeklenebilir.
• VirtIO, VMXNET3, E1000 ve PCNet ağ adaptörlerini destekler. Yüksek performans için VirtIO + multiqueue önerilir.
• İlk açılışta ücretsiz; 1 Mbps interface başına hız sınırı vardır. Lisans alındığında sınır kalkar.
• Disk imajı QCOW2, VMDK, VHDX, OVA ve raw formatlarında resmi olarak indirilebilir.

CHR’nin olmadığı şeyler de önemlidir:

• Container imajı değil. K8s pod’u olarak dağıtılamaz (en azından doğal değildir).
• Donanım hızlandırması yok; performans tamamen vCPU’ya bağlıdır. AES-NI destekli host’ta IPsec/AES-GCM hızlanır.
• Bir SaaS değil; sizin yönettiğiniz bir sanal makinedir.

Lisanslama: P1, P10, PU ve Free Arasındaki Farklar

CHR lisanslaması RouterOS’un genel “level” sisteminden farklıdır. Dört seviye vardır:

• Free: Her interface başına 1 Mbps. Test/lab için ideal.
• P1 (Perpetual 1): 1 Gbps per interface. ~45 USD. Küçük ofis / branch VPN concentrator için.
• P10 (Perpetual 10): 10 Gbps per interface. ~95 USD. Aggregate edge router.
• PU (Perpetual Unlimited): Sınırsız. ~250 USD. Production core, IXP peering, vb.

Perpetual lisanslar bir CHR instance’a bağlıdır; instance silinirse lisans serbest bırakılabilir ancak bunu MikroTik destek talebi ile yapmak gerekir. Bu nedenle, immutable infrastructure mantığıyla “her deploy yeni VM” yapısı kuran ekipler için P1/P10/PU yerine 60-günlük trial + Annual lisans (zayıf bir adoption olan ama mevcut) daha esnek olabilir. Üretimde sabit IP ve sabit instance kullanan ekipler için Perpetual hâlâ en mantıklı seçim.

Lisanslamayı otomatize etmek mümkündür. MikroTik account API’si üzerinden lisansı CLI ile alabilirsiniz:

# Account portal kimlik bilgileri ile lisansı çek
/system license renew [email protected] password=portalpass level=p1

Platform 1: Proxmox VE Üzerinde CHR

Proxmox; KVM tabanlı, açık kaynak ve self-hosted bir hipervisor olarak DevOps ortamlarında giderek popüler. CHR’yi Proxmox’a deploy etmek için temel adımlar:

# Proxmox host üzerinde
cd /var/lib/vz/template/iso
wget https://download.mikrotik.com/routeros/7.13.4/chr-7.13.4.img.zip
unzip chr-7.13.4.img.zip

# Yeni VM oluştur (qm CLI)
qm create 200 
    --name chr-edge-01 
    --memory 1024 
    --cores 2 
    --net0 virtio,bridge=vmbr0 
    --net1 virtio,bridge=vmbr1 
    --ostype l26 
    --scsihw virtio-scsi-pci

# CHR raw disk'i import et
qm importdisk 200 chr-7.13.4.img local-lvm

# Disk'i SCSI olarak bağla
qm set 200 --scsi0 local-lvm:vm-200-disk-0
qm set 200 --boot order=scsi0
qm set 200 --serial0 socket --vga serial0

qm start 200

İlk açılışta serial console (qm terminal 200) ile bağlanırsınız. Varsayılan kullanıcı admin, şifre boş. Ardından klasik RouterOS yapılandırması başlar. Production’da daha mantıklı olan Cloud-init benzeri bir initial config injection mekanizmasıdır; ne yazık ki CHR cloud-init desteklemez. Bunun yerine second drive olarak FAT32 config disk mount edip autorun.scr ile script çalıştırabilirsiniz.

Otomatik Provisioning: Proxmox + Bash Wrapper

#!/usr/bin/env bash
# /usr/local/bin/spawn-chr.sh
set -euo pipefail
VMID=$1
NAME=$2
WAN_BRIDGE=${3:-vmbr0}
LAN_BRIDGE=${4:-vmbr1}
TEMPLATE_DISK="/var/lib/vz/template/iso/chr-7.13.4.img"

qm clone 100 $VMID --name $NAME --full true
qm set $VMID --net0 virtio,bridge=$WAN_BRIDGE
qm set $VMID --net1 virtio,bridge=$LAN_BRIDGE
qm set $VMID --memory 2048 --cores 2

# Inject config disk
CONFIG_IMG=/tmp/chr-config-$VMID.img
dd if=/dev/zero of=$CONFIG_IMG bs=1M count=4
mkfs.vfat $CONFIG_IMG
mkdir -p /mnt/chrcfg
mount -o loop $CONFIG_IMG /mnt/chrcfg
cat > /mnt/chrcfg/autorun.scr <

Bu basit wrapper, "yeni CHR" deploy etmeyi tek komuta indirir. 50 şubelik bir kurulum için for-loop yeterlidir.

Platform 2: AWS EC2 Üzerinde CHR

MikroTik, AWS Marketplace'te resmi CHR AMI'si yayınlamıştır. AMI ID'leri bölgeye göre değişir (örneğin eu-central-1'de farklı, us-east-1'de farklı). En güncel listeyi aws ec2 describe-images --filters "Name=name,Values=*CHR*" --owners aws-marketplace ile alabilirsiniz.

Önemli noktalar:

• AWS CHR otomatik olarak P1 lisanslıdır (Marketplace ücretine dahil). Bu, hem rahatlık hem de tuzak: P1 1 Gbps cap'i vardır, daha yüksek throughput için BYOL daha uygundur.
• EC2 instance tipi olarak c6i.large veya m6i.large önerilir; ENA (Elastic Network Adapter) sürücüsü desteği vardır.
• İlk SSH erişimi için instance launch sırasında User Data alanı CHR'nin autorun.scr mekanizmasını taklit eder.
• Multiple ENI ile her CHR farklı VPC subnet'ine bağlanabilir; bu, hub-and-spoke transit VPC tasarımları için doğaldır.

Terraform ile AWS CHR Deploy

# main.tf
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" { region = "eu-central-1" }

data "aws_ami" "chr" {
  most_recent = true
  owners      = ["aws-marketplace"]
  filter {
    name   = "name"
    values = ["mikrotik-CHR-*"]
  }
}

resource "aws_security_group" "chr" {
  name   = "chr-edge-sg"
  vpc_id = var.vpc_id

  ingress { from_port = 22    to_port = 22    protocol = "tcp" cidr_blocks = [var.admin_cidr] }
  ingress { from_port = 8291  to_port = 8291  protocol = "tcp" cidr_blocks = [var.admin_cidr] }
  ingress { from_port = 51820 to_port = 51820 protocol = "udp" cidr_blocks = ["0.0.0.0/0"] }
  egress  { from_port = 0     to_port = 0     protocol = "-1"  cidr_blocks = ["0.0.0.0/0"] }
}

resource "aws_instance" "chr_edge" {
  ami                         = data.aws_ami.chr.id
  instance_type               = "c6i.large"
  subnet_id                   = var.public_subnet_id
  vpc_security_group_ids      = [aws_security_group.chr.id]
  source_dest_check           = false  # Router için zorunlu!
  key_name                    = var.ssh_key_name

  user_data = <<-EOT
    /user set admin password="${var.admin_pass}"
    /ip dns set servers=1.1.1.1,9.9.9.9 allow-remote-requests=yes
    /interface wireguard add name=wg-corp listen-port=51820 private-key="${var.wg_priv}"
    /ip address add address=10.99.0.1/24 interface=wg-corp
    /interface wireguard peers add interface=wg-corp public-key="${var.wg_peer_pub}" allowed-address=10.99.0.10/32
  EOT

  tags = { Name = "chr-edge", ManagedBy = "terraform" }
}

resource "aws_eip" "chr" {
  instance = aws_instance.chr_edge.id
  domain   = "vpc"
}

Burada source_dest_check = false kritik bir noktadır. AWS VPC, varsayılan olarak EC2 instance'larından gelen paketin kaynak veya hedefinin instance'ın IP'si olmasını bekler. Router gibi davranan bir VM bu kontrolü disable etmek zorundadır.

BGP Konfigürasyonu: AWS Direct Connect ile

CHR'yi VGW (Virtual Private Gateway) veya Transit Gateway BGP peer'i olarak kullanabilirsiniz. Bu sayede on-prem'inizden gelen prefix'ler dinamik olarak öğrenilir:

/routing bgp instance
add as=65100 router-id=10.0.0.10
/routing bgp peer
add name=aws-vgw remote-address=169.254.1.1 remote-as=64512 
    hold-time=30s keepalive-time=10s

Platform 3: Hetzner Cloud Üzerinde CHR

Hetzner, fiyat/performans dengesinde çok iyi olduğu için DevOps ekiplerinin sevdiği bir platformdur. Resmi bir CHR imajı yoktur; ancak snapshot oluşturarak custom imaj sunabilirsiniz.

Adımlar:

1. Hetzner Cloud'da rescue mode'da bir CX11/CX21 sunucu açın.
2. SSH ile bağlanın, wget ile CHR raw image'ı çekin.
3. dd ile diske yazın: dd if=chr.img of=/dev/sda bs=4M
4. Reboot. Sunucu CHR olarak açılır.
5. Hetzner Cloud Console'dan snapshot oluşturun. Artık bu snapshot'tan yeni instance'lar deploy edebilirsiniz.

# hcloud CLI ile snapshot'tan instance deploy
hcloud server create 
    --name chr-fra-01 
    --image $CHR_SNAPSHOT_ID 
    --type cx21 
    --location fsn1 
    --network corp-net 
    --ssh-key admin

Terraform tarafında karşılığı:

resource "hcloud_server" "chr" {
  name        = "chr-fra-01"
  image       = data.hcloud_image.chr_snapshot.id
  server_type = "cx21"
  location    = "fsn1"
  network {
    network_id = hcloud_network.corp.id
    ip         = "10.0.1.5"
  }
  ssh_keys = [hcloud_ssh_key.admin.id]

  labels = { managed_by = "terraform", role = "edge_router" }
}

Hetzner'in bir özelliği vSwitch ürünüdür; bu sayede Hetzner Cloud + dedicated server topolojinizi tek bir Layer 2 ağda toplayabilirsiniz. CHR bu vSwitch'in bridge'inde central router olarak görev yapabilir.

Platform 4: Vultr Üzerinde CHR

Vultr, özellikle "ISO upload" özelliği nedeniyle CHR için DevOps ekiplerinin gözdesidir. Adımlar şöyledir:

1. Vultr panelinde ISO Library'ye CHR raw imajını yükleyin.
2. Yeni instance açarken bu ISO'yu boot disk olarak seçin.
3. İlk boot'tan sonra, ISO'yu detach edip diski boot disk yapın.

Vultr'un API'si Terraform provider'ı ile entegredir:

resource "vultr_iso_private" "chr" {
  url = "https://download.mikrotik.com/routeros/7.13.4/chr-7.13.4.img.zip"
}

resource "vultr_instance" "chr_edge" {
  plan      = "vc2-1c-1gb"
  region    = "fra"
  iso_id    = vultr_iso_private.chr.id
  label     = "chr-fra-01"
  hostname  = "chr-fra-01"
  enable_ipv6 = true
}

Platform 5: VMware ESXi / vSphere

VMware ortamında CHR'nin OVA imajı resmi olarak dağıtılır. govc CLI ile import otomatize edilebilir:

# govc kurulumu (Go binary)
export GOVC_URL=https://vcenter.example.com
export [email protected]
export GOVC_PASSWORD=...
export GOVC_INSECURE=true

govc import.ova 
    -ds=datastore1 
    -pool=/DC/host/cluster1/Resources 
    chr-7.13.4.ova

govc vm.network.add -vm chr-edge -net "VLAN10-WAN"
govc vm.network.add -vm chr-edge -net "VLAN20-LAN"
govc vm.power -on chr-edge

vSphere üzerinde Terraform hashicorp/vsphere provider'ı ile aynı işlemi yapabilirsiniz; productionsa Pulumi tercih edenler için TypeScript ile de benzer kod yazılabilir. ESXi tarafında CHR için en kritik VMware ayarı "Promiscuous Mode" + "Forged Transmits" seçeneklerinin port grubunda etkinleştirilmesidir. Aksi halde CHR'den geçen paketler vSwitch tarafından düşürülür.

Centralized Management: Ansible ile Çoklu CHR Yönetimi

10 farklı bulutta 50 CHR çalıştırdığınızda artık tek tek WinBox açmak ölçeklenmez. Ansible'ın community.routeros koleksiyonu CHR ile mükemmel uyumludur:

# inventory.yml
all:
  children:
    chr_edge:
      hosts:
        chr-aws-fra: { ansible_host: 10.0.1.5 }
        chr-aws-iad: { ansible_host: 10.0.2.5 }
        chr-hetzner-fsn: { ansible_host: 10.1.1.5 }
        chr-vultr-fra: { ansible_host: 10.2.1.5 }
      vars:
        ansible_connection: network_cli
        ansible_network_os: community.routeros.routeros
        ansible_user: ansible-bot

# playbook.yml
- hosts: chr_edge
  gather_facts: false
  tasks:
    - name: Apply baseline firewall
      community.routeros.command:
        commands:
          - /ip firewall filter add chain=input action=drop in-interface=ether1 connection-state=invalid
          - /ip firewall filter add chain=input action=accept connection-state=established,related
          - /ip firewall filter add chain=input action=drop in-interface=ether1
    - name: Configure NTP
      community.routeros.command:
        commands:
          - /system ntp client set enabled=yes
          - /system ntp client servers add address=pool.ntp.org

Bu yapı tek bir ansible-playbook komutuyla 50 farklı bulut bölgesindeki tüm CHR'lerinizi tutarlı hale getirir.

Monitoring: SNMP + Prometheus Exporter

CHR'nin SNMP modülü standart RouterOS ile aynıdır. SNMPv3 önerilir:

/snmp set enabled=yes
/snmp community add name=corp-ro security=private
/snmp set engine-id="chr-aws-fra"

Prometheus tarafında nshttpd/mikrotik-exporter (artık ksurl'in fork'u daha aktif) kullanılabilir:

# mikrotik-exporter.yml
devices:
  - name: chr-aws-fra
    address: 10.0.1.5
    user: prometheus-bot
    password: ${MTK_PASS}
  - name: chr-hetzner-fsn
    address: 10.1.1.5
    user: prometheus-bot
    password: ${MTK_PASS}

features:
  bgp: true
  routes: true
  wireguard: true
  optics: false
  ipsec: true

Grafana dashboard'larında "CHR per-region throughput", "BGP session up/down", "WireGuard peer handshake age" panelleri standart hale gelir.

GitOps Yaklaşımı: CHR + ArgoCD?

CHR ne kadar otomatize olursa olsun, native Kubernetes resource'u değildir. Bu nedenle ArgoCD ile doğrudan yönetilemez. Ancak Crossplane veya Pulumi Kubernetes Operator ile arada bir abstraction katmanı eklenebilir. Pratik yaklaşım: Git deposunda Terraform + Ansible kodu tutmak, GitHub Actions / GitLab CI ile değişikliklerde otomatik terraform plan ve ansible-playbook --check çalıştırmak, merge sonrası apply yapmaktır.

# .github/workflows/chr-deploy.yml
name: CHR Deploy
on:
  push:
    paths: ['terraform/chr/**', 'ansible/playbooks/chr_*.yml']
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform -chdir=terraform/chr init
      - run: terraform -chdir=terraform/chr plan -out=tfplan
      - uses: actions/upload-artifact@v4
        with: { name: tfplan, path: terraform/chr/tfplan }
  apply:
    needs: plan
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with: { name: tfplan, path: terraform/chr/ }
      - run: terraform -chdir=terraform/chr apply -auto-approve tfplan
      - run: ansible-playbook -i ansible/inventories/prod ansible/playbooks/chr_baseline.yml

Performans Tuning ve Yaygın Tuzaklar

• vCPU bağlama: KVM/Proxmox üzerinde cpu parametresini host yaparak AES-NI'nin guest'e geçmesini sağlayın. qm set 200 --cpu host.
• VirtIO multiqueue: queues=N ile birden fazla TX/RX kuyruğu açın. 2-4 vCPU için 2 kuyruk yeterli.
• Disk hızı: Yöneticisel kayıt için 1 GB disk fazlasıyla yeter. Logu uzun süre tutacaksanız 4 GB; aksi halde flash storage kullanılırsa I/O fazla maliyetlidir.
• Tuzak 1: Bazı bulut sağlayıcıları (özellikle Hetzner Cloud) DHCPv6 ile IPv6 dağıtır; CHR varsayılan olarak DHCPv6 client değildir. /ipv6 dhcp-client add interface=ether1 eklemeyi unutmayın.
• Tuzak 2: AWS Marketplace lisansı, Spot Instance'la kullanılırsa "instance silindi" senaryosunda lisans takılı kalır. Production'da On-Demand kullanın.
• Tuzak 3: Vultr "Block Storage" disk imajıyla uyumlu değildir; sadece local SSD kullanın.

Maliyet Analizi: 10 Şubelik Bir Topoloji

Hipotetik bir senaryo: Avrupa'da 10 şube, hub Frankfurt'ta. Karşılaştırma:

• Donanım MikroTik (hAP ax² + RB5009): ~$2000 CapEx, $0 aylık. Ancak power + bağlantı maliyetleri var.
• CHR on AWS: 10 x c6i.large = ~$700/ay + 10 x P1 lisans = $450 one-time. Veri transferi ek olarak ~$500/ay.
• CHR on Hetzner: 10 x CX21 = ~$70/ay + 10 x P1 = $450 one-time. Veri transferi ücretsiz.
• CHR on Vultr: 10 x 1GB plan = ~$60/ay + 10 x P1 = $450 one-time.

Görüldüğü gibi hybrid yaklaşım çoğu zaman en mantıklı: edge'de bir MikroTik donanım kutusu (low-cost CapEx), bulutta bir-iki adet CHR (yüksek-bandwidth backbone). Bu kombinasyon, multi-region WireGuard mesh + BGP backbone için ideal.

Sık Sorulan Sorular

CHR fiziksel RouterBoard yerini tutar mı?

Performans açısından çoğunlukla evet. Bir CCR2004 yaklaşık 4-5 Gbit/s yapar; benzer maliyetli bir c6i.xlarge CHR aynı seviyededir. Ancak fiziksel cihazların ASIC tabanlı switch offload, hardware NAT ve PoE port gibi özellikleri CHR'de yoktur.

P1 lisansını ikinci bir VM'e taşıyabilir miyim?

Resmi olarak hayır; pratikte MikroTik destek talebi ile lisans key'i yeni instance'a transfer edilebilir. Süreç bir-iki iş günü sürebilir. Immutable infrastructure ile çalışıyorsanız bu sürtünme önemli olur; bu durumda Annual lisans daha uygun olabilir.

AWS Marketplace CHR mı, BYOL mu daha mantıklı?

Düşük trafik (1 Gbps altı, sabit instance) için Marketplace daha kolaydır. Yüksek trafik veya 10+ instance fleet için BYOL + Perpetual Unlimited daha ucuza gelir. Marketplace EC2 fiyatı + RouterOS lisansını birleştirir; bunu kendiniz manuel yaparsanız genelde %30-40 tasarruf olur.

CHR'nin Kubernetes uyumluluğu var mı?

Doğrudan yok. Ancak KubeVirt ile CHR sanal makinesi Kubernetes cluster içinde çalıştırılabilir. Bu setup özellikle telco edge ve MEC (Multi-access Edge Computing) senaryolarında gündeme geliyor. Production'da hâlâ deneysel sayılır.

CHR yüksek erişilebilirlik (HA) için ne öneriyor?

VRRP RouterOS'ta yerleşiktir; iki CHR aktif-pasif yapı kurabilir. Cloud-native HA için Floating IP + sağlayıcı API'si gerekir (örneğin AWS'de Elastic IP'yi failover ile bir Lambda fonksiyonuna bağlamak). Active-active için BGP ECMP en temiz çözüm.

Terraform state'i CHR konfigürasyonunu kapsıyor mu?

Hayır; Terraform sadece sanal makine ve underlying altyapıyı (Security Group, VPC, EIP) yönetir. CHR'nin içindeki yapılandırma için Ansible veya custom REST API çağrıları (RouterOS API üzerinden) kullanılır. İki katmanlı bir yaklaşım çoğu ekip için en sürdürülebilir olmuştur.

CHR güvenli mi? Public internet'e açılırsa risk büyük mü?

RouterOS güvenli bir codebase'tir ancak default credentials ve açık servis listesi büyük tehlikelidir. Production CHR'ler için: SSH key tabanlı, WinBox portu disable veya IP-restricted, Web admin disable, API SSL only, MAC server disable şart. Cloud Security Group/Firewall katmanında da bu servisleri sıkılaştırın.

Sonuç

CHR; RouterOS'un olgun feature setini bulut çağına taşımanın MikroTik'in ilk ve hâlâ en başarılı denemesidir. Doğru otomasyon (Terraform + Ansible + GitHub Actions) ile multi-cloud topolojiler tek bir Git deposundan yönetilebilir hale gelir. Performans, lisanslama ve cloud-native uyum konularındaki tuzakları bilen bir DevOps ekibi için CHR; on-prem MikroTik fleet ile bulut workload'ları arasında en organik bridge'lerden biridir. Bir sonraki yazıda CHR + WireGuard ile multi-region mesh tasarımı ve adaptive firewall ile zero-trust katmanı eklemeyi inceleyeceğiz.

Aynı Konuda Diğer Yazılarımız

Konuyla bütünleşik olarak okumanızı önerdiğimiz içerikler:

• MikroTik Queue Tree: HTB, Burst ve Priority Pratikleri — MikroTik queue tree ile ileri bant genişliği yönetimi: HTB, burst, priority ve PCQ pratikl
• MikroTik Firewall Stratejisi: Zero Trust Mimarisinden Adaptive Defense'e — MikroTik firewall ile Zero Trust mimarisi, adaptive defense, threat intel feed ve SIEM ent
• MikroTik RouterBoard Serisi: 2026'da Hangi Model Kime Uygun? Detaylı Karşılaştırma — MikroTik RouterBoard ailesinin hAP, hEX, RB, CCR ve cAP modellerinin 2026 güncel karşılaşt
• MikroTik Üzerinde Hız Testi: BTest, Bandwidth Monitör ve İperf3 ile Performans Ölçümü — MikroTik üzerinde BTest, iperf3 ve bandwidth monitor ile profesyonel hız testi nasıl yapıl
• Çoklu Şubeli MikroTik Site-to-Site VPN Mesh: Otomasyon ve Scripting ile Yönetim — Çoklu şubeli MikroTik site-to-site VPN mesh otomasyonu: Ansible, scripting, REST API ve mo

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• MikroTik Resmi Dökümantasyon (RouterOS Wiki)
• MikroTik Resmi Forumu
• MikroTik Resmi Sitesi
• Alpine Linux Resmi
• Linux Kernel Project