Unul din lucrurile pe care le neglijezi când construiești un homelab e rețeaua. Cumperi hardware, instalezi Proxmox, ridici VM-uri — și între timp totul merge pe un switch de 1Gbps și pe router-ul de la ISP. La un moment dat realizezi că transferurile între noduri sunt limitate de rețea, nu de disk sau CPU, și că ar fi cazul să faci lucrurile cum trebuie.

Iată cum arată rețeaua de acasă după câteva iterații.

Hardware-ul de rețea

Întregul stack e TP-Link Omada — un ecosistem gestionat centralizat printr-un controller hardware dedicat:

  • ER605 v2.0 — router/gateway
  • OC200 — Omada Hardware Controller, gestionează întregul stack
  • SG2008P v3.20 — switch managed PoE 8 porturi – 4 alimenteaza AP-urile, 1 alimenteaza OC200
  • EAP653 x2 — AP-uri Wi-Fi 6 (etaj 2 și parter 2)
  • EAP265 HD x2 — AP-uri Wi-Fi 5 (etaj 1 și parter 1)

OC200 e un controller hardware dedicat — un dispozitiv mic cât o cutie de chibrituri mai mare care rulează Omada Controller fără să consume resurse din Proxmox sau să depindă de el. Avantajul față de varianta software: e întotdeauna activ independent de starea cluster-ului, ceea ce contează dacă faci modificări de rețea exact când un nod Proxmox e down.

Avantajul unui stack integrat: configurezi un VLAN o dată în controller și se propagă automat pe switch și pe toate AP-urile. Roaming-ul Wi-Fi între cele 4 AP-uri funcționează transparent — nu simți trecerea de la un AP la altul. Față de soluția de a cumpăra echipamente de la producători diferiți și a le gestiona separat, diferența de confort e semnificativă.

2.5Gbps — unde contează

Nu toată rețeaua are 2.5Gbps — nu are sens. Telefoanele, laptopurile și dispozitivele IoT se descurcă perfect pe 1Gbps. Dar între nodurile Proxmox și QNAP, lățimea de bandă contează direct în performanța homelab-ului:

  • Live migration între nodurile Proxmox — copierea memoriei RAM a unui VM în câteva secunde, nu zeci
  • Backup-uri VM pe NFS spre QNAP — un backup de 50GB în 3 minute, nu 7
  • Plex direct play de pe QNAP spre clienți cu cerințe mari de bandwidth (4K remux, Dolby Atmos)
  • Transferuri de fișiere mari spre/dinspre NAS

Switch-urile de 2.5Gbps sunt luate de pe AliExpress — mă zgârcesc intenționat aici. Un switch unmanaged de 2.5Gbps cu 5-8 porturi costă 80–150 RON pe AliExpress față de 400–600 RON pentru echivalentul de brand. Pentru traficul intern de homelab, diferența de calitate nu justifică diferența de preț.

Topologia: nodurile Proxmox (pve00, pve01, pve02) și QNAP-ul sunt conectate la switch-urile de 2.5Gbps. Switch-urile de 2.5Gbps sunt conectate uplink la SG2008P-ul Omada care face managementul VLAN-urilor. Am mai incercat sa folosesc adaptoare de retea (tot de pe aliexpress) pentru nodurile proxmox dar rezultatele au fost dezamagitoare, asa ca am abandonat si le tin in cutia cu maimute.

3 VLAN-uri — separare clară

Rețeaua e împărțită în trei zone cu politici de trafic diferite:

VLAN Default — uz general

Laptopuri, telefoane, televizoare, calculatoare. Trafic standard spre internet, fără restricții interne.

VLAN IoT

Becuri smart, prize inteligente, camere, termostate, orice dispozitiv care “sună acasă” în mod dubios. Izolat de rețeaua principală — un dispozitiv IoT compromis nu are acces la laptopuri sau la NAS. Poate ieși pe internet dar nu poate comunica cu celelalte VLAN-uri.

Aceasta e poate cea mai importantă decizie de securitate dintr-un homelab. Dispozitivele IoT au firmware actualizat rar, vulnerabilități cunoscute și producători care dispar sau abandonează suportul. Le dai acces la internet pentru că au nevoie să funcționeze, dar le izolezi de restul rețelei.

VLAN Sandbox/HomeLab

Nodurile Proxmox, QNAP, VM-urile și LXC-urile din cluster. Acces la internet controlat, comunicare liberă între componente. Separat de rețeaua de uz general pentru că un experiment care merge prost (un container care consumă tot bandwidth-ul, un VM care face broadcast storms) nu afectează restul casei.

ER605 face routing între VLAN-uri cu reguli explicite — ce poate vorbi cu ce e definit clar, nu implicit.

Diagrama rețelei

Internet
    │
  ER605
    │
  SG2008P Switch Omada
    ├── VLAN Default  ──► Laptopuri, telefoane, TV
    ├── VLAN IoT      ──► Becuri, camere, smart home
    └── VLAN HomeLab  ──► Proxmox + QNAP
              │
    ┌─────────┴──────────┐
    │                    │
Switch 2.5G         Switch 2.5G
(AliExpress)        (AliExpress)
    │                    │
pve00  pve01         pve02  QNAP
                           TS-464

OC200 — Omada Hardware Controller (independent)

AP-uri Omada (4x) — toate VLAN-urile propagate wireless
  EAP653 Etaj 2
  EAP653 Parter 2
  EAP265 Etaj 1
  EAP265 Parter 1

Ce funcționează bine

OC200 ca controller hardware dedicat — independent de cluster-ul Proxmox, mereu activ, consum neglijabil. Îți dă vizibilitate completă pe tot stack-ul: câți clienți sunt pe fiecare AP, ce bandwidth consumă, uptime per dispozitiv.

VLAN-urile prin controller — configuri o dată, se propagă pe switch și pe toate AP-urile automat. Dacă adaugi un AP nou, preia automat configurația VLAN existentă.

2.5Gbps intern — transferurile între Proxmox și QNAP sunt limitate acum de QNAP, nu de rețea. Switch-urile ieftine de pe AliExpress nu au dat nicio problemă în utilizare reală.

Ce aș schimba

Switch-urile de 2.5Gbps de pe AliExpress sunt unmanaged — nu pot face trunking VLAN pe ele. Asta înseamnă că traficul de homelab și traficul de management merg pe același cablu fizic spre SG2008P, unde se separă. Funcționează, dar nu e elegant. La o viitoare iterație aș lua un switch managed de 2.5Gbps — există opțiuni TP-Link TL-SG105-M2 la ~200 RON care fac trunking VLAN și s-ar integra mai curat în stack-ul Omada.

Altfel — rețeaua funcționează exact cum ar trebui. Izolarea IoT dă liniște, 2.5Gbps intern face homelab-ul considerabil mai rapid, și gestionarea centralizată prin OC200 elimină nevoia de a accesa fiecare dispozitiv separat.

Posturi din aceeași serie:

Totul a pornit de la un programator Hunter cu 2 zone care funcționa de ani buni. Simplu, not smart, fiabil — dar limitat. Când am avut nevoie de încă două zone (picuratoare) și de control pe WiFi, l-am înlocuit cu un switch Tuya de 4 canale cumpărat cu sub 100 RON de pe aliexpress. A mers excelent.

Între timp a apărut nevoia de o a cincea zonă — inca un un picurator pe grădină — rezolvată cu un Sonoff SWV-BSP, o electrovalvă inteligentă pentru apă cu Zigbee 3.0 integrată în HA prin Zigbee. Tocmai când credeam că e gata, s-a stricat un Iritrol Life DC de la aspersoarele din fata casei: consuma bateria în 1-2 săptămâni, indiferent ce faceam. Soluția: am tras fir, am schimbat solenoidul și l-am conectat la o priză smart. Zona 6 e pregătită în cod, așteptând switch-ul fizic definitiv.

Trei lumi diferite — Tuya WiFi, Zigbee 3.0 și o priză smart — fără nicio legătură între ele la nivel de protocol. Exact genul de situație în care Home Assistant strălucește: le unești pe toate într-un singur sistem, cu logică comună.

Dar automatizarea de bază — pornește zona X la ora Y — e banală. Ceea ce m-a interesat a fost să adaug valoare reală: știam din măsurători că apersoarele mele dau 0.4 L/m²/minut. De acolo a venit ideea: dacă știu debitul și știu temperatura prognozată, pot calcula exact cât trebuie să ud și pot ajusta duratele automat la începutul fiecărei săptămâni sau luni.

Hardware folosit

Setup-ul fizic e deliberat ieftin și simplu:

  • Tuya TYWB 4ch-RF — controlează zonele 1–4: Gazon Paul, Gazon Anca, Lateral Grădina, Copacii. Input AC/DC 7-32V/USB 5V, 10A per canal, 16A total, WiFi 2.4GHz + Bluetooth + 433MHz RF. Integrat în HA prin integrarea Tuya nativă.
  • Sonoff SWV-BSP — Electrovalvă inteligentă pentru apă, Zigbee 3.0 — zona 5, picuratorul din grădiniță. Controlează direct fluxul de apă, integrată în HA prin Zigbee.
  • Priză smart (zona 6, placeholder) — pentru Iritrol-ul stricat: solenoid nou pe 24vAC, fir tras, priză smart până la o soluție mai elegantă.

Total hardware pentru 5 zone active: sub 200 RON. Programatorul Hunter original costa mai mult și nu putea face jumătate din ce face sistemul actual. Cel iritrol life dc… 2 zone… doar 900 lei.

Arhitectura în Home Assistant

Sistemul folosește Irrigation Unlimited (HACS) ca motor de control al zonelor — nu pentru schedule-urile lui native, ci pentru comenzile manual_run și cancel pe care le apelează automatizările HA.

De ce această abordare și nu schedule-urile native IU? Pentru că avem nevoie de durate dinamice — calculate în funcție de temperatură și debit — care se schimbă săptămânal. Schedule-urile IU sunt statice prin natură. Automatizările HA cu manual_run permit transmiterea duratei calculate la momentul rulării.

ha-irigatii/
├── packages/
│   └── irigatie.yaml        # Entități, automatizări, senzori
└── lovelace/
    └── irigatie_dashboard.yaml  # Dashboard cu 3 pagini

Zonele de irigații

NrZonăHardwareStatus
1Gazon PaulTYWB 4ch-RF canal 1Activ
2Gazon AncaTYWB 4ch-RF canal 2Activ
3Lateral GrădinaTYWB 4ch-RF canal 3Activ
4CopaciiTYWB 4ch-RF canal 4Activ
5Picurator GrădinaSonoff SWV-BSP Zigbee 3.0Activ
6Irigații Față CasăPriză smart (Iritrol reparat)Pregătit, dezactivat

Zona 1 are două durate configurabile: normală și caniculă — mai lungă, activată automat când prognoza indică ≥3 zile cu maxime de peste 30°C în săptămâna următoare.

Planificarea automată

Fiecare zonă are o automatizare de schedule zilnic cu mai multe moduri selectabile din interfață:

  • Zile fixe — Lun+Joi, Mar+Joi+Sâm, Lun+Mie+Vin sau zilnic
  • Interval — o dată la X zile, bazat pe data ultimei irigări stocate în input_datetime
  • Dezactivat — oprire completă a schedule-ului pentru zona respectivă

Modul Interval e util pentru zone ca picuratorul sau copacii — nu au nevoie de ritmicitate fixă, ci de un interval minim între udări.

Bilanțul hidric — de unde vine valoarea reală

Acesta e miezul sistemului. Știind că gazonul consumă 0.4 L/m²/minut (măsurat cu testul casoletei — pui o cutie pe gazon în timpul irigării și măsori câți mm s-au acumulat în X minute), poți calcula exact cât udă sistemul per săptămână și cât ar trebui să ude în funcție de temperatură.

Formula necesarului e deliberat simplă:

necesar_saptamanal [L/m²] = temperatura_medie_maxime_7_zile [°C]

Calibrare: la 30°C medii → 30 L/m²/săptămână. E o aproximare, dar una care funcționează în practică — temperatura maximă e cel mai bun proxy simplu pentru evapotranspirație fără senzori de umiditate sol.

Zilnic la 07:00, o automatizare apelează weather.get_forecasts (Met.no, integrat nativ în HA) și calculează media maximelor zilnice pe 7 zile. Duminică seara la 21:00, verifică dacă săptămâna viitoare are caniculă (≥3 zile cu maxime ≥30°C).

Procentul acoperit — câte procente din necesarul calculat e acoperit de programul curent — e afișat în dashboard cu un gauge 0–150% per zonă de gazon.

Auto-ajustarea duratelor

Pasul următor față de simpla afișare a bilanțului: sistemul recalculează automat duratele de irigare la frecvența configurată (săptămânal, la 2 săptămâni sau lunar) pentru a menține bilanțul la ~100%.

durata [min/sesiune] = temperatura_medie_maxime / sesiuni_pe_sapt / debit_L_mp_min

Exemplu — Gazon Paul la 28°C, Lun+Joi, debit 0.4:
  → 28 / 2 / 0.4 = 35 min/sesiune

La 20°C:
  → 20 / 2 / 0.4 = 25 min/sesiune

Duratele au clamping per zonă (gazonul între 1–59 min, copacii între 5–120 min, picuratorul între 5–180 min) și pot fi activate/dezactivate individual per zonă. Zona 1 calculează și durata de caniculă cu un factor ×1.3.

Rezultat practic: vara, când temperaturile cresc, duratele cresc automat luni dimineața fără nicio intervenție manuală. Toamna, scad.

Dashboard-ul — 3 pagini responsive

Construit cu custom:layout-card și custom:button-card (HACS), responsive pe desktop, tabletă și telefon:

  • Pagina 1 — Control: butoane Start/Stop per zonă, timp total azi, toggle caniculă, grafic activitate ultimele 48h
  • Pagina 2 — Bilanț Hidric: gauge per zonă de gazon, deficit sau exces față de necesar
  • Pagina 3 — Configurare: ore start, durate, program, interval, debit măsurat, toggle auto-ajustare per zonă

O notă tehnică: today_duration din Irrigation Unlimited trackează doar sesiunile din schedule-urile native IU. Deoarece sistemul folosește manual_run din automatizări HA, today_duration rămâne 0. Soluția: senzori history_stats care citesc direct din istoricul HA, indiferent de modul de pornire al zonei.

Instalare rapidă

  1. Instalează din HACS: Irrigation Unlimited, button-card, layout-card
  2. Copiază packages/irigatie.yaml în <config>/packages/
  3. Activează packages în configuration.yaml: homeassistant: packages: !include_dir_named packages
  4. Înlocuiește entity ID-urile switch-urilor cu ale tale în secțiunea irrigation_unlimited:
  5. Restart complet HA (nu doar reload — input_number cu mode: box necesită restart)
  6. Calibrează debitul cu testul casoletei și setează input_number.zona_N_litri_mp_minut

Ce urmează

Compensare precipitații — datele sunt disponibile din același weather.get_forecasts (atributul precipitation per zi). Formula ar deveni necesar_ajustat = max(0, necesar - precipitatii_prognozate_mm). Dacă plouă marți, sistemul scade automat durata de joi.

Notificări push — când bilanțul hidric scade sub 70%, când caniculă se activează automat sau când auto-ajustarea modifică o durată cu mai mult de 10 minute.

Zona 6 (Gazon Față Casă) e deja pregătită în cod — entități, automatizări, bilanț hidric — dar dezactivată (enabled: false) până când switch-ul fizic e instalat.

Asta e primul meu proiect / repo pe Github aici: ha-irigatii

Pe undeva în adâncurile acestui site există un PDF din epoca dinozaurilor — Using Linux as a Router — care apare în Google Search Console pentru 192.168.4.256 cu aproape 500 de impresii pe an. Oamenii caută “linux router”, “linux as a router”, “configure linux as router” și ajung la un document scris probabil când eu configurăm routere cu floppy disk si mufa “din” pe tastatura…

Ideea în sine nu e rea. Linux poate face routing excelent dar în 2025 răspunsul corect la “ar trebui să folosesc Linux ca router acasă?” e aproape întotdeauna nu. Hai să vorbim despre când are sens și când nu.

Când Linux ca router chiar are sens

Am folosit pfSense — o distribuție BSD specializată pentru routing și firewall cu aceeași filosofie — în zeci de laboratoare de-a lungul anilor. Scenariile în care un router software pe hardware generic e alegerea corectă sunt foarte specifice:

Rețele de laborator izolate

Când construiești un lab cu mai multe rețele care nu trebuie să se vadă între ele — să zicem o rețea de management, una de producție și una de teste — ai nevoie de ceva care să controleze exact ce trafic trece între ele. Un router de raft nu îți dă granularitatea asta la un preț rezonabil. pfSense pe un VM Proxmox cu trei interfețe virtuale rezolvă problema elegant, fără hardware suplimentar.

În Proxmox, creezi bridge-uri separate pentru fiecare rețea, asignezi interfețe VM-ului pfSense și configurezi regulile de firewall exact cum ai nevoie:

# pfSense — exemplu reguli firewall prin shell
# Blochează traficul din rețeaua de test spre producție
pfctl -a "USER_RULE" -f /etc/pf.conf

# Verifici regulile active
pfctl -sr

# Verifici starea interfețelor
ifconfig vtnet0
ifconfig vtnet1

Publicarea de endpoint-uri din lab spre exterior

Ai un serviciu care rulează într-o rețea izolată și vrei să îl expui controlat spre o altă rețea sau spre internet? NAT + port forwarding configurabil granular, VPN site-to-site între lab-uri, reguli de routing bazate pe sursă sau destinație — pfSense face toate astea printr-o interfață web decentă sau direct din config.

# Verifici tabela de routing
netstat -rn

# Adaugi o rută statică spre o rețea de lab
route add -net 10.10.20.0/24 gw 192.168.1.1

# Activezi IP forwarding pe Linux vanilla
echo 1 > /proc/sys/net/ipv4/ip_forward
# Persistent în /etc/sysctl.conf:
# net.ipv4.ip_forward = 1

# Regulă NAT cu iptables pentru a masca traficul
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state \
  --state RELATED,ESTABLISHED -j ACCEPT

Scenarii enterprise sau ISP

VyOS, pfSense, OPNsense sau Linux cu FRRouting rulează pe servere dedicate în producție la ISP-uri și companii. Dacă ai nevoie de BGP, OSPF, MPLS sau routing dinamic complex, software-ul pe hardware commodity bate orice router SMB de pe raft ca funcționalitate per leu investit.

pfSense vs OPNsense vs Linux vanilla — pe scurt

pfSense (netgate.com) — bazat pe FreeBSD, cea mai matură soluție, interfață web completă, comunitate enormă, documentație excelentă. Gratuit pentru uz personal, versiunea comercială (pfSense Plus) pentru producție enterprise. Prima alegere pentru lab-uri.

OPNsense (opnsense.org) — fork pfSense din 2015, tot FreeBSD, interfață mai modernă, actualizări de securitate mai frecvente, Wireguard integrat nativ. Dacă începi de la zero azi, OPNsense e argumentabil alegerea mai bună.

Linux vanilla (iptables/nftables + iproute2) — maxim de control, zero GUI, configurezi totul din fișiere și comenzi. Are sens dacă știi ce faci sau dacă construiești ceva automatizat (Ansible, Terraform). Pentru un lab ocazional, pfSense/OPNsense sunt mult mai rapide de configurat.

De ce nu ții un PC ca router acasă

Și totuși, cu toată experiența asta cu pfSense, acasă am un TP-Link ER605 — un router dedicat de ~200 RON — și nu mă gândesc să îl înlocuiesc cu un Lenovo M715q sau orice altceva care are un ventilator.

Motivele sunt simple:

Consum de energie. Un mini-PC cu pfSense consumă între 15–30W în idle, non-stop, 24/7. ER605 consumă 8W maxim, mai puțin în practică. Diferența de 10–20W înseamnă 88–175 kWh pe an — la prețul actual al curentului în România, între 80–160 RON în plus pe factură anual, doar pentru privilegiul de a rula un router pe hardware de calculator.

Complexitate inutilă. Rețeaua de acasă nu are nevoie de BGP, OSPF sau firewall cu stateful inspection cu 50 de reguli. Are nevoie să funcționeze când dai drumul la Netflix sau când intri pe un apel video. Un router dedicat face asta și nu trebuie să îl repornești după un update de kernel.

Puncte de failure în plus. Un PC înseamnă un SSD care poate muri, un ventilator care se poate bloca, un OS care necesită update-uri și monitorizare. Routerul dedicat are firmware în flash, fără piese mobile, și rulează ani fără intervenție.

Ce folosesc acum — stack Omada

Rețeaua de acasă rulează pe un stack TP-Link Omada complet:

  • ER605 — router/gateway, dual WAN, VPN server, firewall de bază
  • Switch Omada — managed, VLAN-uri pentru separarea rețelei de homelab de cea de uz general
  • 4x AP-uri TP-Link Omada — Wi-Fi 6, roaming transparent între camere
  • Omada Controller (rulează ca VM pe Proxmox) — management centralizat pentru tot stack-ul

Avantajul unui ecosistem integrat: toate dispozitivele se văd în același panou de control, roaming-ul Wi-Fi funcționează fără să simți trecerea de la un AP la altul, VLAN-urile se configurează o dată și se propagă automat pe toate switch-urile și AP-urile.

ER605 face routing la gigabit fără transpirație, are VPN IKEv2/OpenVPN/L2TP integrat pentru acces din afară și costă cât o cină la restaurant. Nu are niciun motiv să fie înlocuit cu un PC.

Concluzie

Linux ca router în 2025 are locul lui — în lab-uri, în VM-uri Proxmox care conectează rețele izolate, în scenarii enterprise unde ai nevoie de routing dinamic complex. pfSense și OPNsense sunt unelte excelente și le recomand oricui construiește un homelab serios.

Dar pentru rețeaua de acasă — unde vrei să funcționeze totul fără să te gândești la el — un router dedicat de 150–300 RON e răspunsul corect. Mai ieftin pe termen lung, mai simplu, mai fiabil.

PDF-ul vechi din /beer/ rămâne acolo ca document istoric. Dacă ești curios cum arăta configurarea unui router Linux în era pre-pfSense, merită citit ca artifact dar nu folosit ca ghid în 2025.

Posturi din aceeași categorie:

Uptime Kuma este un tool dragut de monitorizare, face automat rapoarte SLA, monitorizeaza site-uri, este destul de util. Pentru a monitoriza ill.ro folosesc altceva (UptimeRobot), m-am gandit sa fie independent de homelab, ca daca pica homelab-ul nu mai imi zice nimeni ca a cazut site-ul…
Voi folosi ArgoCD pentru a testa si invata cum functioneaza acest tool… l-am instalat si pana acum e doar o interfata web… Asadar sa instalam cu ArgoCD.

Pentru pasii astia avem niste prerechizite:
1. Un share nfs pentru persistent storage (il foloseste uptime kuma ca sa tina minte tot ce face)
2. Un cont de github sau orice repo, eu o sa folosesc github ca inca nu am deployat asa ceva in homelab.
3. metalLB functional 🙂

1. Mai intai share-ul NFS: am folosit v3 pentru simplitate, am permis accesul full din reteaua de acasa, desigur in afara homelab-ului vom avea autentificare si altele. Am creat un share numit uptime-kuma.

Pe nodurile k8s (control/worker) vom instala nfs-common si testam daca share-ul nfs este disponibil si putem scrie pe el.

apt install -y nfs-common
mkdir /mnt/test-nfs
mount -t nfs -o nfsvers=3 IP_NFS:/uptime-kuma /mnt/test-nfs
touch testnfs
cd /mnt/test-nfs && ls

Ar trebui sa vedem fisierul. Daca e acolo, inseamna ca nodurile noastre pot accesa NFS, trecem mai departe.

2. Github. Facem un nou repo, o sa il numesc argoCD si vom crea intr-un director nou urmatoarele fisiere:

Prima oara facem un namespace, fisierul uptimekuma-namespace.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: uptime-kuma

Definim un persistent volume – uptimekuma-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-uptime-kuma
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=3
  nfs:
    path: /uptime-kuma
    server: IP_NFS #adresa ip a serverului nfs

Persistent volume claim uptimekuma-pvclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uptime-kuma-pvc
  namespace: uptime-kuma
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: slow

Definim serviciul – uptimekuma-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: uptime-kuma-tcp
  namespace: uptime-kuma
spec:
  type: LoadBalancer #nu specificam ip, lasam metallb sa aleaga pentru noi
  ports:
  - name: web-ui
    protocol: TCP
    port: 3001
    targetPort: 3001
  selector:
    app: uptime-kuma

Si in final, deployment-ul uptimekuma-deplyment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: uptime-kuma
  namespace: uptime-kuma
spec:
  selector:
    matchLabels:
      app: uptime-kuma
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: uptime-kuma
    spec:
      containers:
      - name: uptime-kuma
        image: louislam/uptime-kuma:1
        imagePullPolicy: IfNotPresent
        env:
        # only need to set PUID and PGUI because of NFS server
        - name: PUID
          value: "1000"
        - name: PGID
          value: "1000"
        ports:
        - containerPort: 3001
          name: web-ui
        resources:
          limits:
            cpu: 200m
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 128Mi
        livenessProbe:
          tcpSocket:
            port: web-ui
          initialDelaySeconds: 60
          periodSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /
            port: web-ui
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: data
          mountPath: /app/data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: uptime-kuma-pvc

Pasul 2, sa intram in ArgoCD, sa definim un repository si o aplicatie. Rezultatele ar arata ca in printscreen-urile de mai jos. Avem nevoie de 2-3 lucruri:
– repository URL: tip https sau cum vreti voi, si path-ul.
– project – o sa fie default, ca nu am altceva definit
– cluster – o sa aleaga automat clusterul pe care este instalat
– path: uptimekuma – e directorul unde am pus tot.
– sync: am lasat manual

Dupa ce accesezi aplicatia si dai click pe sync, argo o sa downloadeze yaml-urile din repo, din directorul ales si o sa inceapa sa le aplice.
Rezultatul ar trebui sa arate asa:

Teoretic ar trebui sa poti accesa uptime kuma, pe ip-ul pe care il aloca metallb… si sa vezi interfata.

Orice schimbare a yaml-urilor din github vor fi semnalate de ArgoCD. Daca ai pus sincronizarea pe automat ar trebui ca orice modificare faci sa fie deployata in Kubernetes automat, sa zicem ca modifici numarul de replici (pod-uri) pentru aplicatia ta.. sau faci un update… Mai jos exemplu:

“BestMan” m-a sfatuit sa ma uit si la ArgoCD. Rachete, magie, gitops, kubernetzi…
Sa incepem cu o traducere:

Argo CD este un instrument declarativ CICD pentru aplicațiile Kubernetes. Acesta utilizează stilul GitOps pentru a crea și gestiona clustere Kubernetes. Atunci când se fac modificări în configurația aplicației din Git, Argo CD o compară cu configurația aplicației care rulează și notifică utilizatorii pentru a sincroniza starea dorită cu cea actuală.
Argo CD a fost dezvoltat în cadrul proiectului Argo al Cloud Native Computing Foundation (CNCF), un proiect destinat în special gestionării ciclului de viață al aplicațiilor Kubernetes. Acest proiect include, de asemenea, Argo Workflow, Argo Rollouts și Argo Events. Fiecare dintre acestea rezolvă un set specific de probleme în procesul de dezvoltare agilă și contribuie la livrarea scalabilă și securizată a aplicațiilor Kubernetes.

Cumva in github pui yaml-urile, asta verifica ce e acolo si face treaba. Asta e magie, ca pana acum stateam cu 20j de fisiere yaml pe nodu de control si le pierdeam, le suprascriam, nu mai stiam care fisier e ce imi trebuie… nah, gandire de sysadmin.
Am deja cont de github, o sa fac un repo nou si o sa il folosesc pentru a instala “Uptime Kuma” cu ArgoCD.

Instalarea ArgoCD e simpla, am facut un namespace nou si am folosit manifestul lor.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Dupa 2-3 minute am vazut si podurile:

Mai devreme am pus MetalLB si as vrea sa il folosesc sa ajung la ArgoCD. Se poate folosi si nodeport dar e mai elegant asa, fara sa accesezi porturi ciudate. Dezavantajul pe care il vad eu pe termen lung o sa trebuiasca sa extinzi pool-ul de ip-uri folosit de metallb. Deci, revenim:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Teoretic acum ar trebui sa am ArgoCD publicat pe unu din ip-urile alea din loadbalancer, pe porturile 443 si 80.

O sa avem nevoie de parola (userul e admin). Avem o parola random creata la instalare…
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Accesam 192.168.111.220:80, user si parola avem. Iaca!

Avem ArgoCD functional, teoretic putem incepe sa il folosim.
Next post, instalare “Uptime Kuma” cu ArgoCD.