Terraform vai OpenTofu? Nopeus ei ratkaise, mutta tila voi lukita paluun

Nykyistä Terraform-kantaa ei kannata siirtää OpenTofuun oletetun nopeusedun vuoksi. Siirtymä on perusteltu, jos lisenssi tai OpenTofun ominaisuudet tuovat tiimille selvää hyötyä ja käytössä oleville työnkuluille löytyy toimiva vastine. Päätös on tehtävä kokoonpano ja työtila kerrallaan, koska sama organisaatio voi käyttää Terraformia eri tavoin.

Erityisesti HCP Terraformia käyttävän tiimin on arvioitava komentorivin lisäksi etäajot, tilan säilytys ja käyttöoikeudet. OpenTofun tilasalaus tuo oman paluuehtonsa: Terraform ei voi jatkaa suoraan salatusta tilasta, vaan tila on ensin kirjoitettava takaisin salaamattomaksi OpenTofulla. Siksi palautusta on kokeiltava ennen kuin salaus otetaan käyttöön tuotannossa.

Mitä nopeusmittaus todella kertoo?

TechPlainedin syyskuussa 2026 tekemässä 400 resurssin paikallismittauksessa uuden infrastruktuurin plan kesti Terraformilla 1 505 ja OpenTofulla 1 584 millisekuntia, mutta apply 2 951 ja 906 millisekuntia. Plan-ajat olivat siis lähellä toisiaan, kun taas apply erosi selvästi. Mittauksessa käytettiin paikallisia providereita ilman pilven verkkokutsuja tai etäbackendia; se mittasi työkalujen paikallista työtä, ei tuotannossa tehtävää pilvimuutosta.

Pilviresurssien luonnissa ja päivityksessä kokonaisaikaan vaikuttavat myös palvelun rajapintakutsut, verkko ja tilan lukitus. Paikallisen apply-ajon ero ei siksi kerro, kuinka paljon oman ympäristön muutos nopeutuisi. Jos CI tekee usein muutoksettomia plan-ajoja, niiden kestoa voi verrata omalla kokoonpanolla, samoilla provider-versioilla ja samalla backendillä. Nopeus on silloin mitattava työnkulku, ei yleinen peruste vaihtaa työkalua.

HCP-riippuvuus on laajempi kuin komentovalinta

HashiCorpin versiovertailun mukaan Terraform Community Edition on ilmainen komentorivityökalu. HCP Terraform lisää muun muassa etäajot, versioidun etätilan, roolipohjaiset käyttöoikeudet ja yksityisen moduuli- ja provider-rekisterin. Jos tiimi käyttää näitä palveluja, binäärin vaihtaminen ei siirrä ajohistoriaa, hyväksyntäkäytäntöjä eikä rekisterin sisältöä toiseen ajoympäristöön.

HCP-työtilasta on selvitettävä, mikä käynnistää plan-ajon, missä apply hyväksytään, mistä tunnukset tulevat ja kuka saa lukea tai muuttaa tilaa. Myös moduulien ja providerien jakelutapa kuuluu samaan kartoitukseen. Itse hallitulla etäbackendillä toimivan kannan siirto voi olla rajatumpi, mutta sen CI-skriptit, käyttöoikeudet ja tilan lukitus on silti käytävä läpi. Päätöksen kohde on koko ajoketju, vaikka näkyvin muutos olisi uusi komento.

Milloin lisenssi muuttaa päätöstä?

HashiCorpin BSL-lisenssiä koskeva selvennys sallii Terraformin käytön organisaation sisäisen infrastruktuurin hallintaan ja sisäisen palvelun osana. Rajaus kohdistuu kolmansille osapuolille myytäviin, HashiCorpin kaupallisen tuotteen kanssa kilpaileviin tarjontaan, joissa ohjelmistoa isännöidään tai se sisällytetään tuotteeseen. Sisäisen alustatiimin työtä ei siten pidä rinnastaa automaattisesti ulkoisille asiakkaille myytävään palveluun.

Jos organisaatio rakentaa tällaista asiakastuotetta, lisenssin soveltuminen riippuu tuotteen toteutuksesta ja sopimusehdoista. Muulle tiimille lisenssi voi olla pitkäaikainen hankinta- tai hallintaperuste OpenTofun puolesta, mutta sen hyötyä on verrattava siirrettävien työtilojen, automaation ja tukijärjestelyjen kustannuksiin. Toimivan kannan vaihtamiselle tarvitaan tunnistettu hyöty, ei vain yleinen mieltymys toiseen lisenssimalliin.

Siirtymismatriisi nykyiselle kannalle

Työtiloittainen kartoitus erottaa helposti siirtyvät kokoonpanot niistä, joiden riippuvuudet vaativat uuden toteutuksen. Kirjaa kuhunkin kohtaan nykyinen ratkaisu, OpenTofussa käytettävä vastine ja koe, jolla vastine todetaan toimivaksi.

• HCP ja automaatio: Merkitse etäajot, hyväksynnät, käyttöoikeudet, käytännöt ja CI-käynnistimet. Jos jokin niistä on HCP:n tarjoama, nimeä korvaava palvelu ja sen ylläpitäjä ennen tuotantosiirtoa.
• Tila ja backend: Merkitse tilan sijainti, versiointi, lukitus, varmuuskopiot ja käyttöoikeudet. Selvitä myös, lukevatko muut kokoonpanot saman työtilan tuloksia terraform_remote_state-tietolähteellä; niiden toiminta on kokeiltava erikseen.
• Providerit ja moduulit: Tarkista lähdeosoitteet, lukitut versiot, yksityiset rekisterit ja kokoonpanossa käytetyt ominaisuudet. Yhteinen kokoonpanokieli helpottaa siirtoa, mutta juuri käytetty yhdistelmä on todennettava alustuksella ja plan-ajolla.
• Lisenssi ja hankinta: Erota sisäinen käyttö asiakkaille tarjottavasta palvelusta. Vertaa lisenssi- ja sopimusperustetta siihen työhön, jonka ajoympäristön tai rekisterin vaihto aiheuttaa.
• Palautus: Määritä palautettava tilaversio, tarvittavat avaimet ja se, millä työkalulla palautettu tila luetaan. Kokeile myös, vastaako palautettu tila siirron jälkeen muuttunutta infrastruktuuria.

Tilasalaus tekee paluusta oman siirtonsa

OpenTofun tilasalausohje kuvaa tilan ja tallennettujen plan-tiedostojen salauksen myös etäbackendin kanssa. Ohjeen mukaan salattua tilaa ei voi lukea ilman oikeaa avainta, ja olemassa olevan salaamattoman tilan käyttöönotto vaatii erillisen siirtymäasetuksen. Salaus kannattaa siksi käsitellä omana muutoksenaan sen jälkeen, kun työkalun vaihto on todettu toimivaksi.

Jos Terraformiin halutaan palata salauksen käyttöönoton jälkeen, OpenTofun on ensin luettava nykyinen tila alkuperäisellä salausmenetelmällä ja kirjoitettava se ohjeen mukaisesti salaamattomaksi. Tämä edellyttää toimivaa avainta, pääsyä nykyiseen tilaan ja oikeuksia päivittää sitä. Sen jälkeen on vielä tarkistettava, osaako valittu Terraform-versio käsitellä tilaa ja siirron aikana käyttöön otettuja ominaisuuksia. Salausta edeltävä varmuuskopio auttaa häiriössä, mutta se vanhenee heti, kun infrastruktuuriin tehdään uusia muutoksia.

Tilasalaus vaikuttaa myös kokoonpanoihin, jotka lukevat toisen työtilan tilaa terraform_remote_state-tietolähteellä. Niille voidaan tarvita oma salausmääritys ja pääsy oikeaan avaimeen. Tämä riippuvuus voi jäädä piiloon, jos kokeessa ajetaan plan vain sille työtilalle, jonka tila salataan.

Rinnakkainen plan ennen ensimmäistä muutosta

OpenTofun siirtymäohje suosittelee varmuuskopioimaan koodin ja tilan, alustamaan kokoonpanon uudella työkalulla sekä kokeilemaan ensin pientä muutosta. Rinnakkainen plan-vertailu lisää tähän käytännöllisen tarkistuspisteen: se näyttää, suunnittelevatko työkalut samoille resursseille samoja toimia ennen kuin OpenTofu kirjoittaa tilaan.

1. Tallenna nykyinen kokoonpano, tilaversio, muuttujat ja provider-lukitukset. Rajaa vertailun ajaksi muut tekijät, jotka voisivat muuttaa infrastruktuuria tai tilaa.
2. Alusta työkalut erillisissä työhakemistoissa. Varmista kummallekin tarkoitetut backend-asetukset ja tunnukset; HCP-riippuvaisessa kannassa selvitä ensin, missä OpenTofun vertailuajo voidaan tehdä.
3. Aja planit peräkkäin samaa lähtötilannetta vasten. Vertaa resurssien lisäyksiä, muutoksia, korvauksia ja poistoja sekä virheitä, ei vain tulosteen sanamuotoa tai kestoa.
4. Selvitä odottamattomat erot ennen ensimmäistä OpenTofun apply-ajoa. Kokeile sitten pientä hallittua muutosta ympäristössä, jonka vaikutukset tunnetaan, ja tarkista sen jälkeen tila sekä riippuvaisten kokoonpanojen planit.
5. Harjoittele palautus eristetyllä tilakopiolla. Jos tilasalaus aiotaan ottaa käyttöön, toista koe salatulla tilalla ja sen palauttamisella salaamattomaksi.

Siirtyminen on järkevä valinta, kun tavoiteltu lisenssi- tai ominaisuushyöty on selvä, plan-vertailun erot on ratkaistu ja käytetyille HCP-toiminnoille sekä palautukselle on kokeiltu toimiva toteutus. Jos nämä riippuvuudet ovat yhä auki, nykyisen kannan pitäminen Terraformissa säilyttää tunnetun työnkulun päätöksen ajaksi.

Lue myös:

• Jira vai Linear? Hallintatyö voi ratkaista ennen lisenssihintaa
• ETF vai indeksirahasto? Pieni kuukausisummaa muuttaa kuluedun
• SVOP-sijoitus vai pääomalaina? Palautusjärjestys ratkaisee