Sovelluskehityksen siirtyessä yhä useammin mikropalveluihin ja konttiteknologioihin, myös erilaiset pilvipalvelualustat ovat yleistyneet ja ovatkin nykyään useasti osana sovelluskehitystä. Me Ambientialla olemme ottaneet käyttöön RedHatin Openshiftin. Tämä teksti aloittaa Openshift-aiheisen lyhyen blogisarjan, jossa pureudutaan Openshiftin käyttöön sovelluskehittäjän näkökulmasta.

Perusteet tutuksi

Openshift perustuu Kubernetesin orkestrointiin ja Dockeriin. Perusperiaatteisiin kuuluu jakaa sovelluksen osat kontteihin (containers), jotka ovat helposti monistettavia ja kertakäyttöisiä. Tämä mahdollistaa esimerkiksi sovelluksen skaalaamisen, kun samanlaisia kontteja voidaan luoda useita tarpeen mukaan ja jakaa käyttäjien aiheuttamaa kuormaa niiden kesken. Toisaalta resurssit säästyvät, kun turhaan ajossa olevat kontit voidaan ajaa alas. Kehittäjä määrittelee tarvittavat riippuvuudet ja sovelluksen osat käännösvaiheen konfiguraatiossa (buildConfig), joiden perusteella luodaan Docker-perustainen image pohjaksi containerille. Sovellus voi sisältää useita kontteja, esimerkiksi tietokanta ja sovelluksen käyttöliittymä, joita ajetaan podeissa ja joiden tulisi pystyä kommunikoimaan sisäisesti keskenään. Tähän tarkoitukseen määritellään serviceitä. Ulkopuolisiin yhteyksiin, esimerkiksi web-sivun osoitteita varten, luodaan reittejä (routes). Konttien vieminen ajoon määritellään deploymentConfigin avulla. Lisää Openshiftin peruskäsitteistä ja arkkitehtuurista voit lukea täältä.

Sovelluskehityksessä on olennaista ottaa huomioon konttiteknologioiden käyttämä rakenne ja konseptit. Esimerkiksi konttien kertakäyttöisyys tarkoittaa, että sovelluksen pysyvä data tulee säilöä jonnekin, ja mahdollisesti jakaa usean instanssin kesken. Myös Openshiftin käyttämät prosessit vaikuttavat olennaisesti siihen, kuinka sovellusta kannatta lähteä toteuttamaan juuri Openshiftiin. Kun haluat toteuttaa sovelluksesi Openshiftiin, kannattaa tutustua näihin omakohtaisiin vinkkeihini ja kokemuksiini siitä, kuinka Openshiftin kanssa kannattaa edetä, mitä asioita pitää ottaa huomioon ja kuinka saada parhaat hyödyt irti kehittäjän näkökulmasta.

Parhaat käytännöt konfiguraatioihin  ja ajoympäristöjen hallintaan

Openshiftin kanssa alkuun pääsee hyvin monella eri tapaa. Valmiita esimerkkejä ja pohjia asetuksista löytyy ja sellaisen voi käynnistää ajoon Openshiftiin napin painalluksella tai yhdellä komentorivikäskyllä. Omiin tarpeisiin ajoympäristöä voi muokata Openshiftin tarjoamasta web-pohjaisesta käyttöliittymästä tai yaml/json-pohjaisista konfiguraatioista. Tarvittavia elementtejä (kuten buildConfig, service, route, deploymentConfig) voi lisätä yksitellen tai sitten lähteä alun perin tekemään kokonaista mallipohjaa, (template). Kun toteutus on edennyt haluttuun suuntaan ja Openshift-projekti alkaa hahmottua, kannattaa viimeistään tässä vaiheessa luoda omasta projektista template. Tämän avulla ympäristö tulee säilöttyä talteen esimerkiksi versionhallintaan, eikä vaivalla koottu ja hiottu ympäristö pääse hukkumaan vahingossakaan. Template-pohjaa on myös helppo käyttää eri ympäristöjen (kehitysympäristö, testausympäristö, tuotantoympäristö jne.) pystyttämiseen sekä ympäristön monistamiseen. Lisäksi template:n avulla on helppo jakaa työnsä tuotokset esimerkiksi niiden tiimien ja kehittäjien kesken, jotka aloittavat vastaavien teknologioiden parissa.

Sovelluksen skaalaus (auto-scaling) ja uudelleenasennus (re-deployment) kannattaa myös ottaa huomioon jo aivan projektin alkuvaiheessa, vaikka näitä ei heti toteuttaisikaan lopulliseen muotoonsa. Kumpikin ominaisuus nimittäin vaikuttavat siihen, ajetaanko sovelluksesta useita instansseja eli podeja yhtäaikaisesti vai aina erikseen. Esimerkiksi pysyvä levyosio (peristent volume) täytyy määritellä jo luontivaiheessa soveltumaan joko jaettuun tai yhden podin käyttöön. Mikäli levyjako ei tue jaettua käyttöä ja rolling-tyyppinen asennus halutaan ottaa käyttöön, joutuu levyosion luomaan myöhemmin uudelleen. Asennusstrategialla onkin suuri merkitys siihen, pysyykö sovellus koko ajan ajossa uutta podia luodessa ja kuinka hyvin skaalaus toimii. Recreate-strategiassa edellinen instanssi ensin pysäytetään ja vasta sen jälkeen käynnistyy uusi. Tällöin käyttökatkos on pidempi kuin rolling-strategiassa, jossa uusi instanssi käynnistetään taustalla pystyyn ja otetaan mukaan kuormanjakoon vasta sitten, kun se on jo kokonaan toiminnassa. Podin käyttötarkoitus määritteleekin sen, mitä strategiaa kannattaa noudattaa: rolling-strategia sopii skaalattaviin podeihin kun taas esimerkiksi tietokantapodeja ei ole hyvä asentaa rolling-strategialla, jolloin pysyvää levyosiota ja tietokannan dataa saattaisi kirjoittaa useampi instanssi yhtäaikaisesti.

Kehitysympäristön automaatiolla kohti jatkuvaa integraatiota

Openshift perustuu kehitys- ja ajoympäristön automatisoituun pystyttämiseen ja tukee luonnollisesti jatkuvaa integraatiota (continuous integration/continuous delivery). Esimerkiksi käännösvaihe (build) ja asennusvaihe (deployment) on eroteltu, joten jatkuvaa integraatiota kääntämisen, testaamisen ja asennuksen suhteen on helppo hyödyntää. Täten myös Openshiftissä ajettavaa projektia suunniteltaessa kannattaa ajoissa ottaa huomioon CI/CD-prosessit.

Mieti esimerkiksi:

  • Miten sovellus käännetään?
  • Mitä työkaluja halutaan käyttää (esimerkiksi Jenkins/Bamboo/Openshiftin oma käännösstrategia source-to-image)?
  • Kuinka koodi testataan?
  • Miten sovellus viedään eri testivaiheisiin ajoon ja siitä lopulta tuotantoon?
  • Kuinka hallita ja toteuttaa esimerkiksi sovelluksen tarvitsemia ympäristöön sidottuja asetuksia tai ympäristömuuttujia?

Jaoin ohessa vinkkejä Openshiftin käytöstä osana sovelluskehitystä etenkin projektin kokonaisuuteen liittyen. Seuraavassa blogikirjoituksessa keskityn Openshift-toteutukseen tietyn teknologian näkökulmasta: mitä kannattaa ottaa huomioon Openshiftissä, kun sovellus on toteutettu WordPressillä.

ambientia

Blogi