DevOps konsultin työtehtäviä ohjelmistoyrityksessä

(1)

DevOps konsultin työtehtäviä ohjelmistoyrityksessä

Petrus Manner

Haaga-Helia ammattikorkeakoulu Amk-opinnäytetyö

2021

Tietojenkäsittelyn tutkinto

(2)

Tiivistelmä

Tekijä(t) Petrus Manner Tutkinto Tradenomi

Raportin/Opinnäytetyön nimi

DevOps konsultin työtehtäviä ohjelmistoyrityksessä Sivu- ja liitesivumäärä

63 + 1

Tässä portfoliomaisessa päiväkirjatyössä seurataan DevOps-konsultin arkea Suomalai- sessa keskisuuressa ohjelmistoyrityksessä. Työ koostuu kirjoittajan oman työn lähtötilan- teen kuvauksesta, kymmenestä seurantaviikosta, sekä loppupohdinnoista. Seurantaviikot sijoittuvat ajalle 30.08.2021–12.11.2021. Seurantaviikkojen aikana päiväkirjamerkintöjä tehtiin päivittäin. Jokaisen seurantaviikon lopussa on viikkoanalyysi, jossa käydään läpi menneen viikon työtehtäviä, sekä niitä yhdistäneitä teemoja.

Päiväkirjamerkinnöissä on pyritty tuomaan esille mahdollisimman laaja kirjo erilaisia De- vOps-roolille ominaisia tehtäviä, ja raportoinnissa on keskitytty korostamaan uniikkeja, tai muuten mielenkiintoisina pidettyjä työtehtäviä. Viikkoanalyysit on luotu etsimällä kuluneella viikolla kulloinkin suoritettuja työtehtäviä yhdistävä teema, jonka pohjalta kirjoittajan ammatillista osaamista on analysoitu.

Päiväkirjatyön seurantaviikkojen aikana tehtyjen merkintöjen ja analyysien pohjalta on muodostettu loppupohdinta. Loppupohdinnan avulla käydään läpi kirjoittajan ammattiosaa- misen kasvua päiväkirjatyön seurantajaksojen aikana, sekä mietitään päiväkirjatyön hyö- tyjä sekä jatkokehitysmahdollisuuksia.

Asiasanat

Konsultointi, pilvipalvelut, järjestelmänhallinta, www

(3)

Sisällys

1 Johdanto ... 1

2 Lähtötilanteen kuvaus ... 2

2.1 Oman nykyisen työn analyysi ... 2

2.2 Sidosryhmät työpaikalla ... 4

2.3 Vuorovaikutus työpaikalla ... 5

3 Päiväkirjaraportointi ... 6

3.1 Seurantaviikko 1 ... 6

4 Pohdinta ja päätelmät... 60

Lähteet ... 62

Liitteet ... 64

(4)

1 Johdanto

Tässä päiväkirjamuotoisessa opinnäytetyössä seurataan DevOps-konsultin arkea ja työ- tehtäviä keskisuuressa ohjelmistotalossa. Työ koostuu johdannosta ja lähtötilanteen kuvauksesta, kymmenestä seurantaviikosta ja niiden pohjalta tehdyistä analyyseistä, sekä lopputilanteen arvioinnista ja pohdinnasta. Seurantaviikkojen aikana raportoidaan päivit- täin työpäivän keskeisimmät tehtävät ja muu sisältö. Lisäksi jokaisesta seurantaviikosta kirjoitetaan erillinen analyysi.

Opinnäytetyön kirjoittaminen ja seurantaviikot sijoittuvat aikavälille 23.08.2021–

14.11.2021. Poikkeuksena tähän on viikon 36 (06.09.2021–12.09.2021) jolloin olen lomalla, joten työtehtävien raportointi ei ole mahdollista.

Tietoperustana työssä käytetään DevOps-roolille ominaisia teknologioita ja konsepteja kä- sitteleviä teoksia. Jatkuvaa kehitystä- ja integraatiota käsittelevä “Continuous Delivery Pi- pelines: How To Build Better Software Faster” (Farley 2021) on David Farleyn hiljattain jul- kaisema teos, joka kuvaa kattavasti jatkuvan kehityksen järjestelmien suunnittelun, kehityksen ja optimoinnin vaiheittain. ”Introduction to DevOps with Kubernetes: Build scalable cloud-native applications using DevOps patterns created with Kubernetes” (Yilmaz & Ak- bas 2019) puolestaan käsittelee konttiorkestraatiotyökalu Kuberneteksen toimintaperiaat- teita. Teoksessa käydään myös läpi Kuberneteksen sovittamista erilaisten DevOps-käy- täntöjen piiriin, joten se sopii aihealueeltaan hyvin tämän opinnäytetyön tietoperustaan.

Lisäksi työssä viitataan laajasti erilaisiin dokumentaatioihin ja käyttöoppaisiin, joita käytän jokapäiväisen työskentelyn lomassa paljon.

Työskentelen kirjoitushetkellä DevOps-konsulttina kotimaisessa, vuonna 2006 peruste- tussa CMS-järjestelmiin erikoistuvassa ohjelmistoyrityksessä, johon viitataan tästä lähtien tekstissä nimellä Foobar. Foobarilla on toimipisteitä neljässä eri kaupungissa, ja se työllis- tää noin 100 henkilöä. Pääasiallinen työpisteeni sijaitsee Helsingin toimistolla, mutta ko- ronaepidemiasta johtuen olen työskennellyt noin viimeisen vuoden täysin etänä.

DevOps-roolissa menestymiseen tarvitaan ongelmanratkaisutaitoja, analyyttista ajattelua, sekä priorisointi- ja stressinsietokykyä. Informaatioteknologian nopeasti kehittyvän ja muuttuvan luoteen vuoksi on myös pystyttävä sisäistämään uutta informaatiota nopeasti, sekä soveltamaan sitä käytännössä.

Opinnäytetyö sisältää paljon teknisiä käsitteitä sekä ammattisanastoa, joista keskeisimmät on kuvattu liitteessä (Liite 1).

(5)

2 Lähtötilanteen kuvaus

2.1 Oman nykyisen työn analyysi

Pääasiallisia työtehtäviäni DevOps roolissa ovat:

- Jatkuvan kehityksen- ja integraation (CI/CD) järjestelmien suunnittelu, pystyttämi- nen ja ylläpito.

- Pilvi-infrastruktuurin suunnitteleminen, pystyttäminen ja ylläpito.

- Palvelinten ja palvelinohjelmistojen pystyttäminen, konfigurointi, ylläpito ja vian- haku.

- Testiautomaation suunnittelu, kehittäminen ja ylläpito.

- Erilaiset QA-tehtävät. (esim. projektien lopputestaus)

Valtaosa päivittäisistä työtehtävistäni kuuluu selkeästi DevOps-roolille ominaisten tehtä- vien piiriin. Tyypilliset työtehtävät voidaan jakaa karkeasti kolmeen eri kategoriaan: alka- vien tai jo käynnissä olevien asiakasprojektien kontekstissa toteutetut työtehtävät, Fooba- rin tukisopimuksen piiriin kuuluvien asiakkaiden tukipyyntöjen käsittely, sekä yrityksen si- säisten järjestelmien ja resurssien ylläpito.

Keskeneräisiin tai alkaviin asiakasprojekteihin liittyvät tehtävät ovat yleensä työmäärältään huomattavasti laajempia kuin tukitehtävät, ja sisältävät lähes poikkeuksetta puhtaan tekni- sen implementaation lisäksi ainakin jonkin verran suunnittelu- ja tutkimustyötä. Tällaiset tehtävät pyritään niiden laajuuden vuoksi resursoimaan yrityksen sisällä mahdollisimman tehokkaasti ja hyvissä ajoin. Tukipyynnöt puolestaan ovat usein yllättävämpiä, ja niiden sisältö vaihtelee laajasti. Suurin osa tukipyynnöistä koskee palvelimien, tai niillä ajettavien ohjelmistojen konfiguraatiomuutoksia, kuten esimerkiksi Nginx WWW-palvelimen uudelleenohjauksia, tai SSL-sertifikaattien uusimista. Tukipyynnöt ovat lähtökohtaisesti myös kiireellisempiä, kuin asiakasprojektien kontekstissa toteutettavat työtehtävät.

Foobar käyttää monien muiden IT-alan yritysten tapaan projektin- ja tehtävänhallintaan suunniteltua Jira -ohjelmistoa. Jira mahdollistaa sekä yksittäisten työtehtävien, että laajempien projektikokonaisuuksien seuraamisen ja hallinnoimisen. Jiran kontekstissa yksit- täistä standarditoimeksiantoa (engl. work item) kutsutaan vapaasti suomennettuna tike- tiksi (engl. ticket). Työn päiväkirjaosuudessa puhutaan paljon työpyynnöistä sekä työ- jonosta – vaikka työtehtäviä kulkeutuu jokapäiväisessä työssä minulle tehtäväksi monia eri kanavia pitkin, ovat ne yleensä silti dokumentoitu Jira-tiketin muotoon. Työjonon voidaan siis yleisellä tasolla mieltää koostuvan yhdestä tai useammasta Jira-tiketistä.

Työtehtävistä suoriutumiseen vaaditaan teknisestä näkökulmasta ainakin tuntemusta unix-pohjaisten käyttöjärjestelmien - erityisesti Linuxin – toiminnasta, sekä komentokehot- teen hallitsemista. Myös jonkin ohjelmointikielen (esim. Bash, Python) osaaminen on

(6)

tarpeellista. Julkisten pilvien toiminnan ja palveluiden hahmottaminen, ainakin konseptu- aalisella tasolla, on myös kriittistä. Foobar tuottaa verkkosivustoja- ja palveluita, joten in- ternetin toiminnasta ja yleisistä verkkoprotokollista on myös hyvä omata ymmärrystä.

Pehmeille taidoille on myös tarvetta, sillä konsultin roolissa toimitaan paljon asiakastaja- pinnassa, ja projektityöskentely vaatii vuorovaikutusta tiimin jäsenten kanssa. Foobarin vi- rallinen työkieli on englanti, joten on pystyttävä kommunikoimaan suomen lisäksi myös englanniksi. Oman ajankäytön hallinta ja priorisointi ovat työssä onnistumisessa myös tär- keässä roolissa. Foobar käyttää lähtökohtaisesti paljon aikaa ja vaivaa resursoinnin suun- nitteluun ja seuraamiseen, mutta se ei aina tarkoita, että ennalta suunnitellut aikataulut ja arviot toteutuvat. Työtehtäviä on pystyttävä priorisoimaan itsenäisesti niiden kiireellisyy- den ja määräaikojen mukaan.

Koen tällä hetkellä suoriutuvani omista työtehtävistäni hyvin, sekä olevani teknisesti riittä- vän taitava suorittamaan kaikki minulle osoitetut tehtävät ilman erillistä ohjeistusta. Kyke- nen tekemään teknisiä päätöksiä ja suunnitelmia itsenäisesti, sekä perustelemaan ne tar- vittaessa muille.

Osallistun aktiivisesti sisäisten järjestelmien ja prosessien kehittämiseen oman roolini puit- teissa, ja toimin DevOps-tiimin varajohtajana. Yritän lisäksi toimia DevOps-kulttuurin puo- lestapuhujana, ja levittää päivittäisen työskentelyni lomassa tietoisuutta DevOps-toiminta- malleista Foobarin sisä- sekä ulkopuolella.

Foobar on ensimmäinen IT-alan työpaikkani. Työurani Foobarin alaisuudessa alkoi noin kolme vuotta sitten harjoittelujaksolla, jonka jälkeen vastaanotin vakinaisen työpaikan titte- lillä ”QA-engineer”. Tuohon aikaan tekniset taitoni olivat suhteellisen heikot verrattuna ny- kytasoon, mutta koulun ja oman harrastuneisuuden kautta kerrytetty osaaminen myötävai- kutti työssä pärjäämiseen huomattavasti.

Alun perin olin siis vastuussa pelkästään QA-tehtävistä, mutta työnkuvani on sittemmin laajentunut, osittain Foobarin sisäisen DevOps-mallin luonnin johdosta. Tämän organisaa- tiomuutoksen taustalla oli ajatus yhdistää kaksi olemassa olevaa kompetenssia, ”QA” ja

”systems” yhdeksi kokonaisuudeksi, eli DevOps-tiimiksi. Muutos tarjosi loistavan tilaisuu- den laajentaa omaa osaamistani uusien teknologioiden ja käytäntöjen kautta, joita oma henkilökohtainen vapaa-ajan harrastuneisuus ja yleinen kiinnostus tuki ennestään. Osaa- misalani on laajentunut myös DevOps-roolin ulkopuolelle, josta esimerkkinä toimii

backend-kehitys Typescript ohjelmointikielellä.

(7)

Ammatillisesti koen kehittyneeni paljon viimeisen vuoden aikana, ja uskonkin termin ”asi- antuntija” pätevän ainakin tiettyjen osaamisalueiden yhteydessä. Konkreettisesti tämä nä- kyy päivittäisen työskentelyn tehostumisena, joka puolestaan on antanut itsevarmuutta luottaa omaan päätöksenteko- ja arviontikykyyn enemmän. Pystyn perustelemaan erilaisia tekemiäni teknisiä ratkaisuja asiakkaille ja kollegoille objektiivisesti, sekä myös omien em- piiristen kokemusteni kautta. Jo saavutetusta ammatillisesta kehityksestä huolimatta en kuitenkaan koe vielä olevani samalla tasolla useiden kokeneempien kollegoideni kanssa, ja kehitettävää koen olevan ainakin laajempien arkkitehtuurien suunnittelussa, sekä kon- teista ja niiden hallinnoimisesta.

2.2 Sidosryhmät työpaikalla

Kuvassa 1 havainnollistetaan omassa oman työskentelyni kannalta merkittävät sidosryh- mät ajatuskartan muodossa.

Kuva 1. Ulkoiset ja sisäiset sidosryhmät työpaikalla

Omassa työssäni olen harvoin tekemisissä muiden ulkoisten sidosryhmien kanssa, kuin asiakkaiden. Asiakasprojektien kontekstissa merkittäviä sidosryhmiä (merkitty kuvassa vihreällä) ovat projektia toteuttava tiimi, sekä asiakas. Projektitiimiin kuuluu ainakin yksi kehittäjä, tech-lead, sekä projektipäällikkö. Foobarin tukisopimuksista syntyvien työtehtä- vien kautta olen tekemisissä myös tukipalvelukoordinaattorien kanssa.

Toinen merkittävä sisäisten sidosryhmien haara on sisäiset kehitystiimit. (merkattu kuvassa oranssilla.) Tällaiset tiimit ovat keino jakaa työntekijöitä organisaation sisällä pie- nempiin, loogisempiin ryhmiin, eivätkä siis itsessään määritä asiakasprojektien tiimejä tai

(8)

kompostiota. Tiimin sisällä sidosryhmiä ovat sekä oman ja muiden tiimien jäsenet, oma lähiesimieheni, sekä tiimin vetäjä. Muita sekalaisia sidosryhmiä ovat myynti, henkilöstöhal- linto, ja markkinointiosasto. (merkattu kuvassa liilalla.)

2.3 Vuorovaikutus työpaikalla

Kommunikaatio kollegoideni kanssa tapahtuu pääasiallisesti Slack-pikaviestimen avulla.

Foobar hyödyntää em. pikaviestintä varsin laajasti - jokaiselle asiakasprojektille on lähtö- kohtaisesti yksi tai useampi kanava. Kommunikaatio on jaettu usein ”sisäisiin” ja ”ulkoisiin”

kanaviin, kanavien osallistujien mukaan. Sisäiset kanavat ovat tarkoitettu Foobarin omien työntekijöiden käyttöön, jossa keskustelua käydään esimerkiksi kehitystyöstä, tai muista projektin toteutukseen liittyvistä aiheista. Ulkoiset kanavat ovat puolestaan tarkoitettu asia- kaskommunikointiin. Slack-pikaviestimen ohella kommunikointiin käytetään myös sähkö- postia. Kommunikaatiota tapahtuu paljon myös Jira-tikettien kautta – sisäiset sekä ulkoiset sidosryhmät seuraavat työtehtävien edistymistä pitkälti tikettien kautta, joten kommunikaatio ja tiedon välittäminen niiden avulla on tärkeää.

Asiakaskontekstissa suurin osa kommunikoinnista tapahtuu projektipäällikön tai tech- lead:in kautta. Olen kuitenkin myös itse jonkin verran suorassa kontaktissa asiakkaiden kanssa, etenkin teknisiin asioihin liittyen. Tällainen kommunikaatio asiakkaiden kanssa tuottaa välillä haasteita, sillä teknisten yksityiskohtien, konseptien ja suunnitelmien kom- munikoiminen vähemmän teknisille henkilöille ei aina ole helppoa. Tämän tyyppisen tiedon välittäminen eteenpäin kuulijalle helposti ymmärrettävässä muodossa vaatii usein asi- oiden esittämistä teknisten yksityiskohtien sijaan käytännön hyötyjen ja analogioiden kautta.

(9)

3 Päiväkirjaraportointi

3.1 Seurantaviikko 1

Maanantai 30.08.2021

Tänään olen suunnitellut hoitavani työpyynnön liittyen asiakkaan tuotantoympäristöön tar- vittaviin uudelleenohjauksiin, sekä osallistuvani toisen projektin sprint-katselmointiin. Lo- pun työpäivästä suunnittelen käyttäväni Foobarin sisäiseen projektiin, jossa pyritään luomaan standardoitu Helm paketti tietyn tyyppisien asiaksprojektien pohjaksi. Projektiin viitataan tästä eteenpäin tekstissä nimellä Foobar cloud.

Päivä alkoi suunnitellusti Nginx uudelleenohjausten toteuttamisella. Alun perin helpoksi ja nopeaksi arvioimani työpyyntö kuitenkin eskaloitui – asiakkaan päässä oli epäselvyyttä uudelleenohjattavista poluista, ja vastaavasti palvelimen päässä konfiguraatiot olivat jok- seenkin monimutkaisia. Palvelimella oli jo valmiiksi kymmeniä eri uudelleenohjaus-sään- töjä, joista osa toimi valmiiksi hieman odottamattomasti. Ongelmia aiheutti erityisesti yksi ns. wildcard-sääntö, joka evaluoitiin ennen uusia uudelleenohjaus-sääntöjä. Sain työpyyn- nön kuitenkin lopulta ratkaistua, vaikkakin se vei enemmän aikaa kuin olin ajatellut.

Iltapäivällä osallistuin asiakasprojektin sprint-katselmointiin, ja esittelin toiselle asiakkaalle edellisviikolla implementoimiani Robot Framework-automaatiotestejä. Loppupäivän tutus- tuin Foobar cloud projektin kontekstissa Helm-nimisen Kubernetes pakettimanagerin toi- mintaan, lähinnä dokumentaation kautta.

Tiistai 31.08.2021

Päivä on täynnä kokouksia, joten en ole suunnitellut tekeväni mitään spesifejä työtehtäviä.

Aamupäivä menee kokonaisuudessaan kompetenssimanagerin kanssa pidettävään kehi- tyskeskusteluun, ja iltapäivällä on vuorossa muutama lyhyempi palaveri, joista ensimmäi- nen koskee tukisopimuksen määrittelyjen laatimista asiakkaan Kubernetes tuotantoympä- ristölle, ja toinen taas em. ympäristön nykytilaa.

Päivän ensimmäinen kokous, eli kehityskeskustelu, meni mielestäni hyvin. Kollegoilta oli keskustelua varten kerätty etukäteen palautetta, ja se oli suurimmilta osin todella positii- vista. Iltapäivän kokoukset menivät myös hyvin, ja onnistuimme hahmottelemaan tukipal- veluiden koordinaattorin kanssa sopivat ehdot asiakkaan Kubernetes ympäristön ylläpi- toon.

(10)

Ennen työpäivän lopettelemista kerkesin vielä palata hieman eilen aloittamani Helm pakettimanagerin tutkimiseen, jonka tiimoilta aiheena oli tänään riippuvuuksien lisääminen ja kustomointi. Helm kutsuu asennettavia kokonaisuuksia kartoiksi (chart). Omia karttoja luo- dessa voidaan riippuvuuksiksi lisätä rajoittamaton määrä muita karttoja. Tämä ominaisuus mahdollisti kaikkien sovelluksen tarvitsemien riippuvuuksien kokoamisen yhteen karttaan, joka puolestaan helpottaa kehittäjien työtä, ja pitää konfiguraatiot kätevästi yhdessä pai- kassa.

Keskiviikko 01.09.2021

Päivän agendana on jatkaa Foobar cloud projektin kanssa. Puolelta päivin aion osallistua joka toinen viikko pidettävään henkilöstökokoukseen, sekä erään asiakasprojektin viikkopalaveriin.

Aamupäivä alkoi yllättävällä työpyynnöllä – eräässä asiakasprojektissa oli tarvetta analy- soida kolmannen osapuolen laatima arkkitehtuurisuunnitelma Azure-ympäristön toteutuk- sesta. Pohjatietoni muutamaan arkkitehtuurissa käytettyyn komponenttiin liittyen oli heikko, joten suunnitelman verifiointi vaati jonkin verran dokumentaatioiden tutkimista, ja päätyikin lopulta viemään koko aamupäivän. Arkkitehtuurisuunnitelma oli mielestäni pä- tevä, joskin tietyt asiat olivat vielä paikoin määrittelemättä.

Henkilöstökokouksen ja lounaan jälkeen selvittelin kiireellistä työpyyntöä, joka liittyi asiakkaan tuotantoympäristön äkilliseen hajoamiseen. Tarkistin backend-palvelimen lokitiedot, ja huomasin että eräs sovelluksen käyttämä tietokantakysely oli alkanut yllättäen palautta- maan tyhjää. Tämä kysely hakee tietokannasta sovelluksen toiminnalle kriittistä dataa, joten se oli ilmeinen syy ympäristön äkilliseen hajoamiseen. Tarkistin vielä, että kyse ei ole yhteysongelmasta kannan ja backend-palvelimen välillä, ja raportoin sitten aiheesta suoraan asiakkaan yhteyshenkilölle. Ongelman syyksi paljastui pienen selvittelyn jälkeen asiakkaan toinen yhteistyökumppani, joka on vastuussa tietokannasta ja sen ylläpidosta, joten muita toimenpiteitä ei minun osaltani tarvittu.

Iltapäivällä selvittelin vielä Foobar cloud projektin osalta Helm paketin kautta tarjottavan sovelluksen palvelemista lokaalisti tietyn verkkotunnuksen kautta localhost-osoitteen sijaan. Sovelluskontin paljastaminen Kubernetes palvelinklusterin ulkopuolelle toteutetaan tässä tapauksessa Nginx-ingressin avulla, jonka konfigurointi vaati hieman dokumentaation sisäistämistä. Vaikka ohjelmisto on minulle ennestään tuttu, sen versiosta 1.0.0 eteenpäin vaaditaan toiminnan mahdollistamiseksi uusi ”IngressClass” resurssi, jonka implementoinnista minulla ei ollut aiempaa kokemusta.

(11)

Torstai 02.09.2021

Tänään tiedossa ei ole kokouksia tai muitakaan ennalta suunniteltuja työtehtäviä. Olen ensi viikon lomalla, joten olen tarkoituksella yrittänyt välttää suurempien työkokonaisuuk- sien ottamista omalle kontolleni. Suunnittelen edistäväni Foobar cloud projektia, jossa seuraavana vaiheena on lokaalin kehitysympäristön hiominen loppuun, ja sen yhteenso- vittaminen AWS:än Kubernetes-ympäristön (EKS) kanssa.

Vietin koko päivän Foobar cloud projektin parissa. Lähinnä tutkin, miten olemassa oleva lokaali Helm-paketti saadaan integroitua AWS EKS-ympäristöön, ja millaisia modifikaati- oita se edellyttää. EKS vaatii toimiakseen Amazonin tarjoaman ELB-instanssin (Amazon load balancer), joita on tarjolla kahta eri tyyppiä. Toinen näistä kahdesta vaihtoehdosta on ALB (Application load balancer), joka reitittää nimensä mukaisesti liikennettä sovellusta- solla, esim. http-otsakkeiden, URL-polkujen tai isäntänimen perusteella. Tätä vaihtoehtoa en kuitenkaan tahtoisi käyttää, sillä se efektiivisesti korvaisi jo käytössä olevan Nginx-ingressin, täten eriyttäen lokaalin- ja kehitysympäristön konfiguraatiot. Mielestäni sopivampi vaihtoehto oli NLB (Network load balancer). NLB on OSI-mallin tasolla 4 operoiva kuormantasaaja, joka voidaan sijoittaa olemassa olevan Nginx-ingressin eteen, täten mahdol- listaen jo lokaalissa kehitysympäristössä käytettyjen konfiguraatioiden hyödyntämisen myös pilviklusterissa. Kokosin tutkimusteni perusteella kaaviot näistä kahdesta implementaatioista, ja aion esitellä ne kollegoilleni huomisessa Foobar cloud seurantakokouksessa.

Perjantai 03.09.2021

Tänään joudun lopettamaan työt hieman normaalia aikaisemmin henkilökohtaisten menojen takia. Ehdin kuitenkin esittelemään eilen laatimani ehdotukset AWS EKS arkkitehtuurista, sekä osallistumaan erään asiakasprojektin viikkopalaveriin.

Päivä alkoi tarkistamalla edellisviikolla jättämäni, asiakkaan Azure ympäristöön liittyvän tukipyynnön tilan Pyyntöön ei oltu vielä reagoitu mitenkään, joten en valitettavasti saanut asiaa eteenpäin.

Esitelmäni Foobar cloud projektin EKS arkkitehtuurista meni hyvin, ja päädyimmekin vaih- toehtojen läpikäynnin jälkeen laatimaan kollegoiden kanssa alustavan suunnitelman sen implementoinnista. Ennen työpäivän loppua ehdin vielä suorittaa yhden työpyynnön, joka koski asiakkaan pilvitietokannan varmuuskopioimista kovalevylle. Kopioinnista teki haas- teellista se, että asiakkaan tietokanta ei ollut suoraan auki julkiseen internettiin. Ratkaisin

(12)

ongelman luomalla uuden virtuaalipalvelimen samaan sisäverkkoon kuin tietokanta, jonka avulla onnistuin ottamaan tietokannasta varmuuskopiot.

Viikkoanalyysi

Tällä viikolla työskentely on painottunut vahvasti Foobar cloud projektin kautta Kuberne- teksen ja Helm pakettimanagerin ympärille. Kubernetes on konttien ajamiseen ja orkest- roimiseen kehitetty avoimen lähdekoodin alusta. Kubernetes mahdollistaa kompleksien pilvinatiivien sovellusten määrittelemisen ja hallinnoinnin joustavasti ja luotettavasti.

(Yılmaz & Akbaş 2019) Omaan Kuberneteksesta jonkin verran aiempaa kokemusta - olen tottunut kehittämään ja ylläpitämään yksittäisille palveluille tai sovelluksille suunniteltuja ympäristöjä, jotka noudattavat pääasiallisesti mikropalveluarkkitehtuuria. (engl. Microser- vice architecture) Mikropalveluarkkitehtuuri voidaan määritellä joukkona pieniä eriytettyjä palveluita, jotka kommunikoivat keskenään kevyiden mekanismien avulla, kuten http-protokolla tai erinäiset rajapinnat. (Fowler 2014) Kuberneteksen tapauksessa mikropalvelut viittaavat Docker-kontteihin, jotka kommunikoivat Kuberneteksen moninaisten rajapintojen avulla.

Foobar cloud -projektin kontekstissa oma aiempi Kubernetes osaaminen ja kokemus valitettavasti eivät päde sellaisenaan, sillä yksittäisen sovellusympäristön sijaan ajatuksena on kehittää geneerinen sapluuna, jolla useita eri asiakasprojektien ympäristöjä voidaan pystyttää samaan Kubernetes palvelinklusteriin. Vaikka myös tässä tapauksessa sovellusta ajetaan kontissa, niin tilanne eroaa mikropalveluarkkitehtuurista siten, että tässä tapauksessa sovellus muodostuu useiden konttien sijasta vain yhdestä kontista, ja sovelluk- sia itsessään ajetaan rinnan useita.

Tämä kriittinen eroavaisuus on korostunut varsinkin tietoverkkojen ja reitityksen suunnittelussa, ja Nginx-ingressien konfiguroimisessa. Kubernetes ingressin (engl. Ingress) tarkoitus on reitittää kyselyt palvelinklusterissa sijaitseville palveluille, ja niiden kautta edelleen yksittäisille podeille. Reititys tapahtuu ingressin konfiguraation perusteella, ja vaatii ingressi kontrollerin (engl. Ingress controller) resurssin toimiakseen. (Kubernetes 2021) Käy- tännössä tämä tarkoittaa sitä, että ingressi määrittelee miten reititys tulisi hoitaa, ja ingressi kontrolleri on vastuussa em. konfiguraatioiden toteuttamisesta.

Toinen ingresseihin liittyvä ongelma on tällä viikolla ollut lokaalin Kubernetes palvelinklusterin sisällä pyörivän ingressikonfiguraation siirtäminen AWS EKS palveluun. EKS vaatii toimiakseen erityisen Elastic Load Balancer (ELB) resurssin. AWS tarjoaa kaksi erilaista ELB tyyppiä, Application Load balancer (ALB), sekä Network Load Balancer (NLB). ALB- tyyppisen kuormantasaajan käyttö osoittautui kuitenkin mahdottomaksi jo olemassa

(13)

olevan Nginx-ingress kontrollerin rinnalla – molemmat operoivat OSI-mallin tasolla 7, joten ABL-tyyppinen kuormantasaaja korvaisi tässä tapauksessa Nginx-ingress kontrollerin (Kuva 2). Tämä ei ole toivottavaa, sillä se aiheuttaa ylimääräistä työtä, sekä eriyttää kehitys- ja tuotantoklusterien konfiguraatiot. On hyvä huomata, että vaikka ALB tyyppinen kuormantasaaja ei teknisesti sijaitse Kubernetes-klusterin sisällä, kahden tason 7 kuormantasaajan ketjuttaminen ei ole käytännön ja suorituskyvyn puolesta toivottavaa. Ratkai- suna päädyttiin käyttämään NLB-tyyppistä kuormantasaajaa (Kuva 3), joka operoi OSI- mallin tasolla 4. Tämä tarkoittaa sitä, että tuotantoklusteriin voidaan ajaa samat konfiguraatiot kuin lokaalinkin klusteriin, jonka jälkeen se avataan internettiin käyttämällä NLB- tyyppistä kuormantasaajaa.

Kuva 2. ALB-tyyppinen kuormantasaaja (Cornell 2019)

Kuva 3. NLB-tyyppinen kuormantasaaja (Cornell 2019)

(14)

Päivä alkaa tänään lukemalla sähköpostit ja Slack-viestit edellisviikolta, jonka olin lomalla.

Päivän työtehtävät muodostuvat oletettavasti pitkälti näiden viestien pohjalta.

Kahlattuani heti aamusta sähköpostien ja muiden viestien läpi, aloitin niiden pohjalta ker- tyneiden työpyyntöjen priorisoinnin ja suorittamisen. Heti aluksi palasin seurantaviikolla 1 mainitsemani Nginx-palvelimen kimppuun, jonka tiimoilta tehtävänä oli jälleen implemen- toida uudelleenohjaus-sääntöjä. Asiakas oli tällä kertaa koostanut Excel-tiedostoon listan tarvittavista säännöistä, joita oli yhteensä noin 80 kappaletta. Uudelleenohjattavien polkujen lisäksi joukossa oli myös muutama aliverkkotunnus. Päädyin kirjoittamaan yksinkertai- sen Python-ohjelman, joka jäsenteli Excel-tiedostosta tarpeelliset kentät tekstitiedostoon, samalla muuntaen rivit Nginx:än ymmärtämään muotoon. (Taulukko 1). Lisäsin uudelleenohjaukset palvelimelle käsin, ja testattuani kaiken toimivaksi suljin työpyynnön.

Taulukko 1. Esimerkki koodin syötteestä ja vastaavasta tuloksesta Alkuperäinen osoite example.com/some-url-path

Uudelleenohjauksen osoite target.org/redirect-path

Nginx yhteensopiva sääntö rewrite ^/some-url-path target.org/redirect-path permanent;

Iltapäivällä hoidin vielä muutamia sekalaisia työtehtäviä. Korjasin erään palvelimen SSH- asetukset, ja suoritin Slack-pikaviestimen käyttäjänhallintaan liittyviä tehtäviä.

Tiistai 14.09.2021

Suunnitelmissa on tänään lähinnä edistää Foobar cloud-projektia, sekä vastata kiireellisiin työpyyntöihin. Iltapäivällä osallistun erään asiakasprojektin viikkopalaveriin.

Päivä alkoi äkillisellä työpyynnöllä: kollega ei päässyt kirjautumaan asiakkaan testipalveli- melle käyttäen toimiston staattista IP-osoitetta. Mielenkiintoisena lisänä kollega mainitsi, että saman asiakkaan tuotantopalvelimelle hän pääsi edelleen kirjautumaan normaalisti.

Pienen tutkimisen ja palvelimien ympäristöjen vertailun jälkeen ongelman syyksi paljastui testipalvelimen palomuurin asetukset. Tuotantopalvelin käytti Foobarin standardiasetuk- sien mukaista palomuuria, mutta testiympäristön säännöt olivat implementoitu eri tavalla.

(15)

Tilanne ratkaistiin lisäämällä toimiston IP-osoite listalle, joka määrittää SSH-porttiin sallit- tavat yhteydet.

Iltapäivän osallistuin lyhyeen asiakaspalaveriin, jonka jälkeen työskentelin Foobar cloud- projektin parissa. Tavoitteena oli siirtää eräs verkkosivu pois jo olemassa olevasta AWS EKS-palvelinklusterista, jota olimme aikaisemmin käyttäneet projektin testaamiseen.

Tämä sivusto oli määrä siirtää erään toisen pilvipalvelun virtuaalipalvelimeen, joten ennen klusterin tyhjentämistä oli tarpeellista ottaa varmuuskopiot tietokannasta ja tiedostoista.

Tietokannan varmuuskopiointi osoittautui odotettua hankalammaksi, sillä AWS RDS-palvelu (Relational Database Service) ei salli valmiiden varmuuskopioiden lataamista suoraan kovalevylle. Lisäksi tietokanta oli avoinna pelkästään tietylle AWS-sisäverkolle, joten en pystynyt yhdistämään siihen suoraan omalta tietokoneeltani. Päädyin luomaan uuden virtuaalipalvelimen samaan sisäverkkoon tietokannan kanssa, jonka kautta onnistuin lopulta yhdistämään RDS-palveluun, ja lataamaan varmuuskopiot.

Tänään olen suunnitellut jatkavani eilistä varmuuskopioiden ottamista, jonka tiimoilta vuorossa on tiedostojen kopiointi AWS EFS-palvelusta. Lisäksi osallistun henkilöstökokouk- seen, sekä erään asiakasprojektin kokoukseen, jossa agendalla on heidän palvelunsa uuden toiminnallisuuden määritteleminen.

Aloitin heti aamusta varmuuskopioiden ottamisen EKS-palvelinklusterissa pyörivästä verk- kosivustosta. Sivusto käyttää tiedostojen tallentamiseen AWS EFS (Elastic File System) palvelua. Palvelu on verrattavissa toiminnaltaan normaaliin verkkolevyjärjestelmään (engl.

Network File System), vaikkakin se tarjoaa myös tiettyjä uniikkeja ominaisuuksia. Koska palvelu on toiminnaltaan verrattavissa normaaliin verkkolevyyn, oli myös varmuuskopioiden ottaminen varsin suoraviivaista. Kiinnitin ensin EFS-tiedostojärjestelmän virtuaalipalvelimen omaan tiedostojärjestelmään, jonka jälkeen pakkasin varmuuskopioitavat tiedostot siirtoa varten. Lopuksi kopioin pakatut tiedostot omalle kovalevylleni.

Henkilöstökokouksen ja lounaan jälkeen oli aika osallistua asiakasprojektin merkeissä pi- dettävään kokoukseen, jossa määriteltiin asiakkaan palveluun toteutettava uusi toiminnal- lisuus. Kokous ei vaatinut minulta henkilökohtaisesti mitään panosta, mutta koska olen re- sursoitu projektille – ja myös työskennellyt sen parissa aiemmin – osallistuin mielelläni kokoukseen pysyäkseni kärryillä projektin etenemisestä.

Iltapäivällä konfiguroin uuden tuotantopalvelimen EKS-palvelinklusterista siirrettävälle si- vustolle. Importoin varmuuskopioidun SQL-tietokannan, ja siirsin EFS-järjestelmästä kopi- oidut ja pakatut tiedostot oikeille paikoilleen. Sivusto on rakennettu käyttäen tunnettua,

(16)

stabiilia CMS-järjestelmää, joten varmuuskopioiden importoiminen sujui ongelmitta. Testa- sin lopuksi vielä uuden tuotantoympäristön käyttöä ja sisällön lisäämistä varmistuakseni, että kaikki toimii kuten pitää, sekä kurkistin pikaisesti palvelimen lokeihin, jotka näyttivät onneksi olevan vapaat virheviesteistä.

Torstai 16.09.2021

Päivän ainoana tavoitteena on saada koko viikon kestäneen, aiemmin EKS-palvelinklusterissa ajetun sivuston migraatio uudelle virtuaalipalvelimelle valmiiksi. Muita työtehtäviä tai kokouksia ei tälle päivälle ole sovittuna.

Aloitin päivän uudelleenmäärittelemällä siirrettävän sivuston DNS-asetukset. Sain eilen valmiiksi tiedostojen ja tietokannan siirtämisen uudelle palvelimelle, joten sivusto on itses- sään toimintavalmis, mutta verkkotunnukset on vielä osoitettava uuden palvelimen IP- osoitteeseen. Tämä prosessi on yksinkertainen, ja vaatii ainoastaan verkkotunnuksen re- levanttien DNS-tietueiden (tässä tapauksessa A-tietue ja useita CNAME-tietueita) osoitta- misen uuden palvelimen IP-osoitteeseen. Ylimääräistä aikaa kuitenkin kului siihen, että kyseiselle palvelulle on olemassa useita päätason verkkotunnuksia (fi, com, uk), joiden DNS-tietueita hallinnoidaan useiden eri palveluiden kautta. Ennen muutoksia piti siis sel- vittää, mistä kuhunkin verkkotunnukseen edes pääsee käsiksi.

Muokattuani kaikkien verkkotunnuksien DNS-tietueet osoittamana uuteen palvelimeen, oli tarpeellista uusia TLS-sertifikaatit näille verkkotunnuksille. Tämän prosessin nopeutta- miseksi Foobar käyttää valmiiksi konfiguroitua Bash-ohjelmaa, joka luo tai uusii TLS-sertifikaatit halutuille verkkotunnuksille Let’s Encrypt-palvelun avulla. Sertifikaattien luominen onnistui hyvin, mutta ylimääräistä työtä aiheutti palvelun moninaisten verkkotunnusten uu- delleenohjaaminen yhteen spesifiin verkkotunnukseen (example.com), joka vaati hieman muutoksia Nginx-palvelimen konfiguraatioihin (Kuva 4).

(17)

Kuva 4. DNS-tietueiden kohdistaminen ja Nginx-uudelleenohjauksien rakenne

Tänään joudun äkillisten menojen takia lopettamaan työpäivän hieman normaalia aikaisemmin, mutta siitä huolimatta agendalla on pystyttää uusi EKS-palvelinklusteri yhdessä kollegoiden kanssa, ja mikäli aikaa riittää, asentaa myös NBL-kuormantasaaja klusterin eteen.

Ensimmäisenä työtehtävänä tänään oli erään asiakkaan tuotantoympäristön uudelleenohjauksien korjaaminen. Ympäristön Nginx-palvelimen pitäisi uudelleenohjata kaikki www- aliverkkotunnukseen saapuva liikenne pääasialliseen verkkotunnukseen, mutta tämä uudelleenohjaus ei jostain syystä toiminut. Selviteltyäni asiaa noin tunnin verran paikanta- matta ongelman syytä, päädyin pyytämään kokeneempaa kollegaa avuksi. Kollegan avulla paikansimme ongelman virheellisesti konfiguroituun Nginx map-direktiiviin. Direktii- vin tarkoituksena oli kaapata www-aliverkkotunnukseen kohdistuvat kutsut, ja ohjata ne muuttujan avulla oikeaan pääasialliselle verkkotunnukselle. Edellä mainittuja map-direk- tiivejä oli kuitenkin määritelty kaksi kappaletta, eikä Nginx täten voinut tietää, kumpaa niistä tulisi käyttää. Ongelma ratkesi yhdistämällä nämä erilliset direktiivit, jolloin uudelleenohjaukset toimivat halutulla tavalla.

Iltapäivällä osallistuin vielä Foobar Cloud-projektin viikkopalaveriin, jonka oli normaalista poiketen tarkoitus käyttää uuden EKS-palvelinklusterin pystyttämiseen yhteisvoimin. Aloi- tin ruudunjaon kollegoilleni, ja kävimme yhdessä läpi klusterin pystyttämiseen vaaditut toi- menpiteet. Loimme aluksi klusterille oman VPC-ympäristön, kolme kappaletta aliverkkoja, sekä SG-ryhmän (Security Group) tietoliikenteen ja resurssien oikeuksien rajoittamiseksi.

Tämän jälkeen siirryttiin luomaan itse EKS-klusterin, joka hyödynsi aiemmin luomiamme

(18)

resursseja. Loppupäivästä yritin vielä parhaani mukaan saada NLB-kuormantasaajaa toimimaan uudessa klusterissa, mutta valitettavasti en ehtinyt saada toimivaa konfiguraatiota kasaan ennen työpäivän päättymistä.

Viikkoanalyysi

Tällä viikolla Nginx www-palvelin on tuottanut suuren osan työtehtävistä. Nginx on vuonna 2004 julkaistu vapaan lähdekoodin www-palvelinohjelmisto, jota voidaan käyttää perintei- sen verkkosisällön palvelemisen lisäksi myös esimerkiksi käänteis-proxynä (engl. reverse- proxy) muiden palveluiden edessä, kuormantasaajana, tai TLS yhteyksien terminoimi- seen. Nginx tukee http-protokollan lisäksi muita modernissa internetissä käytettyjä teknii- koita ja protokolleja, esim. WebSocket ja gRCP. (Nginx 2021)

Olen käyttänyt Nginx:ää henkilökohtaisissa projekteissani jo ennen alalle työllistymistä.

Koen kuitenkin, että vasta oikeiden tuotantoympäristöjen konfiguroimisen kautta olen päässyt kartuttamaan ammatillisesti pätevää osaamista, sillä reaalimaailman verkkosivus- tojen- ja palveluiden Nginx konfiguraatiot ovat tyypillisesti paljon harrasteprojekteja vaati- vampia ja monimutkaisempia. Pystyn lähtökohtaisesti hoitamaan Nginx:ää koskevat työpyynnöt itsenäisesti ilman ongelmia, mutta tietyissä tapauksissa on yhä turvauduttava kokeneempien kollegoiden apuun. Yleensä tällaiset tapaukset liittyvät toiminnallisuuksiin, joita en ole ennen käyttänyt – esimerkiksi tällä viikolla tapahtunut map-direktiiviin liittyvä ongelma.

Map-direktiivin tehtävä on evaluoida annettu muuttuja, jonka arvon mukaan alustetaan toinen muuttuja halutulla arvolla. Esimerkissä muuttujan ”name” arvo määritellään ”http- host”-muuttujan arvon mukaan, ja ”default” muuttujan arvoa käytetään, jos mikään muista arvoista ei täsmää (Kuva 5).

(19)

Kuva 5. Esimerkki Nginx map-direktiivistä (Nginx 2021)

Vaikka map-direktiivin toiminta oli minulle selkeää, niin dokumentaatiossa ei kuitenkaan ollut mainintaa siitä, millä periaatteella Nginx valitsee käytetyn direktiivin, mikäli tarjolla on useita. Tästä syystä en vianhaun yhteydessä osannut kyseenalaistaa uudelleenohjauksen käyttämän map-direktiivin oikeellisuutta, ennen kuin kollegani selitti sen toiminnan perus- teellisemmin. Vaikka kokeneemman kollegan apuun turvautuminen tuntuukin tällaisissa tilanteissa välillä lannistavalta, koen sen silti olevan erinomainen tapa oppia uutta, ja kehit- tää ammatillista osaamista.

Nginx:än ohella huomattavan määrän työtä tällä viikolla on tuottanut myös AWS-pilvipal- velu, jonka tiimoilta erilaisia ongelmia ratkottiin useampana päivänä. AWS (Amazon Web Services) on Amazon.com inc. omistama pilvilaskenta-alusta. AWS on julkisen pilven markkinajohtaja - vuoden 2021 toisella neljänneksellä AWS:n osuus pilvimarkkinoista oli 31 % (Canalys 2021.) Kuten Nginx, myös AWS:n käyttö on minulle ennestään tuttua, niin aiempien asiakasprojektien kuin oman harrastuneisuutenikin kautta. Viime aikoina olen kuitenkin työskennellyt enemmän Microsoftin Azure-pilvialustan kanssa, joten AWS:n käyttö pidemmän ajan jälkeen vaati hieman uudelleenopettelua. Lisäksi tällä viikolla tuli toimittua paljon sellaisten AWS-komponenttien kanssa, joiden käytöstä minulla ei juuri ole aiempaa kokemusta. Esimerkkinä voidaan käyttää vaikkapa EFS-palvelua, tai erinäisiä kuormantasaajia.

Viikon AWS-aiheiset työtehtävät vahvistivat ennestään henkilökohtaista kuvaa siitä, että palvelu tekee kaikkensa ajaakseen käyttäjät palveluloukkuun (engl. vendor lock), tehden pilvipalvelun vaihtamisesta äärimmäisen vaikeaa. Palveluloukku käsitteenä kuvaa

(20)

tilannetta, jossa palveluntarjoaja pyrkii tekemään palvelun vaihtamisesta (esim. kilpaili- jalle) mahdollisimman haastavaa – tai jopa mahdotonta – käyttäen erilaisia teknisiä, oikeu- dellisia tai taloudellisia keinoja. (Raza 2020)

Tässä tapauksessa palveluloukku ilmentyi hankaluuksina saada sivuston tietokannasta ja tiedostoista varmuuskopiot. AWS RDS-palvelu (Relational Database Service) voidaan määritellä ottamaan säännöllisesti varmuuskopioita, joiden kautta voidaan virhetilanteen sattuessa palauttaa toimiva versio kannasta. Näitä varmuuskopioita ei kuitenkaan voida suoraan ladata omalle kovalevylle, vaikka esim. tietojen siirtäminen toiselle tietokantaklus- terille (AWS:n sisällä) on tuettu. Omasta mielestäni vielä räikeämpi esimerkki palvelu- loukusta oli kuitenkin EFS-palvelun tiedostojen kopiointi ulos pilvestä. AWS muutaman eri- laisen palvelun tiedostojen siirtämiseen, joiden käyttämisesti luonnollisesti peritään

maksu, eikä tiedostoja voi ladata esimerkiksi käyttöliittymän kautta. Todellisuudessa EFS toimii kuitenkin normaalin verkkolevyn tapaan, ja voidaan täten kiinnittää esimerkiksi virtuaalipalvelimen tiedostojärjestelmään. AWS-dokumentaatio tarjoaa tästä esimerkin, mutta mielestäni on selvää, että käyttäjä yritetään ensisijaisesti ajaa maksullisten palveluiden pariin.

Olen suunnitellut tänään edistäväni Foobar cloud-projektia, sillä loppuviikko näyttää asiakasprojektien tiimoilta varsin kiireiseltä, enkä usko ehtiväni palata tämän projektin pariin ennen ensi viikkoa.

Aloitin päivän tutkimalla viime perjantaina pystytettyä EKS-klusteria, sekä muita resursseja. Vaikka Kuberneteksen toiminta onkin minulle ennestään tuttu, EKS lisää toimintape- riaatteiden joukkoon paljon AWS:lle spesifejä konsepteja, kuten IAM-oikeudet ja roolit.

Näiden roolien ja oikeuksien toiminta EKS kontekstissa on minulle uutta, joten aamupäivä meni pitkälti dokumentaation lukemisessa ja käytännön testaamisessa.

Iltapäivällä jatkoin vielä hieman EKS:än toiminnan selvittelemistä, mutta hoidin myös yhden työpyynnön liittyen asiakkaan tuotantopalvelimeen: konfiguroin Varnish välimuistipal- velimen poistamaan sen läpi kulkevista http-pyynnöistä tietyt otsakkeet, jotka tuottivat ongelmia sivuston toiminnalle.

(21)

Tiistai 21.09.2021

Tänään kalenterissa on Foobar Cloud-projektin edistämisen lisäksi asiakaskokous, jonka tarkoituksena on laatia tarjous uudesta toiminnallisuudesta heidän verkkopalveluunsa. Li- säksi olen valmistellut koulutuksen erään toisen asiakkaan henkilöstölle, jossa käydään läpi Azure pilvialustan toimintaa, sekä demonstroidaan, kuinka pystyttää yksinkertainen verkkosivusto.

Aamu alkoi työpyynnöllä, jonka mukaan asiakkaan tuotantopalvelimelle piti asentaa uusi TLS-sertifikaatti pian julkaistavaa verkkosivustoa varten. Asiakas toimitti sertifikaatin minulle pfx-muodossa. Pfx tiedostossa on pakattuna yhteen itse TLS-sertifikaatti, sekä sertifikaatin yksityinen avain (engl. private key). Pfx on Windows-käyttöjärjestelmälle ominai- nen tiedostoformaatti, eikä Foobarin käyttämä Nginx tue tämän tyyppisiä sertifikaatteja.

Täten oli tarpeellista eristää tiedostosta sertifikaatti sekä yksityinen avain, jotka puolestaan voidaan asentaa palvelimelle. Tämä on varsin yksinkertainen toimenpide, ja molem- pien komponenttien eristäminen pfx-tiedostosta onnistui yhdellä komennolla. Tämän jäl- keen asensin avaimen sekä sertifikaatin palvelimelle, ja konfiguroin Nginx:än käyttämään niitä halutun verkkotunnuksen varmistamiseen.

Seuraavaksi siirryin tutkimaan Foobar-cloud projektin pilviresurssien tilaa. Huomasin nopeasti, että VPC-ympäristö, johon olimme kollegoiden kanssa edellisviikolla pystyttäneet EKS-klusterin, ei ollut käyttökelpoinen. Redundanssin lisäämiseksi tarvitsemme kaksi kappaletta julkisia sekä privaatteja aliverkkoja, mutta VPC-ympäristö oli määritelty käyttä- mään pienehköä CIDR-osoiteavaruutta (engl. Classless Inter-Domain Routing). Tämä jätti verrattain alhaisen määrän IP-osoitteita per aliverkko, eikä tätä arvoa voinut jälkikäteen muuttaa VPC-ympäristön asetuksissa. Virkistin hieman muistia luokattoman reitityksen peruskonsepteista, ja rupesin kasaamaan uutta VPC-ympäristöä sekä aliverkkoja. VPC- ympäristön osoiteavaruudeksi valitsin 10.0.0.0/16, josta rikoin neljä kappaletta aliverkkoja EKS-klusterin käyttöön. Jokaisella aliverkolla on verkkomaskilla /21 tarjolla 2046 IP-osoitetta, joten käytössä on vain pieni osa koko VPC-ympäristön 65534 mahdollisesta IP- osoitteesta (Taulukko 2).

Taulukko 2. VPC-ympäristön ja sen aliverkkojen osoiteavaruudet

Selite CIDR Osoiteavaruus Osoitteiden määrä

VPC 10.0.0.0/16 10.0.0.0–10.0.255.255 65534

Aliverkko 1 10.0.0.0/21 10.0.0.0–10.0.7.255 2046 Aliverkko 2 10.0.0.0/21 10.0.8.0–10.0.15.255 2046

(22)

Lounaan jälkeen osallistuin päivän ainoaan kokoukseen, jossa kävimme läpi asiakkaan verkkopalveluun uuden toiminnallisuuden vaatimuksia ja siihen liittyviä työtehtäviä. Yläta- son kuvaus toiminnallisuudesta oli seuraava:

- Integroidutaan kolmannen osapuolen palveluun REST-rajapinnan avulla.

- Rajapinnasta palautuva data tulee jäsennellä tietyllä tavalla.

- Data tulee näyttää käyttäjälle tietyllä tavalla.

Kokous meni hyvin, ja saimme laadittua asiakkaalle alustavan tarjouksen työmääristä ja kustannuksista.

Iltapäivästä pidin vielä Azure demon asiakkaalle. Osallistujilla oli jonkin verran tietotek- nistä ymmärrystä, joten koulutuksen tunnin aikaikkunaan saatiin mahtumaan runsaasti asiaa. Kävimme läpi virtuaalipalvelimen pystyttämisen, yleisiä tietoturvakäytäntöjä palvelimen suojaamiseksi, verkkopalvelimien toimintaa yleisellä tasolla, sekä verkkotunnuksien kohdentamista palvelimelle.

Tälle päivälle ei ole suunnitteilla mitään erillisiä työtehtäviä, sillä koko iltapäivä menee De- vOps-tiimin kesken järjestettävässä ryhmätyökurssissa, jonka tarkoituksena on käydä läpi anonyymin, koko yrityksen laajuisen työhyvinvointikyselyn tuloksia, ja keskustella niistä.

Tämän lisäksi arvioin edistäväni hieman Foobar cloud-projektia.

Aloitin aamun käymällä läpi Slack-viestit ja sähköpostit, mutta niiden tiimoilta ei löytynyt mitään uusia työpyyntöjä, eli siirryin heti aamusta työskentelemään Foobar cloud-projektin pariin. Ajatuksena oli provisioida EKS-klusterille laskelmointitehoa, jotta päästään testaa- maan resurssien pystyttämistä klusteriin. Kuberneteksen näkökulmasta laskemointitehoa tuottavia yksiköitä kutsutaan solmuiksi (engl. node), ja ne ovat tyypillisesti yksittäisiä virtu- aalipalvelimia. Yritin useamman tunnin provisioida solmujoukkoa tuloksetta, mutta onnistuin kuitenkin tarkentamaan ongelman juurisyyksi EKS:än puutteelliset oikeudet.

Iltapäivän ryhmätyökurssi meni hyvin, ja saimme aikaan paljon mielekästä keskustelua ky- selyn tuloksista. Ryhmätyökurssi venähti pitkälle iltapäivään, joten en enää viitsinyt palata EKS:än äärelle, vaan lopetin työt tältä päivältä.

Aliverkko 3 10.0.0.0/21 10.0.16.0–10.0.23.255 2046 Aliverkko 4 10.0.0.0/21 10.0.24.0–10.0.31.255 2046

(23)

Torstai 23.09.2021

Tänään olen lähtökohtaisesti suunnitellut vain rakentavani erääseen asiakasprojektiin uuden kehitysympäristön. Projekti sijaitsee Azure-pilvipalvelussa, jonne tarvitaan tuotanto- ja testiympäristöjen lisäksi kolmas kehitysympäristö.

Päivä alkoi suunnitelmista poiketen ohjelmistojen ja käyttöjärjestelmäpäivitysten asentamisella. Huomasin että molemmat Docker sekä MacOS tarjosivat uusia päivityksiä, joten päätin aloittaa niiden asentamisella, ja päivitin samalla myös Brew-pakettimanagerin kautta asennetut ohjelmistot.

Ohjelmistojen päivittämisen jälkeen pääsin siirtymään kehitysympäristön pystyttämiseen.

Olen aikaisemmin pystyttänyt projektille testiympäristön, joten prosessi oli käytännön tasolla ennestään tuttu. Projekti kuitenkin vaatii laajasti erilaisia Azure palveluita toimiakseen, joiden kloonaaminen ja uudelleenkonfigurointi olemassa olevista resursseista oli suhteellisen työlästä. Verkkopalvelun frontend pyörii Azure web app-palvelun päällä, ja backend koostuu REST-rajapinnasta, joka paljastaa joukon backend-funktioita. Lisäksi palvelu käyttää Azure B2C aktiivihakemistoa käyttäjänhallintaan.

Saatuani tarvittavan infrastruktuurin pystyyn, kiinnitin uuden ympäristön vielä CI/CD-järjes- telmään, jota myös jo olemassa olevat ympäristöt käyttävät. Järjestelmä on toteutettu Azure DevOps-alustalle, ja on jostain syystä suunniteltu toimimaan hieman monimutkai- sesti. Backend rakennetaan ja julkaistaan YAML-tiedostoilla määritellyn prosessin kautta, mutta frontend käyttää puolestaan käyttöliittymän kautta määriteltyä prosessia. Eriytyneet konfiguraatiot tuottivat hieman lisätyötä, mutta sain lopulta myös uuden kehitysympäristön julkaisut toimimaan.

Tänään agendalla on ainakin hoitaa työpyyntö liittyen asiakkaan palvelinympäristön kloo- naamiseen, ja osallistua muutamaan viikkopalaveriin.

Päivä alkoi suunnitellusti palvelinympäristön kloonaamisella. Pointtina oli kopioida jo olemassa oleva tuotantoympäristö, joka voitiin sitten konfiguroida uudelleen toimimaan tes- tiympäristönä. Aloitin ottamalla varmuuskopiot tuotantopalvelimen kovalevystä, jonka jäl- keen pystytin uuden virtuaalipalvelimen, johon liitin varmuuskopioidun levyn. Konfiguroin seuraavaksi uuden testipalvelimen ymmärtämään testaamiseen käytettyjä verkkotunnuksia. Testipalvelimen tietokannassa oli myös joitain viittauksia tuotantopalvelimen verkkotunnukseen, jotka siivosin pois tietokantakyselyiden avulla.

(24)

Lounaan jälkeen oli aika ottaa osaa Foobar cloud-projektin viikkopalaveriin, jossa jouduin valitettavasti kertomaan, että en ollut vielä saanut aikaan toimivaa EKS-klusteria. Viikko oli ollut varsin kiireinen asiakasprojektien saralla, joten en ollut ehtinyt palaamaan alkuvii- kosta kohtaamani ongelman pariin, jossa EKS-klusteri ei hyväksy provisioitua solmuryh- mää.

Seuraavaksi osallistuin erään toisen asiakkaan viikkopalaveriin, jossa käytiin hieman läpi kuluneen viikon tapahtumia – en ole tällä viikolla osallistunut projektiin mitenkään, joten poistuin lyhyen tilannekatsauksen jälkeen lounaalle.

Iltapäivällä kerkesin hoitaa vielä kaksi pienempää työpyyntöä. Ensimmäinen liittyi asiakkaan tuotantopalvelimen uudelleenohjauksiin – www-aliverkkotunnuksen liikenne haluttiin uudelleenohjata pääasialliseen verkkotunnukseen. Toinen työpyyntö liittyi erään projektin Slack-kanavan notifikaatioihin. Kehittäjät halusivat saada ilmoituksia kanavalle aina, kun projektin Github repositorioon luodaan uusi vetopyyntö (engl. pull request). Github tukee notifikaatioiden automaattista lähettämistä http-kutsulla, jotka voidaan sitten kohdistaa Slack-kanavalle käyttäen Webhook herätteitä.

Viikkoanalyysi

Työtehtävät ovat tällä viikolla painottuneet pilvilaskenta-alustoille. AWS aiheutti päänvai- vaa EKS-klusterin tiimoilta, mutta välillisesti eniten tutkimustyötä tuli kuitenkin tehtyä liittyen identiteetin ja pääsynhallintaan, eli AWS IAM-palveluun (engI. Identity and Access Management). IAM-palvelu on vastuussa kaikkien AWS-rajapintoja käyttävien resurssien pääsynhallinnasta joko hyväksymällä tai hylkäämällä resursseihin kohdistuvia pyyntöjä.

Sallai (2021, 7–18) määrittelee IAM-palvelun päättävän pyynnön hyväksymisestä tai hyl- käämisestä neljän eri kriteerin kautta:

• Entiteetti (engl. principal) edustaa pyynnön tehnyttä tahoa. Se voi olla IAM-käyttäjä tai rooli, jokin toinen AWS-palvelu, tai anonyymi taho. Entiteetin voidaan siis miel- tää kuvaavan tekijää.

• Toimenpide (engl. action) määrittelee toimenpiteen, joka suoritetaan pyynnön teh- neen entiteetin nimissä. Toimenpide voi olla esimerkiksi S3-ämpärin resurssien lu- keminen, tai Lambda-funktion suorittaminen.

• Resurssi (engl. resource) spesifioi pyynnön kohteen, eli resurssin jolle pyynnössä määritelty toimenpide suoritetaan.

• Metadata on moninaista pyyntöön kiinnitettyä dataa. Esimerkkeinä pyynnön tulok- siin vaikuttavasta metadatasta on esimerkiksi pyynnön tehneen IAM-käyttäjän nimi, kuinka ja mistä pyyntö on tehty (IP-osoite, protokolla) ja pyynnön kohdere- surssin tunnisteet.

(25)

Alla oleva esimerkki (Kuva 6) demonstroi rajapintaan kohdistetun IAM-kutsun rakennetta.

IAM-käyttäjä ”user1” (entiteetti) haluaa lukea (toimenpide) kuvatiedoston S3-ampäristä (resurssi) ”website_images”. IAM-palvelu evaluoi kutsun, ja päättää hyväksytäänkö toimenpide.

Kuva 6. Esimerkki IAM pyynnön rakenteesta

IAM-roolit ja niiden konfigurointi ovat minulle ennestään tuttua puuhaa, vaikkakaan kokemusta erityisen suurista tai komplekseista rooleista ei ole. Pidän AWS identiteettien ja pääsynhallintaa konseptuaalisesti varsin yksinkertaisena, mutta ennen tätä viikkoa en ym- märtänyt miten käyttöoikeuksia evaluointi tapahtuu teknisessä mielessä.

Kutsun evaluointi alkaa kontekstin rakentamisella. AWS ei jaa teknisiä spesifikaatioita tä- män askeleen toiminnasta, mutta korkealla tasolla sen voidaan sanoa jäsentelevän rele- vantit tiedot kaikista yllä mainituista lohkoista – prinsipaali, toimenpide, resurssi sekä me- tatieto. Seuraavassa vaiheessa IAM-palvelu evaluoi kaikki tunnetut IAM-säännöt (engl.

policy), ja filtteröi pyynnön kontekstin perusteella pois sellaiset säännöt, jotka eivät ole re- levantteja pyynnön kannalta - IAM ei siis vielä tee päätöksiä kutsun hyväksymisestä tai hylkäämisestä. Viimeisessä vaiheessa IAM vertaa filtterin läpi päässeitä sääntöjä kutsua vasten, ja tekee päätöksen kutsun hyväksymisestä tai hylkäämisestä. (Sallai 2021, 66–72)

Logiikka kutsun hyväksymisen takana on monimutkaista, mutta alempi kuva (Kuva 7) summaa sen pääpiirteittäin hyvin. Pyyntö evaluoidaan ehtolausekkeiden tapaan askel ker- rallaan, alkaen eksplisiittisen kiellon tarkistamisesta. Kaavion – ja yleisesti IAM-pyyntöjen evaluoinnin logiikan – ymmärtämistä on ainakin itselleni auttanut se, että suurimmassa osassa tilanteita eksplisiittisen luvan puute johtaa pyynnön hylkäämiseen.

(26)

Kuva 7. IAM-pyynnön evaluointilogiikka (AWS 2021)

Tänään olen suunnitellut työskenteleväni Foobar Cloud-projektin parissa, sillä toimiva EKS-klusteri on edellytys projektin etenemiselle, eivätkä kollegat pääse työskentelemään tehokkaasti ennen sitä.

Työskentelin suunnitellusti koko aamupäivän ajan Foobar Cloud-projektin parissa, ja sain aikaan huomattavaa edistystä. Edellisviikolla esiin nousseet ongelmat solmujoukkojen provisiontiin liittyen ratkesivat eksctl-nimisen komentorivityökalun avulla. Eksctl on kolmannen osapuolen kehittämä, vapaan lähdekoodin ohjelmisto, joka on suunniteltu EKS- klusterien luomiseen ja ylläpitoon. Määrittelin EKS-klusterin sekä solmujoukkojen ominai- suudet YAML-konfiguraatiotiedoston, jonka pohjalta eksctl loi tarvittavat resurssit automaattisesti.

Lounaan jälkeen lähdin hahmottelemaan itse klusterin arkkitehtuuria ja rakennetta. Vaikka arkkitehtuurista olikin jo korkealla tasolla valmis suunnitelma, sen implementointi tuotti jonkin verran haasteita. AWS luo automaattisesti uuden kuormantasaajan aina, kun EKS- klusteriin luodaan uusi LoadBalancer-tyyppinen palvelu (engl. service). Käyttämämme Nginx-Ingressi kontrolleri ei tukenut suoraan NLB-tyyppistä kuormantasaajaa, joten jouduin muuttamaan Helm paketin konfiguraatioita jonkin verran saadakseni sen yhteensopi- vaksi. Saatuani kuormantasaajan sekä ingressi kontrollerin toimimaan, julkaisin klusteriin vielä kaksi erillistä testisovellusta reitityksen testaamiseksi. Sovellukset ja reititys toimivat halutusti, joskin TLS-sertifikaattien puute aiheutti hieman ongelmia Chrome-selaimella.

(27)

Tiistai 28.09.2021

Tänään suunnitelmissa on ainakin avustaa erään projektin OICD-kirjautumiseen liittyvien ongelmien selvittelemisessä, sekä valmistella erään asiakasprojektin tuotantoympäristö sivuston julkaisua varten.

Päivä alkoi suunnitellusti asiakkaan tuotantoympäristön konfiguroimisella. Palvelimella on kolme kappaletta asiakkaan verkkosivustoja, joista kaksi oli julkaistu edellisviikolla, ja nyt suunnitteilla oli kolmannen julkaisu. Asensin sivuston verkkotunnukselle TLS-sertifikaatin ja yksityisen avaimen, implementoin muutamia uudelleenohjauksia aliverkkotunnuksien välillä, ja poistin http-autentikoinnin sivustolta. Yrittäessäni ladata uudet konfiguraatiot, jotain odottamatonta kuitenkin tapahtui – Nginx prosessi ei pystynyt käynnistymään onnistuneesti, jonka seurauksena kaikki kolme verkkosivua olivat tavoittamattomissa. Sillä ky- seessä oli tuotantoympäristö, tilanne oli korjattava nopeasti. Paikansin ongelmat lokitie- dostojen avulla, joita oli kaksin kappalein – ensinnäkin Nginx ei pystynyt lukemaan sertifi- kaattitiedostoa, ja toiseksi sertifikaatin yksityinen avain oli salattu. Ensimmäinen ongelma ratkesi helposti avaimen salauksen purkamisella. Sertifikaattitiedoston lukuoikeuksiin liit- tyvä ongelma vaati hieman enemmän tutkimista – ongelmaksi paljastui lopulta SELinux, jonka asettamat oikeudet sertifikaattitiedostolle olivat väärin. Korjattuani oikeudet sain käynnistettyä Nginx prosessin onnistuneesti.

Iltapäivällä tutkin asiakasprojektin OICD (Open ID Connect) kirjautumiseen liittyviä ongelmia. Kirjautumisen fasilitoi Azure B2C-palvelu, jonka konfiguroimisesta minulla oli onneksi aikaisempaa kokemusta. Selvittelyn jälkeen palvelusta paljastui muutama toiminnan es- tävä ongelma: B2C:hen rekisteröity takaisinohjauspolku oli konfiguroitu väärin, jonka vuoksi kirjautuminen keskeytyi ennenaikaisesti. Lisäksi backend-palvelimen asiakastun- niste oli asetettu väärin. Molemmat ongelmat olivat kuitenkin onneksi helppo korjata.

Päivän agendaan kuuluu tänään kuukausittainen DevOps-tiimin kokous, erään asiakasprojektin sisäinen aloituskokous, sekä henkilöstökokous. Muun ajan keskityn DevOps-työ- jonon purkamiseen.

Päivän ensimmäiset työpyynnöt olivat GitHub-notifikaatioiden konfiguroiminen erään projektin Slack kanavalle, sekä TLS-sertifikaattien päivittäminen erään asiakkaan tuotantoym- päristöön. Olen hoitanut molempia työpyyntöjä vastaavia tehtäviä runsaasti, joten molemmat olivat varsin nopeasti hoidettu.

(28)

Seuraavana vuorossa oli erään asiakasprojektin sisäinen aloituskokous, jossa käytiin läpi projektin määrittelyjä, ja mietittiin yleisellä tasolla sen kulkua. Projekti tullaan toteuttamaan AWS-pilvipalveluun, ja siinä käytetään omasta mielestäni varsin moderneja teknologioita.

Mainitsemisen arvoista lienee etenkin projektin backend, joka toteutetaan serverless-ark- kitehtuurin mukaisesti AWS Lambda-palvelun avulla. Oma roolini tässä projektissa tulee olemaan ensisijaisesti AWS infrastruktuurin pystyttäminen ja konfigurointi, mutta toisaalta myös backend-kehittäjän tukeminen, sillä omaan aikaisempaa kokemusta serverless-kehi- tyksestä.

Henkilöstökokouksen ja lounaan jälkeen otin osaa kuukausittaiseen DevOps-tiimin kokoukseen. Käsittelimme kokouksessa yrityksen sisäisiä järjestelmiä ja infrastruktuuria, sekä CentOS käyttöjärjestelmän tulevaisuutta. Kokouksen jälkeen hoidin vielä yhden työpyynnön liittyen Nginx uudelleenohjauksiin.

Torstai 29.09.2021

Tänään suunnittelen käyttäväni aamupäivän Foobar Cloud projektin parissa, ja hoitavani iltapäivästä työpyyntöjä DevOps-työjonosta. Yritän jossain välissä myös tutkia hieman AWS Cognito-palvelua, jota olisi tarkoitus käyttää lähitulevaisuudessa eräässä asiakasprojektissa.

Aamupäivä meni suunnitellusti Foobar Cloud projektin kanssa työskennellessä. Ajatuk- sena oli asentaa klusteriin TLS-sertifikaatteja automaattisesti jakava resurssi, jotta uusien ympäristöjen julkaiseminen klusteriin olisi helpompaa. Onnistuin saamaan Let’s Encrypt- palvelun testirajapinnan allekirjoittamaan TLS-sertifikaatteja onnistuneesti, mutta oikeiden tuotantosertifikaattien saaminen ei vielä tuntemattomasta syystä onnistunut. Lisäksi kokei- lin http-autentikoinnin ja IP-osoitteiden rajaamista Nginx ingressin avulla.

Iltapäivällä hoidin työpyynnön Nginx uudelleenohjauksiin liittyen – tehtävä ei tuottanut ongelmia, sillä vastaavat uudelleenohjaukset kuuluvat nykyään lähes päivittäisiin tehtäviini.

Loppupäivän käytin AWS Cognito-palveluun tutustumiseen. AWS Cognito-palvelua tullaan käyttämään eräässä asiakasprojektissa, ja koska se on minulle ennestään tuntematon palvelu, päätin käyttää hieman aikaa siihen tutustumiseen. Cognito palvelu tarjoaa paljon erilaisia toiminnallisuuksia, mutta olin itse kiinnostunut lähinnä siitä, onko siihen mahdollista rekisteröidä ulkoisia palveluntarjoajia SAML-protokollan avulla. Päädyin pienen selvittelyn jälkeen siihen tulokseen, että Cognito täyttää kaikki projektille asetetut kriteerit, ja tä- ten sitä voidaan käyttää projektissa vahvan tunnistautumisen implementointiin.

(29)

Uskon eilisen Let’s Encrypt X3 TLS-kantasertifikaatin vanhenemisen vaikuttavan olennai- sesti tämän päivän työtehtäviin. Sertifikaatti on varmasti edelleen käytössä vanhemmilla palvelemilla, joten uskon tämän päivän pitävän sisällään ainakin jonkin verran päivitys- ja korjaustöitä tähän liittyen.

Aamu alkoi mielenkiintoisella tavalla, kun Slack-pikaviestin ei toiminut. Syy tähän selvisi Twitteristä: ongelmia nimipalvelun kanssa. Ongelman pysty onneksi korjaamaan väliaikai- sesti käyttämällä joko Googlen (8.8.8.8) tai Cloudflaren (1.1.1.1) DNS-palvelimia, joille uudet toimivat asetukset olivat jo propagoituneet.

Aamupäivän vietin pitkälti päivittelemällä TLS-kantasertifikaatteja vanhemmille palveli- mille, tai auttamassa muuten erinäisiä projekteja, joille oli koitunut haittaa sertifikaatin van- henemisesta. Ehdin kuitenkin ottaa osaa Foobar Cloud-projektin viikkokokoukseen, jossa esittelin tämän viikon edistymisen. Kokouksen jälkeen hoidin vielä muutamia pieniä työpyyntöjä DevOps-työjonosta, ja lähdin viikonlopun viettoon.

Viikkoanalyysi

Tällä viikolla työtehtävien joukosta on noussut esiin temaattisesti TLS-sertifikaatit, johtuen etenkin perjantaina vanhenneesta Let’s Encrypt X3 juurisertifikaatista. TLS sertifikaatteja käyttivät aikoinaan lähinnä pankit ja muut vastaavat arkaluontoista tietoa käsittelevät verk- kopalvelut, mutta tänä päivänä https-protokollan avulla kommunikointi (jonka TLS-sertifikaatti mahdollistaa) on pitkälti muuttunut poikkeuksesta säännöksi. Esimerkiksi monet suositut selaimet kuten Google Chrome ja Mozilla Firefox varoittavat käyttäjää erikseen sivustoista, jotka käyttävät normaalia http-protokollaa salatun https-protokollan sijaan.

TLS-salaus käyttää toimiakseen epäsymmetrisen salauksen metodia, jossa tiedon salaa- miseen ja purkamiseen käytetään kahta erillistä avainta. Tällaista salausmenetelmää kutsutaan julkisen avaimen salaukseksi (engl. Public-key cryptography). Salauksen toiminta perustuu siihen, että julkisella avaimella salattu tieto voidaan purkaa pelkästään avainpa- rin yksityisellä puoliskolla, tai toisin päin (Kuva 8). Avaimet toimivat aina pareittain, ja kum- mankaan avainpuoliskon päätteleminen toisesta on suunniteltu laskennallisesti mahdottomaksi – avainten luominen tapahtuu käyttämällä suurien alkulukujen tekijöihin perustuvia yksisuuntaisia funktioita, jotka ovat nopeita suorittaa, mutta äärimmäisen vaikeita kääntää takaisin. (Baka & Schatten 2020, 14–15)

(30)

Kuva 8. Julkisen avaimen salauksen toiminta

TLS-sertifikaattien toiminta on minulle tuttua korkealla tasolla, eikä niiden käyttäminen, hankkiminen tai uusiminen välttämättä edellytä syvällistä, teknistä ymmärrystä niiden toiminnasta. Viikon työtehtävien kautta huomasin kuitenkin kiinnostuneeni yhä enemmän TLS-sertifikaattien teknisemmästä puolesta. En usko TLS-salaukseen käytettävien krypto- grafisten operaatioiden tai matemaattisten kaavojen olevan ammatillisen kehitykseni kannalta välttämätöntä (tai edes tarpeellista), mutta koen, että oman ymmärryksen kartuttami- nen TLS-sertifikaattien käytännön implementaatioista ja toiminnasta olisi silti hyödyllistä.

Erityisen kiinnostavaksi osa-alueeksi itselleni nousi sertifikaattien luominen, ja niiden verifikaatio CA:n (Certificate Authority) toimesta.

TLS-sertifikaateista puhuttaessa viitataan käytännössä aina vuonna 1988 määriteltyyn x.509 standardin mukaiseen sertifikaattiin, joka on myönnetty virallisen CA:n toimesta palvelimen tai palvelimien varmennusta varten, ja kattaa yhden tai useamman isäntänimen.

(Baka & Schatten 2020, 54–56.) Sertifikaattia anotaan tietynlaisella CSR-pyynnöllä. (Certi- ficate Signing Request). Pyynnön luominen alkaa generoimalla uusi avainpari, jota TLS- sertifikaatti tulee käyttämään. Tämä avainpari, sekä kourallinen muita vaadittavia tietoja (Taulukko 3) enkoodataan base64-muotoon, ja lähetetään CA:lle verifioitavaksi. (Baka &

Schatten 2020, 45–46)

Taulukko 3. CSR metatiedot (Baka & Schatten 2020, 46)

Arvo Selite

Common Name This is the “primary” domain name for which a certificate will be valid.

Organisation Common Name The name of the organisation requesting the certificate.

(31)

Seuraavaksi CA:n täytyy varmistaa, että sertifikaattia pyytävä taho omistaa sen isäntäni- men (tai isäntänimet), joille sertifikaattia haetaan. Normaali isäntänimen verifikaatio tapahtuu varmistamalla, että sertifikaattia anova taho kontrolloi isäntänimeä globaalissa DNS verkossa. Yleinen käytäntö CA:n kannalta on pyytää sertifikaattia anovaa tahoa lisäämään spesifi DNS-tietue isäntänimelle, usein TXT tai CNAME. Myös sähköpostipohjainen verifikaatio on mahdollinen. Sertifikaatin myöntämisen jälkeen CA lisää oman uniikin tiivisteen sertifikaatin loppuun, jota asiakasohjelma (esim. verkkoselain) voi käyttää sertifikaatin ve- rifiointiin. (Baka & Schatten 2020, 44–47)

Sairasloma.

Tiistai 05.10.2021

Tänään suunnittelen osallistuvani kuukausittaiseen tietoturvakillan kokoukseen, sekä erään asiakasprojektin viikkopalaveriin. Lisäksi suunnittelen asiakkaan lomakepohjaisen sovelluksen testaamista.

Päivä alkoi tietoturvakillan kokoontumisella. Käsittelimme yrityksen sisäisten tietoturvakäy- täntöjen nykytilaa, sekä parannusehdotuksia. Lisäksi aloitimme uuden projektin, jonka tarkoituksena on kerätä lista tietoturvaan liittyvistä käytännön asioista, jotka olisi hyvä ottaa huomioon asiakasprojektien yhteydessä. Kokouksen jälkeen siirryin työstämään asiakkaan verkkolomake-pohjaisen sovelluksen testausta. Testauksen taustalla on monimutkai- set luku- ja muokkausoikeudet – lomakkeiden oikeudet perustuvat käyttäjien roolien li- säksi myös lomakkeisiin itseensä kiinnitettyihin sääntöihin. Testauksen aikana löytyi muutamia pieniä toimintavirheitä, joskaan ne eivät olleet oman harkintakykyni mukaan

Organisational Unit The department within the organisation requesting the certificate.

Locality The municipality of the organisation.

Region The full name of the state, province, or territory of the organisation.

Country Code Two-digit country code.

Subject Alternative Name The full list of DNS names for which the certificate will be considered valid.

(32)

kriittisiä, tai paljastaneet mitään arkaluontoista tietoa väärille käyttäjille tai rooleille. Rapor- toin havaintoni projektitiimille, ja suljin työpyynnön.

Iltapäivällä osallistuin asiakasprojektin viikkopalaveriin, jossa käytiin läpi projektin etene- mistä. Projekti on tällä hetkellä jatkokehitysvaiheessa, joten mitään erityisen kiireellisiä asioita ei ollut käsiteltävänä – omaan työjonoon kokouksen tiimoilta kuitenkin syntyi muutamia tehtäviä, jotka arvioin saavani hoidettua tämän viikon aikana.

Tarkoituksena on tänään edistää erästä asiakasprojektia, johon liittyen minulla on muutama avoin työpyyntö. Projektiin kiinnitetään lisäksi tänään uusi frontend-kehittäjä, joten oletan että aikaa kuluu tämän johdosta myös projektiin perehdyttämiseen ja lokaalin kehi- tysympäristön käynnistämiseen, sillä se on hieman monimutkainen. Lisäksi tiedossa on kuukausittainen team-lead kokous.

Aamu alkoi suunnitellusti asiakasprojektin parissa. Tehtävän oli selvittää, miksi testiympä- ristön kirjautuminen ei toiminut. Testiympäristö, kuten kaikki muutkin projektin ympäristöt, on asennettu Azure AKS (Azure Kubernetes Service) palveluun, joten lähdin selvittele- mään ongelmaa sieltä. Avasin testiympäristön backend-kontin lokitiedot, joista kävi ilmi, että kirjautumiselle kriittinen tietokantakysely palauttaa halutun datan sijasta tyyppivir- heen. Tietokantaa ylläpitää kolmannen osapuolen toimija, jonka takia en pystynyt selvittä- mään vikaa pidemmälle. Tarkistin versionhallinnasta onko kyselyyn tehty hiljattain muutoksia, ja lähetin aiheesta sähköpostin tietokantaa ylläpitävälle taholle. Tämän jälkeen avustin odotetusti projektitiimin uutta jäsentä pystyttämään paikallisen kehitysympäristön.

Lounaan jälkeen osallistuin team-lead kokoukseen. Kuukausittaisessa kokouksessa käy- dään yleensä läpi tiimien resursointitilanteet, sekä mahdollisesti muita ajankohtaisia tai tärkeitä aiheita. Kokouksen jälkeen palasin aamulla alkaneen työrupeaman kimppuun – vuorossa oli uuden tuotantoympäristön pystyttäminen AKS-klusteriin. Edistin tätä työpyyn- töä niin pitkälle kuin mahdollista, mutta jouduin kuitenkin jättämään sen lopulta hieman kesken, sillä asiakkaan nimipalveluun ei vielä oltu konfiguroitu ympäristön viimeistelemi- seen tarvittavia tietueita.

Torstai 06.10.2021

Päivän agendalla on useita sekalaisia työpyyntöjä. Aikomuksena on ainakin tutkia OICD- kirjautumiseen (Open ID Connect) liittyviä ongelmia, ajaa erään asiakkaan AWS

(33)

DynamoDB tietokantaan uutta sisältöä, sekä ottaa osaa tietoturva-killan fasilitoimaan aivoriiheen asiakasprojektien tietoturvan parantamiseksi.

Aloitin työpäivän suunnitelmien mukaisesti tutkimalla asiakasympäristön OICD-kirjautumista. OICD on OAuth2-protokollan päälle rakennettu menetelmä, jota käytetään sähköi- sen identiteetin varmentamiseen. (Bradley ym. 2014) Ympäristö ja sen resurssit sijaitsivat Azure-pilvipalvelussa, joten aloitin tutkimustyön käymällä läpi palveluiden ja resurssien asetukset, sekä lähdekoodin kirjautumista koskevat osat. Noin tunnin tutkimisen jälkeen minulle ei vieläkään ollut selvää miksi kirjautumisen toiminnassa oli ajoittain ongelmia – kaikki resurssit olivat nähdäkseni konfiguroitu oikein. Sillä lokitietoja edellisistä tapauksista ei ollut saatavilla, päätin olla käyttämättä työpyyntöön enempää aikaa. Sovin projektitiimin kanssa palaavani asiaan uudestaan, jos ongelma vielä ilmaantuu.

Seuraavana oli vuorossa datamassan ajaminen asiakkaan DynamoDB tietokantaan. Data toimitettiin Excel tiedostossa, joten se oli ensin jäsenneltävä DyanmoDB:n ymmärtämään JSON formaattiin. Hoidin tämän kirjoittamalla lyhyen Python ohjelman. Seuraavaksi käytin AWS:än ohjelmistokehityspaketista (SDK, Software Development Kit) löytyvää Python-kir- jastoa datan syöttämiseksi tietokantaan.

Iltapäivällä osallistuin tietoturvakillan aivoriiheen, jonka tarkoituksena oli kartoittaa erilaisia tietoturvakäytäntöjä, ja miten ne toteutuvat asiakasprojektien kontekstissa. Foobar ottaa tietoturvan vakavasti, joten mitään selkeitä ongelmia tai aukkoja emme löytäneet – aina on kuitenkin jotain parannettavaa, ja kokouksen pääteeksi olimmekin saaneet listattua muutamia hyviä seikkoja tietoturvan kehittämiseksi entisestään.

Tämän päivän kulkua on vaikea arvioida etukäteen. Vaikka työjonossa on jonkin verran tehtäviä odottamassa, ne ovat tällä hetkellä jumissa itsestäni riippumattomista syistä. Us- kon päivän tulevan koostumaan lähinnä spontaanien työpyyntöjen selvittelemisestä.

Aamu alkoi työpyynnöllä, jonka mukaan erään asiakkaan ympäristöihin piti asentaa TLS- sertifikaatit. Tähän kyseiseen asiakkaaseen viitataan tekstissä tästä eteenpäin nimellä Sa- lama. Pienen selvittelyn jälkeen paljastui, että sertifikaattien asentaminen ei nykyisellä arkkitehtuurilla ollut mahdollista. Verkkopalvelun frontend tarjoillaan Azuren storage ac- count-palvelusta staattisena verkkosivuna, eikä tähän palveluun ole mahdollista asentaa omaa TLS-sertifikaattia. Raportoin tilanteen projektipäällikölle, ja esitin muutaman eri vaih- toehdon tilanteen korjaamiseksi: Application Gateway-palvelu tai CDN (Content Delivery