This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Infrastruktura

Wstęp do Opentofu

1: Sprzęt (HomeLab)

2: Architektura Sieciowa

3: Vault

4: Gitlab

5: HAProxy

6: Kubernetes

Infrastruktura stanowi fundament środowiska informatycznego w organizacji. Obejmuje wszystkie zasoby – fizyczne i wirtualne – które umożliwiają działanie systemów, usług i aplikacji. W nowoczesnych działach IT infrastruktura musi być automatyzowalna, skalowalna, bezpieczna i możliwa do odtworzenia.

📍

Infrastructure as Code (IaC) to podejście do zarządzania infrastrukturą IT, w którym zasoby są definiowane i utrzymywane za pomocą kodu, a nie manualnych operacji. Jednym z najczęściej wykorzystywanych narzędzi do implementacji IaC jest OpenTofu, rozwijany przez firmę HashiCorp. OpenTofu umożliwia automatyczne tworzenie, aktualizowanie oraz usuwanie zasobów w chmurze i środowiskach lokalnych, na podstawie deklaratywnych plików konfiguracyjnych.

Wdrażając podejście IaC z użyciem OpenTofu, należy przyjąć szereg kluczowych założeń projektowych, które zapewniają bezpieczeństwo, skalowalność oraz powtarzalność środowisk infrastrukturalnych.

Architektura projektu OpenTofu w `pl.rachuna-net`

Kod źródłowy projektu znajduje się pl.rachuna-net/infrastructure/opentofu.

# Przykładowy opis struktury projektu
pl.rachuna-net/infrastructure/opentofu
├── gitlab-profile                      # Documentation
├── home.rachuna-net.pl
├── iac-gitlab                          # IaC - Gitlab Management by terraform
├── modules                             # Terraform modules
│   ├── gitlab-group                    # Terraform module for menagment groups
│   ├── gitlab-project                  # Terraform module for menagment projects
│   ├── proxmox-container
│   ├── proxmox-download-container
│   ├── proxmox-vm
│   ├── routeros-bonding
│   ├── routeros-bridge
│   ├── routeros-dhcp-server
│   ├── routeros-dns
│   ├── routeros-ethernet
│   ├── routeros-system
│   ├── routeros-vlan
│   ├── vault-pki-cert-ca
│   └── vault-pki-cert-intermediate
├── proxmox
├── router.rachuna-net.pl
└── vault

Założenia projektów Infrastructure as a Code

Infrastructure as Code (IaC) to podejście do zarządzania infrastrukturą IT, w którym:

zasoby są definiowane i utrzymywane za pomocą kodu, a nie manualnych operacji.
automatyczne tworzenie, aktualizowanie oraz usuwanie zasobów w chmurze i środowiskach lokalnych, na podstawie deklaratywnych plików konfiguracyjnych.

1 - Sprzęt (HomeLab)

HomeLab: MikroTik + 3× Proxmox + Synology, opisany jako kod.

📍 Kontekst

Zbudowanie lokalnego HomeLab odwzorowujący małą produkcję (router MikroTik, klaster Proxmox, NAS), utrzymywany jako kod (OpenTofu + Ansible). Celem jest powtarzalność, HA i możliwość szybkiego odtworzenia środowiska pod K8S/CI/CD/observability.

Cel

Małe, trójwęzłowe środowisko Proxmox + centralny storage Synology + MikroTik jako rdzeń sieci.
Wzorzec pod IaC: definicje sieci, storage i VM/CT w repo pl.rachuna-net/infrastructure (moduły iac-mikrotik, iac-proxmox, iac-synology).
Gotowa baza pod klastry K8S, CI/CD, monitoring/logowanie i eksperymenty z bezpieczeństwem.

Założenia projektowe (IaC)

Automatyzacja provisioning/upgradow przez OpenTofu/Terraform; konfiguracja systemów i usług przez Ansible.
Sieć MikroTika (VLAN/bridge/DHCP/firewall) jako kod; testy zmian w CI przed wdrożeniem.
Wersjonowanie konfiguracji Proxmoxa, eksportów NFS, VIP-ów i adresacji; snapshoty i backupy opisane w repo.
Odtwarzalność: reinstalacja hostów + import z IaC = identyczne środowisko.

Sprzęt i platforma uruchomieniowa

Router MikroTik – brama WAN/LAN, terminacja VLAN, firewall, DHCP/DNS. Konfiguracja w iac-mikrotik.
Klaster Proxmox (3× mini PC) – hypervisor dla VM/LXC, HA, storage współdzielony NFS; hostuje bazowe usługi (Vault/Consul, HAProxy, GitLab Runner, monitoring).
NAS (Synology) – eksporty NFS dla Proxmoxa i pod przyszłe StorageClass K8S, repo backupów i obrazów VM.

Architektura sieciowa

Topologia gwiazdy: MikroTik łączy trzy node’y Proxmoxa i NAS; trunk z VLAN-ami do każdego węzła.
VLAN/bridge: segmenty mgmt, prod, lab, storage; DHCP per segment, separacja ruchu + reguły firewall.
Bonding na łączach do NAS (przepustowość + redundancja); VIP-y zarządzane IaC dla usług infrastrukturalnych.

Architektura logiczna

Proxmox (3×): VM/CT dla GitLab CE + Runners, Vault/Consul, HAProxy/Traefik, monitoring (Prometheus/Grafana/Loki/Promtail), K8S (jeśli uruchomiony).
NAS: NFS exports (prod/nonprod) dla VM/CT i przyszłych PV w K8S; harmonogram snapshotów i backup offsite.
MikroTik: routing/NAT, polityki międzysegmentowe, DHCP/DNS, logowanie zdarzeń do centralnego sysloga.

Diagram sprzętu i połączeń

flowchart LR
    R[Router MikroTik<br/>WAN + VLAN/Bridge]
    subgraph PVE["Klaster Proxmox"]
        N1[Node 1<br/>VM/CT]
        N2[Node 2<br/>VM/CT]
        N3[Node 3<br/>VM/CT]
    end
    S[NAS<br/>NFS/Backup]

    R --> N1
    R --> N2
    R --> N3
    R --> S
    S -. shared NFS .- N1
    S -. shared NFS .- N2
    S -. shared NFS .- N3

Observability, backup, DR

Monitoring/logi hostów i usług: Prometheus + Loki/Promtail (VM/CT) definiowane jako kod.
Backup: snapshoty VM/CT w Proxmox, kopie konfiguracji MikroTika, backup eksportów NFS (NAS + offsite).
DR: reinstalacja Proxmoxa, import konfiguracji z repo IaC, przywrócenie danych z NFS/backupów; procedury opisane w repo.

Podsumowanie

Router MikroTik daje kontrolę nad siecią, klaster 3× Proxmox zapewnia elastyczne zasoby i HA, a Synology spina storage oraz backup. Całość jest wersjonowana i wdrażana jako kod, więc środowisko można szybko odtworzyć i rozbudować o K8S, CI/CD oraz obserwowalność bez utraty spójności.

2 - Architektura Sieciowa

Architektura sieciowa

📍 Kontekst

Architektura została zaprojektowana w sposób:

modularny – każdy segment sieci ma jasno określoną funkcję,
skalowalny – możliwość dodawania kolejnych VLAN-ów i mostów,
bezpieczny – separacja ruchu klientów, serwerów, DMZ i storage,
wysokodostępny – bonding dla infrastruktury storage,
automatyzowalny – pełna konfiguracja utrzymywana jako kod.

---
config:
  theme: neo
  layout: dagre
---
flowchart LR
 subgraph ETH["Ethernet LAN"]
        ETH2["ether 2<br>(LAN-01)"]
        ETH3["ether 3<br>(LAN-02)"]
        ETH4["ether 4<br>(LAN-03)"]
        ETH9["ether 9<br>(LAN-08)"]
        ETH10["ether 10<br>(LAN-09)"]
  end
 subgraph VLAN2["VLAN"]
        VLAN2D["VLAN 10<br>(LAN-01)"]
        VLAN2I["VLAN 20 - DMZ<br>(LAN-01)"]
  end
 subgraph VLAN3["VLAN"]
        VLAN3D["VLAN 10<br>(LAN-02)"]
        VLAN3I["VLAN 20 - DMZ<br>(LAN-02)"]
  end
 subgraph VLAN4["VLAN"]
        VLAN4D["VLAN 10<br>(LAN-03)"]
        VLAN4I["VLAN 20 - DMZ<br>(LAN-03)"]
  end
 subgraph BRIDGE["BRIDGES"]
        BRIDGESTORAGE["BRIDGE-STORAGE"]
        BRIDGE2["BRIDGE-PROXMOX"]
        BRIDGE3["BRIDGE-VMS-DMZ"]
        BRIDGE4["BRIDGE-VMS-INTERNAL"]
        BRIDGE5["BRIDGE-CLIENTS"]
  end
 subgraph DHCP["DHCP SERVERS"]
        DHCPSTORAGE["BRIDGE-STORAGE"]
        DHCP2["BRIDGE-PROXMOX"]
        DHCP3["DHCP-VMS-DMZ"]
        DHCP4["DHCP-VMS-INTERNAL"]
        DHCP5@{ label: "<span style=\"color:\">DHCP-CLIENTS</span>" }
  end
 subgraph LB["Router"]
        ROU0[("router.rachuna-net.pl")]
        ETH1["ether 1<br>WAN"]
        ROUB1["BONDING-STORAGE"]
        ETH
        VLAN2
        VLAN3
        VLAN4
        BRIDGE
        DHCP
  end
 subgraph PROXMOX["PROXMOX CLUSTER"]
        PVE-S1["PVE-S3"]
        PVE-S2["PVE-S2"]
        PVE-S3["PVE-S1"]
  end
    WAN["WAN"] ==> ETH1
    ETH1 ==> ROU0
    DHCPSTORAGE ==> BRIDGESTORAGE
    BRIDGESTORAGE ==> ROUB1
    ETH2 ==> PVE-S1
    ETH3 ==> PVE-S2
    ETH4 ==> PVE-S3
    VLAN2D ==> ETH2
    VLAN3D ==> ETH3
    VLAN4D ==> ETH4
    VLAN2I ==> ETH2
    VLAN3I ==> ETH3
    VLAN4I ==> ETH4
    DHCP2 ==> BRIDGE2
    BRIDGE2 ==> ETH2 & ETH3 & ETH4
    BRIDGE3 ==> VLAN4I & VLAN2I & VLAN3I
    BRIDGE4 ==> VLAN2D & VLAN3D & VLAN4D
    DHCP3 ==> BRIDGE3
    DHCP4 ==> BRIDGE4
    DHCP5 ==> BRIDGE5
    ROUB1 ==> ETH9 & ETH10
    ETH9 ==> STORAGE["storage.rachuna-net.pl"]
    ETH10 ==> STORAGE

    DHCP5@{ shape: rect}
    ROUB1@{ shape: rect}
    style ETH fill:#C8E6C9, color: #000000
    style BRIDGE fill:#E1BEE7, color: #000000
    style DHCP fill:#FFCDD2, color: #000000
    click ETH2 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether2.tf?ref_type=heads"
    click ETH3 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether3.tf?ref_type=heads"
    click ETH4 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether4.tf?ref_type=heads"
    click ETH9 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether9.tf?ref_type=heads"
    click ETH10 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether10.tf?ref_type=heads"
    click VLAN2D "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether2-vlan-vms-internal.tf?ref_type=heads"
    click VLAN2I "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether2-vlan-vms-dmz.tf?ref_type=heads"
    click VLAN3D "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether3-vlan-vms-internal.tf?ref_type=heads"
    click VLAN3I "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether3-vlan-vms-dmz.tf?ref_type=heads"
    click VLAN4D "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether4-vlan-vms-internal.tf?ref_type=heads"
    click VLAN4I "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/vlan/ether4-vlan-vms-dmz.tf?ref_type=heads"
    click BRIDGESTORAGE "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bridge/bridge-storage.tf?ref_type=heads"
    click BRIDGE2 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bridge/bridge-proxmox.tf?ref_type=heads"
    click BRIDGE3 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bridge/bridge-vms-dmz.tf?ref_type=heads"
    click BRIDGE4 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bridge/bridge-vms-internal.tf?ref_type=heads"
    click BRIDGE5 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bridge/bridge-clients.tf?ref_type=heads"
    click DHCPSTORAGE "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/dhcp-servers/dhcp-storage.tf"
    click DHCP2 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/dhcp-servers/dhcp-proxmox.tf"
    click DHCP3 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/dhcp-servers/dhcp-vms-dmz.tf"
    click DHCP4 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/dhcp-servers/dhcp-vms-internal.tf"
    click DHCP5 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/dhcp-servers/dhcp-clients.tf"
    click ETH1 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/ethernet/ether1.tf?ref_type=heads"
    click ROUB1 "https://gitlab.rachuna-net.pl/pl.rachuna-net/infrastructure/opentofu/iac-mikrotik/-/blob/main/router.rachuna-net.pl/interfaces/bonding/bonding-storage.tf?ref_type=heads"
    linkStyle 7 stroke:#D50000,fill:none
    linkStyle 8 stroke:#D50000,fill:none
    linkStyle 9 stroke:#D50000,fill:none
    linkStyle 10 stroke:#2962FF,fill:none
    linkStyle 11 stroke:#2962FF,fill:none
    linkStyle 12 stroke:#2962FF
    linkStyle 17 stroke:#2962FF,fill:none
    linkStyle 18 stroke:#2962FF,fill:none
    linkStyle 19 stroke:#2962FF,fill:none
    linkStyle 20 stroke:#D50000,fill:none
    linkStyle 21 stroke:#D50000,fill:none
    linkStyle 22 stroke:#D50000,fill:none
    linkStyle 23 stroke:#2962FF,fill:none
    linkStyle 24 stroke:#D50000,fill:none

1. Węzeł centralny – router brzegowy

Centralnym elementem architektury jest router router.rachuna-net.pl, który pełni funkcję:

bramy wyjściowej do Internetu (WAN),
głównego punktu dystrybucyjnego sieci LAN,
terminatora VLAN,
koncentratora mostów (bridge),
serwera DHCP dla wydzielonych segmentów sieci.

Interfejs ether1 pracuje jako port WAN i zapewnia bezpośredni dostęp do sieci Internet. Pozostałe interfejsy Ethernet są wykorzystywane jako porty dostępowe (LAN) dla serwerów, urządzeń końcowych oraz infrastruktury pomocniczej.

2. Segmentacja sieci i VLAN

Architektura oparta jest na logicznym podziale sieci przy użyciu VLAN-ów i mostów (bridge), co umożliwia separację ruchu oraz kontrolę bezpieczeństwa.

Na portach ether2, ether3 oraz ether4 skonfigurowano następujące sieci logiczne:

VLAN 20 – VMS-DMZ
VLAN 10 – VMS-INTERNAL

Porty te są fizycznie podłączone do węzłów wirtualizacyjnych:

pve-s3 – ether2 i ether3
pve-s2 – ether4

Ruch z tych interfejsów trafia do wspólnego węzła logicznego, który rozdziela go do trzech mostów:

BRIDGE-VMS-DMZ – dla maszyn wystawionych do strefy DMZ
BRIDGE-VMS-INTERNAL – dla maszyn wewnętrznych
BRIDGE-PROXMOX – sieć zarządzająca hypervisorami

Każdy z powyższych mostów posiada dedykowany serwer DHCP.

3. Sieć storage – agregacja łączy (bonding)

Bonding kart sieciowych został zastosowany w celu zwiększenia niezawodności oraz wydajności komunikacji z infrastrukturą storage, która stanowi krytyczny element całego środowiska.

Sieć storage jest całkowicie odseparowana logicznie od pozostałych segmentów (VMS, DMZ, CLIENTS), co minimalizuje ryzyko kolizji ruchu oraz wpływu obciążeń użytkowych na operacje magazynowania danych.

Most BRIDGE-STORAGE posiada dedykowany serwer DHCP, a ruch w tej sieci jest ograniczony wyłącznie do komunikacji pomiędzy węzłami klastra a systemem storage.

4. Sieć klientów (BRIDGE-CLIENTS)

Porty:

ether5 – router domowy
ether6 – drukarka
ether7 – nbo-002-mr
ether8 – nbo-001-mr

są podłączone do wspólnego mostu:

BRIDGE-CLIENTS

Most ten odpowiada za obsługę urządzeń końcowych i posiada oddzielny serwer DHCP dla klientów. Dodatkowo na ether5 zestawiony jest VLAN dedykowany dla ruchu klienckiego.

5. Sieć storage – agregacja łączy

Interfejsy:

ether9
ether10

zostały połączone logicznie w interfejs:

BONDING-STORAGE

Agregacja zapewnia:

większą przepustowość,
redundancję połączeń.

Interfejs bondingowy prowadzi do serwera storage, który następnie podłączony jest do:

BRIDGE-STORAGE

Most ten posiada dedykowany serwer DHCP dla sieci storage.

6. Warstwa serwerów DHCP

W architekturze funkcjonuje pięć niezależnych serwerów DHCP:

Segment	Most	Funkcja
VMS-DMZ	BRIDGE-VMS-DMZ	Adresacja maszyn w strefie DMZ
PROXMOX	BRIDGE-PROXMOX	Adresacja hypervisorów
VMS-INTERNAL	BRIDGE-VMS-INTERNAL	Adresacja maszyn wewnętrznych
CLIENTS	BRIDGE-CLIENTS	Adresacja urządzeń użytkowników
STORAGE	BRIDGE-STORAGE	Adresacja systemów magazynu danych

Taki podział gwarantuje pełną separację domen rozgłoszeniowych (broadcast) oraz umożliwia stosowanie niezależnych polityk bezpieczeństwa.

7. Dostęp do Internetu

Ruch wychodzący ze wszystkich mostów jest routowany przez:

ether1 (WAN) → Internet

Router pełni rolę centralnej bramy NAT oraz punktu kontroli bezpieczeństwa dla całej infrastruktury.

8. Zarządzanie konfiguracją (IaC)

Cała konfiguracja interfejsów, VLAN-ów, bondingów, mostów oraz serwerów DHCP zarządzana jest w modelu Infrastructure as Code przy użyciu OpenTofu/Terraform.

Każdy element topologii posiada odpowiadający mu plik konfiguracyjny, m.in.:

interfejsy Ethernet,
VLAN,
bonding,
bridge,
serwery DHCP.

Umożliwia to:

pełną wersjonowalność konfiguracji,
automatyczne odtwarzanie środowiska,
spójność konfiguracyjną między środowiskami.

3 - Vault

Architektura wysokiej dostępności HashiCorp Vault z backendem Consul na Proxmox (LXC)

📍 Kontekst

Celem architektury jest zapewnienie wysokiej dostępności (HA), spójności danych oraz bezpiecznego, kontrolowanego dostępu do usług:

HashiCorp Vault – centralny system zarządzania sekretami, certyfikatami i tożsamościami,
HashiCorp Consul – backend storage i mechanizm koordynacji dla Vault,

uruchomionych jako kontenery LXC na platformie Proxmox, z redundantną warstwą dostępową opartą o VIP i HAProxy.

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph LB["HA Layer"]
        VIP[("VIP")]
        HA1["HAProxy 1"]
        HA2["HAProxy 2"]
        HA3["HAProxy 3"]
  end
 subgraph CONSUL["Consul"]
        C1["consul<br>ct01005"]
        C2["consul<br>ct01006"]
        M4["consul<br>ct01007"]
  end
 subgraph VAULT["VAULT"]
        v1["vault<br>ct01005"]
        v2["vault<br>ct01006"]
        v3["vault<br>ct01007"]
  end
 subgraph PROXMOX["Proxmox"]
    direction TB
        CONSUL
        VAULT
  end
    U == "consul.rachuna-net.pl" ==> VIP
    VIP --> HA1 & HA2 & HA3
    HA1 == :8200 ==> VAULT
    HA2 == :8200 ==> VAULT
    HA3 == :8200 ==> VAULT
    HA1 == :8501 ==> CONSUL
    HA2 == :8501 ==> CONSUL
    HA3 == :8501 ==> CONSUL
    v1 == :8501 ==> C1
    v2 == :8501 ==> C2
    v3 == :8501 ==> M4
    U == "vault.rachuna-net.pl" ==> VIP

    C2@{ shape: rect}
    style CONSUL fill:#FFF9C4,color:#000000
    style VAULT fill:#C8E6C9,color:#000000
    linkStyle 0 stroke:#2962FF
    linkStyle 4 stroke:#AA00FF,fill:none
    linkStyle 5 stroke:#AA00FF,fill:none
    linkStyle 6 stroke:#AA00FF,fill:none
    linkStyle 7 stroke:#2962FF,fill:none
    linkStyle 8 stroke:#2962FF,fill:none
    linkStyle 9 stroke:#2962FF,fill:none
    linkStyle 10 stroke:#2962FF,fill:none
    linkStyle 11 stroke:#2962FF,fill:none
    linkStyle 12 stroke:#2962FF,fill:none
    linkStyle 13 stroke:#AA00FF,fill:none

1. Architektura logiczna

Architektura systemu składa się z czterech warstw:

Warstwa kliencka (External)
Warstwa wysokiej dostępności (HA Layer)
Warstwa wirtualizacji (Proxmox)
Warstwa aplikacyjna (Vault i Consul w LXC)

2. Warstwa kliencka (External)

2.1. Opis

Warstwa kliencka obejmuje:

administratorów infrastruktury,
aplikacje wewnętrzne i zewnętrzne,
systemy CI/CD oraz automaty infrastrukturalne.

Klienci komunikują się wyłącznie z warstwą HA poprzez nazwy DNS.

2.2. Punkty dostępu

Usługa	DNS	Port
Vault	`vault.rachuna-net.pl`	443 (https)
Consul	`consul.rachuna-net.pl`	443 (https)

3. Warstwa HA (VIP + HAProxy)

3.1. VIP (Virtual IP)

VIP stanowi pojedynczy, logiczny punkt wejścia do systemu:

przypisany do nazwy DNS,
zarządzany mechanizmem typu VRRP (np. keepalived),
niezależny od fizycznej instancji HAProxy.

📍

VIP zapewnia ciągłość dostępu w przypadku awarii pojedynczego węzła HAProxy.

3.2. HAProxy

Warstwa HA składa się z trzech instancji HAProxy:

HAProxy 1
HAProxy 2
HAProxy 3

Każda instancja jest równorzędna i bezstanowa.

Odpowiedzialności HAProxy:

rozdzielanie ruchu (load-balancing),
health-check backendów,
separacja ruchu Vault i Consul po portach,
opcjonalna terminacja TLS.

Mapowanie portów:

Port	Backend	Opis
8200	Vault	API oraz UI Vault
8501	Consul	HTTPS API oraz UI Consul

4. Warstwa wirtualizacji – Proxmox

4.1. Charakterystyka

Platforma Proxmox VE pełni rolę warstwy infrastrukturalnej:

hostuje kontenery LXC,
zapewnia izolację procesów,
umożliwia backup, snapshoty i migracje.

Vault i Consul działają jako niezależne kontenery LXC, uruchomione na różnych węzłach Proxmox (zalecane).

4.2. Model rozmieszczenia

Usługa	Kontener LXC	ID	Node
Consul,Vault	ubuntu	ct01005	pve-s1
Consul,Vault	ubuntu	ct01006	pve-s2
Consul,Vault	ubuntu	ct01007	pve-s3

📍

Rozmieszczenie kontenerów na różnych hostach Proxmox minimalizuje ryzyko awarii domenowej.

5. Warstwa aplikacyjna – Consul

5.1. Rola Consul

Consul pełni funkcję:

backend storage dla Vault,
mechanizmu koordynacji (leader election),
systemu utrzymania quorum.

5.2. Tryb pracy

Klaster Consul składa się z trzech instancji.
Wymagane quorum: minimum 2/3.
Komunikacja z Vault odbywa się po HTTPS (:8501).

📍

Brak quorum Consul skutkuje brakiem możliwości poprawnego działania Vault.

6. Warstwa aplikacyjna – Vault

6.1. Rola Vault

Vault odpowiada za:

bezpieczne przechowywanie sekretów,
zarządzanie PKI i certyfikatami,
wystawianie API do integracji aplikacyjnych.

6.2. Tryb HA

Vault działa w trybie High Availability:

jeden node aktywny (active),
pozostałe nody w trybie standby.

📍

Stan aplikacji oraz lock aktywnego noda są przechowywane w Consulu.

7. Komunikacja wewnętrzna Vault ↔ Consul

Kierunek	Protokół	Port
Vault → Consul	HTTPS	8501

Każda instancja Vault komunikuje się z klastrem Consul w celu:

zapisu i odczytu danych,
utrzymania locków HA,
synchronizacji stanu.

8. Wysoka dostępność i odporność na awarie

8.1. Eliminacja SPOF

Warstwa	Mechanizm
Dostęp zewnętrzny	VIP + 3× HAProxy
Vault	Active / Standby
Storage	Consul quorum
Infrastruktura	Proxmox + LXC

8.2. Scenariusze awarii

Awaria pojedynczego HAProxy → ruch przejmowany przez pozostałe instancje.
Awaria aktywnego Vault → automatyczne przełączenie na standby.
Awaria jednego węzła Consul → zachowane quorum.
Awaria hosta Proxmox → kontenery na pozostałych hostach pozostają dostępne.

4 - Gitlab

Architektura GitLab z pula GitLab Runnerów (LXC) z cache NFS

📍 Kontekst

Celem architektury jest zapewnienie spójnego i skalowalnego środowiska CI/CD, które:

obsługuje jednocześnie self-hosted GitLab CE oraz gitlab.com,
wykorzystuje pulę wielu runnerów (skalowanie horyzontalne wykonawców),
posiada współdzielony mechanizm cache dla pipeline’ów oparty o NFS,
upraszcza zarządzanie artefaktami cache oraz skraca czasy buildów.

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph Gitlab["GITLAB"]
        GITLAB["gitlab-ce"]
        GITLAB_COM["gitlab.com"]
  end
 subgraph RUNNER["GITLAB RUNNERS"]
        R1["Gitlab runner s1"]
        R2["Gitlab runner s2"]
        R3["Gitlab runner s3"]
  end
 subgraph STORAGE["NFS Storage"]
        NFSProd[("NFS Gitlab-Runner<br> Cache")]
        NFSProv["NFS Provisioner"]
  end
    GITLAB == <br> ==> R1
    U ==> GITLAB
    GITLAB ==> R2 & R3
    GITLAB_COM ==> R1 & R2 & R3
    R1 == /cache ==> NFSProv
    R2 == /cache ==> NFSProv
    R3 == /cache ==> NFSProv
    NFSProv == /volume1/gitlab-runner ==> NFSProd

    style RUNNER fill:#FFF9C4,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000
    linkStyle 0 stroke:#D50000,fill:none
    linkStyle 1 stroke:#00C853,fill:none
    linkStyle 2 stroke:#D50000,fill:none
    linkStyle 3 stroke:#D50000,fill:none
    linkStyle 4 stroke:#AA00FF,fill:none
    linkStyle 5 stroke:#AA00FF,fill:none
    linkStyle 6 stroke:#AA00FF,fill:none
    linkStyle 7 stroke:#FF6D00,fill:none
    linkStyle 8 stroke:#FF6D00,fill:none
    linkStyle 9 stroke:#FF6D00
    linkStyle 10 stroke:#FF6D00

1. Architektura logiczna

Architektura składa się z czterech warstw:

Warstwa kliencka (External)
Warstwa GitLab (GitLab CE + gitlab.com)
Warstwa wykonawcza CI/CD (GitLab Runners)
Warstwa storage cache (NFS)

2. Warstwa kliencka (External)

2.1. Opis

Warstwa kliencka obejmuje:

użytkowników (developerów, adminów),
automaty (np. integracje, webhooki, narzędzia deploymentowe),
procesy CI/CD inicjowane przez system GitLab.

2.2. Punkt wejścia

Użytkownicy komunikują się z:

GitLab CE (instancja self-hosted) – interfejs www, API, repozytoria,
gitlab.com – analogicznie, w zależności od repozytoriów/projektów.

3. Warstwa GitLab

3.1. GitLab CE (self-hosted)

Rola:

zarządzanie repozytoriami, merge requestami, issue tracking,
orkiestracja pipeline’ów i kolejkowanie jobów,
dostarczanie konfiguracji .gitlab-ci.yml do runnerów,
dystrybucja zadań do zarejestrowanych wykonawców (runnerów).

Interakcje:

GitLab CE przydziela zadania do runnerów R1, R2, R3.

3.2. gitlab.com

Rola:

publiczna lub osobna instancja GitLab wykorzystywana równolegle,
możliwość wykorzystywania tej samej puli runnerów (model „shared runners” w ujęciu infrastruktury użytkownika).

Interakcje:

gitlab.com deleguje zadania do runnerów R1, R2, R3 (o ile są zarejestrowane do tej instancji).

📍 Uwagi architektoniczne

Jeden runner może być zarejestrowany do wielu instancji, natomiast jest to decyzja operacyjna; wymaga jednoznacznych polityk bezpieczeństwa i separacji (patrz sekcja 10).

4. Warstwa wykonawcza CI/CD – GitLab Runners

4.1. Skład

Warstwa CI/CD obejmuje trzy instancje wykonawcze:

GitLab runner s1 (R1)
GitLab runner s2 (R2)
GitLab runner s3 (R3)

4.2. Rola

Runner odpowiada za:

pobranie joba z GitLab (CE lub gitlab.com),
wykonanie joba w wybranym executorze (np. Docker/Shell),
zarządzanie cache buildów oraz pobieraniem/zapisywaniem cache,
publikację wyników (logi, statusy, artefakty) do GitLab.

4.3. Skalowanie i dostępność

Architektura umożliwia skalowanie horyzontalne poprzez dodawanie kolejnych runnerów.
Awaria pojedynczego runnera zmniejsza przepustowość, ale nie zatrzymuje działania całego CI/CD.

5. Warstwa storage – NFS dla cache

5.1. Cel cache

Cache CI/CD jest wykorzystywany do przechowywania danych pośrednich (np. zależności, paczek, warstw buildów), aby:

skrócić czas pipeline’ów,
ograniczyć transfer i liczbę pobrań z Internetu,
ujednolicić środowisko pracy runnerów.

5.2. Komponenty

📍 NFS

NFS Provisioner:

udostępnianie wolumenów NFS dla runnerów w formie mountów /cache,
zapewnienie „warstwy pośredniej” w zarządzaniu zasobem NFS (zależnie od implementacji: statycznie lub dynamicznie).

NFS Gitlab-Runner Cache

fizyczny backend danych cache,
miejsce, gdzie finalnie lądują dane cache utrzymywane dla runnerów.

5.3. Mapowanie montowań

Runner	Mount	Backend
R1	`/cache`	NFS Provisioner → /volume1/cache
R2	`/cache`	NFS Provisioner → /volume1/cache
R3	`/cache`	NFS Provisioner → /volume1/cache

6. Przepływy (workflow)

6.1. Uruchomienie pipeline (GitLab CE)

Użytkownik wykonuje push/merge request do GitLab CE.
GitLab CE tworzy pipeline i planuje joby.
Jeden z runnerów (R1/R2/R3) pobiera joba.
Runner wykonuje job i używa /cache do odczytu/zapisu danych cache.
Wyniki joba są raportowane do GitLab CE.

6.2. Uruchomienie pipeline (gitlab.com)

Analogicznie, z tą różnicą, że orkiestracja pipeline zachodzi po stronie gitlab.com, natomiast wykonanie joba nadal jest realizowane przez runner’y użytkownika.

7. Wysoka dostępność i odporność na awarie

7.1. Założenia

Komponent	Odporność
Runners	odporność przez redundancję (min. 3 instancje)
GitLab CE	zależne od wdrożenia (poza zakresem tego diagramu)
Cache NFS	potencjalny SPOF, zależny od HA NFS (poza zakresem)

7.2. Krytyczne zależności

NFS jako cache: awaria NFS nie zatrzymuje całego CI/CD, ale może:
- wydłużyć pipeline’y,
- spowodować błędy jobów, jeśli pipeline zakłada istnienie cache lub brak tolerancji na brak mountu.

📍

Zalecane jest traktowanie NFS cache jako „performance layer”, a nie jako wymogu funkcjonalnego.

8. Wymagania bezpieczeństwa i separacji (zalecenia)

Jeżeli te same runnery obsługują jednocześnie GitLab CE i gitlab.com, należy przyjąć minimalny zestaw zasad:

separacja runnerów tagami (tags) i restrykcyjne rules/only po stronie projektów,
rozdzielenie executorów i środowisk uruchomieniowych (np. różne Docker daemony, izolacja hostów),
kontrola, co trafia do cache (ryzyko „cache poisoning” między projektami),
ograniczenie uprawnień runnerów (np. unikanie privileged, ograniczenie mountów hosta),
rozważenie dedykowanych runnerów dla gitlab.com vs GitLab CE, jeśli wymagania compliance są wysokie.

5 - HAProxy

Architektura warstwy HA: VIP + 3× HAProxy dla usług LXC oraz Kubernetes

📍 Kontekst

Celem architektury jest zapewnienie jednolitego, wysoko dostępnego punktu wejścia (VIP) dla usług publikowanych pod domeną *.rachuna-net.pl, w sposób umożliwiający:

redundancję warstwy LB (brak SPOF na wejściu),
separację i agregację backendów pochodzących z dwóch środowisk:
- LXC (Proxmox): Consul, Vault,
- Kubernetes: Traefik (Ingress), Kubernetes API (masters),
centralne sterowanie routowaniem oraz health-checkami.

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph LB["HA Layer"]
        VIP[("VIP")]
        HA1["HAProxy 1"]
        HA2["HAProxy 2"]
        HA3["HAProxy 3"]
  end
 subgraph CT["LXC"]
        CONSUL["Consul"]
        VAULT["Vault"]
  end
 subgraph K8S["Kubernetes"]
        T["Traefik"]
        M["K8S Masters"]
  end
 subgraph SERVICES["Services"]
    direction TB
        CT
        K8S
  end
    U == "<span style=paddK8S-left:><span style=paddK8S-left:>*.rachuna-net.pl</span></span>" ==> VIP
    VIP ==> HA1 & HA2 & HA3
    HA2 === n1["Small Circle"]
    HA1 === n1
    HA3 === n1
    n1 ==> CONSUL & VAULT & M & T

    n1@{ shape: sm-circ}
    style CT fill:#FFF9C4,color:#000000
    style K8S fill:#C8E6C9,color:#000000
    style n1 fill:#D50000,stroke:#D50000
    linkStyle 0 stroke:#AA00FF,fill:none
    linkStyle 1 stroke:#AA00FF,fill:none
    linkStyle 2 stroke:#AA00FF,fill:none
    linkStyle 3 stroke:#AA00FF,fill:none
    linkStyle 4 stroke:#AA00FF,fill:none
    linkStyle 5 stroke:#AA00FF,fill:none
    linkStyle 6 stroke:#AA00FF,fill:none
    linkStyle 7 stroke:#AA00FF,fill:none
    linkStyle 8 stroke:#AA00FF,fill:none
    linkStyle 9 stroke:#AA00FF,fill:none
    linkStyle 10 stroke:#AA00FF,fill:none

1. Architektura logiczna

Architektura składa się z następujących warstw:

External – klienci (użytkownicy, aplikacje)
HA Layer – VIP + trzy instancje HAProxy
Services – docelowe backendy:
- LXC: Consul, Vault
- Kubernetes: Traefik, Masters (API)

2. Warstwa kliencka (External)

2.1. Opis

Warstwa kliencka obejmuje wszystkie podmioty inicjujące połączenia do usług domenowych.

2.2. Punkt wejścia

Użytkownicy łączą się do usług poprzez:

*.rachuna-net.pl → VIP

W praktyce oznacza to, że niezależnie od tego, czy celem jest Vault, Consul, aplikacje w K8S czy API Kubernetes, wejście jest spójne i scentralizowane.

📍

Wyjątkiem jest:

gitlab.rachuna-net.pl,
registry.rachuna-net.pl
*.pages.rachuna-net.pl.

W przyszłości planowane jest przełączenie usług na HAProxy

3. Warstwa HA (VIP + HAProxy)

3.1. VIP (Virtual IP)

VIP stanowi logiczny adres wejściowy, którego zadaniem jest:

zapewnienie stałego endpointu dla DNS (A/AAAA),
umożliwienie failover pomiędzy instancjami HAProxy (VRRP/keepalived).

VIP nie realizuje routingu aplikacyjnego; jest jedynie mechanizmem przekierowania do aktywnej instancji warstwy LB.

3.2. HAProxy 1/2/3

Warstwa HA składa się z trzech instancji HAProxy, które zapewniają:

terminację lub transparentne przekazanie TLS (w zależności od modelu),
routing ruchu do odpowiednich backendów (LXC/K8S),
health-check backendów,
możliwość rozdzielania ruchu po portach (np. 443/8200/8501/6443) oraz po SNI/Host header.

W modelu z diagramu wszystkie instancje HAProxy są równorzędne, a warstwa HA działa jako „klaster” LB.

4. Warstwa usług (Services)

Warstwa usług jest zbiorem backendów pochodzących z dwóch niezależnych domen wykonawczych: LXC i Kubernetes.

4.1. LXC (Proxmox)

W warstwie LXC znajdują się usługi infrastrukturalne:

Consul – system koordynacji / storage backend (w zależności od wdrożeń),
Vault – system zarządzania sekretami i certyfikatami.

Warstwa HAProxy publikuje te usługi na zewnątrz zgodnie z polityką portów i nazw.

4.2. Kubernetes

W warstwie Kubernetes znajdują się kluczowe elementy komunikacyjne:

Traefik – Ingress Controller dla usług aplikacyjnych (HTTP/HTTPS),
Kubernetes Masters (API) – dostęp do kube-apiserver (typowo port 6443) dla administracji i automatyzacji klastra.

Warstwa HAProxy może:

kierować ruch HTTP/HTTPS (443) do Traefik,
kierować ruch TCP (6443) do API serverów masters.

5. Model routingu (abstrakcja „Service Router”)

📍

Diagram wskazuje logiczny węzeł pośredni (oznaczony jako małe kółko), który reprezentuje koncepcję wspólnego „routera usług” w warstwie HAProxy:

jest to abstrakcja, nie osobna maszyna,
oznacza, że HAProxy posiada spójny model backendów i reguł routingu,
umożliwia kierowanie ruchu do:
- Consul,
- Vault,
- Traefik,
- Kubernetes Masters.

W praktyce realizowane jest to przez konfiguracje HAProxy w postaci:

wielu frontendów po portach,
backendów z checkami,
ewentualnych ACL po SNI/Host.

6. Przepływy ruchu

6.1. Przepływ ogólny

Klient inicjuje połączenie do *.rachuna-net.pl.
DNS wskazuje na VIP.
VIP kieruje ruch do jednej z instancji HAProxy.
HAProxy, na podstawie portu i reguł routingu, przekazuje połączenie do właściwego backendu:
- LXC: Vault/Consul,
- K8S: Traefik lub API masters.

6.2. Przykładowe mapowania (typowe)

Usługa	Warstwa	Port wejściowy	Backend
Vault UI/API	LXC	8200 lub 443	Vault
Consul UI/API	LXC	8501 lub 443	Consul
Aplikacje (Ingress)	K8S	443	Traefik
Kubernetes API	K8S	6443	Masters

Dokładne porty i tryb TLS zależą od przyjętego standardu publikacji (L4 passthrough vs TLS termination).

7. Wysoka dostępność i odporność na awarie

7.1. Eliminacja SPOF na wejściu

VIP zapewnia stały endpoint.
Trzy instancje HAProxy zapewniają redundancję.

7.2. Domena awarii

awaria pojedynczej instancji HAProxy nie powoduje niedostępności usług,
awaria pojedynczego backendu (np. Vault node / Traefik pod / master) może być maskowana przez load-balancing i health-checki, o ile backend jest zestawem replik.

6 - Kubernetes

Architektura rozwiązania

Wdrożenie klastra Kubernetes zostanie zrealizowane na infrastrukturze Proxmox z uwzględnieniem wysokiej dostępności warstwy sieciowej, control-plane oraz storage. Architektura została podzielona na warstwy funkcjonalne: load balancing, control-plane, worker nodes, storage, ingress, sieć, monitoring, logowanie oraz procesy backup/DR. Poniższy opis stanowi kompletny model docelowy dla środowiska.

// to do cert menager, sprzęg z vault

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph LB["HA Layer"]
        VIP[("VIP 80 443 6443")]
        HA1["HAProxy 1"]
        HA2["HAProxy 2"]
        HA3["HAProxy 3"]
  end
 subgraph CP["Control Plane"]
        M1["Master 1"]
        M2["Master 2"]
        M3["Master 3"]
  end
 subgraph WK["Worker Nodes"]
        W1["Worker 1"]
        W2["Worker 2"]
        W3["Worker 3"]
        W4["Worker 4"]
        W5["Worker 5"]
        W6["Worker 6"]
  end
 subgraph ING["Ingress Layer"]
        T["Traefik"]
  end
 subgraph SYS["System Components"]
        Mon["Monitoring Stack"]
        Logs["Logging Stack"]
  end
 subgraph K8S["Kubernetes Cluster"]
    direction TB
        CP
        WK
        ING
        SYS
  end
 subgraph STORAGE["NFS Storage"]
        NFSProd[("NFS Export Prod")]
        NFSNonProd[("NFS Export NonProd")]
        NFSProv["NFS Provisioner"]
  end
    U --> VIP
    VIP --> HA1 & HA2 & HA3
    HA1 -- 80 443 --> T
    HA1 -- 6443 --> M1
    HA2 -- 80 443 --> T
    HA2 -- 6443 --> M2
    HA3 -- 80 443 --> T
    HA3 -- 6443 --> M3
    T --> W1 & W2 & W3 & W4 & W5 & W6
    NFSProd --> NFSProv
    NFSNonProd --> NFSProv
    NFSProv --> W1 & W2 & W3 & W4 & W5 & W6
    M1 --> Mon & Logs
    M2 --> Mon & Logs
    M3 --> Mon & Logs
    W1 --> Mon & Logs
    W2 --> Mon & Logs
    W3 --> Mon & Logs
    W4 --> Mon & Logs
    W5 --> Mon & Logs
    W6 --> Mon & Logs

    style CP fill:#FFF9C4,color:#000000
    style WK fill:#BBDEFB,color:#000000
    style ING fill:#C8E6C9,color:#000000
    style SYS fill:#E1BEE7,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000
    style CP fill:#FFF9C4,color:#000000
    style WK fill:#BBDEFB,color:#000000
    style ING fill:#C8E6C9,color:#000000
    style SYS fill:#E1BEE7,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000

flowchart LR
    U[Users]

    subgraph LB[HAProxy layer]
        VIP[(VIP)]
        HA1[HAProxy_1]
        HA2[HAProxy_2]
        HA3[HAProxy_3]
    end

    subgraph K8S[Kubernetes_cluster]
        subgraph CP[Control_plane]
            M1[Master_1]
            M2[Master_2]
            M3[Master_3]
        end

        subgraph WK[Worker_nodes]
            W1[Worker_1]
            W2[Worker_2]
            W3[Worker_3]
            W4[Worker_4]
            W5[Worker_5]
            W6[Worker_6]
        end

        T[Traefik_ingress]
    end

    subgraph STORAGE[NFS_server]
        NFS1[NFS_exports]
    end

    subgraph VAULT[Vault_cluster]
        V1[Vault_1]
        V2[Vault_2]
        V3[Vault_3]
    end

    U --> VIP
    VIP --> HA1
    VIP --> HA2
    VIP --> HA3

    VIP --> M1
    VIP --> M2
    VIP --> M3

    HA1 --> T
    HA2 --> T
    HA3 --> T

    T --> W1
    T --> W2
    T --> W3
    T --> W4
    T --> W5
    T --> W6

    W1 --> NFS1
    W2 --> NFS1
    W3 --> NFS1
    W4 --> NFS1
    W5 --> NFS1
    W6 --> NFS1

    W1 --> V1
    W2 --> V1
    W3 --> V2
    W4 --> V2
    W5 --> V3
    W6 --> V3

Warstwa Load Balancing – HAProxy

Warstwa wejściowa systemu składa się z trzech instancji HAProxy uruchomionych jako maszyny wirtualne, każda na innym węźle Proxmox. HAProxy pełni dwie kluczowe funkcje:

1.1. Balansowanie ruchu do API Kubernetes

Wszyscy klienci oraz komponenty klastra łączą się z jednym adresem wirtualnym (VIP) obsługiwanym przez HAProxy.
VIP jest utrzymywany mechanizmem VRRP (keepalived).
HAProxy kieruje ruch na port 6443 do trzech masternodów.

1.2. Balansowanie ruchu HTTP/HTTPS aplikacji

Ruch użytkowników trafia do HAProxy, które przekazuje go do Ingress Controllerów (Traefik) działających w klastrze.
HAProxy pracuje w trybie L4 (TCP passthrough) dla TLS lub L7 dla terminacji TLS – w zależności od scenariusza.

Takie podejście zapewnia wysoki poziom redundancji oraz izolację ruchu przychodzącego.

2. Warstwa Control-Plane – 3× Master

Klaster Kubernetes wykorzystuje trzy węzły master, każdy ulokowany na osobnym węźle fizycznym Proxmox. Zastosowany model zapewnia:

pełne HA etcd (quorum 3/3),
odporność na awarię jednego węzła Proxmox,
stabilność kontrolera i procesów zarządzających klastrem.

Węzły master pełnią wyłącznie funkcję control-plane (bez uruchamiania workloadów), co zmniejsza ryzyko interferencji oraz upraszcza utrzymanie.

3. Warstwa Worker – 6× Worker Nodes

Warstwa obliczeniowa klastra składa się z sześciu nodów worker, rozmieszczonych równomiernie na węzłach Proxmox. Założenia:

nody worker służą do uruchamiania wszystkich aplikacji oraz komponentów systemowych (np. Traefik, Promtail),
zastosowane będą dedykowane labels/taints dla logicznych podziałów środowisk oraz typów workloadów.

Układ 6 nodów zapewnia elastyczne skalowanie oraz podział obciążeń.

4. Warstwa Storage – NFS z wieloma eksportami

Jako główna warstwa storage wykorzystany zostanie serwer NFS. Architektura przewiduje kilka eksportów, co umożliwia segregację środowisk oraz lepszą kontrolę nad backupami:

/srv/nfs/k8s-prod – dane środowiska produkcyjnego,
/srv/nfs/k8s-nonprod – dane środowisk deweloperskich i testowych.

W klastrze zastosowany zostanie NFS Subdir External Provisioner, tworzący dynamiczne katalogi per PVC. Dla środowiska przewidziane są oddzielne StorageClass:

nfs-prod
nfs-nonprod

Takie podejście zapewnia prosty, stabilny i łatwy do zarządzania system storage.

5. Sieć klastra (CNI) – Calico

W warstwie sieciowej klaster wykorzystuje Calico jako Container Network Interface. Calico zapewnia:

routing między pods i node’ami,
wsparcie dla NetworkPolicies,
wysoką wydajność i stabilność.

Cała komunikacja między node’ami (masters, workers, HAProxy, NFS) odbywa się w jednej sieci L2 Proxmox, co znacząco upraszcza zarządzanie.

6. Warstwa Ingress – Traefik

Klaster wykorzystuje Traefik jako Ingress Controller. Decyzja wynika m.in. z chęci wykorzystania nowoczesnego narzędzia i możliwości rozbudowy o middleware, automatyczne certyfikaty, routing oparty o CRD oraz integrację z HAProxy.

Architektura ruchu:

Klient → HAProxy (VIP)
HAProxy → Traefik (NodePort)
Traefik → Service → Pod

Traefik odpowiada za routing HTTP/HTTPS, rewrites, TLS oraz polityki ruchu.

7. Obserwowalność – lekkie komponenty

7.1. Monitoring

Zastosowane zostaną lekkie komponenty:

Prometheus (pojedyncza instancja),
kube-state-metrics,
metrics-server,
Grafana (wizualizacja metryk).

Model ten jest wystarczający dla środowiska opartego o Proxmox i ma ograniczone zużycie zasobów.

7.2. Logowanie

Zestaw logowania oparty na:

Loki (storage logów),
Promtail (agent logujący na nodach).

Logi aplikacyjne będą dostępne w Grafanie.

8. Backup / Disaster Recovery

Model DR zakłada pełne podejście Infrastructure as Code (IaC):

Cała infrastruktura (VM-ki Proxmox, konfiguracje sieci) – Terraform.
Konfiguracja systemowa VM (kubelet, containerd, pakiety) – Ansible.
Warstwa aplikacyjna K8S (Traefik, monitoring, provisioner NFS, CRD, deployed apps) – Helm/Kustomize w repo Git.

Backup kluczowych elementów:

backup eksportów NFS (najważniejsze dane – PV),
okresowy backup etcd,
przechowywanie manifestów i konfiguracji w repozytoriach Git (GitOps).

Odtworzenie klastra polega na odtworzeniu NFS, ponownym wdrożeniu klastra z IaC oraz podpięciu poprzednich wolumenów.

9. Proces instalacji – kubeadm (bootstrap)

Środowisko jest bootstrappowane narzędziem kubeadm:

kubeadm init na pierwszym masterze z endpointem VIP API (HAProxy).
Dołączenie pozostałych masterów z kubeadm join --control-plane.
Dołączenie workerów.
Instalacja Calico.
Instalacja provisionera NFS.
Instalacja Traefika.
Instalacja komponentów obserwowalności.

Po etapie bootstrapu klaster może być rozbudowywany automatycznie przez IaC.

Podsumowanie

Przedstawiona architektura rozwiązania opiera się na trzech fundamentalnych filarach: wysoka dostępność, prostota operacyjna oraz możliwość rozwoju. Trzy HAProxy, trzy master nodes i sześć worker nodes tworzą stabilną i skalowalną podstawę dla aplikacji kontenerowych. Warstwa storage oparta o NFS jest celowo uproszczona, ale logicznie podzielona tak, aby wspierać porządek środowiskowy i backup. Wszystkie elementy klastra mogą być utrzymywane, odtwarzane i skalowane w podejściu Infrastructure as Code.

Infrastruktura

📍

Architektura projektu OpenTofu w pl.rachuna-net

Założenia projektów Infrastructure as a Code

1 - Sprzęt (HomeLab)

📍 Kontekst

Cel

Założenia projektowe (IaC)

Sprzęt i platforma uruchomieniowa

Architektura sieciowa

Architektura logiczna

Diagram sprzętu i połączeń

Observability, backup, DR

Podsumowanie

2 - Architektura Sieciowa

📍 Kontekst

1. Węzeł centralny – router brzegowy

2. Segmentacja sieci i VLAN

3. Sieć storage – agregacja łączy (bonding)

4. Sieć klientów (BRIDGE-CLIENTS)

5. Sieć storage – agregacja łączy

6. Warstwa serwerów DHCP

7. Dostęp do Internetu

8. Zarządzanie konfiguracją (IaC)

3 - Vault

📍 Kontekst

1. Architektura logiczna

2. Warstwa kliencka (External)

2.1. Opis

2.2. Punkty dostępu

3. Warstwa HA (VIP + HAProxy)

3.1. VIP (Virtual IP)

📍

3.2. HAProxy

Odpowiedzialności HAProxy:

Mapowanie portów:

4. Warstwa wirtualizacji – Proxmox

4.1. Charakterystyka

4.2. Model rozmieszczenia

📍

5. Warstwa aplikacyjna – Consul

5.1. Rola Consul

5.2. Tryb pracy

📍

6. Warstwa aplikacyjna – Vault

6.1. Rola Vault

6.2. Tryb HA

📍

7. Komunikacja wewnętrzna Vault ↔ Consul

8. Wysoka dostępność i odporność na awarie

8.1. Eliminacja SPOF

8.2. Scenariusze awarii

4 - Gitlab

📍 Kontekst

1. Architektura logiczna

2. Warstwa kliencka (External)

2.1. Opis

2.2. Punkt wejścia

3. Warstwa GitLab

3.1. GitLab CE (self-hosted)

3.2. gitlab.com

📍 Uwagi architektoniczne

4. Warstwa wykonawcza CI/CD – GitLab Runners

4.1. Skład

4.2. Rola

4.3. Skalowanie i dostępność

5. Warstwa storage – NFS dla cache

5.1. Cel cache

5.2. Komponenty

📍 NFS

5.3. Mapowanie montowań

6. Przepływy (workflow)

6.1. Uruchomienie pipeline (GitLab CE)

6.2. Uruchomienie pipeline (gitlab.com)

7. Wysoka dostępność i odporność na awarie

7.1. Założenia

7.2. Krytyczne zależności

📍

8. Wymagania bezpieczeństwa i separacji (zalecenia)

5 - HAProxy

Architektura projektu OpenTofu w `pl.rachuna-net`