‫O comando Docker Health Check. Foi um novo recurso adicionado em 1. 12, que surgiu no meio de 2016, ao mesmo
‫tempo em que Swarm Kit e Swarm Mode estavam disponíveis no Docker. Ele foi adicionado realmente como parte desse kit de
‫ferramentas, mas ainda funciona em todos os arquivos diferentes, como o Dockerfile, o arquivo Compose, o comando docker run
‫usa, os arquivos Stack o suportam, a atualização do serviço eo serviço create command support
‫it .
‫Está em toda parte.
‫Eu recomendo que, quando você estiver indo para a produção, você se envolver em opções de teste para este comando de
‫verificação de saúde.
‫Vai funcionar bem fora da caixa com um executivo.
‫Ele vai executar esse comando dentro do contêiner, como se você estivesse executando seu próprio
‫comando exec.
‫Então, não está executando isso de fora do recipiente; É apenas executá-lo para dentro, o que
‫significa que mesmo os trabalhadores simples que não possuem portas expostas, você pode executar um comando simples para validar se
‫eles estão retornando bons dados ou o que for.
‫É uma simples execução de um comando, o que significa que ele recebe um retorno simples. Espera um 0 ou um 1.
‫Em Linux e Windows, você tem códigos de saída de comandos e um 0 é uma coisa boa.
‫Isso significa que tudo estava bem.
‫Qualquer coisa que não seja um 0 será um erro na maioria dos aplicativos.
‫Mas no Docker, precisamos desse aplicativo para sair especificamente de um 1. Vamos mostrar em um minuto como
‫você faz isso.
‫Há apenas três estados para um healthcheck no Docker. Começa com o início. O início é o primeiro
‫30 segundos, por padrão, onde ainda não executou um comando healthcheck.
‫Então vai correr um.
‫Se isso retornar um 0, ele começará com o saudável. Isso mudará para a opção saudável.
‫Isso levará esse comando e ele será executado a cada 30 segundos por padrão novamente. Se alguma vez receber um retorno insalubre, como
‫uma saída 1, isso o marca como um recipiente insalubre.
‫Temos opções para controlar tudo isso, incluindo tentativas.
‫Vamos ver isso em um minuto.
‫Esta é uma opção muito melhor do que tivemos no passado porque o Docker, até agora, estava apenas se certificando de
‫que o aplicativo ainda estava em execução.
‫Não tinha nenhuma visão sobre se essa aplicação estava fazendo o que era suposto.
‫Agora podemos fazer isso dentro do próprio recipiente Docker.
‫Mas isso não é um substituto para sua solução de monitoramento de terceiros.
‫Isso não lhe dará gráficos ou status ao longo do tempo, ou qualquer tipo de ferramenta de terceiros que você esperaria
‫de uma solução de monitoramento.
‫Trata-se de entender Docker se o próprio recipiente tiver um nível básico de saudável.
‫Então, em um Nginx, ele pode retornar um localhost do arquivo de índice de raiz. Um retorno de 200 ou 300 está bem e dá-lhe um
‫código de saída de 0, e considera-o saudável.
‫Isso não é um super avançado uh, você sabe, ferramenta de monitoramento.
‫devolvesse um erro de 404 ou 500, consideraria isso insalubre e podemos fazer algo a respeito disso.
‫Mas se isso
‫Onde vamos ver este Docker healthcheck na GUI?
‫O primeiro lugar está em container ls.
‫Verá como esta nova opção.
‫Está no meio. Veremos em um segundo, onde nos mostrará um dos três estados, se a verificação de
‫integridade estiver sendo executada, e é assim que realmente sabemos que há uma verificação de saúde.
‫Essa é a maneira mais fácil, pelo menos, de saber. Veremos a história, os últimos cinco desse
‫healthcheck, aparecem no inspeção para esse recipiente. E podemos ver algumas tendências básicas ao longo do tempo lá.
‫Mas o comando de encaminhamento do docker não leva ação em um recipiente insalubre.
‫Uma vez que o healthcheck considera um recipiente insalubre, o docker run apenas indicará que no comando
‫ls e no inspeção, mas não vai agir.
‫É aí que esperamos que Swarm Services tome medidas.
‫Assim, as pilhas e os serviços irão realmente substituir esse contêiner por uma nova tarefa, em um novo host
‫possivelmente, dependendo do planejador.
‫de atualização, vemos um pouco de bônus extra ao usar o healthchecks porque as atualizações considerarão o
‫healthcheck como parte da prontidão para esse recipiente antes que ele vá e mude o próximo.
‫Mesmo no comando
‫Se um recipiente aparecer, mas não passa seu exame de saúde, a atualização do serviço
‫não vai para o próximo. Ou vai agir de acordo com as mudanças que você deu.
‫Vejamos alguns exemplos antes de irmos à linha de comando.
‫Este é o que estamos usando no docker run.
‫Isso nos permite usar uma imagem existente que não tenha uma verificação de integridade, e estamos adicionando a
‫verificação de integridade no tempo de execução.
‫Nesse caso, estamos usando a imagem Elasticsearch. contêiner, não a porta publicada, mas dentro do contêiner.
‫Você pode ver o comando é um cURL localhost 9200, que é a porta que o Elasticsearch
‫está executando dentro do Para Elasticsearch, existe
‫uma URL de saúde real.
‫Então, podemos usar isso aqui.
‫Você notará os dois tubos com o falso no final desse comando.
‫E isso vai ser bastante
‫comum se usar algo como cURL ou outra ferramenta que enviará um código de erro que seja diferente de 1.
‫Lembre-se quando eu mencionei isso há algum tempo? Precisamos sair com 1 se houver um problema. o Docker vai fazer.
‫Porque esse é o código de erro que
‫Precisamos ter certeza de que, neste caso, um shell sempre retornará o falso 1 código de saída se
‫houver algo que saia desse comando diferente de 0.
‫É uma ótima maneira de resolver esse problema.
‫Isso acontece com CURL, a CURL dará outros códigos de erro potenciais e não queremos que
‫isso aconteça.
‫Nos arquivos reais do Docker, podemos adicionar o mesmo comando. O formato é um pouco diferente. Mas você vê
‫que nós temos essas opções aqui. Temos o intervalo, o tempo limite, o período de início (que é novo) e as tentativas.
‫O intervalo é o que você pensa que é. É, por padrão, a cada 30 segundos.
‫Com que frequência ele vai executar esta verificação de saúde. O tempo limite é quanto tempo vai esperar antes de
‫erros e retorna um código ruim, se talvez o aplicativo seja lento. O período de início é um novo recurso o intervalo de tempo antes de iniciar
‫que nos permite agora em 17. 09 e mais recente, para dar um período de espera mais longo do que os primeiros 30 segundos da duração. Antes, sempre aguardaria Mas talvez você tenha um aplicativo Java ou banco de dados, ou algo que demore muito mais para começar.
‫o tempo. a verificação de saúde. Talvez demore cinco minutos.
‫Você poderia adicionar esse período de início lá. Ainda vai fazer saídas de saúde. Mas o que isso fará é que não será alarmado em um cheque insalubre até
‫que esse tempo tenha decorrido.
‫vez que ultrapassou essa marca de dois minutos.
‫Então, se você definir dois minutos lá, mesmo que seja um exame de saúde a cada 30 segundos, isso só o considerará insalubre, uma O último, tentativas, significa que vamos tentar esta verificação de
‫saúde x um número de vezes antes de considerar isso insalubre.
‫Isso dá talvez a um aplicativo potencialmente instável a chance
‫de voltar com um saudável e recuperar por conta própria antes de considerarmos isso um recipiente realmente insalubre.
‫O comando basic healthcheck que você usaria em um Dockerfile é
‫chamado HEALTHCHECK, todas as letras maiúsculas lá. O mesmo formato existe onde se estamos apenas fazendo um simples CURL
‫do localhost porque talvez seja um aplicativo PHP ou algo assim. Nós podemos fazer isso.
‫para que você veja como eu adiciono o intervalo de tempo limite e as tentativas antes do próprio comando.
‫É assim que você adicionaria todas essas opções a um Dockerfile
‫O primeiro há para o comando básico, observe que não tenho que
‫colocar um CMD se eu apenas estou dando o comando para executar. Mas se eu quiser mostrar opções, se eu quiser dar-lhe opções personalizadas fora da
‫caixa com o tempo limite e assim por diante, então preciso especificar qual é o comando.
‫Agora, estas não são duas linhas diferentes.
‫Observe a barra traseira no final da primeira linha lá.
‫Então não confunda isso.
‫poderia ser, se você tivesse um aplicativo estático executado dentro de um servidor Nginx.
‫Aqui temos um exemplo simples do que
‫Você poderia definir o intervalo e o tempo limite de seu Dockerfile, e você simplesmente teria que simplesmente fazer
‫um comando cURL no localhost.
‫Se retornar um 200 ou 300, ele considera isso bem. Se retornar um 4, ou 5, ou qualquer outra coisa,
‫ele considera que um erro.
‫Você percebe aqui que eu tenho uma saída 1, o que é o mesmo que um falso.
‫Eu fiz isso apenas para mostrar que certos exemplos na Internet terão um falso. Certos
‫exemplos terão uma saída 1.
‫Ambos fazem o mesmo.
‫Aqui está um exemplo um pouco mais avançado.
‫Nesse caso, estamos usando um aplicativo PHP combinado com o Nginx.
‫O que eu fiz é que, nos recursos, você encontrará um link para este exemplo do PHP. Eu adicionei um arquivo de configuração
‫Nginx personalizado que usa URLs de status Nginx e PHP-FPM.
‫Ambos os aplicativos têm sua própria página de status e tipo de URL de ping do healthcheck.
‫Você pode usar aqueles em seus aplicativos se estiver usando PHP ou Nginx. Existem dois URLs diferentes, mas você
‫pode usar ambos dentro do mesmo healthcheck.
‫Neste caso, estamos usando apenas um deles e
‫estamos jogando o localhost / ping, que é
‫realmente um comando de status PHP-FPM, mas você deve habilitar isso dentro do seu PHP-FPM. Mais uma vez, nos recursos desta palestra, existe um link para um padrão Docker
‫do PHP Padrões.
‫Você pode verificar isso em um GitHub, onde eu mostrei neste exemplo um pouco mais de detalhes.
‫Em seguida, temos um exemplo do Postgres, então, no Dockerfile, eu posso usar um URL diferente.
‫Aqui temos um aplicativo Postgres onde no comando healthcheck, estou usando um comando de pg já.
‫Agora, com diferentes aplicativos, existem ferramentas diferentes. teste muito simples de uma conexão com um servidor Postgres.
‫Com o Postgres, ele vem com uma ferramenta embutida, que é um
‫Não valida que você tenha bons dados, ou que seu banco de dados esteja montado corretamente. Simplesmente vai dizer: 'Este servidor
‫de banco de dados permite conexões? Sim ou não? "Isso é um bom que você pode
‫fazer fora da caixa.
‫Veja como seria um arquivo de compositor / pilha.
‫Muito parecido.
‫Você notará que o período de início lá requer uma versão diferente.
‫Como o comando healthcheck saiu em 1. 12, foi realmente suportado em 2. composição.
‫1 deste arquivo de
‫Mas, se você usar o período de início, isso significa que você precisa atualizar seu arquivo de
‫composição para a versão 3. 4 para suportar isso. Porque o
‫período de início saiu mais de um ano depois, depois que o comando healthcheck fez.
‫Vamos começar com alguns comandos de execução simples.
‫O que faremos aqui é que vamos começar um servidor de banco de dados
‫do Postgres sem o healthcheck porque, por padrão, ele não vem com um.
‫comando manual healthcheck que irá adicionar na linha de comando e veremos a diferença.
‫Então, vamos executá-lo novamente com um
‫Aqui, vamos chamar o primeiro p1. Vamos executá-lo separado da
‫imagem oficial do Postgres.
‫Se eu fizer um container docker, verá que não há nada que indique um healthcheck aqui.
‫Se fizermos o mesmo comando novamente, e chamá-lo p2 desta vez, vamos adicionar um comando de saúde.
‫Desta vez, vamos usar o pgready, sobre o
‫qual conversamos anteriormente, para testar que as conexões estão disponíveis neste servidor Postgres. Nós vamos dizer que o usuário que precisamos é
‫o usuário do postgres. Na verdade, não precisamos dar uma senha. tentar fazer login.
‫Não vai Apenas tentará validar. Usaremos a imagem Postgres.
‫Agora, se fizermos um container docker, e eu diminuir um pouco,
‫você verá que ele diz: 'Up 4 segundos de saúde está começando. "Agora, obtemos
‫esse recurso adicional em nosso status de nosso comando ls. Ele permanecerá no estado inicial por 30 segundos padrão até que ele execute
‫o
‫comando healthcheck pela primeira vez.
‫Agora que esperamos mais de 30 segundos, você verá que mudou para status de saudável.
‫tivemos essa nova opção de status de saúde.
‫Se fizermos um recipiente de ancoradouro inspecionar esse p2, veremos no topo de tudo isso que Neste caso, eu só consegui executá-lo duas vezes.
‫Você pode ver a saída lá, que está mostrando que está aceitando conexões.
‫Tudo bem. Vamos fazer algum serviço criar comandos para o mesmo banco de dados, na mesma avaliação de teste.
‫O que veremos aqui quando fazemos isso é que existem três estados diferentes
‫que um serviço passa ao iniciar.
‫Está se preparando, o que geralmente significa que está baixando a imagem. Está começando, o que significa que ele está executando o recipiente
‫e trazê-lo. Então está correndo.
‫Sem o comando healthcheck, o início e a execução são muito rápidos. Eles são quase instantâneos.
‫Vamos ver isso aqui com um serviço docker criar nome p1 postgres.
‫Depois de concluir a preparação, baixando a
‫imagem, você verá que vai imediatamente começar a ser executado, porque não há verificação de saúde. Não tem mais nada além de
‫iniciar o contêiner e dizer: 'Sim. O binário está em execução. "Mas, se fizermos o mesmo comando, o serviço docker crie e chame-o p2
‫como antes, e dê esse mesmo comando
‫de saúde.
‫Iniciamos este serviço com o comando healthcheck incorporado.
‫primeiro salão de segurança executar.
‫O que veremos é que ele vai de preparar para iniciar, e ele se sentará no estado inicial para os 30 segundos padrão até o
‫Este é agora o serviço Docker esperando um estado saudável antes
‫de considerar este serviço totalmente em execução. Após completar os 30 segundos, ele mudará para o estado em execução. Então, conseguimos verificar o último pouco,
‫apenas para garantir que ele seja considerado estável, e depois terminamos.
‫Você já pode ver, fora da caixa, que com serviços, bem
‫como atualizações de serviço, obteremos esse bônus extra de conceito de saúde se usarmos esses comandos sempre que pudermos.
‫