<del>Docker</del> AWS infrastruktúra üzemzavar - teljes leállás van

Hálózatok egyéb

"Issues accessing Registry, Hub, Scout, DBC, DHI - We are seeing issues accessing and using our services across many of our products. See dockerstatus.com⁠ for updates."

https://www.dockerstatus.com/

Minden szolgáltatásuk "Full Service Disruption" állapotban van:

Incident Status: Full Service Disruption

Components: Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud, Docker Hardened Images

Locations: Docker Web Services

  • 2297 megtekintés

( tompos v | 2025. 10. 20., h – 10:59 )

minden is all

AWS DynamoDB paff-on van (meg lehet, mas is?).

Egyik kollégám jelezte, náluk a Microsoft 365 admin center van nyekken...

A Docker státusz oldalon ennyit már írnak:

"[Identified] We have identified the underlying issue with one of our cloud service providers. We are monitoring the situation and prepare our systems for when the issues with our service provider resolve."

( trey | 2025. 10. 20., h – 11:15 )

Szerkesztve: 2025. 10. 20., h – 11:15

Jól hangzik!

(sub)

trey @ gépház

Egyetlen AWS régió esett ki, nagyon gáz hogy még a nagyok is elesnek, senkinél nincs régió független HA, de tovább megyek, EU felhasználóként hogyhogy a személyes adataimmal foglalkozó szolgáltatás is döglött, miközben azt ugye biztos nem US-East régióban tárolják...?

A Route53-ban van multi-zone funkcionalitás egyáltalán? A felületről nem emlékszem ilyesmire, hogy lehetne egy zónánál kérni, hogy több régióban is hozza létre. A multi-AZ meg ahogy látjuk, kevés.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

HA / Backup tesztről hallott már ezeknek a cégeknek az üzemeltetése vagy odáig még nem jutottak a tankönyvben?

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Így van, AWS-ben még mindig vannak (mindig is voltak) ilyen bedrótozott szarságok amik 99.9999%ban jók lesznek (és ezért számodra láthatatlan, mindegy).

Amikor valamit igénybe veszel aminek a 26. layere alatt van egy ilyen bedrótozott szarság és ezért már akár nem is tudsz róla, szerződésben sem szerepel akkor kb. így jártál (mint most).

A probléma ott van, hogy az AWS-nek vannak olyan, globális szolgáltatásai, amik csak us-east-1-ben mennek, nincsenek HA-val ellátva. És lehalt az us-east-1, és emiatt minden, ami az ott futó globális szolgáltatásokat használja, tök mindegy, hogy melyik adatközpontban fut. Azaz eu-central-1-ben hiába futtatsz te valamit, ha van olyan szolgáltatás, ami us-east-1-ben fut, érintett leszel.

Király... Ez már a teljesen megvalósított Five Pillars of the Well-Architected Framework vagy vannak még egyéb ehhez hasonló bedrótozott függőségek?

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ha belegondolsz valahol valóban vicces ez az eltartott kisujjas "5-pillars WAF sallala ..." a mai nap tükrében :)

Persze ha a másik irányból nézed akkor fut a felhőben egy tonna összetákolt szar.  Amit az AWS persze kevéssé bán hiszen az nekik csak több pénzt jelent :)

Hát értem. Amúgy nem hiszem, hogy az AWS mérnökei annyire balfaszok lennének, hogy ne tudnák megoldani a HA-t a core szolgáltatásaikra, ez inkább szándékos sprólásnak tűnik. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ha jól láttam az us-east-1 esett ki ami nem egy átlagos AWS régió. Sok belső és publikus AWS cucc csak ott fut vagy csak ott érhető el és a kaszkád hatások miatt olyan szolgáltatások elesnek ilyenkor amikre az ember elsőre nem is gondolna, akár más régiókban is. Például a Route 53 console-ja csak us-east-1-ben volt anno. Amikor pár éve volt egy ilyen akkor a us-east-1 workloadunkról azért nem tudtak a fejlesztők gyorsan elváltani mert a step-by-step doksiban a Route 53 web console használata szerepelt és pár óráig küzdöttek mielőtt szóltak volna nekünk. Emellett még persze egy csomó más szolgáltatás is meghót, de a pontos listára már nem emlékszem csak erre a kissé vicces esetre.

Reméltem hogy azóta az AWS már betartja a saját javaslatát és minden szolgáltatást több régióba is kirak, de ezek szerint ezt még nem sikerült megugrani.

( hnsz2002 v | 2025. 10. 20., h – 14:18 )

A felhő az jó, értem? :)

"Sose a gép a hülye."

Jobb, mint Vér Pistike rencergizda, aki semmit nem dokumentál és amikor áll a cég épp nem ér rá felvenni a telefont. De komoly cég Vér István alvállalkozója sem jobb, aki tudatlanul tartja az ügyfelet, hogy valójában egy noname hosting támogatás nélküli gépén fut a kritikus alkalmazása, és már évek óta semmire nincs támogatás.

Olyan is van, ahol a munka nem is lényeg h. el legyen végezve (elmúlt pár hét történesei alapján, amit hálistennek nem közvetlen érintettként csak a kollégáim elmeséléséből hallgattam végig), hanem csak az h. lepapírozva minden le legyen. Különben hiába végezted el magát a munkát sikeresen - miközben megoldottad a váratlan kolosszális fuckup-ot - , a nem tökéletes papírozás miatt leszel mégis sortűz elé állítva.

Nem, de ha abban vannak a taskok, hogy mit kell csinálni, meg ki mivel hogy áll - főleg ha egymásnak adjátok-veszitek, akkor anélkül elég nehéz. Olyan mint a bevásárló lista... Emlékszel erre-arra, meg mintha az is kellene, veszel valamit, aztán hazamész, és... OK, ezt nem vettem. Ezt sem. Ez nem is kellett volna. Ebből fele annyi is elég lett volna, vagy épp 3x ennyi kell.

Szóval lehet nélküle dolgozgatni persze, ötletszerűen, emlékekből... Aztán vagy jó lesz, vagy nem. Vagy azt kellett csinálni vagy nem, vagy azon a gépen vagy nem... :)

"Sose a gép a hülye."

Mert nem az asztal alatt volt a szerver, hanem valahol máshol. Ott nem volt másik gépük amivel helyettesítették volna. Ezért írtam, ha a cégnél bent az asztal alatt tartják, ha más nem a legerősebb notit nevezik kis szervernek oszt jóvan :D

https://index.hu/napirajz/2015/11/10/aeroport_kaputt/

Fedora 42, Thinkpad x280

Értem én, csak hát te jöttél azzal, hogy annyi idő alatt lett életre lehelve, mintha vérpistike csinálta volna. Aztán itt az utolsó vérpistikés pont nem ilyen volt. Pedig gondolom laptopja speciel volt a prohardvereseknek is :)

ha a cégnél bent az asztal alatt tartják

tudod, ha a nagymama csilingelt volna, ő lett volna a villamos :) 

Jah felénk nagyon is jellemző, hogy Mancika néninek ha nem jön be a jira, rögtön tudja, hogy azért nem jön be mert az AWS us-east lehalt.

Majd pár másodperc múlvva megnyugszik, mondván de jó mert 100 ak dolgoznak a hiba elhárításán ...

Életszerű ...

Fedora 42, Thinkpad x280

Ilyenkor mindig eszembe jut egy nagy partner, aki nagyon frankó cloud rendszert épített. Tényleg odatette az embert, a technikát, tesztelt, ment innovatívan előre, kvázi úttörőként a témában.

Aztán voltam a másik cég, aki 1 gépre, de geo-redundáns backupra épített. Helyben gyors restore biztosított, arra a 10 évben egyszeri gép gebaszra. Meg a távoli helyen backup, ha leégne az egész szerverterem.

Szóval a nagy csillagrombolónak volt max pár hónapos uptime. Volt, hogy 2 hetet alig hozott össze, mert szerencsétlen rendszer esett-kelt állandóan. A technika ördöge sosem aludt náluk.
A másik cégnél meg 3 éves uptime. Faék egyszerű kiépítés, jó hardveren, cserébe stabilan megy.

A fenti kontraszt többször eszembe jut és ha az igény mégsem annyira kívánja, inkább egy single vagy aktív-passzív megoldást építünk ki, kézzel billentve. Az aktív-> passzív etetés is olykor egyszerű megoldásokkal megy (pl. rsync), nem elosztott fájlrendszer. Így nem tud bekavarni Murphy bácsi. Persze ehhez az kell, hogy az üzleti model ezt megengedje. A $-t látva, általában megengedi :)

Overengineering, na ja. Nem csak szoftvert, infrát is lehet overengineerelni. 
Nekem van egy olyan elméletem hogy a legkisebbeket meg a legnagyobbakat kell cloudba tenni.
Középen van egy elég tisztességes sáv ahol egyszerűen nem éri meg a cloud. Maximum egyes jól kiválasztott részeket érdemes cloudba tenni és akkor lesz hybrid megoldás. Ez a sáv a cloud providerek ajánlatainak függvényében mozog valamennyire. 

Így. A hibrid IaaS a legjobb, de az a legbonyolultabb, így az marad a középső sáv nagyobb játékosainak, a többiek számára a cloud inkább hidegtartaléinak jó. 

PaaS/SaaS esetén hacsak nem core terület, sajnos mindenkinek inkább cloud, mert azokhoz helyben nem lehet értelmes csapatot építeni. Szükséges méret drága és halálra unják magukat, olyan ritka a komoly esemény. Cserében le is pusztul a tudásuk. Amíg a broadcom nem rondított bele, a vmware tanzu-ban nagy reményem volt. Ügyesen csomagolta a hibrid szolgáltatást olyan tudásba, ami középkategória fölött helyben amúgy is megvolt.

>  Szükséges méret drága és halálra unják magukat, olyan ritka a komoly esemény.

Ilyenkor kell bérelni az embert. Persze, nem lesz olyan jó, mint a helyi csapat, de megüti az elégségest. Cserébe nem ül és malmozik, ha nincs munka, hanem dolgozik más ügyfél fényévente egyszer előjövő haváriáján.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

És vissza is tértünk a felhő problémájára. Ha az ember jó neked, mint XaaS, akkor a szoftver miért nem? Outsourcing pont ugyanazzal küzd, mint a felhő. Skálázni és olcsón tartani akkor tudod, ha végletekig standard és primitív építő elemekből rakod össze, hogy a frissen beesett bölcsész is el tudja végezni a dolgok 80+ százalékát. Aztán jön egy olyan komplex helyzet ami 3 csapaton is átnyúlik, és mindhárom pingvinezik, hogy "de hát nálam minden zöld", és kezdődik a ticket pingpong. Mert ugye ha helyben nincs szakértelem, akkor még annak felmérése is nehéz, hogy hány és milyen contractor kell a virtuális csapatba, így egyszerűbb kiadni erre szakosodott cégnek. De ennek a rekurzív folytatása az, hogy a felhő jó. Más oldja meg a felépítés bonyolultságát, más üzemelteti, nekem csak használni kell.

Külső supporttal de szépet szivtunk évekig. Nagy cég, sok technikai, főleg felhős tudással. Volt 1 max 2 ember, aki értette, a nagyon magas problémák nála is megakasztották a folyamatot, de azért szállított megoldást 1-2 hét alatt. Valszeg senior volt, ritkán ért rá. Ha nem őt osztották rád, jott a bénázás. Ami napi szinten előfordul, azt kb tudta, ha nem, akkor Google. Akár ott a meeten :) De ha már kicsit összetettebb volt a probléma, nem triviális, Google nincs tele a problémával, akkor elvérzett. Na de pont ezért kertünk supportot, mert ennyire a mi wineseink is benne voltak.

Ha jott is ugyes srác, tovább alt fél év után. Gondolom külföld vagy magan vállalkozás.

Másik céggel meg úgy jártunk, aki outsource-ba is foglalkoztat: Vezető fejlesztőnk elment, tudást egy partnernek adta volna tovább, aki bedolgozik nálunk. Fél év alatt 3 srácot küldtek hozzánk. Vagy hulye volt vagy okos, de dobbantott külföldre. Szóval en is azt látom, hogy attól, hogy szolgáltatásként veszed igénybe a munkaerőt, Koránt sem biztos, hogy jobban jársz. Ott is ugyanazzal küzdenek, mint te.

A síikert kifejezi, hogy végül vissza foglalkoztatjuk a vezeto fejlesztőt.

Mindkettő cég VPS szolgáltatást adott a piacnak. Így az alapokat nézve, ugyanaz volt a feladat. Hogy a felettes réteget ki mire használta, az már más. A nagy cloud rendszert biztos komolyabb üzleti partnerek vették igénybe, mert komolyabb számok voltak mögötte. Csak a gyakorlatban sajnos, ami el tudott romlani, elromlott. És itt, ha jól értettem, a szoftveres oldalról voltak bajok.

Lazán kapcsolódik: volt, hogy DRBD + OCFS2 -vel volt megoldva a cluster fájlrendszere egy nagy terhelésű, terhelés elosztott weboldal kiszolgálására. 99%-ban csak olvasás történik.
Egy kernel frissítés után 1-2 hetente split-brain állapotba kerültek a node-ok.
Előző kernellel jó volt. Használtuk tovább előző kernellel, majd amikor kijött egy újabb kernel, ismét stabilan ment. Kb 1 évre rá megismétlődött a jelenség egy új kernel frissítéssel.
Na akkor bontottuk el a clustert és lett 2 single gép, aktív-passzív megoldással. Késleltetett rsync alapú fájl szinkronnal. Csak az SQL maradt replikálva.
Ez a jelenség is megerősít abban, hogy minél több szoftveres réteget pakolunk egymásra, annál könnyebben megborul.
Az életben szinte sosem HW hiba miatt volt leállásunk, hanem sunyi szoftver bugok miatt, főleg cluster környezetben.

( zslaszlo v | 2025. 10. 20., h – 14:43 )

Szerkesztve: 2025. 10. 20., h – 14:45

Akkor ezért állt ma délelőtt a Canva is valószínűleg... Szerk. Mármint az AWS miatt.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( hrgy84 | 2025. 10. 20., h – 16:43 )

A Slack is érintett volt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( n.balazs v | 2025. 10. 20., h – 23:27 )

Szerintem a topic címét érdemes lenne módosítani Dockerről AWS-re. Csak a pontosság kedvéért.

Szerencsére én ma ebből az egészből semmit se vettem észre. Nyugodtan tudtam dolgozni.