Master Node

 Master Node (ili Control Plane) je ključna komponenta u Kubernetes klasteru. On je mozak klastera i upravlja svim operacijama, kao što su raspoređivanje resursa, skaliranje aplikacija, praćenje stanja, i druge administrativne funkcije.

---

🧠 Šta Master Node radi?

Master Node je odgovoran za centralizovano upravljanje celokupnim Kubernetes klasterom. Sastoji se od nekoliko ključnih komponenti koje omogućavaju funkcionisanje i koordinaciju:

1. API Server (kube-apiserver):

• API server je glavna tačka interakcije sa Kubernetes klasterom.

• Svi zahtevi (kao što su komande kubectl ili automatske interakcije sa klasterom) idu kroz API server.

• API server obrađuje ove zahteve, usmerava ih prema odgovarajućim Kubernetes komponentama, i vraća rezultate korisnicima.

2. Controller Manager (kube-controller-manager):

• Kontroler menadžer upravlja kontrolerima koji prate stanje klastera i prate promene u sistemu.

• Na primer, kada se desi nešto neočekivano, kao što je nestanak Pod-a, kontroler će pokušati da ga ponovo pokrene (npr. za Deployment, ReplicaSet).

• Takođe, prati resurse poput Node-ova, Pod-ova, Service-ova i Deployment-a.

3. Scheduler (kube-scheduler):

• Scheduler je odgovoran za raspoređivanje Pod-ova na Worker Node-ove.

• On prati dostupne resurse na Node-ovima (CPU, RAM, itd.) i odlučuje na kojem Node-u će se pokrenuti određeni Pod.

• Scheduler takođe uzima u obzir faktore kao što su affinity, taints, tolerations, itd.

4. etcd:

• etcd je distribuirani key-value store koji čuva sve podatke o stanju klastera (kao što su podaci o Podovima, Service-ima, Node-ovima, konfiguracijama, itd.).

• To je osnova za pohranu podataka u Kubernetesu.

• Ako se podaci u klasteru promene (npr. ako se doda novi Pod ili obriše neki servis), etcd se ažurira.

5. Cloud Controller Manager (ako je korišćenje u cloud okruženju):

• Ova komponenta omogućava Kubernetesu da komunicira sa cloud servisima (AWS, GCP, Azure) i automatski upravlja resursima u cloudu.

• Na primer, može automatski da kreira load balancer-e, cloud storage i druge resurse u cloud okruženju.

---

🛠️ Kako Master Node funkcioniše?

1. Korisnik ili Kubernetes kontroler šalje komande preko kubectl ili druge interfejse ka API server-u.

2. API server proverava i validira zahtev, i prosleđuje ga odgovarajućim komponentama (Scheduler, Controller Manager, itd.).

3. Scheduler odlučuje gde da rasporedi Pod.

4. Controller Manager prati stanje klastera i menja ga ako je potrebno (npr. pokreće novi Pod ako postojeći nije dostupan).

5. etcd čuva sve promene u stanju klastera.

---

🧩 Analogija:

Zamisli da je Master Node kao menadžer fabrike. On prati sve procese, usmerava radnike (Pod-ove), i odlučuje šta treba da se desi u svakom trenutku. Kada nešto pođe po zlu (npr. radnik (Pod) se pokvari), menadžer (Master) će doneti odluku o tome kako da to popravimo.

---

⚠️ Napomena:

• Master Node ne pokreće direktno Podove (to rade Worker Node-ovi). Međutim, on upravlja svim operacijama klastera.

• U većim klasterima možeš imati više Master Node-ova za visoku dostupnost (HA), što znači da će klaster ostati operativan čak i ako jedan Master Node padne.

Šta je Node u Kubernetesu?

 Node je fizički ili virtuelni računar na kojem se pokreću Podovi u Kubernetes klasteru. Node-ovi predstavljaju radnu jedinicu klastera i svaki Node u klasteru pokreće Kubernetes komponente koje omogućavaju pokretanje i upravljanje aplikacijama.

Ukratko: Node = računar koji pokreće Podove u klasteru.

---

🔧 Šta Node radi?

Svaki Node ima nekoliko ključnih komponenti:

1. Kubelet – Agent koji pokreće na svakom Node-u i brine se da su Podovi pokrenuti prema specifikacijama.

2. Kube Proxy – Odgovoran za mrežno rutiranje unutar klastera.

3. Container Runtime – Softver koji omogućava pokretanje kontejnera (npr. Docker, containerd).

---

🧠 Ključne karakteristike Node-a:

• Svaki Node može da pokreće više Podova.

• Node-ovi mogu biti "master" ili "worker":

  • Master Node (ili Control Plane) upravlja celokupnim klasterom, raspoređuje resurse, prati stanje.

  • Worker Node (obično više) pokreće Podove koji čine aplikacije.

---

📋 Prikaz Node-a:

Možeš da proveriš sve Node-ove u klasteru koristeći komandu:

kubectl get nodes

Izlaz može izgledati ovako:

NAME           STATUS   ROLES    AGE   VERSION
node1          Ready    master   5d    v1.24.0
node2          Ready    <none>   5d    v1.24.0
node3          Ready    <none>   5d    v1.24.0

• STATUS pokazuje stanje Node-a (da li je spreman, preopterećen, itd.)

• ROLES prikazuje ulogu Node-a: master ili worker

---

🗺️ Analogija:

Zamisli da je Kubernetes klaster kao fabrika, a Node je kao mašina u toj fabrici koja obavlja deo posla. Dok fabriku (klaster) vodi menadžer (master), mašina (Node) radi konkretan posao — pokreće proizvodnju (Podove).

---

🧩 Kako Node komunicira sa Kubernetesom?

• Kubelet na Node-u šalje informacije o stanju Podova nazad Master Node-u.

• Kube Proxy omogućava da Podovi komuniciraju međusobno i sa spoljnim svetom.

• Container Runtime (kao Docker) pokreće kontejnere koji su unutar Podova.

Šta je Deployment? Šta je StatefulSet?

 Deployment je Kubernetes objekat koji upravlja stateless aplikacijama, tj. aplikacijama koje ne zavise od svog identiteta i ne čuvaju stanje lokalno.

Ukratko: Deployment = automatsko skaliranje i obnavljanje "običnih", zamjenjivih Podova.

🔧 Šta radi Deployment:

• Pokreće željeni broj identičnih Podova

• Osigurava da uvek ima tačno toliko aktivnih replika

• Automatski pravi rolling update (postepeno ažuriranje verzije)

• Vraća prethodnu verziju ako nešto krene po zlu

---

📄 Primer YAML fajla:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Ovo pravi 3 identična Nginx Poda koji mogu da se zamene bilo kad.

---

🧱 Šta je StatefulSet?

StatefulSet je tip kontrolera za stateful aplikacije — one koje:

• Trebaju stalni identitet (ime, IP adresu)

• Imaju stalne podatke koji ne smeju da se izgube

• Zahtevaju redosled pokretanja i gašenja

Ukratko: StatefulSet = koristiš kad ti treba stabilan, predvidiv red i podaci.

---

🧠 Ključne razlike naspram Deployments:

	Deployment	StatefulSet
Imena Podova	Nasumična	Fiksna (ime-0, ime-1...)
IP adrese	Mogu da se promene	Ostaju stabilne
Volume	Deljeni	Svaki Pod ima svoj volume
Skaliranje	Bilo kojim redosledom	U strogoj sekvenci
Primeri upotrebe	Web serveri, API	Baze, Kafka, Redis

---

📄 Primer YAML za StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: "redis"
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis
        volumeMounts:
        - name: redis-data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

Svaki Pod (redis-0, redis-1, redis-2) ima svoj lični disk (PVC) koji se ne briše automatski.

---

🗺️ Analogija:

• Deployment = vojska identičnih robota, lako zamenjivih.

• StatefulSet = red zaposlenih sa imenima, radnim stolom i ličnim fiokama.

Šta su Volume u Kubernetesu?

 Volume u Kubernetesu je mehanizam za čuvanje podataka koje kontejneri mogu da koriste, nezavisno od životnog veka kontejnera.

Ukratko: Volume omogućava deljenje i/ili očuvanje podataka između kontejnera ili između restarta.

---

❗Zašto je to važno?

• Kada kontejner umre, sve što je bilo u njegovom fajl sistemu nestaje.

• Volume omogućava:

  • trajno skladištenje podataka

  • deljenje fajlova između kontejnera u istom Podu

  • učitavanje konfiguracija i tajni (ConfigMap, Secret)

  • spajanje sa eksternim skladištima (npr. NFS, AWS EBS, GlusterFS, itd.)

---

🧩 Kako se koristi?

Volume se definiše na nivou Pod-a i povezuje sa kontejnerima pomoću volumeMounts.

📄 Primer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-volumom
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: moj-vol
      mountPath: /usr/share/nginx/html
  volumes:
  - name: moj-vol
    emptyDir: {}

U ovom primeru:

• Volume moj-vol je tipa emptyDir (prazan folder koji traje koliko i Pod)

• Montiran je u /usr/share/nginx/html u kontejneru

---

📚 Tipovi volumena (neki od najčešćih):

Tip	Opis
emptyDir	Privremeni folder koji traje koliko i Pod
hostPath	Fajl ili folder sa host mašine
configMap	Volume baziran na ConfigMap
secret	Volume baziran na Secret
persistentVolumeClaim (PVC)	Povezuje se sa trajnim skladištem (disk, NFS, cloud)
nfs, awsElasticBlockStore, gcePersistentDisk, csi	Eksterno skladište

---

🧠 Persistent Volume (PV) i PVC

Za dugotrajno skladištenje koristi se sistem:

• PV (PersistentVolume) – apstrakcija fizičkog skladišta

• PVC (PersistentVolumeClaim) – zahtev aplikacije za prostor

Pod ne koristi direktno PV, već pravi PVC koji se onda mapira na PV.

---

🗺️ Analogija:

Zamisli kontejner kao kamp-prikolica. Sve što je unutra nestaje kad je pomeriš. Volume je kao eksterni kontejner (šupa) ili hard disk koji možeš da priključiš i koristiš nezavisno od same prikolice.

Šta je Secret u Kubernetesu?

 Secret je Kubernetes objekat za čuvanje poverljivih podataka, kao što su:

• lozinke

• API tokeni

• SSH ključevi

• TLS sertifikati

Ukratko: Secret = bezbedan način za čuvanje osetljivih informacija u klasteru.

---

🧠 Zašto se koristi?

• Da ne hardcoduješ poverljive podatke u YAML fajlove, slike (image-e), ili promenljive okruženja.

• Kubernetes može da upravlja tim podacima sigurnije nego sa običnim ConfigMap-ovima:

  • Sekreti se čuvaju u base64 kodiranju

  • Mogu se šifrovati na disku (ako je tako podešeno)

  • Imaju stroža pravila pristupa (RBAC)

---

📄 Primer Secret fajla:

apiVersion: v1
kind: Secret
metadata:
  name: moj-secret
type: Opaque
data:
  username: dXNlcm5hbWU=       # base64("username")
  password: cGFzc3dvcmQ=       # base64("password")

Možeš napraviti Secret i komandno:

kubectl create secret generic moj-secret \
  --from-literal=username=username \
  --from-literal=password=password

---

🧩 Kako se koristi u Podu?

1. ✅ Kao environment promenljive:

spec:
  containers:
  - name: moj-kontejner
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: moj-secret
          key: username

2. 📁 Kao fajlovi u volume-u:

spec:
  volumes:
  - name: secret-vol
    secret:
      secretName: moj-secret
  containers:
  - name: moj-kontejner
    volumeMounts:
    - name: secret-vol
      mountPath: /etc/secret

Fajlovi /etc/secret/username i /etc/secret/password biće dostupni u kontejneru.

---

⚠️ Napomena:

• Iako su "secure", Secret-i su base64 kodirani, a ne enkriptovani po defaultu.

  • Šifrovanje na disku moraš eksplicitno da uključiš.

• Pristup Secret-ima treba kontrolisati putem RBAC pravila.

Šta je ConfigMap u Kubernetesu?

 ConfigMap je objekat koji služi za čuvanje konfiguracionih podataka (u obliku parova ključ-vrednost), odvojeno od same aplikacije.

Ukratko: ConfigMap = spoljašnja konfiguracija za tvoju aplikaciju.

---

🧠 Zašto se koristi?

• Omogućava da aplikacija ostane ista, a konfiguracija se menja bez rekreiranja slike (image-a).

• Idealno za stvari kao što su:

  • Konfiguracioni fajlovi

  • API ključevi (ne osjetljivi – za sensitive podatke koristi Secret)

  • Promenljive okruženja (env vars)

  • Argumenti komandne linije

---

📄 Primer ConfigMap fajla:

apiVersion: v1
kind: ConfigMap
metadata:
  name: moja-konfiguracija
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

---

🧩 Kako se koristi?

Možeš je "ubaciti" u Pod na nekoliko načina:

1. ✅ Kao environment promenljive:

spec:
  containers:
  - name: moj-kontejner
    image: myapp
    envFrom:
    - configMapRef:
        name: moja-konfiguracija

U kontejneru ćeš imati promenljive APP_MODE=production, LOG_LEVEL=info.

2. 📁 Kao fajlovi u volume-u:

spec:
  volumes:
  - name: config-vol
    configMap:
      name: moja-konfiguracija
  containers:
  - name: moj-kontejner
    volumeMounts:
    - name: config-vol
      mountPath: /etc/config

Ključevi iz ConfigMap biće fajlovi u /etc/config/.

---

⚠️ Napomena:

• ConfigMap nije za sensitive podatke (lozinke, tokeni) → za to koristi Secret.

• Ako promeniš ConfigMap, moraš restartovati Pod da bi video nove vrednosti (osim ako koristiš reload mehanizam u aplikaciji).

---

🗺️ Analogija:

Zamisli da ti je aplikacija kao motor, a ConfigMap kao tabla sa dugmićima (parametrima) koje menjaš bez rastavljanja motora.

Šta je Ingress u Kubernetesu?

 Ingress je objekat koji omogućava spoljašnji HTTP/HTTPS pristup aplikacijama koje rade unutar klastera – preko URL-a i domena.

Ukratko: Ingress = pametan HTTP/HTTPS "ulaz" u tvoj klaster.

---

🧱 Kako radi?

• Radi iznad Service-a.

• Koristi se da route-uje (prosleđuje) HTTP(S) zahteve ka odgovarajućim servisima na osnovu:

  • URL putanje (npr. /app1, /admin)

  • Naziva domena (npr. app.mojsa.it, admin.mojsa.it)

• Radi preko Ingress kontrolera – softvera koji obrađuje pravila iz Ingress objekta (npr. nginx ingress controller, traefik, HAProxy...)

---

🧠 Zašto je važan?

• Bez Ingress-a moraš da koristiš NodePort ili LoadBalancer za svaki servis posebno.

• Sa Ingress-om možeš da imaš jednu tačku ulaza (npr. jedan domen) i da rutiraš sve unutar klastera elegantno.

---

📄 Primer YAML fajla:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: primer-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.mojdomen.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: moj-servis
            port:
              number: 80

Ovo znači:

• Svi zahtevi na http://app.mojdomen.com/ biće prosleđeni moj-servis na portu 80.

Šta je Service u Kubernetesu?

 Service (servis) je stalna mrežna apstrakcija koja omogućava pristup Podovima putem fiksne IP adrese i DNS imena, bez obzira na to da li se Podovi menjaju.

Drugim rečima:

Service je "stalna adresa" za pristup aplikaciji koja se pokreće u Podovima, iako se ti Podovi menjaju u pozadini.

---

🧠 Zašto je to važno?

Kada koristiš Deployment ili ReplicaSet, Kubernetes stalno menja Podove (npr. zbog restarta, skaliranja…). Svaki Pod dobije novu IP adresu, pa ne možeš direktno da se oslanjaš na njih.

Zato koristiš Service kao "fiksni ulaz" koji automatski preusmerava saobraćaj na ispravne Podove.

---

⛓️ Kako radi?

Service koristi label selector da pronađe Podove:

apiVersion: v1
kind: Service
metadata:
  name: moj-servis
spec:
  selector:
    app: moja-aplikacija
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Ovo znači:

• Pronalazi sve Podove koji imaju label: app=moja-aplikacija

• Kada neko pristupi ovom servisu na portu 80, saobraćaj se šalje na 8080 unutar Podova

• ClusterIP znači da je servis dostupan samo unutar klastera

---

🧭 Tipovi servisa:

Tip	Dostupan gde?	Opis
ClusterIP	Unutar klastera	Podrazumevani
NodePort	Sa spolja preko nodova	Otvara port na svakom nodu
LoadBalancer	Spolja kroz cloud load balancer	Koristi eksterni IP (npr. u AWS, GCP)
ExternalName	DNS alias za eksterni servis	Nema port forwarding

---

🗺️ Analogija:

Zamisli da imaš restoran (Podove) koji se stalno seli u različite lokale, ali uvek zadrži isti broj telefona (Service). Kada klijent pozove taj broj, automatski se poveže sa trenutnom lokacijom.

Šta je Pod u Kubernetesu?

Pod je najmanja i najosnovnija jedinica koju Kubernetes može da "pokrene". To je objekat koji predstavlja jedan ili više kontejnera (najčešće jedan), koji dele istu mrežu i sistem fajlova.

Ukratko:

• Pod = kontejner(i) + mreža + skladište + metadata

• Kontejneri unutar jednog poda:

  • Dele IP adresu i portove

  • Dele volume-ove (fajl sistem)

  • Pokreću se zajedno na istom Node-u

---

Zašto postoji Pod ako koristi kontejnere?

Kubernetes ne upravlja direktno kontejnerima (npr. Docker), već koristi Podove da ih "spakuje" zajedno. To omogućava napredne scenarije, kao što su:

• Glavni kontejner + pomoćni (sidecar) kontejner (npr. za logovanje, proxy, backup, itd.)

• Lakše restartovanje, skaliranje i održavanje

---

Vizuelna analogija:

Zamisli Pod kao sobu, a kontejnere kao ljude u toj sobi:

• Ljudi (kontejneri) mogu međusobno da pričaju bez odlaska napolje (mreža)

• Imaju zajednički sto (fajl sistem) gde svi mogu da ostavljaju stvari

• Ako se seli soba, svi idu zajedno

Primer YAML fajla za Pod:

apiVersion: v1
kind: Pod
metadata:
  name: moj-pod
spec:
  containers:
  - name: moj-kontejner
    image: nginx
    ports:
    - containerPort: 80

Ovo definiše Pod koji pokreće jedan Nginx kontejner.

Šta je Pi Network i koje mogućnosti nudi?

Pi Network je inovativna digitalna valuta koja omogućava korisnicima da je "rudare" (zarade) direktno sa svojih mobilnih telefona, bez potrebe za moćnim računarima ili velikom potrošnjom energije, kao što je to slučaj sa Bitcoinom.

Ova mreža je osmišljena sa ciljem da učini kriptovalute dostupnim svima, bez tehničkih prepreka koje inače prate rudarenje. Korišćenjem Pi aplikacije, korisnici mogu svakodnevno potvrđivati svoj doprinos mreži i na taj način zarađivati Pi tokene.

Kako funkcioniše Pi Network?

Za razliku od tradicionalnih kriptovaluta koje koriste skupe i energetski intenzivne metode rudarenja, Pi Network se oslanja na koncept poverenja između korisnika. Sistem koristi mobilnu aplikaciju kroz koju korisnici jednostavno potvrđuju svoju aktivnost u mreži, bez potrebe za dodatnom računalnom snagom.

Koje mogućnosti nudi?

1. Jednostavno rudarenje – Dovoljno je da imate aplikaciju i svakodnevno je aktivirate kako biste nastavili sa zarađivanjem Pi tokena.

2. Sigurne transakcije – Kada mreža bude u potpunosti razvijena, korisnici će moći da koriste Pi za plaćanje robe i usluga.

3. Podrška za razvoj aplikacija – Programeri mogu kreirati aplikacije unutar Pi ekosistema, gde mogu omogućiti korisnicima da koriste Pi kao način plaćanja ili interakcije unutar aplikacije.

4. Mogućnost razmene – Pi Network je 20. februara 2025. godine prešao na otvoreni mainnet, omogućavajući korisnicima da trguju Pi tokenima na globalnom nivou. Ovaj prelazak je omogućio listiranje Pi tokena na više kripto berzi, uključujući OKX, što je dovelo do značajnog rasta cene Pi tokena.

Kako se koristi Pi?

Trenutno, svi korisnici mogu da rudare Pi besplatno, ali mogu i da ga troše na različite proizvode i usluge u okviru Pi ekosistema.

Da li je Pi legitiman?

Pi Network nije klasična investicija, već eksperiment u stvaranju nove digitalne valute. Projekat je razvijen od strane tima sa Stenford univerziteta i okuplja globalnu zajednicu korisnika koji učestvuju u njegovom razvoju.

Pi Network je pokušaj da se kriptovalute učine dostupnijima i korisnijima za svakodnevne ljude. Iako još uvek nije u potpunosti razvijen, projekat pruža mogućnost da se uključite u svet digitalnih valuta bez početnog ulaganja i tehničkog znanja.

Kako rudariti Pi token?

Evo kako da započnete rudarenje Pi tokena u nekoliko jednostavnih koraka:

1. Preuzmite Pi Network aplikaciju

Prvi korak je preuzimanje zvanične Pi Network aplikacije sa Google Play Store-a (za Android) ili App Store-a (za iOS).

2. Registrujte nalog

Nakon instalacije, potrebno je da kreirate nalog koristeći:

• Broj telefona ili Facebook nalog (preporučuje se telefon zbog sigurnosti).
• Izaberete korisničko ime i lozinku.

3. Unesite pozivni kod

Pošto je Pi baziran na mreži poverenja, potreban vam je pozivni kod od nekog ko već koristi Pi. Ako nemate kod, možete koristi sledeći: ficaaca.

Korišćenjem pozivnog koda prilikom registracije, možete rudariti 25% više Pi tokena u odnosu na osnovnu brzinu rudarenja!

4. Pokrenite rudarenje

Jednom kada ste registrovani, kliknite na dugme munje ⚡ u aplikaciji da biste pokrenuli rudarenje. Proces traje 24 sata, nakon čega morate ponovo pritisnuti dugme da biste nastavili rudarenje.

5. Pozovite druge korisnike

Pi Network omogućava da povećate brzinu rudarenja tako što ćete pozvati druge korisnike da se pridruže preko vašeg koda.

6. Verifikujte svoj identitet (KYC)

Da biste kasnije preneli rudarske nagrade na Mainnet i koristili Pi za transakcije, potrebno je proći KYC verifikaciju (dokaz identiteta) unutar aplikacije.

7. Koristite Pi za transakcije

Kada prikupite dovoljno Pi tokena i prođete KYC, moći ćete da ih koristite za kupovinu robe i usluga ili da ih prebacite u svoj Pi Wallet kada funkcionalnosti mreže postanu potpuno operativne.

HAProxy

Instalacija HAProxy-a

Instalacija Haproxy-a može se razlikovati ovisno o operativnom sustavu koji koristite. Evo koraka za instalaciju Haproxy-a na nekim od popularnih operativnih sustava:

Ubuntu / Debian:

Koristite sljedeće naredbe u terminalu:

1. Ažuriranje paketnih izvora:

   sudo apt-get update

2. Instalacija Haproxy-a:

   sudo apt-get install haproxy

3. Potvrda instalacije:

   haproxy -v

CentOS / RHEL:

1. Instalacija EPEL repozitorija (ako već nije instaliran):

   sudo yum install epel-release

2. Instalacija Haproxy-a:

   sudo yum install haproxy

3. Potvrda instalacije:

   haproxy -v

Konfiguracija:

Nakon instalacije, konfiguracijski datoteku možete pronaći obično na putanji /etc/haproxy/haproxy.cfg. Otvorite tu datoteku koristeći uređivač teksta (npr. nano, vim, gedit) i prilagodite konfiguraciju prema vašim potrebama.

Nakon što izmijenite konfiguracijsku datoteku, sačuvajte promjene i pokrenite Haproxy servis. Ovisno o distribuciji Linuxa, naredbe za upravljanje servisom mogu biti različite:

• Za Ubuntu / Debian:

  sudo systemctl start haproxy

  sudo systemctl enable haproxy # Ovo osigurava da se Haproxy pokrene pri pokretanju sustava

• Za CentOS / RHEL:

  sudo systemctl start haproxy

  sudo systemctl enable haproxy

Nakon ovih koraka, Haproxy bi trebao biti uspješno instaliran i pokrenut na vašem sustavu. Možete pristupiti konfiguracijskoj datoteci kako biste prilagodili postavke prema vašim zahtjevima i potrebama aplikacije koju želite balansirati.

HAProxy sa više domena 

Host tabela na haproxy:

/etc/hosts

	127.0.0.1 localhost 127.0.1.1 router
	140.82.58.111 server1
	95.179.179.5 server2
	199.247.28.183 server3
	# The following lines are desirable for IPv6 capable hosts
	::1 localhost ip6-localhost ip6-loopback
	ff02::1 ip6-allnodes
	ff02::2 ip6-allrouters

/etc/haproxy/haproxy.cfg

global
	log /dev/log local0
	log /dev/log local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon
	defaults
	log global
	mode http
	option httplog
	option dontlognull
	timeout connect 10s
	timeout client 60s
	timeout server 60s
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http
	frontend http_in
	mode http
	option httplog
	bind *:80
	option forwardfor
	acl host_server1 hdr(host) -i entroinfo.xyz
	acl host_server1 hdr(host) -i www.entroinfo.xyz
	acl host_server2 hdr(host) -i sub1.kubehttps.xyz
	acl host_server3 hdr(host) -i sub2.kubehttps.xyz
	use_backend http_server1 if host_server1
	use_backend http_server2 if host_server2
	use_backend http_server3 if host_server3
	backend http_server1
	mode http
	option httplog
	option forwardfor
	server server1 server1:80
	backend http_server2
	mode http
	option httplog
	option forwardfor
	server server2 server2:80
	backend http_server3
	mode http
	option httplog
	option forwardfor
	server server3 server3:80
	frontend https_in
	mode tcp
	option tcplog
	bind *:443
	acl tls req.ssl_hello_type 1
	tcp-request inspect-delay 5s
	tcp-request content accept if tls
	acl host_server1 req.ssl_sni -i entroinfo.xyz
	acl host_server1 req.ssl_sni -i www.entroinfo.xyz
	acl host_server2 req.ssl_sni -i sub1.kubehttps.xyz
	acl host_server3 req.ssl_sni -i sub2.kubehttps.xyz
	use_backend https_server1 if host_server1
	use_backend https_server2 if host_server2
	use_backend https_server3 if host_server3
	backend https_server1
	mode tcp
	option tcplog
	option ssl-hello-chk
	server server1 server1:443
	backend https_server2
	mode tcp
	option tcplog
	option ssl-hello-chk
	server server2 server2:443
	backend https_server3
	mode tcp
	option tcplog
	option ssl-hello-chk
	server server3 server3:443

Provera konfiguracije

Da biste provjerili ispravnost konfiguracijske datoteke Haproxyja, koristite naredbu haproxy -c -f /putanja/do/konfiguracijske/datoteke/haproxy.cfg.

Ova naredba provjerava ispravnost sintakse konfiguracijske datoteke bez pokretanja Haproxyja. Ako postoji bilo kakva pogreška u sintaksi datoteke, ova naredba će prikazati poruku o pogrešci koja će vam pomoći u otklanjanju problema.

Primjer naredbe za provjeru konfiguracije Haproxyja:

haproxy -c -f /etc/haproxy/haproxy.cfg

Zamijenite /etc/haproxy/haproxy.cfg stvarnom putanjom do vaše konfiguracijske datoteke.

Ako nema pogrešaka pri provjeri konfiguracije, naredba će vratiti poruku poput "Configuration file is valid". Ako postoje greške, dobit ćete odgovarajuću poruku koja će vam pomoći da identificirate i ispravite problem u konfiguracijskoj datoteci.

Global

Opcije pod globalnom sekcijom u konfiguracijskoj datoteci Haproxy-a postavljaju globalne parametre i postavke koje se primjenjuju na razini cijelog Haproxy servisa. Ovdje su neke od glavnih opcija koje se mogu postaviti unutar globalne sekcije:

1. log: Definira način na koji se logovi generiraju i gdje se šalju. Primjer: log /dev/log local0.

2. chroot: Postavlja direktorij u kojem će Haproxy promijeniti korijenski direktorij nakon pokretanja, čime se osigurava dodatna sigurnost.

3. stats socket: Definira putanju do Unix socketa za interakciju s Haproxy statistikama.

4. stats timeout: Postavlja vremensko ograničenje za prikupljanje statistika.

5. user i group: Postavlja korisničko ime i grupu pod kojima će Haproxy pokrenuti procese radi sigurnosti.

6. daemon: Ova opcija govori Haproxyju da se pokrene kao daemon, tj. kao pozadinski proces.

7. maxconn: Postavlja maksimalni broj aktivnih konekcija koje Haproxy može obraditi.

Primjer globalne sekcije u Haproxy konfiguraciji:

global
    log /dev/log    local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 2000

Ove opcije se koriste za postavljanje globalnih parametara Haproxyja koji će se primijeniti na sve frontend i backend sekcije definirane u konfiguracijskoj datoteci. Važno je prilagoditi ove opcije prema potrebama i zahtjevima vaše infrastrukture i aplikacije kako bi Haproxy radio kako treba i osigurao optimalnu učinkovitost i sigurnost.

Defaults

Opcija defaults u Haproxy konfiguraciji služi za postavljanje zadanih vrijednosti i parametara koji se primjenjuju na sve backendove i frontendove ako se ti parametri eksplicitno ne definiraju u određenim sekcijama.

Evo nekoliko ključnih opcija koje se često koriste unutar defaults sekcije:

1. mode: Postavljanje načina rada (mode) koji se koristi za obradu prometa, poput http, tcp, health, itd. Primjer: mode http.

2. log: Definira način generiranja logova za promet koji prolazi kroz Haproxy.

3. timeout connect: Postavlja vremensko ograničenje za uspostavu TCP konekcije.

4. timeout client: Postavlja vremensko ograničenje za čekanje na aktivnost od klijenta.

5. timeout server: Postavlja vremensko ograničenje za čekanje na aktivnost od servera.

6. option: Postavljanje specifičnih opcija koje kontroliraju ponašanje Haproxyja. Na primjer, option http-server-close zatvara HTTP sesiju nakon odgovora od servera.

Primjer defaults sekcije u Haproxy konfiguraciji:

defaults
    mode http
    log global
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms
    option http-server-close

Ove opcije postavljaju zadane vrijednosti za sve frontendove i backendove ako se ove vrijednosti ne definiraju eksplicitno unutar pojedinačnih sekcija. To omogućuje jednostavnije i konzistentnije upravljanje parametrima kao što su vremenska ograničenja, načini rada i opcije za sve dijelove konfiguracije Haproxyja. Važno je prilagoditi ove zadane vrijednosti prema potrebama i zahtjevima vašeg sustava kako bi Haproxy radio kako treba i osigurao optimalnu učinkovitost.