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 exemploNã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árioNã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 noCloudwatch
que inicia umatask
do Fargate com base no cronograma definido:
O motivo para eu sugerir você considerar evitar isso, é porque nessa abordagem faltam algumas coisas importantes como:
Definir um tempo limite para o agendamento
Definir uma repetição se houver alguma falha no agendamento
Apenas inicia, mas não atualiza o número de tasks para cima ou para baixo
Também não interrompe as tasks, dessa forma não atualiza o tamanho desejado para 0
Em resumo, essa forma está operando no modo "disparar e esquecer", ou seja o Cloudwatch envia a requisição para iniciar e acaba nisso, sem garantias, sem controles e sem resiliência
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 0O
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 tomarO
EventBridge
é mais avançado, permite chamar o nível da API ECS Fargate passando uma carga personalizada comJSON
, que ajuda a personalizar a chamada API conforme necessário
Tutorial
1- Acesse o console AWS → IAM → Policies → crie uma política conforme abaixo:
Name:
Defina um nome de sua preferência
Por exemplo:
ecs-fargate-scheduler-qa-policy
Description:
Defina uma descrição de sua preferência
Por exemplo:
Policy that grants EventBridge permission to automatically start and stop Fargate tasks in the QA environment
{
"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:
Name:
Defina um nome de sua preferência
Por exemplo:
ecs-fargate-scheduler-qa-role
Description:
Defina uma descrição de sua preferência
Por exemplo:
Role with necessary EventBridge permissions to automatically start and stop Fargate tasks in the QA environment
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, 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:
<Service-ARN>
e <Cluster-ARN>
para seus valores reais{
"DesiredCount": 1,
"Service": "<Service-ARN>",
"Cluster": "<Cluster-ARN>"
}
11- Deixo a opção Schedule
habilitada
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.
- Se houver uma falha ou uma entrega mal sucedida no
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
- Se houver um erro não recuperável, como
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ãocron
que inicia o Fargate enviando uma chamadaAPI
para oUpdateService
doECS
Definindo o
DesiredCount
como1
task por exemplo.E também repetimos isso para parar o Fargate, mas agora definindo o
DesiredCount
para0
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: