Kategorie: software

Zabbix vs PRTG

Tady je přehledné srovnání, zaměřené čistě na bezplatné verze obou nástrojů:

📊 Srovnání Zabbix vs PRTG (free verze)

Funkce / Vlastnost Zabbix (Open Source) PRTG (Free do 100 senzorů)
🧠 Zaměření Servery, aplikace, síť, databáze Síť, servery, aplikace, IoT, cloud
🧭 Discovery Automatické, SNMP, ICMP, agent Automatické, SNMP, WMI, packet sniffing
📈 Grafy a dashboardy Flexibilní, ale méně vizuálně atraktivní Moderní, drag & drop dashboardy
🔔 Notifikace E-mail, SMS, webhook, skripty E-mail, SMS, push, Slack, webhook
🧩 Rozšiřitelnost API, skripty, šablony, proxy API, custom senzory, integrace
🧰 Monitoring serverů Agent-based i agentless Agentless (WMI, SNMP), volitelný agent
🧪 Monitoring aplikací Šablony, skripty Přednastavené senzory (např. VoIP, AD, SQL)
🧱 Škálovatelnost Vysoká, proxy servery Omezená ve free verzi (100 senzorů)
🖥️ Webové rozhraní Funkční, ale konzervativní Moderní, intuitivní GUI
📱 Mobilní aplikace Ne (jen web) Ano (Android, iOS)
💰 Cena 100% zdarma Zdarma do 100 senzorů, potom placené licence

🧠 Shrnutí

  • Zabbix je robustní open-source nástroj, ideální pro komplexní monitoring v prostředí, kde si můžeš vše nastavit podle sebe.
  • PRTG je víc „out-of-the-box“ — má přednastavené senzory, krásné dashboardy a rychlou instalaci, ale ve free verzi tě limituje počtem senzorů.

Pokud ti jde o vizuální přehlednost, rychlé nasazení a jednoduché ovládání, PRTG je blíž tomu, co nabízí třeba LibreNMS, ale s větším rozsahem. Pokud chceš plnou kontrolu, škálovatelnost a open-source filozofii, Zabbix je silnější hráč.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/zabbix-vs-prtg/

Přehledné srovnání Zabbix vs LibreNMS

Zaměřeno čistě na bezplatné verze, které jsou dostupné open-source komunitě. Oba nástroje jsou zdarma, ale liší se filozofií, rozsahem funkcí i náročností na správu:

📊 Srovnání Zabbix vs LibreNMS (zdarma)

Funkce / Vlastnost Zabbix LibreNMS
🧠 Zaměření Komplexní monitoring všeho (servery, síť, appky) Primárně SNMP monitoring síťových zařízení
🧭 Discovery (objevování) Automatické, přes SNMP, ICMP, IPMI, agent Automatické, přes SNMP, LLDP, CDP, ARP
📈 Grafy a vizualizace Pokročilé, vlastní dashboardy, mapy Jednoduché, přehledné SNMP grafy
🔔 Alerting / Notifikace Velmi flexibilní, podmínky, korelace událostí Jednoduchá pravidla, notifikace přes e-mail, Slack
🧩 Rozšiřitelnost API, skripty, integrace, proxy API, pluginy, oxidized, grafana
🧰 Monitoring serverů Agent-based i agentless (Linux, Windows, DB, appky) Omezený, hlavně SNMP
🧪 Monitoring aplikací Ano (MySQL, Apache, Docker, atd.) Ne (nebo velmi omezeně)
🧱 Škálovatelnost Vysoká, proxy servery, distribuované prostředí Horizontální škálování přes pollery
🖥️ Webové rozhraní Funkční, ale méně moderní Moderní, přehledné GUI
🧑‍💻 Komunita / Podpora Velká komunita, dokumentace, fórum Aktivní komunita, GitHub, fórum
💰 Cena (free verze) 100% zdarma, open-source 100% zdarma, open-source
📦 Instalace Vyžaduje víc ruční konfigurace Jednodušší, skripty pro automatickou instalaci

🧠 Shrnutí

  • Zabbix je jako švýcarský nůž — zvládne monitoring téměř všeho, ale vyžaduje víc času na nastavení.
  • LibreNMS je jako elegantní síťový sniffer — rychle nasadíš, krásně vidíš SNMP data, ale mimo síťové zařízení je omezený.

Pokud chceš monitorovat servery, aplikace, databáze, kontejnery, Zabbix je jasná volba.

Pokud ti jde hlavně o síťová zařízení, SNMP, jednoduché grafy a discovery, LibreNMS je pohodlnější.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/prehledne-srovnani-zabbix-vs-librenms/

OpenVPN vs WireGuard

WireGuard je v podstatě modernější alternativa k OpenVPN, která přináší několik technických i praktických výhod. Tady je srovnání, které ti pomůže pochopit rozdíly:

⚡ Rychlost a výkon

Protokol Rychlost Zpoždění Spotřeba CPU
WireGuard Vysoká Nízké Nízká
OpenVPN Střední Vyšší Vyšší
  • WireGuard je až o 50–70 % rychlejší než OpenVPN při stejném šifrování
  • menší režii díky jednodušší architektuře.

🔐 Bezpečnost

    • WireGuard používá moderní kryptografii: ChaCha20, Curve25519, Poly1305.
    • OpenVPN je flexibilní — můžeš si vybrat z více šifrovacích metod (AES, Blowfish…), ale to může vést ke složitější konfiguraci.
    • Oba jsou open-source a bezpečné, ale WireGuard má jen ~4 000 řádků kódu, což usnadňuje audit a snižuje riziko chyb

🧠 Jednoduchost a konfigurace

  • WireGuard je extrémně jednoduchý na nastavení — ideální pro mobilní zařízení nebo routery.
  • OpenVPN je robustní a flexibilní, ale může být náročnější na konfiguraci (certifikáty, TLS, porty…).

🌍 Kompatibilita

  • OpenVPN funguje prakticky všude — Windows, Linux, macOS, Android, routery.
  • WireGuard je novější, ale už ho podporuje většina VPN služeb a OS (včetně Linux kernelu).

🕵️‍♂️ Soukromí

  • WireGuard v základní verzi uchovává IP adresy na serveru (kvůli jednoduchosti), ale většina VPN služeb to řeší dynamickým přidělováním nebo mazáním po relaci.
  • OpenVPN neukládá žádná data o uživateli, což je výhoda pro anonymitu.

🧭 Kdy zvolit WireGuard?

  • Pokud chceš rychlejší VPN, která méně zatěžuje systém.
  • Pro mobilní zařízení nebo routery s omezeným výkonem.
  • Když ti stačí jednoduchá konfigurace bez složitých certifikátů.

🧱 Kdy zůstat u OpenVPN?

  • Pokud potřebuješ maximální kompatibilitu a jemné doladění (např. TCP/UDP porty, obfuskaci).
  • Pro firemní prostředí nebo specifické síťové scénáře.

 

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/openvpn-vs-wireguard/

Souboj nenasytnosti mezi desktopovými prostředími

Tady je přehled, jak si vedou z hlediska RAM, CPU zátěže a celkové efektivity:

🧠 RAM spotřeba při čistém startu

Prostředí RAM (čistý start) Poznámka
GNOME ~750 MB Těžkotonážní, plný efektů
KDE Plasma ~650 MB Bohatý na funkce, ale optimalizovaný
Cinnamon ~630 MB GNOME fork, podobně náročný
MATE ~540 MB Lehký GNOME 2 fork
Xfce ~450 MB Střední váha, velmi svižný
LXQt ~400 MB Ultra lehký, moderní Qt
i3 ~100–200 MB Tiling WM, extrémně úsporný

⚙️ CPU zátěž a odezva

  • GNOME: Efekty, animace, Wayland → vyšší CPU zátěž i při nečinnosti.
  • KDE: Překvapivě svižný, ale některé widgety (např. CPU monitor) žerou dost.
  • Xfce: Nízká zátěž, ale některé panely můžou být žrouti.
  • LXQt: Minimalistický, téměř žádná zátěž.
  • i3: Tiling bez GUI pozlátka → CPU skoro nepozná, že něco běží.

🧩 Funkce vs. nenasytnost

Prostředí Funkce Nenasytnost
GNOME 🧁 Moderní, ale těžký 🟥 Vysoká
KDE 🛠️ Extrémně přizpůsobitelný 🟨 Střední
Xfce 🧃 Jednoduchý, stabilní 🟩 Nízká
LXQt 🧊 Ultra lehký, méně funkcí 🟩 Nízká
i3 🧱 Hardcore minimalismus 🟩 Extrémně nízká

🧪 Reálný dojem

  • KDE: Pokud si ho ořežeš (bez widgetů, efektů), může být stejně lehký jako Xfce.
  • GNOME: Vypadá hezky, ale na slabším stroji tě zničí.
  • Xfce/LXQt: Ideální pro starší stroje nebo low-RAM systémy.
  • i3: Pokud ti nevadí ovládat vše klávesnicí, je to raketa.

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/souboj-nenasytnosti-mezi-desktopovymi-prostredimi/

🐉 Bajka o VMware

V jiném království žil tichý mnich jménem VMware ESXi. Nebyl hlučný, neměl rád cloud, a nikdy se neptal na internet. Byl to hypervizor, co meditoval v tichu serverovny, běžel 500 dní bez restartu, a jeho jediným přáním bylo: „Nech mě být.“

Když přišla doba předplatného a licencí, VMware se jen usmál a řekl:

„Já jsem tu pro ty, kdo chtějí stabilitu, ne slávu. Můj klíč je offline, moje duše je železná, a moje srdce bije v každém snapshotu.“

A tak zatímco jiní padali pod tíhou cloudových smluv, VMware dál běžel. Tichý, stabilní, neviditelný. A ti, kdo ho znali, věděli, že pravá síla není v tom, co se mění, ale v tom, co vydrží.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%90%89-bajka-o-vmware/

Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)

Stáhnout článek v PDF: Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)


Jak zajistit, aby vaše IT prostředí bylo schopné zpětně vyhodnotit, analyzovat a právně obhájit jakýkoliv bezpečnostní incident – bez ohledu na velikost firmy.

V době, kdy je e-mail hlavním nástrojem komunikace a zároveň běžným cílem kybernetických útoků, nestačí jen „fungovat“. Je třeba umět dokázat, že infrastruktura byla spravována bezpečně, že byla schopná incident včas identifikovat – a že lze zpětně rekonstruovat jeho průběh.

Malé a střední podniky (SME) často nemají vlastní bezpečnostní tým, přesto mohou být dobře připravené – díky otevřeným standardům, chytrému nastavení a přiměřené dokumentaci.

🛡️ Klíčové pilíře forenzní připravenosti

Oblast Co znamená v praxi
Auditní stopy Uchovávání logů, přístupových záznamů, e-mailových tras
Retenční politika Jasné pravidlo, jak dlouho se ukládají data (např. logy 90 dní)
Zabezpečení schránek Ochrana hesel, 2FA, izolace kritických rolí
Reprodukce incidentu Možnost zpětně analyzovat, co se stalo (čas, IP, uživatel, soubor)
Soulad s právem Dodržování GDPR, archivace dat a auditovatelnost procesů
Školení a procesy Správce ví, co dělat, když dojde k podezřelé aktivitě

📋 Checklist forenzní připravenosti (pro správce e-mailového systému)

✅ Logy přístupů na IMAP/SMTP uchovávám alespoň 90 dní

✅ E-mailová relace (MAIL FROM / RCPT TO / relay IP) se ukládá do syslogu nebo SIEM* (Security Information and Event Management – systém pro sběr a analýzu logů) (viz. níže)

✅ Mám detekci neobvyklého chování (např. přihlášení z cizího regionu)

✅ Antispamový systém (Rspamd) loguje score a rozhodnutí v detailu

✅ Webmail (např. SOGo) má audit zapnutí/offline režimu, exportu kontaktů apod.

✅ Všechny přístupy přes web UI mají logovací mechanismus a TLS enforcement

✅ Zálohování VM obsahuje metadata i logy, není rotováno bez validace

✅ Uživatelé nemohou měnit SPF/DKIM bez administrátorského přístupu

✅ Existuje směrnice pro práci s e-mailovou schránkou při odchodu zaměstnance

✅ V případě incidentu mám dokument, jak vytáhnout logy, přehled schránek a přístupy

„Pro sběr logů z e-mailového serveru lze využít open-source nástroje jako Wazuh, Graylog nebo OSSEC, které umožňují sledovat relace, přihlašování i anomálie.“ (viz. níže)

🎓 Doporučení pro malé firmy

  • I bez SIEM nebo externího auditního systému lze dosáhnout vysoké úrovně bezpečnosti – stačí mít logiku, smysl pro konzistenci a pravidelně ověřovat funkčnost
  • Dokumentace může mít podobu textového souboru v Git repozitáři, nebo PDF s verzováním – nepotřebujete systém za miliony
  • Forenzní připravenost není paranoia – je to právní štít, když někdo zneužije firemní e-mail, napadne server nebo exfiltruje kontakty

*SIEM je zkratka pro Security Information and Event Management — v češtině by se to dalo přeložit jako „Správa bezpečnostních informací a událostí“.

 

🧠 Co SIEM vlastně dělá?

Je to systém, který:

  • Sbírá logy a události ze všech zařízení v síti (firewally, servery, e-mailové systémy, webmail, VPN…)
  • Analyzuje je v reálném čase → hledá podezřelé chování, útoky, anomálie
  • Umožňuje zpětně rekonstruovat incident → kdo, kdy, odkud, co udělal
  • Pomáhá s compliance → GDPR, ISO 27001, NIS2, HIPAA, PCI-DSS…

🔍 Příklad z praxe:

Když se někdo přihlásí do webmailu z Ruska ve 3 ráno, SIEM to:

  1. Zaznamená jako událost
  2. Porovná s běžným chováním uživatele
  3. Vyhodnotí jako anomálii
  4. Pošle alert správci
  5. Umožní dohledat celý průběh (IP, čas, akce, přístup k souborům…)

📦 Co SIEM není?

  • Není to firewall, ale nadstavba nad logy
  • Není to antivir, ale centrální mozek pro bezpečnostní analýzu
  • Není to jen logovací systém — umí korelaci, alerty, reporting

🧠 Top open-source SIEM nástroje vhodné k mailserveru

🛠️ Nástroj Co umí / Proč se hodí k mailserveru Poznámka k nasazení
Wazuh HIDS + SIEM: logy, integrity check, rootkit detekce, compliance ✅ Docker / VM / bare-metal
OSSEC Host-based IDS, logy z mailserveru, detekce změn ✅ Lehký, ale méně UI-friendly
Security Onion Kompletní distro: Suricata, Zeek, ELK, Wazuh, Kibana ⚠️ Náročnější na HW, ale komplexní
Graylog Log management + alerty, vizualizace, geolokace IP ✅ Moderní UI, vhodné pro SMTP/IMAP logy
ELK Stack Elasticsearch + Logstash + Kibana → logy, dashboardy ⚠️ Nutná konfigurace korelace
Snort / Suricata IDS/IPS pro síťovou vrstvu, SMTP traffic, port scan ✅ Doplněk k SIEM, ne SIEM samotný
Prelude SIEM Korelace událostí, IDMEF standard, integrace s OSSEC/Snort ⚠️ Méně známý, ale standardizovaný
MozDef SIEM od Mozilly, microservices, alerty, Elastic backend ⚠️ Vyžaduje čas na nastavení

🔐 Co sledovat u mailserveru pomocí SIEM

  • SMTP relace: MAIL FROM / RCPT TO / relay IP
  • IMAP/POP3 přihlášení: čas, IP, geolokace, počet pokusů
  • Webmail akce: export kontaktů, přístup z mobilu, offline režim
  • Antispam rozhodnutí: score, reject důvody, greylisting
  • TLS handshake: verze, cipher, expirace certifikátu
  • DKIM/SPF/DMARC logy: validace, selhání, spoofing pokusy

💡 Doporučení

  • Pro lehké nasazení k mailcow: Wazuh nebo Graylog
  • Pro komplexní monitoring: Security Onion nebo ELK Stack
  • Pro síťovou vrstvu: doplňit o Suricata nebo Snort
  • Pro forenzní audit: kombinuj s logy z Postfixu, Dovecotu, rspamd

Pokud si vše jmenované zvládnete sami nainstalovat a hlavně zkonfigurovat, máte TOP řešení kompletně zdarma, přičemž jeho reálná hodnota bude od stovek tisíc do několika milionů podle zvolené konfigurace v porovnání s komerčnímy systémy používanými napřiklad v bankovním sektoru.

„Tento text není právní analýzou, ale technickým přehledem možností, jak podpořit bezpečnostní auditovatelnost e-mailového prostředí. V případě regulovaných odvětví doporučujeme konzultaci s právníkem.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/zasady-forenzni-bezpecnostni-pripravenosti-v-prostredi-sme-malych-a-strednich-podniku/

Co je Kubernetes 3 – Tanzu na vSphere vs. Linux + Kubernetes + KVM

🧠 Tanzu a Kubernetes na vSphere = běží to pod vCenterem, ale část běží přímo na ESXi

Jak to funguje fakticky:

  1. vCenter Server (VM s Photon OS = lehký Linux) slouží jako centrální mozek – GUI, správa clusterů, orchestrace, API, atd.

  2. Supervisor Cluster = Kubernetes běží jako nativní služba na ESXi – ne jako běžící VM s Linuxem, ale jako vnitřní komponenty ESXi (vSphere podpora pro kontejnery)

  3. Tanzu pak umí vytvořit běžné VM, ve kterých běží tzv. TKG clustery – ty už jsou klasicky v Ubuntu/CentOS/Photon a obsahují Kubernetes jako normálně

➕ To znamená:

  • část běží přímo na ESXi (bez Linux VM) = ano, „nativně“

  • část (vCenter, TKG VM) běží jako klasické virtuály = ne tak nativně

🔄 Porovnání: Tanzu na vSphere vs. Linux + Kubernetes + KVM

Vlastnost Tanzu na vSphere Linux + Kubernetes + KVM
Hypervizor ESXi (VMware) Linux + KVM
Správa vCenter, GUI, Workload Mgmt CLI, Cockpit, Virt-Manager, atd.
Kubernetes běží jako… částečně nativní služba + VM s K8s jako běžný software nad OS
Požadavky na síť/sdílené storage vysoké (vDS, HAProxy/NSX, DRS) minimální nebo žádné
Komplexnost prvotního nasazení vysoká (hodiny až dny) nízká/střední (desítky minut až pár hodin)
Cena vysoká (Enterprise licence, vCenter, NSX-T?) prakticky nulová (Linux je zdarma)
Běh VM ✅ nativní, efektivní ✅ s KVM, dobrá virtualizace
Výkon velmi vysoký vysoký
Flexibilita nízká, vendor lock-in vysoká, plná kontrola
Upgrady centralizované, ale podmíněné licencemi plně v tvé režii

🎯 Realistický závěr:

Ano, když máš vlastní server (např. Dell 730xd), tak místo ESXi a Tanzu můžeš dát rovnou Linux (např. Debian/Ubuntu/AlmaLinux), a na něj postavit Kubernetes + KVM + všechno, co chceš – bez licencí, bez složitostí, s větší svobodou.

Tohle řešení:

  • bude výrazně levnější,

  • budeš ho víc ovládat, žádné vendor-locky,

  • Kubernetes můžeš rozběhnout snadno (K3s, kubeadm, MicroK8s, atd.),

  • virtuály můžeš rozjet přes KVM/QEMU, s webovým rozhraním (Cockpit) nebo CLI.

🧰 Konkrétní tipy na to, jak to udělat

 

Tady máš základní stavbu toho opensource „homelab cloudu“:

  1. 🐧 OS: Debian nebo Ubuntu Server

  2. ☸️ Kubernetes: K3s (lehčí, ideální pro jeden node) nebo kubeadm

  3. 🖥️ Virtualizace: libvirt + KVM + Cockpit (nebo Virt-Manager)

  4. 📦 Container registry: třeba Harbor nebo Docker Registry

  5. 🛡️ Ingress, monitoring, backup: Traefik/NGINX + Prometheus + Velero

  6. 🌐 GUI: Portainer (kontejnery), Cockpit (host), Rancher (K8s GUI)

  7. Deployment: Ansible nebo bash script

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-3-tanzu-na-vsphere-vs-linux-kubernetes-kvm/

Co je Kubernetes 2 – Co je Tanzu (VMware)

🌱 Co je Tanzu?

Tanzu = Kubernetes platforma od VMware.

👷‍♂️ K čemu je:

Tanzu není jen „verze Kubernetesu“, ale celá sada nástrojů, která umožňuje:

  • instalovat a spravovat Kubernetes clustery ve vSphere (VMware),

  • integrovat Kubernetes do tvých VM prostředí,

  • spravovat kontejnery stejně snadno jako VM,

  • automatizovat CI/CD, bezpečnost, monitoring, síť a storage v K8s.

📦 VMware Tanzu Kubernetes Grid (TKG) je hlavní nástroj, který nasazuje čistý Kubernetes s podporou od VMware.

 

🔗 Můžeš propojit Kubernetes na vlastním serveru s Google Cloudem?

✅ Ano. Toto se jmenuje Hybridní Kubernetes (Hybrid Cloud) nebo Multi-Cloud Cluster Management.

Jak na to:

  • Propojíš svůj on-premise Kubernetes cluster (např. Tanzu, K3s, RKE, OpenShift…) s Google Kubernetes Engine (GKE) pomocí Anthos, VPN tunelů, nebo Federace.
  • Výsledkem je, že máš centralizovanou správu, monitoring, případně můžeš workloady „rozhazovat“ podle vytížení mezi on-prem a cloud.

🔧 Nástroje:

  • Anthos (Google) – propojí on-prem K8s (včetně Tanzu) s GKE.
  • Rancher, ArgoCD, FluxCD, kubeadm – jiné možnosti pro hybridní orchestraci.
  • Cloud VPN / BGP routing – propojí sítě mezi tvými servery a Googlem.

💻 Jak se Kubernetes na VMware instaluje a provozuje?

Dvě možnosti podle úrovně integrace:


🔧 1) Tanzu vSphere – integrace přímo do VMware prostředí

💡 Pouze pro vSphere 7 Enterprise+ a vyšší s vCenter Serverem a vSAN.

Co se děje:

  • VMware vSphere vytvoří Supervisor Cluster – Kubernetes běží nativně nad hypervisorem.

  • Kubernetes je součástí VMware – spravuješ ho z vSphere UI.

  • Můžeš vytvářet VM i kontejnery z jednoho prostředí.

  • Přidáš Tanzu Kubernetes Grid jako „template“ do prostředí → pak už jen klikáš clustery.

Výhoda:

  • Není třeba spouštět VM s Linuxem.

  • Kubernetes běží jako „first-class citizen“ v ESXi.


🧱 2) Manuální instalace Kubernetes ve virtuálním stroji

Funguje na jakékoli VMware verzi (i Workstation, ESXi Free).

Jak to vypadá:

  1. Vytvoříš virtuálku s Linuxem (Ubuntu, CentOS, Fedora…).

  2. Nainstaluješ kubeadm, kubectl, kubelet (nebo použiješ např. MicroK8s, K3s).

  3. Spustíš kubeadm init, nastavíš networking, storage, apod.

  4. Hotovo – běží ti plný Kubernetes cluster ve VM.

📦 Tip: Pokud chceš rychle a jednoduše, použij:

  • K3s (lehčí Kubernetes od Rancher Labs)

  • MicroK8s (od Canonical, jednoduše rozběhneš i lokálně)

🔁 Shrnutí rozdílů:

Možnost vSphere s Tanzu VM s Linuxem + Kubernetes
Podpora od VMware ✅ Plná ❌ Vlastní odpovědnost
Kubernetes nativně ve vSphere ✅ Ano ❌ Ne
Výkon ⚡ Vysoký (běží přímo na ESXi) 🐢 Závisí na VM
Komplexita instalace ⚙️ Vyšší na začátku, pak klikací ⚙️ Jednoduché, ale ruční
Možnost škálování ✅ Lepší ⚠️ Omezená kapacitou VM
Pro malé laby / domácí ❌ Náročné ✅ Ideální řešení

📌 Shrnutí pro tebe

  • Tanzu = platforma od VMware, která ti umožní spustit Kubernetes přímo na vSphere bez potřeby Linuxových VM.

  • Můžeš Kubernetes propojit s Google Cloudem (např. GKE) pro hybridní nasazení.

  • Pokud nemáš Tanzu licenci, běžná instalace do Linuxové VM ti dá plnohodnotný Kubernetes (např. K3s).

  • GKE je Kubernetes jako služba v cloudu, nemusíš se o nic starat – vhodné na produkci nebo testovací deploymenty.

Tanzu není „jen“ aplikace pod Linux, ale zároveň není tak integrovaná a pohodlná, jak by člověk čekal za ty prachy, co VMware vEnterprise stojí.

Tady je realita bez marketingu:

🧱 Jak se Tanzu instaluje pod VMware (vSphere 7)

🚨 Realita: „Tanzu“ nezapneš jedním tlačítkem jako VM – ale dá se to zautomatizovat, a jakmile to máš, je to pak „klikací“.

Tanzu = několik komponent dohromady:

Vrstva Co to je
Supervisor Cluster Kubernetes běžící přímo na ESXi (zabudovaný do hypervizoru)
Tanzu Kubernetes Grid (TKG) Sada nástrojů pro tvorbu dalších K8s clusterů
NSX-T nebo vDS Nutné pro síťování Kubernetesu
Harbor registry (volitelné) pro vlastní docker image
vSphere Namespace + Content Library Prostředí pro kontejnery a clustery

✅ Co musíš mít (kontrolní seznam):

Potřeba Detaily
vSphere 7 Enterprise Plus Jinak Tanzu neaktivuješ
vCenter Server 7 GUI, řízení clusteru
Cluster s aktivním DRS (Distributed Resource Scheduler)
vSphere Distributed Switch (vDS) nebo NSX-T Pro networking Kubernetesu
Content Library Aby měl Tanzu odkud brát image
Load Balancer (např. HAProxy) Pro přístup na služby v K8s
❗ Volitelné: DNS, NTP, storage policies, storage classes atd.

🔧 Instalace krok za krokem (v kostce)

  1. Vytvoř cluster ESXi hostů (musí mít DRS a sdílené storage)

  2. Vytvoř vSphere Distributed Switch + Port Groups pro komunikaci (pokud nemáš NSX-T)

  3. Zapni vSphere with Tanzu ve vCenteru:

    • Přes Workload Management (vSphere Client → Menu → Workload Management)

    • Vybereš cluster, DVS, IP Pool, storage policy, load balancer (např. HAProxy VM)

  4. vSphere vytvoří Supervisor Cluster:

    • Kubernetes běžící přímo na hypervizoru (ne v Linux VM)

    • Vytvoří se Namespace, které pak spravuješ

  5. Vytvoř Content Library s Tanzu Kubernetes Grid image

  6. Z ní pak vytváříš Tanzu Kubernetes clustery na jedno kliknutí

📦 Co je vlastně Tanzu Kubernetes Grid (TKG)?

  • Image, který se spouští jako VM s Linuxem + Kubernetes + agenti

  • Spouští se automaticky přes vSphere, pokud máš nastavený Supervisor

  • Můžeš ho mít i mimo vSphere, např. na AWS, Azure nebo bare-metal


💬 Takže shrnuto:

  • Supervisor Cluster = Kubernetes běžící nativně na ESXi (ne v Linuxu)

  • TKG = běžící Kubernetes v klasické VM (ale připraveno, automatizováno)

  • Všechno ovládáš z vSphere GUI přes Workload Management

  • Ale předtím musíš:

    • Mít licence

    • Síť (DVS nebo NSX-T)

    • Storage policy

    • Load Balancer (HAProxy / NSX Load Balancer)

🔗 Chceš to reálně zkusit?

Doporučuji začít s Tanzu přes HAProxy a vSphere Distributed Switch, protože NSX-T je peklo (složitý, drahý).

🧠 Myšlenka na závěr:

Ano, Tanzu běží „pod Linuxem“, ale tím Linuxem je v tomhle případě už samotnej hypervizor ESXi – takže Kubernetes běží natvrdo „na železe“, bez prostředníka v podobě klasické VM.

To je důvod, proč je to tak stabilní, ale zároveň složitější na setup.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-2-co-je-tanzu-vmware/

Co je Kubernetes?

🧠Pojďme to rozbalit od základů — co je Kubernetes, k čemu je dobrý, a jak to souvisí s VMwarem, cloudem a proč Google nabízí vytvoření Kubernetes clusteru.

Asi už pár z vás napadlo co je to za technologii, ale nikde to není kloudně popsaný. Člověk se dozví že jde o kontejnery co běží na nějakém linuxu, že to jede v Cluseru kvůli škálování, potřebuje to nějaké řízení a tak, ale ve finále když už na tom někdo něco chce provozovat, tak si to raději zaplatí u Googlu, protože to rozjet u sebe je na kulku do hlavy. Když potom ještě máte komerční řešení od VMware 7 Enterprise Plus a čekáte snad, že když je to komerční produkt, tak to bude snažší, tak si tu kulku lebkou proženete, protože je to ješte xnásobně složitější 🙂

vSphere 7 Enterprise Plus Features:

  • APIs for Storage Awareness
  • Big Data Extensions
  • Compatible with Tanzu Kubernetes Grid Service and Hybrid Infrastructure Service
  • Content Library
  • Cross Virtual Center vMotion
  • Direct Path vMotion
  • H.264 for Remote Console Connections
  • Hot-Pluggable virtual HW
  • MPIO / Third-Party Multi-Pathing
  • Persistent Memory
  • Reliable Memory
  • Remote virtual Serial Port Concentrator
  • Shared Smart Card Reader
  • SR-IOV
  • Storage APIs
  • Storage-Policy Based Management
  • Unlimited virtual SMP
  • vCenter agent for VMware host
  • vGPU
  • Virtual Volumes
  • vShield Endpoint
  • vShield Zones
  • vSphere API
  • vSphere App HA
  • vSphere Auto Deploy
  • vSphere Bitfusion
  • vSphere Data Protection
  • vSphere Distributed Switch
  • vSphere DRS
  • vSphere Encrypted vMotion
  • vSphere FT (up to 8 virtual CPUs)
  • vSphere HA
  • vSphere Host Profiles
  • vSphere Predictive DRS
  • vSphere Proactive HA
  • vSphere Replication
  • vSphere Storage APIs for Array Integration
  • vSphere Storage DRS
  • vSphere Storage I/O Control
  • vSphere Storage vMotion
  • vSphere Trust Authority
  • vSphere View Accelerator
  • vSphere VM Encryption
  • vSphere vMotion
  • vSphere vMotion Metro
  • X-Switch vMotion

🧠 Co je Kubernetes?

Kubernetes (zkráceně K8s) je open-source platforma na správu a orchestraci kontejnerů. Vyvinul ho Google a dnes ho spravuje CNCF (Cloud Native Computing Foundation).

🔧 Co to znamená jednoduše:

  • Máš aplikaci rozdělenou do malých izolovaných „krabiček“ = kontejnerů (např. pomocí Dockeru).

  • Kubernetes se stará o to, kde běží, jak běží, kolik jich běží, restartuje je, škáluje, rozmisťuje po serverech atd.

  • Vytváří tzv. cluster – skupinu fyzických nebo virtuálních strojů, na kterých kontejnery běží.

💡 K čemu je Kubernetes dobrý?

  • Automatická obnova – když něco spadne, znovu to nahodí.

  • Škálování – když máš víc návštěvníků, rozběhne víc instancí.

  • Rollout / rollback – snadno nasazuješ nové verze, můžeš se vrátit zpět.

  • Load balancing – rovnoměrně rozděluje zátěž.

  • Deklarativní konfigurace – všechno popíšeš v YAML nebo JSONu.

☁️ Google nabízí „Create a Kubernetes cluster“

Google Kubernetes Engine (GKE) = Google-hostovaná verze Kubernetesu.
Je to vlastně „klikací“ způsob, jak si vytvořit celý Kubernetes cluster bez toho, že bys musel všechno instalovat a spravovat ručně.

Je to:

  • Rychlé a pohodlné – nemusíš nic konfigurovat, všechno se děje v Google Cloudu.

  • Produkčně připravené – můžeš škálovat na tisíce instancí.

  • Integrace s ostatními službami (síť, storage, monitoring, AI, billing atd.)

VMware vSphere 7 už má nativní podporu Kubernetes (vSphere with Tanzu).
To znamená, že tvůj vlastní server nebo cluster s VMwarem může taky provozovat Kubernetes.

V praxi:

  • Vytvoříš Kubernetes cluster přímo na svých VM.

  • Využíváš vlastní infrastrukturu místo cloudu.

  • Máš větší kontrolu, ale větší nároky na správu.

VMware + Kubernetes = hybridní cloud ready řešení.

🆚 Google Kubernetes Engine vs. vlastní (třeba VMware) Kubernetes

Funkce / Rozdíl Google Kubernetes Engine Vlastní Kubernetes na VMware
Správa clustru Google (automatická) Ty nebo tvůj admin
Infrastruktura Cloud On-premise (tvé servery)
Cena Platíš za výpočetní výkon Platíš za HW + provoz
Rychlost nasazení Velmi rychlá (minuty) Delší (instalace, konfigurace)
Flexibilita a kontrola Omezená (cloud) Vysoká (tvůj svět)

👨‍💻 Jak se to používá?

  1. Vytvoříš cluster (v cloudu nebo lokálně).

  2. Máš aplikaci jako Docker image (např. moje-api:v1).

  3. V YAMLu definuješ nasazení (Deployment), službu (Service), volume, ingress atd.

  4. Používáš příkazy jako:

    kubectl apply -f moje-aplikace.yaml
    kubectl get pods
    kubectl logs moje-api-xyz
  5. Kubernetes se postará o zbytek – nasadí, restartuje, spravuje.

🧭 Shrnutí – co si z toho odnést?

  • Kubernetes je orchestrátor kontejnerů – umožňuje provozovat aplikace škálovaně, stabilně a automatizovaně.

  • Google Kubernetes Engine je způsob, jak si to pustit v cloudu bez starostí o infrastrukturu.

  • VMware 7 Kubernetes taky umí – pro případy, kdy si chceš všechno řídit lokálně.

  • Kubernetes má smysl, když:

    • máš více aplikací/služeb

    • řešíš výpadky, škálování, CI/CD

    • chceš být nezávislý na jednom serveru

    • chceš prostředí připravené na růst nebo mikroservisní architekturu

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes/

Čím jsme jiní…

…citelně lepší bezpečnost (zabezpečení), která je na Internetu v poslední době důležitější než cokoli jiného, je pro nás posláním. Zabezpečení sítě bereme více než vážně, proto také, když nás občas některý klient podlehnuvší nabídce (na papíře jenž snese všechno) opustí, se nestačí divit, co útoků mu najednou jeho „antivirus*“ hlásí. Skutečně se nejedná o útok na něj z naší strany jako mstu, za to že nás opustil. Často ani nevíme ke komu odešel, ale faktem zůstává, že dvouúrovňovou ochranu na vstupu sítě kterou disponujeme, mají jen skutečně kvalitní datová centra, minimum i velkých podniků a organizací včetně těch státních. Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2018/11/15/cim-jsme-jini/

Win 10 nenačte z DHCP serveru IP adresu

Windows 10 se již nevypínají jako předchozí verze windows. Používají tzv. rapid start, což je v podstatě stejné jako hibernace. Při stisknutí vypínace se tak počítač v podstatě jen uspává. Stejné je to i v případě, kdy dáte menu start->napájení->vypnout. Také dojde pouze k uspání. Při delším používaní, např. 3-6 měsíců se „něco“ stane v socketu a začnou se dít tyto anomálie. MS zřejmě předpokládal, že tlačítko restartovat by potom bylo zbytečně nevyužité a navíc, že systém se díky častým aktualizacím restartuje tak často, že jej není potřeba znovu startovat při zapnutí. Možná je důvod jiný, nevím, MS jsem se neptal :). Režim spánku je tak uspání do paměti a VYPNOUT je režim HIBERNACE. Režim hybridní hibernace obsažený v předchozích verzích zmizel, stejně jako vypnutí, které na všech ostatních mě známých systémech dělá i nadále vypnutí. (vypnu/zapnu=rebootuji, jen u MS se tomu říká restartuji.)

Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2017/01/17/win-10-nenacte-z-dhcp-serveru-ip-adresu/

Ubuntu 16.04.1 LTS Launcher bottom

Ubuntu 16.04.1 LTS Launcher bottom = Ubuntu 16.04.1 LTS spouštěč dole 🙂

Jakožto šťastný uživatel Ubuntu, jsem si nikdy nezvykl na spouštěč aplikací nalevo. Vzhledem k tomu, že v Unity až do teď (6 let od zavedení) nebylo možné jej oficielně přesunout dolů, jsem musel používat všemožné obezličky (na koncept vlevo jsem si nezvykl). Nyní však, od verze Unity 7 je již možné zcela oficiálně, tedy výrobcem podporovaným způsobem, umístit spouštěč aplikací dolů. To provedete zadáním níže uvedeného příkazu do terminálu. Tedy  zadáte aplikaci „terminal“ kterou spustíte a do ní příkaz zkopírujete a dáte enter. Není potřeba ani sudo (jak to obvykle v ubuntu bývá u každé drobnosti), příkaz lze zadat jako obyčejný uživatel:

gsettings set com.canonical.Unity.Launcher launcher-position Bottom

Pro případ, že byste s výsledkem nebyli spokojeni můžete vzniklou situaci vrátit zpět zadáním tohoto příkazu:

gsettings set com.canonical.Unity.Launcher launcher-position Left

změna se projeví okamžitě a pozice napravo není podporována 🙂

ubuntu

Přímý odkaz na tento článek: https://www.sympatika.cz/2016/09/23/ubuntu-16-04-1-lts-launcher-bottom/

Přenositelnost OEM licencí

Nejen výrobce „zatím“ nejpoužívanějšího operačního sytému pro PC, ale i další firmy se snaží licencovat svoje produkty tak, aby byl zákazník vždy nucen s HW obměňovat i SW a to i v případě, že to nepotřebuje, nebo dokonce to není k jeho prospěchu. Rozhodnutím Soudního dvora Evropské unie z 3. července 2012 je možné obchodovat už i se softwarovými licencemi v nehmotné podobě.  Obchodování, dokonce i s OEM licencemi, je legální.

Přímý odkaz na tento článek: https://www.sympatika.cz/2014/05/12/prenositelnost-oem-licenci/

MS Office nepíše velká písmena s diakritikou

Pokud se stane, že po čisté instalaci MS Office nelze psát velká písmena s diakritikou, na vině je:

Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2013/06/13/ms-office-nepise-velka-pismena-s-diakritikou/

Nejde přijmout pošta ze seznamu?

Contact_placard_182x101

[error]Problém: Při přihlášení poštovního klienta (Outlook express, Windows Mail, The Bat, Thunderbird…) k serveru seznamu (pop3.seznam.cz) dojde k chybě a spojení je přerušeno.[/error] [warning]Symptom: Přihlášení stejným jménem a heslem přes webové rozhraní (internetovým prohlížečem) funguje bez problému.[/warning] Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2013/03/09/nejde-prijmout-posta-ze-seznamu/