Palveluväylä – kehitystä tehokkaasti pilvessä

Blogikirjoituksen aiemmassa osassa kerroin, mitä julkisen palveluväylän suhteen ollaan tekemässä ja miten se kytkeytyy hallitusohjelmaan. Tässä osassa puolestani tuon esille, miten asioita tehdään ja miten ja miksi tämä parantaa yhteiskunnan tuottavuutta ja säästää kustannuksia.

Uudelleenkäyttö

Ensimmäisenä ja ehkä merkittävimpänä asiana nostan uudelleenkäytön. Emme ole keksimässä pyörää uudelleen, emmekä sortumassa Not Invented Here -periaatteeseen, vaan työn pohjana on Virossa kehitetty valmis X-Road ja virolaisten kanssa on selkeästi sovittu periaatteet jatkokehitykselle. X-Road-palveluväylästähän on Virossa pitkä käyttökokemus ja vaikka uusi versio 6 ei siellä vielä olekaan käytössä, voimme kuitenkin luottaa siihen, että periaatteet toimivat myös käytännössä. Aivan ilman työtä Viron X-Roadia ei kuitenkaan saada Suomeen käyttöön, vaan muutoksia on tehtävä mm. erilaisista tietoturvavaatimuksista johtuen. Lisäksi toteutamme uusia ominaisuuksia, liittyen mm. valvontaan. Toteutus tehdään yhdessä virolaisten ja Viron viranomaisten kanssa ja tuottamamme muutokset toimitetaan myös Viroon. Uudelleenkäytön ilmeisenä etuna on tietenkin kustannustehokkuus. Emme ole osa 340 miljoonan ja kymmenen vuoden hanketta, vaan teemme vaaditut asiat olemassa olevan tuotteen päälle, jonka jälkeen se on valmis suomalaisten organisaatioiden käyttöön, tämän vuoden aikana.

Käyttöönoton helppous

Projektimme eräs tavoitteista on tehdä palveluväylän käyttöönotto siihen liittyville organisaatioille mahdollisimman helpoksi. Virossa palveluväylää käyttää yli tuhat organisaatiota ja se on ainoa julkishallinnon tiedonsiirtokanava. Hitausvoimista johtuen Suomessa ei hetkeen saada vastaavaa organisaatiomäärää palveluväylän käyttäjiksi, mutta isompana maana on mahdollista, että Suomessa palveluväylää käyttäviä organisaatioita tulee lopulta olemaan huomattavasti Viroa enemmän. Kuitenkin pienikin vaiva ja viive palveluväylän käyttöönotossa vaikuttaa siihen, kuinka nopeasti palveluväylän käyttö saadaan laajenemaan maassamme tai saadaanko palveluväylän käyttö ylipäätään lanseerattua. Pidän tätä erittäin tärkeänä asiana, koska esimerkiksi aiemmassa projektissani törmäsin siihen, että käyttöpalvelutoimittajan testipalvelimen asennus kesti yli kuusi kuukautta. Jos toimintavauhti on samaa luokkaa kuin tässä ala-arvoisessa tapauksessa, palveluväylä tai mikään muukaan asia ei ikinä lyö itseään läpi.

Saattaa olla, että joissakin tapauksessa julkishallinnon organisaatio asiakkaana ei tiedä kuinka kauan kunkin palvelimen asennus pitäisi kestää ja siksi monopoliasemassa oleva käyttöpalvelutoimittaja voi tehdä mitä vaan. Palveluväylän tapauksessa yritämme pitää huolen siitä, että palveluväylään liittyminen ei ole ainakaan tiedon puutteesta kiinni. Kärjistetysti voisin sanoa, että ei saa käydä niin, että toimittaja laskuttaa parin tunnin työstä kuukausien työn hinnan. Tai jos niin käy, niin se johtuu muista syistä kuin tiedon puutteesta. Sanotaan, että tieto lisää tuskaa, mutta eiköhän tämä ole kuitenkin vain hyvä uutinen kaikille palveluväylän käyttäjille.

Vaikka palveluväylään liittyminen jo nykyisellään on helppoa, pyrimme sujuvoittamaan tätä prosessia niin paljon kuin mahdollista. Viron Ubuntu-serveriasennuksen lisäksi Suomessa on alustavaihtoehtona RedHat. RHEL 7 tuki ja RPM-paketointi onkin yksi niistä asioista, jotka olemme projektissa toteuttaneet. Tämän lisäksi päätimme helpottaa palveluväylän käyttöönottoa vielä lisää.

Toteutimme eri alustoille (VMWare, VirtualBox, AWS AMI) valmiit virtuaalikoneimaget, jotka tarjotaan virallisten deb ja rpm asennuspakettien rinnalla. Helpoimmillaan siis palveluväylän liityntäpalvelimen saa käyttöönsä avaamalla VirtualBoxiin tai VMWareen xroad-securityserver-fi -imagen tai käynnistämällä AWS:ssä uuden EC2-instanssin vastaavan AMIn pohjalta. Tämän jälkeen organisaation tehtäväksi jää vai pakolliset sertifikaattien hankinta ja salasanojen vaihto.

Virtuaalikoneimaget tuotetaan automaattisesti Packer-työkalulla. Seuraavassa koodilohkossa on esitetty Packerin käyttämä AWS EC2 -builder, jonka avulla luodaan uusi AMI eu-west-1 -regioniin (Irlanti) käyttäen pohjana standardia Ubuntu 14.04 -image.

Vastaava builder on tehty VirtualBoxille (ovf) on esitetty alla. Tämä asentaa standardin Ubuntu 14.04 -iso imagen virtuaalikoneeseen ilman käyttäjän interaktiota.

Asennuksen jälkeen käyttöjärjestelmä provisioidaan. Provisiointi on hyvin samantapainen alustasta riippumatta.

Ainoa X-Road-spesifinen kohta provisioinnissa ja koko proesssissa on securityserver.sh-scripti, jonka sisältö on seuraava:
Tässä tehdään automaattisesti sama, jonka liityntäpalvelimen asentaja tekisi muuten käsin. Huomattavaa on, että tässä vaiheessa käytetään yksityistä X-Road-repositoriota, joka tietenkin tulee muuttumaan myöhemmin julkiseksi repositorioksi. Debconf-asetuksilla ei ole xroad-käyttäjänimeä lukuun ottamatta merkitystä, koska ne asetetaan uusiksi siinä vaiheessa kun virtuaalikone käynnistetään imagesta ensimmäisen kerran.

Resurssien kustannustehokas käyttö

Kustannustehokkuus näkyy projektissamme myös joustavana palvelinresurssien käyttönä. Tarvitsemme kehitys- ja testitarkoituksiin reilun tusinan verran palvelimia. Meillä on keskuspalvelin, ja useita liityntäpalvelimia, jotka vastaavat tosimaailman eri organisaatioiden liityntäpalvelimia eri käyttöjärjestelmissä (Ubuntu ja RedHat) ja palvelimia, jotka pyörittävät testiorganisaatioiden tietopalveluja. Lisäksi on kehitystä tukevia palvelimia, mm. CI-palvelin ja hyppykone. Tarvittaessa ajamme automaattisesti ylös uuden setin keskus- ja liityntäpalvelimia. On selvää, että työstä ei tulisi mitään, jos jokainen palvelinasennus vaatisi yhteydenottoa käyttöpalvelutoimittajaan ja pahimmassa tapauksessa pitkää odotusaikaa. Parhaassakin tapauksessa projektin kesto ja kustannukset moninkertaistuisivat. Ainoa järkevä malli tämäntyyppiseen kehitystyöhön onkin käyttää pilvi-infraa, josta kehitystiimi saa palvelimia välittömästi tarpeen tullessa ja jonne asiat voi täysin automatisoida. Valintamme on ollut AWS ja CloudFormation on ahkerassa käytössä. Suuresta palvelinmäärästä huolimatta infrakustannukset ovat pienet. Tähän menessä kalleimpana kuukautena infra kokonaisuudessaan on maksanut vain 160 euroa. Kustannustehokkuuteen on päästy myös sillä, että tarpeettomat palvelimet ajetaan automaattisesti alas yön ja viikonlopun ajaksi.

Vastaa

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

Liity joukkoon

Backend-kehittäjä

Helsinki, Jyväskylä, Tampere

Frontend-kehittäjä

Helsinki, Jyväskylä, Tampere