‫Așa că puțină magie nu era de fapt magică. A fost rețeaua de rutare. Meshul de rutare este
‫o rețea de intrare sau de intrare care distribuie pachete pentru serviciul nostru sarcinilor pentru acel serviciu,
‫deoarece putem avea mai multe sarcini.
‫Aceasta acoperă de fapt toate nodurile și folosește primitive Kernel care au fost în jur de
‫ceva timp numite IPVS.
‫Deci nu vorbim de un serviciu nou. Chiar vorbim despre
‫caracteristicile principale ale kernel-ului Linux. Ceea ce face cu adevărat aici este echilibrarea încărcării
‫în toate nodurile și ascultarea pe toate nodurile pentru trafic.
‫Există câteva moduri în care putem vorbi despre cum funcționează acest lucru.
‫Primul exemplu este de la un container la altul.
‫Dacă sistemul nostru backend, cum ar fi bazele de date, a fost mărit la două replici, interfața care vorbește
‫cu backends
‫nu ar vorbi direct cu adresa lor IP.
‫Ei vor vorbi de fapt cu ceva numit VIP sau Virtual IP, pe care Swarm îl pune în
‫fața tuturor serviciilor.
‫Aceasta este o IP privată în cadrul rețelei virtuale a Swarm și asigură că sarcina este distribuită între
‫toate sarcinile pentru un serviciu.
‫Deci, dacă vă puteți imagina dacă ați avea un rol de muncitor în aplicația dvs. și avea 10 containere diferite, nu trebuie să puneți un balancer
‫de sarcină în fața acestui lucru.
‫Asta face asta pentru tine.
‫Când vorbiți despre trafic dintr-un serviciu din interiorul rețelei dvs. virtuale vorbind cu un alt serviciu din
‫interiorul rețelei virtuale.
‫Iar cel de-al doilea exemplu de funcționare a rețelei de rutare este traficul extern care intră în roiurile
‫tale, poate alege să lovești oricare dintre nodurile din roiurile tale.
‫Oricare dintre nodurile lucrătorilor vor avea portul publicat deschis și vor asculta traficul respectivului container și
‫apoi vor reroute traficul respectiv la containerul corespunzător pe baza echilibrării încărcării acestuia.
‫Ce înseamnă asta atunci când desfășurați containerele într-un roi, nu trebuie să aveți grijă de serverul pe
‫care se află, pentru că s-ar putea mișca, nu?
‫Dacă un container eșuează și sarcina este recreată de roi, ar putea fi pusă pe un nod diferit. Și cu siguranță nu doriți să trebuiască să
‫schimbați paravanul de protecție sau setările DNS pentru ca acest container să funcționeze
‫din nou.
‫Meshul de rutare rezolvă o mulțime de probleme, permițând site-ul nostru Drupal de pe portul 80 să
‫fie accesibil din orice nod din roi. Și în fundal, ia acele pachete de pe acel
‫server și apoi le direcționează către container. Dacă se află pe un nod diferit, în acesta va fi
‫direcționat peste rețelele virtuale.
‫Dacă se află pe același nod, îl va redirecționa către portul containerului respectiv.
‫Și nu trebuia să facem nimic pentru a permite acest lucru.
‫Totul a ieșit din cutie.
‫Să vedem o diagramă a modului în care ar putea funcționa acest lucru.
‫Dacă am creat un serviciu de știri și i-am spus să aibă trei replici. Și a creat trei sarcini,
‫cu trei containere, pe trei noduri. În interiorul acelei rețele suprapuse, este de fapt crearea unei adrese IP virtuale
‫care este mapată la numele DNS al serviciului, nu? Iar serviciul, în mod implicit, numele DNS, este numele
‫serviciului.
‫În acest caz, am creat un serviciu numit my-web și orice alte containere pe care le am în rețelele suprapuse care
‫trebuie să discute cu serviciul respectiv în interiorul roiului, trebuie doar să
‫vă faceți griji cu privire la utilizarea DNS-ului meu web. Încărcarea corectă virtuală a IP-ului
‫dă naștere traficului între toate sarcinile din acel serviciu.
‫Acest lucru nu este de fapt Robin DNS rotund. Aceasta este de fapt o configurație ușor diferită. Am putea permite
‫acest lucru dacă vrem. Există de fapt o opțiune de a utiliza Robinul rotund DNS.
‫Beneficiile VIP-urilor peste Round Robin sunt că de multe ori cache-urile DNS din interiorul aplicațiilor noastre ne împiedică să
‫distribuim în mod corespunzător încărcătura.
‫Mai degrabă decât să ne luptăm cu clienții DNS în configurația DNS, ne bazăm doar pe VIP, ceea ce
‫este cam așa cum ați avea dacă ați cumpărat un balancer de încărcare hardware dedicat.
‫În cel de-al doilea exemplu, aceasta arăta de fapt ce ar însemna traficul extern.
‫Acest lucru este similar cu ceea ce am făcut cu Drupal, când am creat aceste cutii galbene, prin
‫crearea unui serviciu, numit webul meu, și a creat două sarcini și le-a aplicat la două noduri diferite, fiecare dintre acele noduri având
‫o construcție -în balancer de sarcină pe adresa IP externă. Pentru mine, pentru că folosesc DigitalOcean, adresa IP
‫este cea pe care mi-a oferit-o DigitalOcean. Când folosesc -p și-l publică pe un
‫port, în acest exemplu utilizează portul 80:80, orice trafic care intră în oricare dintre aceste trei
‫noduri de hit-uri care balancerază încărcarea pe portul 80:80. Balancerul de încărcare decide care container trebuie să obțină traficul și dacă
‫traficul respectiv este sau nu pe nodul local sau trebuie să trimită traficul prin
‫rețea către un alt nod.
‫Din nou, acest lucru se întâmplă de fapt în fundal, fără eforturi deosebite din partea noastră.
‫In regula. Să vedem această rețea de direcționare în acțiune.
‫Am văzut deja exemplul cu Drupal și cum ascultă toate cele trei noduri.
‫Dar dacă am avea mai multe sarcini care văd că balancerul de sarcină funcționează.
‫Dacă facem un serviciu de docare
‫creat, ceea ce vom face este că vom folosi un container Elasticsearch. Vom numi căutarea și vom
‫da trei replici. Și doriți să-l publicați pe portul 9200, care este portul implicit.
‫În acest caz, vom dori cu siguranță: 2 acolo, deoarece este cea mai ușoară versiune de
‫a instala chiar acum. În timp ce asta
‫creează, voi menționa că Elasticsearch este de fapt o bază de date de căutare accesibilă printr-un API web
‫JSON.
‫Deci, este foarte ușor să vă loviți cu buclă și să ne dați exemple bune despre cum funcționează acest lucru.
‫Fac un serviciu de căutare doc, vedem că este creat inteligent fiecare sarcină pe un alt nod.
‫Dacă fac doar o curl pe localhostul meu, pe nodul 1 pe portul 9200 pentru că am publicat acel port, voi
‫primi din nou informațiile de bază ale Elasticsearch. O parte din aceasta este că va crea un nume
‫aleatoriu.
‫Asta e doar o caracteristică din Elasticsearch.
‫Dacă mă încurc de mai multe ori, veți vedea pe asta că este Patch, serverul Patch și
‫apoi pentru
‫a treia oară, Jane Foster, și apoi va începe să se repete ca atare.
‫Aceasta este de fapt IP-ul virtual care acționează ca un balancer de sarcină și distribuind sarcina mea în
‫cele trei sarcini.
‫Mai multe note despre plasa de rutare. În 17. 03, care este versiunea pe care ți-o arătam
‫acum, plasa de rutare și echilibrarea încărcării sunt în prezent un balancer de sarcină apatrid.
‫Dacă v-ați confruntat vreodată cu statul în interiorul balancerului de încărcare clasic al lui Amazon sau al altor tehnologii de echilibrare a
‫încărcăturilor, știți despre ce este vorba.
‫Acest lucru înseamnă, în principiu, că dacă trebuie să utilizați modulele cookie de sesiune pentru aplicația dvs. sau dacă se așteaptă ca un container
‫consistent să vorbească cu un client coerent, atunci este posibil să fie nevoie să adăugați alte lucruri care să ajute
‫la rezolvarea acestei probleme.
‫Din cutie, de fiecare dată când atingi un serviciu cu mai multe sarcini, te va da un
‫rezultat diferit.
‫De asemenea, dacă intri în detalii, este de fapt un balancer de încărcare a stratului-3, și de fapt
‫funcționează la nivelul IP și al portului.
‫Nu funcționează efectiv la nivelul DNS.
‫Dacă ați rulat vreodată mai multe site-uri pe același port, pe același server, acest lucru nu va fi făcut
‫încă.
‫Încă mai aveți nevoie de o altă piesă
‫a puzzle-ului, dacă doriți să rulați mai multe site-uri web în același port, pe același roi.
‫Din fericire, aceasta este o cerere destul de comună și există mai multe opțiuni pe care le puteți face pentru a
‫rezolva aceste două probleme.
‫Unul dintre ele este să utilizați Nginx sau HAProxy, care sunt destul de bune exemple în afara containerelor care se vor așeza
‫în față cu plasa de rutare și de fapt vor acționa ca un balancer de încărcare de stat sau un strat
‫pentru balancerul de încărcare, și multe alte lucruri. Dacă aveți nevoie de acest lucru, este posibil
‫să doriți să verificați unele dintre acestea din resursele acestei secțiuni.
‫De asemenea, ar trebui să menționez că, dacă plătiți pentru o abonament la ediția Docker Enterprise, cu aceasta vine ceva
‫numit UCP sau Docker Data Center, care este o interfață web. Dar ar trebui să menționez că ediția Docker Enterprise,
‫dacă primești un abonament la asta pentru nodurile tale de roiuri, de fapt vine cu
‫un strat încorporat pentru proxy web care îți permite să arunci numele DNS în config-ul web al serviciilor tale
‫de roiuri și totul funcționează.