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

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 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?

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)

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)?

if (file_exists($configFile = __DIR__ . '/config/config.local.neon')) {
	$configurator->addConfig($configFile);
}

;)

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.

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?

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.

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

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 ;)

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.

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.

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/en/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…

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á. :-(

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:**

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

includes:
	- repositories.neon

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.**:

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: Přesně tak.