Salve Deus, beleza? Continuando a nossa saga aqui no nosso módulo de Docker, ao decorrer que a gente foi fazendo aquele exemplo ali do Docker Compose, nós vimos algumas questões em relação à dependência de comunicação entre os containers, porque todos os containers ali, o do Node, o Nginx e o Banco de Dados, eles se comunicam e têm uma dependência um do outro. Então, o Node depende do MySQL e o Nginx depende do Node. Então, se a gente acaba não organizando a ordem de execução desses containers, saber também se o container está apto para que o outro se comunique com ele, a gente acaba criando esse ambiente de múltiplos containers que ele vai acabar sendo transportado lá para a sua hospedagem, para a produção, depois para um Kubernetes. Se a gente não sabe lidar com a verificação da saúde do container, se ele está devidamente sendo executado corretamente, a gente não vai saber quando acontecer ali uma falha e identificar isso, saber consertar isso e tudo mais. Então, organizar isso é muito importante. Vamos aqui para o nosso Docker Compose. Nós temos uma instrução que ajuda que os containers vão subir baseado em uma ordem de dependência. Então, vamos colocar que no app, ele depende do DB. Então, nós temos a instrução depends on, eu coloco aqui depends, que é um array, eu posso depender de vários containers, depende do DB. O Nginx depende do app, porque ele vai rodar ali, depende do app, porque ele vai rodar ali. Inclusive não adianta nada ele rodar sem que o Node.js esteja rodando. Então olha só o que vai acontecer agora quando a gente subir esses containers. Vamos rodar aqui o docker-compose-up e a gente vai ver a ordem que esses containers vão acabar subindo. O problema é que tem trocentos logs aqui. Eu rodei... acabou rodando com o build. mas olhando nesse cenário aqui... Deixa eu parar isso aqui de novo. Vamos fazer um docker-compose-down, deixar tudo limpinho aqui e só de praxe vou fazer somente o up. só de praxe, vou fazer somente o up. E eu consigo vir aqui para cima. Então, ele vai criar os containers, mas quem ele poderia levantar primeiro? Na verdade, o que não depende de ninguém, que é o banco de dados. Depois ele precisa rodar o Node e depois o Nginx. Então ele muda a ordem de execução baseada na dependência. Ele faz essa análise conforme o depends on. Então significa o seguinte, eu tenho que tomar cuidado com isso. Se eu chegar aqui e fazer um stop no DB, se eu fazer um stop no DB, eu ainda vou ter o Node de pé mas só porque a gente colocou aquela instrução do restart que ele vai ficar agora reiniciando e vai ficar sempre crashando mas quando eu tenho alguém que é dependente se eu me matar, eu mato o dependente junto também. Acho que ficou claro essa ideia. Mas esse depends on, ele ajuda nesse sentido, tanto para você poder subir na ordem, otimizar e também parar os containers, mas a gente tem que entender que dependência entre os containers é diferente de o container está apto para receber comunicação, receber conexões. Olha só, o meu Node depende do DB, mas esse depende, ele não vai analisá-lo, ele não sabe se uma SQL está pronta na porta 3306. Então, essa regra de dependência apenas analisa, ah, o container do DB iniciou, né? Ah, então, posso iniciar o Node. Agora, se eles vão conseguir se comunicar, é outra história. Então, o depends on, ele acaba organizando um ponto, mas ainda assim, ele acaba sendo insuficiente para poder satisfazer essa necessidade de dependência aqui. Então, para que a gente possa melhorar isso, nós vamos trabalhar com o Health Check, que vai ficar vendo a saúde aqui, verificando se esse container está ok. Então, eu vou passar aqui a instrução Health Check. Na verdade, senso tudo aqui. A primeira coisa vai ser o comando que a gente vai testar. Quero ver se o container está de pé ou não. Na verdade, não é o container que está de pé. Eu quero ver se o banco de dados está apto para receber conexão. Aí você tem que saber qual comando que seria simples para ferramenta, para o banco de dados ou qualquer coisa, para ver se ela consegue aceitar as conexões. Então, para o caso do MySQL, a gente vai usar aqui o comando MySQL Admin, que é um executável, e nós vamos fazer um ping no localhost. Isso aqui é executado dentro do container. Esse teste vai analisar aqueles resultados de saída de terminal. Então, se esse comando aqui não executado com sucesso, a gente vai ter um erro, então esse teste falha. Então, se ele der sucesso, esse health check, ele grava um status ali que está ok. Aí daqui para baixo, a gente vai incluir algumas informações, porque vamos pensar assim que logo quando o container iniciar, ele já vai executar isso aqui, mas sem necessidade dele executar, não, poderia esperar um pouquinho, mas ele pode também executar e o banco de dados não está pronto e a gente tem que executar várias vezes no intervalo. Então as opções aqui abaixo vão nos ajudar a controlar isso aqui. A gente vai fazer assim. Eu vou colocar aqui o intervalo que vai ser de, por exemplo, 1 minuto e 30 segundos. O intervalo vai especificar o tempo de verificação de integridade. Ele aguarda esse tempo para poder fazer outra verificação. Então, dentro desse 1 minuto e 30 que a gente vai tentar. Agora, eu posso também colocar um timeout que vai especificar o quanto a gente vai aguardar para esse comando aqui responder. Vamos colocar 10 segundos, né? Tá bom. Dentro desse intervalo. Eu quero tentar três vezes. três vezes. Até esse retries aqui, ele vai definir o número de retentativas até que a gente declare que o estado desse container não esteja ok. A gente tem que dar umas chances aqui para esse comando executar até ele dar certo. E aí eu posso colocar aqui um período de início. Vamos colocar que eu tenho 10 segundos ou talvez 20 segundos, 15, para poder começar a executar esse teste. Então, durante esse intervalo de 1 minuto e 30, eu vou ter um timeout para poder ver se esse comando está ok, ele vai demorar 10 segundos para poder iniciar quando o container for startado, iniciar, e ele vai tentar 10 vezes. Eu posso passar esses tempos aqui baseado no que eu espero ali, o que vai sendo útil para poder testar essa integridade. Aí, que é o legal aqui agora desse depends on aqui, porque eu posso chegar aqui e falar assim, ó, eu dependo do DB e a condição dele tem que ser healthy, tá? Tem que ser healthy. Por padrão, como a gente coloca daquela forma ali, é um service started, que é só para ver se o container iniciou. Com essa condição, nós vamos analisar o health check do outro container. Então, agora vamos ver a diferença disso. A gente vai ver que o container do Node, que fica lá reiniciando toda hora, ele não vai precisar mais disso. O DB iniciou o Node ainda não. Aí vai demorar uns segundinhos, o comando lá vai executar, vai mudar o status dele para o health check para OK. Aí a gente vai ver que o Node vai iniciar. Vamos aguardar essa execução. Acho que coloquei tempos grandes demais. Talvez. Demorando bastante. Coloquei também um minuto e meio. Vou aguardar aqui um tempinho e eu volto. Olha só, deu tudo certo aqui. Agora não tem mais. Eu posso deixar aquele re-start que estava aqui, por acaso aconteceu um problema. Inclusive, posso colocar isso para os outros conforme a necessidade, mas agora isso que é o legal, porque o Nginx, como ele depende do app e o app depende do DB, então o Node estava esperando o Node estava esperando o DB iniciar, então também o Nginx não iniciava, porque o Nginx depende do Node. Então, olha que interessante. Então, a gente pode colocar health check nos containers, poderia colocar um health check também aqui no app, poderia colocar aqui, no caso, um teste com um CUR para a porta 3000. Vou deixar isso como dever de casa para vocês. Mas eu só quero recapitular isso que está acontecendo aqui. Sobre a questão do intervalo, não significa que depois desse 1 minuto e 30, ele não vai fazer o health check, ele é contínuo. Então, a cada 1 minuto e 30, ele vai fazer esse teste. Mas a questão é que quando deu aqui o teste a primeira vez, com sucesso, aí o próximo, ele vai, depois de 1 minuto e 30, ele vai fazer de novo. E se caso esse teste falhar, o banco de dados crashou alguma coisa, então o nosso container vai ficar prejudicado aqui também e aí ele vai ficar fora. Então isso é importante também. O timeout é justamente o tempo para poder fazer essa verificação, então às vezes o comando que pode ser executado não é um comando rápido, a gente pode colocar aqui um tempo até maior para poder esperar, aí o período de início é aquilo que eu já falei, o container iniciou ali agora, posso esperar um pouquinho para começar a fazer o meu teste, e o número de três retentativas até eu definir que esse container não está de pé. Existem outras estratégias que às vezes são usadas para desenvolvimento, que é usar um script chamado de wait for, se você quiser dar uma olhadinha aí também. o H4, se você quiser dar uma olhadinha aí também. Existe também um Dockerize, mas são soluções que até eu utilizava antes, não utilizo mais. Eu utilizo o Health Check que a gente fica às vezes noiado assim, ah, isso aqui fica executando indefinidamente, poderia até colocar um tempo menor, mas tem um monte de coisas executando na sua máquina que você nem sabe, essas instruções, elas não vão ter consequências, isso só faz parte do jogo, tem um monte de coisas executando atrás desses containers que a gente nem tem ideia e nem tem que ficar preocupando com isso também mas essa opção aqui de help check, ela serve tanto pra desenvolvimento quanto para produção. Ela ajuda você a organizar e evitar uma série de problemas. Imagina o Node ficar executando várias vezes para poder iniciar. A gente até poderia reduzir, inclusive, esses tempos aqui. O período de start poderia, sei lá, colocar uns 5 segundos e o timeout aqui uns 5 segundos também, já o tempo de intervalo talvez uns 30 segundos, nem problema, esse comando aqui é muito simples, não vai ser ele o problema que vai ficar usando recursos da sua máquina. Então a gente fecha aqui o Docker Compose, agora a gente vai ver ali networks e volumes, é isso aí e até a próxima.