Posts

A DevOps mindig is két világ között élt. Pontosabban inkább hat-nyolc világ között. Egyik nap lassú a deployment. Másnap Kubernetes hálózati hiba van. Aztán Terraform drift, flaky teszt, váratlan cloud számla, security kivétel, vagy egy production incident, ami nem hajlandó szépen beleférni egyik dashboardba sem. Ez a sokféleség sokáig úgy nézett ki, mintha a DevOps generalista szakma lenne. Az AI korszakban ez nem gyengeség. Hanem pont az előny. A DevOps eleve több területet köt össze A DevOps nem csak CI/CD, Kubernetes, Terraform vagy monitoring. Ezek eszközök és gyakorlatok. A valódi munka az, hogy összekötünk dolgokat, amelyek maguktól nem beszélnek egymással. ...

Az AWS ezen a héten újra emlékeztetett mindenkit: az Amazon Linux 2 támogatása 2026. június 30-án véget ér. Ez elsőre még kényelmesen távolinak tűnik, aztán az ember végiggondolja, hány helyen bújik meg az AL2. EC2 launch template-ekben, golden AMI-kban, EKS managed node groupokban, ECS hostokon, Packer buildekben, CI runner gépeken, régi Lambda feltételezésekben és olyan admin boxokon, amikhez 2021 óta senki nem nyúlt. Én ezt nem operációs rendszer frissítésként kezelem, hanem infrastruktúra migrációként. Ez fontos különbség. Ha az első reflex az, hogy majd belépek SSH-val és kézzel frissítem a gépeket, akkor már rossz irányba indultunk. A tiszta út nálam: inventory, újraépítés, fokozatos rollout, megfigyelés, majd a régi kapacitás törlése. ...

Március 25-én ébredtem egy Slack üzenetre a security csapattól: “Az ingress-nginx tegnaptól EOL. Mi a terv a migrációra?” Hónapok óta halogattam. A nyugdíjazást még 2025 novemberében bejelentették, de messzinek tűnt. Most viszont valóság lett. Nincs több CVE patch. Nincs több hibajavítás. Az óra ketyeg. Mi történt pontosan március 24-én a Kubernetes SIG Network és a Security Response Committee hivatalosan nyugdíjazta az ingress-nginx-et. A projekt lezárult. A container image-ek és Helm chartok elérhetők maradnak (nem törölnek semmit), de új release nem lesz. Ha holnap jön egy kritikus sebezhetőség, magadra vagy utalva. Ez nem egy deprecation warning, amit három release-en át ignorálhatsz. Ez azt jelenti, hogy a karbantartók elmentek. ...

Ma reggel egy Slack üzenetre ébredtem a security leadtől: “az axiost megtörték npm-en.” Azt hittem vicc. Az axiosnak heti 60 millió letöltése van. Az ember feltételezi, hogy biztonságos, mert mindenki használja. Nem volt vicc. Mi történt pontosan Két kártékony verzió jelent meg npm-en éjszaka: [email protected] és [email protected]. A támadó megszerezte az egyik fő maintainer npm hitelesítő adatait, átírta a fiók emailjét egy ProtonMail címre, és kézzel publisholt npm CLI-vel. Nem volt pull request. Nem volt CI futás. Nem volt code review. Csak egy npm publish egy lopott fiókból. ...

Minden csapat saját klasztert akart. A QA-nak kellett egy, a staging-nek egy, minden fejlesztő akart egyet feature branch-enként. Végül 12 EKS klaszterünk lett, a legtöbb 15%-os kihasználtsággal, és mind pénzbe került. Régóta hallottam a vCluster-ről a Loft Labs-tól, de mindig elnapoltam. Három hónapja végre kipróbáltam. Az ígéret túl szépnek tűnt: teljes Kubernetes klaszterek egyetlen host klaszteren belül, saját API szerverrel, saját erőforrásokkal, teljes izolációval. Extra node-ok nélkül, extra control plane-ek kezelése nélkül. ...

A múlt héten egy teljes szombatot azzal töltöttem, hogy végigauditáltam minden GitHub Actions workflowt az összes repónkban. Nem azért, mert akartam, hanem azért, mert a Trivy elleni supply chain támadás ráébresztett, milyen vékony jégen táncolok. Ha lemaradtál volna: valaki sikeresen becsempészett egy rosszindulatú commitot az actions/checkout actionbe, kihasználva a GitHub fork commit elérhetőségi mechanizmusát. Kicseréltek egy SHA pint a Trivy release workflowjában úgy, hogy egy fork-ban lévő árva commitra mutasson. A commit legitimnek tűnt, a komment azt mondta # v6.0.2, a szerző egy valódi maintainer nevével volt meghamisítva. A tényleges payload Go fájlokat töltött le egy elgépelt domainről és kicserélte a Trivy forráskódját a build során. ...

A múlt héten belefutottam abba, hogy a Kubernetes projekt csendben újraírta az image promotert, vagyis azt az eszközt, ami a hivatalos image-eket feltolja a registry.k8s.io alá. Nem is maga az átírás volt az érdekes, hanem az, hogy az új verzió már rendes SLSA provenance tanúsítványokat és cosign aláírásokat ad az image-ekhez minden tükörnél. Ezen a ponton be kellett vallanom magamnak valamit: a saját image-eimet már jó ideje aláírom CI-ben, de a klaszter oldalon semmit nem kényszerítettem ki. Az aláírás ott volt, csak éppen senki nem nézte. Szóval végre rászántam magam, és rendbe tettem. ...

Két évig én voltam az a fickó, aki adatbázisokat provizionál. Minden hétfő reggel ugyanaz a Slack üzenet: “Hé, kéne egy Postgres a new service-hez.” Megnyitottam a Terraformot, másolás, három változó átírása, plan, approval, apply. Húsz perc az életemből, el. Szorozd meg négy csapattal, és érezni fogod. Aztán beüzemeltem a Crossplane-t Compositions-szel, és most a fejlesztők maguk csinálják egyetlen YAML fájllal. Íme, hogyan jutottam el idáig, és mi tört el közben. ...

Múlt héten hajnali 2-kor kaptam riasztást egy payment service-re, ami eldobálta a kéréseket. Az első ösztönöm ugyanaz volt, mint mindig: elő a cluster-admin kubeconfig-gal a csapat wiki oldaláról, aztán nézzük, mi van. Tíz perc alatt megtaláltam a hibát, de másnap reggel a security csapat jelezte, hogy az audit logokban ott virít a session-öm. Jogosan. Az a “temporary” cluster-admin kubeconfig nagyjából nyolc hónapja volt használatban. Szóval végre nekiültem és összeraktam egy rendes debugging workflow-t. Olyat, ami pontosan annyi hozzáférést ad az ügyeletesnek, amennyire szüksége van, pontosan annyi időre, amennyire kell. ...

Múlt hónapban hajnali 2-kor csörgött a telefonom, mert egy éles cluster API szervere elkezdett timeoutolni. A podok nem schedulálódtak, a kubectl csak lógott, a Slack csatorna pedig addigra teljesen elszabadult. Úgy fél óra múlva jutottam el oda, hogy megint az etcd volt a hibás. Az etcd minden Kubernetes cluster közepén ott van, szóval ha neki rossz napja van, azt az egész rendszer megérzi. Pont ez benne a kellemetlen: az etcd hibái ritkán egyértelműek. Szinte soha nincs egy tiszta jelzés arról, hogy “na igen, ez most biztosan etcd”. Inkább olyan tüneteket látsz, mint a lassú API hívások, a késő scheduling vagy a furcsa timeoutok. Elég sok ilyen incidensen vagyok túl ahhoz, hogy legyen egy saját rövid ellenőrzőlistám, és mostanában az etcd-diagnosis sokat segít abban, hogy gyorsabban jussak a lényeghez. ...