2.8 - Health Checks

Componentes de software ficam indisponíveis por varias razões, como por exemplo falha de comunicação, erro de configuração, problemas com dependências externas como banco de dados ou broker de mensagens. O Openshift possui dois recursos bastante poderosos para fazer o health checks de aplicações. O primeiro que iremos abordar é o Liveness e em seguida o Readiness.

Liveness

O liveness verifica se o container ainda está em execução (de forma sadia). Se a verificação falhar, este container é morto e fica sujeito à política de restart que por padrão é "always".

Ou seja, por padrão sempre que ocorrer alguma falha, o container é reiniciado.

O liveness pode ser verificado de 3 possíveis formas:

  • Executando um handshake de portas TCP

  • Executando alguns dos - HTTP (GET, POST, PUT, DELETE, etc) em um contexto da aplicação

  • Executando um comando ou script dentro do container

Readiness

O readiness define quando que o container está pronto para receber requisições. Caso a verificação do readiness falhe nenhuma requisição será direcionado para este container até que a verificação seja satisfeita. Os mesmos 3 tipos de testes mencionados no liveness também se aplicam para o readiness.

  • Executando um handshake de portas

  • Executando alguns dos verbos HTTP (GET, POST, PUT, DELETE, etc) em um contexto da aplicação

  • Executando um comando ou script dentro do container

Preparando a aplicação

Para testarmos o liveness e o readiness vamos criar dois novos contextos na nossa aplicação. Segue o conteúdo dos dois arquivos abaixo:

liveness.php

<?php
$filename = '/tmp/liveness';

if (file_exists($filename)) {
    header("HTTP/1.1 500 Internal Server Error");
} else {
    echo "Ok";
}
?>

readiness.php

<?php
$filename = '/tmp/readiness';

if (file_exists($filename)) {
    header("HTTP/1.1 500 Internal Server Error");
} else {
    echo "Ok";
}
?>

Você pode criar os dois arquivos pela console do github conforme já fizemos em outros labs.

O resultado final do repositório deve estar conforme imagem abaixo:

Os códigos dos dois probes verificam se existe um arquivo no /tmp dentro do container. No caso do liveness.php, ele verifica se existe um arquivo chamado /tmp/liveness. Caso exista, ele retorna status 500. O mesmo procedimento é executado também no readiness.php com a diferença que ele busca o arquivo /tmp/readiness.

Também podemos atualizar nosso repositório pela linha de comando do git.

git add .
git commit -m "health check adicionado"
git push

Atualizando nosso container

Rebuild da nossa aplicação

O Openshift não tem como saber que nosso código foi alterado no repositório github pois não configuramos os webhooks. Isso será feito na próxima lição. Enquanto isso, vamos criar um novo build da nossa aplicação de maneira manual.

  1. Selecione no menu vertical esquerdo a opção Builds -> Builds

  2. Clique no workshop-ocp na tabela apresentada

  3. No menu superior direito, clique em Start Build

Assim que o build terminar, podemos verificar se aplicação está na sua nova versão. Para isso, basta abrir o contexto /liveness.php e /readiness.php

Caso esteja tudo certo, você verá um Ok na tela.

Configuração no Openshift

Usando a Web Console

Precisamos agora informar o Openshift para monitorar esses dois contextos novos da aplicação. Precisamos abrir o deployment da aplicação:

Clique em Actions e Edit Health Checks

E logo em seguida, edite o health check clicando em add liveness e add readiness

Abaixo segue a configuração do readiness

E o liveness

Usando a linha de comando

Também podemos configurar o livenesse readiness por meio da linha de comando.

Só execute os comandos abaixo de criação de liveness e readiness caso você não tenha feito os passos de criação desses monitoramento pela web console conforme passos anteriores

Antes, veja qual o nome do deploymentconfig usando o comando:

oc get dc

Para saber o nome do seu projeto no Openshift, basta executar:

oc get projects

Substitua ele no comando abaixo para o readiness:

oc set probe dc/workshop-ocp \
 --readiness \
 --get-url=http://:8080/readiness.php

Para saber o nome do seu projeto no Openshift, basta executar:

oc get projects

Para o liveness:

oc set probe dc/workshop-ocp \
 --initial-delay-seconds=20 \
 --liveness \
 --get-url=http://:8080/liveness.php

Para saber o nome do seu projeto no Openshift, basta executar:

oc get projects

Perceba que adicionamos um delay inicial para o health check do liveness. Fizemos isso para evitar que o Openshift fique matando o container enquanto o mesmo estiver "subindo".

O Openshift informa para nós por meio da console web que a aplicação não está pronta para receber requisição por meio da cor azul clara. Se o circulo ficar azul claro, quer dizer que o seu POD não passou no teste de readiness.

Caso o círculo do container apareça laranja, isso quer dizer que o teste de readiness ficou mais de 5 minutos sem passar no teste.

O container ficar azul claro rapidamente e logo em seguida volta a ficar azul escuro. Isso quer dizer que por um breve período de tempo, ele não passou no readiness probe.

Testando o readiness da nossa aplicação

Para testarmos o readiness, vamos executar um comando que cria um arquivo na pasta tmp.

# Veja o nome do seu pod
oc get po

# Crie o arquivo dentro do pod
oc exec <nome-do-pod> touch /tmp/readiness

Na console, agora o container ficará azul claro assim que o Openshift perceber que o readiness probe falhou.

Debug do container

O Openshift permite que você faça um debug do seu container caso ele não passe no teste de readiness. Para testar essa funcionalidade, basta clicar dentro do círculo azul do container que está com problema e logo em seguida clicar em Debug in Terminal.

É importante que você tenha somente uma instância da aplicação rodando para quando clicar dentro do círculo ele vá para a página certa. Para garantir isso, execute o seguinte comando:

oc scale dc/workshop-ocp --replicas=1

Essa opção Debug in Terminal é condicional. Ela só aparece na Web Console quando o seu container está com problema.

Testando o liveness da nossa aplicação

O mesmo passo executado no passo anterior pode ser feito para o liveness.

# Veja o nome do seu pod
oc get po

# Crie o arquivo dentro do pod
oc exec <nome-do-pod> touch /tmp/liveness

Assim que o Openshift perceber que o container parou de responder no contexto do /liveness.php, ele vai matar e criar outro container (que não terá esse arquivo /tmp/liveness já que ele não existe na imagem).

Você pode ver que o container foi reiniciado por meio dos eventos do projeto. Para isso faça:

oc get events

Mais informações

Previous2.7 - Binary DeploymentNext2.9 - Integração Contínua (Webhook)

Last updated