Staattiset sivustot pysyvät pystyssä, kun ne julkaistaan uudelleen

Staattisen sivuston uudelleenjulkaisu Mythexissä poisti aiemmin live-tiedostot ensin ja lataa sitten uuden buildin. Lataus kesti jonkin aikaa, joten osa kävijöistä sai 404-sivun tai sivun, jonka skriptit puuttuivat. Epäonnistunut lataus saattoi jättää sivuston tyhjäksi tai puoliksi uudeksi. Nyt uusi build kirjoitetaan vanhan päälle, sivut viimeisinä, ja jäljelle jääneet tiedostot poistetaan muutamaa minuuttia myöhemmin. Toinen korjaus tekee uudelleenjulkaisusta näkyvän sekunneissa minuutin sijaan. Tiedostoille kuten logolle se voi kestää jopa päivän.

Miten staattista sivustoa palvellaan

Staattinen sivusto on pelkkiä tiedostoja: HTML-sivuja, JavaScriptiä, CSS:ää ja kuvia. Kun julkaiset sellaisen Mythexissä, rakennamme sen, lataamme tuotoksen objektitallennukseen kansioon sivustollesi ja palvelemme sen reunaverkon kautta. Reunapalvelimet ovat lähellä kävijöitä, hakevat tiedostot tallennuksesta ja säilyttävät kopioita jonkin aikaa. (Jos tämä on sinulle uutta, oppaamme mikä CDN on selittää idean.)

Kaksi asiaa oli pielessä: se järjestys, jossa uudelleenjulkaisu muutti tiedostoja, ja se, kuinka pitkään vanhoja kopioita säilytettiin.

Ongelma 1: lataus tyhjensi sivuston ensin

Uudelleenjulkaisu poisti kaiken sivuston kansiosta ja lataa sitten uuden buildin. Niin kauan kuin lataus kesti (12 sekuntia 250 tiedoston sivustolla paikallisessa testissämme), kävijä, jonka pyyntöä ei ollut jo välimuistissa reunapalvelimella, sai 404-sivun tai HTML-sivun, jonka skriptit palauttivat 404:nä.

Epäonnistunut lataus oli pahempi. Kansio oli jo tyhjä, ja toisella kahdesta latauspolusta uusi index.html saattoi päätyä paikalleen ennen epäonnistunutta tiedostoa. Epäonnistuneeksi ilmoitettu julkaisu saattoi jättää puoliksi uuden sivuston live-tilaan.

Korjaus: kirjoita päälle, sivut viimeisinä, siivoa myöhemmin

1. Älä poista ensin. Uusi build ladataan vanhan päälle.
2. Assetit ennen sivuja. Sivu nimeää skriptit ja tyylit, joita se tarvitsee, joten sivut menevät ylös viimeisinä. Ennen kuin uudet sivut ovat paikallaan, kävijät saavat vanhan sivun, joka nimeää vanhat assetit, ja ne ovat yhä paikallaan. Kun uudet sivut ovat paikallaan, niiden nimeämät uudet assetit ovat jo paikoillaan.
3. Poista jäämät myöhemmin. Ennen latausta listaamme, mistä sivusto koostuu. Kolme minuuttia onnistuneen latauksen jälkeen kaikki tuossa listassa, minkä uusi build ei kirjoittanut uudelleen, poistetaan. Kolme minuuttia on pidempi kuin 60 sekuntia, jonka sivu voi olla välimuistissa reunapalvelimella ja selaimessa, joten vanhaa sivua pitelevä kävijä löytää siihen nimetyt assetit.
4. Jos epäilet, älä poista mitään. Jos listaus ennen latausta epäonnistuu, mitään ei siivota. Ylimääräiset tiedostot ovat vaarattomia, ja seuraava julkaisu poistaa ne. Poistaminen tietämättä, mitä siellä oli, on tapa, jolla sivusto päätyy tyhjäksi.

Epäonnistunut lataus jättää nyt edellisen sivuston täsmälleen ennalleen.

Testasimme tämän päästä päähän paikallisesti käyttäen oikeaa latausskriptiä, oikeaa latausreittiä ja oikeaa tallennuspalvelua, ja kävijöitä, jotka saapuivat kylmällä reunavälimuistilla. Vanhalla koodilla 55 / 91 käynnistä oli rikki uudelleenjulkaisun aikana ja 61 / 92 epäonnistuneen julkaisun aikana. Uudella koodilla 0 oli rikki noin 3 500 käynnin aikana, jotka kattoivat molemmat latauspolut, epäonnistuneen latauksen ja sitä seuranneen julkaisun. Juuri oikeat jäämätiedostot poistettiin.

Ongelma 2: uudelleenjulkaisu näkyi liian hitaasti

Vaikka lataus onnistui, muutokset näkyivät hitaasti. Reunapalvelin säilytti sivun kopiota 60 sekuntia ja kaikkia muita tiedostoja päivän, ja kertoi samaa selaimille. Tiedostot, joilla on kiinteä nimi, kuten logo.png, fontti tai mikä tahansa public/-kansion tiedosto, saattoivat näyttää vanhan version jopa päivän uudelleenjulkaisun jälkeen.

Korjaus: tiedostokopiot buildin alle

Kun reunapalvelin kysyy API:lta, missä sivusto sijaitsee, vastaus sisältää nyt build-tunnisteen, joka muuttuu aina, kun julkaisu menee läpi. Reunapalvelin tallentaa kopionsa tämän tunnisteen alle. Julkaisu muuttuu siis heti uudeksi joukoksi välimuistiavaimia, kun reunapalvelimen 30 sekunnin haku vanhenee. Vanhoja kopioita ei enää löydetä, joten reunapalvelin voi säilyttää kopioita päivän, eikä koskaan palvele niitä ylittäen julkaisun, joka ne korvasi.

Selaimet saavat kaksi eri sääntöä:

• Haskattu build-tuotos, kuten assets/index-CzLcxDO8.js, jonka nimi muuttuu aina kun sisältö muuttuu, säilytetään vuoden ja merkitään muuttumattomaksi. Sen nimellä se ei voi koskaan olla vanhentunut.
• Kaikki muu, eli sivut ja kiinteän nimen tiedostot kuten logo, merkitään no-cache-tilaan, eli "tarkista ennen käyttöä". Jos mitään ei ole muuttunut, vastaus on pieni 304 Not Modified ilman runkoa, nyt kun kunnioitamme selaimen If-None-Match-tarkistusta.

Näiden erottaminen vaatii huolellisuutta: public/assets/-kansiosta kopioitu tiedosto säilyttää oman nimensä, ja assets/logo.png:n välimuistittaminen vuodeksi lukitsisi vanhan logon vuodeksi. Tiedosto lasketaan siis haskatuksi vain, jos se on build-tuotoskansiossa ja sen nimessä on segmentti, joka näyttää tiivisteeltä eikä tavalliselta sanalta.

Paikallisesti uusi sivu ja logo näkyivät 6 sekuntia julkaisun mentyä live-tilaan. Aiemmin sivu näkyi 60 sekunnin ja logo päivän kuluttua.

Kaksi pienempää korjausta matkan varrella

• Tyhjät sivut HEAD-pyynnöistä. HEAD-pyyntö kysyy sivun otsikot ilman runkoa. Välimuistitimme tyhjiä vastauksia, joten seuraava kävijä sai tyhjän sivun. HEAD-vastauksia ei enää välimuisteta.
• Oikea sivu "ei mitään täällä". Osoite ilman sovellusta antoi aiemmin pelkkänä tekstinä viestin "This published app is offline or the link was not found" 502-virhekoodilla. Nyt se saa kunnollisen sivun "Täällä ei ole sovellusta", 404-tilan ja linkin takaisin Mythexiin omistajalle. Tuntemattomat mukautetut domainit saavat saman sivun.

Mitä tästä opimme

• Järjestys kuuluu oikeellisuuteen. Samat tiedostot ladattuna eri järjestyksessä erottavat rikkinäisen sivuston toimivasta.
• Poista myöhään ja vain se, minkä tiedät. Siivoaminen latauksen ennen otetulla listauksella on turvallista. Kansion tyhjentäminen ja toivo, että lataus onnistuu, ei ole.
• Välimuistita versiolla, älä ajalla. Vanhenemisajat ovat arvauksia siitä, milloin sisältö muuttuu. Avain, joka muuttuu buildin mukana, on tosiasia.

Aiheeseen liittyen: julkaistu sovelluksesi pysyy pystyssä, kun julkaiset sen uudelleen. Lisää julkaisusta dokumentaatiossa.