Django Channels
Uporaba knjiˇzice Channels [24] omogoˇci, da Django projekt ne podpira le HTTP proto-kola, temveˇc tudi protokole, ki zahtevajo dlje odprte povezave npr. WebSocket, MQTT ... Knjiˇzica je zgrajena na osnovi Python standarda ASGI [26]. Tako lahko v naˇsem projektu uporabimo kombinacijo sinhronih in asinhronih procesov. Za laˇzjo predstavo, kako se spremeni delovanje Django paketa, si lahko pogledamo shemo 2.9.
Teoretiˇcne osnove in pregled literature
Spletni brskalnik
Porabnik (HTTP)
Spletni/WebSocket strežnik
Plast kanala
Http sporočilo WebSocket sporočilo
Vmesniški strežnik
HttpZahtevek
HttpOdgovor
Funkcija pogleda Porabnik
(WebSocket) Procesi v ozadju
Proces delavca
HTTP Python API WebSocket Channels (ASGI)
Slika 2.9: Nadgradnja Django paketa s paketom Channels, ki omogoˇca poleg HTTP ˇse implementacijo WebSocket protokola.
Channels in ASGI razdelita prihajajoˇce povezave na dve komponenti: obseg (ang.
scope) in niz dogodkov (ang. events). Obseg je zbirka dogodkov o prihajajoˇci pove-zavi, kot je recimo pot, od kjer je bil poslan zahtevek, IP naslov WebSocketa ali ime uporabnika. Pri HTTP protokolu obseg traja le ˇcas enega zahtevka, pri WebSocket pa dokler povezava ni zaprta. Med ˇzivljenjsko dobo obsega se pojavi niz dogodkov, pri HTTP protokolu je to le sporoˇcilo z zahtevkom in odgovor, pri WebSocket pa vsi poslani in prejeti paketi s podatki, dokler se povezava ne zapre.
Osnovni sestavni del Channelsov, ki je omenjen tudi na shemi, je porabnik (ang. con-sumer). Lahko si ga predstavljamo kot majhno aplikacijo, ki upravlja z dogodki. Ko je zahtevek za povezavo prejet, Channels sledi definirani usmeritvi, najde ustreznega porabnika (ang. consumer) zahtevane povezave in zaˇzene novo kopijo le-tega. Porab-niki so torej dlje ˇziveˇci in mi skozi kodo definiramo, kako naj upravljajo z dogodki, Channels pa poskrbi, da teˇcejo ob ustreznem ˇcasu in da jih lahko vzporedno teˇce veˇc.
14
Teoretiˇcne osnove in pregled literature ˇSe eden zelo pomemben sestavni del aplikacije so tako imenovane plasti kanala (ang.
channel layer) kot je prikazano na 2.9. Te nam omogoˇcajo, da razliˇcne instance aplika-cije komunicirajo med seboj. Za primer recimo, da ˇzelimo v aplikaciji implementirati klepet. V tem primeru bo vsak uporabnik ob prijavi odprl svojo instanco aplikacije. Da bi lahko vsi uporabniki prejemali sporoˇcila, bi teoretiˇcno morali sporoˇcila shranjevati v podatkovno bazo in jih nato priklicati. Reˇsitev tega so plasti kanala, ki poskrbijo za distribucijo sporoˇcil med prijavljenimi uporabniki v realnem ˇcasu. Dodatno so lahko plasti kanala uporabljene tudi za dodatne delovne procese ali izvajanj nalog v ozadju.
S strani Djanga je Redis [27] trenutno edini podprti ponudnik plasti kanala in bo na kratko opisan v naslednjem odstavku.
Redis
Redis [27] (ang. Remote Dictionary Server) je odprtokodno orodje za shrambo podat-kovne strukture v pomnilnik in se lahko uporablja kot podatkovna baza predpomnilnika ali posrednika sporoˇcil. Ponuja nam uporabo struktur kot so nizi, seznami, mnoˇzice, slovarji itd. Posebnost Redisa je, da shranjuje nabor podatkov v raˇcunalniˇski spo-min. Poslediˇcno je njegov odzivni ˇcas pod milisekundo, kar omogoˇca obdelavo veˇc milijonov zahtevkov na sekundo in je idealna izbira zareal-time aplikacije na razliˇcnih podroˇcjih kot so IoT, finance, tehnologij in igraˇcarstvo. Za uporabo je na voljo v veˇcini programskih jezikov.
V naˇsi aplikaciji smo ga v Django Channels vkljuˇcili s pomoˇcjo knjiˇzicechannels redis.
Kot ˇze zgoraj omenjeno, je njegova naloga v naˇsi aplikaciji, da sluˇzi kot plast kanala.
Enostavneje povedano, opravlja funkcijo posrednika sporoˇcil, kot to podobno poˇcne po-srednik pri MQTT protokolu, katerega smo podrobneje opisali v poglavju 2.2.1.1MQTT protokol. Redis torej poskrbi za komunikacijo med razliˇcnimi instancami aplikacije. Ko poˇsljemo neko sporoˇcilo, je to prejeto na strani drugih porabnikov, ki posluˇsajo na istem kanalu.
2.2.2.2 Kontejnerizacija aplikacije
Docker [21] je platforma za izvajanje aplikacij v lahkih enotah imenovanih kontejnerji (ang. containers). Kako poteka delo s kontejnerji in na kakˇsen naˇcin se uporablja platforma Docker, smo si razjasnili po knjigi avtorja E. Stonemana [28].
Tako imenovani kontejnerji so se zaˇceli uporabljati na razliˇcnih podroˇcjih razvoja pro-gramske opreme, od razliˇcnih aplikacij v oblaku, do zasebne uporabe v podjetjih. Zna-nje Dockerja, ki je najbolj razˇsirjena platforma za kontejnerizacijo, je postalo kljuˇcno za razvijalce, ki se ukvarjajo z razvojem spletnih aplikacij. Kljuˇcna lastnost kontejne-rizacije aplikacije je prenosnost, kar pomeni, da ni razlike med izvajanjem aplikacije v razvojnih fazah na lokalnem raˇcunalniku in med izvajanjem aplikacije v produkcijskem okolju v oblaku. S tem se poenostavi razvoj, saj smo neodvisni od operacijskega sistema in konfiguracije programske opreme, ki jo ima posameznik oziroma ponudnik oblaka.
Druga dobra lastnost je, da vsak gradnik aplikacije operira v kontejnerju. Te skupaj povezuje virtualno omreˇzje in tako lahko med seboj komunicirajo ne da bi bili izpo-stavljeni zunanjemu okolju gostujoˇcega operacijskega sistema. To omogoˇci, da lahko strateˇsko posodabljamo in testiramo posamezne dele aplikacije, jih odstranjujemo in dodajamo. Vsak del aplikacije je definiran v Dockerfile datoteki, povezava celotne
Teoretiˇcne osnove in pregled literature
aplikacje pa v Docker Compose datoteki. Ne glede na to, kateri programski jezik uporablja doloˇcen del aplikacije ali katero tehnologijo uporabljajo naˇse podatkovne baze, razvijalec na svoj sistem namesti Docker, klonira izvorno kodo za postavitev kontejnerjev in zgradi ter zaˇzene celotno aplikacijo z enim ukazom. Za laˇzjo predstavo, kako veˇckontejnerizacija poteka, si lahko ogledamo shemo 2.10.
Računalnik
Slika 2.10: Veˇc kontejnerjev na enemu raˇcunalniku si delijo isti operacijski sistem in