Paikkatietopalvelut konttiin ja pilveen – case Oskari
Pilvimigraatio on osalle organisaatioista arkipäivää, osa on kokeiluvaiheessa, jotkut vielä pohtivat asiaa. Vaikka kovin kuhina ja hype Dockerin ja muiden konttiratkaisuiden päällä on tyyntynyt, ehti “onko siitä Dockeria?” -kysymys vakiintua kielenkäyttöön uusista sovelluksista puhuttaessa.
Olivatpa kontit ja pilvipalvelut lukijalle tuttuja tai eivät, tässä artikkelissa käymme läpi niiden hyötyjä ja niihin liittyvää pohdintaa käyttäen tapausesimerkkinä Oskari-karttapalvelua. Oskarista voit lukea lisää aiemmista blogeistamme tai Oskarin kotisivuilta.
Artikkeli on alunperin julkaistu englanniksi Oskari.orgissa. Gispon Juho Rekilä toimii Oskarin viestintäkoordinaattorina.
Mitä ovat pilvipalvelut? Mitä ovat kontit?
Tunnetuimmat pilvipalvelut tällä hetkellä lienevät Amazonin AWS ja Microsoftin Azure. Ne ylläpitävät asiakkaidensa sinne sijoittamia palveluita ja tarjoavat ylläpitoon liittyviä erilaisia lisäpalveluita.
Pilvimigraatioita voi ajaa tarve pitää julkinen ja valtionhallinnon käyttämä data erillään toisistaan. Nämä kaksi käyttötapausta voidaan erottaa selkeästi käyttämällä julkista pilvipalvelua julkiselle datalle ja toista palvelua sisäiselle datalle.
Pilvipalvelussa ylläpitämisen yhtenä vaihtoehtona on ylläpitää palveluita organisaation omassa konesalissa. Jos organisaatiolla on jo konesali ja siellä tyhjiä palvelimia, palvelut voidaan tietenkin asentaa sinne. Omassa konesalissa palvelut ovat (todennäköisesti) fyysisesti lähellä, ja uuden palvelimen asentaminen voi vaatia manuaalista työtä kaapeleiden ja tietokoneiden kanssa. Pilvialustoilla sama työ voidaan tehdä hiirellä klikkailemalla. Tämä tekee pilvialustoista nopean tavan pystyttää uusia palveluita ja esimerkiksi testata uusinta Oskari-versiota.
Kun palvelua ylläpidetään pilvipalvelussa, organisaatio vastaa ohjelmistosta ja sen päivityksistä, kun taas pilvipalveluntarjoaja varmistaa, että taustalla oleva laitteisto – kuten palvelimet ja fyysiset komponentit – toimivat oikein. Jos taas organisaatiolla on oma konesali, jossa on ongelmia laitteiston kanssa, organisaatio on omillaan.
Konttiteknologia tarkoittaa sovelluksen ja sen kaikkien riippuvuuksien (kirjastot, asennustiedostot jne.) pakkaamista ja eristämistä yhdeksi yksiköksi, jota kutsutaan kontiksi. Konttien luomiseen ja ajamiseen on työkaluja, mm. Docker ja Podman.
Kontit voivat helpottaa ohjelmistojen kehittämistä, testaamista ja käyttöönottoa. Parhaimmillaan kontit tarjoavat yhtenäisen tavan ohjelmistojen pakkaamiseen ja jakamiseen. Kontteja voidaan myös helposti ajaa pilvipalvelussa, ja niitä voidaan ajaa myös omalla tietokoneella. Näistä ominaisuuksista lisää seuraavaksi.

Miksi ajaa Oskaria kontissa?
Oskarissa konttiratkaisun käytön edut verrattuna perinteiseen asennukseen ovat samanlaisia kuin muissa ohjelmistoissa. Tiivistäen voidaan sanoa, että kontit voivat yksinkertaistaa erilaisia prosesseja, jotka liittyvät ohjelmiston asennukseen, kehitykseen ja ylläpitoon.
Jos ohjelmistosta on saatavilla konttiratkaisu, koko ohjelmisto voidaan ladata yhtenä tiedostona (container image). Myös asennusprosessi helpottuu, sillä monimutkaisetkin asennusprosessit voidaan suorittaa yhdellä komennolla.
Kontin käyttö voi helpottaa kehittäjien työtä, jos esimerkiksi kehitystiimillä on yhtenäinen, jaettu konttiratkaisu ohjelmistolle, jota käytetään paikalliseen kehitykseen ja testaukseen. Tuotantokäyttöä varten ohjelmistosta voidaan tehdä erikseen toinen kontti, joka on räätälöity tietylle pilvialustalle. Tämä helpottaa karttapalveluiden ylläpitoa ja käyttöönottoa.
Kontitetun Oskarin käyttö ratkaisee myös ongelmatilanteen, jossa kehittäjän tietokoneella oleva kehitysympäristö ei vastaa tuotantokäytössä olevan Oskarin palvelinympäristöä. Tuotantokäyttöön suunniteltua konttia voi käyttää palvelimen lisäksi myös paikallisesti kehittäjän koneella, jolloin eri ympäristöt ovat yhdenmukaisia keskenään.
Samalle ohjelmistolle voidaan siis luoda erilaisia kontteja: yksi paikalliseen testaukseen ja toinen tuotantokäyttöön – ja eri ympäristöjen yhdemukaisuutta tarvittaessa samaa konttia voidaan ajaa palvelimella ja paikallisesti omalla koneella.
Pilvialustat yleensä pyrkivät tekemään konttien ylläpidosta helppoa, mutta Oskarin käyttö kontissa ei välttämättä tarkoita, että palvelu pitäisi siirtää pilvialustalle. Konttiratkaisu voi silti olla hyödyllinen mm. edellämainituista syistä.
Kannattaako Oskaria ajaa pilvialustalla?
Yksinkertaisimmassa muodossaan Oskarin käyttö pilvialustalla tarkoittaisi palvelun ylläpitoa esimerkiksi Microsoftin Azuressa. Loppukäyttäjä tai palvelun ylläpitäjä ei välttämättä edes huomaa palvelun siirtymistä pilvialustalle.
Palveluita voidaan ylläpitää pilvialustalla, vaikka sitä ei olisi kontitettu. Jos palvelu kuitenkin pyörii kontissa, se voidaan asentaa jaetulle palvelimelle ja palvelun kokonaishinta voi tulla halvemmaksi. Usein kuitenkin asiakas ostaa palvelunsa (kuten Oskarin) käyttöön oman palvelimen.
Kun palvelua käytetään pilvialustalla, saadaan käyttöön myös alustan tarjoamat lukuisat työkalut. Eri pilvialustoilla on erilaisia työkaluja, kuten bugiraportit, jotka helpottavat bugien löytämistä ja korjaamista. Tarvittaessa voidaan luoda erilaisia kontteja, jotka sisältävät Oskarin ja siihen liittyviä palveluita – tai pilvialustan tarjoamia siihen tarjoamia palveluita. Näitä voivat olla esimerkiksi tietoturvatyökalut, Oskariin pääsyä rajoittavat työkalut ja/tai palvelun valvonta.
Erityisesti alustan tarjoamat lisäpalvelut helpottavat usein ylläpitoa. Muun muassa pääsynhallinta on helpompaa, tietokannan ja palveluiden varmuuskopiointia voidaan nopeuttaa, ja saatavilla olevat tietoturvatyökalut yksinkertaistavat tietoturvatilanteen seurantaa. Pilvipalvelut mahdollistavat myös sovellusversioiden ja alustojen nopeamman testauksen, kun uuden palvelun käyttöönotto vaatii lähinnä hiiren napsautuksia verkkoselaimessa.
Valikoiden klikkailu verkkoselaimessa ei kuitenkaan ole ainoa tapa ottaa käyttöön uusia palveluita. Pilvialustoja voidaan hallita myös käyttämällä Infrastructure as Code -työkaluja, kuten Terraformia tai pilvipalveluntarjoajan CLI-työkaluja halutun ympäristön määrittämiseksi.
Tällaisten ohjelmistojen käyttäminen mahdollistaa sen, että voidaan kirjoittaa komentoja/skriptejä, jotka käskevät alustaa luomaan palvelinympäristön, asentamaan sinne valitut kontit ja määrittämään palveluihin liittyviä asetuksia. Samaa skriptiä (joko muuttumattomana tai hieman muokattuna) voidaan sitten käyttää saman palvelun asentamiseen toiseen järjestelmään. Häiriötilanteessa palvelu voidaan tarvittaessa sammuttaa ja skriptin avulla rakentaa nopeasti uudelleen.
Skripti voidaan myös tallentaa versionhallintajärjestelmään, jolloin muutoksia voidaan seurata ja asennusta voidaan toistaa helposti. Tämä on usein yksinkertaisempaa ja luotettavampaa kuin yrittää toistaa jokainen palvelun käyttöönottovaihe selainlomakkeissa kautta.
Jatkopohdintaa
Jos Oskaria tai muuta palvelua aiotaan käyttää pilvialustalla, on otettava huomioon useita asioita. Miten sovelluksen sisäinen verkkoliikenne käsitellään? Mitä resursseja ja lisäpalveluita otetaan käyttöön pilvialustalta? Missä kontit säilytetään? Säilytetäänkö vanhoja versioita, kuinka kauan ja missä? Varmuuskopioidaanko koko tietokantaklusteri ja kuinka usein?
Vaikka pilvialustojen työkalut ovat monella tapaa helpottaneet tietoturvan hallintaa, esimerkiksi AWS:n haavoittuvuuksien lista ei ole välttämättä yksiselitteinen. Jos samassa kontissa on esimerkiksi viisi Oskari-instanssia ja jokaisessa on kaksi tietoturvaongelmaa, kokonaistilanne saattaa näyttää todellisuutta huonommalta (“sinulla on 10 tietoturvaongelmaa!”), ja tilanteesta nopean yleiskuvan saaminen voi olla haastavaa.
Näkymät palvelun käyttöön ja kokonaiskustannukset voivat myös vaikuttaa pilvimigraatioon. Pilvialustoilla on useita erilaisia hinnoittelumalleja, kuten on-demand-malli, jossa palvelun kustannukset määräytyvät käytön mukaan. Lopulliseen hintaan vaikuttavat myös ostetut lisäpalvelut ja käytettävän palvelimen tyyppi. Koska prosessoreita ja muistiyksiköitä on saatavilla kymmeniä, hintaan vaikuttavien muuttujien kokonaismäärä on suuri. Vasta kun palvelu on käynnissä, nähdään siihen valittujen ratkaisujen toimivuus ja onko asetuksia muutettava – mikä voi vaikuttaa palvelun kokonaiskustannuksiin. Tästä syystä lopullista hintaa on vaikea arvioida etukäteen.
Konttiympäristöjen käyttö ja siirtyminen pilvialustoille vaativat myös organisaatiotason linjauksia ja käytäntöjä. Jotkut haluavat siirtää kaikki palvelunsa pilveen, toisilla ei ole vielä vakiintuneita käytäntöjä asian suhteen.
On myös muistettava, että Oskarin tapauksessa ohjelmiston kehittyminen ja päivitykset ovat helpottaneet ohjelmiston sen kehitystyötä ja ylläpitoa kaikilla osa-alueilla – olipa se sitten kontissa tai pilvialustalla tai ei.
