Uma vez que a gente já tem aquele primeiro exemplo ali com o Docker Compose, eu queria ponderar sobre a comunicação entre os dois containers. Eu deixei justamente nessa aula para que a gente possa analisar mais com calma. Então, vamos lá. Olhando o arquivo index.js, lembrando que eu não quero que isso aqui seja um curso de JavaScript, não importa qual a linguagem de programação. Usuário e senha, a gente sabe que é root. O database eu coloquei MySQL, porque o banco lá que sobe padrão aí no MySQL, mas aqui o host é DB. O que a gente está acostumado a colocar aqui? Se eu estiver lá em produção, vai ser um domínio personalizado e localmente é um local host. Então, isso aqui é a primeira Se eu estiver lá em produção, vai ser um domínio personalizado. E localmente, é um local host. Então, isso aqui é a primeira situação que a gente acaba errando. Eu já errei bastante até, de fato, entender com o Docker quando eu estava começando. E isso aqui é muito importante, porque a gente tem que entender que o container do MySQL é uma máquina, é como se fosse uma máquina. O container do Node é outra máquina. Quando você está na sua máquina, o localhost é o endereço que equivale ao 127.0.0.1, que é o IP local da sua máquina. Então, se eu coloco o localhost aqui, ele diz respeito somente ao Node, ele não vai conseguir conversar com mais que eles, são duas aplicações, são dois containers diferentes. Então, a gente precisa de um modo para poder fazer a comunicação entre eles. A gente conseguiria fazer isso, um detalhe que eu vou sempre falar, a gente conseguiria fazer isso tudo lá, rodando com o Docker Run? Sim, mas com o Docker Compose já organiza tudo. O Docker Compose acaba criando uma rede entre esses dois containers, algo que a gente teria que fazer manualmente com o Docker Run, criar uma rede separada, apontar a rede e tudo mais. Então, isso já facilita bastante a nossa vida. Cada container vai ter um IP associado. A gente vai aprender isso no capítulo de networks. Mas esse IP, a gente tem que sempre lembrar que container é efêmero, container é destruído, é criado, destruído, é criado. Uma certeza que a gente tem com container é que ele não tem vida longa, é que ele vai morrer em um determinado momento. Então, usar o IP aqui do container, a gente nem sabe qual IP que seria gerado. Tem como colocar IP fixo? Tem. Mas é melhor usar nomes. A gente não usa o DNS para poder facilitar o acesso às coisas. Então, nós temos um sistema desse aqui também construído pelo Docker para poder facilitar a comunicação entre os containers. Então, construído pelo Docker para poder facilitar a comunicação entre os containers. Então, o nome do service equivale ao nome do container nessa rede. Então, por isso que aqui está DB, porque está DB aqui. Se eu colocasse XPTO aqui, seria XPTO aqui no lugar. Isso é muito importante. Isso aqui você acaba errando. A questão é que você vai executar e vai acontecer o erro. É importante você lembrar dos fundamentos. Esses fundamentos são essenciais. E até mesmo depois, para você poder... A gente vai ter a parte de Kubernetes. Esses princípios vão se aplicar lá também ao Kubernetes de uma forma geral. Então, se eu tiver aqui 10 containers sendo levantados, precisarem se comunicar, use sempre o nome desses caras. Mas a gente vai refrisar isso lá no módulo de network. Então, pessoal, vamos evoluir nossa saga. É isso aí e até a próxima.