Migreringsguide · Fra Heroku
Migrer fra Heroku til SIAX
Heroku gjorde deploys enkle før noen andre gjorde det, og deler av den enkelheten er fortsatt vanskelig å slå. Det som får team til å flytte, er sjelden teknikken, men økonomien: prisen per dyno, add-ons som hver for seg ser billige ut og til sammen blir en betydelig post, og en plattform som har utviklet seg sakte de siste årene.
Hos oss kjører dere webbprosessen og bakgrunnsprosessene som containere på App Hosting, databasen som Managed Postgres og det som mangler en managed motpart, på en VPS. Månedskostnaden blir forutsigbar, og dere får root-tilgang der dere trenger det.
Det som er vanskelig, er ikke appen, men add-on-økosystemet. Heroku har gjort det enkelt å klikke inn en tjeneste, og de fleste team har flere add-ons enn de husker. Hver av dem må erstattes for seg, og noen har ingen opplagt erstatning. Regn med at den delen tar mer tid enn selve applikasjonsflyttingen.
Tidsbruk
En dag for en app med én webbprosess og én Postgres. En til to uker om dere har fem eller flere add-ons, bakgrunnsjobber og skedulerte kjøringer.
Nedetid
Appen kan flyttes uten avbrudd hvis dere kjører parallelt. Databasen krever et skrivevindu: noen minutter med dump og restore for en liten database, lenger for store. Med logisk replikering kommer dere ned i sekunder.
Slik gjør du det
- 1
Kartlegg dynoer, add-ons og config vars
Kjør heroku ps, heroku addons og heroku config for hver app og lagre utdataene. Noter dynotype og antall per prosesstype, samt hvilken plan hver add-on ligger på. Denne listen er kravspesifikasjonen for det nye miljøet, og den er nesten alltid lengre enn teamet gjetter på.
- 2
Erstatt buildpacken med en Dockerfile
Heroku gjør mye for dere usynlig: installerer avhengigheter, kompilerer assets, setter PORT og starter det som står i Procfile. Alt det skal stå eksplisitt i Dockerfilen deres. Bind til den PORT-en miljøet oppgir, i stedet for en hardkodet port. Alternativt kan dere kjøre Cloud Native Buildpacks med pack CLI hvis dere vil beholde buildpack-modellen en stund til.
- 3
Erstatt hver add-on for seg
Gå gjennom listen post for post. Heroku Postgres blir Managed Postgres. Heroku Data for Redis blir Redis eller Valkey på en VPS, som dere selv oppdaterer og sikkerhetskopierer. Papertrail og lignende logg- og oppetidstjenester erstattes av vår overvåkning for kontroller og en loggmottaker dere velger selv. Utgående e-post via SendGrid byttes mot vår e-posttjeneste eller en ekstern SMTP-leverandør. Add-ons uten en tilsvarende tjeneste må enten beholdes som et frittstående abonnement eller driftes av dere selv.
- 4
Migrer Postgres
Kontroller først hvilke extensions dere faktisk bruker, ikke hvilke som tilfeldigvis er installert. Ta en pg_dump i custom-format og kjør pg_restore mot den nye instansen, og test hele veien mot en kopi før dere rører produksjon. For databaser over noen titalls gigabyte setter dere opp logisk replikering og bytter connection string når replikaet har tatt igjen. Husk at Herokus DATABASE_URL kan roteres, og at sslmode-innstillingen ofte er annerledes.
- 5
Flytt worker-prosesser og skedulerte jobber
Hver prosesstype i Procfile blir en egen kjøring hos oss. Worker-dynoer blir separate containere mot samme kø. Heroku Scheduler erstattes av cron i containeren eller en skedulert CI-jobb. Engangskjøringer dere gjorde med heroku run, trenger en ny rutine, for eksempel et skall i den kjørende containeren eller en manuelt utløst jobb.
- 6
Sett opp deploy og hemmeligheter
Koble repoet til Git og CI, slik at push til main bygger imaget og deployer. Flytt alle config vars til hemmelighetshåndteringen og roter dem i forbindelse med flyttingen, siden de nå har passert en eksport. Verifiser at appen starter med akkurat det settet med variabler dere har tenkt å kjøre i produksjon, ikke en delmengde.
- 7
Kjør parallelt, bytt DNS og avvikle
La Heroku-appen fortsette å ta imot produksjonstrafikk mens det nye miljøet ligger på en staging-adresse. Sammenlign logger, feilrate og svartider i minst ett døgn med reell trafikk. Senk deretter TTL, bytt DNS og hold Heroku i gang noen uker til før dere skalerer ned dynoer til null og avslutter add-ons.
Hva som faktisk er vrient
- Add-ons erstattes ikke med et knappetrykk. Hver tjeneste må evalueres, erstattes og testes for seg, og noen har ingen god erstatning i det hele tatt. Dette er som regel den største posten i tidsplanen.
- Vi har ingen managed Redis som produkt. Trenger dere Redis eller Valkey, kjører dere den på en VPS fra 59 kr per måned, med oppdateringer, minnegrenser og backup på eget ansvar.
- Buildpack-magien er usynlig helt til den forsvinner. Automatisk assetkompilering, PORT-binding og injiserte miljøvariabler slutter å skje av seg selv og må skrives eksplisitt inn i Dockerfilen.
- Heroku startet dynoene deres på nytt daglig. Kode med langsomme minnelekkasjer kan ha vært maskert av den syklusen, og blir synlig først når containeren får leve i uker.
- Review apps og pipelines finnes ikke som en ferdig funksjon. Dere kan bygge noe tilsvarende med branch-deployer i CI, men det er arbeid dere må planlegge inn, ikke en innstilling.
Kostnadseksempel
En app med én webbprosess, én worker, én Postgres, Redis og daglig backup: App Hosting fra 99 kr for webben og 99 kr for workeren, Managed Postgres fra 89 kr, en VPS for Redis fra 59 kr og backup 19 kr for 100 GB, altså rundt 365 kr per måned eksklusive mva. Tilsvarende hos Heroku med to Standard-dynoer, Postgres Standard-0 og en Redis-plan ligger på rundt 1 200 til 1 400 kr per måned til listepris, og prisene endres fortløpende.
Ofte stilte spørsmål
- Kan vi beholde buildpackene våre?
- Ikke direkte, vi kjører containere. Enten skriver dere en Dockerfile, noe vi anbefaler på sikt, eller så bygger dere et OCI-image fra de eksisterende buildpackene med pack CLI. Det andre alternativet forkorter migreringen, men skyver arbeidet foran seg.
- Har dere managed Redis?
- Nei. Redis og Valkey må kjøres på en VPS eller dedikert server. Det blir billigere enn en Heroku-plan, men dere overtar driften: oppdateringer, minnepolicy, persistens og backup.
- Følger Postgres-extensionene våre med?
- De vanlige gjør det, inkludert pg_stat_statements, pgcrypto, uuid-ossp og PostGIS. Uvanlige eller Heroku-spesifikke tillegg må verifiseres før dere planlegger cutover, ikke etterpå. Send listen fra databasen deres, så svarer vi konkret.
- Hva gjør vi med Heroku Connect eller andre add-ons som mangler en erstatning?
- Enten beholder dere tjenesten som et frittstående abonnement hos leverandøren, eller så erstatter dere funksjonen med noe dere selv drifter. Vi later ikke som om alt lar seg flytte rett over, og den vurderingen bør gjøres før dere bestemmer flyttedato.