Cache – clean přestane fungovat po deployi
- hlupec
- Backer | 10
Ahoj,
používam pro ukládání výsledků z databáze Cache + FileStorage + SQLiteJournal (verze nette 3.1). Téměř vždy mi po deployi přestane fungovat číštění cache metodou clean (pomocí tagů).
Snažila jsem se to trochu prozkoumat a myslím, že je to tímto:
Po deployi (používám ftp-deploy) se maže temp/cache a to takovým stylem,
že se smažou nejprve všechny soubory obsahujicí cachovaná data a až
nakonec se vymaže soubor journal.s3db. Když během toho mazání někdo
přijde na web (což se stane skoro vždy), vytvoří se už nový soubor
s cachovanými daty … následně se teprve domaže soubor journal.s3db. To
pak znamená, že data jsou cachovaná, ale nemají záznam v journal. Když se
má cache pak vymazat, koukne se do journal, ale tam nic není a tak se nic
nemaže. Soubor s daty ale existuje, takže se stále berou ta stará
cachovaná data.
Tak snad jsem to vysvětlila srozumitelně:) Co s tím? Napadá mě akorát pohrát si s pořadím mazání při deployi, ale říkám si, že by se s tím možná mohlo nette vypořádat i nějak samo od sebe :) Nebo mi něco uniká?
- Dan Hundrt
- Člen | 77
Nastavil bych nejdříve maintenance mode, poté smazal temp/cache, poté vytvořil a vypnul maintenance. Nette už nepoužíváme (přechod na Laravel, tam je to snažší), ale měli jsme:
mv www/_maintenance.php www/maintenance.php
composer install
rm -rf temp
mkdir -p temp
chmod -R 777 temp
chown -R www-data:www-data temp
mv www/maintenance.php www/_maintenance.php
Ty práva jsou důležitá.
V Laravelu:
php artisan down
php artisan migrate
php artisan config:clear
php artisan route:clear
php artisan view:clear
php artisan cache:clear
php artisan up
- Marek Bartoš
- Nette Blogger | 1321
Úplně ideální je dělat deploy do nové složky a přepínat přes symlink cestu do veřejné složky a složkám s daty. Při vysoké zátěži může pořád vzniknout cache ve skriptech, které se spustily už před spuštěním maintenance módu, stejně tak skripty spuštěné z konzole pokud se na ni maintenance nevztahuje. V závislosti na nastavení může zlobit i opcache, nejen cache aplikace.
Při nutnosti dělat deploy přes ftp bude ale nejspíš první krok změnit hosting na nějaký použitelný. (Pro CZ/SK prostředí třeba Váš Hosting)
- Dan Hundrt
- Člen | 77
Zlatej Laravel … :-)
Ten při maintenance zastaví crony + joby a následně je spustí při sestup na up.
Editoval Dan Hundrt (15. 1. 2:03)
- Infanticide0
- Člen | 122
Chápeme, máš rád Laragej. Tak proč nejdeš lidem na jejich fórum radit, jak správně volat globální objekty?
Deployment si může každej nastavit svůj, asi neexistuje jedno řešení,
který by vyhovovalo úplně všem.
Já třeba používám Deployer.
Ty artisan deploy commandy uděláš s bin/console, ale přes Deployer je vůbec nepotřebuješ, funguje přesně tak, jak popisuje Marek Bartoš.
- Kalfi
- Člen | 17
Infanticide0 napsal(a):
Chápeme, máš rád Laragej. Tak proč nejdeš lidem na jejich fórum radit, jak správně volat globální objekty?
Deployment si může každej nastavit svůj, asi neexistuje jedno řešení, který by vyhovovalo úplně všem.
Já třeba používám Deployer.Ty artisan deploy commandy uděláš s bin/console, ale přes Deployer je vůbec nepotřebuješ, funguje přesně tak, jak popisuje Marek Bartoš.
Trochu mimo téma, ale Laragej mě po ránu rozsekal :-D , díky.
- Kamil Valenta
- Člen | 849
Infanticide0 napsal(a):
Já třeba používám Deployer.
To je zajímavý projekt. Zaujala mne poznámka „Zero down time“. My používáme vlastní deploy, ale na nulový down time se nedostaneme. I když jdeš cestou symlinků, často je potřeba synchronizovat více nodů, vykonat db migrace… Kdyby nic jiného, tak během db migrace by služba dostupná být neměla. Nebo Deployer vsází na to, že se nikdo netrefí do dotazu, jehož struktura se změnila?