Migraatio-opas · Vercel:sta
Siirry Vercelistä SIAXiin
Vercel on rakennettu nopeaan alkuun, ja siinä se onnistuu hyvin. Kipu tulee myöhemmin: tiimin käyttäjäpaikkakohtainen hinnoittelu, kaistanleveyslaskutus jota on vaikea ennakoida ennen kuun loppua, funktiokutsut jotka laskutetaan kappalehintaan, ja alusta jossa et voi tarkastaa miten mikään on rakennettu etkä siirtää sitä ilman sovelluksen osien uudelleenkirjoittamista.
Meillä ajat saman sovelluksen konttina App Hostingissa, kiinteällä kuukausihinnalla, ja tietokannan johon voit yhdistää psql:llä. Kaikki on konepellin alla avointa lähdekoodia ja kaikki data sijaitsee EU:ssa. Et sen sijaan saa Vercelin globaalia edge-verkkoa. Se kannattaa sanoa suoraan: jos yleisönne on Kaakkois-Aasiassa ja mittaatte TTFB:tä kymmenissä millisekunneissa, emme ole oikea valinta.
Opas lähtee liikkeelle Next.js-sovelluksesta, koska se on yleisin tapaus. Malli on sama Remixille, Astrolle, SvelteKitille ja Nuxtille. Ero on siinä, kuinka paljon Vercelin alustaominaisuuksia olette päästäneet hiipimään koodiin.
Ajankäyttö
Puoli päivää sovellukselle joka on vain sovellus. Yhdestä kahteen viikkoa, jos nojaatte ISR:ään, Edge Middlewareen, Vercel Blobiin tai KV:hen.
Käyttökatko
Ei käyttökatkoa sovellukselle, jos ajat rinnakkain DNS-vaihdon ajan. Tietokannan siirto vaatii kirjoitusseisokin: muutamia minuutteja pienelle tietokannalle, pidempään jos ette ota käyttöön loogista replikointia.
Näin teet sen
- 1
Kartoita mitä Verceliltä oikeasti käytätte
Etsi koodista kaikki mikä on saatavilla vain Vercelillä: Edge Middleware, runtime = edge, request.geo, waitUntil, ISR:n on-demand-revalidointi, Vercel Cron, Blob, KV ja Postgres. Kirjaa jokainen osuma ylös. Tuo lista on koko migraation vaikeusaste; loppu on rutiinia. Nolla osumaa tarkoittaa parin tunnin työtä.
- 2
Rakenna sovellus kontiksi
Aseta output arvoon standalone next.configissa ja kirjoita kaksivaiheinen Dockerfile: rakenna devDependencies mukana, aja kevyellä node-alpine-imagella. Varmista että sovellus käynnistyy lokaalisti samoilla ympäristömuuttujilla kuin tuotannossa. Tarkista että sharp on mukana jos käytätte next/imagea, muuten kuvanoptimointi kaatuu maksuttoman CPU:n varaan jokaisella kylmäkäynnistyksellä.
- 3
Korvaa Vercel-spesifiset ominaisuudet
Edge Middleware ajetaan meillä tavallisena Node-middlewarena sovelluksessa, ei edgellä. Vercelin geo- ja IP-kentät eivät ole olemassa ja ne pitää korvata headereilla proxyltamme tai itse ylläpidetyllä GeoIP-tietokannalla. Vercel Cron korvataan ajastetulla työllä CI:ssä tai cronilla kontissa. Blob vaihdetaan objektitallennukseemme S3-rajapinnan kautta, mikä on aito koodimuutos eikä pelkkä konfigurointirivi.
- 4
Siirrä tietokanta ja tallennus
Provisioi Managed Postgres ja aja pg_dump, jota seuraa pg_restore uuteen instanssiin. Varmista että kaikki extensionit ovat olemassa ennen aloittamista, ei jälkikäteen. Suuremmille tietokannoille otatte käyttöön loogisen replikoinnin, annatte sen saavuttaa lähteen ja vaihdatte sitten connection stringin lyhyen kirjoitusseisokin aikana. Vercel Blobin tiedostot kopioidaan rclonella S3-endpointtiimme.
- 5
Pystytä build ja deploy
Yhdistä repo Gitiin ja CI:hen ja anna putken rakentaa image ja deployata, kun pushaatte mainiin. Laita kaikki ympäristömuuttujat salaisuuksienhallintaan, ei koskaan imageen. Käytä tilaisuutta hyväksi ja kierrätä avaimet, jotka olivat Vercelin projektiasetuksissa, koska viette ne joka tapauksessa ulos.
- 6
Aja rinnakkain ja vertaile
Anna uuden ympäristön olla staging-aliverkkotunnuksen takana, kun Vercel edelleen ottaa vastaan tuotantoliikennettä. Vertaa vasteaikoja, cache-headereita, uudelleenohjauksia ja 404-käyttäytymistä sivu sivulta. Tarkista erityisesti että sivut, joiden luulitte olevan staattisia, todella renderöityvät staattisesti, ja ettei välimuisti tyhjene jokaisella deployllä.
- 7
Vaihda DNS ja aja alas
Laske TTL 60 sekuntiin vuorokausi etukäteen, vaihda sitten A- tai CNAME-tietue. Pidä Vercel-projekti käynnissä pari viikkoa varajärjestelmänä ja mahdollisten kovakoodattujen vercel.app-URL-osoitteiden kiinniottamiseksi. Vasta sitten lopetatte tilauksen.
Mikä on todella hankalaa
- ISR toimii itseisännöitynä, mutta välimuisti on instanssikohtainen. Jos ajatte useampaa kuin yhtä instanssia, käyttäjät saavat eri versioita samasta sivusta kunnes osoitatte jaetun cache-handlerin Next.jsissä. Helpoin tapa on aluksi yksi instanssi.
- Edge Middlewaresta tulee Node-middleware. Latenssiprofiili muuttuu, ja kaikki mikä nojasi Vercelin geo- tai maakenttiin pitää korvata tai poistaa.
- Esikatselut per commit eivät ole valmiina. Saatte prod-, staging- ja dev-ympäristöt ja voitte rakentaa branch-deployt CI:hen, mutta uniikin URL:n per pull request joudutte pystyttämään itse.
- Vercel KV:llä ei ole vastinetta meillä. Jos tarvitsette avain-arvo-välimuistin, ajatte Redistä tai Valkeytä VPS:llä ja omistatte silloin päivitykset ja varmuuskopioinnin itse.
- Verkkomme on EU-alueellinen, ei globaali. Pohjoismaiselle tai eurooppalaiselle yleisölle ero on marginaalinen. Globaalille yleisölle tiukoilla latenssivaatimuksilla se ei ole.
Kustannusesimerkki
Pieni tuotantosovellus stagingin, yhden Postgresin ja 100 Gt tiedostojen kanssa: App Hosting alkaen 99 kr, staging-ympäristö 49 kr, Managed Postgres alkaen 89 kr ja objektitallennus 25 kr, eli noin 262 kr kuukaudessa ilman alv:tä. Suuremmat instanssit maksavat enemmän. Vastaava Vercelillä kolmella kehittäjällä Pro-tasolla plus managed Postgres asettuu noin 1 000–1 500 kr:oon kuukaudessa ennen kaistanleveys- ja funktioylityksiä, ja heidän hintansa muuttuvat jatkuvasti.
Usein kysytyt kysymykset
- Toimiiko Next.js täysin teillä?
- Kyllä, Node-tilassa standalone-outputilla. Se mikä ei tule mukana on ympärillä olevat alustaominaisuudet: edge runtime, Vercelin geo-headerit, Blob, KV ja Cron. Sovellus toimii, mutta nuo kutsut pitää kirjoittaa uudelleen.
- Onko teillä CDN sovelluksen edessä?
- Välimuistamme staattiset resurssit ja voimme laittaa välimuistin sivujen eteen, mutta meillä ei ole satoja PoP-pisteitä ympäri maailmaa. Alueemme ovat Helsinki, Falkenstein ja Nürnberg. Pohjoismaisille kävijöille latenssi on verrattavissa Verceliin; Aasian tai Etelä-Amerikan kävijöille ei.
- Oletteko ISO 27001- tai SOC 2 -sertifioituja?
- Ei. Meillä ei ole ISO 27001:tä eikä SOC 2:ta. Meillä on GDPR-vaatimustenmukaisuus, henkilötietojen käsittelysopimukset, kaikki data EU:ssa ja avoimeen lähdekoodiin perustuva pino, jonka voitte tarkastaa. Jos asiakassopimuksenne vaatii sertifiointia, se on todellinen este, ja sanomme sen mieluummin suoraan.
- Mitä tapahtuu, jos haluamme takaisin?
- Sovellus on kontti ja tietokanta on tavallinen Postgres. Otatte dumpin ja jatkatte muualla. Se on käytännön seuraus siitä, ettemme rakenna omia suljettuja primitiivejä.