‫Acum, când am văzut secrete cu serviciile, să ne uităm la secrete cu stive. În acest director, sunt în eșantion două exemple
‫și în
‫acest director, am un fișier Compose și apoi două secrete stocate în fișiere text.
‫Deci este parola similară și numele de utilizator pe care le-am avut în cursul precedent, dar acum
‫am definit toate acestea într-un fișier Compose. Avem mai multe lucruri diferite aici.
‫Primul lucru este că versiunea fișierului Compose trebuie să fie 3. 1. Pentru a avea secrete, trebuie
‫să fim la. 1 eliberare de 3.
‫Așadar, trebuia să avem 3 pentru a folosi stive, dar pentru a folosi stive cu secrete, avem nevoie de 3. 1 sau mai
‫nou.
‫Cel de-al doilea lucru pe care îl vom observa este că aici, în partea de jos, avem această cheie secretă a rădăcinilor
‫acum și aici ne definesc secretele.
‫Cele două moduri în care puteți face secrete într-un fișier Compose fie folosesc un fișier pentru fiecare
‫secret, fie aveți secretele pre-create.
‫Aici, de fapt, folosim doar fișiere, dar ceea
‫ce am putea face este să creăm aceste secrete pe cont propriu, printr-o altă metodă, fie prin
‫CLI, așa cum ați văzut, fie prin API direct. Apoi, în loc de fișier, ar
‫fi fost doar: sub el, ar spune doar extern și ar fi numele secretului din lista
‫secretă.
‫Trebuie să spunem fișierul Compose despre secretele noastre și unde sunt și apoi le atribuim de fapt serviciilor
‫care au nevoie de ele.
‫Asta e cheia pentru că ceea ce spunem aici este că doar containerul care
‫dorește secretul nostru devine secretul nostru. Dacă acest fișier a fost complicat, unde am avut mai multe servicii, am putea
‫avea secrete diferite pentru diferite servicii.
‫Mai întâi, le definim pe toate în jos și apoi le atribuim în mod specific
‫la fiecare serviciu.
‫Voi spune că aceasta este de fapt considerată forma scurtă sau calea ușoară de a face secretele în cadrul
‫unui serviciu.
‫Există de fapt un formular lung care vă permite să definiți lucruri precum permisiunile și utilizatorii cărora
‫le este permis accesul utilizând modurile standard Linux și sintaxele de identificare a utilizatorilor.
‫Deci, dacă rulați aplicații ca utilizator non-root, doriți să direcționați aceste secrete doar către acel utilizator care
‫poate accesa aceste aplicații.
‫Dar, din simplitate, în acest prim exemplu, folosim doar formularul scurt.
‫Tot ce trebuie să fac este să folosesc acel fișier într-o comandă de stivă standard. Deci, implementați docker-compose și vom
‫numi acest micdb. Veți vedea, la fel ca înainte, de fapt, a creat prima rețea.
‫În acest caz, a creat mai întâi secretele și apoi a creat serviciul.
‫Dacă am mers și am făcut o căutare secretă a Docker-ului, atunci veți vedea că cei doi sunt acolo și
‫urmează aceeași convenție de denumire ca toate celelalte componente ale stivei, unde este întotdeauna numele stivei și
‫apoi numele obiectului.
‫La fel ca în cursul precedent, dacă am sărit pe serverul SQL și
‫am căutat efectiv acele fișiere, ar fi acolo ca și când au fost înainte; numai acum, sunt gestionați în fișierul nostru de stivă.
‫Lucrul frumos aici este dacă mi-am eliminat stiva, și curăță secretele și îi scapă de ei. În exemplul precedent, dacă vrem să
‫ne îndepărtăm secretele,
‫ar fi trebuit să facem un rm secret pentru a elimina efectiv
‫fiecare. La fel ca ultimul memento,
‫în aceste exemple am folosit fișiere text pe acest server și că vorbim despre un roi de 3
‫noduri aici.
‫Dar dacă sunteți într-un mediu de producție sau într-adevăr ceva care nu este pe mașina dvs. locală, nu
‫ar trebui să păstrați secretele în fișiere sau în fișierul de istorie bash sau în orice loc care ar putea fi probabil
‫pe acea gazdă.
‫Este un fel de înfrângere în scopul de a avea secretele în primul rând. Indiferent de procesul dvs. de obținere a
‫secretelor în Swarm, știți că este posibil să
‫aveți nevoie de curățare odată ce ați terminat acolo, pentru a nu lăsa secrete reziduale în jurul valorii
‫de care oamenii pot obține ușor.