Drupal user
Fórum
Drupal version

Zdravím,

neměl by Maintenance Mode řešit i stav, kdy jsou (při update jádra např.) zrovna mazány soubory Drupalu či nahrávány nové?

(tj. Drupal v tu chvíli není schopen najet ani částečně a tedy ani si vytáhnout z DB text "Maintenance Mode Message"(Zpráva režimu údržby) určený pro zobrazení na stránce informující o probíhající údržbě)

 

Nebo jak to řešíte vy? Nahrajete na web nějaký svůj index.html?

Ahoj dříve jsem to řešil stejně, jistota, že tam bude pořád na co koukat :-) Teď to řeším tak, že mam mirror ten aktualizuji pak na něj nasměruji DNS, obnoveni DNSka je poměrně rychle, záleží jak to kdo má nastaveny...nikdo nic nepozna

Ahoj marinex,

dík moc za reakci.

1) chápu, že se DNS zrychlily z dřívějších 24 hodin, ale nemám s tím aktuálně nyní zkušenosti. O kolik se běžně dnes liší časově dva uživatelé, když jednomu se to DNS zaktualizuje hodně rychle a druhému hodně pomalu?

Nebudu mít pak reakci od prvního na novém webu a od druhého na starém?

2) používám share hosting (např. u gigaserveru mám nějaký extra tarif, cca 10gb) - to bys dělal tedy jak? Platit si dva stejné tarify?

 

A takže to tedy Drupal neřeší? (ani třeba v novych verzich ani nějakym custom modulem?)

A takže většina instalací Drupalu běží na něčem lepším, než je běžný sdílený hosting?

- kdyz je zrovna treba smazany soubor ktery resi pripojeni do DB tak drupal nema jak zjistit, ze je v maintenance.
- u Drupalu 8 si myslim, ze ta premisa plati, ze bezi jinde nez na beznym hostingu kam se dostanes jen pres FTP
- napr. Docker deploy znamena vyrazne kratsi vypadek i bez pouziti proxy pred webem. to same i pokud bych na to sel jednoduseji a git pull mi stahl novy composer.lock a potom udelat composer install. Zkratka FTP is dead.

Pripad kdy jsou smazany soubory Drupalu Drupal resit nemuze. Kdyz je kompletne / castecne smazany, tak neni zarucene ze bude spravne fungovat.

Maintenance Mode https://www.drupal.org/docs/user_guide/en/extend-maintenance.html v Drupalu resi situaci kdy uz je aktualizovany kod Drupalu ale jeste neprobehly DB updaty. V tuto chvili kod predpoklada jinou strukturu DB a napriklad pri nacitani dat z DB by mohla nastat chyba. Web v tu chvili ceka na spusteni drush updb nebo /update.php

Situaci kdy se jeste meni soubory na serveru bych resil napriklad nasmerovanim na jiny vhost kde bude staticka stranka s 503 hlavickou + treba https://www.cloudflare.com/ ktery tu nedostupnost schova pro vetsinu navstevniku.

Mimo jineho vhostu me jeste napada ze webserver umi hledat index soubory v ruznem poradi. V .htaccess se da nastavit ze index.html ma prednost pred index.php. Jinymi slovy pokud dam na server index.html tak by to melo efektivne vypnut Drupal. - Ale to nemam ozkousene. (Nevim co s tim udelaji ciste URL, dalsi direktivy ktere ma Drupal v .htaccess atp.) Neco ke cteni: http://httpd.apache.org/docs/2.0/mod/mod_dir.html#directoryindex

> Pripad kdy jsou smazany soubory Drupalu Drupal resit nemuze. Kdyz
> je kompletne / castecne smazany, tak neni zarucene ze bude spravne fungovat.

Nechci se přít - ale předpokládal jsem od začátku úplně samozřejmě, že když existuje něco jako Maintenance Mode, tak drupal _automaticky_ vytvoří na disku nějaký (dejme tomu) statický html a příp. poupraví nastavení tak, aby po dobu změn se návštěvníkům servíroval ten statický html. ((Nebo využije nějakou jinou fíčuru, jako třeba nějakou keš, co já vím - v PHP nejsem guru, dělal jsem v jiných tech., prostě musím předpokládat,  že v PHP funguje alespoň něco z moderních technologií, když je tak žádané a rozšířené))

Nějaký důvod, proč by to bývalo bylo principiálně nešlo? Proč by to drupal řešit nemohl?

 

_Samozřejmě_, že  si to index.html tam dokážu dát sám. Nicméně v popisu u Maintenance Mode jsem dříve _nikde_ nezaregistroval upozornění, že to takto drupal neřeší a že si to mám pořešit sám.

Až s postupem času, když jsem měl trochu více drupal osahaný a měl jsem lepší odhad, co od něj mohu a nemohu očekávat, mne samozřejmě napadlo, že to dupal možná neřeší  - a šel jsem si to otestovat :-(

 

 

 

Srovnal bych to se zadanim "Tady mas prazdnou slozku do ktere nesmis zapisovat. Pripojeni do DB nemas. Zajisti ze uzivatel uvidi spravny vysledek." - Tyhle podminky se proste musi vyresit mimo jakoukoli PHP aplikaci.

Je to extremni pripad, ale realny v momente kdy bezi deploy. Na FTP hostingu je situace stejna. Jen netrva vteriny, ale minuty a to pak samozrejme svadi k tomu stravit extra 30s nakopirovanim nejakeho placeholder souboru.

Ted par detailu ktere me k tomu napadaji.

  • Hned si vybavuju autoupdate Wordpresu - OK, ale Drupal se neupdatuje sam => neridi proces. Kdyz pujdu a zacnu mazat soubory Wordpressu tak taky nikdo nezaruci ze vrati spravnou maintenance page.
  • Drupal a autoupdate se (zatim) nekamaradi protoze Drupal komunita preferuje deploy gitem, spravu verzi composerem a docroot bez prav na zapis ze strany webserveru. Coz zase nahrava bezpecnosti.
  • Doufejme ze v zari uz tu nekdo bude moci napsat ze muj prispevek je zastaraly :-) Automatic Updates initiative https://www.drupal.org/project/ideas/issues/2940731

1) automatic updates... Dlouho jsem nevidel vice kontroverzni tema (ke me to proste nesmi, ale chapu, ze pro male weby asi dobry).

2) staticky soubor vytvoreny Drupalem? Nechci, aby Drupal cokoliv psal kamkoliv mimo files. Jako vyvojar Drupalu neumim odhadovat nastaveni milionů hostingů, do toho mame sva vlastni reseni postavena dnes uz dost casto na nginx.

Co jsem cetl, tak autoupdates budou zamereny jen na mini weby typu "postav a zapomen". Jakmile pouzivas nejaky deploy proces tak to neni nic pro tebe. Jednoduse si to odporuje - bude to mozne vypnout.

Přidat komentář