Uudised, sündmused ja blogi

Töötavat süsteemi ei torgita - bull... ehk Teh31 osa 2

Aga nüüd siis minu oodatuima teema juurde. Saksa domeeniregistri tarkvaraarenduse osakonna juht Marcos Sanz Grossón rääkis tarkvara pideva tarne lahendusest .de registris. Oleme samm-sammult EISis liikunud oma tarkvaraarendusega selles suunas, kuid mind on vaevanud küsimus, kas seda sama põhimõtet ei saaks ka muu tarkvara nagu operatsioonisüsteemid, andmebaasi tarkvara, püsivara ja muu kolmandate osapoolte poolt arendatava tarkvara haldamise juures kasutada - miks käivad tarkvaraarendus ja süsteemide administreerimine nii erinevaid radu. Sakslased tõestasid, et see ei pea nii olema.

Serveri operatsioonisüsteemi uuendamiseks ei pea ootama teise täiskuu öö, kolmandat tundi, vaid seda saab ja lausa peab tegema kohe. CID (Continuous Integration and Delivery ehk tarkvara pidev integratsioon ja tarne) põhimõte on, et valmis lahendused tuleb viivitamatult lõpptarbijani viia. Agiilse ehk kiire/paindliku tarkvaraarenduse maailmast pärit idee järgi peavad tarkvara parandused ja uuendused jõudma kasutajani kohe kui need on valmis. "Vanasti" eelistati uuendused kokku koguda ühte suurde kuhja, et siis ühel teatud kuuvalgel ööl kõik korraga ära paigaldada. CID maailmas tehakse seda, aga kasvõi mitu korda päevas.

Denic alustas projektiga juba 2011 aastal, ajendiks vajalike arenduste ja süsteemiuuenduste paigaldamise edasilükkamise tagajärjel tekkinud suured raskused leitud turvavea lappimisel - operatsioonisüsteemi tuuma, teekide ja rakenduste korraga uuendamine... Loogika lihtne: kriitilises olukorras mahukaid muudatusi sisse viia on halb praktika.

CID süsteem on üles ehitatud konveieri (pipeline) põhimõttel, kus on eraldi loogiline liin taristule ja registritarkvarale. Testsüsteem laeb versioonihaldusest automaatselt uue versiooni ning läbib seejärel kaks eraldi testprotsessi - esimene on nö paikamise või uuendamise test, teine aga kogu süsteemi uuesti seadistamise test. Lisaks paigaldamisele läbib tarkvara ka kõik võimalikud sisulised automaattestid. Olulisem ja huvitavam neist testimise radadest on teine, mille osas jõudsime põhimõttelisele nõusolekule, et pikemas perspektiivis pole paikamise testi ehk isegi vaja.

Puhta platvormi lähenemine põhineb objekt-orienteeritud tarkvaraarendusest pärit mõistel immutable object ehk antud juhul tõlkes muutumatu server (immutable server). See on server, mis püsib muutumatuna kogu oma eluea vältel. Kui on vajalik mingi uuendus, siis pannakse selleks automaatselt püsti uus testid läbinud server ning vana kustutatakse. Ka vigade, viiruste, troojalaste või muude taoliste probleemide korral on esimene samm serveri kustutamine ja uue nullist paigaldamine. Nii on tagatud, et üksteist dubleerivad serverid on alati identsed ja paljud intsidendid leiavad kiire lahenduse. Ka süsteemi taastamine kriisiolukorras on tänu igapäevasele süsteemi taaspaigaldamise praktikale pingevaba.

Denic rakendab ka ainult rollforward põhimõtet ehk probleemi avaldumisel toodangu keskkonnas ei minda tagasi eelmisele versioonile, vaid lahendatakse probleem, täiendatakse teste ja paigaldatakse parandatud versioon. Nagu reeglitega ikka, tehakse ka siin vajadusel erandeid - korra on ette tulnud, et kõik testid läbinud lahendus osutus toodangu keskkonnas reaalse koormuse juures liiga aeglaseks. Probleemi kriitilisusest ja lahenduse leidmise ajanõudlikkusest lähtudes taastati selles olukorras uuenduse eelne versioon.

Branching ehk tarkvaraveresioonide harud on keelatud. Kasutatakse funktsionaalsuse lülitamise (feature toggle) lähenemist, kus veel valmiva tarkvara omaduse kood jõuab koos teiste versioonihaldusesse laetud täiendustega toodangusse, kuid funktsioon ise lülitatakse sisse alles siis kui see on avalikustamiseks valmis.

Tarkvarauuenduste toodangusüsteemi paigaldamisel kasutatakse sini-rohelist tarnet (blue-green deployment). Paralleelselt on kaks toodangu serverit. Testid edukalt läbinud tarkvaraversioon paigaldatakse sinise serverina. Käivituvad veel viimased suitsutestid ning kui kõik korras, muudetakse sinine server roheliseks ehk sellest saab uus reaalses kasutuses olev toodangu server. Selliselt on versiooni uuendused sisuliselt silmapilksed. Ainsa probleemina sini-rohelise ümberlülituse juures tõid sakslased välja olekuga (stateful) ühenduste katkemise - kui registripidaja EPP lahendus sellist olukorda hallata ei oska, tuleb registripidajal ühendus käsitsi taastada.

Kõik tarkvarauuendused jõuavad lõppkasutajani maksimaalselt 24 tunni jooksul.Kogu süsteem on dubleeritud kahes geograafiliselt lahus olevas asukohas, kus kummaski on oma sini-roheline tarnelahendus. Süsteem pole küll veel valmis, puudu on näiteks kvaliteeditestid (turbetestid, koormuse testid jne) ning andmebaasi uuenduste rakendamine toimub käsitsi, kuid tulemus on muljetavaldav ja pakub palju võimalusi eeskuju võtmiseks.

Nagu ikka sellistel kohtumistel, peitub suur osa väärtusest ka teiste registritega suheldes kogutavas infos, mõtetes ja ideedes. Huvitavat statistikat - Rootsi register (.se) pani sügisel müüki oksjoni korras 349 seni reserveeritud või blokeeritud domeeni, peamiselt riiginimed ja tähised, mida senini polnud võimalik registreerida. Tänaseks on esimesed paarkümmend müüdud keskmise hinnaga umbes 4000€ domeen - ka meil on päris pikk nimekiri reserveeritud domeenidest...

Taani riik pani seadusesse nõude, et kõigi Taani eraisikust .dk domeeni registreerijate nimed, isikukoodid ja postiaadressid peavad märtsiks 2015 domeeniregistris vastama rahvastikuregistri andmetele. Kehtib see loomulikult vaid Taani kodanikest registreerijate ja kontaktide kohta. Miks seda tehti, teavad ilmselt vaid seadusandjad ise, kuid positiivne väljund sellest on tuvastatud kontaktide andmete automaatne uuendamine domeeniregistris kui kodanik oma kontaktandmeid rahvastikuregistris muudab. Tehniliselt lihtne, kuid kehva andmekvaliteedi ja tihti vananenud andmete tõttu raksesti teostatav ülesanne, jätab registri hinnangul ilmselt ligi 300 000 kontakti registris nõutud vasteta. Mis nendest kontaktidest ja nendega seotud domeenidest saab, ei tea veel keegi. Tõin selle välja, sest ka meie kontrollime Eesti domeeniomanike andmeid äri- ja rahvastikuregistrite vastu, kuid eesmärgiks on kontaktandmete asemel lihtsalt kontrollida ,kas isik eksisteerib. Kontaktandmete sidumine riiklike registritega on aga täiesti uus mõte :)

Domeeniregistrite maailmas, nagu ilmselt ka mitmel pool mujal, tehakse pajusid asju, sest naabrid teevad sama - mõned sellised nähtused on registrite sertifitseerimine ISO27001 ja registrilukk. Juba mõnda aega on registrilukk kuum teema, ridamisi registreid teatas jälle selle juurutamisest või arendamisest. Lühidalt on tegemist lahendusega, mis võimaldab domeeni registreerijal oma domeeni andmed lukku panna ning muudatuste tegemine eeldab siis juba lisaks registripidajale tüüpiliselt ka registri sekkumist. Registriluku vajalikkuse üle olen pikalt mõelnud ja kõhelnud, kas mitte ei tegeleta siin probleemi asemel sümptomitega. Ajendiks on domeeni andmete kaitsmise vajadus nõrkade registripidajate süsteemide kaudu teostatud rünnete eest. Õigem oleks tegeleda registri ja registripidaja süteemide vahelise liidestusega näiteks läbi kahetasemelise autentimise kasutades masinliideste (API) puhul füüsilisi tongleid nagu kasvõi YubiKey (vaata ka postitust "Registripidajate identifitseerimine ja autentimine") ja kasutajapõhiste lahenduste korral elektroonilist ID-d või TOTP protokollil põhinevaid lahendusi. Meie teenuste osakond on välja pakkunud, küll registreerija oma admin kontakti eest kaitsmise probleemi lahendades .uk ja veel mõne registri eeskujul registreerijalt täiendava kinnituse küsimise, mis on ka sisuliselt registriluku üks võimalikest vormidest. Registrilukule võiks pühendada täiesti omaette postituse. Olgu siis praegu lihtsalt öeldud, et minu arvates lahendatakse registrilukuga valet asja, kuid probleem on olemas ja tekitanud registreerijate hulgas juba nõudluse sellise teenuse järele.

Päevakava ja esitlused on leitavad CENTRi kodulehelt https://centr.org/Tech31. Järgmine tehnilise töögrupi kohtumine toimub juuni esimesel nädalal Stokholmis.