Infrastruktuuri Koodina: Osa 1 - Mistä on kyse?





Julius Rajala

17.2.2021 · 4 min

Infrastructure as code: osa 1 blogibanneri

TL;DR:

Idention Terraform-reseptit löydät täältä.

Me Identiolla halusimme tuoda avoimiksi mielestämme hyviä IaC-ratkaisuja. Tämän blogikirjoituksen kaverina julkaistiin yllä mainittu GitHub-repository, joka sisältää mielestämme hyviä Terraform-moduuleja. Tässä kaksiosaisessa artikkelissa ohjelmistokehittäjämme Julius käsittelee IAC ratkaisujen hyötyjä, sekä yksinkertaisen Terraform-ympäristön pystyttämistä.

Infrastruktuuri Koodina: Osa 1 - Mistä on kyse?

Infrastruktuuri koodina (Infrastructure as Code), eli IaC-ratkaisut ovat viime vuosina levinneet yhä suurempaan käyttöön, mutta vielä toistaiseksi niihin törmää harmittavan harvoin asiakasprojektien parissa. Muutamien Identiolaisten kanssa aiheesta keskusteltuani, päätimme tehdä aiheen lähestymisen mahdollisimman helpoksi. Toivon, että tämä, ja pian julkaistava toinen artikkeli, saavat sinutkin viimeistään tässä vaiheessa harkitsemaan jonkin IaC-ratkaisun käyttöönottoa.

Miksi pilvi-infra kannattaa toteuttaa koodina?

Oikeastaan IaC-ratkaisujen hyödyntäminen kulminoituu kahteen vahvaan pointtiin: versionhallintaan ja replikoitavuuteen.

Versionhallinnan hyötyjä tuskin yksikään ohjelmistokehittäjä kehtaa vuonna 2020 lähteä hirveästi kiistämään. Infrastruktuuriratkaisujen tuominen samoihin tuttuihin versionhallintajärjestelmiin mahdollistaa muutosten helpon seurattavuuden, helpottaa virheiden löytämistä ja kaiken kukkuraksi antaa meille selkeämmän kuvan siitä mitä palveluita ympäristöissämme pyörii. Kun kaikki infra on koodattu, ei pitäisi laskussakaan esiintyä yllätyksiä.

Toinen pointti jää tuskin ensimmäistä paljon huonommaksi. Kaikki isompien pilvitarjoajien työkaluja käyttäneet ovat varmasti joskus uransa alkuaikoina eksyneet palvelukonsoleihin tai käyttäneet ylimääräistä aikaa löytääkseen ne tietyt valikoitavat checkboxit, joiden kanssa saadaan virtuaalitietsikka toimimaan juuri niin kuin halutaan.

IaC-ratkaisut laittavat kehittäjän kirjoittamaan ympäristönsä ylös, jolloin ratkaisu on helpommin uudelleenkäytettävissä. Terraform vieläpä tarjoaa näppärän moduulirakenteen, jonka avulla uuden ympäristön pystytyksestä tulee huomattavasti triviaalimpi keikka. Useamman ympäristön pyörittämisellähän on selkeät hyötynsä. On mukavampaa koeajella uusia ominaisuuksia ensin testiympäristössä, kuin jättää bugien löytäminen asiakkaan tehtäväksi.

Halusin avata tätä maailmaa myös käytännön tasolla ja toisen osan ideana onkin antaa varsin kädestäpitäen ohjeet pilviympäristön pystyttämiseen Hashicorpin Terraformia hyödyntäen. Lähtötasona oletettakoon jonkin verran kokemusta AWS-ympäristöstä ja valmiiksi toimiva AWS-tili.

Tiivistettynä

Vielä kiteytettynä, mitä IaC-ratkaisut antavat ohjelmistoprojektin osapuolille:

Kehittäjälle:

  • Versionhallinnan hyödyt nyt myös pilvi-infrassa
  • Vähemmän AWS-paneelia, enemmän koodia
  • Replikoitavat ympäristöt

Projektinvetäjälle / asiakkaalle:

  • Parempi läpinäkyvyys toteutetun infrastruktuurin suhteen
  • Tiedon siirtäminen kehittäjien välillä helpompaa
  • Replikoitavat ympäristöt

Tässä vaiheessa toivon että kaikki lukijat edes harkitsevat IaC-ratkaisujen hyödyntämistä. Jo olemassa olevan ympäristönkin voi siirtää monille alustoille, eikä kaiken pilvi-infran siirtoa suinkaan tarvitse tehdä kerralla.

Enter Terraform

IaC-ratkaisun valinta on tietysti tärkeää. Tarjolla on vaihtoehtoja AWS:n CloudFormationista JavaScript-pohjaiseen Pulumiin ja useita muita. Viime vuosina vaihtoehtojen määrä on kasvanut, mutta mielestäni yksi on noussut yli muiden. Tällä kertaa tutustumme tähän omaan suosikkiini, Terraformiin.

Terraform from Hashicorp

Muun muassa Vagrantista tutun Hashicorpin kehittämä Terraform on avoimen lähdekoodin ohjelmistoa. Go-kielellä toteutettu Terraform on kehitetty vastaamaan monipilvi-ympäristöjen tarpeisiin. Alustalla on monia miellyttäviä toiminnallisuuksia, mutta listasin tässä niistä muutaman mielestäni olennaisen:

Terraform ei ota kantaa rakennettavaan infrastruktuuriin ja tuettujen pilvialustojen määrä onkin valtava. Täältä voit tarkastaa löytyvätkö omat tarjoajasi Terraformin tarjonnasta. Suuri pilvialustojen määrä puolestaan mahdollistaa Terraformia kirjoittaville kehittäjille paljon laajemman kentän hyödynnettäviä palveluja ja vähentää järjestelmänne liitäntää tiettyyn alustaan.

Terraform-konfiguraatioita kirjoitetaan Hashicorpin HCL-kielellä. Kieli on kokemusteni mukaan herkullisen deklaratiivinen, mutta kuitenkin ekspressiivinen. Pienellä määrällä koodia saat paljon aikaiseksi ja HCL:n deklaratiivinen tyyli ei jätä lukijalleen paljon tulkinnanvaraa. Kielen deklaratiivinen moduulijärjestelmä mahdollistaa lisäksi isojenkin kokonaisuuksien helpon replikoinnin.

Nämä vahvuudet huomioiden keskitymme blogisarjan toisessa puolikkaassa juuri Terraformin hyödyntämiseen. Mainittakoon, ettei IaC-ratkaisuissa kuten muuallakaan, ole yhtä ainutta oikeaa valintaa joka ratkaisee kaikki ongelmat. Tietyissä tilanteissa kannattaa harkita olisiko jokin toinen vaihtoehto vaatimuksiisi osuvampi.

Call to action

Ennen kuin siirrytään konkreettisemman toteutuksen pariin, haastan lukijat miettimään omaa pilviympäristöään.

  • Pysyttekö täysin perillä pilvialustoilla pyörivistä palveluistanne? Onko koskaan tullut vahingossa maksettua jostain ympäristön osasta jonka olemassaolosta ette tienneet?
  • Ovatko infra-muutokset kehittäjiesi keskuudessa kirosana vai onko muutosten tekeminen ja ympäristöjen pystyttäminen helppoa? Kuinka paljon työtä vaatisi esimerkiksi uuden QA-ympäristön pystyttäminen?

Esimerkiksi näihin tilanteisiin IaC ratkaisut tarjoavat helpotusta.

Seuraavassa osassa

Toivon että tämä teksti on antanut sinulle jonkinlaisen kuvan Infrastructure as Code -ratkaisuista. Seuraavassa osassa pystytämme yhdessä kokonaisen Terraform-moduulin, jonkalaista voisit käyttää esimerkiksi Idention nettisivujen hostaamiseen.

Mikäli kiinnostuksesi heräsi ja haluat viedä homman teoriasta käytäntöön, pysy linjoilla toista osaa varten. Julkaisemme sen lähiaikoina.