Evdeki Veri Merkezi: Proxmox ile Kendi Homelab'inizi Kurun

Homelab kuran çoğu kişi işe kurmak istediği uygulamadan başlar: bir medya sunucusu, bir Nextcloud, bir oyun sunucusu. Sonra bir şey bozulur ve ortaya çıkar ki logu tutan yoktur, hangi servisin ne zaman düştüğünü kimse bilmez, IP’ler elle dağıtıldığı için de hangi makinenin ne olduğu belirsizdir.

Önceki homelab denememde MSI marka bir laptop üzerinde kısıtlı imkanlarla çalışmıştım. Bu kez masaüstü bilgisayarıma Proxmox kurup uygulamalardan önce gelmesi gereken temeli kuruyorum: isim çözümleme, merkezî log, metrik toplama ve erişilebilirlik izleme. Bunlar olmadan bir küme sağlıklı takip edilemez.

Bu, ev ortamındaki bir kurulumdur; güvenlik duvarı ve yapılandırması karmaşık servisler kapsam dışında bırakıldı.

Servislerin tamamını LXC konteyner olarak çalıştıracağım. LXC, tam bir sanal makine gibi kendi çekirdeğini çalıştırmaz; hostun çekirdeğini paylaşır. Pratik sonucu şudur: Dnsmasq veya Rsyslog gibi tek işlik bir servis için 512 MB bellek yeterli olur, aynı iş bir VM’de en az 1-2 GB ister. Ayrıntı için Proxmox wiki sayfasına bakabilirsiniz.

Şablondan Konteynere: Beş Servisin İskeleti

Beş servisin beşi de aynı iskeletten çıkıyor: bir Debian şablonu, sabit bir IP, --onboot 1. Farklı olan yalnızca bellek ve disk.

Önce şablonu indiriyoruz. Proxmox şablon listesini kendisi tutar:

pveam update
pveam available --section system | grep debian-12

system          debian-12-standard_12.7-1_amd64.tar.zst

pveam download local debian-12-standard_12.7-1_amd64.tar.zst

Sürüm numarası deponuzda farklı çıkabilir; aşağıdaki komutlarda pveam available çıktısında gördüğünüz dosya adını kullanın.

CTID’yi IP’nin Son Basamağı Yapmak

Proxmox her konteynere bir sayı (CTID) verir ve varsayılan olarak 100’den başlar. CTID’yi IP’nin son sekizlisiyle aynı seçmek, altı ay sonra pct list çıktısına baktığınızda hangi numaranın hangi makine olduğunu düşünmenizi engeller. Ücretsiz bir karar, ve homelab’de tuttuğunuz tek konvansiyon bu olsa bile işe yarar.

vCPU sütununun hepsinde 2 yazması savurganlık değil: LXC’de çekirdek bir üst sınırdır, ayrılmış bir kaynak değil. Boşta duran konteyner hiçbir çekirdeği tutmaz. Bellek ve disk ise gerçekten ayrılır — log ve influxdb‘nin diski büyük, çünkü ikisi de zamanla dolan veri tutuyor.

İlk Konteyner: pct create

DNS sunucusunu ayrı yazıyoruz, çünkü tek farkı olan o:

pct create 108 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname dns \
  --cores 2 --memory 512 --swap 512 \
  --rootfs local-lvm:4 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.1.8/24,gw=192.168.1.1 \
  --nameserver 1.1.1.1 \
  --unprivileged 1 --onboot 1 \
  --ssh-public-keys /root/.ssh/id_ed25519.pub

--nameserver 1.1.1.1 satırı bilerek böyle. Bu konteyner ağın DNS sunucusu olacak, ama dnsmasq daha kurulmadı; kendini çözümleyici olarak gösterirse ilk apt update komutu çalışmaz. Kalan dördü 192.168.1.8‘i gösterecek.

while read -r ad ctid ip bellek disk; do
  pct create "$ctid" local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
    --hostname "$ad" \
    --cores 2 --memory "$bellek" --swap 512 \
    --rootfs local-lvm:"$disk" \
    --net0 name=eth0,bridge=vmbr0,ip="$ip"/24,gw=192.168.1.1 \
    --nameserver 192.168.1.8 \
    --unprivileged 1 --onboot 1 \
    --ssh-public-keys /root/.ssh/id_ed25519.pub
done <<'SON'
log      109 192.168.1.9   512 16
influxdb 111 192.168.1.11 2048 32
grafana  112 192.168.1.12 1024  8
uptime   113 192.168.1.13 1024  8
SON

for id in 108 109 111 112 113; do pct start "$id"; done
pct list

VMID  Status   Lock  Name
108   running        dns
109   running        log
111   running        influxdb
112   running        grafana
113   running        uptime

--unprivileged 1 varsayılan ve öyle kalmalı: ayrıcalıksız konteynerde root, host’ta sıradan bir kullanıcıya eşlenir. Ayrıcalıklı konteynere ancak host diskini doğrudan bağlamak gibi bir zorunluluk varsa geçin — ve o zaman konteyneri güvenlik sınırı saymayın.

dns.homelab.local: İsim Çözümleme Olmadan Geri Kalanı Kurmak Anlamsız

Sırayı bilerek buradan başlatıyoruz. Grafana’nın veri kaynağını 192.168.1.11 diye yazarsanız, o makineyi bir gün taşıdığınızda panoların hepsi bozulur ve nerede ne yazdığını aramaya başlarsınız.

pct enter 108
apt update && apt install -y dnsmasq dnsutils

Yapılandırmayı ana dosyaya değil, /etc/dnsmasq.d/ altına yazıyoruz — paket güncellemesi ana dosyayı değiştirebilir:

# /etc/dnsmasq.d/homelab.conf

# Yalnızca kendi arayüzünde dinle
interface=eth0
bind-interfaces
listen-address=192.168.1.8

# /etc/resolv.conf'u okuma, yukarı akışı burada sabitle
no-resolv
server=1.1.1.1
server=9.9.9.9

# Yerel alan adı — bu isimler yukarı akışa hiç sorulmasın
domain=homelab.local
local=/homelab.local/
expand-hosts

address=/proxmox.homelab.local/192.168.1.10
address=/dns.homelab.local/192.168.1.8
address=/log.homelab.local/192.168.1.9
address=/influxdb.homelab.local/192.168.1.11
address=/grafana.homelab.local/192.168.1.12
address=/uptime.homelab.local/192.168.1.13

# Alan adı içermeyen ve özel adres için gelen sorgular dışarı sızmasın
domain-needed
bogus-priv

Yeniden başlatmadan önce sözdizimini sınayın; dnsmasq hatalı yapılandırmayla başlamaz ve systemctl restart size sebebini söylemez:

dnsmasq --test
systemctl restart dnsmasq

dnsmasq: syntax check OK.

Doğrulama: İki Sorgu, İki Farklı Cevap

dig @192.168.1.8 grafana.homelab.local +short
dig @1.1.1.1 grafana.homelab.local +short

192.168.1.12

İkinci komutun boş dönmesi doğru sonuçtur. local=/homelab.local/ satırı bu isimlerin yukarı akışa hiç sorulmamasını sağlıyor; ikinci komut dolu dönerse seçtiğiniz alan adı internette gerçekten kayıtlı demektir ve er ya da geç yanlış adrese bağlanırsınız.

Host’u ve Konteynerleri Bu Sunucuya Yöneltmek

Konteynerlerin dördü oluşturma sırasında ayarlandı. Proxmox host’u için düğümün System → DNS panelinden birinci sunucuyu 192.168.1.8, ikinciyi 1.1.1.1 yapın.

İkinci sunucuyu boş bırakmayın. DNS konteyneri kapalıyken host hiçbir adı çözemez; şablon indiremez, güncelleme yapamaz ve arızayı çözmek için gereken her şey elinizden gider.

.local alan adı RFC 6762 ile mDNS’e ayrılmıştır. systemd-resolved çalıştıran istemciler .local biten sorguları unicast DNS’e değil mDNS’e yollar; o makinelerde bu tablodaki isimler çözülmez. Sıfırdan kuruyorsanız RFC 8375’in ev ağları için ayırdığı home.arpa ya da .internal kullanın. Bu yazıda homelab.local korunuyor, çünkü kurulum böyle yapıldı ve isimler her yerde bu şekilde geçiyor.

log.homelab.local: Günlüğü Makinelerin Üstünde Bırakmamak

Merkezî günlüğün asıl kazancı arama kolaylığı değil: çöken makinenin günlüğü, çökmeden önce başka bir makineye yazılmış olur. Diski dolan ya da açılmayan bir sunucunun son satırlarını başka türlü göremezsiniz.

pct enter 109
apt update && apt install -y rsyslog

Sunucu Tarafı: Gelen Günlüğü Kaynağına Göre Ayırmak

# /etc/rsyslog.d/10-uzak.conf

module(load="imudp")
module(load="imtcp")

template(name="UzakDosya" type="string"
         string="/var/log/uzak/%HOSTNAME%/%PROGRAMNAME%.log")

ruleset(name="uzakGunluk") {
    action(type="omfile" dynaFile="UzakDosya" createDirs="on")
    stop
}

input(type="imudp" port="514" ruleset="uzakGunluk")
input(type="imtcp" port="514" ruleset="uzakGunluk")

Kural kümesinin sonundaki stop olmazsa uzaktan gelen her satır bir de bu makinenin kendi /var/log/syslog dosyasına yazılır; iki kopya tutar, diski iki katı hızda doldurursunuz.

rsyslogd -N1
systemctl restart rsyslog

rsyslogd -N1 yapılandırmayı çalıştırmadan doğrular — dnsmasq --test‘in rsyslog’daki karşılığı.

İstemci Tarafı: Kuyruksuz Gönderim Günlüğü Sessizce Kaybettirir

Aşağıdaki dosya, günlüğü gönderen her makineye konur: Proxmox host’u ve diğer dört konteyner.

# /etc/rsyslog.d/90-uzak.conf

*.* action(type="omfwd"
           target="192.168.1.9" port="514" protocol="tcp"
           queue.type="linkedList"
           queue.filename="uzakkuyruk"
           queue.maxdiskspace="256m"
           queue.saveonshutdown="on"
           action.resumeRetryCount="-1")

Bu bloğun yarısı kuyruk ayarı ve asıl mesele orada. protocol="udp" ile kuyruksuz gönderirseniz, log sunucusu kapalıyken üretilen satırlar hiçbir yere yazılmadan kaybolur — hem de tam olarak bir şeyler bozulduğu için ona baktığınız anda. Yukarıdaki hâliyle rsyslog gönderemediğini diske yazar, sunucu dönünce sırayla iletir, kapanışta kuyruğu kaybetmez.

Diski Doldurmadan: logrotate

# /etc/logrotate.d/uzak

/var/log/uzak/*/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service > /dev/null 2>&1 || true
    endscript
}

postrotate bloğu şart: rsyslog döndürülen dosyanın tanıtıcısını açık tutmaya devam eder ve HUP almazsa yeni satırları silinmiş dosyaya yazar. Disk dolar, ls hiçbir şey göstermez.

Doğrulama, Proxmox host’undan tek satır:

logger -t denemesi "merkezi gunluk testi"

log konteynerinde:

cat /var/log/uzak/proxmox/denemesi.log

Aug 23 19:41:02 proxmox denemesi: merkezi gunluk testi

influxdb.homelab.local: Metriğin Durduğu Yer

Grafana veri tutmaz, yalnızca çizer. Metriği saklayan katman ayrı bir servis ve önce o kurulur.

pct enter 111
apt update && apt install -y curl gpg
mkdir -p /etc/apt/keyrings
curl -fsSL https://repos.influxdata.com/influxdata-archive_compat.key \
  | gpg --dearmor -o /etc/apt/keyrings/influxdata.gpg
echo 'deb [signed-by=/etc/apt/keyrings/influxdata.gpg] https://repos.influxdata.com/debian stable main' \
  > /etc/apt/sources.list.d/influxdata.list
apt update && apt install -y influxdb2
systemctl enable --now influxdb

İlk yapılandırma organizasyonu, kovayı (bucket) ve saklama süresini belirler:

influx setup --org homelab --bucket proxmox --username admin --retention 90d

--retention 90d boş bırakılırsa veri sonsuza kadar saklanır ve 32 GB’lık disk bir gün sessizce dolar. Ev ortamında üç ay fazlasıyla yeter.

Proxmox’un yazabilmesi için bir jeton gerekiyor. Önce kovanın kimliğini alıyoruz:

influx bucket list

ID                Name      Retention   Organization ID
b7f3a1c9d0e24856  proxmox   2160h0m0s   0a5c31e78b942df6

influx auth create --org homelab \
  --write-bucket b7f3a1c9d0e24856 \
  --description "proxmox metrik yazma"

Grafana’nın da kendi jetonu olacak, ama onunki yalnızca okuma yetkisi taşıyacak:

influx auth create --org homelab \
  --read-bucket b7f3a1c9d0e24856 \
  --description "grafana metrik okuma"

Çıkan jetonlar yalnızca bir kez gösterilir. Kaybederseniz yenisini üretmek dışında yolu yok. İki ayrı jeton üretmenin sebebi de görünür: Proxmox’un okumaya, Grafana’nın yazmaya ihtiyacı yok. Birini iptal etmeniz gerektiğinde diğeri etkilenmez.

Proxmox’u Metrik Sunucusuna Bağlamak

Arayüzde Datacenter → Metric Server → Add → InfluxDB yolunu izleyin.

Aynı tanım dosyada /etc/pve/status.cfg olarak durur — girintiler sekme karakteridir, boşluk değil:

influxdb: homelab
	server 192.168.1.11
	port 8086
	influxdbproto http
	organization homelab
	bucket proxmox
	token <jeton>

influxdbproto satırı sürüm ayrımını yapan yerdir: udp seçilirse Proxmox eski InfluxDB 1.x protokolüyle yazar ve organization / bucket / token alanlarının hiçbiri kullanılmaz. InfluxDB 2.x ile http (ya da TLS varsa https) zorunludur.

Birkaç dakika sonra veri akmaya başlamış olmalı:

influx query --org homelab 'from(bucket:"proxmox") |> range(start: -5m) |> limit(n: 5)'

Çıktı boşsa sorun jeton ya da protokol tarafındadır; journalctl -u pvestatd Proxmox’un yazma denemesinin neden reddedildiğini yazar.

grafana.homelab.local: Metriği Panoya Çevirmek

pct enter 112
apt update && apt install -y apt-transport-https software-properties-common wget gpg
mkdir -p /etc/apt/keyrings
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor -o /etc/apt/keyrings/grafana.gpg
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" \
  > /etc/apt/sources.list.d/grafana.list
apt update && apt install -y grafana
systemctl enable --now grafana-server

Arayüz http://192.168.1.12:3000 adresinde; ilk giriş admin / admin ve Grafana parolayı değiştirmeden devam ettirmez.

Veri kaynağını Connections → Add new data source → InfluxDB yolundan ekliyoruz:

Query language alanı bu formun tek kritik alanı. Varsayılan InfluxQL‘dir ve o dil InfluxDB 1.x içindir; 2.x sunucuya InfluxQL ile bağlanmaya çalışırsanız “Save & test” hata döner. Flux seçtiğinizde form Organization ve Token alanlarını gösterir — o alanların belirmesi doğru yolda olduğunuzun işareti.

Pano için sıfırdan panel yazmanız gerekmiyor: grafana.com/grafana/dashboards üzerinde “Proxmox” araması yapıp Flux sorgusu kullanan bir panoyu içe aktarabilirsiniz. InfluxQL ile yazılmış panolar bu veri kaynağıyla boş görünür.

uptime.homelab.local: Bir Şeyin Düştüğünü Grafiğe Bakarak Öğrenmemek

Grafana bir şeyin nasıl gittiğini gösterir; ayakta olup olmadığını sormak ayrı bir iştir. Uptime Kuma’yı Docker’sız, doğrudan Node.js ile kuruyoruz:

pct enter 113
apt update && apt install -y git curl build-essential
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
git clone https://github.com/louislam/uptime-kuma.git /opt/uptime-kuma
cd /opt/uptime-kuma
npm run setup

npm run setup bağımlılıkları kurup arayüzü derler; eski bir makinede birkaç dakika sürer. Servis tanımı:

# /etc/systemd/system/uptime-kuma.service
[Unit]
Description=Uptime Kuma
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/uptime-kuma
ExecStart=/usr/bin/node server/server.js
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now uptime-kuma

Arayüz http://192.168.1.13:3001 adresinde ve ilk açılışta yönetici hesabını sizden ister.

Eklenecek kontroller:

DNS satırı diğerlerinden farklı bir şey ölçüyor ve tablodaki en değerli satır o. dns konteynerine Ping atmak makinenin ayakta olduğunu söyler; dnsmasq çökmüş ya da yapılandırması bozulmuşsa Ping yine yeşil kalır. DNS monitörü ise cevabın kendisini ister — servisi ölçer, makineyi değil. Aynı mantıkla Proxmox için hem Ping hem :8006 kontrolü var: biri makineyi, diğeri arayüzü.

Yanlış Yapılırsa: Sessizce Bozulan Dört Yer

1. DNS’i tek başına bırakmak. dns konteyneri kapalıyken ve host’un ikinci nameserver’ı yokken küme yönetilemez hale gelir — güncelleme yapamaz, şablon indiremez, konteyner oluşturamazsınız. Host’ta ikinci sunucu olarak yukarı akışı bırakın ve --onboot 1‘i her konteynerde koruyun.

2. Günlüğü UDP ile kuyruksuz göndermek. Kayıp sessizdir: gönderen tarafta hata yok, alan tarafta satır yok. Fark ancak bir arızadan sonra günlüğe baktığınızda ortaya çıkar ve o noktada geri getirmenin yolu kalmamıştır.

3. İzleyiciyi izlediği şeyin üstünde çalıştırmak. Uptime Kuma da diğer dördü gibi aynı Proxmox host’unda duruyor. Host çökerse bütün servisler düşer ve uyarı gönderecek olan da düşer. Homelab için bunun makul çözümü, dışarıdan (telefondan, ücretsiz bir izleme servisinden) tek bir “Proxmox arayüzü açık mı” kontrolü eklemektir.

4. Grafana’da sorgu dilini varsayılanda bırakmak. InfluxDB 2.x kurup Grafana’da InfluxQL seçmek, veri akıyorken bile boş panolar üretir. Sorunun metrik toplamada değil sorgu dilinde olduğunu anlamak saatler alabilir.

Doğrulama: Dört Katman da Gerçekten Çalışıyor mu?

Servislerin active (running) görünmesi kurulduklarını kanıtlar, çalıştıklarını değil. Dördünü de sırayla sınıyoruz:

# 1. İsim çözümleme
dig @192.168.1.8 uptime.homelab.local +short     # 192.168.1.13
dig @1.1.1.1 uptime.homelab.local +short         # boş dönmeli

# 2. Merkezî günlük — Proxmox host'undan gönder, log konteynerinde ara
logger -t denemesi "dogrulama"
sleep 2
pct exec 109 -- grep dogrulama /var/log/uzak/proxmox/denemesi.log

# 3. Metrik — son beş dakikada veri var mı
pct exec 111 -- influx query --org homelab \
  'from(bucket:"proxmox") |> range(start: -5m) |> limit(n: 5)'

Dördüncü adım okuma değil tatbikat, ve tek gerçek testtir:

pct stop 112

Uptime Kuma’nın Grafana monitörü bir dakika içinde kırmızıya dönmeli ve bildirim kanalınıza düşmeli. Dönmüyorsa izleme kurulmuştur ama çalışmıyordur — ve bunu ilk gerçek arızada öğrenmek istemezsiniz. Bildirim geldikten sonra geri alın:

pct start 112

Alternatif: LXC Yerine Sanal Makine Kurmak

VM tercih ederseniz, oluşturma adımını hızlandırmak için daha önce hazırladığım iki otomasyondan yararlanabilirsiniz.

Ansible ile Otomatik Template Oluşturma

Yazdığım Ansible rolü ile Ubuntu 22.04, Debian 12 ve CentOS 7 için otomatik template üretebilirsiniz: ansible-role-vm-proxmox. Böylece VM oluşturma adımını template dosyasından Full Clone alarak çok daha hızlı yaparsınız.

OpenTofu ile VM Sağlama

Hazırladığım main.tf dosyasında ubuntu_vm_1 ve ubuntu_vm_2 bloklarını çoğaltabilirsiniz. RAM, CPU, ağ ve SSH anahtarı gibi bölümleri istediğiniz gibi düzenleyebilirsiniz. Dosyadaki kritik kısım provider "proxmox" bloğudur; Proxmox sunucusunun adresini ve API bilgilerini buraya doğru girmeniz gerekir.

Ama unutmayın: bu iki yöntem de sanal makine oluşturur, LXC konteyner kadar hafif olmayacaktır.

Sonuç

Homelab’i bir veri merkezi gibi kurmanın karşılığı, ilk arıza anında alınır:

• Uygulamalardan önce temel gelir. İsim çözümleme, merkezî log, metrik ve erişilebilirlik izleme kurulmadan eklenen her servis, bozulduğunda elle kurcalanarak aranır. Dördü de yukarıdaki tabloda birer satır ve toplamda birkaç saatlik iş.
• Servis başına LXC, VM’den ucuzdur. Çekirdeği paylaştıkları için tek işlik servisleri konteynerde çalıştırmak aynı donanımdan kat kat fazla servis çıkarır; izolasyona ihtiyaç duyduğunuz yerde VM’e geçersiniz.
• Elle kurulan makine, kurulduğu gün doğrudur. Template + Ansible ya da OpenTofu ile sağlanan makine, altı ay sonra yeniden kurulabilir olduğu için doğru kalır.
• İzlemenin kurulmuş olması çalıştığı anlamına gelmez. Bir servisi bilerek durdurup bildirimin geldiğini görene kadar izleme sistemi bir varsayımdır; pct stop ile yapılan otuz saniyelik tatbikat bu varsayımı ölçüye çevirir.

İzleme tarafını kavramsal olarak toparlamak için Monitoring nedir ve neden önemlidir, Prometheus tabanlı bir alternatif kurulum için Adım adım Prometheus, Grafana ve Node Exporter kurulumu yazılarına bakabilirsiniz.