RSO Končni zagovori TO-DO

[jstavanja]

RSO KONČNI ZAGOVORI to-do

1. Uvod

• [x] Mikorstoritve naj vsebujejo zadostno količino funkcionalnosti za demo rešitev zadanega projekta.

  • [ ] frontend login (komunikacija z auth serviceom)
  • [x] frontend poslušanje komadov (komunikacija z media-storage)
  • [x] nek admin panel treba nardit za upload komada (komunikacija z media storage, ki mora znat desifrirat JWT token, če je nekdo admin (to preveri pri auth modulu) in pol še komunikacija s katalogom, ki ga media storage pokliče i guess)

    2. Naloga

    2.1 Zasnova arhitekture

• [x] shemo mikrostoritev in njihovih interakcij,

• [x] primere sporočil in zahtevkov, ki jih bo obdelovala aplikacija, nekaj kompleksnejših zahtevkov, pri obdelavi katerih bodo sodelovale vsaj tri mikrostoritve. (to je tisto shranjevanje komada)

• [x] Zasnovo arhitekture objavite v enega izmed repozitorijev. Lahko dodate tudi poseben repozitorij za dokumentacijo.

  • [x] tuki je treba osvežit vse pol na koncu da bo štimalo

2.2 Vzpostavitev zvezne integracije

• [X] Check, če je za vse service?

• [X] vse spremembe iz GitHub veje master prevede in zapakira (build)

• [ ] izvede teste enot (unit testing) – teste bomo dodali v nadaljevanju semestra (a to dejansko rabmo / smo dodali v nadaljevanju semestra?)

• [X] ustvari novo sliko Docker

• [X] objavi sliko na portalu Docker Hub.

3. Naloga

Seznanite se z naslednjimi koncepti upravljanja konfiguracije, ki jih bomo uporabljali v nadaljevanju semestra (ter preverjali na zagovorih, kolokvijih in izpitih).

Tu je treba mal tku verbalnu predebatirat in preštudirat pomojem.

• [X] Konfiguracija mikrostoritev z uporabo okoljskih spremenljivk.
• [X] Kdaj uporabimo ta način konfiguracije?
• [X] Kakšna je podpora s strani izbranega mikrostoritvenega ogrodja? Zakaj je pomembna?
• [X] Kakšna je prioriteta okoljskih spremenljivk v izbranem mikrostoritvenem ogrodju in zakaj?

Definiranje okoljskih spremenljivk ob zagonu vsebnikov Docker.

Tu pa je treba mal sprobat še enkrat tku na hitru.

• [X] Preučite in testiranje načine definiranja okoljskih spremenljivk v okoljih Docker in Docker compose.
• [X] Vaše mikrostoritve zaženite v okolju Docker in pri tem konfiguracijske vrednosti, specifične za zagon v določenem okolju (npr. konfiguracija povezave na bazo), definirajte z uporabo okoljskih spremenljivk.
• [X] Namestitev ponovite, tokrat z uporabo orodja Docker compose.

Pripravite načrt upravljanja s konfiguracijo v vaši aplikaciji. Pri tem:

• [ ] identificirajte vso konfiguracijo vaše aplikacije (use passworde, urlje do baz itd. je treba najt pa ruknt v neke ENV variable),
• [ ] ločite implementacijo in konfiguracijo – konfiguracijo naj bo mogoče spreminjati brez ponovnega prevajanja in nameščanja mikrostoritve (ta gre hand in hand z zgornjo?),
• [x] predvidite uporabo različnih virov konfiguracije, npr. konfiguracijske datoteke, okoljske spremenljivke, konfiguracijski strežnik...,
• [ ] na smiselnem primeru podprite dinamično rekonfiguracijo storitve, npr. z uporabo konfiguracijskega strežnika (tu nam manjka, mogoče to za logging un url od logstasha tlele loh ruknemo notr).
• [x] V ogrodju KumuluzEE lahko uporabite razširitev KumuluzEE Config (or not :D).

Odkrivanje storitev

Odkrivanje storitev v okolju Docker.

• [X] V primeru zagona mikrostoritve in pripadajoče podatkovne baze kot dveh vsebnikov Docker je potrebno v mikrostoritvi določiti naslov vsebnika s podatkovno bazo. Zaradi dinamične narave okolja Docker ne uporabimo IP naslova vsebnika, temveč vgrajen mehanizem za odkrivanje vsebnikov. (to mamo že pr docker-composeu od auth npr)
• [X] Preučite in preizkusite odkrivanje vsebnikov z uporabo koncepta Docker network (npr. docker network ls) in imenom vsebnika ter odkrivanje vsebnikov znotraj namestitve Docker compose. (probamo na roke)

Zasnova in implementacija odkrivanja storitev v vaši aplikaciji.

• [x] Posodobite implementacijo vaših obstoječih mikrostoritev tako, da bodo vsi klici med posameznimi mikrostoritvami implementirani s pomočjo odkrivanja storitev. Statično kodiranje povezav med mikrostoritvami ni sprejemljivo. (kot tam pri auth modulu, pa tudi pri catalog-management?)
• [x] Uporabite register storitev (npr. etcd, Consul ...).
• [x] V ogrodju KumuluzEE lahko uporabite razširitev KumuluzEE Discovery.
• [x] Pripravite demonstracijo odkrivanja storitev na vašem računalniku. (this we do also pa uporabmo un etcd browser na netu)

4. Naloga

4.1 Kubernetes

• [x] Ustvarite si račun pri poljubnem ponudniku oblačnih storitev. Izberite ponudnika, ki ponuja že nameščeno okolje Kubernetes.
• [x] Po kreiranju računa, vam ponudniki tipično ponudijo orodja in niz ukazov, s katerimi si lokalno skonfiguriramo orodje kubectl.
• [x] Ustvarite namestitvene datoteke za vaše namestitve in storitve. Dodajte jih v git repozitorij k pripadajoči storitvi. Pri namestitvah uporabite docker slike, ki vam jih CI cikel objavlja v repozirotiju.
• [x] Ustrezno konfigurirajte Kubernetes storitve (services). Prikažite uporabo različnih tipov storitev (npr. ClusterID in NodePort).
• [x] Nekaj vaših storitev naj bo dostopnih na javnem IP naslovu.
• [x] Ustrezno implementirajte odkrivanje storitev. Uporabite lahko: Register storitev, na enak način, kot če bi mikrostoritve zaganjali lokalno. (to je še treba pol še enkrat preverit ampak pri authu je delalo že nekej ob prvem mejniku)

5. Naloga

5.1 API za preverjanje vitalnosti in Kubernetes Liveness Probes

• [x] V vaše storitve dodajte API za preverjanje vitalnosti.
• [x] Uporabite lahko KumuluzEE Health (of course not in Node ;)).
• [x] Implementirajte vsaj dve kontroli zdravja.
• [x] API za preverjanje zdravja naj vrača ustreze HTTP status kode, da bo skladen s Kubernetes Liveness Probes.
• [x] V namestitvene datoteke Kubernetes za namestitve (deployments) dodajte Liveness Probes.
• [ ] Simulirajte bolno storitev (npr. z dinamično konfiguracijo ali POST zahtevkom) in opazujte, ali jo Kubernetes na novo zažene.

5.2 Zbiranje metrik

• [x] Storitvam dodajte končno točko, na kateri izpostavite nekaj metrik.
• [x] Uporabite lahko KumuluzEE Metrics (:not_so_ez:).

5.3 Kubernetes in dnevniške datoteke

• [x] Preglejte dokumentacijo ukaza kubectl logs.
• [x] Izpišite dnevniške datoteke vseh podov neke namestitve (deployment).

6. Naloga

6.1 Implementacija centralnega beleženja dnevnikov

• [X] V vaše mikrostoritve dodajte orodje za beleženje dnevnikov, ki bo dnevnike pošiljalo v sistem za centralizirano beleženje dnevnikov. Uporabite lahko KumuluzEE Logs.
• [X] Dnevnike pošiljajte v sistem za centralizirano beleženje dnevnikov. Uporabite lahko trial račun na logit.io. V Log4j2 uporabite appender tipa TCP.
• [X] Storitev naj vsakemu dnevniškemu zapisu doda tudi kontekstne podatke (ime storitve, verzija, okolje...). V Log4j2 lahko za ta namen implementirate interceptor.
  • ime
  • verzija
  • okolje
• [X] Vaše mikrostoritve naj beležijo vse vstope in izstope v metode posameznih končnih točk REST.
  • vstopi
  • izstopi
• [X] V orodju za pregled dnevnikov pripravite tri zanimive poizvedbe po dnevnikih (npr. izpis dnevnikov določene mikrostoritve, izpis vseh vstopov v določeno metodo, ...) Primer: marker.name: ENTRY || marker.name: EXIT

6.2 Izolacija in toleranca napak

• [x] Simulirajte napako pri enem izmed klicev med dvema mikrostoritvama (npr. mikrostoritev se registrira na napačnem naslovu ali na napačnih vratih). Zmislt si morva nek scenario ki faila in tam sprobat ta fault tolerance. To mogoče lahko demojamo kar lokalno/na dockerju in ne na Kubernetesu, kjer zna bit pain redeployat in tu.
• [x] Pripravite ustrezen nadomestni mehanizem (fallback), ki se bo prožil v primeru napake na klicani mikrostoritvi.
• [x] Pri implementaciji odpornosti na napake lahko uporabite časovnik (timeout).
• [x] Uporabite prekinjevalec toka (circuit breaker).
• [x] Pripravite demo, v katerem prikažete različna stanja prekinjevalca toka (odprto, pol-odprto, zaprto).
• [x] Ponovno simulirajte napako na eni izmed mikrostoritev in opazujte delovanje aplikacije.

7. Naloga

7.1 Uporaba zunanjih (3rd party) API-jev

• [x] V vašo aplikacijo vključite kak zunanji API. API-je lahko najdete na portalu RapidAPI. Uporabite lahko npr. tudi Amazon Rekognition.

Končni zagovori info

Na zagovoru bomo ocenjevali:

• Arhitekturno zasnovo aplikacije in kvaliteto rešitve danega problema.
• Vsebinsko povezanost razvitih mikrostoritev v celovito aplikacijo.
• [x] Pripravite vsaj pet klicev vaših storitev REST, pri obravnavi katerih sodeluje več mikrostoritev.
• Razumevanje konceptov, ki so bili izpostavljeni v navodilih nalog.
• Implementacijo in razumevanje zahtev iz nalog (npr. konfiguracija, odkrivanje storitev, Kubernetes, preverjanje vitalnosti, beleženje dnevnikov ...).
• Število razvitih mikrostoritev.
  • [ ] Vsak član skupine mora razviti vsaj tri mikrostoritve.

Na zagovore prihajajte pripravljeni:

• [x] Vaše mikrostoritve naj bodo nameščene na Kubernetesu.
• [x] Imejte pripravljeno izvorno kodo vaših mikrostoritev.

Vse koncepte iz nalog in njihovo implementacijo morate razumeti in jo znati razložiti.

Mogoče nam še kakšna mikrostoritev manjka, glede na to, da jih nimamo (št. memberjev teama) * 3 mikrostoritve. OOOORRR we can ask on dem forums, kajti na začetku je bilo rečeno drugače.

[mcebular]

@matejklemen This issue is absolutely huge and is, in fact, not a good first issue.

[jstavanja]

@matejklemen This issue is absolutely huge and is, in fact, not a good first issue.

Considering the fact that @matejklemen is a newbie, we should perhaps be more supportive. Thus I propose we give him some kudos in a form of a box of Fisherman's Friends and just start working on the thing? If you wish to help, please consider contacting me. Thanks 👍

[mcebular]

@jstavanja since @matejklemen is a maintainer of https://github.com/matejklemen/sis-backend, I wouldn't say he's a newbie, but rather that this issue could be broken down into more seperate issues and then creating a project (with a milestone) that would contain those issues.

You know how it goes, breaking that monolithic issue into smaller microissues.

[jstavanja]

What an excellent idea @mc0239 ! Ain't nobody got time for the monoliT H I C C stuff. Wish we had you on our team. Could you make some time for a short meeting sometime between now and Monday @ 9:00 AM?

[jstavanja]

EZ