Pět příspěvků pokrylo to, o čem 1.9 je: příspěvek ve dvou jazycích, web v jazyce stránky, co leží v cíli nasazení před prvním nasazením, hosting, který umí jen FTP a jednu zkratku v telefonu místo dvou. Tenhle je zbytek, v pořadí, v jakém ho provozovatel potká. Většina z něj přišla od dvou lidí, kteří 1.9 nainstalovali od nuly a upgradovali kopii webu o 6 600 příspěvcích, přesně podle dokumentace.
Sdílený hosting často přichází s adresářem, přihlášením přes FTP a ničím dalším – bez SSH, bez rsync, bez gitu. Pro blog.sh to stačilo odjakživa; dokumentace to jen do 1.9 neříkala. Cesta vede přes backend rclone, protože rclone umí FTP jako jeden ze svých mnoha vzdálených cílů.
Někdo stěhuje blog z WordPressu na blog.sh a nechává si stejný hosting, stejný adresář i stejnou adresu. Sestavení je hotové, první nasazení projde bez jediné chyby – a úvodní stránka je pořád ta stará. Při nahrávání se nic nepokazilo. Starý web jen nikdo neodstranil a hosting mu dává přednost.
How did I set up blog.sh on my shared hosting
pavelchcepsat.cz
Pavel přestěhoval WordPressový blog ze sdíleného hostingu na blog.sh, a to přes obyčejné FTP. Postup popisuje krok za krokem: export WXR, import, rclone, zkušební běh, nasazení.
Stojí za přečtení, pokud tvůj web běží na hostingu, který nabízí FTP a nic víc.
#blogsh #wordpress #staticsite
Někdo postaví celý web na notebooku, naimportuje do něj desetiletí starých příspěvků, prohlédne si každou stránku — a nic z toho ještě nikam nedorazilo. V env.sh není řečeno kam a nic dalšího na to nečeká: sestavení proběhne, archiv projde kontrolou, každá stránka se vykreslí na localhost. Sestavení neví, kde má web nakonec skončit, a vědět to nepotřebuje.
Totéž sestavení může začít na notebooku, o rok později se přestěhovat na pronajatý VPS a potom skončit na instanci Cloudronu. Mezi těmito přesuny se v obsahové pipeline nemění nic. Mění se odpověď na jedinou otázku — kam mají soubory jít — a odpovědět na ni může šest věcí.
DEPLOY_BACKEND v env.sh určuje cíl; hodnoty pod ním závisejí na tom, který to je. Všechno za tímto řádkem je u všech šesti stejné. Každý backend si vede vlastní manifest — SHA-256, velikost a čas změny každého souboru, který už nahrál — takže nasazení posílá vždy jen to, co se od minulého změnilo. deploy-web.sh --dry-run tento manifest přečte, aniž by se čehokoli dotkl.
Takhle vypadá výstup, spuštěný právě teď proti vlastnímu backendu tohoto webu:
Průvodci byli přeložení od začátku; vyprávění kolem nich ne. Český web sledoval vlastní nasazení v angličtině, o řádek nad českou větou – varování sestavení, selhání oznámení, chyby importu, pokyny fronty k opravě, všechno. Ne přímo rozbité. Jen dům, kde půlka pokojů odpovídá jiným jazykem.
1.4 tu práci dokončuje: celé vyprávění nasazení – hlavička, průběh, závěrečný součet, každé oznámení o omezení – plus všech jedenáct varování sestavení, každé selhání Bluesky a Mastodonu a věty, které import vypíše, když zdroj zemře. Angličtina, čeština a němčina nesou tutéž sadu a sada testů paritu vynucuje, takže klíč nemůže existovat v jednom jazyce a v druhém shodit běh.
Diagnostika uvnitř vět se nepřekládá: HTTP kód, syrová odpověď serveru, text výjimky. To jsou důkazy a důkazy se citují, ne parafrázují – věta kolem nich patří webu, to uvnitř patří síti.
Nasazení tohoto webu má dvě pojistky. Když má sestavení náhle mnohem méně souborů, než je naživo, nebo mnohem méně bajtů, nasazení se zastaví. Existují proto, že rozbité sestavení vypadá pro rsync --delete přesně jako záměrné, a statický web je vždy jen jednu sebejistou synchronizaci od vymazání.
V 1.0 se uměly samy vypnout. Trvale. Potichu. Tady je jak, protože tvar téhle chyby je užitečnější než oprava.
Pojistky porovnávaly nové sestavení s manifestem nasazení – záznamem toho, co je na cíli. Rozumné, dokud nahrání neselže. Neúspěšné nahrání nechá manifest mimo skutečnost a pojistka měřící proti záznamu, o kterém ví, že je špatně, by spustila poplach při každém dalším běhu.
Takže tam byla značka: po neúspěšném běhu pojistky odvolat, dokud nepřijde čistý běh a referenci neobnoví.
To je celá funkce: nasazení předpokládá, že velká změna je chyba, dokud neřekneš jinak.
Každé nasazení si vede manifest – SHA-256, velikost a mtime každého nahraného souboru. Další nasazení se proti němu porovná a sáhne jen na to, co se skutečně změnilo. Rychlé, nudné, správné.
Zajímavá část je to, co se stane, než se cokoli nahraje. Když počet souborů od posledního nasazení klesl o víc než 20 %, celé se to zastaví. Tohle je skutečný výstup z tohoto webu – na minutu jsem odstavil polovinu složek sestavení z dohledu a požádal o nasazení: