﻿1
00:00:05,810 --> 00:00:10,720
‫Această secțiune va fi plină de prelegeri și sarcini în jurul datelor persistente.

2
00:00:11,230 --> 00:00:16,490
‫În primul rând, vom discuta despre problemele de date persistente și despre cum a devenit chiar

3
00:00:16,490 --> 00:00:18,280
‫o problemă în primul rând.

4
00:00:18,290 --> 00:00:23,640
‫Conceptele cheie pe care trebuie să le înțelegeți sunt ideea unei infrastructuri imuabile.

5
00:00:23,810 --> 00:00:28,580
‫Și ideea în jurul containerelor este în mod natural efemer în design.

6
00:00:28,880 --> 00:00:36,680
‫Vom acoperi cele de la prima conferință. Apoi ne vom arunca cu capul în volume de date și

7
00:00:36,680 --> 00:00:44,270
‫cum rezolvă unele dintre problemele noastre în jurul datelor persistente. Apoi, vom săpați în mount-uri de legare și cum

8
00:00:44,360 --> 00:00:50,660
‫rezolvă diferite probleme cu date persistente. Apoi, vom termina această secțiune cu câteva sarcini în jurul modului în care

9
00:00:50,720 --> 00:00:57,530
‫să păstrăm datele bazei de date, în timp ce înlocuim containerele pentru bazele de date. Și apoi, de asemenea, în jurul valorii de

10
00:00:57,740 --> 00:01:03,320
‫fapt montarea cod într-un container de la gazdă în timp ce îl editați, astfel

11
00:01:03,320 --> 00:01:11,560
‫încât să puteți rula acest cod în interiorul container live. Cerințele pentru această primă conferință sunt doar înțelegerea modului în care

12
00:01:11,560 --> 00:01:16,970
‫se execută containerele și conceptele despre containere și imagini pe care le-am discutat până acum.

13
00:01:17,050 --> 00:01:23,230
‫Până acum, vă îngrijorează doar ceea ce este necesar pentru a rula un container, nu datele unice care ar putea fi create

14
00:01:23,230 --> 00:01:24,920
‫odată ce un container rulează.

15
00:01:25,840 --> 00:01:29,200
‫Containerele sunt menite să fie imuabile și efemere.

16
00:01:29,320 --> 00:01:34,220
‫Acestea sunt doar buzzwords fantezie pentru neschimbat și temporar, sau de unică folosință.

17
00:01:34,480 --> 00:01:40,180
‫Ideea este că putem să aruncăm un container și să creăm unul nou dintr-o imagine,

18
00:01:40,180 --> 00:01:40,770
‫nu?

19
00:01:41,790 --> 00:01:47,820
‫Apoi, nu vorbim despre o limitare reală a containerelor, ci mai degrabă despre un scop de proiectare sau despre

20
00:01:47,820 --> 00:01:49,070
‫o bună practică.

21
00:01:49,080 --> 00:01:54,690
‫Aceasta este ideea unei infrastructuri imuabile în care nu schimbăm lucrurile odată ce rulează.

22
00:01:54,840 --> 00:02:00,330
‫Dacă trebuie să se întâmple o schimbare de configurare sau poate să se întâmple o actualizare a versiunii

23
00:02:00,330 --> 00:02:02,420
‫containerului, atunci redimensionăm un nou container.

24
00:02:02,490 --> 00:02:08,370
‫Acest lucru ne oferă beneficii uriașe în fiabilitate și consecvență, iar modificările se pot reproduce.

25
00:02:08,490 --> 00:02:10,350
‫Dar există un compromis.

26
00:02:10,350 --> 00:02:16,140
‫Cum rămâne cu datele unice pe care aplicația dvs. le va produce? Aceste baze de date sau o valoare de stocare-cheie sau orice altceva

27
00:02:16,140 --> 00:02:18,150
‫pe care aplicația dvs. o scutește într-un fișier?

28
00:02:18,330 --> 00:02:24,810
‫În mod ideal, containerele nu trebuie să conțină datele dvs. unice amestecate cu binarele de aplicații. Acest lucru este cunoscut sub numele

29
00:02:24,810 --> 00:02:30,340
‫de "separarea preocupărilor", iar Docker ne oferă un mare beneficiu aici.

30
00:02:30,450 --> 00:02:36,780
‫Putem actualiza aplicația noastră prin recrearea unui nou container, cu o versiune actualizată a aplicației noastre și, în mod ideal, datele noastre unice sunt

31
00:02:36,990 --> 00:02:42,530
‫în continuare acolo unde trebuie să fie și au fost păstrate pentru noi în timp ce recipientul nostru a fost reciclat.

32
00:02:42,540 --> 00:02:48,510
‫În cazul în care nu ați observat până acum, containerele pe care le-am utilizat în mod implicit au fost persistente.

33
00:02:48,510 --> 00:02:53,880
‫Orice schimbări în ele s-au păstrat de-a lungul repornirilor și repornirea până când am eliminat containerul.

34
00:02:54,240 --> 00:02:57,160
‫Doar pentru că am oprit containerul sau am restartat gazda,

35
00:02:57,300 --> 00:03:00,030
‫nu înseamnă că modificările fișierului din container vor dispărea.

36
00:03:00,210 --> 00:03:05,910
‫Doar atunci când scoatem containerul că stratul lui UFS dispare, dar vrem să reușim să facem acest

37
00:03:05,910 --> 00:03:07,160
‫lucru la nevoie.

38
00:03:07,170 --> 00:03:13,320
‫Această problemă a datelor unice este cunoscută în industrie ca "date persistente" și până la containere,

39
00:03:13,320 --> 00:03:19,230
‫nu am avut un nume pentru asta. Deoarece majoritatea lucrurilor pe care le-am construit au fost persistente, ca și

40
00:03:19,230 --> 00:03:24,090
‫cum ați ști acele servere vechi care rulează acea aplicație veche timp de cinci sau 10 ani sau mai mult.

41
00:03:24,270 --> 00:03:26,850
‫Totul a fost persistent în mod implicit.

42
00:03:26,850 --> 00:03:32,400
‫Acum, în noua lume a containerelor și scalarea automată a aplicațiilor, datele persistente creează o

43
00:03:32,400 --> 00:03:33,280
‫problemă unică.

44
00:03:33,420 --> 00:03:36,640
‫Docker are două soluții la această problemă, cunoscute sub

45
00:03:36,720 --> 00:03:42,450
‫numele de "volume de date" și "mount mounts. "Volumele Docker sunt o opțiune de configurare

46
00:03:42,450 --> 00:03:46,620
‫pentru un container care creează o locație specială în afara sistemului

47
00:03:46,620 --> 00:03:50,130
‫de fișiere union al containerului pentru stocarea datelor unice.

48
00:03:50,210 --> 00:03:55,470
‫Acest lucru îl păstrează prin eliminarea containerelor și ne permite să îl atașăm la orice recipient dorim.

49
00:03:55,940 --> 00:03:58,210
‫Și containerul o vede doar ca o cale de fișiere locală.

50
00:03:58,440 --> 00:04:05,670
‫Apoi, există mount-uri de legare, care sunt pur și simplu ne partajarea sau montarea unui director gazdă, sau fișier, într-un container.

51
00:04:05,970 --> 00:04:10,470
‫Din nou, va arăta ca o cale de fișier locală sau o cale de director către container.

52
00:04:10,470 --> 00:04:12,590
‫Nu va ști de fapt că vine de la gazdă.

