ugrás a tartalomhoz

Ti mit gondoltok erről a library-ről?

1

egy korabbi projectemben

MadBence · Feb. 4. (H), 22.11
egy korabbi projectemben hasznaltuk, annyira nem valt be. olyan problemat old meg, amit nem az alkalmazasnak kellene megoldania: nevezetesen hogy hogyan kell osszeallitani az alkalmazas konfigjat.

a 12factor ajanlasat erdemes megfogadni, tehat ENV valtozokba pakolni a konfigot, vagy hasznalni valami dedikalt megoldast, pl. docker secret vagy docker config. A lenyeg ugyanaz, ne az alkalmazas rakja ossze sajat maganak a konfiguraciot, csak kapja meg keszen valahogy.
2

Szerintem az a baj ezekkel,

inf3rno · Feb. 4. (H), 23.17
Szerintem az a baj ezekkel, hogy eleve téves a megközelítés. Kb. olyan, mintha dependency injection helyett globális változókat használnál. Az egyiknél a fentebbi szintről injektálod be a konfigot explicit módon, a másiknál meg valahonnan a háttérből előrántod implicit módon, valami sokszor nem dokumentált konvenció alapján, mint pl hogy a "./config" mappában vannak az eltérő környezetekhez tartozó konfig fájlok, és az "APP_MODE" környezeti változó írja le, hogy a "production.json"-t töltjük be, vagy a "dev.json"-t, de alapból mindkettő alá betöltjük a "default.json"-t is, aztán valahogy összemergeljük vele a hiányzó részeket, hogy ne kelljen már copy-paste-elni. Szóval ez a "global"-os megközelítés és a DRY principle használata együtt robbanóelegyet képez pont egy olyan részén az alkalmazásnak, ami ha lehet a legfontosabb. Mert ha valami miatt debug módba kerül éles szerveren, akkor szivárogtatni fog az alkalmazás.

Szvsz, ugyanúgy lehet kódban a konfig, viszont a fentiekkel ellentétben muszáj injektálni valahogy az alkalmazásba a konfigot, ahelyett, hogy hagynánk, hogy magától berántsa valahonnan. Talán a legfapadosabb példa a következő:

/*
app/ # ide jön a verziókövetett kód
data/ # ide jönnek az adatfájlok
dev.js # ez konfigurálja és indítja el az alkalmazást
*/
dev.js

var path = require("path");
var config = {};
config.db = {
	address: "localhost",
	username: "fasf3",
	password: "adg3t34fsf"
};
config.data = {
	directory: path.resolve("data")
};
var app = require("./app");
app.run(config);
Nyilván production környezethez meg lenne egy hasonló "production.js", aminek a tartalmát csak pár ember ismeri. Egyedül talán annyi hátránya van ennek, hogy az embernek fáj tesztet írni az ilyen indítófájlokra, annyira szög egyszerű, és talán nem is kell hozzá.

Ugyanígy meg lehetne oldani json-al is, elég egy `require("dev.config.json")`-t beletenni, és akkor nem kell változtatni az indító fájlt konfig cserekor. Viszont kapásból gondod lehet a data directory útvonalával, mert nem tudod, hogy a "./app"-hoz viszonyítva kell e megadni vagy a "dev.js" fájlhoz viszonyítva. Az ilyenek miatt nem vagyok oda azért, hogy kód helyett adatfájlból konfiguráljunk...

Ez a megközelítés szerintem egész jó webalkalmazásokra, viszont ha befordítós nyelvről van szó, és nem fér bele, hogy minden konfig változásnál újra fordítsd a kódot, akkor muszáj kitenni ini vagy json fájlba. Ilyenkor érdemes egy kommentben dokumentált minta fájlt csinálni (azért talán jobb az ini), illetve parancssorból megadni neki, hogy melyik config fájlt használja, pl "app.exe --config=dev.conf.ini", és jobb ha nincs default változata.

A ti megoldásotok miben jobb ennél?
3

A kornyezeti valtozokban az a

MadBence · Feb. 6. (Sze), 10.45
A kornyezeti valtozokban az a jo, hogy univerzalisan mukodnek. Kis tulzassal a bekonfiguralt alkalmazas elinditasa annyi, hogy
$ source .env
$ ./app
(productionben ez nalunk ugy nezett ki, hogy volt egy systemd unit EnvironmentFile direktivaval ellatva, egy masik projectben pedig egy supervisord volt hasonloan folkonfiguralva)

Nem ertem miert erdemes dependency injectiont hasznalni konfiguraciora, az alkalmazas szempontjabol a konfiguracio egy globalis valami, innentol kezdve tenyleg lehet globalis, ez csak kodszervezes kerdese.
4

Nem ertem miert erdemes

inf3rno · Feb. 6. (Sze), 15.31
Nem ertem miert erdemes dependency injectiont hasznalni konfiguraciora, az alkalmazas szempontjabol a konfiguracio egy globalis valami, innentol kezdve tenyleg lehet globalis, ez csak kodszervezes kerdese.


Ugyanaz miatt, ami miatt kódban sem használsz globális változókat. Nehezebben tudod nyomon követni, hogy honnan kapnak értéket és milyen szabályok alapján.

Ha felteszel valami config libet, mint amit a kezdő hozzászólásnál írtam, akkor emlékezni kell rá, hogy milyen belső szabályok alapján működik a lib. Pl hogy először a "./config/default.json"-t rántja be, aztán a "./config/${process.ENV.NODE_ENV}.json"-t, aztán esetleg ezeket felülírhatja a "process.ENV" változókkal vagy sem. Ugyanezt egy sor kódban átlátható módon el tudod intézni, ha flat a config:

var config = Object.assign(
    require("./config/default.json"),
    require(`./config/${process.ENV.NODE_ENV}.json`)
);
Ugyanígy tetszőleges szabályokat megadhatsz, pl hogyha nem "process.ENV"-ből jön a jelszó, akkor hibaüzenetet dobsz. Megadhatsz whitelistet paramétereknek, hogyha typo van, akkor ne induljon el az alkalmazás, hanem dobjon hibát.

A DI előnye, hogy a helyi környezethez tudod igazítani az alkalmazást anélkül, hogy bele kellene nyúlni a kódjába. A hátránya annyi, hogy plusz egy fájlt kell írnod 5 percben minden környezethez, vagy csak simán bemásolsz egy default fájlt, aztán felülírod az értékeket.

Ha van egy jól bejáratott szabályrendszered konfigurálásra, amit ledokumentáltál, akkor az is működhet ugyanolyan jól, ha te mondod meg, hogy milyen környezetben fusson az alkalmazás. Én most egyelőre átállok a config injection-re, nekem sokkal szimpatikusabb.
5

Ugyanaz miatt, ami miatt

MadBence · Feb. 6. (Sze), 17.54
Ugyanaz miatt, ami miatt kódban sem használsz globális változókat. Nehezebben tudod nyomon követni, hogy honnan kapnak értéket és milyen szabályok alapján.


Ez altalaban igaz a globalis valtozokra, de a konfiguraciod alapvetoen fix, nem valtozik, ott kap erteket ahol deklaralva van. Teljesen mindegy hogy egy globalis objektumbol rantod ki az adatbazis jelszot, vagy zsonglorkodsz valami parameterrel.

A DI előnye, hogy a helyi környezethez tudod igazítani az alkalmazást anélkül, hogy bele kellene nyúlni a kódjába.
Szerintem ennek sok koze nincs a DI-hoz, kornyezeti valtozokkal ugyanugy mukodik.

Ha van egy jól bejáratott szabályrendszered konfigurálásra
Nem tudom mi ertelme szabalyrendszereket kitalalni. Ki lehet persze, de ez ne az alkalmazas feladata legyen. Az csak kapja meg keszen a konfiguraciot. A konfiguracio osszeallitasanak feladata (meglepo modon) a konfiguracio menedzsment rendszer feladata kene hogy legyen (ha van szukseg valami ipari megoldasra).
6

Ez altalaban igaz a globalis

inf3rno · Feb. 6. (Sze), 20.38
Ez altalaban igaz a globalis valtozokra, de a konfiguraciod alapvetoen fix, nem valtozik, ott kap erteket ahol deklaralva van. Teljesen mindegy hogy egy globalis objektumbol rantod ki az adatbazis jelszot, vagy zsonglorkodsz valami parameterrel.


Csak akkor fix, ha tolsz egy freezet az egészre miután beállítottad. Egyébként bármikor bele lehet nyúlni. Elég egy félresikerült kódrészlet, ahol ugyanazokat a változó neveket használod, de elfelejted kitenni, hogy "var". Tényleges biztonság ilyen szempontból szerintem csak lokális változókkal van.

Szerintem ennek sok koze nincs a DI-hoz, kornyezeti valtozokkal ugyanugy mukodik.


Én nem veszem ennyire magától értetődőnek, hogy tudom állítani a környezeti változókat. Nekem ez plusz egy külső függőség, ami ha valami miatt megszűnik, akkor rámegy 1 óra, hogy kiderítsem miért nem fut az alkalmazás. Volt már pl htaccess-ben beállított header-ekkel hasonló gondom, ami 1 évig működött, aztán apache verzió váltásnál eltört, és írhattam át a kódot. Körülbelül hasonlóan instabilnak érzem a környezeti változókat is, ha külsős hosting szolgáltatónál fut valami. De elég csak rákeresni, hogy env varibles lost, van néhány találat.

A te esetedben ha gyorsan váltani kell fájlos konfigra, akkor olyankor hozzá kell nyúlni a kódhoz, hogy fájlból szedje, aztán újrafordítani az egészet, ha olyan a nyelv, vagy csak minify-t tolni rá pl js-nél. Ezen kívül csinálhatsz plusz egy git branch-et, aminél fájlból szedi a konfigot ahelyett, hogy környezeti változóból szedné, vagy ha azt nem akarod, akkor kitalálhatsz valamilyen szabályt arra az esetre, ha környezeti változó és konfig fájl is meg van adva, vagy jó esetben ha csak egy helyen fut az alkalmazás, akkor törlöd a régit és teljesen átállsz az újra. A DI-s példámban ezzel szemben ilyen esetben elég csak az indító scriptet átírnom, hogy fájlból szedje a konfigot, vagy ő maga tartalmazza azt változókban. És mivel az indító script nem verziókövetett kód, így ezen kívül nincs is más dolgom. Ha befordított lenne az alkalmazás, akkor bash indító scripttel ugyanígy átadható a konfig.

Nem tudom mi ertelme szabalyrendszereket kitalalni. Ki lehet persze, de ez ne az alkalmazas feladata legyen. Az csak kapja meg keszen a konfiguraciot. A konfiguracio osszeallitasanak feladata (meglepo modon) a konfiguracio menedzsment rendszer feladata kene hogy legyen (ha van szukseg valami ipari megoldasra).


Na legalább ebben egyetértünk, hogy nem az alkalmazás feladata, hogy összeszedje a konfigurációt, hanem készen kell kapnia.
7

Csak akkor fix, ha tolsz egy

MadBence · Feb. 6. (Sze), 23.46
Csak akkor fix, ha tolsz egy freezet az egészre miután beállítottad. Egyébként bármikor bele lehet nyúlni. Elég egy félresikerült kódrészlet, ahol ugyanazokat a változó neveket használod, de elfelejted kitenni, hogy "var".
Globalis valtozo alatt termeszetesen nem a JS ertelemben vett globalis valtozora gondolok, hanem pl:
import config from './config';

function app() {
  // ...
}

app()
a config.js tartalma pedig ilyesmi:
export default {
  db: {
    user: process.env.DB_USER,
    pass: process.env.DB_PASS,
  },
};
Lenyegtelen, hogy az app parameterben kapja-e meg a konfiguraciot, vagy beimportalja. A te dev.js-es megoldasod is ugyanugy "globalis" valtozokat hasznal, csak az alkalmazas futtatasahoz pluszban szukseged van egy nem verziokezelt plusz fajlra (dev.js, production.js, stb).

Tényleges biztonság ilyen szempontból szerintem csak lokális változókkal van.
A parameterben kapott konfigot ugyanugy modositani tudod, mint egy globalis valtozot :).

Én nem veszem ennyire magától értetődőnek, hogy tudom állítani a környezeti változókat.
Erdemes utanajarni, mert nyelv es operacios rendszer fuggetlen fogalom, igy tulajdonkeppen barmilyen projectben hasznos lehet.

Körülbelül hasonlóan instabilnak érzem a környezeti változókat is, ha külsős hosting szolgáltatónál fut valami.
Nem tudom mit ertesz pontosan "kulso hosting szolgaltato" alatt, illetve miert "instabilak" ezek a kornyezeti valtozok.

A te esetedben ha gyorsan váltani kell fájlos konfigra, akkor olyankor hozzá kell nyúlni a kódhoz
Ahogy a te esetedben is, viszont nalam a konfiguracios modul is verziokovetve van, ami mondjuk nem hatrany ha az ember szeretne pl. visszaallni egy korabbi verziora.

A DI-s példámban ezzel szemben ilyen esetben elég csak az indító scriptet átírnom
Nalam pedig eleg a config.js-t atirnom, hogy mostantol ne az legyen az adatbazis jelszo, hogy process.env.DB_PASS, hanem fs.readFileSync('/run/secrets/DB_PASS').
8

Globalis valtozo alatt

inf3rno · Feb. 7. (Cs), 01.18
Globalis valtozo alatt termeszetesen nem a JS ertelemben vett globalis valtozora gondolok, hanem pl:


Ha így vesszük, akkor véletlenül elég nehéz megváltoztatni. Levédeni egyébként le lehet a tiédet is, csak egy deepFreeze-t kell rá tolni mielőtt exportálod. https://github.com/substack/deep-freeze Ugyanúgy, ahogy az enyémre is rá lehet tolni mielőtt átadom. A másik lehetőség, hogy miután elkészült berakod valami proxyba, ami csak olvasni engedi.

Ahogy a te esetedben is, viszont nalam a konfiguracios modul is verziokovetve van, ami mondjuk nem hatrany ha az ember szeretne pl. visszaallni egy korabbi verziora.


Nalam pedig eleg a config.js-t atirnom, hogy mostantol ne az legyen az adatbazis jelszo, hogy process.env.DB_PASS, hanem fs.readFileSync('/run/secrets/DB_PASS').


Rendben, csináljunk egy visszaállítást. Az adatbázis jelszó a "/run/secrets/DB_PASS"-ben van, visszaállunk az előző verzióra és a "process.env.DB_PASS"-ből szedjük. Hoppá, nincs hozzáférés az adatbázishoz...

A konfiguráció nem az alkalmazás része, az az éppen futó példányhoz tartozik, emiatt nem jó a kóddal együtt verziókövetni. Ahány példány fut, annyi féle szabályt tudsz hozni, hogy honnan szedje a konfigot, ezért ha a verziókövetett kódban rántod be, akkor mindegyik megoldást ott kell támogatni. Aztán hozhatsz prioritási sorrendet és külön szabályokat tök feleslegesen arra, hogy mi az elsődleges adatforrása a konfignak.

A te "config.js"-es példád csak azért nem törik el, mert minden értéket környezeti változókból szed, amiket kívülről állítasz át, és mert minden környezetben hozzáférsz a környezeti változókhoz. Ha a kettő közül bármelyik megváltozna valami miatt, akkor azonnal eltörne. Pl ha a dev gépen fájlból akarnád szedni a konfigot, a production server-en meg process.ENV-ből, akkor kénytelen lennél a config modulban mindkettőt támogatni. A másik megoldás, hogy csinálsz 2 branch-et, és egyikben az process.ENV-et támogatod, a másikban meg a fájlokat. Nekem egyik sem szimpatikus. Az egyedüli megoldás, ha leszeded a verziókövetést a config modulról, ami szinte ugyanaz, mint amit én csinálok. Az én változatomnak még van annyi előnye, hogy környezettől függően tudok polyfill-eket betölteni mielőtt betölteném és elindítanám az alkalmazást. Ha a szerver oldali kódból bundle-t csinálsz és aláírod, akkor a konfigot (vagy annak betöltési módját) nem teszi bele a bundle-be, plusz tudom ellenőrizni, hogy nem e nyúlt bele egy hacker út közben. Nyilván ezek mellett van annyi hátránya, hogy a konfig struktúra nem verziókövetett, és ha az változik, pl egy visszaállításnál, akkor nem fog tudni elindulni az alkalmazás az új konfig struktúrával. Valamennyire ez is verziókövethető hasonlóan az adatbázis struktúrához, de elég macerás, és szerintem nem éri meg. Egyszerűbb inkább hibát dobni, ha nem stimmel az átadott konfig struktúra, aztán a hibaüzenetből úgyis látja az ember, hogy mi a gond, és tudja orvosolni. Úgy látszik mindennek van Achilles sarka. :-)

Nem tudom mit ertesz pontosan "kulso hosting szolgaltato" alatt, illetve miert "instabilak" ezek a kornyezeti valtozok.


A konkrét példa header változásra a Godaddy-ből volt. Azt értem alatta, hogy nem saját szerveren megy a dolog, hanem tárhely szolgáltatójén.

Szerintem azért instabilak, mert nincsen minden oprendszeren stabilan megvalósítva a dolog. Csak gyorsan kerestem, de nem is igazán találtam oprendszer független szabványt arra, hogy hogyan kell kinéznie. Amúgy nem véletlen linkeltem a google találatokat, csak nézd meg hányan szívnak a beállításukkal, főleg Windows rendszereken, IDE-kben, Docker Container-ben, és hányan pl a CLI paraméterezéssel vagy JSON fájlok betöltésével. Azért elég nagy a különbség. A .env fájl, amit használsz még szerintem a legjobb megoldás az összes közül, mert helyben van, és nem az oprendszerben kell állítgatni.
9

Rendben, csináljunk egy

MadBence · Feb. 7. (Cs), 10.33
Rendben, csináljunk egy visszaállítást. Az adatbázis jelszó a "/run/secrets/DB_PASS"-ben van, visszaállunk az előző verzióra és a "process.env.DB_PASS"-ből szedjük. Hoppá, nincs hozzáférés az adatbázishoz...
Nyilvan ha az infrastruktura valtozik, akkor az infrastrukturat is rollbackelni kell.
A konfiguráció nem az alkalmazás része, az az éppen futó példányhoz tartozik, emiatt nem jó a kóddal együtt verziókövetni.
Ez az en megoldasomban sincs igy, a konfiguracio teljesen elkulonul az alkalmazastol. A config.js csak egy adapter, ami a rendelkezesre allo kulso konfiguraciot olyan formara hozza, amit az alkalmazas mar fogyasztani tud egy egyseges interfeszen keresztul.
Pl ha a dev gépen fájlból akarnád szedni a konfigot, a production server-en meg process.ENV-ből, akkor kénytelen lennél a config modulban mindkettőt támogatni.
Ezt mondjuk pont nem akarnam sose (legyen minel kevesebb kulonbseg a dev es prod kornyezet kozott), de ebben az esetben csak bele kell nyulni a config.js-be (nalad szinten bele kell nyulni egy nem verziokovetett, tehat senki altal nem ismert fajlba).
Az én változatomnak még van annyi előnye, hogy környezettől függően tudok polyfill-eket betölteni mielőtt betölteném és elindítanám az alkalmazást.
Ezt szinten nem ertem, ha pl egy node-os alkalmazasrol beszelunk, akkor csak a megfelelo kapcsoloval kell elinditani a folyamatot (-r polyfill), nem erzem a kulonbseget a ket megoldas kozott.
... szerver oldali kódból bundle-t csinálsz ... tudom ellenőrizni, hogy nem e nyúlt bele egy hacker ...
Szerintem ott eleg nagy gondok vannak, ha attol tartasz, hogy valaki a szerver oldali kododba nyult bele. Egyebkent nem ertem mi az elonye annak, ha a kodban nincs benne, hogy hogyan allitod elo a konfiguraciot. Szerintem ez pont hatrany.
Szerintem azért instabilak, mert nincsen minden oprendszeren stabilan megvalósítva a dolog.
Tovabbra sem tudom dekodolni mit jelent a stabil es instabil szo ebben a kontextusban. A process.env valtozo platformfuggetlen modon tartalmazza a kornyezeti valtozokat. Ha beallitani szeretned oket, akkor ott van a platform-fuggetlen cross-env, vagy a szinten platform-fuggetlen dotenv.
10

senki altal nem ismert

inf3rno · Feb. 7. (Cs), 12.26
senki altal nem ismert fajlba


Ezt kifejtenéd? Ha ledokumentálom, hogy milyennek kell lennie, vagy adok egy példa fájlt minden verzióhoz, vagy esetleg csinálok egy Config osztályt, ami ellenőrzi a struktúráját, akkor melyik része nem ismert?

Ezt szinten nem ertem, ha pl egy node-os alkalmazasrol beszelunk, akkor csak a megfelelo kapcsoloval kell elinditani a folyamatot (-r polyfill), nem erzem a kulonbseget a ket megoldas kozott.


Nem tudtam, hogy ilyen létezik. Mindig hiányoltam.

Szerintem ott eleg nagy gondok vannak, ha attol tartasz, hogy valaki a szerver oldali kododba nyult bele.


Nem tartok tőle, ez is csak egy plusz lehetőség.

Egyebkent nem ertem mi az elonye annak, ha a kodban nincs benne, hogy hogyan allitod elo a konfiguraciot. Szerintem ez pont hatrany.


Továbbra is annyi az előnye, hogy tetszőleges módon előállíthatod, és nem az alkalmazás készítőjének kell foglalkoznia vele, hanem annak, aki el akarja indítani, és aki ismeri az adott környezetet, amiben futtatni akarja. Ami ezzel a megközelítéssel egyenértékű az egyedül a Docker container használata.

Tovabbra sem tudom dekodolni mit jelent a stabil es instabil szo ebben a kontextusban. A process.env valtozo platformfuggetlen modon tartalmazza a kornyezeti valtozokat. Ha beallitani szeretned oket, akkor ott van a platform-fuggetlen cross-env, vagy a szinten platform-fuggetlen dotenv.


Akkor a megbízhatatlan szó talán jobban értelmezhető. Pl az SSH kitörli őket, sok IDE terminal szintén kitörli őket, ha onnan akarod indítani az alkalmazásod, van olyan IDE, ami bugos, és nem menti el őket két indítás között, ha megadod a GUI-n a projekthez. Általában jellemző, hogyha nem sikerül berántani őket valahol, akkor azt írják, hogy this is an expected (security) feature. Általában viszont ezek nincsenek ledokumentálva, vagy külön rá kell keresni mielőtt próbálkoznál bármivel, mert közel sem evidens. Pl Docker esetében sem mindenkinek egyértelmű, hogy mit fog betölteni és mit nem. link link link Ez mind külön extra szívás, és eltöltött plusz órák, ha belefutsz. Gondolom már végigmentél ezeken, aztán megvan a bejáratott módszered, ami mindig működik. Ami leginkább zavar, hogy nem látom ezeket a környezeti változókat, hogy átadásra kerülnek, hanem feltételezem, hogy ott vannak. Ellenőrizni csak úgy tudom, ha írok egy külön teszt fájlt, ami listázza őket, és akkor látom, hogy tényleg rendben vannak. Esetleg akkor beleírom a kódba, hogy `if (process.ENV.hasOwnProperty("password"))`, aztán ha nincs, akkor kivételt dobok és nem indul el az alkalmazás. Ezen felül 1-2 évvel ezelőttig kisebb biztonsági rés volt a Unix rendszereken, hogy listázni lehetett ps-el minden process környezeti változóját, szemben mondjuk az fájlokkal, amiket ACL véd. Mondjuk ha már ps-t tudnak tolni a szerveren, akkor veszett ügy az egész. Egyébként miért rántanék be egy teljes library-t, amikor simán át tudom adni a konfigot paraméterként mindenféle külső függőség nélkül is?
11

Ezt kifejtenéd? Ha

MadBence · Feb. 7. (Cs), 13.27
Ezt kifejtenéd? Ha ledokumentálom, hogy milyennek kell lennie, vagy adok egy példa fájlt minden verzióhoz, vagy esetleg csinálok egy Config osztályt, ami ellenőrzi a struktúráját, akkor melyik része nem ismert?
Van egy olyan erzesem, hogy elbeszelunk egymas mellett. Te ugyanugy egy konfig fajlt irsz, mint en a .env-es peldamban, csak a .env-et konnyebb legeneralni (nem azt mondom, hogy ez a te esetedben lehetetlen).
Nem tartok tőle, ez is csak egy plusz lehetőség.
Ha nem tartasz tole, miert akarsz ra felkeszulni? Vannak dolgok, amiket alapvetoen elfogadunk, mint pl az, hogy a szerverhez illetekteleneknek nincs hozzaferese. Ha van, akkor ott joval nagyobb bajok vannak, nem az fog erdekelni hogy ki mit valtoztatott meg egy konfig fajlban.
Továbbra is annyi az előnye, hogy tetszőleges módon előállíthatod, és nem az alkalmazás készítőjének kell foglalkoznia vele
A kornyezeti valtozokat szinten tetszoleges modon allithatod elo. Mindket esetben ugyanarrol van szo, csak az en esetemben a konfiguracio kod szinten egy globalis process.env valtozobol jon, a te esetedben pedig egy config parameterbol. Egyik esetben sem kell foglalkozni vele, hogy ez a ket valtozo hogyan kap erteket.
Akkor a megbízhatatlan szó talán jobban értelmezhető. Pl az SSH kitörli őket, sok IDE terminal szintén kitörli őket, ha onnan akarod indítani az alkalmazásod, van olyan IDE, ami bugos, és nem menti el őket két indítás között, ha megadod a GUI-n a projekthez.
A megbizhatatlan ezek alapjan nekem azt jelenti, hogy nem ismered ezeket az eszkozoket elegge magabiztosan ahhoz, hogy hasznald oket production kornyezetben. Ez teljesen rendben van, nyilvan vannak alternativ megoldasok is, hasznald oket nyugodtan ha neked jobban kezre all. Persze erdemes figyelni arra, hogy a kodon dolgozo masik 50 fejleszto is hasonlo velemenyen legyen.
Docker esetében sem mindenkinek egyértelmű, hogy mit fog betölteni és mit nem. link link link
A felhozott peldak mindegyike tok egyertelmu (szamomra), illetve aki production kornyezetben uzemeltet dockert, annak ezeket illene ismernie.
Egyébként miért rántanék be egy teljes library-t, amikor simán át tudom adni a konfigot paraméterként mindenféle külső függőség nélkül is?
A kerdes jogos, en sem hasznalnek erre kulso libraryt, hiszen mind a Docker, mind szamos kornyezet (systemd, supervisord, stb) tamogatja ezek beallitasat.
12

Ha nem tartasz tole, miert

inf3rno · Feb. 7. (Cs), 13.57
Ha nem tartasz tole, miert akarsz ra felkeszulni? Vannak dolgok, amiket alapvetoen elfogadunk, mint pl az, hogy a szerverhez illetekteleneknek nincs hozzaferese. Ha van, akkor ott joval nagyobb bajok vannak, nem az fog erdekelni hogy ki mit valtoztatott meg egy konfig fajlban.


Ki beszélt itt szerver hozzáférésről? MITM-el azt tesznek bele a kódba, amit akarnak. Egy digitális aláírás meg véd az ilyesmi ellen. Pl sok gagyi tárhelyen csak FTP van. Azoknál kifejezetten hasznos összecsomagolni és aláírni a kódot és betöltés előtt indító scripttel ellenőrizni az aláírást. Nyilván jobb elmenni egy ilyen tárhelyről, ha van lehetőséged.

A megbizhatatlan ezek alapjan nekem azt jelenti, hogy nem ismered ezeket az eszkozoket elegge magabiztosan ahhoz, hogy hasznald oket production kornyezetben. Ez teljesen rendben van, nyilvan vannak alternativ megoldasok is, hasznald oket nyugodtan ha neked jobban kezre all. Persze erdemes figyelni arra, hogy a kodon dolgozo masik 50 fejleszto is hasonlo velemenyen legyen.


Én úgy vagyok vele, hogyha nem muszáj, akkor nem teszek bele feleslegesen energiát, amikor van egyszerűbb és rugalmasabb megoldás is zéró energia befektetéssel. Egyébként ha a csapat megkívánja, akkor szívesen használok .env fájlokat, vagy bármi egyebet, saját projektnél viszont nem látom semmi előnyét a már leírtak miatt.

A felhozott peldak mindegyike tok egyertelmu (szamomra), illetve aki production kornyezetben uzemeltet dockert, annak ezeket illene ismernie.


Hát könnyen előfordulhat, hogy az 50 fős csapatodból 2-3 embernek van hozzáférése a production szerverhez, a többiek meg szívnak mire be tudják állítani a környezeti változókat a fejlesztői környezetben, IDE-ben, stb, ha nincs nagy tapasztalatuk vele...

Van egy olyan erzesem, hogy elbeszelunk egymas mellett. Te ugyanugy egy konfig fajlt irsz, mint en a .env-es peldamban, csak a .env-et konnyebb legeneralni (nem azt mondom, hogy ez a te esetedben lehetetlen).


Egy kicsit igen, de ennyi belefér. Mindkettő működőképes megoldás. Nekem az egyik szimpatikusabb, neked meg a másik.