Período de carência? - Serviço de contêiner do AWS EC2 e balanceadores de carga elásticos

Question

Quando um balanceador de carga elástico (ELB) está associado a um grupo de escalonamento automático, é possível especificar um período de tolerância durante o qual novas instâncias do EC2 não serão encerradas, mesmo se marcadas como não íntegras pelo ELB. É possível especificar um período de tolerância semelhante, durante o qual as novas tarefas do ECS não serão eliminadas e reiniciadas pelo serviço do ECS associado, mesmo que a instância do ECS em que uma tarefa está sendo executada tenha sido marcada como não íntegra pelo ELB?

Atualização:

Em nosso caso de uso atual, o contêiner docker que está sendo executado como uma tarefa do ECS contém uma instância do JBoss que carrega vários caches na inicialização. Esses caches podem levar vários minutos para serem carregados. No entanto, o serviço do ECS registra a instância do contêiner com o ELB, assim que o contêiner é iniciado. Isso significa que o tráfego pode ser roteado para o novo contêiner antes de estar pronto para aceitá-lo. Poderíamos aumentar o intervalo de verificação de integridade e os "limites saudáveis / não íntegros" no ELB para evitar que o ELB direcione o tráfego para a instância e o serviço ECS reinicie o contêiner até que os caches sejam carregados. No entanto, aumentar o intervalo e os limites da verificação de integridade não são desejáveis, porque se uma instância for marcada como não íntegra após o carregamento dos caches, o serviço do ECS deverá reiniciar o contêiner assim que possível (o que exige um intervalo de verificação de saúde mais curto e limites menores) ).

Assim, é possível aplicar um período de tolerância durante o qual o tráfego não será roteado para um novo contêiner pelo ELB e o serviço do ECS não reiniciará o contêiner (mesmo se falhar nas verificações de integridade)? Ou, na falta disso, há alguma sugestão referente a uma solução para nosso caso de uso?

    

Answer 1

Após uma discussão com a equipe de suporte, verifica-se que o ECS não suporta nosso caso de uso atual.

Existe uma solução alternativa que resolve um dos problemas que enfrentamos. Essa solução alternativa é criar um contêiner de verificação de integridade essencial e separado e na mesma tarefa do ECS que o contêiner de aplicativo real. A finalidade do contêiner de verificação de integridade é monitorar o contêiner do aplicativo para determinar quando o aplicativo foi iniciado completamente. Se detectar que o aplicativo falhou ao iniciar, ele sai, fazendo com que o serviço do ECS faça o ciclo da tarefa. O ELB é configurado para executar suas verificações de integridade no contêiner de verificação de integridade, que sempre informará que está ativo por meio da porta relevante. Essa solução alternativa impedirá que o serviço do ECS efetue o ciclo da tarefa do ECS devido a falhas nas verificações de integridade.

No entanto, o ELB começará a rotear o tráfego para o contêiner do aplicativo imediatamente. Ele fará isso, mesmo que o contêiner do aplicativo ainda não esteja pronto para receber tráfego (por exemplo, porque ainda está aguardando o carregamento de um cache). Atualmente, não há como atrasar o envio de tráfego do ELB para o contêiner do aplicativo, pois o serviço do ECS não oferece suporte a um período de carência. Conseguimos solucionar esse problema enviando mensagens para nossos contêineres de aplicativos por meio do SQS e apenas fazendo com que eles saiam da fila quando seus caches estão totalmente carregados. No entanto, temos casos de uso futuros (como a exibição de solicitações da Web) quando essa não for uma opção viável. Para este fim, pretendo levantar uma solicitação de recurso para o período de carência.

Como um aparte, tanto o Kubernetes ( link ) e Marathon ( link ) já suportam esta opção para verificação de saúde, se alguém ler isto for feliz por não usar um serviço gerenciado.