Amazonove spletne storitve v računalniškem oblaku (AWS) lahko uporabljamo tudi v IoT napravah z ESP8266, ESP32, WINC15x0, WFI32E in drugimi IoT WiFi moduli. Kako jo izdelamo in kako deluje AWS IoT naprava? Katere storitve ponuja oblak? Kako z njim povežemo dve oddaljeni napravi? Kako varno je? Koliko stane?
V preteklem nadaljevanju smo spoznali, najosnovnejše možnosti povezave IoT naprave z AWS storitvami z ESP32-WROOM modulom, pri čemer smo preveril zgolj zajem podatkov, ne pa tudi načinov njihove obdelave in možnosti njihovega posredovanja v AWS oblak in preko njega tudi v drugo IoT napravo. Tokrat se najprej lotimo alternativnih možnosti dostopa do AWS IoT storitev z množico razvojnih plošč na osnovi WINC15x0 modula. Zanimala nas bo tudi alternativna možnost ožičene komunikacije IoT naprave z AWS oblakom, za katero bomo uporabili kar Microchip PIC32MZ EF Starter kit z vgrajeno LAN8720 hčerinsko ploščico. Pri tem bomo za alternativno testirane AWS nastavitev in storitev ter ustreznosti izdelanih e-certifikatov na PC namestili AWS konzolo in OPENSSL. V nadaljevanju bomo preizkusili Microchipov WiFi modul WINC1510.
Ta vsebina je samo za naročnike
Nazadnje bomo spoznali, kako uporabljamo AWS IoT z AWS Lambda funkcijami, ki omogočajo analitične in statistične obdelava podatkov, ne da bi za to potrebovali lasten navidezni AWS strežnik. Za zahtevnejše aplikacije pa ga seveda lahko vzpostavimo; kako pa bomo videli na koncu članka.
AWS IoT Core prek Etherneta
Začnimo pa kar z vprašanjem, ali za dostop do AWS IoT Core nujno potrebujemo WiFi? Čeprav bi ob poplavi WiFi AWS IoT modulov pomislili, da AWS IoT Core ne moremo uporabljali tudi prek žičnih omrežij, je v resnici WiFi vselej samo posrednik do ožičenega Etherneta. Zato je denimo PIC32MZ EF Starter kitu vseeno, ali do AWS dostopa preko žičnega LAN8720 vmesnika, ali preko WiFi vmesnika na razvojni plošči. Vse je odvisno, do izbire nastavitev. Pomemben element omenjenega starter kita je kriptografski modul, vgrajen v PIC32MZ2048EFM100 mikrokontroler, saj tako ni potreben dodaten kriptografski modul.
Za dostop do AWS potrebujemo še vgnezdeno programsko kodo, novejša Microchip MPLAB X IDE (vsaj 5.35, uporabil sem 5.45), XC32 prevajalnik (uporabil sem 2.5) in razvojni programski paket s FreeRTOS, ki ga potegnemo iz AWS FreeRTOS konzole. Morda spotoma omenimo še to, da MPLABX IDE 5.xx omogoča hkratno namestitev več različic orodij Microchip Code Configurator in Microchip Harmony Configurator, zato pri prevajanju projektov, združljivih z različnimi verzijami teh orodij, orodij ni več potrebno odstranjevati in nameščati.
Predpogoj za ogled podrobnih navodil na spletni strani https://console.aws.amazon.com/freertos je, da smo prijavljeni v AWS FreeRTOS konzolo. Kljub temu pa prijava v FreeRTOS konzola za prenos primernov iz GitHuba (https://github.com/aws/amazon-freertos) ni potrebna.
Projekt AWS_demos združuje kopico primerov za različne načine uporabe AWS storitev. Za izbiro in zagon izbranega primera moramo v MPLABX IDE namestiti še Microchip Code Configurator v4.0, ki je bil včasih na voljo samo za 16-bitne in 8-bitne PIC mikrokontrolerje, zdaj pa ga z ustreznimi dodatnimi programskimi knjižnicami lahko uporabimo tudi za PIC32 projekte. Microchip Code Configurator potrebujemo za predpripravo programske kode za prevajanje s prevajalnikom XC32 v MPLAB X IDE.
Dostop do AWS prek sistemske konzole in OPENSSL v pomoč pri testiranju
Potreba po tekstovnem upravljanju storitev AWS je pokaže takoj, ko moramo namestiti množico IoT napravo oziroma narediti množici podobnih opravil. Omogoča tudi nekatera dodatna testiranja. Že res, da se zdi, da avtorjem spletnih videov vsi namestitveni postopki stečejo kot po maslu, a vendarle gre lahko tudi kaj narobe. Preden je nastalo preteklo nadaljevanje, sem se kar nekaj časa ubadal s problemom, kako podatke iz AWS modula uspešno prenesti v njegovo sliko v AWS oblaku, v katerem lahko zbrane podatke analiziramo in obdelujemo. Ugnezdena programska oprema je vračala naslednjo napako:
AWS_IOT: failed! mbedtls_net_connect_returned -0x52
AWS_IOT: Error (-23) connecting to https://……-ats.iot.eu-central.1.amazonaws.com:8883
Čeprav je večina poročil o tej napaki so govorila o nedostopnosti DNS strežnika oziroma nezmožnosti pretvarjanje domenskih imen v IP naslove kot najverjetnejšem vzroku za napako, sem po temeljiti analizi programske kode odkril, da se moj ESP32-AWS-modul dejansko sploh ne poveže v internet. Še prej sem ponovno izdelal in z ESP32-AWS-modulom pravilno povezal tudi e-certifikata in zasebni ključ naprave, katere sem preveril z odprtokodnim orodjem OPENSSL (za prevajanje programske kode moramo namestiti GNU prevajalnik s pripadajočim razvojnim okoljem za naš operacijski sistem), ki ga lahko prenesemo iz interneta tudi v obliki namestitvene datoteke z izvedljivo programsko kodo za različne operacijske sisteme. Namestil sem tudi AWS IoT konzolo, ki jo lahko uporabimo za podrobnejšo analizo dostopnosti storitev AWS oblaka.
Kakorkoli, vsi testi so po ponovni namestitvi in vgradnji novi certifikatov v programsko kodo delovali brezhibno, le zgoraj omenjena napaka ESP32-AWS-modula ni in ni hotela izginiti dokler nisem takole spremenil dela programske kode za povezovanje modula z dostopno točko:
WiFi.mode(WIFI_STA);
delay(10000);
WiFi.config(apIP,apGWIP,subNET,DNS1,DNS2);
do {
Serial.print("Connecting to SSID: ");Serial.println(WIFI_SSID);
status = WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
i = 50;
while(((status=WiFi.status())!=WL_CONNECTED)&&(i>0)){
delay(100);i--;}
} while (status != WL_CONNECTED);
Tako se stavek WiFi.beginizvede enkrat za vselej, vrednosti spremenljivke status pa ni potrebno predhodno nastaviti. Prvotna koda ni delovala zato, kar je bila začetna vrednosti spremenljivke status WL_CONNECTED. Zato se omenjeni stavek ni niti enkrat izvedel…
IoT z WINC15x0
Čeprav so Microchipovi WiFi moduli WINC1000, WINC15x0 in WINC3400 na moč podobni ESP-jem, imajo vendarle drugačno razporeditev priključkov, z gostiteljskim mikrokontrolerjem pa večina komunicira le prek SPI vmesnika. UART-a sta uporabljena zgolj za programiranje in diagnostiko. Nekatere WINC module lahko programiramo in upravljamo tudi prek I2C priključka, za uporabniške aplikacije v modulu pa je na voljo pa je tudi nekaj splošno-namenskih GPIO priključkov.
Podobno, kot ESP moduli, so tudi WINC na voljo v različicah z anteno na tiskanem vezju in priključkom za zunanjo anteno. Kljub veliki podobnosti pa v njihovem jedru bije APS3 procesor, zato nabor strojnih ukazov ni združljiv s tistimi v ESP32 in ESP8266 modulih.
Poleg načinov delovanja kot WiFi postaja in WiFi dostopna točka omogoča tudi način P2P (peer-to peer, slov. točka-točka), s katerim lahko medsebojno povežemo dva modula, tako da izključimo vse ostale možnosti povezav.
Bistvena razlika pa je pri programiranju vgrajene programske opreme, saj modul nima posebnih priključkov za izbiro načina zagona, ampak moramo namesto tega prek SPI vodila posredovati zaporedje ukazov. Programiramo ga nato preko prvega UART-a (RS232 za razhroščevanje), SPI ali I2C vmesnika.
Prednosti hčerinskih razširitvenih ploščic na osnovi WINC15x0
Hčerinski ploščici ATWINC1500-XPRO in ATWINC1500 PICtail/PICtail Plus Daughter Board sta namenjeni povezovanju z AVR, SAM in PIC razvojnimi kompleti. ATWINC1500-XPRO ima robno vtičnico, prek katere jo lahko povežemo z nekaterimi razvojnimi ploščami s SAM in AVR mikrokontrolerji, med katerimi pa nisem našel moje ATSAMV71, ampak le primer za enostavnejšo ATSAME70 razvojno ploščo. Sicer imata obe plošči konektor EXT1, prek katerega lahko povežemo hčerinsko ploščo ATWINC1500-XPRO. Poglavitni prednosti ATWINC1500-XPRO sta, da a vsebuje kriptografski čip ATECC608A in da vsebuje tudi diskretne elemente za podporo delovanju modulu.
Celoviti Microchipovi rešitvi PIC-IoT in AVR-IoT
Pri Microchipu so mislili tudi na tiste, ki želijo AWS IoT preizkusiti brez spajkanja in podrobnega preučevanja dokumentacije. PIC-IoT temelji na WINC1510 modulu in PIC24 mikrokontrolerju, za strojno podporo varnostnemu kodiranju pa skrbi ATECC608A čip. Zanimivo pa je, da so pri Microchipu kot programator/razhroščevalnik/USB-RS232 most za PIC24 uporabili kar SAMD21E mikrokontroler, saj je bil ta prvotno namenjen le Atmelovim rešitvam.
AVR-IoT vezje s podobnimi zmogljivostmi kot PIC-IoT, le ga je zgrajeno okoli ATMega4808 mikrokontrolerja, zmogljivejši SAMD21E mikrokontroler pa deluje kot programator/razhroščevalnik/USB-RS232 most za ATMega4808.
AVR-IoT in PIC-IoT rešitvi sicer izhajata iz sorazmerno velike množice rešitev na osnovi palete Atmelovih SAM razvojnih plošč, ki jih je Microchip po nakupu Atmela prilagodil tudi za PIC mikrokontrolerje. Tistim, ki že imate ustrezno SAM razvojno ploščo (kar lahko preverite v zbirki primerov v zadnji različici Atmel Studia), zato zadošča nabava ATWINC 1500-XPRO modula.
Kako se lotiti programiranja?
Ker nisem imel preizkusnega vezja, ampak le WINC1510 modul, sem dolgo razmišljal, kako ga čim enostavneje preizkusiti. Izdelave novega vezja na osnovi PIC18, PIC24, PIC32, SAM ali AVR mikrokontrolerja se je lotilo že veliko avtorjev na spletu objavljenih projektov.
Za začetnika je morda še najenostavnejše programiranje modula v Arduino okolju, saj so pri Adafruitu z odprtokodno programsko knjižnico WiFi101 poskrbeli za njegovo povezavo z razvojno ploščo Arduino Uno. Podrobnejši pregled kode razkrije, da programske knjižnice ni težko prilagoditi tudi za druge z Arduinom združljive razvojne plošče, ki podpirajo SPI komunikacijo. Resda je za AVR mikrokontroler Arduina UNO že vse prednastavljeno, a z nekaj dopolnitvami lahko v programski kodi lahko z WINC15x0 prek SPI povežemo poljuben združljiv mikrokontroler s SPI vodilom.
Tako se zamisel, da bi v ta namen uporabil kar ESP32 modul sploh ni zdela slaba. Čeprav ima slednji tudi lastni WiFi modul, ni ovir, da ne bi mogel komunicirati tudi z WINC15x0, kar bi mu odprlo še več možnosti povezovanja v brezžičnih omrežjih. Vsekakor bi se dalo na ta način izdelati tudi brezžični usmerjevalnik, ki medsebojno poveže dve brezžični omrežji, ali pa podaljša doseg obstoječega brezžičnega omrežja. Možnosti za preizkušanje novih tehnologij je tako več ko dovolj, a pod pogojem, da smo pripravljeni veliko truda vložiti tudi razvoj programske opreme.
Prilagoditev WiFi101 knjižnice
Za prilagoditev programske kode je ključna pravilna opredelitev programske strukture WINC1501_SPI, s katero prek Arduina se povežemo z enoto SPI v gostiteljskem mikrokontrolerju. Če vrednosti WINC1501_SPI, ne opredelimo, je privzeta vrednost kar SPI; kar nam pri ESP32 tudi ustreza, saj želimo uporabiti VSPI vmesnik. Zdaj moramo nastaviti le še krmilne priključke, kar lahko storimo s funkcijo setPins(CS_pin, IRQ_pin, RESET_pin, ENABLE_pin), pri čemer, lahko za ENABLE_pin izberemo tudi vrednost -1, kar je enako kot, če tega podatka ne podamo. To nam omogoča, da prihranimo priključek na gostiteljskem mikrokontrolerju, v kolikor je EN na WINC15x0 povezan na logično 0 (stalno omogočen). Druge prilagoditve niso potrebne, saj ima ESP32 zmogljivo SPI enoto, ki brez težav prenaša podatke s hitrostmi do 80 Mb. Slednje je precej več, kot 12 Mb prednastavitev v knjižnici WiFi101.
Razvoj programske opreme z AWS FreeRTOS SDK
Pri AWS so pripravili več predstavitvenih programskih paketov, ki temeljijo na operacijskem sistemu FreeRTOS. Vključujejo tako izvorno kodo primerov, FreeRTOS kot tudi programskih orodij za različne strojne osnove: Raspberry Pi, ESP32, PIC32, Rasberry Pi, PC simulator itn. Slednji je pomemben pripomoček za testiranje tistim, ki še nimajo mikrokontrolerske razvojne ploščice, ali pa preučujejo predvsem nabor AWS IoT in AWS Greengrass funkcionalnosti.
Bistvo FreeRTOS rešitev je uporaba standardnega jedrnega operacijskega sistema z enotnim API programskim vmesnikom. Posebnosti posameznih strojnih osnov so tako implementirane v gonilniki za posamezne strojne osnove (npr. ESP32, PIC32, …) in skupkih definicijskih datotek za posamezne razvojne plošče. FreeRTOS poenostavlja tudi hkratno poganjanje več procesov v enem mikrokontrolerju in obravnavo prekinitev.
Namestitve razvojnega okolja AWS FreeRTOS se moramo lotiti v več korakih po navodilih iz console.aws.amazon.com. Še posebej pomembno je, da pravilno namestimo cmake in prevajalnike za izvorno kodo IoT naprav, ki jih želimo programirati. Nato se lotimo konfiguracije cmake, pri kateri izberemo tudi razvojno ploščo, ki jo uporabljamo, da lahko cmake prevede kodo primerov vgrajene programske opreme. Velja omeniti še, da sta za enkrat na voljo FreeRTOS razvojna kompleta za AWS IoT in AWS Greengrass storitve.
Razvoj vgrajene programske opreme z Microchip Harmony in Atmel Studio
Za razvoj programske opreme z AVR in SAM mikrokontrolerji, ki so prvi podpirali WINC module, potrebujemo Atmel Studio 7 in ustrezno razvojno ploščo. Malo sem bil razočaran, ker primeri niso že v osnovi prilagojeni tudi za ATSAMV71 razvojno ploščo, saj hčerinski modul z WINC1510 (sicer brez čipa za kriptografijo ATECC608A) ne bi bilo težko izdelati. Kljub temu je 3,3 V dovolj zmogljivo tudi za WINC1510, zato se lahko pri povezavi modula s preizkusno ploščo zgledujemo po ATWINC1500-XPRO.
Tudi Microchip Harmony že vsebuje tudi primere uporab WINC modulov za PIC32MX in PIC32MZ mikrokontrolerje, primere za AWS pa lahko prenesemo iz console.aws.amazon.com. Pred tem moramo v Microchip Harmony namestiti vsaj Microchip MPLAB Code Configurator (MCC), ki zdaj ob namestitvi ustreznih knjižnic poleg PIC18 in PIC24 podpira tudi PIC32. Je pa res, da za instantni dostop do AWS storitev z razvojno ploščico PIC-IoT ali AVR-IoT potrebujemo tudi podporo za PIC24 ali AVR mikrokontrolerje. Prenos ustreznih programskih knjižnic s spleta je k sreči avtomatiziran. Zato je dovolj, da s spleta prenesemo samo eno izmed zadnjih tretjih ali četrto različico MCC.
Skupek primerov najdemo v Microchip Harmony v projektu <namestitveni imenik Microchip Harmony>appstcpipwifi_winc1500_socket. Vendar so primeri uporabni tudi za WINC1510, saj se ta od WINC1500 razlikuje le po dvakrat večjem Flash RAM-u (8 Mb).
Prednost primerov za Microchip Harmony in Atmel Studio pred drugimi razvojnimi okolji je predvsem v boljši integraciji z Microchipovimi razvojnimi okolji, kar omogoča lažjo ponovno uporabo kode še izdelanih projektov. Vendar pa lahko tu računamo predvsem na demonstracijo uporabe WINC modulov, medtem so za AWS storitve na voljo osnovni primeri.
AWS Lambda ali kako zastonj obdelati podatke
AWS omogoča tri nivoje storitev SAAS (programska oprema kot storitev), PAAS (strojna osnova kot storitev), IAAS (infrastruktura kot storitev). Prvi nivo predstavljajo gotovo programske aplikacije, ki jih lahko računalniški oblak ponudi odjemalcem kot storitve, kot so umetno-inteligenčne storitve, statistične obdelave in analize podatkov. Kateri nivo bomo izbrali, je odvisno od naših potreb in namena uporabe IoT naprav, ki jih načrtujemo. Enostavne nosljive IoT naprave, morda potrebujejo le podatkovno zbirko za shranjevanje zajetih podatkov in nekaj funkcij za njihovo analizo in statistično obdelavo. Vendar pri tem ne gre za zanemariti umetno-inteligenčnih storitev, s katerimi lahko, denimo spletne kamere, zaznajo predmete in osebe, ali pa preberejo napise in črtne kode. Tudi tu se odpira široko polje različnih rešitev, ki bodo lahko namesto lastnih procesnih zmogljivosti uporabljale AWS storitve.
Čeprav je večina stvari, povezanih s procesiranjem podatkov, v AWS prej ali slej plačljivih sta manj zahtevnim uporabnikom na voljo AWS Lambda in AWS DynamoDB relacijska podatkovna zbirka, ki sta za nezahtevno obdelavo manjših količin podatkov zastonj brez časovne omejitve na prvo leto uporabe. Kljub temu pa umetno-inteligenčne storitve niso zastonj.
Kako uporabljamo AWS Lambda?
Lambda funkcija se sproži z enim od sprožilcev, ki jih definiramo zanjo v Lambda konzoli. Med mogočimi prožilci so tudi AWS IoT t.i. gumbi naprav pa tudi AWS S3 (storitev za preprosto shranjevanje podatkov), AWS MQ in AWS SNS. Po izvajanju funkcija rezultate shrani izbran izhod, ki je lahko druga funkcija, AWS DynamoDB podatkovna zbirka itn. Tako je proženje Lambda funkcije mogoče tudi prek MQTT sporočil IoT naprav, vključenih v AWS oblak. Lambda funkcijo lahko napišemo v enem od naslednjih popularnih programskih jezikov: JavaScript, Python, Ruby, Java, Go, C# in skriptnem jeziku Microsoft Windows PowerShell. Lahko pa na mesto tega uporabimo eno od že pripravljenih funkcij, ki so na voljo v AWS Lambda konzoli; česar se lotimo v prihodnjem nadaljevanju.
AWS IoT Core povežemo z AWS Lambda tako, da v AWS IoT Core vnesemo ustrezna pravila, ki na osnovi prejetih sporočil prožijo AWS Lambda funkcije. Pravilo poskrbi, da AWS Lambda funkcija dobi sporočilo iz AWS IoT naprave, ki ga nato ustrezno obdela.
Drugi način komunikacije je preko AWS IoT dogodkov (AWS IoT Events), pri katerem AWS IoT z detektorjem dogodkov spremlja MQTT sporočila s povezanih IoT naprav. Detektor dogodkov je avtomat stanj, ki povezuje MQTT sporočila z dogodki v JSON obliki. Ob vnaprej določenih dogodkih proži ustrezne akcije. Ena od mogočih akcij je tudi AWS Lambda funkcija.
Vzpostavitev AWS navideznega PC strežnika
AWS PAAS storitve so na voljo v obliki navidezne omrežne infrastrukture in različnih predlog za ustvarjanje navideznih strežnikov, med katerimi ne manjkajo niti najnovejši Microsoft Windows strežniki, razni spletni strežniki in strežniki podatkovnih zbirk. PAAS storitve tako predstavljajo vnaprej pripravljeno osnovo za nameščanje lastne strežniške programske opreme.
Po drugi strani, daje IAAS tudi možnosti za vzpostavitev lastne sistemske programske opreme v varovanem navideznem računalniku. Pri tem moramo samo zagotoviti tako licence za programsko opremo, če pa ustrezne strežniške predloge ni na voljo pa tudi kopijo sistemske programske opreme.
Vendar takoj povejmo, da sta tako PAAS in IAAS plačljiva z nekaj izjemami, ki so omejene na prvo leto uporabe. Če imate zastonjsko spletno stran, pri katerem od veliki ponudnikov gostovanja spletnih strani, velja morebitno vzpostavitev lastnega strežnika v okviru AWS vsekakor preveriti tudi v finančnem smislu. Kakorkoli, za enostavne strežniki z zmogljivostjo Intel Atoma, ki je primeren tudi za osebno rabo, bomo na mesec odšteli nekaj evrov, vendar strošek uporabe z zmogljivostjo hitro narašča. Zato velja biti pri izbiri vrhnje zmogljivosti še posebej previden. Paziti moramo tudi, da po izteku 12 mesečnega obdobja zastonjske uporabe navideznega PC slednjega izbrišemo in vrnemo njegove resurse AWS, sicer bomo morali plačevati za uporabljen SSD ali diskovni pomnilnik.
AWS navidezna infrastruktura obsega navidezne strežnike oziroma navidezne PC-je, pri čemer moramo najprej definirati vsaj prednastavljeni navidezni strežnik (default VPC), da lahko na njem vzpostavimo eno ali več instanc poljubnih operacijskih sistemov. Vsekakor lahko definiramo tudi več dodatnih VPC, pri čemer na vsakega namestimo po več instanc, kar je odvisno od želene arhitekture navideznih strežnikov.
Instanca: Windows Server 2019
Poglejmo kako vzpostavimo enostavno instanco navideznega strežnika Windows Server 2019, ki ga bomo lahko zastonj uporabljali 1 leto (velja opozorilo, da bo nadaljnja uporaba samodejno postala plačljiva). Tokrat moramo iz AWS konzole izbrati storitev EC2, nato pa v levem stranskem pogledu še Instances nato pa v desnem zgornjem kotu še gumb Launch instances from template, s katerim odpremo novi navidezni računalnik iz predloge AMI (Amazon Machine Image). Zdaj v filtrsko polje Instance Types vnesemo Free-Tier eligible, tako da AWS kozola pokaže samo predloge navidezni računalnikov, ki jih lahko eno leto od vzpostavitve AWS računa uporabljamo zastonj, če pri tem upoštevamo omejitev na 750 ur procesiranja na mesec in ne prekoračimo omejitev porabe sistemskih sredstev. V pregledu poiščemo Microsoft Windows Server 2019 Base in izbiro potrdimo z gumbom Select. Pred nami se pojavi nova tabela z različno zmogljivih navideznih strežnikov izbranega tipa. Če nočemo plačevati, lahko ponovno izberemo samo med tistimi, pri katerih je zeleno polje z napisom Free tier elegible. Moja izbira res ni bila težka, saj je bila na voljo le ena taka instanca.
Po kliku na gumb Configure Instance Details, v naslednjem oknu vnesemo in izberemo osnovne podatke, ki obsegajo ime, strežniški center, način dostopa do interneta in ostalih omrežij, omrežno infrastrukturo ter različne opcijske nastavitve delovanja in nadzora navideznega računalnika. Pri tem je pomembno, da za strežniški center izberemo tistega, ki podpira naš izbrani tip strežnika.
Naslednji korak je dodajanje podatkovnega pogona (gumb Add storage v desnem spodnjem kotu). Za začetek kar pustimo predlagano vrednost 30 GB (lahko kvečjemu manj, če želimo pomnilnik porazdeliti med več hkratnih navideznih strežnikov) in izberemo SSD ali diskovni trajni pomnilnik, saj nam tako uporabe AWS eno leto ne bo zaračunal.
V naslednje okno pridemo preko gumba Configure Security Group (Nastavi varnostno skupino). Dejansko gre za požarni zid in usmerjevalnik, v katerem nastavimo želene možnosti dostopa v in iz navideznega PC-je iz interneta. Ker bomo navidezni PC preko interneta tudi upravljali, ni slabo izbrati možnosti upravljanja iz konzole le preko IP naslova, ki ga uporabljamo za svoj domači oziroma službeni računalnik. Tako drugim uporabnikom možnosti upravljanja navideznega računalnika (prek grafičnih konzol SSH ali RDP) ne bodo na voljo. Po drugi strani, lahko storitve, kot je HTTP (vrata 80), odpremo vsem internetnim uporabnikom, če želimo na primer vzpostaviti spletno stran.
Naslednji korak je izdelava varnostnega certifikata, iz katerega lahko nato s posebnim orodjem dekodiramo tudi varnostno geslo za vstop v navidezni računalnik prek RDP. Uporabniško ime je Administrator. Če varnostni certifikat že imamo, ga lahko izberemo pri ustvarjanju instance in nam ni potrebno ustvariti novega. Izdelano instanco moramo zdaj le še zagnati tako, da v pregledu instanc odpremo spustni meni Actions in kliknemo Start. Nato počakamo kako minuto, da se instanca zažene in dobi stanje Running.
Za testiranje lahko uporabljamo katerikoli računalnik z RDP odjemalcem, pri čemer je RDP standardno nameščen le v Windows, v Linux ali Android pa ga moramo dodatno namesti (npr. sudo apt-get install remmina). Prijavimo se z uporabniškim imenom Administrator in geslom. Povejmo še, da Linux instanco vzpostavimo na podoben način.
Na kaj je dobro paziti pri testiranju?
Pri običajnem delu prek interneta smo pogosto zavarovani s požarnim zidom, ki dovoljuje le določene vrste komunikacij, denimo TCP/IP protokol z odprtimi vhodnimi vrati za odpiranje spletne pošte in brskanje po spletnih straneh. Pri terminalski in sporočilnim komunikaciji z AWS oblakom moramo pogosto uporabljati tudi druge protokole in hkrati precej širši nabor standardiziranih vrat zanje. Zato moramo temu primerno prilagoditi tudi omejitve požarnega zidu. Pogosto se splača komunikacije za upravljanje navideznih PC ali drugih pomembnih funkcionalnosti omejiti samo na naš stalni IP naslov, saj tako preprečimo komunikacijo morebitnih hekerjev, ki bi lahko poskušali do nastavitev dostopati iz drugih IP naslov. Vsekakor pa si take zaščite ne moremo privoščiti, v kolikor za dostop do interneta ne uporabljamo stalnega IP naslova, ki ga sicer internetni operaterji upravičeno odsvetujejo zaradi večje izpostavljenosti vdorom v lokalno (npr. domače) internetno omrežje. Večina podjetji in ustanov se tej nevarnosti ogne z nakupom in namestitvijo namenskega požarnega zidu, ki je lahko tudi usmerjevalnik.
Je navidezni PC strežnik alternativa AWS IoT Core in AWS Lambda?
V navidezni strežnik lahko nameščamo spletne storitve po lastni izbiri, zato tudi ni nujno, da za dostop do njega uporabljamo protokol MQTT. Prav tako, imam pri obdelavi podatkov ni potrebno uporabljati AWS Lambda funkcij. Zato imamo pri programiranju IoT naprav več svobode.
Naslednjič
Spoznali bomo, kako IoT napravo povežemo z AWS navideznim PC, ki smo ga ustvarili v tokratnem nadaljevanju. Nadaljujemo tudi z razvojem lastnih AWS Lambda funkcij in s pregledom AWS Lambda storitev, ki jih lahko uporabljamo iz IoT naprav. Več o izdelavi WiFi AWS IoT združljivih modulov preberite na spletni strani https://sites.google.com/site/pcusbprojects.
Avtor: dr. Simon Vavpotič
https://sites.google.com/site/pcusbprojects
2021/293
