Salve, Deus, beleza? Continuando a nossa saga aqui no nosso módulo de Docker, nós vamos trabalhar nessa aula administrando os containers, então nós vamos ver vários comandos para poder ver logo, apesar que a gente já viu na última aula, como que a gente não bloqueia terminal, listando os containers e fazendo várias coisas. Administração mesmo no dia a dia, quais as opções e comandos que são importantes para que a gente possa gerenciar esses containers. Então, bora aqui para o VS Code. Deixa eu deixar tudo bonitinho aqui. Vamos começar pelo que a gente já... Muitas coisas que tem no comando docker convencional vão ter aqui com docker compose. A gente tem aqui os nossos containers executando. Vamos parar com o ctrl-c. E aí tem uma pessoa que gosta bastante de não bloquear o terminal, é o Wesley. Eu já gosto de bloquear. Aí vai de gosto. Se eu rodar um docker up, ele vai bloquear o terminal. Vou ter que abrir outro terminal para poder fazer outras coisas. Então, tem o detach com o "-d", também. Então, olha só. Os meus containers foram iniciados. O nosso terminal não está bloqueado mas eu não gosto do "-d", às vezes eu até rodo mas normalmente eu não gosto dele porque aí você tem que testar você não tem garantia que está tudo funcionando você tem que no mínimo fazer um docker com pose logs para poder ter o resultado e às vezes em muita coisa a gente não sabe se está tudo ok. Claro que a gente consegue fazer um PS e ver o status dos containers também. Mas a gente tem então esse "-b", que você pode executar. Já aproveitando sobre a questão dos logs, se eu executar com o PosedockerLogs, todos os comandos que a gente for executar aqui, muitos deles permitem que você passa o nome do serviço e ele só vai incidir naquele serve sim então se eu fizer logs ele mostra tudo seu passar aqui em de nex ele mostra somente os logs do indian ex também é interessante para a gente poder ir capturando os logs. Inclusive também, a gente tem aqui uma outra opção para o logs. Às vezes eu tenho muito log sendo mostrado. Ah, eu só quero ver os últimos 10 aí do Nginx. Então, ele mostra só as últimas 10 linhas. Então, nós temos a opção tail também. O comando tail do Linux é para poder ler arquivos. Inclusive, a gente até consegue deixar o logs ali pegando as últimas 10 linhas sempre. Mas, beleza. Agora, sobre essa listagem aqui dos containers, a gente já sabe lá atrás que o PS e o container ls lista, mas eu prefiro muito mais o docker-compose-ls. Ou... o PS, na verdade. O PS, na verdade. Porque ele vai sempre pegar o seu Docker Compose que você tem ali e mostra somente o que está rodando ali. Vamos supor que você tenha outros Dockers Compose que estão rodando, outros containers que estão rodando avulso, o Docker PS é muito ruim porque ele acaba mostrando tudo. Às vezes você quer ver tudo, mas ver somente o que é local é interessante. Então, ele só pega o que está local. Ele mostra o nome do container e etc. Se a gente quiser verificar os containers que não estão rodando, porque aqui o PS é a mesma história do Docker PS, você passa a opção menos A. Então, se tivesse algum container que não estivesse de pé, ele também acabaria mostrando. Sobre a questão de stop de container, a gente já viu que o Ctrl C quando faz o up sem o menos D, ele acaba dando o comando sinal ali de parar, mas e agora no caso do menos D? Como a gente está com o Docker Compose, dava dando comando sinal ali de parar, mas e agora no caso do "-d"? Como a gente está com o docker-compose, faz o stop. Ele vai começar a parar os três containers. Se você fizer um docker-stop também, mais o nome do container, a gente não tinha aqui o nome do container, eu consigo também fazer o stop. Vamos fazer um docker-compose up-d docker-compose ps, então eu tenho aqui o nome do container. Se eu quiser fazer uma parada avulsa, a gente consegue fazer aqui vai quebrar tudo lá, porque tem nginx com dependendo do node, ele acabou parando aqui o container, então os comandos convencionais acabam funcionando, mas você consegue também parar apenas um container passando o nome do service, que se torna mais simples. Então, se eu quisesse fazer o mesmo comando ali acima, como ele já está parado aqui, é muito rápido, mas eu posso passar somente aqui o db, o nginx, ou o app também, para poder fazer essa parada dos containers. Vamos voltar para cá. Eu vou fazer um docker-compose-stop. Deixa ele parar tudo. E vamos fazer aqui um docker-compose-up. A gente vê justamente essa questão dos nomes dos containers. Isso aqui é algo muito importante de a gente entender. Aqui para cá. Ele cria os nomes dos containers, eu já falei disso aqui no curso, que ele vai pegar o nome da sua pasta, claro, se tiver ali carácter especial, ele vai fazer uma transformação, mas é o nome da pasta que você está atualmente, traço o nome do service, mais um número incremental, que eu não tenho aqui réplicas desses containers. Se tivesse réplicas, ele iria ficar colocando aqui um, dois, três números de réplicas que você teria desse container. Então, isso aqui é o padrão dele para poder diferenciar. Agora, um cuidado que você tem que tomar é que vamos supor que você esteja em uma outra pasta, em um outro lugar, e você tenha a pasta com esse mesmo nome e você tenha containers, que até o Dockerfile é diferente, seja a aplicação Java aqui, que ele vai acabar compilando, mas você tem o mesmo nome de pasta e o mesmo nome de container. Quando você rodar aqui o up, ele vai levantar o node em vez do Java que você tinha. Justamente porque ele sempre olha esse padrão ali, olha, ele vê, peraí, nome de pasta, nome do service. Ah, já tem? Então ele pega e levanta. Então tome cuidado quando você criar nomes de passos iguais, o que acaba acontecendo. É bom que você rode o comando down. O comando down, ele faz, ele é a junção de um docker stop mais um docker rm, ou seja, ele vai parar os containers todos e vai removê-los. Eu posso também só fazer isso para um container específico se eu passar o nome do service. Se eu passar somente app aqui, ele só para e destrói o app. Mas se eu fizer aqui, ele vai destruir tudo. Está vendo? Ele está removendo. Inclusive, tem a rede que é criada para poder fazer a comunicação entre eles também. Ela é criada quando a gente faz o up e é destruída também. Então o DAO é um comando importante. Se eu quiser fazer... Às vezes eu estou com todos os containers parados, não destruí eles. Eu também tenho um RM e eu posso passar aqui um index, um app para poder fazer a remoção à bolsa. Mas o DAO, normalmente, ele acaba sendo uma salvação que você está... Ah, eu não quero nem fazer stop, eu destruo esse negócio tudo e pronto. Você tem que tomar cuidado aqui, se você não tiver um dados persistente, igual no banco de dados, aqui depois a gente vai aprender a trabalhar com volumes, você perderia o que você tem aí no seu banco de dados. Mas isso aí já é uma história mais para frente. A gente já viu aqui a questão de nome dos containers, agora vamos falar sobre a questão do build. Um detalhe importante é você saber quando você tem que refazer o build das suas imagens novamente. Se você está mexendo aqui em informações, como no deploy, a porta que você vai expor, a tag image aqui, você apenas faz aí o down, se você quiser, tem necessidade, faz o stop e faz o up novamente. É mais que o suficiente. Você não precisa fazer o build. Agora, olha só o que eu vou fazer aqui. eu vou fazer o build agora. Olha só o que eu vou fazer aqui. Se eu chegar e passar aqui um arquivo para executar com um Node que não existe, que meu container nem iria ser executado, se eu fizer o up ele vai executar o Node normalmente, porque ele vai pegar a última versão da imagem. A gente consegue ver... Na verdade eu estou com esse terminal que está liberado. A gente consegue ver que o problema é esse nome. Deixa eu colocar um 03 aqui atrás. Pera aí, qual que é o nome? Estou colocando errado aqui também. 03. 03. Estou colocando errado aqui também. 03. O problema é que ele vai pesquisar, mas está aqui no meio, essas imagens que foram... Esses conteúdos acabam gerando imagens específicas para eles também. Vou ter uma imagem para esse, uma imagem para esse. E nesse caso aqui do MySQL não, porque a gente está puxando a imagem mas acaba gerando container sempre quando você tem um build é que ele tem a imagem, então ele acaba executando aqui, conectado com um monte de dados se eu quiser fazer um novo build pra poder testar, então tem que rodar parei aqui no outro para também. Então vamos fazer aqui. Docker Compose Up menos menos build. Aí está vendo que ele vai executar novamente. Aí ele vai crashar. Deixa ele... Os outros dois como já não teve mudança está vendo que eles subiram primeiro? Mas o app aqui está sendo recriado. Aqui já deu zica, porque ele vai falar ali que o index não existe, aquele index com monte de um lá não existe, beleza. Então eu vejo, às vezes, muita gente fazendo, ah, chega aqui e expõe uma nova porta. Aí a pessoa vai e faz o comando up com menos build. Tem problema? Não. Não tem problema você fazer isso. A polícia não vai chegar na sua casa pra poder te prender. Não é um crime. Mas quando você tá fazendo isso aqui, é desnecessário, porque como você não fez mudança no Dockerfile, o build faz ele reprocessar a imagem novamente, que acaba demorando mais para poder subir. Você não quer ser mais eficiente na hora de rodar sempre os seus containers, consumir menos tempo, então só use o build e aí que você demonstra o conhecimento seu com o Docker. Use o build somente em situações que você está modificando, você precisa gerar uma nova imagem. Eu espero que isso tenha ficado bem claro aí para vocês. Então, a gente já falou aqui também os comandos. O up, eu consigo subir somente um container se eu precisar. Aqui não faria muito sentido, porque eles estão todos dependentes um do outro, mas às vezes você tem um docker compose que um container aqui não é dependente de ninguém e você só quer subir ele para poder brincar de alguma forma. Então, você faz um up mais o nome do service. Então, esses comandos como o up, o stop, o down, o rm, o logs, você consegue, o down, o rm, o logs, você consegue passar somente o nome do service para poder fazer ali a sua execução. A última opção que nós vamos ver aqui é como a gente executa comandos dentro do container, porque quando a gente sobe aqui com o up, vamos subir aqui, melhor, tem que recompilar, aqui eu tenho que recompilar porque eu fiz a mudança no dockerfile de novo. Ah, outro detalhe, quando a gente tem um up rodando, deixa eu até fazer aqui, se eu fizer um ctrl-c ele para, se eu fizer um ctrl-c de novo, aí ele faz o kill, Então, se você fizer dois, aqui não deu tempo porque ele já estava parando. Mas no momento que ele demora um pouquinho para parar, se você fizer dois Ctrl C, você fez o primeiro, fez o segundo, ele faz a parada e já remove também. Ele remata o container. Então, vamos rodar aqui com o "-build", como eu fiz lá a alteração no meu Dockerfile. E aí, se eu quiser executar, poderia estar com o "-d", aqui, para não bloquear o terminal, mas se eu quisesse executar comandos lá dentro do meu Node, então eu faço docker-compose exec app, o nome do service, mais o bash ou o sh, se não tiver bash, usa o charscript. Consegui entrar. entrar então muito mais simples que aquele exec-it você tem que lembrar lá o id do container o nome pra poder fazer o bashing, então isso aqui é muito mais direto eu consigo entrar também no nginx, se eu quiser, sh consigo entrar também no mysql com beta do, exceto o nginx todos os dois tem o Bash ali. Vou logar no MySQL. Pronto. É assim que a gente vai administrando. Os nossos containers. Sempre com aquela situação. Que vai limpando as suas coisas de tempo em tempo. Então pessoal. Vamos evoluir a nossa saga. É isso aí. E até a próxima.