viac verzii aplikacie nad jednym kodom – struktura
- bazo
- Člen | 620
ahoj,
momentalne riesim nasledujuci problem:
momentalne mame 3 oddelene verzie tej istej aplikacie, pre kazdu podporovanu
krajinu jednu. spravil som jednu verziu ktora zahrna vlastnosti vsetkych
doterajsich verzii.
a teraz potrebujeme tie 3 krajiny a dalsie, ktore pridu obsluhovat
jednym kodom.
Kazda krajina ma vlastny config.neon kde su specificke nastavenia a potom
config.local.neon kde su pripojenia do databazy
kazda krajina ma vlastnu db – z historickych dovodov
pre ostru prevadzku mame domeny konciace na .tld cize .sk, .de, .cz atd
ale na devel serveri mame url sk.domena.eu, cz.domena.eu atd
potom su tu este pocitace vyvojarov kde to moze mat kazdy inak, ja pouzivam
system podobny develu
v root folderi projektu sa nachadza skript cli, ktory obsluhuje konzolove prikazy
a teraz sa konecne dostavam k otazke: ako poriesit adresarovu strukturu tak aby prevadzka a setup boli co najjednoduchsie?
podla mna su dve moznosti:
- nasmerovat kazdu domenu do rovnakeho www adresara – bud si podla nejakych regexov, ktore moc neviem, zistim o aku krajinu ide, alebo vytvorim pre kazdu krajinu zvlast index v tvare index_sk.php, index_cz.php atd, kde budu zadefinovane cesty ku konfigurakom ktore sa maju nacitat
vyhoda je – staci jeden deploy, logy na jednom mieste,
nevyhody – X verzii suboru index_krajina.php ked budeme pokryvat 20 krajin
tak ich tam bude 20, takisto budem musiet mat 20 verzii cli skriptu aby mal
spravne konfiguracne udaje
- deploynut kazdu verziu ako zvlast aplikaciu
vyhoda – ziadne duplikovanie index.php a cli, jednoduchsie nacitanie
konfigu pre krajinu(napriklad podla $ENV)
nevyhoda – X instalacii, X deployov, logy na X miestach, mozem zabudnut
pushnut hotfix do 1 z X verzii, zaberie to X krat viac miesta na serveri
ako riesite taketo situacie vy? existuju aj ine riesenia?
vopred dakujem za odpoved
Editoval bazo (21. 10. 2014 10:57)
- Tomáš Votruba
- Moderator | 1114
@bazo Máme stejnou situaci. Detekci webu řešíme přes hostResolver, který matchne doménu.
Ad CLI, jak píše @newPope, určit web pomocí parametru.
Nejlépe přes vlastní application, která přidá parametr --host
ke všem příkazům, jako composer.
- Eda
- Backer | 220
Taky mám více webů nad jedním kódem a řešil jsem úplně stejný problém. Nakonec jsem to vyřešil WebResolverem (zřejmě Tomáš má něco podobného, akorát tomu říká jinak).
U mě je to služba, kterou mám registrovanou v DIC a třeba rozdílné
databáze pro rozdílné weby řeším tak, že mám vlastní ConnectionFactory,
která vyžaduje WebResolver, ze kterého se dozví, na jakém webu jsme a podle
toho nastaví připojení. Takto to dělají i jiné služby, které jsou
nějak závislé na webu. Jen si prostě vyžádají WebResolver, zavolají
getWeb()
a je to.
- Tomáš Votruba
- Moderator | 1114
@akadlec @bazo Zjednodušeně jak to napsal @Eda.
$host = $this->httpRequest->getUrl()->getHost()
$website = $websiteDao->fetchOneBy(['host' => $host]);
Issues, které jsem řešil:
- Entity manager předávám setterem v DI, jelikož je někdy potřeboval jak hostResolver, tak entity manager, a to způsobuje circular reference.
- Pro fčnsot v CLI se v DI nastavuje fallback při absenci
getHost()
, tedy:
$builder->addDefinition($this->prefix('hostResolver'))
->setClasss('Phc\Application\HostResolver')
->addSetup('$consoleHost', [$builder->parameters['host']]);
Editoval Tomáš Votruba (24. 10. 2014 9:15)
- Tomáš Votruba
- Moderator | 1114
@bazo To už je otázka preferencí.
@akadlec Zatím používáme 1 databázi s příznakem
website_id
. Zkusil bych řešení, co popisuje @eda