top of page
Search

Uge 46: Selfhost Kafka

  • Writer: Kenneth H Sørensen
    Kenneth H Sørensen
  • Nov 13
  • 4 min read

Updated: Nov 15


ree

Redpanda and Tailscale


Jeg har sat en Kafka-kompatibel løsning op i mit homelab, fordi vores Product Owner nævnte, at Trackunit bruger Kafka i produktionen.


Målet var at få praktisk erfaring med event streaming, så vores projekt kan afspejle den teknologi, de arbejder med virksomheden.





Introduktion


Formålet med at bygge et self-hosted event-streaming setup var at få en enkel, stabil message broker til udvikling for både teamet og mig selv.


Da PO gerne ville have Kafka falgt valget på Redpanda fordi det er Kafka-kompatibelt, enkelt at køre og kræver få ressourcer.


  • Samme type teknologi som Trackunit bruger

  • En løsning der fungerer lokalt og samtidig kan tilgås af teamet uden cloud-afhængighed

  • Understøtter

    • Ingestion → AI → videre behandling

    • AI → andre services om status på behandling af billeder

  • Hurtigt at installere og nemt at administrere



Infrastruktur: Lenovo + Proxmox + VM


  • Lenovo ThinkCentre med Proxmox

  • Ubuntu Server VM dedikeret til Redpanda

  • Redpanda kører som Docker-container

  • Tailscale til privat mesh-netværk og sikkerhed (wireguard)


  • Fordele: isolation, snapshots, ressourcestyring, nem opgradering

  • Ulemper: Single-node, ingen replikation, ingen garanti for availability



Netværk: Cloudflared forsøg og skift til Tailscale


Jeg havde behov for ekstern adgang til VM'en, da vi i teamet sidder remote ift. hinanden.


Cloudflared (afprøvning):

  • Cloudflared tunneller god til HTTP(S), men ikke til Kafka-protokollen

  • Resultat: rpk kunne ikke oprette forbindelse gennem tunnelen


Tailscale (løsningen):

  • WireGuard-baseret mesh-netværk

  • Direkte IP-adgang uden port forwarding

  • Stabil TCP-trafik til Redpanda

  • Enkelt at sætte op og fungerer hver gang



Deployment af Redpanda i Docker


Redpanda blev installeret via Docker for at holde miljøet fleksibelt og isoleret.


  • Hurtig installation og opdatering

  • Ingen eksterne komponenter som Zookeeper

  • God ydeevne i single-node udviklingsmiljøer

  • Let at styre via rpk CLI



Opsætning


Installation af Tailscale på VM:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Dette giver VM'en en Tailscale IP (f.eks. 100.97.224.69).


Konfiguration af Redpanda med Tailscale IP:


docker run -d \
 --name=redpanda \
 -p 9092:9092 \
 -p 9644:9644 \
 -v redpanda-data:/var/lib/redpanda/data \
 docker.redpanda.com/redpandadata/redpanda:latest \
 redpanda start \
 --overprovisioned \
 --smp 1 \
 --memory 1G \
 --kafka-addr internal://0.0.0.0:9092 \
 --advertise-kafka-addr internal://100.97.224.69:9092

Det vigtigste er --advertise-kafka-addr der fortæller Redpanda at annoncere Tailscale IP'en til clients i stedet for localhost.



Topics og rpk-styring


Jeg oprettede de topics, der bruges i vores pipeline.


rpk topic create tu.images.uploaded --partitions 4 --replicas 1
rpk topic create tu.recognition.completed --partitions 4 --replicas 1

ree

Læring

Jeg startede med et lavere antal partitioner på hver, men opdaterede dem til 4, for at teste, hvordan Redpanda håndtere flere partitioner og prøve at forstå Kafka parallelisering.


  • I et single broker-setup giver flere partitioner muligheder for flere consumers læser samtidig (det tænker jeg dog ikke vi får i Trackunit projektet)

  • ObjectKey som messageKey sikrer at events for samme billede altid går til samme partition

  • AI-servicen kan stadig konsumere events stabilt, uanset hvilken partition de ligger i

  • 1 replika = ingen backup-kopier (kun én kopi af dataen / ingen redundans)



Jeg lavede en tegning, til et tidligere blogindlæg, af min forståelse af Kafka arkitekturen.

Den er mere kompliceret end det jeg har sat op nu, men giver et billede af hvordan parallelisering kunne foregå hvis der var flere partitioner, samt replikering på tværs af brokers, hvis man har mere end en.

ree


Integration med microservices


Opsætningen blev koblet direkte til vores pipeline.


  • Ingestion producerer events til tu.images.uploaded

    • ved ConfirmUpload use case

  • AI-service konsumerer, udfører behandling og publicerer til tu.recognition.completed, som andre services kan lytte på



Adgang for teammedlemmer


For at give andre udviklere adgang til Redpanda uden at eksponere min VM offentligt, bruger vi Tailscale.


Tailscale giver hver udvikler en privat IP-adresse og etablerer et direkte, krypteret mesh-netværk mellem deres maskine og Redpanda-VM’en.


Opsætning for et teammedlem:

  • Teammedlem installerer Tailscale på sin egen maskine

  • Jeg sender en invitation til Tailscale-netværk

  • Når invitationen accepteres, får teammedlemmet sin egen Tailscale-IP (100.x.x.x)

  • Teammedlemmet kan nu nå Redpanda-VM’en via dens Tailscale-IP på port 9092, uden port forwarding eller SSH-adgang


Fordele:

  • Ingen adgang til selve VM’en, kun til Redpanda-ports

  • Ingen eksponering af computeren eller Proxmox-serveren

  • Teammedlemmer kan producere og konsumere events fra deres egen maskine



Sikkerhed ift transport


Selvom Redpanda ikke er konfigureret med SSL/TLS, er al trafik krypteret gennem Tailscale's WireGuard-protokol.


Tailscale/WireGuard:

  • End-to-end kryptering mellem alle enheder

  • Private keys forbliver altid på den enkelte enhed

  • Automatisk key rotation

  • Ingen data går gennem Tailscale's servere (kun koordinering)

  • ACL (Access Control Lists) der fungerer som network policies


Dette betyder at Kafka-trafikken (port 9092) er fuldt krypteret mellem clients og broker, selvom Redpanda selv kører uden SSL.


I et prod miljø ville man typisk også konfigurere:

  • SASL authentication på Kafka-niveau (brugernavn og password for at connecte)

  • SSL/TLS direkte i Redpanda (dvs. i stedet for at lade tailscale stå for kryptering)

  • Network policies og firewall rules


Til et udviklingsmiljø giver Tailscale tilstrækkelig sikkerhed uden kompleksiteten af at administrere certificates og authentication.





Refleksion


Opsætningen var mere udfordrende end forventet.

Jeg prøvede først Cloudflare Tunnel (både HTTP og TCP), men ingen af dem virkede med Kafka.

Min broker sender sin addresse til klienter, men kunne ikke nås gennem tunneller.


Tailscale var langt mindre kompliceret.


Det tog længere tid end planlagt, men gav en dybere forståelse af event streaming på netværksniveau end en managed cloud-løsning ville have givet.





Ressourcer


Apache ZooKeeper (kræves af kafka IKKE redpanda)

Redpanda

Tailscale

Docker


Proxmox



bottom of page