Provoz a řešení problémů
Společný deployment
Produkční jednotkou je repozitář nkp-deploy. Aktuální docker-compose.yml spouští:
solrna hostitelském portu8983,tomcats webem/API na portu8088,harvesterz imagebackend-build:latests argumentemharvester,updaterze stejného image s argumentemupdater.
Oba backendové kontejnery čekají na healthcheck Solru. Všechny aplikační kontejnery sdílejí ./.kapp:/root/.kapp.
První spuštění
V kořeni nkp-deploy:
sudo chown -R 8983:8983 solr/
docker compose pull
docker compose up -d
docker compose ps
Pro neveřejné GHCR image se deployment server přihlašuje pomocí provozního GitHub účtu a personal access tokenu classic s oprávněním read:packages; podrobnosti jsou v návodu pro GitHub Actions a GHCR. Hostitelský Tomcat není potřeba; web běží v kontejneru služby tomcat.
Před spuštěním
Ověřte:
- Docker a Compose,
- čitelnost
.kapp/app.confa webové konfigurace, - práva uživatele 8983 k
solr/, - cores
titles,authors,aut,contracts,configuration, - dostupnost všech URL v
instances, - perzistenci
.kapp/contractsa případného file touch store, - Keycloak URL, realm/client a role,
- že produkční secrets nejsou nahrazené ukázkovými hodnotami.
Aktualizace
git pull
docker compose pull
docker compose up -d
docker compose ps
Změny Solr schémat kontrolujte před restartem. nkp-deploy obsahuje i data cores; neprovádějte slepé nahrazení produkčních indexových adresářů obsahem pracovního repozitáře.
Logy
docker compose logs -f harvester
docker compose logs -f updater
docker compose logs -f tomcat
docker compose logs -f solr
Harvest job používá startNow(), takže restart harvester okamžitě spustí
sklizeň a po ní úplný updater. Restart samostatné služby updater pouze obnoví
interní API pro cílené přepočty.
Kontrola harvestu
- změnil se
.kapp/timestamps/<acronym>/timestamp, - v
titlespřibyly/změnily se dokumenty a MODS MD5, - v
authorspřibyly autority, - nové tituly mají
state,state_historyaassigned_licenses, - log obsahuje commity
titlesaauthors.
Chybějící timestamp způsobí full harvest. Nesprávné apiVersion, url nebo solrCloud může způsobit prázdný či opakující se cursor.
Kontrola updateru
- log nejdřív zpracuje smlouvy a poté tituly,
- změny stavu mají
state_user:Updater, release_yearodpovídá opravenému nebo sklizenému roku,- licence ze smluv se přidaly pouze titulům se shodným ČČNB/ISSN a správnou knihovnou,
- po běhu proběhl commit
titles.
Updater aktuálně prochází celý core. U velkého indexu sledujte dobu běhu a zatížení Solru.
Provozní kontrola webového API a diagnostika oprávnění je v technické dokumentaci webové a API vrstvy.
Smlouvy
Když updater nepřidá licenci:
- smlouva musí mít ČČNB nebo ISSN,
- licence musí obsahovat prefix a
_, napříkladmzk_dnnt, - titul musí mít shodný identifikátor,
- odpovídající
licenses_<acronym>musí potvrdit danou knihovnu, - zkontrolujte log „Skipping contract license“.
File touch store
Při factory: "file" zkontrolujte trvalý a zapisovatelný baseDir. Pro PID se ukládají pid.txt, root_pid.txt, mods.xml, mods_md5.txt, source.txt a physicalLocations.txt. Při problémech s inody použijte factory: "solr".
Bezpečný hromadný zásah
- Pořiďte Solr backup/snapshot.
- Ověřte konfiguraci a počty kandidátů.
- Vyzkoušejte reprezentativní vzorek.
- Spusťte příslušnou službu/import.
- Porovnejte počty stavů a licencí.
- Zkontrolujte
state_history,state_date,release_yeara smluvní licence. - Teprve poté posuňte checkpoint odebírajícího Krameria.