Introdução
Você pode ter diversos motivos e casos de uso diferentes para querer iniciar e parar de forma agendada e automática o AWS Fargate, no meu caso específico eu precisava de um Fargate para um ambiente de QA que não tinha a necessidade de estar funcionando o tempo todo, então precisava de alguma solução que me permitisse iniciar e parar o Fargate em horários agendados e de forma automática.
Isso me levou a analisar algumas opções, considerar alguns desafios e então este artigo irá descrever um pouco sobre tudo isso e demonstrar como consegui atingir esse objetivo.
Algumas Opções
Evite usar Cron dentro de um Container
Parece ser uma escolha fácil e óbvia, assim como faria em uma instância Linux através de uma conexão SSH a configuração de um crontab -e, a primeira opção que nos vem na mente é:
"E se eu acessar meu container e criar um cron nele também, da mesma forma que eu faria em uma instância Linux?"
Alguns motivos para você responder não a esta pergunta são:
Não é o padrão, seu container deve estar preocupado somente com o processo principal da sua aplicação, ele não deve se preocupar com processos adicionais como o cron por exemplo
Não é "limpo", nosso objetivo é iniciar e parar o Fargate, então a cada vez que isso acontecer, seguindo o princípio da infraestrutura imutável, um novo container será criado e não o mesmo, então se você não automatizar a criação do cron, não haverá nenhum sentido no que estamos tentando fazer aqui, além disso essa automatização pode ser um obstáculo desnecessário
Não é colaborativo e intuitivo, se você estiver em um projeto pequeno, ainda sim deverá lembrar dessa configuração, mas e se você estiver em um projeto maior e com uma equipe maior, certamente outros devs não lembrarão ou perceberão de forma fácil e intuitiva que existe um cron dentro do container
Evite usar ECS Scheduled Tasks
Essa seria a segunda opção óbvia a ser usada, pois podemos encontrar essa opção no console AWS:
Porém, se possível evite usar essa opção ou pelo menos considere isso antes em seu caso de uso:
- Ao criar um
ECS Schedule Tasks, no background a AWS estará criando de uma forma simplificada uma regra de evento no Cloudwatch que inicia uma task do Fargate com base no cronograma definido:
Porém entendo que para alguns casos isso pode ser o suficiente e funcionar, só quis compartilhar esses pontos que achei relevante.
Prefira usar o EventBridge
Essa seria a terceira opção que me veio a mente, a que acabei utilizando e a que descreverei o passo a passo de como consegui fazer isso, mas antes algumas notas importantes também:
Ao contrário da abordagem anterior, aqui há mais resiliência, pois o EventBridge não irá apenas iniciar uma task, mas ele também terá a capacidade de atualizar o número de tasks para cima, para baixo ou interromper atualizando o tamanho desejado para 0
O EventBridge possui opções mais avançadas e flexíveis que você poderá escolher se houver uma falha, como por exemplo se irá monitorar isso, se tentará novamente, se deseja adicionar em uma fila de processamento ou outra ação que você deseja tomar
O EventBridge é mais avançado, permite chamar o nível da API ECS Fargate passando uma carga personalizada com JSON, que ajuda a personalizar a chamada API conforme necessário
Tutorial
ℹ
Esse tutorial está considerando o START/STOP para um serviço do Fargate, e não para tasks individuais (sem serviço) e também não a nível de cluster para todos os serviços dentro dele, mas sim para um único serviço do Fargate dentro de um Cluster.
1- Acesse o console AWS → IAM → Policies → crie uma política conforme abaixo:
Name:
Description:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecs:ListServicesByNamespace",
"ecs:GetTaskProtection",
"ecs:ListAttributes",
"ecs:DescribeTaskSets",
"ecs:DescribeTaskDefinition",
"ecs:DescribeClusters",
"ecs:ListServices",
"ecs:ListAccountSettings",
"ecs:DescribeCapacityProviders",
"ecs:ListTagsForResource",
"ecs:ListTasks",
"ecs:ListTaskDefinitionFamilies",
"ecs:DescribeServices",
"ecs:ListContainerInstances",
"ecs:DescribeContainerInstances",
"ecs:DescribeTasks",
"ecs:ListTaskDefinitions",
"ecs:ListClusters",
"ecs:UpdateService"
],
"Resource": "*"
}
]
}
2- Agora vá para IAM → Role → crie uma role conforme abaixo:
ℹ
Remova a política anexada automaticamente
ℹ
Adicione a política que criamos nesta role
ℹ
Edite a aba Trust Relashionship para conceder permissão ao EventBridge, conforme abaixo
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
3- Agora vá para o console AWS → EventBridge → Rules → Create rule
4- Defina um nome e descrição de sua preferência, por exemplo:
Name:fargate-start-tasks-qa-monday-to-friday-morning
Description:Rule that automatically starts QA environment ECS Fargate
Altere para a opção Schedule
Clique em Continue in EventBridge Scheduler
5- Altere para Recurring schedule → defina uma expressão cron de sua preferência
ℹ
Por exemplo, eu gostaria de iniciar as tasks no Fargate de segunda a sexta as 9 horas (horário de Brasília)
Por exemplo, para executar de segunda a sexta às 09 horas (UTC -3), isso seria:
00 9 ? * MON-FRI *
00: é o minuto em que o cron será executado. Neste caso, o que significa que a tarefa será executada quando o relógio marcar exatamente 0 minutos.
9: é a hora em que o cron será executado. Neste caso, o que significa que a tarefa será executada às 9 horas. (UTC -3)
?: isso indica que não estamos definindo um dia específico do mês. A tarefa será executada independentemente do dia do mês.
*: isso indica que a tarefa será executada em todos os meses. Não estamos definindo um mês específico.
MON-FRI: especifica os dias da semana em que a tarefa será executada. Neste caso, a tarefa será executada de segunda a sexta-feira.
*: indica que a tarefa será executada em todos os anos. Não estamos definindo um ano específico.
Uma vez compreendido o formato do cron, lembre-se de ajustar seu Time Zone e preencher de acordo com suas necessidades.
6- Defina a opção Flexible Time Window, essa opção é útil quando você quiser que o EventBridge funcione dentro do tempo dessa janela que você definiu, pense nisso em casos que as tasks ou targets ainda não estão prontos, desta forma você define um intervalo de tempo para que isso seja feito.
Por exemplo, se eu definisse o cron as 9 horas e um Flexible Time Window de 15 minutos, na prática significa que o EventBridge Scheduler garantirá que ele seja executado dentro deste período, ou seja entre 9:00 às 9:15, mas isso não significa que ele será executado as 9:15, mas sim que será acionado dentro deste intervalo a qualquer momento a partir do horário agendado (no exemplo as 9:00 + flexible time window).
Isso é muito bom para distribuir as execuções nesta janela de tempo, reduzindo os impactos de várias solicitações ao mesmo tempo em um ambiente grande.
Como neste meu caso isso não é um requisito necessário, defino como Off
7- Você também pode definir uma data de início e término, como eu espero que a expressão cron funcione e não planejo inserir uma data para que esse cron comece a funcionar ou terminar, não preencho e clico em Next
8- Agora altere para All APIs → pesquise por ecs → selecione a opção ECS
9- Agora pesquise por update → selecione a opção UpdateService
10- Como nessa regra estamos querendo iniciar o Fargate, defino o campo DesiredCount como 1 para então ter uma task em execução, você pode ajustar isso para suas necessidades e preferência:
⚠
Lembre-se de alterar <Service-ARN> e <Cluster-ARN> para seus valores reais
{
"DesiredCount": 1,
"Service": "<Service-ARN>",
"Cluster": "<Cluster-ARN>"
}
11- Deixo a opção Schedulehabilitada
12- Não defino nenhuma ação após o agendamento ser executado, pois neste caso de uso não planejo excluir o agendamento
13- Agora você pode definir uma DLQ (Dead Letter Queue), isso seria uma fila SQS para armazenar os eventos que falharam, aqui ainda existem dois tipos:
Recuperáveis
- Se houver uma falha ou uma entrega mal sucedida no
target (que no nosso caso é a API UpdateService do ECS), por padrão o EventBridge tentará fazer ela novamente por 24 horas e até 185 vezes.
Não recuperáveis
- Se houver um erro não recuperável, como
AccessDenied por exemplo, isso não será repetido pelo EventBridge, mas ele poderá adicionar se você quiser isso em uma fila DLQ para ser tratado ou processado posteriormente
ℹ
Mesmo desabilitando a opção Retry Policy, ainda sim o EventBridge tentará repetir para eventos recuperáveis por 24 horas e até 185 vezes. Isso é um comportamento padrão, você configurando ou não.
Para este tutorial, defino isso como Disable, mas se isso for importante para você, este é o momento de configurar de acordo com suas preferências:
14- Não defino nenhuma criptografia
15- Seleciono a Role que criamos no início do tutorial
16- Clico em Create
Pronto! 😄
Porém criamos até agora apenas para iniciar o Fargate, ainda falta uma parte importante que seria parar o Fargate, para isso basta repetir os mesmos passos, porém mudando os nomes, descrições e principalmente o código JSON para o DesireCount igual a 0, isso significa que não desejamos nenhuma task em execução:
{
"DesiredCount": 0,
"Service": "<Service-ARN>",
"Cluster": "<Cluster-ARN>"
}
Para não tornar o tutorial muito grande e ser repetitivo, não vou descrever todo o passo a passo novamente, mas para sua comodidade, aqui estariam a sequência de imagens para parar o Fargate também:
Limitações
O Event Bridge é capaz de fazer um único request por vez, isso significa que você não pode adicionar vários Fargates no mesmo request, e isso pode gerar duplicação de trabalho, pois deverá repetir este passo a passo para cada Fargate que desejar.
O Fargate e o Event Bridge precisam estar na mesma região.
Conclusão
Pronto! 😄
Agora sim temos todo o nosso objetivo completo.
Vimos neste artigo algumas opções para iniciar e parar o Fargate, analisamos e consideramos alguns desafios e limitações entre as opções, elegemos o uso do EventBridge como melhor opção para este caso e fizemos um tutorial passo a passo para iniciar e parar o Fargate que faz:
O EventBridge Scheduler configurado com uma expressão cron que inicia o Fargate enviando uma chamada API para o UpdateService do ECS
Definindo o DesiredCount como 1 task por exemplo.
E também repetimos isso para parar o Fargate, mas agora definindo o DesiredCount para 0 para que não haja tasks em execução.
Por fim, depois que o cron for executado em seu horário definido, poderemos ver no cluster do fargate nenhuma task originada pelo nosso agendamento automático:
E no service também podemos ver o DesiredCount como 0 como definimos:
E depois novamente a task iniciada também pelo nosso agendamento automático em seu horário definido:
ℹ
Lembre-se de excluir todos os recursos ao final para não obter cobranças indesejadas e manter sua conta AWS limpa e organizada.
✅
Espero que essas informações tenham sido úteis para você!
