Michael JohnsonJulkaisun jälkeen aktiivinen Cloudflare Durable Object voi nyt jatkaa toimintaansa nykyisellä koodiversiolla, kunnes se siirtyy horrostilaan tai asetettu määräaika umpeutuu. Cloudflare otti 30. lokakuuta käyttöön oletusarvoisen lykätyn päivityksen, jonka enimmäisviive on viisi minuuttia. Kehittäjien kannalta tämä muuttaa käynnissä olevien objektien toimintaa käyttöönoton aikana: päivityksen ei tarvitse keskeyttää niitä heti, ja tuetut WebSocket-yhteydet voivat säilyä siirryttäessä uuteen versioon.
Mitä käyttöönoton aikana tapahtuu
Durable Objects -objektit ovat osoitteellisia objekteja, joilla on pysyvä identiteetti ja tila. Cloudflare käyttää niitä muun muassa asiakkaiden koordinointiin, pitkäkestoisiin tehtäviin ja WebSocket-istuntoihin. Yhdellä objektilla on kerrallaan käytössä yksi koodiversio. Siksi aktiivinen instanssi voi välittömässä vaihdossa käynnistyä uudelleen ja keskeyttää työn tai yhteydet.
Oletusarvoisesti siirtyminen tapahtuu nyt viiveellä. Käyttöönoton jälkeen aktiivinen objekti jatkaa pyyntöjen käsittelyä vanhalla versiolla. Jos se ehtii siirtyä horrostilaan tätä ennen, uusi versio käynnistyy seuraavan yhteydenoton yhteydessä. Jos viisi minuuttia kuluu ja objekti on yhä aktiivinen, se käynnistetään uudelleen ja ottaa uuden version käyttöön. Worker-julkaisu valmistuu tästä erillään: viive koskee sitä, milloin jo aktiivinen objekti alkaa suorittaa uutta koodia.
Kenelle tästä on hyötyä
Muutos on tärkeä palveluille, joissa yksi objekti ylläpitää toimintaa pyyntöjen välillä, kuten pitkäkestoisessa istunnossa, useiden asiakkaiden koordinoinnissa tai WebSocket-yhteydessä. Viivästetty siirtymä antaa tällaiselle objektille mahdollisuuden saattaa käynnissä oleva toimintansa luonnollisesti päätökseen tai siirtyä lepotilaan ennen päivitystä. WebSocket-yhteyksien osalta Cloudflare mainitsee erillisen ehdon: Hibernation APIa käyttävät yhteydet pysyvät muodostettuina, kun objekti ottaa uuden koodin käyttöön horrostilasta herättyään.
Käytännössä tiimin kannattaa selvittää, mitkä aktiiviset objektit voivat pysyä varattuina yli muutaman minuutin ja mitä WebSocket-APIa ne käyttävät. Näistä riippuu, antaako uusi käyttöönottotapa sovellukselle mahdollisuuden hallittuun siirtymään vai katkeaako yhteys pakotetun päivityksen yhteydessä.
Viisi minuuttia on aikaikkuna, ei takuu
Cloudflare kuvaa lykättyä päivitystä best effort -toiminnoksi: objekti voi käynnistyä uudelleen aiemmin, esimerkiksi suoritusympäristön päivityksen vuoksi. Jos se ei ole siirtynyt horrostilaan enimmäisviiveen päättyessä, alusta ottaa uuden version käyttöön käynnistämällä objektin uudelleen. Siksi tärkeä tila kannattaa tallentaa pysyvään tallennustilaan ja toiminnot suunnitella niin, että ne voidaan tarvittaessa käynnistää uudelleen. Cloudflaren dokumentaatio suosittelee tallentamaan käyttöönotot kestäväksi tarkoitetun tilan sen sijaan, että luotettaisiin aktiivisen instanssin muistiin.
Tiimit voivat ohittaa Durable Objectsin oletustoiminnan asetuksissa: päivitystilan voi määrittää välittömäksi tai lykätylle siirtymälle voi valita toisen määräajan. Välitön tila sopii tilanteisiin, joissa uusi versio on otettava käyttöön heti, esimerkiksi kiireellisen korjauksen vuoksi. Pidempi viive voi antaa objekteille lisää aikaa, mutta samalla se pidentää jaksoa, jonka aikana osa instansseista käyttää vanhaa versiota.
Mitä kannattaa tarkistaa ennen seuraavaa käyttöönottoa
Tarkista Workerin ja Durable Objectsin pyyntöjen yhteensopivuus siltä varalta, että ne toimivat eri versioilla. Varmista, että kriittinen tila tallennetaan pysyvään tallennustilaan eikä vain muistiin. Selvitä WebSocket-yhteyksien osalta, käyttääkö sovellus Hibernation APIa: tavalliset yhteydet voivat katketa päivityksen käyttöönoton yhteydessä. Jos käyttöönotto edellyttää välitöntä siirtymää, tarkista tilan asetus erikseen sen sijaan, että luottaisit uuteen oletusarvoon.
Cloudflare muutti näin käyttöönoton oletusarvoista kompromissia: aktiivisille objekteille annetaan rajallinen aika siirtyä luontevasti, ja tiimit voivat edelleen nopeuttaa päivitystä asetuksella. Kehittäjän kannalta hyödyllisintä on tarkistaa vanhan ja uuden version yhteensopivuus, tilan säilyminen ja WebSocket-yhteyden tyyppi ennen seuraavaa käyttöönottoa.
