1 00:00:05,810 --> 00:00:10,720 ‫Esta seção estará cheia de palestras e trabalhos em torno de dados persistentes. 2 00:00:11,230 --> 00:00:16,490 ‫Primeiro, vamos discutir os problemas de dados persistentes e como isso mesmo se tornou 3 00:00:16,490 --> 00:00:18,280 ‫um problema em primeiro lugar. 4 00:00:18,290 --> 00:00:23,640 ‫Os principais conceitos que você precisa entender são a idéia de infra-estrutura imutável. 5 00:00:23,810 --> 00:00:28,580 ‫E a idéia em torno de recipientes sendo naturalmente efêmera em design. 6 00:00:28,880 --> 00:00:36,680 ‫Vamos abordá-los na primeira palestra. Então vamos mergulhar em volumes de dados e como aqueles 7 00:00:36,680 --> 00:00:44,270 ‫solucionam alguns de nossos problemas em torno de dados persistentes. Então, também vamos cavar em montagens de ligação e 8 00:00:44,360 --> 00:00:50,660 ‫como isso resolve diferentes problemas com dados persistentes. banco de dados, ao mesmo tempo em que substitui os contêineres para bancos de dados. 9 00:00:50,720 --> 00:00:57,530 ‫Então, acabaremos com esta seção com algumas tarefas em torno de como preservar os dados do E, em seguida, também em torno do código 10 00:00:57,740 --> 00:01:03,320 ‫de montagem realmente em um recipiente do host enquanto você está editando, para que 11 00:01:03,320 --> 00:01:11,560 ‫você possa executar esse código dentro do contêiner ao vivo. Os requisitos para esta primeira palestra são apenas entender como 12 00:01:11,560 --> 00:01:16,970 ‫executar contêineres e os conceitos de contêineres e imagens que discutimos até agora. 13 00:01:17,050 --> 00:01:23,230 ‫Até agora, você só se preocupou com o que é necessário para executar um contêiner, e não os dados exclusivos que podem ser criados 14 00:01:23,230 --> 00:01:24,920 ‫assim que um contêiner está sendo executado. 15 00:01:25,840 --> 00:01:29,200 ‫Os recipientes devem ser imutáveis ​​e efêmeros. 16 00:01:29,320 --> 00:01:34,220 ‫Essas são apenas buzzwords extravagantes para imutáveis ​​e temporárias, ou descartáveis. 17 00:01:34,480 --> 00:01:40,180 ‫A idéia aqui é que podemos simplesmente jogar fora um recipiente e criar um novo a partir de uma 18 00:01:40,180 --> 00:01:40,770 ‫imagem, certo? 19 00:01:41,790 --> 00:01:47,820 ‫Então, não estamos falando de uma limitação real de contêineres, mas de um objetivo de design, ou 20 00:01:47,820 --> 00:01:49,070 ‫de uma melhor prática. 21 00:01:49,080 --> 00:01:54,690 ‫Esta é a idéia de infra-estrutura imutável onde não mudamos as coisas uma vez que elas estão sendo executadas. 22 00:01:54,840 --> 00:02:00,330 ‫Se uma mudança de configuração precisa acontecer, ou talvez a atualização da versão do contêiner tenha que 23 00:02:00,330 --> 00:02:02,420 ‫acontecer, então nós reimplementamos um novo recipiente. 24 00:02:02,490 --> 00:02:08,370 ‫Isso nos dá grandes benefícios na confiabilidade e consistência, e torna as mudanças reprodutíveis. 25 00:02:08,490 --> 00:02:10,350 ‫Mas há uma compensação. 26 00:02:10,350 --> 00:02:16,140 ‫E quanto aos dados exclusivos que seu aplicativo produzirá? Esses bancos de dados, ou um valor chave armazenam, ou qualquer outra 27 00:02:16,140 --> 00:02:18,150 ‫coisa que o seu aplicativo escreve em um arquivo? 28 00:02:18,330 --> 00:02:24,810 ‫Idealmente, os recipientes não devem conter seus dados exclusivos misturados com os binários do aplicativo. Isso é conhecido como "separação de 29 00:02:24,810 --> 00:02:30,340 ‫preocupações" e Docker realmente nos dá um grande benefício aqui. 30 00:02:30,450 --> 00:02:36,780 ‫Podemos atualizar nosso aplicativo recriando um novo contêiner, com uma versão atualizada do nosso aplicativo e, idealmente, nossos dados 31 00:02:36,990 --> 00:02:42,530 ‫exclusivos ainda são onde ele precisa ser e foi preservado para nós enquanto nosso recipiente foi reciclado. 32 00:02:42,540 --> 00:02:48,510 ‫Caso você não tenha notado até agora, os contêineres que usamos, por padrão, eram persistentes. 33 00:02:48,510 --> 00:02:53,880 ‫Todas as mudanças neles foram mantidas durante o reinício e reiniciaram até que removemos o contêiner. 34 00:02:54,240 --> 00:02:57,160 ‫Só porque nós paramos o recipiente ou reiniciamos o host, não 35 00:02:57,300 --> 00:03:00,030 ‫significa que as alterações de arquivo do recipiente se afastem. 36 00:03:00,210 --> 00:03:05,910 ‫É somente quando removemos o recipiente que a camada UFS desaparece, mas queremos fazer 37 00:03:05,910 --> 00:03:07,160 ‫isso à vontade. 38 00:03:07,170 --> 00:03:13,320 ‫Este problema de dados únicos é conhecido na indústria como "dados persistentes" e até contêineres, nós 39 00:03:13,320 --> 00:03:19,230 ‫realmente não temos um nome para isso. Porque, bem, a maioria das coisas que construímos foi persistente, como 40 00:03:19,230 --> 00:03:24,090 ‫você conhece os servidores antigos que executaram esse antigo aplicativo por cinco ou 10 anos ou mais. 41 00:03:24,270 --> 00:03:26,850 ‫Tudo foi persistente por padrão. 42 00:03:26,850 --> 00:03:32,400 ‫Agora, no novo mundo dos contêineres e a escala automática de aplicativos, dados persistentes criam um 43 00:03:32,400 --> 00:03:33,280 ‫problema único. 44 00:03:33,420 --> 00:03:36,640 ‫O Docker possui duas soluções para esse problema, 45 00:03:36,720 --> 00:03:42,450 ‫conhecidas como "volumes de dados" e "binds mount". "Os volumes do Docker são uma opção de 46 00:03:42,450 --> 00:03:46,620 ‫configuração para um contêiner que cria uma localização especial fora do sistema 47 00:03:46,620 --> 00:03:50,130 ‫de arquivos de união do recipiente para armazenar dados exclusivos. 48 00:03:50,210 --> 00:03:55,470 ‫Isso preserva isso através de remoções de contêineres e nos permite anexá-lo a qualquer recipiente que desejamos. 49 00:03:55,940 --> 00:03:58,210 ‫E o recipiente apenas vê isso como um caminho de arquivo local. 50 00:03:58,440 --> 00:04:05,670 ‫Em seguida, há montagens de ligação, que são simplesmente nós compartilhando ou montando um diretório de host, ou arquivo, em um recipiente. 51 00:04:05,970 --> 00:04:10,470 ‫Mais uma vez, parecerá um caminho de arquivo local, ou um caminho de diretório, para o contêiner. 52 00:04:10,470 --> 00:04:12,590 ‫Na verdade, não saberá que vem do host.