config.local.neon a zrušení sekcí v config.neon

Upozornění: Tohle vlákno je hodně staré.
Filip Procházka
Moderator | 4693
+
0
-

Situace

config.local.neon je super – člověk si do něj může dát lokální hesla. Ale tohle se mi nějak nezdá.

Například teď vyvíjím službu, která používá QR kódy. Na localhostu mám třídu, která použije aplikaci qrencode přes konzoli a na produkci chci mít službu, která zavolá vzdáleně můj server, aby jí vygeneroval ten QR kód. Prostě mi sekce dávají smysl, nejenom na změnu hesla.

Jak podle mého vypadá ideální proces:

  • Mám v app/config různé soubory config.dev.neon pro localhost, config.prod.neon pro produkci, config.testing.neon pro testovací prostředí a třeba ještě config.demo.neon (abych mohl například místo reálných platebních brán nastavit sandboxy). A samozřejmě hlavní config.neon, ve kterém by byly definice společných služeb (zástupce sekce common).
  • Podle proměnné prostředí $_ENV['app.environment'] vyberu vhodný config. Pokud není nastaven, tak fallback na autodetekci – localhost → dev, public → prod.
  • Nikde žádné sekce.

Co mi na tomhle vadí tak hesla v repozitáři. Ach ta paranoia :)

  • Aplikace by měla obsahovat volitelně ještě app/config/config.local.neon, ve kterém může mít vývojář hesla pro svoji dev mašinu.
  • Aplikace by měla umět detekovat parametry z globální proměnné $_ENV. Například $_ENV['database.default.password'], $_ENV['database.default.host'], …

Každý ale nemá takové možnosti (vlastní VPS, server, …) a nejspíš ani potřeby.

Diskuze

Já si to samozřejmě upravím tak, aby mi to vyhovovalo, s tím nemám problém. Ale zajímají mě 2 věci:

  • Otázka pro Davida: zůstane tenhle fallback v Nette, nebo chceš někdy v budoucnu sekce rušit úplně? Jaký je tedy best-practise pro běžné uživatele? Jinými slovy – co radit začátečníkům? Imho je config.local.neon bude mást a pro 99% začátečníků je jednodušší prostě „naprasit“ konfiguraci do jednoho souboru i s hesly do různých sekcí.
  • Otázka pro ostatní: Máte automatizovaný deploy? Jak řešíte deploy konfigurace? Řešíte nějak hesla v repozitáři? A co fáze vývoje? Už to tu dlouho nebylo, tak pojďme flamovat :)
hrach
Člen | 1818
+
+1
-

Signály.cz

  • config.developer.neon – každá mašina, instance aplikace, atp. má tento konfigurák, je tam prevazne heslo k db, pripadne jine API klice, je bez sekci
  • config.neon – je konfigurak se sekcemi, ktere vypadaji nejak nasledovne:
common:
	services:
		authenticator: CommunitySystem\AuthHandler
	...
production < common:
	gopay:
		imagePath : //static.signaly.cz/assets/images/gopay
		testMode  : off
	...
beta < production:
	gopay:
		imagePath : //static-beta.signaly.cz/assets/images/gopay
	...
test < production:
	gopay:
		imagePath : //static-test.signaly.cz/assets/images/gopay
		testMode  : on
	...
development < common:
	gopay:
		imagePath : %baseUri%assets/images/gopay
		testMode  : on
	...

A teď to nejdůležitější, jak to načítáme.

$debugMode = tajna magie na detekci, jestli se ma zapnout debugovaci rezim;
$testMode  = tajna magie na detekci, jestli uzivatel ma povoleno pristoupit na testovaci subdomeny;

if (!$configurator->isDebugMode()) {
	if (($debugMode || $testMode) && Nette\Utils\Strings::endsWith($_SERVER['SERVER_NAME'], 'test.signaly.cz')) {
			$environment = 'test';

	} elseif (($debugMode || $testMode) && Nette\Utils\Strings::endsWith($_SERVER['SERVER_NAME'], 'beta.signaly.cz')) {
			$environment = 'beta';

	} else {
			$environment = 'production';

	}
	$configurator->setDebugMode($debugMode);

} else {
	$environment = 'development';

}

$configurator->addConfig(APP_DIR . '/config/config.neon', $environment);
$configurator->addConfig(APP_DIR . '/config/config.developer.neon', false);

Pokud někoho zaujalo využítí basePath v konfiguraku, pak mame ohackovano takto (je to z duvodu, ze nekteri vyvojari pouzivaji virtual host, jini jen localhost):

$baseUri = trim(dirname($_SERVER['SCRIPT_NAME']), '\\/');
$baseUri = (empty($baseUri) ? '/' : "/$baseUri/");

$configurator = new Nette\Config\Configurator;
$configurator->addParameters(array(
	'baseUri' => $baseUri, // hack for local assets urls
));
Patrik Votoček
Člen | 2248
+
0
-

Konfiguraci (zcela) bez sekcí používám už ani nevím jak dlouho a nenarazil jsem na potřebu cokoli měnit.

HosipLan napsal(a):

  • Otázka pro ostatní: Máte automatizovaný deploy? Jak řešíte deploy konfigurace? Řešíte nějak hesla v repozitáři? A co fáze vývoje? Už to tu dlouho nebylo, tak pojďme flamovat :)

Jelikož máme v podstatě 2 aplikace které běží ve více instancích. Tak máme pro každé prostředí každé této aplikace připravenou šablonu configu. Ze které deployment vygeneruje configurák právě pro to dané prostředí a aplikaci.

To mimo jiné znamená že aplikace vůbec neřeší to v kolika a jakých prostředích běží (a s jakými nastaveními). Řeší to za ní deployment.

Filip Procházka
Moderator | 4693
+
0
-

Patrik Votoček napsal(a):

Jelikož máme v podstatě 2 aplikace které běží ve více instancích. Tak máme pro každé prostředí každé této aplikace připravenou šablonu configu. Ze které deployment vygeneruje configurák právě pro to dané prostředí a aplikaci.

Capistano?

pekelnik
Člen | 468
+
0
-

Pouzivam dva konfiguraky:

  • app.neon
  • local.neon

s tim, ze local.neon je v .gitignore a je includovany do app.neon a je vytvoren deploy scriptem ze sablony tak jak pise Vrtak.

Sekce jsem prestal pouzivat ihned jak to bylo mozne!

Snazim se udrzovat konfiguraci minimalistickou a v duchu principu Convention over configuration. Vsechna nastaveni maji sve vychozi hodnoty nastavene v rozsireni compileru. Takze v app.neon je zpravidla pouze nekolik aplikacnich servis a v local.neon jsou opravdu jenom hesla a nejaka ta cesta.

Pokud by se sekce skutecne zrusily vubec by mne to nevadilo.

Co se tyce ruznych $_ENV a app.environmentu nijak bych to asi nevyuzil.

Honza Marek
Člen | 1674
+
0
-

Možnost načítání více konfiguračních souborů je zcela ekvivalentní co do schopností sekcím. Teoreticky je možné načíst soubor config.beta.yml, ale v praxi je jeden config.neon a jeden config.local.yml zcela dostačující (pozměněné nastavení leží jen tam, kde je potřeba). Pro usnadnění instalace se dá připravit verzovaný soubor config.local.template.neon, kde jsou připravené obvyklé lokální konfigurace na přepsání, odkomentování a podobně.

Výhody zrušení sekcí:

  • zruší se celý koncept různých běhových prostředí a Nette tak může být jednodušší na naučení
  • pokud mi stačí jedna sekce, tak si ji nemusím vymýšlet
  • konfiguráky jsou jednodušší, protože není nutné shraňovat veškeré konfigurace na jednom místě (u signálů.cz by tedy celá ta zdánlivě nepostradatelná hrůza zmizela a šla by nahradit jedním config.local.neonem na každé instalaci)
hrach
Člen | 1818
+
0
-

Signaly maji dva druhy lokalnich konfiguraci. Jednu xasr chcemem verzovat, druhou nikoliv. Dale je pro pochopeni logiky jednodussi dedit, nez skladat nejakou divokou kompozici vice souboru. Netvrdim ze by to neslo, ale je to takto urcite jednodussi.

Stejne tak mi prijdou sekce jednodussi pro maly webik. Opravdu mi u nej navadi verzovane heslo, kdyz si to delam jen sam na svem hostingu, nrjake generovani apod. je overhead.

Chapu, ze mnohdy jsou sekce zbytecne, sam jsem vymyslela navrhl tu syntax aktualniho pridavani konfiguraku,nale myslim ze aktualni stav neni nic proti nicemu. Zaroven vsak nic nebrani tomu, aby sandbox byl odpovedne napsan.

nanuqcz
Člen | 824
+
0
-

Omlouvám se, ale nějak mi to nedochází… Chápu to správně, že místo sekcí budu mít dva neon soubory (na localu), ale na server nahraju pouze jeden? A co pak s řádkem

$configurator->addConfig(__DIR__ . '/config/config.local.neon');

? To před každým uploadnutím bootstrap.php z něho budu muset tento řádek smazat (aby mi to jelo na serveru) a následně na localu zase přidat (aby mi to jelo na localhostu)?

Vojtěch Dobeš
Člen | 1318
+
0
-

Nene, všude bude config.local.neon. Jen jeden nebude v repozitáři (aby jeho úpravy nekomplikovaly práci s verzovacím systémem).

Filip Procházka
Moderator | 4693
+
0
-
if (file_exists($configFile = __DIR__ . '/config/config.local.neon')) {
	$configurator->addConfig($configFile);
}

;)

nanuqcz
Člen | 824
+
0
-

HosipLan: Ano, přesně tak bych to udělal :-) Nicméně v aktuálním sandboxu je to udělané tak, že se config.local.neon načítá vždy. To je tedy zajištěné někde ve zdrojácích Configuratoru, aby soubor s názvem „config.local.neon“ na serveru nebyl brán v potaz?

Anebo jak je v novém sandboxu (kde nejsou použity sekce) zajištěna možnost různého nastavení na localhostu a na serveru?

hrach
Člen | 1818
+
0
-

Imo je lepsi chyba to, ze se nenasel konfiguracni soubor, nez ze se nepripojilo k db, protoze neni v localnim konfigu definovany user a heslo.

Honza Marek
Člen | 1674
+
0
-

config.local.neon se načítá vždy, protože se počítá s tím, že vždycky bude existovat. V něm budou takové ty věci, které jsou na každé instalaci jiné (třeba připojení k databázi). Že se načte různé nastavení na localhostu a na serveru je zajištěno tak, že obsah souboru config.local.neon je na localhostu a serveru jiný.

bazo
Člen | 625
+
0
-

akoze teraz sa po novom automaticky nacita config.local.neon? to je riadna konina.

to akoze teraz mam aj na ostrom serveri vytvarat config.local.neon, kvoli heslam atd?

co bolo zle na sekciach?

Honza Marek
Člen | 1674
+
0
-

bazo napsal(a):

co bolo zle na sekciach?

Sekce jsou nepohodlný při týmovým vývoji. Buď se musí všichni vývojáři domluvit, že budou mít na localhostu stejná hesla do databáze nebo mít každý vlastní prostředí, které bude sdílet s ostatními v jednom config souboru.

Jan Tvrdík
Nette guru | 2566
+
0
-

Současný stav mi přijde OK. Každý má možnost svobodně se rozhodnout zda sekce používat či ne. To samé platí i pro konfiguraci ve více souborech.

Sekce jsou nepohodlný při týmovým vývoji.

@Honza Marek: To platilo pouze v době, kdy nebylo možné mít konfiguraci ve více souborech.

Filip Procházka
Moderator | 4693
+
0
-

bazo napsal(a):

akoze teraz sa po novom automaticky nacita config.local.neon? to je riadna konina.

NE! Vidíš snad, že by se tady někde načítal automaticky? Je přece explicitně jmenovaný.

bazo
Člen | 625
+
0
-

hosipla tu to vidim:

Honza Marek napsal(a):

config.local.neon se načítá vždy, protože se počítá s tím, že vždycky bude existovat. V něm budou takové ty věci, které jsou na každé instalaci jiné (třeba připojení k databázi). Že se načte různé nastavení na localhostu a na serveru je zajištěno tak, že obsah souboru config.local.neon je na localhostu a serveru jiný.

Honza Marek napsal(a):

bazo napsal(a):

co bolo zle na sekciach?

Sekce jsou nepohodlný při týmovým vývoji. Buď se musí všichni vývojáři domluvit, že budou mít na localhostu stejná hesla do databáze nebo mít každý vlastní prostředí, které bude sdílet s ostatními v jednom config souboru.

ved teraz si moze kazdy tiez nastavit lokalny config, nikto nemusi mat rovnake hesla.

som nejaky zmateny z toho, co sa tu vobec riesi

Filip Procházka
Moderator | 4693
+
0
-

Řeší se best practise a srovnáváme přístupy.

Honza Marek napsal(a):

config.local.neon se načítá vždy, protože se počítá s tím, že vždycky bude existovat.

To je dáno tímto řádkem, žádná další magie v tom není.

Honza Marek
Člen | 1674
+
0
-

HosipLan napsal(a):

To je dáno tímto řádkem, žádná další magie v tom není.

V pořádku, tak to má bejt. Nikde jsem nepsal, že v tom je magie ;)

enumag
Člen | 2129
+
0
-

Osobně si do sandboxu asi dám verzovaný example-config.local.neon a pokud config.local.neon nebude existovat tak hodím výjimku ať zkopíruje a upraví ten example. Jinak by kolegovi nemuselo dojít proč to nefunguje hned po git clone.

Editoval enumag (10. 12. 2012 13:30)

Filip Procházka
Moderator | 4693
+
0
-

Honza Marek napsal(a):

V pořádku, tak to má bejt. Nikde jsem nepsal, že v tom je magie ;)

Zajisté. Já také nepíšu, že je to magie :) Jen jsou tu tací, co si to špatně vyložili.

Elijen
Člen | 172
+
0
-

Já to používám přesně jak popisuješ v sekci „Jak podle mého vypadá ideální proces“.

  • deploy aplikace přes git (zatím ručně)
  • config.local.neon mám v .gitignore (tzn hesla nejsou v repo)
  • deploy lokální konfigurace ručně (osatní je v repo)

Sekce jsem také přestal používat téměř ihned jak to šlo. Nicméně aby to pro mě bylo ideální, musel by deploy jít nějak jednoduše automatizovat.

To generování konfigu deploy scriptem zní hodně zajímavě, mohl byste někdo osvětlit, jak se toho v praxi dosáhne?

Editoval Elijen (10. 12. 2012 14:10)

mkoubik
Generous Backer | 731
+
0
-

Deploy myslíš nasazování na úplně čistej stroj, nebo nasazení aktuálních zdrojáků místo existujících? Ten soubor s heslama totiž stačí vytvořit jen jednou. Pokud používáš např. capistrano, tak to asi bude symlink do adresáře shared/, podobně se to dá vyřešit u jakéhokoliv nástroje.
A pokud jde o jednorázové vytvoření toho souboru při konfiguraci nového serveru, tak to by se mělo řešit v rámci nějaké automatizace infrastruktury (viz), pokud nic takového nepoužíváš a plácáš si to ručně přes ssh, tak prostě ten soubor vytvoříš ručně při instalaci databáze (a nastavení hesla) a pak na něj budeš (už automatizovaně) linkovat.

David Ďurika
Člen | 333
+
0
-

Elijen napsal(a):
To generování konfigu deploy scriptem zní hodně zajímavě, mohl byste někdo osvětlit, jak se toho v praxi dosáhne?

skus sa mrknut na toto snad pomoze

n.u.r.v.
Člen | 467
+
0
-

Ahoj, zajímalo by, kde dělám chybu:

V config.neon mám následující konfigujraci:

#
# SECURITY WARNING: it is CRITICAL that this file & directory are NOT accessible directly via a web browser!
#
# If you don't protect this directory from direct web access, anybody will be able to see your passwords.
# https://nette.org/security-warning
#
common:
	parameters:

	php:
		date.timezone: Europe/Prague
		# zlib.output_compression: yes

	nette:
		application:
			errorPresenter: Error

		database:
			default:
				dsn: 'mysql:host=ip_adresa1;dbname=nazev_database1'
				user: neco
				password: heslo
			druha:
				dsn: 'mysql:host=ip_adresa2;dbname=nazev_database2'
				user: neco2
				password: heslo2
			treti:
				dsn: 'mysql:host=ip_adresa_2;dbname=nazev_database3'
				user: neco3
				password: heslo3

		session:



	services:
		authenticator: Authenticator
		routerFactory: RouterFactory
		router: @routerFactory::createRouter

		firstsignRepository: Todo\FirstsignRepository
		nejakyRepository: Todo\NejakyRepository(@nette.database.druha, @nette.database.treti)
		dalsiRepository: Todo\DalsiRepository
		.....
		.....


	factories:


production < common:

development < common:

A teď jsem chtěl udělat to, aby když bude běžet nette na localhostu/vývoj. režimu, tak aby to tu první DB bralo z config.local.neon, a když běží naostro, tak aby to bralo z config.neon. Ale v obou režimech aby se zbytek konfigurace (druhá a třetí DB a repozistáře) brala z config.neon…
Tak jsem do config.local.neon udělal toto:

common:
	parameters:

	php:
		date.timezone: Europe/Prague
		# zlib.output_compression: yes

	nette:
		database:
			default:
				dsn: 'mysql:host=localhost;dbname=nazev_database_moje'
				user: neco_moje
				password: heslo_moje

Ale tady jsem skončil jak docílit toho aby se první db přepínala?

V bootstrap.php mám toto:

...
$configurator->addConfig(__DIR__ . '/config/config.neon');
$configurator->addConfig(__DIR__ . '/config/config.local.neon', $configurator::NONE); // none section
...

díky za radu kam co dopsat/přenastavit…

enumag
Člen | 2129
+
0
-

@n.u.r.v. Používáš to špatně.

  1. Smaž řádky common:, production < common: a development < common:.
  2. Vše co zbyde posuň o 1 úroveň odsazení doleva.
  3. Konfigurace přistupů k DB nemá být v config.neon vůbec(!).
  4. Vytvoř si config.local.neon, přidej jej do .gitignore aby nebyl verzovaný.
  5. Do něj dej veškeré nastavení specifické pro dané prostředí (localhost) – zpravidla přístupy k db a např. nastavení defaultní cache storage.
  6. Podobně vytvoř druhý config.local.neon úplně stranou, dej do něj nastavení specifická pro produkci (server).
  7. Po deploymentu aplikace tam tenhle druhý config.local.neon nahraj místo původního. Pokud deployment provádíš přes git tak tam ten lokální ani nebude.

EDIT: Raději jsi měl ale založit nové téma.

Editoval enumag (19. 7. 2013 11:52)

enumag
Člen | 2129
+
0
-

Otázka pro všechny: Konstanta $configurator::NONE je @deprecated, znamená to, že v bootstrapu mám to addConfig volat prostě jen takhle?

$configurator->addConfig(__DIR__ . '/config/config.local.neon', FALSE);

Za pár minut nebudu mít tušení co to FALSE vlastně znamená. :-(

n.u.r.v.
Člen | 467
+
0
-

enumag:

  1. Hmm, řídil jsem se podle quickstart a tam je konfigurace DB v config.neon…
  2. no myslel jsem si, že to bude fungovat takto: v config.neon budou věci, které jsou společné a budou se verzovat (například ty repozitáře a DB, které jsou někde mimo localhost (druhá a třetí). Takže když přidám repo, tak se změna díky gitu (u mě konkrétně díky mercurialu) projeví u všech, ale zároveň bude mít každý u sebe ještě config.local.neon, který se nebude verzovat a tam bude nastavení pro konkrétní prostředí…A když bude v nette v režimu vývoj, bude brát první DB z toho configu.local.neon, jinak jí bude brát z config.local…
  3. Chtěl jsem se vyhnout tomu, že budu muset někde měnit soubory…
  4. k čemu je tedy config.neon, když vše doporučuješ dávat do config.local.neon?
  5. k čemu slouží production < common: a development < common? Myslel jsem si, že to bude právě ta možnost pro přepínání produkční a dev verze, tak jsem udělal toto, ale nějak to pořád bere to config.local.neon:

config.neon:

common:
	parameters:

	php:
		date.timezone: Europe/Prague
		# zlib.output_compression: yes

	nette:
		application:
			errorPresenter: Error

		database:
			druha:
				dsn: 'mysql:host=ip_adresa2;dbname=nazev_database2'
				user: neco2
				password: heslo2
			treti:
				dsn: 'mysql:host=ip_adresa3;dbname=nazev_database3'
				user: neco3
				password: heslo3

		session:



	services:
		authenticator: Authenticator
		routerFactory: RouterFactory
		router: @routerFactory::createRouter

		nejakyRepository: Todo\NejakyRepository
		dalsiRepository: Todo\DalsiRepository(@nette.database.druha, @nette.database.treti)
		...
		...


	factories:


production < common:
		nette:
			database:
				default:
					dsn: 'mysql:host=ip_adresa1;dbname=nazev_database1'
					user: neco1
					password: heslo1
development < common:
		includes:
			- config.local.neon

a config.local.neon:

nette:
	database:
		default:
			dsn: 'mysql:host=localhost;dbname=moje_databse'
			user: ja
			password: moje_heslo

Editoval n.u.r.v. (19. 7. 2013 12:18)

enumag
Člen | 2129
+
0
-

Ano, takhle se to dělalo dříve, a ano to procution < common: a development < common: sloužilo ke konfiguraci jednotlivých režimů (production / dev).

Jeden z důvodů proč nyní je doporučený způsob jiný (nikdo ti nebrání používat ten starý) je ten, že přístupy k databázi nemají co dělat ve verzovaném repozitáři aplikace. config.neon slouží pro všechna nastavení aplikace (extensions, služby, parametry, etc.), config.local.neon pouze pro věci specifické pro dané prostředí – což pro většinu lidí znamená pouze přístupy do databáze.

Editoval enumag (19. 7. 2013 12:26)

Zdeno1981
Člen | 98
+
0
-

enumag napsal(a):

Otázka pro všechny: Konstanta $configurator::NONE je @deprecated, znamená to, že v bootstrapu mám to addConfig volat prostě jen takhle?

$configurator->addConfig(__DIR__ . '/config/config.local.neon', FALSE);

Za pár minut nebudu mít tušení co to FALSE vlastně znamená. :-(

Ahoj, co jsem já tak zkoušel 2.1, tak tam žádána konstanta být nemusí, všechny configy mi to vezme bez problému, jelikož tam jsou zrušené sekce. common, production a development.

Co mě tak trožku zaráží, tak mi tam nejde použit sekce include, nebo možná dělám něco špatně.

Etch
Člen | 404
+
0
-

@**Zdeno1981:**

Sekci includes používám v 2.1 celkem běžně.

includes:
	- repositories.neon
enumag
Člen | 2129
+
0
-

@Zdeno1981: To je přesně ono – to include funguje jen když tam dáš to false. :-P

Zdeno1981
Člen | 98
+
0
-

enumag napsal(a):

@Zdeno1981: To je přesně ono – to include funguje jen když tam dáš to false. :-P

aha, :) tak proto mi to nešlo, díky za vysvětlení.

EDIT, tak ale mmt, u starší revize jsem měl problém se sekci include, ale co jsem dnes stahoval nejnovější, tak sekce include funguje i bez konstanty FALSE

Editoval Zdeno1981 (19. 7. 2013 14:03)

n.u.r.v.
Člen | 467
+
0
-

Ano, takhle se to dělalo dříve, a ano to procution < common: a development < common: sloužilo ke > > > > konfiguraci jednotlivých režimů (production / dev).

Jeden z důvodů proč nyní je doporučený způsob jiný (nikdo ti nebrání používat ten starý) je ten, že > > přístupy k databázi nemají co dělat ve verzovaném repozitáři aplikace. config.neon slouží pro všechna > nastavení aplikace (extensions, služby, parametry, etc.), config.local.neon pouze pro věci specifické > pro dané prostředí – což pro většinu lidí znamená pouze přístupy do databáze.

Mno právě že my to tu potřebujem jinak – při vývoji používáme tu první DB každý svou na localhostu (tedy se přizpůsobuje prostředí), ale ty druhé dvě se berou vždy z hostingu a nikdy se nemění a ani nestahují na localhost…

Takže když změníme na hoatingu např. heslo do DB 2/3, tak potřebuji to udělat taky v mé aplikaci, hodit do verzování a ostatní si to stáhnou…

Takže právě bych chtěl použít mnou uvedený způsob, ale jelikož zatím dělám jen na localhostu, tak musím měnit a režim dev/production pomocí

$configurator->setDebugMode(FALSE);

Jenže to nemá jaksi vliv a pořád to includuje ten config.local.neon

Nebo to je tím, že nemám false u tohoto řádku?:

$configurator->addConfig(__DIR__ . '/config/config.neon');

edit: Když tam dám FALSE, tak vyskočí chyba „Found sections ‚common‘, ‚production‘, ‚development‘ in configuration, but corresponding extensions are missing.“

Editoval n.u.r.v. (19. 7. 2013 14:05)

Etch
Člen | 404
+
0
-

@**n.u.r.v.**:

Takže když změníme na hoatingu např. heslo do DB 2/3, tak potřebuji to udělat taky v mé aplikaci, hodit do verzování a ostatní si to stáhnou…

Furt nějak nechápu, proč by tohle mělo být verzované. Zahrnutí hesel k ostré DB na produkci do verzování považuji za něco naprosto nevhodného. Už jen z toho důvodu, že se mi v praxi X krát stalo, že jsme seděli s kolegou v hospodě a kecali o něčem co teď řeší a neví, jak to udělat.

Tak mi zpřístupnil repositář já si to v té hospodě stáhl do notebooku a řešili jsme to. Kdyby tam měl uložené hesla k ostré DB, tak bych se k nim dostal, i když bych je neměl vůbec vědět.

Hesla k db na produkci proste do verzování nepatří.

Šaman
Člen | 2464
+
0
-

V tom případě je potřeba mít verzovanou nějakou šablonu – prázdný, nebo ukázkový config.local.neon
Protože kromě databáze tam může být potřeba nakonfigurovat i jiné specifické služby, které mám na localu jen testovací (mailer, komunikace s externími zdroji, apod).
V ideálním případě kompletně vyplněné pro produkční server a jen prázdná hesla. Jinak je dost problém to deploynout.. (Kde máte vlastně ta hesla uložená? Nebo spoléháte na to, že to pár lidí ví a kdyžtak se jim zavolá?)

enumag
Člen | 2129
+
0
-

@Šaman: Přesně tak.