Salve, Deus, beleza? Continua nossa saga aqui no nosso módulo de Docker. Nessa última aula do capítulo, nós vamos falar sobre tipos de montagem e elas vão nos ajudar a ter mais performance na hora de lidar tanto com a leitura quanto na escrita de volumes. Tem o modo padrão, quando a gente está usando os volumes, nós usamos esse padrão o tempo todo, que é um consistente, mas nós temos outros modos que vão nos ajudar dependendo, às vezes, o seu container é que precisa estar com os dados mais atualizados, seu host não, vice-versa, enfim. Então, você pode precisar de montar os seus volumes de outras maneiras. Eu criei mais um material para poder falar sobre esses tipos de montagem. Nós temos, na verdade, três tipos de montagens. O consistente, que é esse que a gente está falando, na verdade, nós estamos usando desde quando a gente começou a usar volume. Então, imagina essa consistência como se fosse a consistência do banco de dados. Quando você habilita lá o modo transação do banco e manda uma paulada só de insert, update e delete, ele não garante essa consistência que, ao final, isso vai estar persistido lá no storage. Pois é. Então, esse tipo de montagem vai garantir que os dados estejam consistentes entre host e container. Ou seja, em algum dos dois pontos, nós vamos ter alguém mudando as informações. Então, na hora que alguém está fazendo uma mudança, ele já garante imediatamente que isso está acessível em ambos os lados. Obviamente, esse tipo de montagem é lento porque é o trade-off. Se eu quero garantir consistência, então a gente perde performance, o Teorema CAP, que a gente já falou aqui no MBA. Mas, por exemplo, imagina que você tem uma situação que quando uma mudança é feita no container, o Docker não sincroniza imediatamente com o host. Onde que a gente poderia aplicar esse delegated, que seria o caso propício? Eu tenho um volume que está, aquele volume que a gente monta ali dentro do projeto para poder guardar o banco de dados. Quem que vai acabar escrevendo sempre? Esse é o container. Quase impossível a gente no host mexer em algum arquivo do banco de dados. Então, nesse caso, ele é muito mais útil para quando o container realiza muito de escrita nos dados. Então, a gente pode aplicar... Inclusive, como funciona isso? Vamos pegar aqui um caso de um Docker Compose. Eu coloquei ali como funciona isso vamos pegar aqui um caso de um docker compose eu coloquei ele como que funciona então aqui ó a gente poderia colocar delegated e aí que entra outra questão porque a gente tá falando aqui para conhecer os fundamentos do docker mas você tá com aplicação muito simples não precisa anoiado em colocar delegated aqui, tá muita calma pode ser que vale a pena pode ser que não, porque a gente acaba nem percebendo às vezes a questão de performance entre consistência e o delegated porque você tem uma aplicação muito simples. Então, isso tem que ficar muito claro. Essa questão aqui dessas configurações de volume, elas vão ajudar em várias situações de desenvolvimento, mas principalmente ali no pra valer, se eu estiver usando isso aqui em produção, tem uma ferramenta aí da Docker que é o Swarm, que a gente não vai mostrar o funcionamento dela, porque depois a gente vai partir para o Kubernetes, que já é uma ferramenta muito mais abrangente, que permite a gente orquestrar esses containers de uma forma muito mais complexa. Mas a gente vai ver o uso do Cached daqui a pouco, mas se você quiser colocar Delegated ali, beleza. É um negócio que muita gente não sabe a existência disso aqui. O Cached vai aumentar a performance de leitura. Então, vou imaginar que eu estou com o meu projeto aqui na minha máquina, no host, e, na verdade, o que o container vai acabar fazendo, ele vai precisar só ler. Então, isso aqui aumenta a performance também, porque se eu colocar, no caso, vamos supor, não tem uma aplicação aqui, mas se eu colocasse cached, por esse caso que eu estou editando os arquivos aqui, então o container fica... Só lendo, ele entende que ele tem que sincronizar mais do host para o container. O container pode continuar fazendo as edições dele, mas o fluxo é o contrário do delegated. Então, nós temos esses três modos. Se você não passar nada, é o consistente, como eu já falei. Nós temos também o outro modo, que é apenas o de leitura. Quando a gente habilita também por padrão os nossos volumes, é como se a gente tivesse aqui o Read-Write, que você vai acabar lendo e escrevendo. Mas se eu colocar Read-Only, então o container não vai conseguir fazer a edição. Ele só vai conseguir ler. E, obviamente, isso aqui tem muito mais performance, porque eu não vou ter esse sincronismo envolvido. Então, em muitas situações, se você tem volume somente de leitura, o intuito é somente de leitura, você pode colocar o RO ali. O RW também está disponível, mas ele é muito mais raro porque sempre a gente está querendo trabalhar com eles. Então, existem várias configurações para poder adequar aos contextos do que é necessário, quem que escreve mais, quem que lê mais, e aí os nossos volumes ficam com mais performance. Então, acho que ficou clara essa ideia que não é para ficar com neura, mas você vendo de um projeto que cabe isso, por exemplo, eu estou rodando vários testes com o meu banco de dados, se eu colocar um delegated vai acabar acelerando um pouquinho mais. Se você está desenvolvendo algo bem simples, aí não precisa colocar o delegated lá. Deixa o modo consistente mesmo. Show de bola, pessoal. Então, finalizamos aqui os volumes. Agora, vamos para networks. Então, é isso aí. E até a próxima.