Vyzkoušeno: automatická aktualizace jádra Drupalu až na pár mušek funguje skvěle

Nevýhodou Drupalu 8 je množství malých souborů, kvůli kterým trvá jeho kopírování po FTP desítky minut. Pokud nemáte možnost přejít na lepší hosting s SSH, pak by vás mohl zaujmout pokrok v oblasti automatické aktualizace jádra Drupalu přímo z administrace. Během minutky tak spustíte aktualizaci kliknutím v prohlížeči, případně zcela automaticky.

WordPress to má fajn. Ráno se vzbudíte a v mailu uvidíte hlášení o provedené aktualizaci svého webu. Že pak na web kouknete a zjistíte, co všechno se tam rozbilo, to je věc druhá. Já mám WordPress spíše na malých webech, a tak jsem zatím na problém nenarazil.

Dostupnost aktualizací nám Drupal kontroluje automaticky, jak pro své jádro, tak pro doplňkové moduly a témata vzhledu. Aktualizovat kliknutím v administraci však zvládá už jenom ty moduly a témata.

Má to svůj důvod. V jádře jsou občas takové změny, které vyžadují nějaké další zásahy (nejčastěji předcházející aktualizaci modulů na nejnovější verzi). Jádro je tak nutné kopírovat ručně s vědomím, co vše je pak potřeba zařídit.

Na druhou stranu přeci vím, co dělám. Spouštím aktualizaci a je jedno, co použiju pro její nakopírování. V Drupalu 7 to při použití FTP není až tak velký problém. Nakopírován je do pár minut, pustím update.php a je hotovo.

Drupal 8, založený na komponentách Symfony, obsahuje násobně více souborů a jejich kopírování pro zastaralém FTP zkrátka trvá desítky minut. A i kvůli slabé nabídce českých hostingů s čímkoli modernějším než je FTP, mám řadu klientů majících Drupal přístupný jen skrze FTP. O komfortu příkazového řádku si jako správce mohu nechat leda zdát.

Proto velmi oceňuji snahy vývojářů začlenit do jádra Drupalu možnost automatického nakopírování nového jádra přímo z administrace. Zatím je tato funkcionalita dostupná jen ve formě doplňkového modulu. Plánem je dostat ji přímo do jádra. Ostatně, vývoj podporují Drupal Association, Evropská komise nebo Acquia. Tím budoucí začlenění do jádra beru za hotovou věc.

Dvě fáze vývoje automatických aktualizací jádra Drupalu

Práce na iniciativě automatických aktualizací má dvě fáze. První zahrnuje JSON feedy s informacemi z Drupal.org, zpracování aktualizací v administraci webu, bezpečnostní hledisko a další věci. Tato část je již hotova.

Druhá fáze přinese A/B testování pro robustnější kontrolu webu po aktualizaci a případnou možnost návratu do předchozího stavu. Rovněž automatickou instalaci aktualizací modulů. A v neposledním případě i podporu webů, kde byl Drupal instalován pomocí Composeru.

Průběh aktualizace Drupalu 8 krok za krokem

Rozhodl jsem se modul Automatic Updates vyzkoušet na menším webu s Drupalem 8. Web byl instalován klasicky rozbalením instalačky a nakopírováním na FTP. Žádný composer, drush, nic sofistikovaného.

V době, kdy jsem se do aktualizace pouštěl, běžel web na Drupalu 8.7.8 a cílem bylo provést pohodlnou aktualizaci na Drupal 8.8.1.

Po zapnutí modulu jsem přešel do administrační části Nastavení > Systém > Automatic Updates. Kromě hlášky o dostupnosti aktualizací Drupal zobrazuje informaci o tom, že doposud neproběhla kontrola připravenosti na automatické aktualizace.

Drupal Automatic Updates

Ve zmíněné administrační části tedy klikám na nenápadný odkaz run the readiness check. Modul se pouští do kontroly, jejíž výsledek zobrazuje v další sadě hlášek. V mém případě našel několik kritických a několik méně závažných problémů:

  • Složka s webem nebyla přístupná pro zápis. Opravil jsem změnou oprávnění na serveru a tím vyřešil červený problém.
  • Majitel složky byl jiný než PHP proces, pod kterým běžel Drupal. Opravil jsem na serveru. Kdybych tam kdysi nepřistupoval jinak než po FTP, problém by nebyl.
  • Kontrolní hashe pro .htaccess a robots.txt nesouhlasí s originálem. Jasně, dělal jsem v nich změny. Vyřešil jsem doplněním do políčka pro ignorování kontroly.
  • Výchozí settings.php a další soubory jsem přepsal z instalačky Drupalu 8.7.8. Při minulých ručních aktualizacích jsem tak nečinil, proto se mi to rozešlo. Na funkci webu to každopádně nemělo vliv.

Drupal Automatic Updates

Pro jistotu jsem do políčka Paths to ignore for readiness checks doplnil tedy tři řádky:

.htaccess
robots.txt
sites/*

Znovu jsem spustil kontrolu a vše již proběhlo v pořádku.

Automatickou aktualizaci jádra Drupalu aktivujete po rozbalení sekce Experimental zapnutím volby Enable automatic updates of Drupal core via cron. Já to neudělal. Jednak nevěřím tomu, co dopředu nevyzkouším, jednak mi jde jen o rychlejší nakopírování. Jinak chci mít průběh aktualizace pod svou kontrolou.

Kliknul jsem tedy místo toho na odkaz Manually update now.

První pokus se nezdařil. Přestože kontrola připravenosti na aktualizace si už nestěžovala, proces se zadrhnul na rozdílech v .htaccess a robots.txt. Z mého pohledu nesmyslně. Do robots.txt sahám proto, abych doplnil odkaz na sitemapu. Jistě, mohl bych to řešit modulem pro soubor robotů, ale úprava jednoho txt je přece jednodušší.

V případě .htaccess jej upravuji proto, abych doplnil přesměrování z non www na www a také z http na https. Nemluvě o požadavcích různých hostingů, kde je člověk nucen zakomentovat některé direktivy v tomto souboru.

Ale dobře. Nahradil jsem tyto soubory originálem z instalačky dané verze Drupalu. Opět jsem kliknul na ruční spuštění aktualizace a chvilku si kousal nehty (obrazně).

Aktualizace neproběhne na lusknutí prstu. Přeci jen je i pouhé rozbalení takového počtu souborů docela náročné. Nakonec však prošla bez zaškobrtnutí a bylo hotovo.

Tedy… Kouknul jsem do Logy > Hlášení stavu a zjistil, že modul neprovedl aktualizaci databáze. To jsem musel ručně napravit.

Drupal Automatic Updates

Dojmy z průběhu aktualizace? Je to na dobré cestě, ale…

Když člověk vyřeší drobné zádrhely, které aktualizaci brání ve spuštění, tak funguje. Bál jsem se zhavarování na nějakém time limitu v PHP. Přeci jen to docela dlouho trvalo. Na daném webu mám max_execution_time nastaven na 30 sekund a aktualizaci to zvládlo. Měl by to tedy dát i váš hosting.

Za větší problém považuji kontrolu .htaccess. Navzdory tomu, že soubor byl uveden mezi cestami k ignorování. Ignoruje jej kontrola připravenosti, nikoli však samotná aktualizace. To mi přijde blbé. Nepamatuju si web, kde bych změny v .htaccess neprováděl.

Na druhou stranu si teď nejsem jist, jestli ta kontrola nebyla vynucena změnami v .htaccess mezi danými verzemi Drupalu. Možná, kdyby tam změny nebyly, Drupal by můj ruční zásah ignoroval.

Celý proces tedy rozhodně zatím není na jedno kliknutí, zvláště, když vyžaduje ještě spustit aktualizace databáze a nijak to nepřipomíná. Je to ale rozhodně na dobré cestě a nějaký čas ušetří už v tuto chvíli. Doporučuji jej nasadit, ale zatím používat ručně. Aktualizace pomocí cronu nedává smysl, když neprovede i změny v databázové struktuře.

Tagy

Buďme ve spojení, přihlaste se k newsletteru

Odesláním formuláře souhlasíte s podmínkami zpracováním osobních údajů. 
Více informací v Ochrana osobních údajů.

Autor článku: Jan Polzer

Tvůrce webů z Brna se specializací na Drupal, WordPress a Symfony. Acquia Certified Developer & Site Builder. Autor několika knih o Drupalu.
Marketing Director v Lesensky.cz. Ve volných chvílích podnikám výlety na souši i po vodě. Více se dozvíte na polzer.cz a mém LinkedIn profilu.

Komentáře k článku

Přidat komentář

Odesláním komentáře souhlasíte s podmínkami Ochrany osobních údajů

reklama
Moje kniha o CMS Drupal

 

Kniha 333 tipů a triků pro Drupal 9


Více na KnihyPolzer.cz

Sledujte Maxiorla na Facebooku

Maxiorel na Facebooku

Poslední komentáře
Nové diskuze
Hosting pro Drupal a WordPress

Hledáte český webhosting vhodný nejenom pro redakční systém Drupal? Tak vyzkoušejte Webhosting C4 za 1200 Kč na rok s doménou v ceně, 20 GB prostoru a automatické navyšováním o 2 GB každý rok. Podrobnosti zde.

@maxiorel na Twitteru

Maxiorel na Twitteru