Skip to content

Aktualizace a údržba ​

Tato stránka popisuje postupy pravidelné technické údržby platformy Než zazvoní CMS, provádění systémových aktualizací, údržbu databáze a auditního protokolu, správu logů a nastavení monitoringu dostupnosti. Je určena pro správce platformy.

Platforma běží na vlastním virtuálním serveru (VPS) s kontejnery Docker Compose. Správce zajišťuje provoz všech komponent: operačního systému Linux, Docker Engine, databáze PostgreSQL, redakčního systému Strapi, webového frontendu Next.js a reverzní proxy Caddy.

Plán pravidelné údržby ​

Pro zajištění vysoké dostupnosti a bezpečnosti dodržujte tento harmonogram údržby:

IntervalČinnostPopis
DenněAutomatická zálohaSpuštění skriptu ops/backup.sh v cronu a přenos zálohy mimo server.
MěsíčněAktualizace OS a DockeruInstalace bezpečnostních záplat balíčků v distribuci Debian nebo Ubuntu.
MěsíčněPromazání audit loguSpuštění skriptu scripts/audit-prune.js pro odstranění záznamů starších než rok.
MěsíčněKontrola disku a logůKontrola volného místa na disku a prověření rotace logů Dockeru.
MěsíčněTest obnovyCvičné obnovení zálohy pomocí skriptu ops/restore.sh na záložním stroji.
KvartálněAktualizace Strapi a Next.jsPovýšení verzí aplikačních balíčků po předchozím otestování na stagingu.

Aktualizace operačního systému a Dockeru ​

Bezpečnostní záplaty linuxové distribuce instalujte pravidelně jednou za měsíc.

Postup krok za krokem ​

  1. Vytvořte čerstvou zálohu: Před jakýmkoli zásahem do systému spusťte v kořenovém adresáři projektu příkaz pro zálohu:
    sh
    WEBYSKOL_PROD=1 ops/backup.sh
  2. Aktualizujte seznam balíčků a systém: Spusťte příkazy správce balíčků:
    sh
    sudo apt update && sudo apt upgrade -y
  3. Zkontrolujte verzi Dockeru: Ujistěte se, že Docker Compose plugin je ve verzi 2.24 nebo novější, která podporuje předávání tajných údajů (secrets) ze zdroje environment:
    sh
    docker compose version
  4. V případě potřeby restartujte server: Pokud aktualizace obsahovala nové jádro operačního systému (kernel), restartujte stroj příkazem sudo reboot.
  5. Ověřte stav služeb: Po naběhnutí serveru zkontrolujte, zda všechny kontejnery běží a mají stav healthy:
    sh
    docker compose -f docker-compose.yml -f docker-compose.prod.yml ps

Aktualizace jádra Strapi a Next.js ​

Verze závislostí v souborech cms/package.json a web/package.json jsou z důvodu stability a bezpečnosti pinované na konkrétní čísla verzí (bez použití stříšek ^ nebo tild ~). Aktualizace na vyšší verze provádějte plánovaně jednou za čtvrtletí.

Postup krok za krokem ​

  1. Vytvořte zálohu produkčních dat: Spusťte zálohovací skript WEBYSKOL_PROD=1 ops/backup.sh.
  2. Připravte aktualizaci v lokálním prostředí: Upravte čísla verzí v package.json a spusťte instalaci, aby se aktualizoval soubor package-lock.json.
  3. Nasaďte změny na staging instanci: Spusťte kontejnery se staging konfigurací a nahrajte do nich kopii produkčních dat.
  4. Proveďte sadu testů: V kořeni projektu spusťte všechny verifikační skripty:
    sh
    node tests/site-schema-test.mjs
    node tests/tenant-test.mjs
    node tests/web-test.mjs
    node web/scripts/crawl.mjs --school demo
    Test tenant-test.mjs musí projít se všemi kontrolami bez jediné chyby. Ověřuje, že aktualizace jádra Strapi nenarušila Document Service guard ani lifecycles médií.
  5. Přeneste upravený kód na produkční server: Zkopírujte aktualizované soubory na server přes git nebo nástroj rsync (vynechte složky node_modules, .next, data a soubor .env).
  6. Sestavte a spusťte nové kontejnery: Na serveru spusťte nový build obrazů:
    sh
    docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build
  7. Zkontrolujte endpoint zdraví: Ověřte, že administrace odpovídá kódem 204:
    sh
    curl -I https://<CMS_HOST>/_health

Údržba a promazávání audit logu ​

Redakční systém zaznamenává veškeré operace úprav, publikování, smazání obsahu i manipulace se soubory do auditního protokolu (api::audit-log.audit-log). Protokol slouží ke zpětnému dohledání změn a k plnění požadavků na ochranu osobních údajů.

Z bezpečnostních důvodů je audit log přes HTTP rozhraní dostupný pouze pro čtení. Záznamy nelze z administrace smazat. K řízenému promazávání slouží skript audit-prune.js, který přistupuje přímo k databázi uvnitř kontejneru CMS.

Na následujícím snímku vidíte, jak se zaznamenané události zobrazují správci v administraci:

Historie změn v administraci

Spuštění promazání ​

Příkaz spusťte na hostitelském serveru v adresáři projektu:

sh
docker compose -f docker-compose.yml -f docker-compose.prod.yml exec -T cms node scripts/audit-prune.js --days 365

Parametr --days určuje stáří záznamů, které mají být smazány. Výchozí hodnota je 365 dní (1 rok). Skript má bezpečnostní pojistku: hodnota parametru --days musí být celé číslo a nesmí být menší než 30 dní.

Pro pravidelné promazávání nastavte spouštění tohoto příkazu do systémového plánovače cron s měsíční periodou:

cron
0 3 1 * * cd /opt/webyskol && docker compose -f docker-compose.yml -f docker-compose.prod.yml exec -T cms node scripts/audit-prune.js --days 365 >> /var/log/audit-prune.log 2>&1

Správa disku a rotace logů ​

Kontejnery Dockeru standardně zapisují výstupy do souborů na disku. Bez omezení velikosti mohou logy po čase zaplnit celou diskovou kapacitu serveru.

Nastavení rotace Docker logů ​

V souboru /etc/docker/daemon.json na hostitelském serveru nakonfigurujte ovladač json-file s těmito limity:

json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "5"
  }
}

Toto nastavení omezí velikost jednoho souboru logu na 20 MB a zachová maximálně 5 rotovaných archivů pro každý kontejner. Změnu aplikujte příkazem sudo systemctl reload docker.

Přístupové logy Caddy ​

Provozní přístupové logy (access logs) reverzní proxy Caddy ponechte vypnuté, případně nastavte velmi krátkou dobu uchování. IP adresy návštěvníků jsou podle nařízení GDPR osobními údaji a platforma školních webů je nepotřebuje dlouhodobě shromažďovat.

Sledování volného místa ​

Pravidelně kontrolujte stav disku příkazem df -h. Sledujte zejména zaplnění svazků pgdata (databáze) a uploads (knihovna médií). Při překročení 80 % kapacity disku naplánujte navýšení diskového prostoru nebo přesun médií na objektové úložiště S3.

Monitoring dostupnosti ​

Pro včasné odhalení výpadků nastavte externí monitorovací službu (uptime monitoring), která bude prověřovat stav serveru v intervalu jedné minuty.

Doporučené kontrolní body:

  1. Stav jádra administrace: HTTP požadavek typu HEAD nebo GET na adresu https://<CMS_HOST>/_health. Systém vrací stavový kód 204 No Content, pokud aplikace Strapi i databáze PostgreSQL správně fungují.
  2. Stav veřejného webu: HTTP požadavek na úvodní stránku vybrané školy https://<doména školy>/. Očekávaný stavový kód je 200 OK.

Při selhání kteréhokoli testu nastavte okamžité odeslání výstražného upozornění na e-mail technické podpory provozovatele.

Tipy a doporučení ​

Cvičná obnova databáze

Záloha, kterou nikdo nikdy nezkusil obnovit, není skutečná záloha. Jednou za měsíc vyzkoušejte spuštění skriptu ops/restore.sh se záložním archivem na testovacím virtuálním stroji.

Sledování kvót médií

Při hlášení od redaktora, že do knihovny médií nelze nahrát další soubory, ověřte využití jeho kvóty. Výchozí limit je 2048 MB na školu. V případě potřeby lze kvótu navýšit v proměnné SCHOOL_MEDIA_QUOTA_MB.

Časté chyby ​

  • Povýšení verzí přímo na produkci: Změna minor verzí jádra Strapi může změnit chování Document Service. Nikdy neprovádějte upgrade přímo na ostrém serveru bez otestování na stagingu.
  • Příliš malá hodnota parametru u audit-prune: Zápis parametru --days s hodnotou nižší než 30 způsobí chybu a skript se nespustí.
  • Chybějící rotace logů Dockeru: Výchozí instalace Dockeru nemá nastavené limity velikosti logů. Po několika měsících provozu mohou logy zcela vyčerpat volné místo na disku.

Související ​