Docker

Címkék: #<Tag:0x00007f04ffab5170> #<Tag:0x00007f04ffab4748> #<Tag:0x00007f04ffab4608>

Most ismerkedem a Docker fogalmával, lehetőségeivel. Hozzáteszem nem vagyok sebfejlesztő, de van egy webes alkalmazásom, amely különálló frontendre (Angular) és backendre (php) épül.
Amúgy most elméleti kérdésem lenne, nem technikai.
Külön dockerbe kerülne az Angular és külön dockerbe a backend, külön dockerbe az Nginx.
Az Angular alkalmazás JWT tokénekkel kommunikál. A token érvényességét a backend ellenőrzi. Egyrészt szeretném a backendet lecserélni (Swift, azon belül Vapor) dockerre, másrészt a tokenek létrehozását ellenőrzését, felhasználók adatainak tárolását szintén egy külön dockerbe szervezném.
Tehát ezek a dockerek lennének:

  1. Angular frontend
  2. Swift-Vapor backend
  3. Nginx
  4. Token és felhasználó jelszó és adat kezelés.

Kérdésem az lenne, hogy a Dockerek között hogyan lehet megoldani a biztonságos kommunikációt? Persze azt figyelembe véve, hogy gyors is legyen. Azaz pl ha a backend a kérését szintén aláírná saját titkos kulcsával, a 4. docker pedig az ahhoz tartozó publikus kulccsal ellenőrizné, hogy helyes-e az aláírás és visszaküldi a kért adatot. Nos ez biztos lassítaná az egész folyamatot, tehát ezt elkerülném. Vagy a docker megoldja a biztonságos kommunikációt?
Persze úgy gondoltam, hogy a Dockerben létrehozok előre egy networköt ezen dockereknek. A félelmem amúgy az, hogy a 4. dockernél is használnom kell majd webszervert, hogy ki tudja szolgálni a backendet. És ha fut rajta a webszerver, akkor azok elérhetőek a hoston is docker környezeten kívül. Persze nyílván a szerverről nem engedem ki azt a portot, amivel kommunikál a backend és a 4. docker, de elég lehet ez a biztonság?

Docker network:

1 Like

Köszi!
Megnéztem és itt csak az alap networking kerül szóba. Biztonságos kommunikáció egyáltalán nem. Kerestem neten erről infókat de egyáltalán nem találtam.

Mondjuk lehet nem voltam egyértelmű a kérdésben, hogy pontosan mit is szeretnék:
Csak a 3. Docker azaz az Nginx legyen elérhető a host-ról. Viszont mindegyik Docker tudjon kommunikálni egymással (biztonságosan).

Ugyanakkor mégis hasznos volt ez a leírás, csak másképp: az Amazonos ECS futtatásról adott népi látképet, azzal egyáltalán nem foglalkoztam eddig, de legalább tudom majd hol induljak el!

Nem olvastad elég figyelmesen, létre lehet hozni olyan bridge networköt, amihez csak a megadott dockerek férnek hozzá:

The network create command creates a new bridge network, which is what we need at the moment. In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network.

De itt csak a többi konténertől tudod “megvédeni” az adott dockert, a host hozzáférhetőségétől nem.

Dehogynem, ha mondjuk titkosítod a kapcsolatot a két docker között:

Köszi a kitartó segítséget.

Őszintén szólva olvastam az overlay networksről, de nem foglalkoztam vele részletesebben, mert ahogy olvastam - és az itt megjelenő rövid leírásban is olvasható - két külön hoston lévő Docker kommunikációjához kell.

Ugyanakkor elkezdtem olvasni és közben esett le, hogy amit akarok az pofon egyszerű. Persze nem overlay networkkel.

Szóval a bridge networkkel is meg lehet oldani a problémám. Csakhogy az összes tutorial amit néztem, mind-mind azt írta, hogy a dockerből nyissunk portot ahhoz, hogy elérjük a belső szolgáltatást. De az overlay network dokumentáció olvasása közben esett le, hogy nem kell kinyitni portotokat, hogy két Docker ugyanazon a networkön kommunikálni tudjon egymással. Magyarán a 4 dockerből amit írtam, abból csak az nginxnek kell portot nyitni a host felé és a többi Docker természetesen ugyanazon a networkön legyen és elérik egymás szolgáltatásait hálózaton belül.

Köszi még egyszer a türelmet!

1 Like

Amúgy ha egy hoston vannak a dockerek elvileg izoláltak a hosttól, de én ezt nem teszteltem valós körülmények között. Én egyelőre a virtuális gépekben hiszek, majd meglátom pár év múlva, hogy ez jó ötlet volt -e. Az a koncepcióm, hogy könnyebb egy vas elhalálozása esetén mentésből visszarakni a vm-eket, mint a dockereket. Az első katasztrófa után majd leírom a tapasztalataimat, de tesztek alapján működik a koncepcióm nálunk.

Ez egy fórum, akitudsegít. Már ha nem mainframe-en akarsz zenemintákat tárolni 😂

5 Likes

Mi is VMware környezetben üzemeltetünk. Szeptemberben vettünk át külsősök által fejlesztett alkalmazásokat, amelyek mind Dockerben készültek. (Ráadásul nem az általunk supportált Linuxon).
Emiatt elkellett kezdenem megérteni a Docker működését, felépítését, főleg mert üzemeltetési része hozzánk tartozik. Viszont a koncepcióban látom az értelmet. Én nem mondom azt, hogy a Docker le fogja váltani a virtuális gépek világát. Szerintem a kettő együtt egymás mellett fog letenni. Hol az egyik, hol a másik lesz a megoldás.
A Docker előnye szerintem ott van, hogy egyrészt két vagy több alkalmazást egy virtuális hoston el tudsz különíteni egymástól, így biztonságosabbá lehet tenni az alkalmazásokat. Másrészt mindegyik Docker pont azt és annyi csomagot tartalmaz, mint amire és amennyire szüksége van. Pl ha egyik alkalmazás még php5.3 a másik lehet php 7.2. Persze tudom, hogy ezt meg lehet oldani másként is. Viszont szerintem ha egy virtuális szerver több virtual holtot szolgál ki, akkor már érdemes ott Dockerben gondolkodni.
Amúgy virtuális gép snapshotból sem lehet mindent visszaállítani. Tipikus példa erre megannyi Windowsos szolgáltatás. :D
Amúgy nálunk két Docker környezet van. Egy éles és egy backup. Ha elhalálozik az éles, átveszi a helyét a backup. És van időnk visszaállítani az élest. És amúgy a Docker visszaállítása egyáltalán nem bonyolult. Amúgy a Docker szervereket is lehet snaphotolni, ha úgy van. :)