IaC – Infrastruktuurin hallinta Funidatalla

Mikä IaC?

Perusajatuksena Infrastructure as Code (IaC) konseptissa on nimensä mukaisesti tietojärjestelmän perustana olevan infrastruktuurin tilan ja sen konfiguraation mallintaminen ohjelmakoodina. IaC -koodissa määritellään yleensä deklaratiivisesti halutut resurssit, jotka provisioidaan kohdealustalle sen rajapintaa käyttäen. Rajapinnat ovat erilaisia eri alustoilla, joten IaC -koodi on alustariippuvaista.

Kun infrastruktuuri on määritelty koodina, se voidaan viedä myös versionhallintaan, kuten mikä tahansa muukin ohjelma. Versionhallintaa käytettäessä saadaan pidettyä huoli siitä, että infrastruktuuriin liittyvät muutokset läpikäyvät samanlaisen katselmointiprosessin kuin sovelluskoodi. Katselmoinnissa pyydetään tiimiläinen tai useampi tarkistamaan omat muutosehdotukset läpi ennen kuin muutoksia ajetaan sisään. Katselmoinnissa voidaan pyytää muutoksia ja tarkennuksia tehtyihin valintoihin. Katselmointiprosessi varmistaa, että useampi tiimiläinen ymmärtää tehdyt muutokset, jos niihin myöhemmin tarvitsee tehdä muutoksia sekä tietysti saadaan varmistettua muutosten oikeellisuus useamman silmäparin avulla. Versionhallinta mahdollistaa myös infrastruktuurin kehittämisen atomisissa osissa. Muutosehdotuksia voidaan tehdä pienissä osissa, jolloin riskit virheisiin vähenee sekä implementointivaiheessa että katselmoinnissa. Lopuksi versionhallinta sitoo infrastruktuurin tilan osaksi ohjelman versiointia.

Työkalut pilviresurssien hallintaan

Funidatalla IaCn käyttö on mainittu jo varsin varhaisissa Sisun suunnitteludokumenteissa ja siten se on ollut alusta asti osa Funidatan kulttuuria. Aiempi ajoympäristömme ei tarjonnut tarpeeksi kattavia rajapintoja koneellisille operaatioille IaC:ta varten vaan monia infra-muutoksia tehtiin itsepalveluportaalin kautta tai sähköpostiin tikettinä. Portaalin kautta tehdyt muutokset tapahtuivat automaattisesti, mutta muutoksia pystyi tehdä ainoastaan yksittäiseen palvelimeen kerrallaan. Ne muutokset, joita portaali ei tukenut, täytyi lähettää tikettinä manuaalisesti tehtäväksi. Halusimme siirtää palvelumme ajoon AWS julkipilveen, joka tarjosi meidän toimintatapoihimme sopivat rajapinnat ja kattavan tuen eri IaC -työkaluille. Siirtymisessä pilvipalvelusta toiseen valitsimme AWS:stä sellaiset resurssit, jolla minimoisimme manuaalisen työn tarvetta, mutta säilyttäisimme Dockeriin pohjautuvat ajoympäristöt sekä käytössä olevat ops-palvelut kuten ELK- ja TIG-stackit.

Funidatalla käytetään Terraformia resurssien provisiointiin sekä Ansiblea konfiguraatioiden hallintaan. Terraform ja Ansible valikoitui työkaluiksi, sillä useammalla eri alustalla on vahva tuki näille työkaluille. Funidatan palvelut pyörivät pääosin AWS-ympäristöissä, mutta käytämme soveltuvilta osin Terraformia myös muutamien Azure-resurssiemme hallitsemiseen.

IaC:n tuomat hyödyt

Käytännössä IaC -työkalujen käyttö auttaa pitämään ympäristömme yhdenmukaisina, ja ne mahdollistavat ympäristöjen nopeamman pystyttämisen. Esimerkiksi kun pyöritämme sovelluksistamme useita eri ympäristöjä voimme määritellä yhteiset resurssit ja asetukset kertaalleen yhdessä templatessa sekä eroavat resurssit ja konfiguraatiot toisessa. Tämä helpottaa myös uusien ympäristöjen pystyttämistä merkittävästi. Lisäksi yhteisiä resursseja voi olla palveluiden yli. Esimerkiksi Sisulle luodut hyvät tietoturvakäytänteet infrassa oli triviaalia ottaa käyttöön syksyllä julkaistussa Into-palvelussa. Samaan tapaan käytämme uudelleen resurssien templateja muun muassa sovelluskohtaisten instanssien ja tietokantojen provisioinnissa ja sähköpostien lähetyksessä. Näin saamme hyödynnettyä jo luotua infra-koodia uudelleen uusien palveluiden kohdalla ja mahdolliset muutokset tapahtuvat kaikkiin palveluihin yhdestä paikasta.  

Infrastruktuurin tila on aina kuitenkin vain osittain sidottu IaC:n avulla, mutta mahdollisimman pitkälle muuttumattomaksi tehty tila minimoi riskit odottamattomiin ongelmiin. Esimerkiksi Funidatan IaC -periaatteissa on särö EC2 instanssien järjestelmän pakettipäivitysten kanssa, koska kaikille instansseille asennetuille paketeille ei ole määritelty erikseen versiota Ansiblessa. Tästä syystä testi- ja tuotantoympäristöjen jotkin paketit voivat olla eri versiossa, koska ympäristöjen huoltoikkunat ovat eri aikaan ja paketeista on saatettu julkaista välissä uusia versiota.

IaC saattaa pienten yksittäisten muutosten kohdalla aiheuttaa enemmän työtä kuin niiden tekeminen esimerkiksi käyttöliittymän kautta, johtuen rajapintojen ohjeistuksen puutteellisuudesta tai IaC abstraktion tuomasta kompleksisuudesta. Järkevää onkin miettiä tapauskohtaisesti mihin rajan ad hoc -muutosten ja IaCn välillä vetää.