- Docker Swarm ponuja izvorno združevanje v gruče, mrežno usmerjanje in prekrivno omrežje za objavljanje storitev in povezovanje vsebnikov med več vozlišči.
- Agent Portainer Edge (standardni ali asinhrono) vam omogoča upravljanje oddaljenih okolij Swarm brez izpostavljanja Docker API-ja ali odpiranja nepotrebnih vrat.
- Robno računalništvo izkorišča prednosti Dockerja in WebAssemblyja za izvajanje lahkih, varnih in prenosnih delovnih obremenitev na omejeni strojni opremi.
- Z združevanjem Swarm, Portainer in Wasm lahko ustvarite porazdeljene, na napake odporne in enostavno upravljane robne arhitekture.
Ko se začnete igrati z Docker Swarm, Portainer in uvajanjem na robu omrežja, se zlahka zmedete: agenti, robni agenti, usmerjanje v omrežju (mesh routing), prekrivna omrežja, zakasnitev med VPS-ji v različnih mestih ... vse se sliši odlično, toda ko gre za nastavitev, želite nekaj jasnega, stabilnega in kar vas ne sili, da odprete polovico požarnega zidu.
V naslednjih vrsticah boste našli podrobno razlago v preprosti španščini , kako se vse to ujema: kaj prinaša Docker Swarm, kako deluje usmerjanje v omrežju, kakšno vlogo imata Portainer Agent in Edge Agent (v standardnem in asinhronem načinu), kako upravljati porazdeljena okolja (na primer VPS v New Yorku in drugega v Seattlu) in kako izkoristiti Docker na robu omrežja, tudi z WebAssembly (Wasm) za bolj omejene naprave.
Osnovni koncepti: Docker Swarm, robno računalništvo in Portainer
Preden se začnemo ukvarjati z ukazi, je pomembno razumeti nekaj temeljnih konceptov, ki so skupni vsaki arhitekturi Docker Swarm edge : Swarm kot orkestrator, vloga robnega računalništva in zakaj Portainer tako olajša življenje.
Docker Swarm je Dockerjev izvorni način gručenja, ki vam omogoča združevanje več Dockerjevih mehanizmov (na primer več virtualnih strojev ali VPS-jev) in njihovo upravljanje, kot da bi bili en sam virtualni gostitelj. V praksi to pomeni, da lahko preprosto namestite replicirane storitve, uporabljate prekrivna omrežja med vozlišči, uravnavate obremenitev in izkoriščate visoko razpoložljivost.
Po drugi strani pa robno računalništvo vključuje približevanje obdelave podatkov mestu, kjer se podatki generirajo (senzorji, naprave interneta stvari, majhni tovarniški stroji, usmerjevalniki, prehodi itd.). To zmanjša zakasnitev, prihrani pasovno širino v oblaku in omogoča delovanje tudi z omejeno ali občasno povezljivostjo. Docker dobro deluje na zmerno zmogljivih napravah, vendar se muči z zelo omejeno strojno opremo – na primer pri uporabi nespremenljive distribucije Linuxa .
Tukaj pride na vrsto Portainer , lahka platforma, ki ponuja spletni vmesnik in API za upravljanje okolij Docker, Swarm, Kubernetes ali ACI. Portainer vam omogoča enostavno upravljanje vsebnikov, slik, omrežij, nosilcev podatkov in drugih virov, bodisi na enem gostitelju bodisi na več deset oddaljenih vozliščih.
Za povezavo teh oddaljenih okolij s strežnikom Portainer imate na voljo več možnosti: klasični agent Portainer, neposredna povezava z Docker API/vtičnico in agent Portainer Edge v standardnem ali asinhronem načinu. Izbira prave možnosti je ključna razlika med čisto nastavitvijo in nastavitvijo, polno varnostnih ranljivosti in odprtih vrat.
Docker Swarm: vrata, usmerjanje v omrežju in objavljanje storitev
Ko v Dockerju omogočite način Swarm , vsa vozlišča v gruči sodelujejo v tako imenovani mreži usmerjanja vhodnega prometa . Preprosto povedano, lahko katero koli vozlišče v gruči prejema promet na objavljenih vratih storitve, tudi če to določeno vozlišče ne izvaja nobenih nalog za to storitev.
Da bi vse to delovalo, morajo biti med vozlišči Swarm odprta določena vrata . Natančneje, omrežna ravnina Swarm uporablja:
- Vrata 7946 TCP/UDP za odkrivanje omrežja kontejnerjev.
- Vrata 4789 UDP (nastavljivo) za vhodni omrežni promet na osnovi VXLAN.
Poleg tega morajo biti vrata, ki jih objavite za svoje storitve, dostopna iz zunanjih virov, ki jih bodo porabljali : zunanjih uravnalnikov obremenitve, drugih sistemov, končnih uporabnikov itd. Ta promet bo vstopil skozi katero koli vozlišče, usmerjanje mreže pa bo odgovorno za njegovo preusmeritev v aktivni vsebnik storitev.
Za objavo portov v Swarmu se uporablja možnost . –objaviti Pri ustvarjanju ali posodabljanju storitve. Parameter target označuje notranjo odprtino posode, medtem ko published Določite vrata, izpostavljena v usmerjevalni mreži. Če preskočite objavljena vrata, Docker vsaki nalogi dodeli naključna visoka vrata, nato pa morate pregledati naloge, da ugotovite, katera so bila uporabljena.
Objavljeno pristanišče (<PUBLISHED-PORT>) je tam, kjer je Swarm izpostavlja storitev zunanjemu svetu, medtem ko je kontejnersko pristanišče (<CONTAINER-PORT>Tukaj proces posluša znotraj vsebnika. Če na primer oglašujete zunanja vrata 8080, ki kažejo na notranja vrata 80 strežnika Nginx, bo zahteva po katerem koli vozlišču na vratih 8080 povzročila, da bo Swarm zahtevo usmeril v enega od aktivnih vsebnikov, ne da bi vam bilo treba skrbeti, kje se dejansko izvaja.
Usmerjanje v omrežju posluša na IP-naslovu vozlišča in oglaševanih vratih. Če je IP-naslov zunanje usmerljiv, bo storitev dostopna od zunaj gostitelja; če gre za samo notranji IP-naslov, bo dostop omejen na sam gostitelj ali njegovo zasebno omrežje. Uporabite lahko pregled storitve Docker da si kadar koli ogledate razmerje med ciljnimi vrati (TargetPort) in tisti, ki so bili objavljeni (PublishedPort).
Objavite vrata TCP in/ali UDP in uporabite način gostitelja
Privzeto se ob objavi porta na Swarmu predpostavlja, TCP protokolČe želite objaviti vrata UDP ali kombinirati TCP in UDP, morate uporabiti dolgo sintakso --publish in prilagodite ključ protocol a tcp o udpČe objavite oba in izpustite protokol, bo objavljen kot TCP.
Lahko tudi preskoči mrežno usmerjanje za določeno storitev z uporabo tako imenovane način gostiteljaV tem načinu, ko dostopate do vrat na vozlišču, dosežete samo do primerka storitve, ki se izvaja na tem vozlišču, če ta obstaja. Da bi to dosegli, uporabite dolgo sintakso --publish in vzpostaviš mode=hostČe ne določite ničesar ali pustite mode=ingressUporabljena bo mreža.
Pri gostiteljskem načinu je treba upoštevati nekaj stvari, da se izognete presenečenjem: če dostopate do vozlišča, kjer ni servisnih opravil, so ta vrata lahko nedejavna ali zasedena z drugo aplikacijo ; in če pričakujete, da boste na vozlišču izvajali več replik, statičnih vrat ne boste mogli uporabljati brez konfliktov, razen če Dockerju dovolite, da dodeli naključna vrata ali jih omeji na eno repliko na vozlišče z uporabo globalnih storitev ali omejitev.
V večjih arhitekturah je običajno kombinirati Swarm z zunanjim uravnalnikom obremenitve, kot je HAProxy ali podobno. To lahko storite z uporabo usmerjanja mreže ali z uporabo DNSRR (brez VIP-jev) in uravnavanjem neposredno na IP-naslove nalog, odvisno od tega, kaj najbolj ustreza vašim potrebam glede prometa in opazovalnosti.
Oddaljeno upravljanje s Portainerjem: Agent proti Edge Agentu
Portainer ponuja več načinov za povezavo oddaljenih okolij Docker ali Swarm z vašim strežnikom Portainer , in prav tu se mnogi zmedejo. Tri glavne možnosti so: uporaba agenta Portainer, neposredna povezava z Docker API-jem/vtičnico ali namestitev agenta Portainer Edge (standardni ali asinhroni način).
Klasični agent Portainer je zasnovan za okolja, kjer sta strežnik Portainer in upravljani gostitelji v istem omrežju ali pa lahko vsaj neposredno komunicirata. V tem primeru se strežnik poveže z agentom, zato morate odpreti vrata od strežnika do vozlišč, na katerih se izvaja agent, kar ni vedno zaželeno pri delu z VPS-ji, ki so razporejeni po več podatkovnih centrih ali domačih omrežjih za NAT.
Najbolj varna in prilagodljiva alternativa v porazdeljenih okoljih je Portainer Edge Agent . Tukaj je tok obrnjen: robni agent na oddaljenem gostitelju vzpostavi povezavo s strežnikom Portainer. Namesto vzdrževanja odprte dohodne povezave robni agent občasno anketira strežnik, da preveri čakajoča opravila, in ustrezno ukrepa.
Za delovanje Edge Agent mora strežnik Portainer izpostaviti vsaj vrata spletnega vmesnika (UI) , običajno 9443 ali NodePort, kot je 30779 v Kubernetes. Poleg tega v standardnem načinu potrebujete tudi vrata tunela (8000 ali 30776 v Kubernetes z NodePort). Ta tunel ustvari varno povezavo TLS med Edge Agentom in strežnikom, kar omogoča interakcijo z oddaljenim okoljem v realnem času.
Uradni priročniki za namestitev Portainerja že konfigurirajo strežnik za poslušanje na obeh vratih, vendar boste morali zagotoviti, da požarni zid vašega okolja razkrije ta vrata. Portainer tudi predpostavlja, da izpolnjujete določene minimalne sistemske zahteve; če se od teh bistveno oddaljite, boste morda potrebovali dodatne prilagoditve ali pa bodo nekatere funkcije omejene.
Edge Agent v standardnem načinu na gruči Docker Swarm
Če želite upravljati oddaljeno okolje Docker Swarm s standardnim agentom Edge , je potek dela v Portainerju običajno takšen: v meniju Portainer odprite razdelek Okolja (Povezano z okoljem → Okolja) in kliknite na »Dodaj okolje«. Tam izberite »Docker Swarm« in zaženite čarovnika (Zaženi čarovnika).
V čarovniku izberite možnost Edge Agent Standard in izpolnite podrobnosti okolja: opisno ime, URL, s katerim se bo agent povezal, možnosti skupine ali oznake itd. V razdelku »Več nastavitev« lahko prilagodite pogostost anketiranja , ki določa, kako pogosto Edge Agent preverja nova opravila ali spremembe. Privzeto je to običajno vsakih 5 sekund, vendar jo lahko spremenite, če želite zmanjšati promet ali izboljšati odzivnost.
Ko izpolnite osnovna polja, kliknite »Ustvari«. Če predhodno označujete okolja ali pripravljate skripte za avtomatizacijo, lahko na tej točki pridobite žeton za pridružitev , da ga ponovno uporabite v svojih uvedbah. Portainer bo nato prikazal dodatna polja, ki jih potrebujete za ustvarjanje ukaza za namestitev.
Naslednji korak je izbira oddaljene gostiteljske platforme (Linux ali Windows), kopiranje ukaza, ki ga ustvari Portainer, in njegov zagon v okolju Edge. Ta ukaz prenese sliko agenta Edge in jo konfigurira s pravilnim žetonom in URL-jem. Ko se zažene, se novo okolje prikaže na glavnem zaslonu Portainerja kot novo vozlišče.
Če morate namestiti še eno podobno standardno okolje Edge, lahko uporabite možnost »Dodaj drugo okolje« in ponovite postopek. Ko končate z vsemi okolji Edge, preprosto kliknite »Nadaljuj«, da nadaljujete s konfiguracijo drugih okolij, ali »Zapri«, da se vrnete na glavni seznam.
Edge Agent v asinhronem načinu in z nizkokakovostnimi povezavami
Asinhroni način agenta Portainer Edge je zasnovan za scenarije, kjer je povezljivost omejena, draga ali zelo nestabilna (mobilne povezave ( povezljivost 5G M2M ), podeželske povezave, naprave, ki se povezujejo le občasno itd.). V tem načinu se ne vzpostavi interaktivni tunel v realnem času; namesto tega agent Edge v nastavljivih intervalih pošilja posnetke stanja strežniku Portainer.
Z asinhronostjo ne morete odpreti interaktivnih sej z oddaljenim okoljem, lahko pa si ogledate nedavno stanje gruče in zaženete dejanja na podlagi tega posnetka. Poraba podatkov je veliko manjša, zaradi česar je idealna za uvedbe na robu omrežja, kjer šteje vsak megabajt.
V asinhronem načinu potrebuje Edge Agent le, da ima strežnik odprta vrata uporabniškega vmesnika (9443 ali enakovredna vrata NodePort). Vrata za tunel 8000 niso več potrebna, kar dodatno poenostavi dostop do javnih vrat. Nastavitev okolja v Portainerju je zelo podobna standardnemu načinu; v čarovniku za okolje Docker Swarm preprosto izberete »Edge Agent Async«.
Če želite dodati Edge Async, pojdite v Okolja → Dodaj okolje, izberite »Docker Swarm«, zaženite čarovnika, izberite »Edge Agent Async« in izpolnite osnovne podatke. V razdelku »Več nastavitev« imate tri pomembne intervale: Ping, Snapshot in Command , ki nadzorujejo frekvenco srčnega utripa, posodobitev posnetka okolja in preverjanje novih ukazov. Privzeto je vse nastavljeno na eno minuto, vendar lahko to po potrebi prilagodite.
Tako kot v standardnem načinu lahko s skupinami in oznakami kategorizirate okolja Edge, ustvarite okolje, pridobite žeton za pridružitev in ko je ukaz za vašo platformo (Linux ali Windows) ustvarjen, ga zaženete na oddaljenem gostitelju. Vsak asinhronski agent se bo registriral in Portainer vam bo lahko prikazal njegovo stanje na podlagi najnovejšega prejetega posnetka.
Tipičen scenarij: dva VPS-ja v različnih regijah in uporaba Portainerja
Precej pogost primer je, ko ima nekdo dva VPS-ja na različnih lokacijah (na primer enega v New Yorku in enega v Seattlu) in ju želi upravljati s Portainerjem, ne glede na to, ali uporablja Docker Swarm ali ne, ter nastaviti stvari, kot so Prometheus, cAdvisor in Node Exporter z zasebnim notranjim prometom med vozlišči.
V takšnem primeru se sprašujete, ali je dovolj uporabljati samo Swarm ali pa potrebujete tudi Portainer Agent ali Edge Agent na vsakem VPS-ju. Docker Swarm sam po sebi zagotavlja orkestracijo in prekrivno omrežje med vozlišči, kar na primer omogoča, da instanca Prometheus na newyorškem VPS-ju zbira meritve iz vsebnikov v Seattlu prek šifriranega prekrivnega omrežja.
Portainer v tem kontekstu ni obvezen, vendar je zelo priporočljiv za centralizacijo upravljanja storitev, skladov, nosilcev podatkov in omrežij . Če na enem od VPS-jev (na primer v New Yorku) nastavite strežnik Portainer, lahko VPS v Seattlu povežete z robnim agentom. Na ta način vam ni treba odpirati Docker API-ja ali vzdrževati zunanje dostopnih vrat za klasične agente.
Kar zadeva zakasnitev med vozlišči Swarm v različnih mestih, je ta običajno v desetih milisekundah, kar v večini primerov ni resen problem za storitve, kot so Prometheus, Node Exporter ali cAdvisor, ki redno izvajajo strganje podatkov. Vendar je to treba upoštevati, če boste izvajali storitve, ki so izjemno občutljive na zakasnitev ali doslednost med vozlišči.
Če povzamemo, je najpogostejša in najpraktična nastavitev za to vrsto konfiguracije uporaba Docker Swarm za gruče in prekrivna omrežja med VPS-ji ter uporaba Portainer Edge Agent (boljši od standardnega agenta) za varno upravljanje oddaljenih VPS-jev brez odpiranja nepotrebnih vrat. Klasični agent je smiseln, kadar je vse v istem omrežju ali ima zelo neposredno povezljivost; v geografsko porazdeljenih scenarijih je Edge Agent logična izbira.
Robna delovna mesta v Portainerju na Docker Swarmu
Druga zmogljiva funkcija pri delu z okolji Portainer in Swarm so Edge Jobs (Opravila na robu). Ta opravila vam omogočajo, da določite naloge, ki se bodo izvajale v vaših robnih okoljih, ki jih upravlja Portainer, kar je zelo uporabno za vzdrževanje, ponovno konfiguracijo ali občasne uvajanja.
Ponavljajoče se vprašanje je, ali je mogoče prisiliti opravilo Edge, da se izvaja na določenem vozlišču v gruči Swarm. V mnogih primerih se zdi, da se opravilo vedno izvaja na enem od vozlišč in nimate jasnega nadzora nad tem, na katerem se izvaja, kar je lahko zmedeno, če pričakujete uravnoteženo delovanje ali želite ciljati na določeno vozlišče.
Ključ do nadzora nad tem je v razumevanju, kako Portainer distribuira opravila in kako Swarm upravlja njihovo razporejanje . Glede na to, ali je opravilo zagnano kot samostojni vsebnik na vozlišču, ki ga upravlja Edge Agent, ali kot storitev znotraj gruče Swarm, boste imeli večji ali manjši nadzor prek omejitev ali konfiguracije opravila Edge.
Čeprav lahko izkušnja takoj po namestitvi daje vtis, da je vozlišče izbrano naključno, lahko eksperimentirate z oznakami vozlišč, skupinami in pravili dodeljevanja, da bolje določite, kje se posamezno opravilo izvaja. Tukaj je vredno natančno pregledati dokumentacijo Portainerja in izvajati nadzorovane teste, dokler ne dobite jasnega razumevanja vzorca razporejanja.
Portainer doma: Edge Agent za nadzor naprav, kot je Raspberry Pi
Ko govorimo o uporabi Portainerja za upravljanje domačih naprav ali majhnih gostiteljev, kot je Raspberry Pi , se pristop nekoliko spremeni. Tukaj so Dockerjevi gostitelji zelo pogosto za NAT-om, v domačih omrežjih in brez neposrednega javnega IP-naslova, zaradi česar je izpostavljanje Dockerjevega API-ja ali klasičnega agenta internetu neprijetno in tvegano.
V tem kontekstu se mnogi uporabniki odločijo za uporabo Portainer Edge Agent v standardnem načinu za nadzor svojega Raspberry Pi ali drugih naprav. Na ta način ni treba spreminjati konfiguracije Dockerja, da bi omogočili TCP API ali odprli izpostavljene vtičnice. Edge Agent, kot opomnik, odpre povezavo s strežnikom in prečka NAT, ne da bi se morali ukvarjati s posredovanjem vrat. Poleg tega se te naprave pogosto uporabljajo za projekte vgrajenega vida z OpenMV in drugimi robnimi aplikacijami.
Klasični agent Portainer zahteva, da se strežnik Portainer lahko neposredno poveže z agenti , kar ni vedno izvedljivo v domačem omrežju z usmerjevalniki CG-NAT ali ponudniki internetnih storitev. Poleg tega vključuje odpiranje vrat zunaj domačega omrežja, kar na splošno ni najbolj priporočljiv pristop z vidika varnosti, če nimate vzpostavljene robustne strategije zaščite.
Z Edge Agentom pa potrebujete le, da ima strežnik dostop do uporabniškega vmesnika (in v standardnem načinu do tunelskega vhoda) iz interneta ali omrežja, kjer se nahajajo vaše naprave. Ko so Edge Agents povezani, v glavnem pogledu Portainerja ("Domov") vidite vsako napravo kot neodvisno okolje in lahko s skupinami in oznakami organizirate na ducate Raspberry Pi ali robnih naprav, ne da bi pri tem pretiravali.
Asinhroni način v primerjavi s standardnim načinom v robnih okoljih
Pomembna odločitev pri izbiri agenta Portainer Edge je, ali boste delovali v standardnem ali asinhronem načinu . Standardni način ponuja izkušnjo, ki je zelo podobna skoraj lokalnemu gostitelju: v vsebnikih lahko odprete konzolno sejo, si ogledate dnevnike v živo, interaktivno namestite sklade in tako naprej.
Asinhronski način pa žrtvuje interaktivnost, da bi zmanjšal porabo pasovne širine in bolje prenašal neenakomerne povezave . V okoljih, kjer želite le občasno preveriti stanje, zagnati določena opravila in prihraniti podatke, je asinhronski način pametna izbira. V obeh primerih vam Portainer še vedno omogoča kategorizacijo in upravljanje okolij po skupinah in oznakah.
Kar zadeva odprta vrata, standardni način zahteva tako vrata uporabniškega vmesnika kot vrata tunela , medtem ko asinhroni način zahteva le vrata uporabniškega vmesnika. Če ste na strogi varnostni poti ali želite zmanjšati izpostavljeno površino, asinhroni način znatno poenostavi namestitev, vendar za ceno izgube interaktivnega tunela TLS.
Docker in WebAssembly (Wasm) za robne delovne obremenitve
Ko se premaknemo na področje robnega računalništva na zelo omejenih napravah (majhni ARM-i, prehodi z malo RAM-a itd.), lahko celo tradicionalni vsebniki postanejo nekoliko nerodni. Tukaj nastopi WebAssembly (Wasm), ki se že izvorno integrira z Dockerjem prek izvajalnih okolij, kot sta WasmEdge ali Wasmtime.
Prednosti Wasma za robno računalništvo so očitne: zelo majhne binarne datoteke, skoraj takojšen zagon in močna izolacija na podlagi zmogljivosti. Poleg tega je prenosljivost med arhitekturami (x86, ARM, RISC-V itd.) zelo visoka, ker se binarna datoteka Wasma izvaja v izvajalnem okolju in ne neposredno v operacijskem sistemu.
Za uporabo Wasma z Dockerjem na robu omrežja potrebujete različico Dockerja, ki Podpora za izvajanje WasmDocker Desktop različice 4.15 ali novejše ali Docker Engine s containerdom 1.7 ali novejšim običajno deluje. Če to omogočite v daemon.json shrambo slik `containerrd` in deklarirajte ustrezna izvajalna okolja Wasm (na primer, io.containerd.wasmedge.v1 o io.containerd.wasmtime.v1) in nato znova zaženite Dockerjev demon.
Tipičen primer je majhna storitev obdelava podatkov senzorjev Napisano v Rustu in prevedeno v Wasm (cilj) wasm32-wasiTa program lahko bere podatke JSON vrstico za vrstico, filtrira odčitke, ki presegajo določene pragove temperature ali vlažnosti, in izdaja opozorila prav tako v JSON, vse z neverjetno nizko porabo virov.
Ko je enkrat preveden v WebAssembly, lahko uporabite Minimalističen, na nič temelječ Dockerfilekopiranje samo binarne datoteke .wasm in jo deklarirati kot VSTOPNO TOČKO. Pri ustvarjanju slike z docker buildx za ploščad wasi/wasm In ko ga naložite lokalno, boste videli, kako je nastala velikost le nekaj megabajtov v primerjavi s slikami Pythona ali Node, ki zlahka dosežejo gigabajt.
Uvajanje Wasma na robu omrežja z Dockerjem in Composeom
V resničnih robnih arhitekturah je običajno več storitev na napravo: procesorji senzorjev v WASM, posredniki MQTT za komunikacijo, podatkovne baze časovnih vrst, lahki povratni proxyji itd. Docker Compose je idealen za združevanje vsega tega v eno samo datoteko.
Primer robnega vozlišča bi lahko imel storitev Wasm za obdelavo odčitkov (z uporabo ustreznega izvajalnega okolja Wasm), posrednika Eclipse Mosquitto za prejemanje podatkov senzorjev, bazo podatkov TimescaleDB/PostgreSQL za shranjevanje časovnih vrst in Caddy kot obratni posrednik za izpostavljanje API-jev ali nadzornih plošč. Vsaka storitev bi imela svoja vrata, nosilce podatkov in politike vedno vklopljenega ponovnega zagona.
Za lažjo distribucijo je običajno vzpostaviti lokalna registracija Dockerja na samem Edge Gatewayu, običajno v vratih 5000. Svojo sliko Wasm zapakirate, oznake proti localhost:5000/... in ga potisnete v register. Iz drugih bližnjih robnih vozlišč lahko črpate podatke iz tega lokalnega registra, kar zmanjša zakasnitev in porabo virov za oddaljene registre.
V zelo omejenih sistemih je priporočljivo nastaviti tudi stroge omejitve virov : največjo količino pomnilnika (na primer 32 MB) in omejitve procesorja (0.5 jedra itd.), tudi če vemo, da Wasm sam porabi malo virov. To preprečuje, da bi napaka ali porast obremenitve zamrznila napravo in vas prisilila k ročnemu ponovnemu zagonu.
Omrežja, roj in toleranca prekinitev povezave na robu
Na robu omrežja so običajno manj zanesljiva kot v podatkovnem centru : pogosti izpadi, spremembe IP-naslovov, mobilne povezave itd. Zaradi tega je običajno, da se na vsakem vozlišču ustvarijo namenska mostna omrežja s prilagojenimi podomrežji ali celo zgradijo večmestna omrežja, povezana prek VPN-jev ali varnih predorov.
Z Dockerjem lahko ustvarite izolirana mostna omrežja z lastnim imenom mostu na gostitelju (na primer edge-br0) in nato povežite svoje storitve s tem omrežjem, da dosežete večjo ločitev od preostalega prometa. Če greste še korak dlje in na robnem prehodu nastavite Docker Swarm, lahko uporabite prekrivna omrežja za povezovanje kontejnerjev med več vozlišči z uporabo mehanizma shranjevanja v gručah in oglaševanja v gručah (običajno na Consulu ali drugem zalednem sistemu).
Za scenarije z več gostitelji s Swarmom ostaja Docker Machine uporabno orodje, kar dokazujejo nekatere uvedbe z OpenNebulo . V tem primeru lahko uporabite docker-machine z gonilnikom OpenNebula za zagon virtualnih strojev z boot2dockerjem, nastavitev konzula za odkrivanje, ustvarjanje glavnega strežnika in vozlišč Swarma ter končno povezavo vsega s prekrivnimi omrežji.
Ideja je preprosta: najprej ustvarite virtualni stroj (VM) za Consul, ga zaženete z ustreznim vsebnikom na vratih 8500, pridobite njegov IP-naslov in nato ta IP-naslov uporabite v ukazih `docker-machine create` z možnostma `--swarm` in `--swarm-discovery` . Z konfiguriranima možnostma `cluster-store` in `cluster-advertise` lahko nato ustvarite prekrivno omrežje in zaženete storitve (na primer Nginx na enem vozlišču in BusyBox na drugem), ki lahko med seboj komunicirajo z uporabo imen storitev.
V robnih okoljih, kjer se pogosto pojavljajo prekinitve povezav, je priporočljivo omogočiti lokalno shranjevanje z uporabo nosilcev podatkov ali povezav za shranjevanje podatkov na disku, ko se povezava prekine ( kibernetska odpornost podatkov ). To omogoča vašim vsebnikom, da zbirajo podatke (na primer odčitke senzorjev) in jih pošiljajo v velikem obsegu, ko se povezava obnovi, po vzorcu »shranjevanja in posredovanja«.
Na ravni spremljanja Docker ponuja preprost ukaz, kot je docker stats za pridobitev osnovnih meritev CPU-ja, pomnilnika in omrežnega prometa. Za resnejše uvedbe je običajno uporabljati lahke agente, kot so Izvoznik vozlišč skupaj s Prometheusom, celo definiran v ločenem "spremljevalnem" docker-compose-u, ki izpostavlja metrike gostitelja osrednjemu ekosistemu opazovalnosti.
Posodabljanje teh robnih uvedb je z Dockerjem tudi lažje: prenesete novo sliko, zaustavite stari vsebnik, ga izbrišete in znova zaženete storitev z novo različico. Ker se vsebniki Wasm zaženejo v milisekundah, je čas izpada minimalen, kar je neprecenljivo, ko rob zbira podatke v realnem času.
S tem pregledom postane bolj jasno, kako se deli med seboj ujemajo: Docker Swarm zagotavlja orkestracijo in prekrivno omrežje, Portainer Edge Agent poenostavlja oddaljeno upravljanje brez odpiranja tveganih vrat, Wasm pa zmanjšuje stroške izvajanja aplikacij na vitki strojni opremi . Z ustreznim načrtovanjem vrat, omrežij in načinov agentov (standardnih ali asinhronih) lahko zgradite robustne, porazdeljene robne arhitekture na več lokacijah, pripravljene za skaliranje brez vsakodnevnih administrativnih glavobolov.
