Bejelentkezés

Statikus WordPress-közzétételi sor és üzemeltetés

A Static Publisher sorba állított feladatokra és külső végrehajtásra épül.

Futásidejű fájlok​

A bővítmény a wp-content/uploads/smartcloud-static-publisher/runtime alatt írja az állapotot, többek között:

  • config.json
  • queue.json
  • current-run.json
  • last-run.json
  • export.lock

A célzott tartalomszinkronizálás ebben a futásidejű könyvtárban tartja karban az alapszint, a kurzor, az ellenőrzőpont, a jelölt jegyzék, a hatásterv, a telepítési eltérés és az érvénytelenítés állapotát is. Amíg egy tartalomszinkronizálási feladat sorban áll, fut vagy újrapróbálkozásra vár, ezek a fájlok üzemeltetési állapotot tárolnak, nem eldobható gyorsítótárat.

A naplók a beállított naplókönyvtárban találhatók, a befejezett feladatok pedig az archive/<timestamp-command-jobId-status>/ alatt archiválják műtermékeiket.

Sorparancsok​

Az adminisztrációs felületen a következő parancsok állíthatók sorba:

  • publish
  • crawl
  • deploy
  • invalidate
  • retry-timeouts
  • url egyetlen útvonalas futáshoz

A content-sync feladatokat Professional- vagy Agency-szintű ütemezési szabályok hozzák létre. Ezek nem szabad formátumú kézi URL-parancsok: a feladat változtathatatlan tartományt foglal le a WordPress tartalomnaplójából, és a szabály mentett hatókörét használja. A növekményes közzététel és a célzott tartalomszinkronizálás azonos szintű aktív előfizetést igényel.

Ideiglenes AWS-hitelesítő adatok csatolhatók a publish, deploy és invalidate feladatokhoz. Ezek csak az adott feladat gyermekfolyamatának környezeti változóiba kerülnek be, az adminisztrációs állapot-adattartalmakból pedig ki vannak takarva.

Ütemezési modell​

Az ütemezési szabályokat a publisher-exporter queue-runner minden futtatás elején kiértékeli.

Ennek fontos következményei:

  • a bővítmény önmagában nem indítja el a futtatót,
  • éles rendszerekben cront, systemd-időzítőt, CI-t vagy más külső ütemezőt kell használni,
  • ajánlott kiindulópont az egyperces futtatási ütem,
  • az aktuális intervallumon belül a rendszer kihagyja az egymással egyenértékű ismétlődő feladatokat,
  • az ismétlődő tartalomszinkronizálási igényeket összevonja; a lefoglalt tartomány feldolgozása közben érkező változások követő munkává válnak, és nem bővítik a futó tartományt.

A tartalomszinkronizálás ütemezésének engedélyezése előtt futtasson sikeres normál teljes vagy növekményes közzétételt. Ez a kiadás hozza létre a megbízható jegyzéket és az ellenőrzött alapszintet. A téma, a bővítmény, a közvetlen hivatkozás, a webhelytérkép, az átírás, a hatókör vagy a telepítési cél módosítása szándékosan elavultként jelöli az alapszintet, és új normál közzétételt igényel. Az Ütemező beállításai képernyő közvetlenül jelenti ezt az állapotot.

Jellemző Linux cron-minta:

* * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock \
  publisher-exporter queue-runner \
  --runtime-dir /var/www/site/wp-content/uploads/smartcloud-static-publisher/runtime \
  --max-jobs 1 >> /var/www/site/wp-content/uploads/smartcloud-static-publisher/logs/queue-runner-cron.log 2>&1

Telepítési profilok​

A Static Publisher a legfelső szintű célbeállításokat alapcélként kezeli. A további célok a deploymentProfiles alatt találhatók, és a deploy vagy invalidate művelet során választhatók ki.

Így lehetősége van:

  • egyetlen bejárásra,
  • az alapcélra történő telepítésre,
  • ugyanazon műtermék újrafelhasználására tesztelési, éles vagy ügyfélspecifikus célokhoz,
  • annak elkerülésére, hogy minden előléptetési lépéshez újra be kelljen járni a forrást.

Ha egy profil módosítja a targetOrigin értékét, részesítse előnyben az abszolút átírási módot, hogy a telepítés biztonságosan új célra irányíthassa a már bejárt műterméket.

Naplók és újrapróbálkozási munkafolyamat​

  • a gyökérszintű naplófájlok alkotják az aktuális munkakészletet,
  • a befejezett, sikertelen és leállított feladatok gzip-tömörített naplóműtermékeket és job.json fájlt archiválnak,
  • a retry-timeouts lehetőség szerint a legújabb archivált teljes crawl vagy publish futásból határozza meg az újrapróbálandó URL-eket,
  • a régi archívumokat egy megőrzési feladatból futtatott publisher-exporter prune-logs paranccsal kell eltávolítani.

A tartalomszinkronizálás újrapróbálkozásai megőrzik ugyanazt a lefoglalt tartományt és ellenőrzőpontot. A korlátozott késleltetés megakadályozza egy hibás cél folyamatos terhelését. Ha egy üzemeltető elvet egy sorban álló újrapróbálkozást a WordPressben, a helyi terv törlődik, de a naplókurzor változatlan marad; egy későbbi ütemezőfutás újra felfedezheti a nyugtázatlan tartományt. A törlési és alapszint-biztonsági szabályokért lásd a Célzott tartalomszinkronizálás oldalt.

Külső gazdagépen történő végrehajtás​

Ha a WordPress gazdagépe nem tud Node-ot, Playwrightot vagy cront futtatni, dolgozza fel a sort egy másik gépről, amely látja ugyanazt a futásidejű könyvtárat, vagy töltse le egy sorba állított feladat konfigurációját, és játssza vissza saját parancssorából vagy CI-futtatójából.