Reprodukalhatatlan(?) hiba Spring Boot app-ban

 ( Hevi | 2018. március 24., szombat - 0:06 )

Adott egy listener microservice, gyakorlatilag ket halozati zona kozt proxyzik. Spring Boot app, egy controller, ket interceptor a ki-, es bemeno oldalon, meg egy service osztaly, hogy megse mar a contollerben legyen minden.

Tok jo, meg minden, Postman requestekkel developer gepen megy frankon. Kitesszuk dev-re, megy frankon. Staging, postmannel megy, eles adattal, nem megy... Hosszas kinlodas utan kideritettuk, hogy a bejovo requestet nem feltetlenul pontosan irja le a dokumentacio, szoval gyorsan hozzaigazitottuk a kodot. Developer gepen, dev serveren Postmannel tokeletes. Staging NullPointerezik.

Meg hosszasabb szenvedes utan (mivel staginghez JMX mar nem jar) kiderul, hogy a controller nem kapja meg az adatot, a request object nullokat tartalmaz. Fogalmunk sincs mi lehet, sok-sok google, trial and error, szenvedes es szivas.

1-2 nap megint eltellik, mar ott jarunk, hogy az interceptorban meg megvan az adat meg stagingen is, viszont a controllerben mar nincs. Szoval azt, hogy az nginx nyelne le, vagy a Tomcat dobna el a POST body-t, azt sikeresen kizartuk. Kizartuk azt is, hogy a HttpServletRequest inputStream-jet piszkalnank, amivel esetleg consumed allapotba kerulne, ezaltal olvashatatlalanna valva.

Kiderult, hogy a Java verzio nagyban kulonbozott a harom rendszeren, Fejlesztoi gep Java 8, dev server Java 8, staging Java 7. Hogy honnan szedte ezt ossze a Puppet, fogalmam sincs (infrastukturas sracok is csak neztek, hiszen amit irtak, az Java 8-at tartalmazott). Ezt gyorsan javitottuk, hatha a sevlet API valtozott valahogy, nagyjabol hasonlo Java verziora hozva: stage meg mindig nem megy.

Oke, Tomcat verzio. Mind harom rendszeren kicsit kulonbozo van. Stage-t hozzaigazitjuk a dev serverhez. Semmi. Uj kollega szuz rendszeren: szinten megy.

Lassan csak az OS kulonbozo, macOS fejlesztoi gepeken megy, CentOS 6.9(?) a dev serveren, CentOS 7.4(?) stagingen. Osszerakunk egy Docker image-t CentOS 7 image-dzsel, ugyanazzal a Java, Tomcat verzioval, Es reprodukaltuk!

Csak vicceltem, meg mindig rendesen mukodik az app.

Es lassan kifogytam az otletekbol. Fogalmam sincs, hogy mi okozhatja, hogy ugyanaz a war file a fejlesztoi gepeken, a docker containerben, a dev serveren megy, stagingen nem.

Kozben van egy PoC workaround megoldasunk egy Tomcat filterrel, ami elteszi session valtozoba az adatot, amit a controllerben kiolvasunk, de azert na, ez nem az igazi...

X-akta?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Azonos jdk? Nem openjdk az egyik többi meg oracle, vagy fordítva? Ha kiveszitek az interceptor mi történik? Jól értem, hogy stagingen egy külső rendszer küldi a requesteket? Megpróbáltátok pontosan azt küldeni devre? Esetleg rá tudjátok kötni arra, hogy ott mi történik?

Amúgy ha minden környezet konzisztensen produkálná ezt a viselkedést, akkor jackson mapper környékén kutakodnék.

+1 a dependency kínra, valami más (régebbi) verziójú jackson-t tolhat be.

Egy: gyere a letscode.hu/slack-re, ott esélyesebben fogsz választ találni.

Kettő: nullpointer exception-nál stacktrace mit ír ki? Loggolásnál eredmény?

Kb most kellene mindent lezúzni, és tényleg ugyanazt a rendszert, ugyanazokat a komponenseket telepíteni az összes készülékre.
(PS: egészen véletlenül nem lehetne az 'rinetd' nevű programot használi erre a célra, kb ezredakkora erőforrásigénnyel és hibalehetőséggel?)

Valami security cucc nem lehet az oka?

Koszi a tippeket, vegulis sikerult megoldani a dolgot...

conf/server.xml: maxPostSize="50"

...

:sirvarohogossmiley:

Amugy erdekes hogy ez a konfig csak a filter/interceptor utan lep eletbe, hiszen ott meg megvolt az adat...

legalább megvan xd

Az a baj, hogy a PCI compliance miatt korlatozott hozzaferesunk van a stage serverekhez, pl. app configra csak olvasasi, server configra meg az se. Igy meg azert nehez volt ezt kinyomozni :)

Asszem jobban bele kell neznem a Spring meg Tomcat belso mukodesebe.

Off: akkor itt koncepcionális hiba van: ha az az alapelv, hogy a developer nem nyúlhat az éles rendszerhez, akkor ki kell mondani, hogy az éles rendszer problémái sem tartoznak a developerre. Elégtelen volt a tesztelés, hibás/inkompatibilis a tesztkörnyezet, whatever. Lehet így is működni, meg lehet 'devops'-osan, de a kettőt összemixelni (a developer ne nyúljon az éles rendszerhez, de oldja meg annak a hibáit) nem lehet.

Nekem ebből az jön le hogy a drága üzemeltetők a fejlesztőkre mutogattak, amikor ők voltak képtelenek rendesen beconfigolni a környezetet...

Az üzemeltető azt állít be, amit a rendszer specifikációja igényel. Ha nem volt leítva, hogy maxPostSize legalább 123 kell legyen, akkor marad a default, illetve az, amit a sprinbootosböszmeség.jar hoz magával, amit meg vélhetően a fejlesztő csomagol egybe.

Akkor a teszt-rendszeren és az élesen más volt a default, ami szerinted mentség az üzemeltetői oldalon, jól értem? Vagy?

Az üzemeltetés az élesben csak azt állít be/át, amiről információt kap. Én két dolgot tudok elképzelni: az egyik, hogy a tesztelés során kisebb méretű adatokkal végezték a teszteket, amik belefértek a limitbe. Láttunk már ilyet: Java, ssh-val tölt le/fől, teszten műx, élesen néha elhasal. Mint kiderült, ha túl nagy a fájl, amit mozgatni kell, akkor van gebac. Teszten sosem volt nagy a fájl, ezért nem jött elő. Ez a tesztesetek összeállítóinak a sara.
A másik, hogy teszteltek nagyobb adatkupaccal is, és amikor elhasalt, akkor a teszten átállítottak ezt-azt, és erről az éles üzemeltetést az elvárt változáskezelési folyamaton keresztül nem értesítették, és ott maradt a kisebb érték.

A lényeg hogy nem az üzemeltetés hibája (de mindenki másé igen) hogy élesen nem megy a rendszer, és az sem hogy nem volt egy félig rátermedt üzemeltető sem a csapatban aki észrevette volna a triviális hibát. Ok.

Pontosan. Ha az üzemeltetésnek explicit módon nem adták ki az ukázt, hogy a foo=50 paramétert módosítsák az 1.2.3.4 verzió élesítése előtt foo=123-ra, akkor teljesen jogos, hogy 50-en maradt.

Persze, megértem hogy fogalmatok sincs a rendszerekről amivel dolgoztok és igényetek sincs rá hogy legyen, de hogy ezt a problémát a fejlesztőknek kellett kitalálni, az szomorú.

+1

Igazabol az a baj, hogy vakon kellett debugolni, mert ugyan remote debugot kaptunk a vegen, de peldaul egy VM clone-t mar nem (tul sok effort lett volna kikaparni belole a nem publikus reszeket). Igy meg azert nehez volt ramutatni, hogy hol is van a hiba. Mar az elejen biztos volt, hogy a staging _valahogy_ eldobja a post body-t. Nem tudtuk, hogy miert, bugra gyanakodtunk (hiszen a kornyezet konfiguracioja miert kulonbozne a dev es a staging kozt?).

Ha lett volna hozzaferesunk a konfigokhoz, lehet sokkal hamarabb rajottunk volna, hogy "he, hat az nem ugy nez ki, ahogy ki kellene neznie". Puppet konfiguraciot megint csak nem lathatjuk, nem hasznalhatjuk Docker instance felsetupolasara, mikor arra kertem oket, hogy generaljanak egy docker image-t a puppet configbol, akkor azt nem lehet, mert csak, szoval, na...

De mostmar ezt is tudjuk, es ez egy jo adu asz ebben a nagyedevben, hogy elkezdjuk verni az asztalt, hogy rendbe kell tenni a rendszereket es processeket, mert ez igy baromira szuboptimalis.

Kérdés: a telepítési dokumentációban szerepelt, hogy a "FooBarBaz=123 vagy több" beállítás kell a működéshez? És ez eljutott feladatként az üzemeltetőkhöz?
Az asztalt csapkodhatod, de előtte érdemes megnézni az átadott dokumentációt, hogy az mit is ír erről... Mert a megrendelő azt fogja a t. szállító orra alá tolni.

Szerinted, ha leadunk egy requestet, hogy kell egy listener box, ami requesteket fogad kintrol, es proxyzza a belsobb halozatok fele, akkor ki kell kotni, hogy "de gyerekek, ugy csinaljatok am, ahogy a dev servert, mert igen, a stagingen is szuksegunk lesz a post adatokra"? Szerintem ez kicsit lekezelo, ha ennyi intelligenciat se feltetelezunk a masikrol...

Nem waterfallozunk, agile + devOps, ami mukodne is rendesen, viszont az nem jarja, hogy minden nyomas a fejleszton van, mig az uzemelteto elvan a sajat kis vilagaban es azt mondja: "hat errol nem volt szo". Miert nem volt szo? Tobbszor is osszeultunk, tobbszor is volt meeting arrol, hogy mi is kell nekunk. Ha annyi proaktivitas se nem szorult belejuk, azert ne mi legyunk mar a felelosek.

Mert ugy is gondolhatunk az uzemeltetokre, mint kollegakra, akikkel egyutt dolgozunk es oldjuk meg a felmerulo problemakat, de ugy is tekinthetunk rajuk, hogy mi vagyunk az o stakeholderjei, szoval ha nincs valami megcsinalva, akkor verhetjuk az asztalt, ha valami szar. Nekem mindegy, csak le kell tisztazni a viszonyt es akkor azt varom el amit, es ugy viselkedek ahogy a helyzet kivanja.

Mégegyszer: leírtátok, hogy az adott paraméter milyen értéket/minimumot kel felvegyen? Ha nem, akkor már bocs, de az élesben (meg az uat esetében sem) "csak úgy" nem tekeri meg senki a beállítást. Van olyan paraméter, amit a fejlesztő definiál, hogy mi legyen, van, amire javaslatot tesz és az üzlet mondja meg, hogy mi és hogy, és van, ami az üzemeltetés hatásköre.
Egy request maximális mérete az véleményem szerint üzlet+fejlesztő, az üzem pedig a kapott explicit értékkel beállítja.

Nekem is van szerencsém éles/teszt/fejlesztői motyókat párhuzamosan üzemeltetni: az éles és teszt konfig módosítása verziózottan, fejlesztói changelog (mit kell felvenni/átállítani/stb.) illetve standard változáskezelés alapján történik. Ha sem az üzlet, sem a fejlesztő nem jelzi írásban (módosítási igény, changelog), hogy az adott verzióhoz x, y meg z paramétert változtassuk meg, akkor az bizony marad, ami volt.

Speciel üzemeltetési probléma, hogy a dev miért tér el a staging környezettől ezen paraméterben, ha nincs leírva, hogy be kéne állítani. Pont az a probléma, hogy más az dev rendszer egy olyan konfigurációban, amiben nem kimondott, hogy másnak kell lennie, mint a staging, ami normális esetben üzemeltetési gond, és nem fejlesztői.

Az a baj, hogy csillió paraméter van, és nem lehet mindenre gondolni. Te avval kezdenél egy fejlesztést, hogy a TCP tuningtól kezdve minden szar paramétert leegyeztettek, hogy tuti ne legyen baj? Mikor én anno IIS-re fejlesztettem, tisztában voltam vele, hogy mennyi olyan (defaulttól eltérő!) beállítás lehetett volna, amitől fejreáll minden, mégse volt gond, egyrészt senki nem állítgatott össze-vissza dolgokat, másrészt a környezetek egyformák voltak. Úgy tűnik, hogy a kérdező esetében ez nem így volt. Nem egyes paraméterekről kellene beszélgetni, hanem a big picture-t kéne nézni inkább. Manapság már amúgy sokkal jobb módszerek vannak arra, hogy két környezet egyforma legyen és az alkalmazáshoz lehet csomagolni az őt futtató környezet paramétereit.

Kicsit másképp fogalmaztam volna, de a lényegével egyetértek.
Jó dolog helyismeret nélkül megmondani a tutit.

"Jó dolog helyismeret nélkül megmondani a tutit."

We are hiring! :)

:)
Tönkre is menne a cég, ha odamennék :D

Amire nem gondolsz, nem írsz elő, hogy mennyi legyen, hogy legyen számolva, az defaultban marad. Az, hogy a dev meg a staging esetén más a default, illetve a beállított érték, az, ahogy írtam is, jó kérdés, hogy miért van: azért, mert más verzió van fent, más alapértelmezett értékekkel, vagy azért, mert a dev-en szabadon turkálható/módosítható a konfig.

Az éles/uat/staging konfigok egy része valóban lehet azonos, de a kommunikációs paraméterek, DB-hozzáférések paraméterei mondjuk illő, hogy eltérjenek. Innentől kezdve meg csak idő kérdése, hogy más is szétcsússzon, ha nem jól van kitalálva a konfigmenedzsment.

Az a baj, hogy a default nagyon nem 50.

Picit azert tobb.

https://stackoverflow.com/a/2943515

Nem veletlen nem gyanakodtunk arrafele. Viszont ha lett volna ralatas a konfigra, akkor random trial&error konfig olvasgatas kozben biztos kibokte volna a szemunket.

Nomostan én amit láttam springboot-os motyót, az a jar mellé tett application.properties fájlt nyalja fel, meg a jar-ba becsomagolt beállításokat. Az előbbi verziókezelőből kerül a helyére, miután a fejlesztői leírás (changelog), ileltve az üzleti igények alapján a szükséges paraméterek beállításra/módosításra kerültek, a jar-ba csomagolt egyéb paraméterek beállításait a fejlesztő/szállító adja a csomaggal együtt.
Egyik sem az üzemeltetői terület hatásköre egyébként.

Valószínűleg egy war file-t csinálnak, és az kerül tomcat-be deploy-ba, és annak is biztos megvan az oka, hogy miért.

Igy van.

Ez server.xml -> Tomcat config, semmi koze az app confighoz.

Nomostan nálam a springboot-os app minden kunszt és Tomcat nélkül úgy indul, hogy "java -jar motyo.1.2.3.jar" meg esetleg néhány paraméter, ha szükséges - spring.log helye pl. merthogy adott gépen n+1 ilyen app indul, és ne üssék egymást...

Az az embedded Tomcat verzios. Nem tudom productionben mennyire elterjedt, nalunk sajnos nem. Viszont Spring Boot tud deployolhato war-t is generalni, semmiben nem kulonbozik egy sima war-tol.

Micrservicek, egy app per VM. Szoval az, hogy tobb is futhasson egymas mellett, az nem szempont.

Köszönöm, így már világos :-)

Lehettem volna egyertelmubb is a topic inditoban, lathatolag ez nem trivialis mindenkinek :) legkozelebb megprobalok odafigyelni erre is.

Aztan meg a kollegak allandoan panaszkodnak, hogy tul korulmenyes vagyok es mindent reszletekbe menoen magyarazok el. Dehat mindannyian kulonbozo hatterrel rendelkezunk, igy nem feltetlen erhetunk minden aspektust magyarazaf nelkul.

Viszont mint latjuk, ha az ember nem eleg pontos, akkor nagyon konnyen kialakulhat az egymas mellett elbeszeles.

Szoval na, nem tudom mi a jo, de hosszu tavon azert megprobalok pontosabb lenni!

:) Én voltam értetlen, de mentségemre szolgáljon, hogy nekem a springboot úgy lett "eladva", hogy az a beágyazott tomcat-es megoldás, ellenben a tomcat+war felállású "régi"-vel.

Ha Agile + DevOps, akkor miert van olyan, hogy uzemeltetes?

Errol a fejlesztoket kellene megkerdezni, persze ok sosem ismerik el az okokat :) /bocs ha kivetel vagy./
____________________
echo crash > /dev/kmem

... nem arról van szó, hogy az üzemeltetőnek magától kellett volna kitalálnia hogy egy config file-t írjon át, hanem arról, hogy 0 a segítőkészség, és csak mutogat a fejlesztőre, amikor üzemeltetői domain tudással ezt a problémát körübelül 30 perc alatt kilehetett volna találni.

-1

Bitre ugyanazt a requestet hasznaltuk az osszes rendszer tesztelesere. Azert legyszi feltetelezz mar ennyi szakmaisagot rolam.

Ugyanigy, nem tudok rola, hogy a konfigot utana kellett volna huzni barhol is, kiveve most a stagingen.

Amugy jo kerdes, hogy kinek a felelosege a rendszerek karbantartasa. Ahogy a masik kommentben emlitettem, ugy latom, hogy minden feleloseg a developerekre van tolva, ok ismerjek a kodot, ok ismerjek a kornyezetet, hogy hogy kell konfigolni, stb, mig az uzemeltetes, a networking jol elvan a sajat langymelegeben. Szerintem az uzemeltetes legyen bevonva a tervezesbe (be volt), lassa at es legyen felelosege az altala osszerakott rendszereket illetoen.

Szerintem ez az igazi devOps, amikor a kulonbozo teruletek kepviseloi osszegyulnek, es eldontik, hogy "ez a feladat, hogyan is oldjuk meg", de mindenki vallalja a feleloseget a sajat reszeert, nem az, hogy a fejeszto rohangaljon mindenert, mint a mergezett eger... A fejleszto tudjon a kornyezetrol, de ne az o felelosege legyen, ugyanigy az uzemelteto tudjon az alkalmazasrol, de ne az o felelosege legyen.

Nem arrol van szo, hogy odaloktuk nekik, hogy "nesztek, innentol a tietek", hanem arrol, hogy vannak, akik azt mondjak, hogy "jahat, nem specifikaltad, nem csinaltam meg... ja hogy nem is tudhattal rola, hogy kulonbozo? Ja, ez a mi hibank, de az onok problemaja...".

Én azt nem értem, hogy ha már spring bootról beszélünk és 2018 van, miért xml configokkal baszakodtok ahelyett, hogy beállítjátok application.propertiesben, az üzemeltetőnek meg adtok egy jart, hogy ezt ezen a java verzión futtassátok, viszontlátásra?

Mert szeretik magukat szopatni, nyilvanvalo, nem? Nem? De.

Egy atlagos(an elcseszett) angol cegnel a fejlesztes es az uzemeltetes ket kulon univerzum, az uzemelteto orul, hogy 10+ eve nem kellett Java verziot (sem) valtoztatnia, a fejleszto meg hiaba kaparja a falat, az uzemeltetesnek vetojoga van, mar ha a fejleszto egyaltalan szobaallhat barkivel. Deployment lekorlatozva Tomcat 7.0-ba bedobott war-okra, a logokhoz az uzemeltetes kulon keres utjan elerhetoseget biztosit. Remote debugrol ne is almodjon a tisztelt fejleszto, azert vannak a logok.

Vagy egy sztori, Java app OutOfMemoryError-ral elszall elesben tobbszor is, kerdezem, mennyi memoria van neki, mondjak 2 GB (egy ~100ezer gepjarmubol erkezo geolokaciokat processzalo app-rol beszelunk, az MQ-n befuto uzenetek szama 100/masodpercben merheto, ezeket bizonyos feltetelek eseten valamilyen idoablakkal aggregalni kell, es az aggregalt adatokat tovabb processzalni, szoval nem egy egyszeru REST service). Kerdezem, nem lehetne esetleg kiprobalni novelni a memoriat, hatha tenyleg keves neki? Azt nem lehet, a 2GB eddig mindig eleg volt, kulonben is draga a memoria (???). Oke, nincs tobb kerdesem...

Ha te nem ilyen cegnel dolgozol, orulj neki es becsuld meg magad :)

+1

+sok
____________________
echo crash > /dev/kmem

+1

Igy van.

Amit jelenleg tapasztalok az, hogy a Product team, es benne a fejleszto az ertsen mindenhez (is!), mig a tobbiek elvannak a sajat kis domainjukben... Mert ugye a fejleszto legyen tisztaban a koddal, a legujabb technologiakkal, modszertanokkal; legyen tisztaban a tesztelessel; legyen tisztaban az uzemeltetessel; persze a business domainhez is konyitania kell, mert na.

Nem panaszkodom, mert igy novekszik az ember tudasszintje, az viszont nem tetszik, hogy a "support" csapatok egy szalmaszalat nem tennenek keresztbe, hogy elore vigyek a dolgot. Proaktivitas, mint olyan ebben az esetben nem volt az uzemeltetes reszerol, latszott rajtuk, hogy csak nyug vagyunk nekik.

Nos, ez a hozzaallas nem igazan tetszik, de miutan leultem a team leadjukkel egy 10 percre es elmagyaraztam neki, hogy mi nem ellenseg vagyunk, hanem baratok, meghozza olyan baratok, ahol az egymasrautaltsag kicsit egyoldalu, szerencsere az o hozzaallasuk is valtozott kicsit.

Nem lenne jobb, ha konténerben szállítanátok mindent, és ott meg a doksiban le lehetne írni, hogy mi az az 5 db paraméter amit beállíthat (minimum mennyi ram, mennyi cpu, bejövő hálózati kapcsolat), máshoz nem nyúlhat?

Nyilván nem 2 perc átállni erre a módszerre, de lehet, hogy megérné.

Egy atlagos fejlesztonek annyi beleszolasa van ebbe, mint hogy holnap essen-e az eso.

(Es akkor meg az atallas koltsegerol es a megkerdojelezheto megterulesrol nem is beszeltunk...)

Nyilván egy ilyen döntés e fölött a szint fölött születik. De pont ez az eset, ahol szerintem 3-4 emberhét simán elment erre a problémára, ha nem több. Ezért ki lehetne dolgozni az üzemeltetéssel _közösen_ egy javaslatot.

Nyilván ez egy sok szereplős történet egy nagyobb cégnél, ahol mindenkinek megvan a saját (ellen)érdeke, de nekem voltak pozitív tapasztalataim. Ha nem próbálják meg, akkor biztos nem lesz semmi. Akkor marad az, hogy az üzemeltetőkkel kell járni sörözni, és "shadow-IT" módban megoldani a dolgokat. :)

Az a baj, hogy a PCI compliance miatt korlatozott hozzaferesunk van a stage serverekhez

Ez nem indok arra, hogy ne az általatok adott leírás szerint települjön mindegyik környezet.
Továbbá az eredményről (bárki is csinálja) megvalósulási doksit szokás csinálni rendes helyeken, amiből egyből kiderül, ha a konfig fájlban mégis más van az egyik helyen, mint a másikon.

.

2 gondolat:

1. Ez így nekem nem DevOps/Agile hozzáállás. A mi team-jeink a vertical-ok mentén vannak felszabdalva és egy team egy adott vertical-ért teljes felelősséget vállal. A backend-től a frontend-ig, plusz deployment (CI/CD) és infrastruktúra.
Mi maintain-eljük az egész cloud infrastruktúrát a K8s node-tól kezdve az összes service-ig a cloudban.
Az infrastruktúra is a kód részét képezi ("Infrastructure as Code" mindset), tehát teljesen a mi felelősségünk alá esik.
Nekem 2018-ban ezt jelenti a DevOps/Agile fejlesztés és nem azt, hogy E-Mailben vagy hivatalos levélben aláírással és pecsétekkel kell megkérnem az XY osztály részlegét, hogy deployolják a becsomagolt war file-omat. Persze lehet csak én vagyok nagyon szerencsés, hogy így dolgozhatok...

Minden estre szerintem nehéz úgy Agile fejleszteni, hogy ha a cég olyan dolgokat figyelmen kívül hagy, mint:
team autonomy
coninous integration / deployment (a master mindig healthy és deployolható és az új feature-ök Feature Branch-on jönnek be PR-eken keresztül)
fail fast philosophy
fast iteration

És ha az infrastruktúra nem a te hatásköröd, akkor nem vagyok benne teljesen biztos, hogy ezek egyáltalán megvalósíthatóak-e.

2. Ha nem engednek hozzá titeket a szerverhez és a konfigokhoz, akkor lehet csinálni egy Endpointot ami HTTP callra visszatolja az összes Environment variable-t, aztán lehet diffelni a különböző rendszerek beállításait. Bár ez tipikusan egy olyan megoldás amikor a dev-nek backdoor-t kell rakni a saját szoftverébe a shitty policy-k miatt a cégnél. :(

Jogos, de mindket problema a PCI/SOX kovetelmenyek miatt letezik szamunkra. Erzekeny adatokkal dolgozunk, igy komoly torvenyi kotelezettsegeink vannak. Ennek egyike, hogy a developernek nem lehet hozzaferese a live rendszerekhez.

Tudunk tenni ellene? Nem.

Sajnos a csapatunk ilyen szempontbol oszver, ugyan vertikalisnak kene lenni, de ebben torvenyileg limitalva vagyunk. A torvenyt nem tudjuk megvaltoztatni (es amugyis jogos), szoval az egyuttmukodesen kell javitani.

En mindig ugy mentem oda az uzemeltetokhoz, hogy hogy tudnank _ssgiteni_ lekuzdeni ezt a problemat. De sajnos hiaba probaltuk sajat kezbe venni a problemat, nem tudtuk.

Innentol mar csak az oszinte beszelgetes hasznalhat, es jelenleg az a celom, hogy kialakitsam azt a viszonyt, ahol egyutt, es nem egymas ellen dolgozunk. Hiszen az mindenki erdeke :)

+1.

Nálunk is megvannak a törvényi követelmények, mégis hozzáférek éles logokhoz, vagy pl. tudok profilert futtatni éles rendszeren, tehát nem hiszem, hogy a törvényre lehetne fogni ezeknek a tiltását. (És persze ki van kötve, hogy logba nem megy PII, de ez ortogonális, mert ha a fejlesztő nem férne közvetlenül hozzá az éles logokhoz, akkor se mehetne bele PII.)

Háttőőőő ezt ne hangoztasd túlságosan, ha egy auditor észreveszi gáz lesz :P

Mi lesz gáz? Nem férek hozzá szenzitív adathoz és nem tudom direktben befolyásolni az éles rendszer működését. Ha külön devops részleg lenne, őket kellene megkérni, hogy nézzenek logot/futtassanak profilert, ami plusz egy kör, de ugyanúgy lenne valaki a cégben, aki rálát a dolgokra. Az mitől lesz "törvényesebb"?

Mondjuk 2018-ban nem hasznalunk tomcat-et meg containert ugy generalisan.
A masik, remote debug. Ha vegiglepteted, meglesz a tettes.

Abbol pont nem derult ki, ugy kellett rajonnunk, hogy az architect felvetette, hogy "probald uresen kuldeni..." es akkor megjott a controllerbe is az adat. "Probalj egy karaktert... probalj 10-et... probalj 100-at... na az mar nem megy, probalj 30-at...".

Vegulis eljutottunk az 50 byte-os hatarig, parszor meg leteszteltuk, hogy tenyleg 50-e a hatar, a header befolyasolja-e, vagy csak a body erintett, a lead tolt egy gyors google-t es kuldte is a megfejtest.

Utolag mar trivialis, hogy ezzel kellett volna kezdeni a debugolast, de mivel a kornyezethez nem fertunk hozza, es mert ez mindenhol mashol mukodott, igy nem csak environmentalra gondoltunk, hanem a bug lehetoseget se vetettuk el. Fel se merult, hogy a staging Tomcat mashogy lenne konfigolva.

Nem veletlen jott elo egy retron action pointkent, hogy "Assume nothing"! Sajnos az elet tenyleg ezt igazolja, dehat na, semmi se lehet tokeletes :)

Mindenesetre as elso ponthoz: ez van, ezt kell szeretni. Mindenki azon van (nagyjabol), hogy kikalapaljuk a kornyezetet, csak meg nem vagyunk ott teljesen. Surlodasok sajnos lesznek, amig nem tokeletes minden, de ezeket meg kezelni kell.

Nekem igazabol tok mindegy, hogy az infras sracoknak mit kenyelmes karbantartani, mert szivesen megtanulom barmelyik megoldast supportalni. Ha ok Tomcatet akarnak, akkor azt kapnak. Ha standalone jar-t, akkor azt. Nekem nem tisztem eldonteni, hogy melyik a jobb megoldas, hiszen nem ehhez (ehhez sem) ertek.

Viszont ha nekik ez jo, akkor am legyen. Tomcatet hasznalni nem kell felnetek jo lesz mindenki egyetert en nem ellenzem.

A vegen ugyis az dont, hogy a ket field expert hogy tud egyutt dolgozni, es hogy alapvetoen segitokeszseg van-e minden oldalrol, vagy magasrol leszaras... en jobb szeretem az elobbit

Eleg szep pelda arra, hogy mi a baj a mutable (Ansible, Puppet es tsai) rendszerekkel

NixOS-t mindenkinek! ;)

Ez az a fajta topic, amiért érdemes hup-ra járnom. Köszi :)