Statična spletna mesta zdaj ostanejo na voljo med ponovnim objavljanjem

Ponovno objavljanje statičnega spletnega mesta na Mythexu je prej najprej izbrisalo žive datoteke in šele nato naložilo novo verzijo, zato so med nalaganjem nekateri obiskovalci dobili stran 404 ali stran, ki ji manjkajo skripti. Neuspešno nalaganje je lahko pustilo mesto prazno ali le delno novo. Zdaj se nova verzija zapiše čez staro, strani se zapišejo zadnje, ostanki pa se odstranijo nekaj minut kasneje. Drugi popravek poskrbi, da se ponovna objava pokaže v nekaj sekundah namesto v minuti – ali, za datoteke kot je logotip, do enega dneva.

Kako je statično spletno mesto postreženo

Statično spletno mesto je sestavljeno samo iz datotek: HTML strani, JavaScript, CSS in slik. Ko ga objavite na Mythexu, ga zgradimo, izhod naložimo v objektno shrambo v mapo za vaše mesto in ga postrežemo prek omrežja robnih strežnikov – strežnikov blizu vaših obiskovalcev, ki datoteke pridobijo iz shrambe in jih nekaj časa hranijo. (Če ste s tem novi, naš vodnik o tem, kaj je CDN pojasni idejo.)

Narobe sta bili dve stvari: vrstni red, v katerem ponovna objava spreminja datoteke, in to, kako dolgo so se hranile stare kopije.

Težava 1: nalaganje je najprej izpraznilo mesto

Ponovna objava je izbrisala vse v mapi mesta in nato naložila novo verzijo. Vse dokler je nalaganje trajalo – 12 sekund za mesto s 250 datotekami v našem lokalnem testu – je obiskovalec, čigar zahteva še ni bila v predpomnilniku na robu, dobil 404 ali HTML stran, katere skripti so vračali 404.

Neuspešno nalaganje je bilo še slabše. Mapa je bila že prazna, na eni od obeh poti nalaganja pa se je lahko nov index.html naložil, preden je spodaj padla datoteka. Objava, ki je bila označena kot neuspešna, je lahko pustila napol novo mesto v živo.

Popravek: pisanje čez, strani zadnje, brisanje pozneje

1. Najprej ne brišemo. Nova verzija se naloži čez staro.
2. Sredstva pred stranmi. Stran navaja skripte in sloge, ki jih potrebuje, zato strani gredo gor zadnje. Dokler nove strani niso naložene, obiskovalci dobijo staro stran, ta pa navaja stara sredstva, ki so še tam. Ko pridejo nove strani, so novi sredstva, ki jih navajajo, že na mestu.
3. Ostanke odstranimo pozneje. Pred nalaganjem zabeležimo, iz česa je mesto sestavljeno. Tri minute po uspešnem nalaganju se izbrišejo vse datoteke s tega seznama, ki jih nova verzija ni prepisala. Tri minute so več kot 60 sekund, kolikor lahko stran ostane v predpomnilniku na robu in v brskalniku, zato obiskovalec, ki še vedno drži staro stran, lahko najde sredstva, ki jih ta navaja.
4. Če dvomite, ne brišite ničesar. Če seznam pred nalaganjem ne uspe, se nič ne odstrani. Ostanki datotek so nenevarni, naslednja objava jih počisti. Brisanje brez vedenja, kaj je bilo tam, je tisto, zaradi česar mesto ostane prazno.

Neuspešno nalaganje zdaj pusti prejšnje mesto točno takšno, kot je bilo.

Testirali smo od začetka do konca lokalno, z dejansko skripto za nalaganje, dejansko potjo za nalaganje in shranjevanjem ter obiskovalci s hladnim predpomnilnikom na robu. Pri starem kodu je bilo 55 od 91 obiskov pokvarjenih med ponovno objavo, 61 od 92 pa med neuspešno. Pri novi kodi je bilo 0 pokvarjenih med približno 3.500 obiski, ki so zajeli obe poti nalaganja, neuspešno nalaganje in objavo po njem – in odstranjene so bile točno ostale datoteke.

Težava 2: ponovna objava se je prikazala prepočasi

Tudi ko je nalaganje teklo dobro, so se spremembe pojavljale počasi. Rob je hranil kopijo strani 60 sekund in vseh drugih datotek en dan, in to je sporočal tudi brskalnikom. Datoteke s fiksnim imenom – logo.png, pisava, karkoli iz mape public/ – so lahko še do enega dneva po ponovni objavi kazale staro različico.

Popravek: kopije datotek pod oznako gradnje

Ko rob vpraša naš API, kje mesto živi, odgovor zdaj vključuje oznako gradnje, ki se spremeni ob vsaki objavi. Rob shranjuje kopije pod to oznako. Objava tako postane popolnoma nov nabor ključev predpomnilnika takoj, ko poteče 30-sekundno iskanje na robu. Stare kopije se nikoli več ne najdejo, zato lahko rob hrani kopije en dan, ne da bi kdaj postregel kopijo, ki jo je nadomestila objava.

Brskalniki dobijo dve različni pravili:

• Zgrajeni izhod z razpršenimi imeni – datoteke kot assets/index-CzLcxDO8.js, katerih ime se spremeni, kadar se spremeni vsebina – se hranijo eno leto in so označene kot nespremenljive. Pod tem imenom nikoli ne morejo biti zastarele.
• Vse ostalo – strani in datoteke s fiksnim imenom, kot je logotip – so označene z no-cache, kar pomeni »preveri pred uporabo«. Če se nič ni spremenilo, je odgovor majhen 304 Not Modified brez vsebine, saj zdaj upoštevamo brskalnikovo preverjanje If-None-Match.

Razlikovanje obeh zahteva previdnost: datoteka, kopirana iz public/assets/, ohrani svoje ime, in če bi assets/logo.png hranili eno leto, bi za eno leto zaklenili stari logotip. Zato se datoteka šteje za razpršeno le, če je v mapi izhoda gradnje in če njeno ime vsebuje segment, ki je videti kot zgoščena vrednost, ne običajna beseda.

Lokalno sta bili nova stran in logotip vidna 6 sekund po tem, ko je objava stopila v veljavo. Prej je bilo to 60 sekund za stran in en dan za logotip.

Dve manjši popravili ob tem

• Prazne strani iz zahtev HEAD. Zahteva HEAD zahteva glave strani brez vsebine. Prazne odgovore smo shranjevali v predpomnilnik, zato je naslednji obiskovalec te strani dobil prazno stran. Odgovori HEAD se zdaj ne shranjujejo v predpomnilnik.
• Prava stran za »tukaj ni ničesar«. Naslov brez aplikacije je prej vrnil navadno besedilo »This published app is offline or the link was not found« s kodo napake 502. Zdaj dobi pravo stran »Tukaj ni nobene aplikacije« s statusno kodo 404 in povezavo nazaj na Mythex za lastnika. Enako dobijo neznane domene po meri.

Kaj smo iz tega vzeli

• Vrstni red je del pravilnosti. Enake datoteke, naložene v drugačnem vrstnem redu, so razlika med pokvarjenim in delujočim mestom.
• Brišite pozno in samo tisto, kar poznate. Čiščenje s seznamom, zajetim pred nalaganjem, je varno; praznjenje mape in upanje, da se nalaganje konča, ni.
• Predpomnite po različici, ne po času. Časi poteka so ugibanje, kdaj se vsebina spremeni. Ključ, ki se spreminja z gradnjo, je dejstvo.

Povezano: vaša objavljena aplikacija zdaj ostane na voljo med ponovnim objavljanjem. Več o objavljanju je v dokumentaciji.