VABAKAVA:3 taaskasutuse tagasitulek

JÄRJEKORDNE TAASKASUTUS

Kui on suur soov ametit vahetada siis tuleb ka teha palju kodutöid. Seega taaskord kasutan võimalust ja taaskasutan kirjatöid. "PSSSSS" rohkem neid taaskasutusi ei tule, kuna antud kirjatöö kandis vilja ja saan alustada peagi uuel ametipostil😉!

Lähteülesanne

Soovime majutada avalikult kättesaadavat WordPressi veebilehte, mille kasutuskoormus on ajas muutuv ja võib periooditi olla väga suur. Veebileht kuvab ilmaandmeid ning selle kasutatavus sõltub otseselt ilmastikutingimustest – kasutuskoormus kasvab eelkõige intensiivsete vihma- ja lumesadude ajal.
Veebi sihtgrupiks on peamiselt Eesti elanikud ning lahendus peab olema suunatud Eesti-sisesele kasutusele.
Asutuse põhimõtete kohaselt peab igal veebiteenusel olema:
LIVE-keskkond – avalikult kättesaadav tootmiskeskkond
TEST-keskkond – LIVE-keskkonnaga funktsionaalselt ja konfiguratsioonilt identne, kuid mitte avalikult ligipääsetav
Infoturbe nõudest tulenevalt peab teenus olema majutatud asutuse enda virtuaalmasinatel või asutuse enda hallatavas Kuberneteses.
Veebi lähtekood asub GITis.
Kirjelda sinu poolt soovitatud lahenduse arhitektuuri ning CI/CD pipeline ülesehitust.
Eeldame, et lahenduse kirjeldamisele kulub maksimaalselt 2 tundi. Mõistame, et selle ajaraami jooksul ei ole võimalik kõiki detaile ammendavalt käsitleda ning ootame pigem arhitektuurset ja kontseptuaalset kirjeldust.

Kirjatükk ise

Käesolev dokument kirjeldab asutuse avalikult kättesaadava WordPressi-põhise 

ilmainfo veebilehe majutuse arhitektuuri. Süsteemi peamine väljakutse on ajas tugevalt 

muutuv kasutuskoormus, mis on otseses korrelatsioonis ilmastikutingimustega. 

Ekstreemsete ilmaolude korral peab platvorm suutma koheselt skaleeruda, et 

teenindada tuhandeid samaaegseid kasutajaid. 

Turvanõuetest lähtuvalt on kogu lahendus majutatud asutuse enda hallatavas VMware 

virtuaalkeskkonnas asuvas Kuberneteses. Rakendatud on range LIVE- ja TEST

keskkondade eraldatus, kus TEST-keskkond on funktsionaalselt identne LIVE-iga, kuid 

isoleeritud sisevõrku. Haldus- ja juurutusprotsess põhineb kaasaegsel GitOps 

metoodikal.

1. Alus-infrastruktuur ja Operatsioonisüsteem 

Kuna koormustippude ajal on uute ressursside kättesaadavuse kiirus kriitilise 

tähtsusega, on alus-infrastruktuur optimeeritud spetsiaalselt konteinerite 

jooksutamiseks. 

        • Hüperviisor: Süsteem jookseb asutuse VMware vSphere (ESXi) klastris. 

        • Baas-operatsioonisüsteem: Kubernetese töömasinate operatsioonisüsteemina kasutatakse VMware Photon OS-i. See on spetsiaalselt vSphere'i keskkonnale optimeeritud ja äärmiselt õhuke  Linuxi distributsioon. 

        

    • Eelised: Erinevalt traditsioonilistest "paksudest" operatsioonisüsteemidest, 

käivitub Photon OS sekunditega, tarbib minimaalselt CPU-d ja mälu ning omab 

oluliselt väiksemat ründepinda. See on kriitiline eeldus, et süsteem suudaks 

tormi ajal klastrisse uusi servereid luua minutite, mitte kümnete minutitega.

2. Süsteemi Üldarhitektuur ja Komponendid 

Lahendus tugineb mikroteenuste arhitektuurile. 

2.1 Võrguliiklus ja Ingress 

Kogu kasutajaliiklus suunatakse läbi koormusjaoturi Kubernetese Ingress Controllerile (nt NGINX või Traefik), mis vastutab TLS-sertifikaatide halduse ja domeenipõhise ruutimise eest. Avalik liiklus (LIVE) ja sisevõrgu liiklus (TEST) on eraldatud Ingressi reeglite ja/ või asutuse enda võrgupoliitikatega 

2.2 Rakenduse kiht (WordPress) 

WordPress on disainitud töötama muutumatu rakendusena. Rakenduse lähtekood, teemad ja pistikprogrammid pakitakse CI/CD protsessi käigus standardseks konteineri imagesse ning laaditakse asutuse konteinerite registrisse.

 

Käitluskeskkonnana toimiv Kubernetes tõmbab registrist vajaliku tõmmise versiooni ja käivitab selle oma klastris Pod'idena. Selline lähenemine lahutab rakenduse koodi täielikult alus-infrastruktuurist ning võimaldab WordPressi koopiate (Pod'ide) arvu dünaamiliselt ja sekunditega skaleerida, ilma et igasse uude serverisse tuleks tarkvara käsitsi paigaldada. 

2.3 Andmebaas, Vahemälu ja Salvestus 

• Andmebaas: Kasutatakse MariaDB klastrit, et tagada relatsiooniliste andmete 

käideldavus ja jõudlus. 

• Vahemälu (Redis): Süsteemi peamine koormuse leevendaja on Redis 

objektivahemälu. Suure liikluse ajal teenindatakse enamik päringuid otse Redise 

mälust, säästes andmebaasi ülekoormusest. 

• Failisalvestus: Dünaamilise sisu (wp-content/uploads) jaoks kasutatakse 

jagatud kettaruumi (NFS/CephFS), mis on ühendatud kõikidele WordPressi 

pod'idele samaaegselt.

3. Skaleeruvus ja Koormustippude Haldus 

Skaleerumine on jaotatud kaheks tasemeks, et tagada nii kohene reageerimine kui ka pikaajaline vastupidavus: 

        1. Kohene reageerimine (Konteinerite skaleerimine): Horizontal Pod Autoscalerjälgib liiklust ja CPU kasutust. Liikluse kasvades luuakse olemasolevatesse Photon OS masinatesse sekunditega uusi WordPressi pod'e juurde (nt 2 -> 20+).

 

        2. Infrastruktuuri skaleerimine: Kui olemasolevates Photon OS node'ides saab ressurss otsa, suhtleb Kubernetese Cluster Autoscaler otse VMware vCenteri 

API-ga. Süsteem kloonib automaatselt uue Photon OS virtuaalmasina. Tänu 

Photon OS-i kergusele laaditakse uus masin üles ja liidetakse klastriga 

erakordselt kiiresti, võimaldades uutel WordPressi pod'idel tööd alustada. 

4. Keskkondade Eraldatus ja Turvalisus 

        • Isolatsioon: LIVE ja TEST on eraldatud nii namespace'ide andmebaaside 

instantside kui ka failisalvestuse tasemel. 

        • Network Policies: Klastrisisesed võrgupoliitikad piiravad suhtlust – näiteks 

WordPress tohib rääkida ainult oma keskkonna andmebaasi ja Redisega ning 

TEST keskkonnale on välisvõrgust ligipääs keelatud. 

        • Saladuste haldus: Sensitiivne info hoitakse välises süsteemis (nt HashiCorp Vault või asutuse turvahoidla) või krüpteeritud K8s Secrets objektidena. Neid ei lisata kunagi Git repositooriumisse. 

        • WAF (Web Application Firewall): Ingressi tasemel rakendatakse reegleid, mis kaitsevad süsteemi levinud rünnakute ja pahatahtliku liikluse eest.

5. CI/CD Konveier ja GitOps Töövoog  

Tarkvara tarneprotsess on ehitatud GitOps metoodikale, mis tähendab, et Kubernetese klastri reaalne seis on alati sünkroonis Git repositooriumites kirjeldatud deklaratiivse seisuga. Kogu protsess on automatiseeritud alates koodi kirjutamisest kuni LIVE keskkonda jõudmiseni, välistades käsitöövead. 

5.1 Repositooriumite eraldamise strateegia 

Vältimaks lõputuid ehitustsükleid ja hoidmaks õigused selgena, on koodibaas jagatud kahte eraldi Git repositooriumisse: 

        1. Rakenduse repositorium: Sisaldab WordPressi kohandatud teemasid, 

pistikprogramme, konteineri definitsioonifaili ja rakenduse teste. Siin toimetavad 

peamiselt arendajad. 

        2. Infrastruktuuri repositorium: Sisaldab Kubernetese manifeste (Helm chartid või Kustomize failid), mis kirjeldavad LIVE ja TEST keskkondade seisu (Ingressid, HPA-d, Service'id, image'ite versioonid). Siin toimetab ArgoCD ja CI/CD automaatika. 

5.2 Pideva Integratsiooni faas  

See faas käivitub automaatselt, kui arendaja teeb muudatuse Rakenduse 

repositooriumi peaharusse . CI platvormina kasutatakse asutuse eelistatud lahendust. 

        • Samm 1: Koodi kontroll: Kontrollitakse PHP koodi süntaksit ja käivitatakse 

rakenduse taseme ühikutestid. Tuvastatakse ka kogemata koodi sisse jäänud 

saladused. 

        • Samm 2: Konteineri ehitamine: CI server võtab ametliku WordPressi baas

image'i ja lisab sinna sisse asutuse teemad ning pluginad. Tulemuseks on 

muutumatu Docker image. Image märgistatakse unikaalse sildiga. 

        • Samm 3: Turvaskaneerimine: Enne image'i registrisse laadimist skaneeritakse seda tuntud turvaaukude osas tööriistaga nagu Trivy. Kriitiliste leidude korral konveier peatatakse. 

        • Samm 4: Registrisse laadimine: Edukalt skaneeritud image laetakse asutuse privaatsesse konteinerite registrisse. 

        • Samm 5: Infra Repo uuendamine: CI server teeb automaatse commit'i 

Infrastruktuuri repositooriumisse, muutes TEST-keskkonna failis WordPressi 

image'i sildi uueks.

5.3 Pideva Juurutamise faas 

Siit võtab töö üle klastri sees elav ArgoCD. Konteinerite registril või CI serveril puudub igasugune ligipääs LIVE või TEST Kubernetese klastritele. 

        • Samm 6: TEST-keskkonna sünkroniseerimine: ArgoCD märkab, et Infra Repos muutus TEST-keskkonna manifest. Ta tõmbab muudatuse ja rakendab uue seisu wordpress-test namespace'i. Photon OS baasil Kubernetes käivitab uued 

konteinerid ja suunab liikluse neile. 

        • Samm 7: Automaattestid TEST-keskkonnas: Kui ArgoCD on TEST-keskkonna edukalt uuendanud, käivitatakse automaatsed lõppkasutaja testid (nt Playwright või Cypress), et veenduda lehe korrektses kuvamises ja ilmainfo laadimises. Vajadusel tehakse ka lühike koormustest. 

        • Samm 8: Juurutamine LIVE-keskkonda: Kui TEST-keskkonna testid on edukad, ootab süsteem vastutava isiku  manuaalset kinnitust, kuna ilmainfo näol on tegemist kriitilise teenusega. 

                 • Kinnitamisel kopeerib CI/CD automaatika uue image'i sildi Infra         Repo LIVE-keskkonna konfiguratsioonifaili. 

        • Samm 9: LIVE-keskkonna sünkroniseerimine: ArgoCD tuvastab LIVE

konfiguratsiooni muutumise ja teeb klastris wordpress-live namespace'is sujuva, 

katkestusteta  uuenduse uuele versioonile. 

5.4 Tagasirullimine anomaaliate korral 

Kui peale LIVE-juurutust selgub, et süsteemis on viga, on tagasirullimine triviaalne: 

        1. Administraator teeb Infrastruktuuri repositooriumis viimasele commit'ile git revert. 

        2. ArgoCD märkab, et Giti seis muutus tagasi eelmise versiooni peale. 

        3. ArgoCD taastab LIVE-klastris automaatselt ja minutitega eelmise stabiilse seisu.

6. Skaleeruvuse ja koormustaluvuse testimine 

Skaleeruvuse testimise (Load ja Stress Testing) eesmärk on simuleerida intensiivsest ilmastikust tingitud äkilisi liikluse kasve (nn "tormi simuleerimine") ning jälgida süsteemi automaatset reageerimist. 

        • Koormustestide tööriistad: Testimiseks kasutatakse kaasaegseid tööriistu (nt k6, Locust või JMeter), mis suudavad tekitada lühikese aja jooksul tuhandeid 

samaaegseid päringuid. Testid käivitatakse reeglina TEST-keskkonna vastu. 

        

        • HPA ja Cluster Autoscaleri valideerimine: 

                o Samm 1: Skript genereerib äkilise liikluse kasvu (näiteks 100 päringult sekundis 5000 päringuni sekundis).

 

                o Samm 2: Monitooritakse reageerimisaega – kui kiiresti reageerib 

Horizontal Pod Autoscaler ja käivitab uued WordPressi konteinerid. 

                o Samm 3: Jälgitakse Cluster Autoscaleri tööd – kui klastri olemasolev 

ressurss ammendub, mõõdetakse aega, mis kulub uue Photon OS virtuaalmasina loomiseks VMware'is, selle klastriga liitumiseks ja liikluse vastuvõtmiseks. 

    • Vahemälu efektiivsuse kontroll: Jälgitakse Cache Hit Ratio näitajat. Koormustesti ajal peab andmebaas koormus jääma stabiilseks, samas kui Redis võtab vastu enamiku lugemispäringutest.

lisainfo kodutöö kohta

Kasutasin ai-d natukene raskemalt, kuna "eelmine" nädal oli puhkusreis, kuhu ei soovinud arvutit kaasa vedada ja otsustasin teha asju ette, samale nädalale juhtus to eelmine vabakava kodutöö ja ka 2 nädalateemat. Ma ei kirjutanud ühes nädalas nii palju ka oma kutseka lõputööd kirjutades. seega olin kirutamisest juba väsinud ja ai-d inimlikumaks ei jaksanud enam teha (vist unustasin ka mainida, et käesoleva kirjatöö kirjutasin valmis reisile eelneval päeval).
Aga mis seal ikka, ju sobib ka see postituseks, töö ma omale sain, miks ei peaks ka 2 punkti saama 😉.