Jari Laari

Jari Laari

Passionate Software Developer

TwitterLinkedIn

Tuntuuko pilviympäristöjen hallinta karkaavan käsistä ja huomaat viettäväsi liikaa aikaa pilvipalveluntarjoajan hallintakonsolissa? Tai oletko vahingossa aiheuttanut katkon palveluun pilviympäristön päivityksen yhteydessä? Ratkaisu ongelmiisi voi olla Infrastructure as Code.

Infrastructure as Code tarkoittaa lähestymistapaa, jossa määritystiedoston (template) avulla konfiguroidaan ja käynnistetään ohjelmiston tarvitsemat pilvipalvelut. Käynnistettävä palvelu voi olla mikä tahansa pilvipalveluntarjoajan palvelu, esimerkiksi virtuaalikone, virtuaaliverkko, kuormantasaaja tai tietokanta. Vastakohta on toimintatapa, jossa tarvittavat pilvipalvelut konfiguroidaan ja käynnistetään manuaalisesti AWS Management Consolen, Azure Portalin tai Google Cloud Consolen kautta.

Pilviympäristöä voidaan muuttaa määritystiedoston avulla. Pilvipalvelun kehitysprosessin aikana määritystiedostoon voidaan lisätä tai sieltä poistaa palveluita ja päivitykset heijastuvat pilviympäristöön. Työkaluja ovat Cloud Formation (AWS), Azure Resource Manager (Azure), Cloud Deployment Manager (Google Cloud Platform) tai yleispätevä Terraform.

Koska pilvessä toimivat ohjelmistot ovat yhä tiukemmin sidottu pilviympäristöön, tarkoittaa muutokset ohjelmistossa usein myös muutosta pilviympäristössä. Määritystiedostoja käyttämällä pilviympäristön hallittavuus säilyy, riski inhimillisille erehdyksille vähenee ja ohjelmistokehitysprosessin laatu paranee. Kokosin tähän artikkeliin kuusi syytä, miksi sinunkin kannattaa koodata pilviympäristösi.

1. Laatu

Pitkälle automatisoituun julkaisuputkeen (Delivery Pipeline) kuuluu pilvipalvelun määritystiedostojen ajaminen. Yhdessä ohjelmiston julkaisun yhteydessä päivitetään siis myös pilviympäristö, mikäli siihen on tullut muutoksia. Tämä on erityisen kätevää silloin, kun käytössä on erillinen testi- ja tuotantoympäristö. Automaation avulla molemmat ympäristöt saadaan tarvittaessa täysin identtisiksi ja ennen tuotantoon vientiä saadaan viimeistään testiympäristössä varmuus, ettei muutos pilviympäristössä riko ohjelmiston toimintaa.

2. Kustannussäästöt

Ohjelmiston testiympäristössä voidaan käyttää täysin samoja palveluita kuin tuotannossa, mutta esimerkiksi tietokannan koko voidaan testiympäristössä parametrisoida pienemmäksi. Kustannusäästöjä saadaan myös sillä, että testiympäristöt voidaan sammuttaa, kun niitä ei tarvita. Tämän kaiken lisäksi ohjelmistokehittäjien aikaa säästyy, kun heidän ei tarvitse manuaalisesti ylläpitää ja päivittää useampaa pilviympäristöä.

3. Pilviympäristön turvallisuus

Kun ohjelmiston julkaisu ja pilviympäristön konfigurointi on jätetty täysin automatiikalle, ei laaja joukko ylläpitäjiä välttämättä enää tarvitse pääkäyttäjätason oikeuksia pilvipalveluntarjoajan hallintakonsoliin. Tämän ansiosta mahdollisuus tilin kaappaukselle tai inhimilliselle virheelle vähenee, koska kaikki pilviympäristön muokkaustoimenpiteet suoritetaan hallitusti määritystiedoston avulla. Määritystiedostolla konfiguroidaan pilviympäristön pääsyoikeuksia, kuten tietokannan tai virtuaalikoneen pääsynhallintaa. Kun pääsynhallinta on kuvattu määritystiedostossa, voidaan sen turvallisuutta analysoida automaattisten työkalujen avulla.

4. Jäljitettävyys ja läpinäkyvyys

Ohjelmiston toiminta on nykyaikana sidottu vahvasti pilviympäristöön. Muutokset ohjelmakoodissa vaikuttavat pilviympäristöön ja päinvastoin. Kun pilviympäristön infrastruktuurikuvaus on versiohallinnassa yhdessä ohjelmistokoodin kanssa, voidaan pilviarkkitehtuurissa tapahtuneita muutoksia tarkastella ongelmanratkaisun yhteydessä.

Usein pilvikomponenttien välillä on keskinäisiä riippuvuuksia, esimerkiksi tietokannan täytyy olla samassa virtuaaliverkossa sovelluspalvelimien kanssa. Nämä riippuvuudet voidaan kuvata ymmärrettävästi määritystiedostossa. Samalla syntyy siis dokumentaatio pilviympäristöstä ja sen riippuvuuksista.

5. Versiointi

Kun ohjelmisto tarvitsee uuden pilvikomponentin käyttöön, tarvittava lisäys tehdään määritystiedostoon ja muutokset viedään versiohallintaan yhdessä koodimuutosten kanssa. Määritystiedoston avulla ohjelmistokoodi ja sen vaatimat pilvikomponentit siis sidotaan toisiinsa versionhallinnassa. Tämän avulla varmistutaan siitä, että ohjelmistolla on aina automaattisesti tarvittava infrastruktuuri käytössä, kun ohjelmisto julkaistaan.

6. Katselmointi

Laadukkaaseen ohjelmistoprojektiin kuuluu tuotettavan ohjelmistokoodin katselmointi tiimikaverin toimesta. Kun pilviympäristökuvaus ja sen muutokset tallentuvat määritystiedostoon ja versiohallintaan, voidaan pilviympäristössä tapahtuvat muutokset katselmoida ennen niiden suorittamista. Tämä parantaa laatua ja edesauttaa informaation jakamista.

 

Tykkäsitkö artikkelista?

Anna pienet aplodit!

Kommentit

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *