Você pode ter diversos motivos diferentes para querer reiniciar automaticamente um droplet no Digital Ocean, se você estiver procurando por alguma opção no console, observará algo parecido com essa imagem:

Há apenas duas opções disponíveis:

• Turn off

• Power Cycle

Mas infelizmente nenhuma que nos ajude a reiniciar nosso droplet.

Podemos também por exemplo acessar o droplet através de SSH e executar o comando:

sudo shutdown -r now

Então se você está procurando uma forma de reiniciar automaticamente seu Droplet no Digital Ocean, compartilho neste artigo o passo a passo de como consegui fazer isso.

Resposta Curta

1- Acesse seu Droplet através do SSH com seu aplicativo de terminal de sua preferência

2- Copie e cole o comando:

# Create reboot script file
cat <<'EOF' | sudo tee -a ~/reboot-script.sh > /dev/null
#!/bin/bash

# Add timestamp to the log file before shutdown
echo "Reboot initiated at $(date)" >> ~/reboot-log.txt

# Shutdown the machine
sudo shutdown -r now
EOF

# Set reboot script file executable
chmod +x ~/reboot-script.sh && \

(crontab -l 2>/dev/null; \
echo "0 7 * * * ~/reboot-script.sh"; \
echo "0 19 * * * ~/reboot-script.sh") | crontab - && \

# Create log file
touch ~/reboot-log.txt && \

# Set logrotate to log file
cat <<'EOF' | sudo tee -a /etc/logrotate.conf > /dev/null
~/reboot-log.txt {
    daily
    rotate 15
    compress
    delaycompress
    missingok
    notifempty
}
EOF

3- Edite o cron para os horários de sua preferência alterando esse trecho:

(crontab -l 2>/dev/null; \
echo "0 7 * * * ~/reboot-script.sh"; \
echo "0 19 * * * ~/reboot-script.sh") | crontab - && \

4- Pressione Enter para executar

• Se você não editou o cron, ele irá reiniciar todos os dias as 07 e 19 horas UTC

• Se você editou o cron, ele irá reiniciar de acordo com sua preferência

Caso você queira entender um pouco mais sobre os detalhes do que foi feito, acompanhe nosso tutorial detalhado abaixo, senão achar necessário, você está pronto!

Tutorial

1- Utilize seu terminal preferido e acesse seu Droplet através do SSH

2- Crie um arquivo chamado reboot-script.sh com o comando:

touch reboot-script.sh

3- Agora edite esse arquivo com o comando:

sudo nano reboot-script.sh

E adicione o seguinte conteúdo:

#!/bin/bash

# Add timestamp to the log file before shutdown
echo "Reboot initiated at $(date)" >> ~/reboot-log.txt

# Shutdown the machine
sudo shutdown -r now

4- Torne o arquivo executável com o comando:

chmod +x reboot-script.sh

5- Edite o crontab

Por exemplo, para executar todos os dias às 07 horas UTC, isso seria:

0 7 * * *

• 0: é 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.

• 7: é a hora em que o cron será executado. Neste caso, o que significa que a tarefa será executada às 7 horas.

• *: o asterisco é um caractere curinga que representa "todos". Quando usado nos campos de dias do mês e dias da semana, significa "todos os dias do mês" e "todos os dias da semana", respectivamente.

Uma vez compreendido o formato do cron, e lembrando que você deve usar o horário em UTC, você pode ajustar para sua necessidade.

Depois disso, execute o comando:

crontab -e

E adicione o seguinte conteúdo na última linha:

0 7 * * * ~/reboot-script.sh

6- Crie o arquivo chamado reboot-log.txt com o comando:

touch reboot-log.txt

7- Esse arquivo de log pode se tornar grande com o passar do tempo, então vamos automatizar a limpeza do tamanho dele também para que não ocupe muito espaço no disco com o comando:

sudo nano /etc/logrotate.conf

E ao final do arquivo, adicione o conteúdo:

~/reboot-log.txt {
    daily
    rotate 15
    compress
    delaycompress
    missingok
    notifempty
}

Conclusão

Vimos que não há opções disponíveis diretamente no console do Digital Ocean para reiniciar um Droplet até o momento que este artigo foi criado, também vimos que é possível reiniciar esse droplet através do SSH de forma manual, mas passamos por uma resposta curta com copiar e colar um único comando para atingir esse objetivo, até um tutorial mais detalhado para que você possa fazer o passo a passo que automatiza esse processo seguindo essa ordem de etapas:

1. Crie um arquivo de script chamado reboot-script.sh, ele será responsável por adicionar linhas no log e reiniciar o droplet

2. Torne esse arquivo executável

3. Crie um arquivo chamado reboot-log.txt, ele será responsável por armazenar os logs de reinicialização

4. Configure um log rotate para este arquivo reboot-log.txt, ele será responsável por limpar e manter o arquivo de log otimizado

5. Configure um cron para executar o reboot-script.sh, ele será responsável por "chamar" nosso reboot-script.sh no horário adequado, desta forma adicionando uma linha no log e reiniciando o droplet

Você pode visualizar o log com o comando:

cat reboot-log.txt

Se você estiver buscando outras opções, talvez essas leituras e tutoriais sejam de seu interesse:

• 👉 Aprenda a Reiniciar sua Instância Lightsail com Agendamento Automático

• 👉 Aprenda a Reiniciar sua instância EC2 com Agendamento Automático

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:

• 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 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

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

{
    "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:

{
     "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

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:

1. O EventBridge Scheduler configurado com uma expressão cron que inicia o Fargate enviando uma chamada API para o UpdateService do ECS

2. Definindo o DesiredCount como 1 task por exemplo.

3. 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:

Você pode ter vários motivos e razões diferentes para querer agendar um start e stop automático para o RDS. No meu caso eu estava criando um ambiente de QA onde não precisava que o RDS ficasse ligado o tempo todo para manter os custos reduzidos, felizmente a AWS disponibilizou uma opção no console para parar temporariamente durante 7 dias seu RDS, isso pode ser encontrado em:

• Console AWS → RDS → DB Instance → Action → Stop

Embora isso já ajude para muitos casos, não se encaixava muito bem ao que eu precisava, pois eu não gostaria de ficar repetindo essa tarefa e esses cliques, então era hora de pensar em uma solução e automatizar esse processo, compartilho neste artigo como consegui atingir esse objetivo.

Tutorial

1- Acesse o console AWS → IAM → Policies → crie uma política conforme abaixo:

Name:

• Defina um nome de sua preferência

• Por exemplo:

  • rds-scheduler-qa-policy

Description:

• Defina uma descrição de sua preferência

• Por exemplo:

  • Policy that grants EventBridge permission to automatically start and stop RDS in the QA environment

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBProxyTargetGroups",
                "rds:StartDBCluster",
                "rds:DescribeDBInstanceAutomatedBackups",
                "rds:DescribeDBRecommendations",
                "rds:DescribeGlobalClusters",
                "rds:DescribeEngineDefaultParameters",
                "rds:DescribeRecommendations",
                "rds:DescribeDBClusterAutomatedBackups",
                "rds:DescribeDBProxyTargets",
                "rds:DownloadDBLogFilePortion",
                "rds:DescribeSourceRegions",
                "rds:StopDBCluster",
                "rds:DescribeDBSnapshots",
                "rds:DescribeDBSecurityGroups",
                "rds:StartDBInstance",
                "rds:DescribeReservedDBInstances",
                "rds:DescribeBlueGreenDeployments",
                "rds:DescribeValidDBInstanceModifications",
                "rds:DescribeDbSnapshotTenantDatabases",
                "rds:DescribeIntegrations",
                "rds:DescribeOrderableDBInstanceOptions",
                "rds:DescribeCertificates",
                "rds:DescribeOptionGroups",
                "rds:DescribeDBShardGroups",
                "rds:DescribeDBEngineVersions",
                "rds:DescribeDBSubnetGroups",
                "rds:DescribeExportTasks",
                "rds:DescribeTenantDatabases",
                "rds:DescribePendingMaintenanceActions",
                "rds:DescribeDBParameterGroups",
                "rds:DescribeDBClusterBacktracks",
                "rds:DescribeReservedDBInstancesOfferings",
                "rds:DescribeRecommendationGroups",
                "rds:DescribeDBInstances",
                "rds:DescribeEngineDefaultClusterParameters",
                "rds:DescribeDBProxies",
                "rds:DescribeDBParameters",
                "rds:DescribeEventCategories",
                "rds:DescribeDBProxyEndpoints",
                "rds:DescribeEvents",
                "rds:DescribeDBClusterSnapshotAttributes",
                "rds:DescribeDBClusterParameters",
                "rds:DescribeEventSubscriptions",
                "rds:DescribeDBLogFiles",
                "rds:StopDBInstance",
                "rds:DescribeDBSnapshotAttributes",
                "rds:ListTagsForResource",
                "rds:DescribeDBClusterSnapshots",
                "rds:DescribeOptionGroupOptions",
                "rds:DownloadCompleteDBLogFile",
                "rds:DescribeDBClusterEndpoints",
                "rds:DescribeAccountAttributes",
                "rds:DescribeDBClusters",
                "rds:DescribeDBClusterParameterGroups"
            ],
            "Resource": "*"
        }
    ]
}

2- Agora vá para IAM → Role → crie uma role conforme abaixo:

• Name:

  • Defina um nome de sua preferência

  • Por exemplo:

    • rds-scheduler-qa-role

• Description:

  • Defina uma descrição de sua preferência

  • Por exemplo:

    • Role with necessary EventBridge permissions to automatically start and stop RDS in the QA environment

{
    "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:rds-name-start-qa-monday-to-friday-morning

• Description:Rule that automatically starts QA environment RDS

• 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 rds → selecione a opção RDS

9- Agora pesquise por start → selecione a opção StartDBInstance

10- Como nessa regra estamos querendo iniciar o RDS, defino o campo DbInstanceIdentifier com o nome da minha instância RDS

{
  "DbInstanceIdentifier": "<RDS-NAME>"
}

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 StartDBInstance do RDS), 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 RDS, ainda falta uma parte importante que seria parar o RDS, para isso basta repetir os mesmos passos, porém mudando o request da API para StopDBInstance

E novamente passar o nome correto do seu RDS substituindo <RDS-NAME>

{
  "DbInstanceIdentifier": "<RDS-NAME>"
}

Limitações

• O Event Bridge é capaz de fazer um único request por vez, isso significa que você não pode adicionar várias instâncias RDS no mesmo request, e isso pode gerar duplicação de trabalho, pois deverá repetir este passo a passo para cada instância do RDS que desejar.

• O RDS e o Event Bridge precisam estar na mesma região.

Conclusão

Pronto! 😄

Agora sim temos todo o nosso objetivo completo.

Vimos neste artigo um tutorial passo a passo para iniciar e parar o RDS que faz:

1. O EventBridge Scheduler configurado com uma expressão cron que inicia o RDS enviando uma chamada API para o StartDBInstance do RDS

2. O EventBridge Scheduler configurado com uma expressão cron que para o RDS enviando uma chamada API para o StopDBInstance do RDS

Por fim, depois que o cron for executado em seu horário definido, poderemos ver no RDS a instância pausada ou iniciada:

Você pode ter vários motivos e razões diferentes para querer agendar um start e stop automático para suas instâncias EC2. No meu caso eu estava criando um ambiente de QA onde não precisava que o EC2 ficasse ligado o tempo todo para manter os custos reduzidos, então compartilho como consegui atingir esse objetivo.

Tutorial

1- Acesse o console AWS → IAM → Policies → crie uma política conforme abaixo:

Name:

• Defina um nome de sua preferência

• Por exemplo:

  • ec2-scheduler-qa-policy

Description:

• Defina uma descrição de sua preferência

• Por exemplo:

  • Policy that grants EventBridge permission to automatically start and stop EC2 in the QA environment

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        }
    ]
}

2- Agora vá para IAM → Role → crie uma role conforme abaixo:

• Name:

  • Defina um nome de sua preferência

  • Por exemplo:

    • ec2-scheduler-qa-role

• Description:

  • Defina uma descrição de sua preferência

  • Por exemplo:

    • Role with necessary EventBridge permissions to automatically start and stop EC2 in the QA environment

{
    "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:ec2-start-qa-monday-to-friday-morning

• Description:Rule that automatically starts QA environment EC2

• 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 ec2 → selecione a opção EC2

9- Agora pesquise por start → selecione a opção StarInstances

10- Como nessa regra estamos querendo iniciar as instâncias EC2, defino o campo InstancesIds com o ID das minhas instâncias EC2

{
  "InstanceIds": [
    "<Instance-ID-1>",
    "<Instance-ID-2>"
  ]
}

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 StartInstances do EC2), 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 as instâncias EC2, ainda falta uma parte importante que seria parar as instâncias EC2, para isso basta repetir os mesmos passos, porém mudando o request da API para StopInstances

E novamente passar os IDs corretos das instâncias EC2 substituindo <Instance-ID>

{
  "InstanceIds": [
    "<Instance-ID-1>",
    "<Instance-ID-2>"
  ]
}

Limitações

• As instâncias EC2 e o Event Bridge precisam estar na mesma região.

Conclusão

Pronto! 😄

Agora sim temos todo o nosso objetivo completo.

Vimos neste artigo um tutorial passo a passo para iniciar e parar as instâncias EC2 que faz:

1. O EventBridge Scheduler configurado com uma expressão cron que inicia as instâncias EC2 enviando uma chamada API para o StartInstances do EC2

2. O EventBridge Scheduler configurado com uma expressão cron que para as instâncias EC2 enviando uma chamada API para o StopInstances do EC2

Por fim, depois que o cron for executado em seu horário definido, poderemos ver no EC2 a instância pausada ou iniciada:

Você pode ter diversas razões e motivos para querer configurar uma instância NAT na AWS, para meu caso de uso estava precisando criar um novo ambiente de QA, este ambiente consistia em ter uma função Lambda que fosse capaz de ter uma conexão com a internet e também com recursos da VPC.

Felizmente uma função Lambda pode ser configurada dentro de uma VPC e então conceder acesso aos recursos dela, mas infelizmente ao fazer isso, essa mesma função que agora pode se comunicar com RDS, Elasticache e outros recursos da VPC, perde a conexão com a internet, isso ocorre porque a AWS irá atribuir um ENI com endereço IP privado na função lambda quando adicionada na VPC, desta forma impedindo sua conexão com a internet.

Há uma solução sugerida pela AWS para este caso, que consiste em adicionar um NAT Gateway, isso é robusto, escalável e com certeza um caminho a seguir para um ambiente de produção. O problema que me encontrei aqui é que o NAT Gateway é um serviço caro, gerenciado pela AWS e que funciona o tempo todo, então parecia um grande exagero para um ambiente de QA que funciona em alguns horários pré-definidos.

Como citei, esse era o meu cenário, mas novamente você pode querer ter um NAT por qualquer outro motivo, por exemplo para fornecer conexões a internet de qualquer recurso criado em uma sub-rede privada, como instâncias, RDS, etc.

Como alternativa, optei por não usar o serviço gerenciado NAT Gateway, mas sim criei e configurei minha própria instância NAT, compartilharei com você uma breve descrição do que significa o NAT e passaremos por um tutorial de como atingi esse objetivo.

O que é NAT?

NAT significa Network Address Translation, é uma técnica utilizada em redes de computadores para traduzir endereços IP de um formato para outro. Seu principal objetivo é permitir que vários dispositivos em uma rede compartilhem um único endereço IP externo, isso é especialmente útil em redes domésticas e empresariais, onde há escassez de endereços IP públicos disponíveis.

Por exemplo, quando você contrata um plano de internet para sua casa, sua operadora não entregará para você um endereço IP público para cada um de seus dispositivos, como laptops, computadores, TVs, impressoras, celulares, etc. Mas sim entregará um IP público dinâmico e todos os seus equipamentos conectados em seu roteador poderão usar o mesmo IP público dinâmico fornecido através do NAT, pense nisso conforme diagrama abaixo:

Onde cada endereço IP 192.168.0.X de seus equipamentos conectados é entregue através do DHCP configurado em seu roteador, e todos obtém um único endereço IP público, esse funcionamento se dá através do NAT configurado em seu roteador.

No contexto da AWS, o NAT desempenha um papel parecido e é fundamental na comunicação entre instâncias em redes privadas e recursos externos, como a internet. Ao criar instâncias em uma sub-rede privada, ela não terá um endereço IP público, mas sim um endereço privado da sua VPC, o que as impede de se comunicar diretamente com a internet. Então é neste momento que o NAT trabalha, pois atua por meio de tradução de endereços IP, conforme diagrama abaixo:

Cada recurso criado na sub-rede privada, possui uma rota para um NAT que está em uma sub-rede pública com acesso à internet, permitindo então assim que os recursos privados consigam acesso a internet.

Concluído essa introdução, espero que você esteja um pouco mais familiarizado com esse conceito, partiremos agora para o tutorial prático.

Tutorial

Antigamente, a AWS fornecia uma AMI pronta para instâncias NAT, porém seu suporte foi descontinuado em dezembro de 2023, conforme anúncio oficial:

Como alternativa, a AWS sugere criar sua própria instância NAT baseado no Amazon Linux mais recente, porém eu não gostaria de usar essa imagem e sim me basear no Ubuntu, bom e foi isso que eu fiz, abaixo estão os passos:

Pré-Requisitos

Este artigo é extenso, passaremos por muitos passos, para evitar que fique ainda maior, não cobriremos a configuração de uma VPC do zero, também não discutiremos em detalhes sobre a VPC ou rede, se você já possui uma VPC com sub-redes públicas e privadas, pode pular algumas etapas e passos que descrevo abaixo, senão for o caso, passaremos pelas principais configurações necessárias.

Criando Grupo de Segurança

1- Acesse o console AWS → VPC → Security Group → Create Security Group e defina de acordo com suas preferências:

• Name: por exemplo nat-instance-sg

• Description: por exemplo Security group with permissions required for NAT Instance

• Inbound: suas regras de entrada, por exemplo HTTP, HTTPS e SSH

👉 Como melhorar a administração e organização dos Grupos de Segurança da AWS com o VPC Prefix List

• Outbound: suas regras de saída, você precisará adicionar HTTP e HTTPS para 0.0.0.0/0 para ter conexão com a internet

• Tags: se preferir, adicione tags

Criando Nat Instance

1- Acesse o console AWS → EC2 → Instance → Launch Instance → preencha as informações:

• Name: defina um nome de sua preferência, por exemplo NAT Instance

• AMI: escolha Ubuntu

• Architecture: escolha 64-bit (x86)

• Instance Type: escolha o tamanho, lembre-se que todas as conexões irão passar por essa instância, então definir uma instância muito pequena pode aumentar o gargalo e a latência da conexão com a internet, porém para meu caso de uso que era um ambiente de QA, o tipo micro pareceu ser uma boa escolha.

• Keypair: escolha seu keypair, isso é sua chave de acesso que precisaremos dele depois para conseguir conectar através de SSH

• VPC: escolha o ID da sua VPC

• Subnet: defino como sem preferências, pois não me importa muito em qual sub-rede nossa instância NAT será criada, porém se preferir você pode definir uma subnet pública e não privada

  ⚠

  O NAT Instance deve ser criada em uma sub-rede Pública!

• Auto-assign Public IP: escolho habilitado, pois desejo que essa instância NAT tenha um endereço IP público criado automaticamente

• Security Group: escolho o grupo de segurança que criamos anteriormente

• Storage: defino um tamanho e seleciono o tipo como gp3

• Por fim clico em Launch Instance

Configurando o NAT Instance

1- Com nossa instância criada, acesso através de SSH → e primeiro atualizo os pacotes do Ubuntu com o comando:

sudo apt update -y

2- Agora verifico qual o nome da interface de rede primária com o comando:

ip a

E descubro que ela se chama ens5

3- Agora ativo o encaminhamento de IP com os comandos:

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf

sudo sysctl -p

4- Então agora criamos a regra para o NAT com o comando:

# Making a catchall rule for routing and masking the private IP
sudo iptables -t nat -A POSTROUTING -o ens5 -s 0.0.0.0/0 -j MASQUERADE

5- Agora precisamos tornar essa regra persistente, pois quando acontecer um reboot ou stop nessa instância, a regra do iptables para o NAT será perdida e você certamente não gostará de ter que acessar ela toda vez para repetir este comando, então para isso criamos uma pasta chamada iptables no diretório etc:

sudo mkdir -p /etc/iptables

6- E salvo nossa regra em um arquivo chamado rules.v4 com o comando:

sudo iptables-save | sudo tee /etc/iptables/rules.v4

7- Neste momento, nossa regra já está salva, mas ainda assim não está automático, seria necessário ainda acessar a instância para restaurar nossa regra, bom vamos corrigir isso agora instalando o iptables-persistent no modo silencioso que fará esse trabalho automático para nós.

sudo debconf-set-selections <<EOF
iptables-persistent iptables-persistent/autosave_v4 boolean true
iptables-persistent iptables-persistent/autosave_v6 boolean true
EOF

sudo apt-get -y install iptables-persistent

Desativando Verificações de Origem/Destino

1- Ainda não acabamos tudo, precisamos agora parar a verificação de origem e destino dessa instância, então acesso o console AWS → EC2 → seleciono a instância → Actions → Networking → Change source/destination check

2- Clico em Stop

Criando Tabela de Roteamento na VPC

1- Acesse o console AWS → VPC → Route Tables → Create Route Table

2- Defina um nome de sua preferência como por exemplo Private Route → selecione sua VPC → defina Tags se desejar → clique em Create Route Table

3- Agora clique em Edit Routes

4- Adicione uma rota:

• Destination:0.0.0.0/0

• Target:escolha o ID da sua instância NAT

Criando Sub-Redes Privadas

Como estou na região de Ohio, tenho três Availabilty Zones disponíveis:

• us-east-2a

• us-east-2b

• us-east-2c

Já tenho 3 sub-redes públicas criadas por padrão, então criarei outras três sub-redes privadas para cada Availability Zone .

1- Acesse o console da AWS → VPC → Subnets → Create Subnet

• us-east-2a | 172.31.48.0/20

• us-east-2b | 172.31.64.0/20

• us-east-2c | 172.31.80.0/20

2- Volte para o menu Route Tables → selecione a Tabela de Roteamento Privado que criamos → selecione a aba Subnet Associations → Edit

3- Selecione agora as sub-redes privadas criadas → clique em Save Association

Testando

Fizemos muitas coisas até aqui, por favor não se sinta "perdido", recapitulando o que fizemos até aqui:

• Criamos o Grupo de Segurança

• Criamos o NAT Instance na sub-rede pública

• Desativamos Verificações de Origem/Destino

• Criamos a Tabela Privada de Roteamento

• Criamos as Sub-redes Privadas

Neste momento, já temos tudo devidamente configurado, mas e agora como testar se tudo está funcionando? Bom para isso vou fazer 2 testes:

• Criar uma função Lambda dentro da VPC (lembre-se que isso perde a conexão dela com a internet) e testar sua conexão com a internet através do NAT Instance

• Criar uma instância EC2 na sub-rede privada e testar sua conexão com a internet

Lambda

Para adicionar a função Lambda que vamos criar, precisamos antes criar uma policy e role , vamos fazer isso agora:

Policy

1- Acesse o console AWS → IAM → Policies → Create Policy → crie a política com o código abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeNetworkInterfaces",
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:DescribeInstances",
                "ec2:AttachNetworkInterface"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "arn:aws:logs:<your-region>:<your-account-id>:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:<your-region>:<your-account-id>:log-group:/aws/lambda/<your-lambda-function-name>:*"
            ]
        }
    ]
}

2- Defina de acordo com suas preferências:

• Name: por exemplo lambda-test-internet-connection-policy

• Description: por exemplo Policy with necessary permissions to be used in the lambda function named test-internet-connection

Role

1- Acesse o console AWS → IAM → Role → Create Role → crie a role escolhendo:

• AWS Services

• Lambda

2- Adicione a política que acabamos de criar

3- Defina de acordo com sua preferência:

• Name: por exemplo lambda-test-internet-connection-role

• Description: por exemplo Role with required permissions used in lambda function named test-internet-connection

Criando o Lambda Function

1- Acesse o console AWS → Lambda → Create Function → Author from Scratch

2- Defina de acordo com sua preferência:

• Name: por exemplo test-lambda-internet-connection

3- Escolha as opções:

• Runtime:Node.js

• Architecture:x86_64

• Use an existing role: escolha a role que criamos anteriormente

4- A função será criada → clique na aba Code → renomeie o arquivo de index.mjs para index.js (remova o m do nome)

5- Apague o código criado automaticamente pela AWS → adicione este código:

const getContent = function (url) {
  // return new pending promise
  return new Promise((resolve, reject) => {
    // select http or https module, depending on reqested url
    const lib = url.startsWith('https') ? require('https') : require('http');
    const request = lib.get(url, (response) => {
      // handle http errors
      if (response.statusCode < 200 || response.statusCode > 299) {
        reject(new Error('Failed to load page, status code: ' + response.statusCode));
      }
      // temporary data holder
      const body = [];
      // on every content chunk, push it to the data array
      response.on('data', (chunk) => body.push(chunk));
      // we are done, resolve promise with those joined chunks
      response.on('end', () => resolve(body.join('')));
    });
    // handle connection errors of the request
    request.on('error', (err) => reject(err))
  })
};

exports.handler = async (event) => {
  console.log('Received event: %j', event);

  const url = event.url || 'https://www.google.com';
  try {
    const content = await getContent(url);
    console.log('Response content: %j', content);
    console.log('You have access to the internet, congratulations!');

    return {
      statusCode: 200,
      body: JSON.stringify({
        message: 'You have access!',
        content,
      }),
    };
  } catch (e) {
    console.error(e);
    return {
      statusCode: 500,
      body: JSON.stringify({
        message: e.toString(),
      }),
    };
  }
}

6- Clique em Configure Test Event

7- Defina um nome de sua preferência, por exemplo TestInternetConnection

8- Clique em Deploy → Test

9- Vamos colocar nossa função lambda na VPC → clique na aba Configuration → VPC → Edit

10- Selecione as Sub-redes privadas → e o grupo de segurança (escolhi o default-vpc security group)

11- Clico em Test novamente e concluo:

Criando um EC2 Privado

1- Acesse o console AWS → EC2 → Launch Instance → defina de acordo com sua preferência:

• Name: por exemplo ec2-private-test-internet-connection

• AMI:Amazon Linux

• Escolha uma sub-rede privada

• Verifique se a opção Auto-assign public IP é marcada como Disable

Role

1- Com nossa instância criada, precisaremos criar uma role para permitir conexões através do Session Manager, então vou para o console AWS → IAM → AWS Service → seleciono EC2

2- Adiciono a permissão AmazonSSMManagedInstanceCore

3- Defina um nome e descrição de acordo com suas preferências:

• Name: por exemplo ec2-session-manager-role

• Description: por exemplo Role with required permissions to allow access to EC2 through Session Manager

4- Volto para o console AWS → EC2 → seleciono a instância privada de teste → Actions → Security → Modify IAM Role

5- Seleciono a role que criamos anteriormente

6- Estamos quase lá, agora edito as regras de entrada do grupo de segurança do NAT Instance para permitir o ping dos blocos CIDR das sub-redes privadas

7- Edito agora nas regras de saída para permitir que o NAT Instance envie o ping para a internet

8- Agora com tudo pronto, vamos tentar conectar em nossa instância privada que não tem um IP público, através do Session Manager que possui permissões adequadas no IAM Role que foi anexada em nossa instância. Para isso seleciono novamente a instância privada de teste → Connect

9- Altero para a aba Session Manager → Connect

10- Executo um ping para o Google:

ping google.com

Conclusão

Fizemos uma breve explicação sobre o NAT Instance, também observamos o porque ele seria útil para meu caso de uso, além disso passamos por um tutorial de como configuramos um NAT Instance no Ubuntu com configurações persistentes para que funcione mesmo depois de reiniciar ou desligar.

Garantimos que mesmo após de um reboot, as regras do NAT estarão funcionando:

Garantimos também que mesmo que a instância esteja parada (stopped), quando ligarmos ela, automaticamente a ENI da tabela de rota privada que criamos mudará o status para ativo sem qualquer ação manual, fazendo com que o NAT funcione.

Também criamos dois testes práticos e reais:

• uma função lambda na VPC com conexão na internet

• e outra instância EC2 privada com conexão na internet, para isso configuramos também permissões adequadas.

Ao final fomos capazes de atingir o objetivo.

Como mencionei no início, este meu cenário eu não precisava da instância ligada o tempo, então se você também estiver interessado em reduzir ainda mais seu custo, talvez ache interessante agendar o STAR/STOP de uma instância EC2, veja mais detalhes sobre como fazer isso neste outro artigo:

• 👉 Como Agendar um START/STOP Automático no EC2

Com isso consegui reduzir um custo inteiro mensal de um NAT Gateway para o preço sob demanda do EC2 em uma instância mínima e com horários agendados de funcionamento.

Em um cenário de desenvolvimento ágil e integração contínua, a flexibilidade é importante. É nesse contexto que os Self-Hosted Runners do Bitbucket emergem como uma solução poderosa, oferecendo controle total sobre seu ambiente de build e deploy.

Neste artigo, exploraremos passo a passo como criar seu próprio Bitbucket Runner Auto Hospedado. Essa abordagem não apenas amplia a capacidade de personalização do seu pipeline, mas também proporciona maior eficiência ao permitir a execução de builds em um ambiente familiar e sob seu controle direto.

Tipos de Runners do Bitbucket

O Bitbucket oferece flexibilidade na execução de pipelines de CI/CD através de dois tipos de Runners:

• Shared

• Self-Hosted

Shared Runner:

• Gerenciado pela Nuvem: Você não precisa hospedar ou gerenciar nenhum servidor. O runner compartilhado é gerenciado e hospedado pelo Bitbucket na nuvem.

• Pronto para Uso: É uma opção pronta para uso, eliminando a necessidade de configurações adicionais.

• Ideal para Projetos Menores: Adequado para projetos menores e equipes que buscam uma solução rápida e eficiente sem a necessidade de manutenção direta.

• Cobrança: Oferece um limite de minutos de execução no plano gratuito com possibilidade de realizar upgrades.

Self-Hosted Runner:

• Controle Total: Você precisa hospedar ou gerenciar o servidor. O runner self-hosted oferece controle total ao permitir que você configure e mantenha seus próprios agentes de build.

• Adaptabilidade ao Ambiente: Permite a execução de builds em um ambiente que você controla, com a flexibilidade de adaptar recursos conforme necessário.

• Adequado para Projetos Complexos: Ideal para projetos maiores, equipes que requerem ambientes específicos ou aqueles que precisam integrar com recursos internos.

• Cobrança: Você tem a cobrança do seu servidor, mas seus minutos são ilimitados e você não será cobrado pelo limite e preço do Bitbucket.

Nível do Workspace

Se você for um administrador do espaço de trabalho, poderá configurar e gerenciar vários runners para toda a sua conta para que possam ser usados ​​em pipelines em qualquer repositório no espaço de trabalho. Isso torna mais fácil e economiza tempo na criação e gerenciamento de seus runners quando você tem muitos repositórios em seu espaço de trabalho.

Nível do Repositório

Você opcionalmente pode configurar e gerenciar runners para determinados repositórios, limitando seu uso em toda a organização, porém isso pode demandar mais tempo de administração sua.

Benefícios do Self-Hosted Runner

• Configurações de build personalizadas: os runners permitem que você configure seu hardware para diferentes tipos de build. Por exemplo, se seu build tiver que consumir muitos recursos, usar hardware com mais memória pode melhorar o tempo de execução.

• Acesse aplicativos ou bancos de dados internos: ao executar pipelines na infraestrutura do Bitbucket com shared runners, dificulta o trabalho para poder acessar sistemas internos como banco de dados por exemplo. Se você precisa executar testes de integração em seus bancos de dados ou aplicativos internos, você poderá fazer isso com runners auto hospedados na mesma rede fornecendo acesso necessário aos serviços internos.

• Fluxos de trabalho híbridos: você pode otimizar seus recursos usando runners auto hospedados com configurações personalizadas para builds que exigem isso e usar a infraestrutura do Bitbucket com shared runners para outros trabalhos.

Todo esse contexto é interessante, mas talvez seu principal motivo seja resolver esse aviso em sua conta Bitbucket:

Se você atingir o limite mensal do plano gratuito, receberá esse aviso e ficará incapaz de continuar usando os shared runners até o próximo mês, você pode resolver isso realizando um upgrade de conta ou usando seu próprio runner, e sim, se você usar seu próprio runner você também terá os custos relacionados a isso, mas considerando que você pode cria-lo no seu mesmo ambiente e que pode obter minutos ilimitados (pois ele é seu), talvez faça sentido considerar esse custo ao invés do custo de upgrade de conta no Bitbucket, você deve colocar na balança o melhor custo-benefício e decidir pela melhor escolha no seu cenário.

Tutorial Prático - Pré-Requisitos

Para a instalação de um Runner auto hospedado do Bitbucket, como o nome sugere você precisará de uma máquina, isso pode ser desde seu próprio computador até qualquer VPS de sua preferência.

Criando uma instância Lightsail

1- Acesse o console AWS → Lightsail → Create Instance

2- Escolha a região

3- Escolha o sistema operacional

4- Não adicione um script de inicialização, não altere sua chave key-pair e não habilite snapshots automáticos, as opções padrões parecem boas aqui.

5- Escolha Dual Stack, pois ainda há limitações para uso do IPv6 e precisamos que nossa instância tenha IPv4 também.

6- Selecione o tamanho da instância

7- Defina um nome, opcionalmente você pode inserir tags e clique em criar instância

8- Aguarde até o status Pending mudar para Running

Criando um IP Fixo

Se olharmos bem, a instância Lightsail recebeu um IPv4 e IPv6 público dinâmicos, isso aconteceu porque selecionamos a opção Dual Stack quando criamos a instância. O dinâmico significa que quando desligarmos essa instância e ligarmos novamente, esses endereços IPs irão mudar, isso pode ser um pouco chato e frustrante de se lembrar, principalmente quando você está tentando se conectar a ela.

Então vamos resolver isso criando um IP Fixo.

1- No console AWS Lightsail → Networking

2- Clique em Create Static IP

3- Mantenha a mesma região e zona de disponibilidade da sua instância → escolha a instância recém criada

4- Defina um nome → Create

Conectando via SSH na instância Lightsail

Se você não quiser usar um cliente SSH, pode fazer isso diretamente no console da AWS clicando nesse botão:

Se você estiver usando uma distribuição linux, como por exemplo ubuntu, poderia acessar também através do seu terminal com o comando:

ssh -i <LightsailDefaultKey.pem> <user>@<public-ip>

# Example
ssh -i LightsailDefaultKey.pem ubuntu@44.198.68.63

Porém como estou usando em meu computador o sistema operacional Windows, eu poderia fazer isso através do WSL2 com Prompt de Comando , Powershell ou Terminal do Windows, o Putty e muitas outras opções de clientes SSH disponíveis.

Mas prefiro usar o cliente gratuito chamado Termius, você pode obtê-lo em sua página de download e talvez seja necessário criar uma conta gratuita, há planos pagos disponíveis, mas o gratuito aqui é suficiente.

Também há opções disponíveis para Mac e Linux no final da página;

Não importa qual ferramenta SSH você usará, vimos agora que há muitas opções, tudo que você precisa ter em mente aqui é que você precisa se conectar na instância de alguma forma para seguirmos o tutorial.

1- Acesse o console AWS Lightsail → Account → SSH Keys

2- Procure por Default Keys → download

3- Abra o cliente SSH (em nosso exemplo Termius) → clique no ícone de engrenagem

4- Defina um nome de sua preferência → mova o arquivo da sua chave keypair que baixou do console AWS

5- Clique em New Host

6- Preencha os campos com:

• Address: o IP da instância

• Label: nome de sua preferência

• User: ubuntu

• Selecione Key

Clique em Connect

Clique em Continue

Instalando o Docker e Docker Compose

Uma vez conectado na instância, você precisará instalar o Docker e o Docker Compose, por favor copie o código de instalação que criamos em outro artigo disponível aqui:

• 👉 Como Instalar ou Atualizar o Docker e o Docker Compose

Cole em seu terminal e pressione Enter.

Aguarde a instalação e ao final você deverá ver algo parecido com:

Adicionando um Self-Hosted Runner do Bitbucket

1- Acesse sua conta Bitbucket → ícone de engrenagem → Workspace Settings

2- Clique em Workspace runners → Add runner

3- Escolha Linux Docker (x86_64)

4- Defina um nome de sua preferência → crie um label

5- Clique em Next → e ele fornecerá uma saída de comando como a seguinte

docker container run -it \
-v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/docker/containers:/var/lib/docker/containers:ro \
-e ACCOUNT_UUID={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} \
-e REPOSITORY_UUID={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} \
-e RUNNER_UUID={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} \
-e RUNTIME_PREREQUISITES_ENABLED=true \
-e OAUTH_CLIENT_ID=xxxxxxxxxxxxxxxx \
-e OAUTH_CLIENT_SECRET=xxxxxxxxxxxxxxxxxx \
-e WORKING_DIRECTORY=/tmp --name runner-xxxxxxxxxxxxxxxxxx docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1

6- Cole em seu terminal SSH → Enter

7- Feche seu terminal SSH → retorne para sua conta Bitbucket

8- Abra novamente seu terminal → obtenha o ID do container do seu runner com o comando:

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

9- Digite o comando abaixo para atualizar o restart policy deste container:

docker update --restart always <your-container-id>

10- Verifique a inspeção de container com o novo restart policy definido:

docker inspect -f '{{ json .HostConfig.RestartPolicy }}' <your-container-id>

Use o Self-Hosted Runner do Bitbucket

Para usar seu Self-Hosted Runner criado, você deve definir o seguinte trecho em seu arquivo bitbucket-pipelines.yml:

runs-on:
  - "lightsail1"

Vamos para um exemplo:

1- Crie um arquivo bitbucket-pipelines.yml na raíz do seu repositório, por exemplo:

definitions:

  hello_my_self_hosted_runner: &hello_my_self_hosted_runner
    name: Hi
    image: atlassian/default-image:4
    services:
      - docker
    runs-on:
      - "lightsail1"
    script:
      - echo "Hello, I'm running on Bitbucket's Self-Hosted Runner"

pipelines:

  branches:

    main:
      - stage:
          name: Production
          deployment: production
          steps:
            - step: *hello_my_self_hosted_runner

Bônus - Segurança

Se você utilizar uma conexão entre Bitbucket e AWS com OpenID Connect, descrevemos o passo a passo de como fazer isso aqui:

• 👉 Como configurar a Autenticação entre Bitbucket e AWS com OpenID Connect (OIDC)

Você pode aumentar ainda mais a sua segurança limitando o acesso apenas a este Self-Hosted Runner com o trecho SourceIp da seguinte forma:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::{AWS_ACCOUNT_NUMBER}:oidc-provider/api.bitbucket.org/2.0/workspaces/{WORKSPACE}/pipelines-config/identity/oidc"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringLike": {
      "api.bitbucket.org/2.0/workspaces/{WORKSPACE}/pipelines-config/identity/oidc:sub": "{REPO_UUID}:*"
    },
    "IpAddress": {
      "aws:SourceIp": [
        "<your-runner-ip>"
      ]
    }
  }
}

Limites de Uso

O Self-Hosted Runner tem os seguintes limites de uso:

• Máximo de memória disponível: você pode configurar até 32 GB (8x) de memória

• Número total de runners: você pode configurar até 100 runners por workspace e 100 runners por repositório

• Tempo de fila dos steps: os steps podem ficar na fila por no máximo 2,5 horas

Conclusão

Em resumo, a escolha entre um Shared Runner e um Self-Hosted Runner no Bitbucket Pipelines depende das necessidades específicas do seu projeto. O Shared Runner oferece praticidade para projetos menores, enquanto o Self-Hosted Runner proporciona controle total, personalização e eficiência em ambientes mais complexos.

Vimos em um tutorial prático o passo a passo de como criar um Self-Hosted Runner hospedado na AWS. Também vimos que é possível limitar a segurança para um IP específico para que você tenha certeza de estar usando somente seu runner.

Se você observar bem, todo o processo ainda é manual e você pode repeti-lo quantas vezes precisar. Você ainda pode pensar em uma solução automática para lançar seus runners e escalar eles, mas para a grande maioria esse procedimento manual será suficiente.

Ao entender os benefícios do Self-Hosted Runner, como controle total do ambiente, personalização flexível e integração com recursos internos, você pode tomar decisões mais informadas para otimizar seus processos de CI/CD. Escolha o tipo de Runner que se alinha melhor com os requisitos únicos do seu projeto, garantindo uma implementação eficaz e adaptada ao seu ambiente de desenvolvimento.

Em um cenário de desenvolvimento ágil e integração contínua, a flexibilidade é importante. É nesse contexto que os Self-Hosted Agents do Azure DevOps emergem como uma solução poderosa, oferecendo controle total sobre seu ambiente de build e deploy.

Neste artigo, exploraremos passo a passo como criar seu próprio Agent Auto Hospedado do Azure DevOps. Essa abordagem não apenas amplia a capacidade de personalização do seu pipeline, mas também proporciona maior eficiência ao permitir a execução de builds em um ambiente familiar e sob seu controle direto.

Tipos de Agents do Azure DevOps

O Azure DevOps oferece flexibilidade na execução de pipelines de CI/CD através de três tipos de Agents:

• Microsoft-Hosted Agents

• Self-Hosted Agents

• Azure Virtual Machine Scale Set Agents

Microsoft-Hosted Agents

• Servidores Gerenciados pela Microsoft: Os Microsoft-Hosted Agents são servidores de build e deploy totalmente gerenciados e atualizados pela Microsoft e estão pronto para uso sem qualquer configuração adicional.

• Limite Gratuito de Minutos por Mês: no momento da criação deste artigo, existe um limite de 1.800 minutos gratuitos por mês para o uso, oferecendo uma opção econômica para projetos menores.

• Solicitação de Liberação de Minutos: A Microsoft começou a exigir a solicitação através de um formulário para liberar os 1.800 minutos gratuitos para evitar abusos, se você não o fizer receberá um erro parecido com:

Self-Hosted Agents

• Controle Total: Você precisa hospedar ou gerenciar o servidor. O self-hosted oferece controle total ao permitir que você configure e mantenha seus próprios agentes de build.

• Adaptabilidade ao Ambiente: Permite a execução de builds em um ambiente que você controla, com a flexibilidade de adaptar recursos conforme necessário.

• Adequado para Projetos Complexos: Ideal para projetos maiores, equipes que requerem ambientes específicos ou aqueles que precisam integrar com recursos internos.

• Cobrança: Você tem a cobrança do seu servidor, mas seus minutos são ilimitados e você não será cobrado pelo limite e preço do Azure DevOps.

Azure Virtual Machine Scale Set Agents

• Elasticidade com Azure Virtual Machine Scale Set: Os Azure Virtual Machine Scale Set Agents oferecem elasticidade, permitindo a escala automática de máquinas virtuais conforme a demanda de build e deploy.

• Integração com Azure DevOps: Projetados para integração direta com o Azure DevOps, esses agentes fornecem um ambiente escalável e gerenciável para pipelines de CI/CD.

• Configuração Sob Demanda: Permitem a configuração sob demanda de máquinas virtuais, garantindo recursos adequados para lidar com a carga de trabalho, com a flexibilidade de ajustar conforme necessário.

Benefícios do Self-Hosted Agents

• Configurações de build personalizadas: os agents permitem que você configure seu hardware para diferentes tipos de build. Por exemplo, se seu build tiver que consumir muitos recursos, usar hardware com mais memória pode melhorar o tempo de execução.

• Acesse aplicativos ou bancos de dados internos: ao executar pipelines na infraestrutura do Azure DevOps com Microsoft-Hosted Agents, dificulta o trabalho para poder acessar sistemas internos como banco de dados por exemplo. Se você precisa executar testes de integração em seus bancos de dados ou aplicativos internos, você poderá fazer isso com agents auto hospedados na mesma rede fornecendo acesso necessário aos serviços internos.

• Fluxos de trabalho híbridos: você pode otimizar seus recursos usando agents auto hospedados com configurações personalizadas para builds que exigem isso e usar a infraestrutura do Azure DevOps com Microsoft-Hosted Agents para outros trabalhos.

Tutorial Prático - Pré-Requisitos

Para a instalação de um Agent auto hospedado do Azure DevOps, como o nome sugere você precisará de uma máquina, isso pode ser desde seu próprio computador até qualquer VPS de sua preferência.

Criando uma instância Lightsail

1- Acesse o console AWS → Lightsail → Create Instance

2- Escolha a região

3- Escolha o sistema operacional

4- Não adicione um script de inicialização, não altere sua chave key-pair e não habilite snapshots automáticos, as opções padrões parecem boas aqui.

5- Escolha Dual Stack, pois ainda há limitações para uso do IPv6 e precisamos que nossa instância tenha IPv4 também.

6- Selecione o tamanho da instância

7- Defina um nome, opcionalmente você pode inserir tags e clique em criar instância

8- Aguarde até o status Pending mudar para Running

Criando um IP Fixo

Se olharmos bem, a instância Lightsail recebeu um IPv4 e IPv6 público dinâmicos, isso aconteceu porque selecionamos a opção Dual Stack quando criamos a instância. O dinâmico significa que quando desligarmos essa instância e ligarmos novamente, esses endereços IPs irão mudar, isso pode ser um pouco chato e frustrante de se lembrar, principalmente quando você está tentando se conectar a ela.

Então vamos resolver isso criando um IP Fixo.

1- No console AWS Lightsail → Networking

2- Clique em Create Static IP

3- Mantenha a mesma região e zona de disponibilidade da sua instância → escolha a instância recém criada

Em nosso exemplo Norte da Virgínia e Zona de Disponibilidade A

4- Defina um nome → Create

Conectando via SSH na instância Lightsail

Se você não quiser usar um cliente SSH, pode fazer isso diretamente no console da AWS clicando nesse botão:

Se você estiver usando uma distribuição linux, como por exemplo ubuntu, poderia acessar também através do seu terminal com o comando:

ssh -i <LightsailDefaultKey.pem> <user>@<public-ip>

# Example
ssh -i LightsailDefaultKey.pem ubuntu@54.160.152.44

Porém como estou usando em meu computador o sistema operacional Windows, eu poderia fazer isso através do WSL2 com Prompt de Comando , Powershell ou Terminal do Windows, o Putty e muitas outras opções de clientes SSH disponíveis.

Mas prefiro usar o cliente gratuito chamado Termius, você pode obtê-lo em sua página de download e talvez seja necessário criar uma conta gratuita, há planos pagos disponíveis, mas o gratuito aqui é suficiente.

Também há opções disponíveis para Mac e Linux no final da página;

Não importa qual ferramenta SSH você usará, vimos agora que há muitas opções, tudo que você precisa ter em mente aqui é que você precisa se conectar na instância de alguma forma para seguirmos o tutorial.

1- Acesse o console AWS Lightsail → Account → SSH Keys

2- Procure por Default Keys → download

3- Abra o cliente SSH (em nosso exemplo Termius) → clique no ícone de engrenagem

4- Defina um nome de sua preferência → mova o arquivo da sua chave keypair que baixou do console AWS

5- Clique em New Host

6- Preencha os campos com:

• Address: o IP da instância

• Label: nome de sua preferência

• User: ubuntu

• Selecione Key

Clique em Connect

Clique em Continue

Instalando o Docker e Docker Compose

Uma vez conectado na instância, você precisará instalar o Docker e o Docker Compose, por favor copie o código de instalação que criamos em outro artigo disponível aqui:

• 👉 Como Instalar ou Atualizar o Docker e o Docker Compose

Cole em seu terminal e pressione Enter.

Aguarde a instalação e ao final você deverá ver algo parecido com:

Criando um Personal Access Token (PAT)

1- Faça login no console Azure DevOps → ícone de engrenagem → Personal Access Token

2- Clique em New Token

3- Defina:

• Um nome de sua preferência, por exemplo self-hosted-agent-token

• Sua organização

• Altere o tempo de expiração de acordo com sua preferência, por exemplo gosto de definir o tempo máximo de um ano através da seleção no calendário, mas totalmente opcional

• Em scope, selecione Custom definied → Show all scopes

4- Em Agent Pools → selecione Read & manage → Create

5- Copie e salve seu token em um local seguro agora

Instalando o Self-Hosted Agent

1- Abra novamente seu terminal → crie o diretório chamado azp-agent-in-docker com o comando:

mkdir ~/azp-agent-in-docker \
&& cd ~/azp-agent-in-docker

2- Crie o arquivo Dockerfile com o comando:

touch Dockerfile

3- Insira o seguinte conteúdo em seu Dockerfile:

sudo nano Dockerfile

# Use Ubuntu 22.04 as the base image
FROM ubuntu:22.04

# Update package information and upgrade installed packages
RUN apt update && \
    apt upgrade -y

# Install dependencies and capabilities
RUN apt install -y \
    curl \
    git \
    jq \
    libicu70

# Set the target architecture (e.g., "linux-x64", "linux-arm", "linux-arm64")
ENV TARGETARCH="linux-x64"

# Set the working directory inside the container
WORKDIR /azp/

# Copy the start script to the working directory
COPY ./start.sh ./

# Make the start script executable
RUN chmod +x ./start.sh

# Create a user 'agent' and set ownership of the working directory
RUN useradd agent && \
    chown agent ./

# Switch to the 'agent' user
USER agent

# Another option is to run the agent as root.
# ENV AGENT_ALLOW_RUNASROOT="true"

# Define the entry point for the container to execute the start script
ENTRYPOINT ./start.sh

cat Dockerfile

4- Agora crio o arquivo chamado start.sh com o comando:

touch start.sh

5- Insira o seguinte conteúdo em seu start.sh:

sudo nano start.sh

#!/bin/bash
set -e

if [ -z "${AZP_URL}" ]; then
  echo 1>&2 "error: missing AZP_URL environment variable"
  exit 1
fi

if [ -z "${AZP_TOKEN_FILE}" ]; then
  if [ -z "${AZP_TOKEN}" ]; then
    echo 1>&2 "error: missing AZP_TOKEN environment variable"
    exit 1
  fi

  AZP_TOKEN_FILE="/azp/.token"
  echo -n "${AZP_TOKEN}" > "${AZP_TOKEN_FILE}"
fi

unset AZP_TOKEN

if [ -n "${AZP_WORK}" ]; then
  mkdir -p "${AZP_WORK}"
fi

cleanup() {
  trap "" EXIT

  if [ -e ./config.sh ]; then
    print_header "Cleanup. Removing Azure Pipelines agent..."

    # If the agent has some running jobs, the configuration removal process will fail.
    # So, give it some time to finish the job.
    while true; do
      ./config.sh remove --unattended --auth "PAT" --token $(cat "${AZP_TOKEN_FILE}") && break

      echo "Retrying in 30 seconds..."
      sleep 30
    done
  fi
}

print_header() {
  lightcyan="\033[1;36m"
  nocolor="\033[0m"
  echo -e "\n${lightcyan}$1${nocolor}\n"
}

# Let the agent ignore the token env variables
export VSO_AGENT_IGNORE="AZP_TOKEN,AZP_TOKEN_FILE"

print_header "1. Determining matching Azure Pipelines agent..."

AZP_AGENT_PACKAGES=$(curl -LsS \
    -u user:$(cat "${AZP_TOKEN_FILE}") \
    -H "Accept:application/json;" \
    "${AZP_URL}/_apis/distributedtask/packages/agent?platform=${TARGETARCH}&top=1")

AZP_AGENT_PACKAGE_LATEST_URL=$(echo "${AZP_AGENT_PACKAGES}" | jq -r ".value[0].downloadUrl")

if [ -z "${AZP_AGENT_PACKAGE_LATEST_URL}" -o "${AZP_AGENT_PACKAGE_LATEST_URL}" == "null" ]; then
  echo 1>&2 "error: could not determine a matching Azure Pipelines agent"
  echo 1>&2 "check that account "${AZP_URL}" is correct and the token is valid for that account"
  exit 1
fi

print_header "2. Downloading and extracting Azure Pipelines agent..."

curl -LsS "${AZP_AGENT_PACKAGE_LATEST_URL}" | tar -xz & wait $!

source ./env.sh

trap "cleanup; exit 0" EXIT
trap "cleanup; exit 130" INT
trap "cleanup; exit 143" TERM

print_header "3. Configuring Azure Pipelines agent..."

./config.sh --unattended \
  --agent "${AZP_AGENT_NAME:-$(hostname)}" \
  --url "${AZP_URL}" \
  --auth "PAT" \
  --token $(cat "${AZP_TOKEN_FILE}") \
  --pool "${AZP_POOL:-Default}" \
  --work "${AZP_WORK:-_work}" \
  --replace \
  --acceptTeeEula & wait $!

print_header "4. Running Azure Pipelines agent..."

chmod +x ./run.sh

# To be aware of TERM and INT signals call ./run.sh
# Running it with the --once flag at the end will shut down the agent after the build is executed
./run.sh "$@" & wait $!

cat start.sh

ls -1

6- Agora construo a imagem com o comando:

docker build -t "azp-agent:linux" -f Dockerfile .

docker image ls --format "table {{.ID}}\t{{.Repository}}"

7- Agora vamos precisar de três informações para poder iniciar nosso container:

• AZP_URL:

  Você pode obtê-la olhando para a barra de endereço do seu navegador:

  🔗

  https://dev.azure.com/<your-organization>

  

• AZP_POOL:

  ℹ

  Você precisa criar um novo em Organization Settings → Agent Pools → Add Pool

  

  ℹ

  Selecionar o tipo Self-Hosted

  

  ℹ

  Definir um nome de sua preferência, por exemplo AWS-Lightsail-Self-Hosted-Linux-Docker → manter a opção Auto-provision this agent pool in all projects marcado → Create

  

• AZP_TOKEN:

  Este é o Personal Access Token (PAT) que criamos e copiamos para um local seguro antes.

8- Com essas três informações em mãos, vamos iniciar o container com o seguinte comando:

docker run \
  -e AZP_URL="<Your Azure DevOps instance>" \
  -e AZP_TOKEN="<Your Personal Access Token>" \
  -e AZP_POOL="<Your Agent Pool Name>" \
  -e AZP_AGENT_NAME="AWS Lightsail Docker Agent 1" \
  --name "azp-agent-1" \
  azp-agent:linux

9- Digite o comando abaixo para atualizar o restart policy deste container:

docker update --restart always <your-container-id>

10- Verifique a inspeção de container com o novo restart policy definido:

docker inspect -f '{{ json .HostConfig.RestartPolicy }}' <your-container-id>

Usando o Self-Hosted Agent

Se você estiver usando o arquivo azure-pipelines.yml você pode definir seu Self-Hosted Agent no trecho pool, por exemplo:

trigger:
- main

pool:
  # Name of your agent pool
  name: 'AWS-Lightsail-Self-Hosted-Linux-Docker'  

jobs:
- job: RunOnSelfHostedAgent
  displayName: 'Run on AWS Lightsail Docker Agent'
  steps:
  - script: echo "Hi, I'm running on AWS Lightsail Docker Agent 1"
    displayName: 'Print Message'

docker ps --format "table {{.ID}}\t{{.Names}}" --all

Se você estiver usando o editor classic , poderá fazer isso selecionando o pool

Bônus - Atualização dos Agents

A qualquer momento, você pode atualizar seus agents em Organization Settings → Agent Pools → More Options (três pontinhos) → Update Agent

Conclusão

Em meio ao dinâmico cenário da automação e integração contínua, o Self-Hosted Agent do Azure DevOps emerge como uma ferramenta poderosa para capacitar equipes de desenvolvimento. Neste artigo, exploramos os diferentes tipos de agents disponíveis, destacando a versatilidade e flexibilidade do Self-Hosted Agent.

Ao conduzir um passo a passo prático, mergulhamos na criação de um Self-Hosted Agent utilizando o Docker. Essa abordagem não apenas oferece controle total sobre o ambiente de execução, mas também demonstra a escalabilidade e eficiência proporcionadas pelo uso de containers.

Vimos que os passos são manuais e você pode repeti-los quantas vezes for necessário. Também pode ainda pensar em uma forma de automatizar e escalar a criação de seus Self-Hosted Agents, mas para a maioria das pessoas isso será o suficiente.

Ao concluir esta jornada, espero que você esteja equipado com os conhecimentos necessários para aproveitar ao máximo o potencial do Self-Hosted Agent no Azure DevOps. A capacidade de personalizar, escalar e integrar-se perfeitamente ao seu ambiente torna esse recurso essencial para otimizar seus fluxos de trabalho de CI/CD.

Introdução

Explorar as possibilidades da tecnologia de containers é uma jornada emocionante para desenvolvedores e profissionais de DevOps. O Docker e o Docker Compose são ferramentas importantes e suas instalações podem ser uma experiência única e empolgante, especialmente ao explorar novos caminhos para otimizar o ambiente de desenvolvimento.

Existem duas versões do Docker:

• Docker CE (Community Edition): é uma versão gratuita e de código aberto do Docker, adequada para uso pessoal e em pequenas e médias empresas. O suporte é principalmente fornecido pela comunidade e pode ser mais limitado em comparação com o Docker EE.

• Docker EE (Enterprise Edition): é uma versão paga do Docker, projetada para uso em ambientes corporativos e em grande escala. Ela oferece suporte comercial, SLAs (Service Level Agreements) e recursos adicionais voltados para segurança, conformidade e integração.

Neste artigo, compartilho como tenho feito a instalação ou atualização do Docker CE (Community Edition) e do Docker Compose que são gratuitos. Além disso, vou detalhar como essa instalação pode ser realizada de forma eficiente no contexto do Windows, aproveitando o WSL2 (Windows Subsystem for Linux 2) e dispensando a necessidade do aplicativo Docker Desktop.

Para Usuários do Windows

Se você usa o Windows, não se preocupe, poderá fazer a instalação deste artigo sem problemas, mas antes de seguirmos em frente, é interessante que você saiba que há duas formas de instalar o Docker no Windows:

Opção 1 - Aplicativo Docker Desktop

Não há muitas novidades aqui, você pode fazer essa instalação:

1- Acesse o site oficial:

• 👉 https://www.docker.com/products/docker-desktop/

2- Clique em Download for Windows:

Ao final, você pode obter um resultado semelhante:

Opção 2 (Sugerida) - WSL2

WSL2 significa (Windows Subsystem for Linux 2) e possibilita ter um Linux nativo dentro do Windows, então a ideia aqui é instalar o Docker diretamente no Linux nativo do Windows. Entrarei em mais detalhes sobre algumas vantagens e desvantagens sobre isso, de qualquer forma essa opção exige que seu Windows tenha um WSL2 instalado e configurado, para isso talvez você ache interessante ler este outro artigo com um passo a passo de como atingir esse requisito:

• 👉 WSL2 - Instalação e Configuração

Vantagens e Desvantagens

Até agora mencionei que há duas opções de instalação do Docker no Windows, mas como você pode decidir qual é a melhor opção para você? Para responder essa pergunta, vou detalhar um pouco mais algumas coisas que aprendi para ajudar você a tomar essa decisão.

Ao instalar o aplicativo Docker Desktop no Windows, no background ele usará o WSL2, mas de uma forma um pouco diferente. Quando a instalação for concluída, será criado duas distribuições adicionais do WSL2 em seu dispositivo:

• docker-desktop: responsável por executar o docker deamon e sua infraestrutura ao redor para seu funcionamento.

• docker-desktop-data: responsável por armazenar as imagens e configurações do docker.

NAME                     STATE           VERSION
* Ubuntu-22.04           Running         2
  docker-desktop         Running         2
  docker-desktop-data    Running         2

Como você pode perceber, você precisará de mais recursos como memória, cpu, disco, etc para executar todas as distribuições ao mesmo tempo. Então a grande desvantagem aqui é a performance e a lentidão.

Eu particularmente não gosto dessa abordagem, por dois motivos:

• Para aprender docker, eu prefiro executar o comandos docker ao invés de depender de uma interface gráfica

• Quando estou na minha distribuição linux nativo com o WSL2 e executo um comando docker, na verdade não estou usando o docker diretamente nele, mas estou usando a outra distribuição docker-desktop, então eu acho que isso é uma etapa a mais desnecessária e que pode causar erros e lentidões.

Em contrapartida, uma grande vantagem é que o Docker estará compartilhado e disponível em qualquer ambiente ou ferramenta que você usar, por ele estar em uma distribuição dedicada à isso (distro docker-desktop), todos os comandos docker funcionarão no windows terminal, no powershell, no cmd, etc.

Embora eu não ache isso muito útil, pois na maioria das vezes uso apenas minha distribuição linux nativa do WSL2, então raramente eu preciso do docker no powershell ou cmd por exemplo. Mas entendo se este não for o seu caso.

Uma grande desvantagem da instalação no WSL2 é que ela é individual, ou seja, se você tiver várias distribuições, deverá instalar o docker em cada uma delas, pois diferente da instalação do Docker Desktop, os comandos não ficam compartilhados entre as distribuições, felizmente vou compartilhar um único comando rápido e fácil que ajudará essa repetição ser bem menos tediosa.

Em resumo, você pode tomar sua decisão agora baseando-se em:

• Aplicativo Docker Desktop: se você deseja ter uma interface gráfica ou executar comandos docker em qualquer lugar como powershell, cmd ou windows terminal, essa opção pode ser a mais adequada para você.

• Docker no WSL2: se você está mais interessado em aprender os comandos docker, não precisa de uma interface gráfica, precisa do docker somente na sua distribuição linux e está mais interessado em performance, essa opção pode ser a mais adequada para você.

Instalação ou Atualização

1- Abra seu aplicativo de terminal preferido:

2- Insira o comando:

Embora o site oficial do Docker mencione um mínimo de 4GB de RAM necessários, na maioria das vezes 2 GB de RAM poderá ser o suficiente para muitas cargas de trabalhos, esse script funcionou bem para:

• Mínimo de 512 MB RAM

• Mínimo de 2vCPU (core)

• Mínimo de 20 GB SSD

# Install latest Docker Version
curl -fsSL https://get.docker.com/ | sh && \

# Get latest Docker Compose version
COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest \
| grep 'tag_name' \
| cut -d'"' -f4) && \

# Download latest Docker Compose
sudo curl \
-L "https://github.com/docker/compose/releases/download/$COMPOSE_VERSION/docker-compose-$(uname -s)-$(uname -m)" \
-o /usr/local/bin/docker-compose && \

# Make Docker Compose executable
sudo chmod +x /usr/local/bin/docker-compose && \

# Add current user to "docker" group
sudo usermod -aG docker $USER && \

# Show Docker and Docker Compose versions
echo "============================================" && \
echo "Docker and Docker Compose Versions Installed" && \
docker --version && \
docker-compose --version && \
echo "============================================"

Agora todos os comandos Docker já estarão disponíveis:

docker --help

Também estará disponível os comandos Docker Swarm:

docker swarm --help

Também os comandos Docker Stack:

docker stack --help

E por fim os comandos do Docker-Compose:

docker-compose --help

Explicando o Comando

Se você estiver curioso em descobrir o que cada etapa do comando está fazendo, para um melhor entendimento, vou quebrar o comando acima em várias partes e ir explicando passo a passo:

# Install latest Docker Version
curl -fsSL https://get.docker.com/ | sh && \

Este comando utiliza o curl para baixar o script de instalação oficial do Docker a partir da URL fornecida. O pipe | envia o conteúdo baixado pelo curl para o comando sh, que executa o script.

Em outras palavras, estamos acessando o script oficial disponível em:

• 👉 https://get.docker.com

E executando com o bash este script, que então irá verificar a arquitetura do seu dispositivo se é x86_64 ou arm64 por exemplo, também irá verificar a sua distribuição se é ubuntu, debian, centos, etc. E fará a instalação ou atualização.

# Get latest Docker Compose version
COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest \
| grep 'tag_name' \
| cut -d'"' -f4) && \

Obtém a versão mais recente do Docker Compose disponível no repositório do GitHub, analisando a resposta para obter a versão mais recente e armazenando na variável de ambiente COMPOSE_VERSION.

# Download latest Docker Compose
sudo curl \
-L "https://github.com/docker/compose/releases/download/$COMPOSE_VERSION/docker-compose-$(uname -s)-$(uname -m)" \
-o /usr/local/bin/docker-compose && \

Baixa a versão mais recente do Docker Compose e salva no diretório /usr/local/bin/

# Make Docker Compose executable
sudo chmod +x /usr/local/bin/docker-compose && \

Torna o arquivo docker-compose baixado executável.

# Add current user to "docker" group
sudo usermod -aG docker $USER && \

Adiciona o usuário atual ao grupo docker para poder executar comandos Docker sem usar sudo .

# Show Docker and Docker Compose versions
echo "============================================" && \
echo "Docker and Docker Compose Versions Installed" && \
docker --version && \
docker-compose --version && \
echo "============================================"

Mostra as versões do Docker e Docker Compose instaladas ou atualizadas.

Bônus - Para quem usar WSL2

Você pode configurar o docker para iniciar automaticamente junto com seu WSL2:

1- Crie o arquivo em /etc/wsl.conf

2- Insira esse conteúdo com seu editor preferido:

[boot]
systemd=true
[boot] command = service docker start

Conclusão

Neste artigo, compartilhei como tenho feito a instalação ou atualização do Docker e Docker Compose, também demonstrei para usuários Windows duas opções de instalação, ainda demonstrei qual poderia ser a opção mais adequada e informei a que eu uso e os motivos para isso.

Introdução

No cenário atual de desenvolvimento de software, a integração entre diferentes plataformas é crucial para promover eficiência e colaboração. Nesse contexto, o OpenID Connect (OIDC) emerge como um protocolo de autenticação poderoso e amplamente utilizado, desempenhando um papel fundamental na segurança e na interoperabilidade entre sistemas.

A automatização de todos os processos de test, build e deploy garante que os produtos que são desenvolvidos sejam produzidos mais rapidamente, com melhor qualidade e menos erros. Há várias ferramentas disponíveis para automatizar esses processos manuais. Mas quando você automatiza tudo, não se esqueça de uma coisa: Segurança!

Então você criou um app incrível e chegou a hora de fazer o deploy para AWS, você configura um pipeline de CI/CD para automatizar muitas coisas, nesse momento você percebe que precisa realizar a autenticação do seu pipeline com sua conta AWS e começa a se preocupar com a segurança em torno disso. Se você chegou até aqui procurando uma solução para essa sua preocupação e necessidade, eu também já a tive e compartilho como cobri esse tema e o que tem funcionado para mim.

O que é OpenID Connect (OIDC)

O OIDC é uma extensão do OAuth 2.0, focado na autenticação de identidades. Sua principal finalidade é permitir que aplicativos e serviços validem a identidade de usuários de maneira segura e eficiente. Ao fornecer uma camada adicional sobre o OAuth 2.0, o OIDC adiciona recursos específicos para autenticação, possibilitando a obtenção de informações sobre o usuário autenticado de maneira padronizada.

O funcionamento do OIDC baseia-se em um fluxo de comunicação seguro entre partes envolvidas, conhecidas como provedor de identidade (IdP) e cliente. No contexto do nosso artigo, o Bitbucket atuará como cliente, enquanto a AWS será configurada como o provedor de identidade.

O processo começa com o cliente (Bitbucket) solicitando a autenticação ao provedor de identidade (AWS). O provedor de identidade (AWS), por sua vez, autentica o usuário, retornando um token de identificação ao cliente (Bitbucket), que pode ser usado para acessar informações sobre o usuário autenticado.

Ao configurar o OpenID Connect (OIDC) entre o Bitbucket e a AWS, estaremos estabelecendo uma ponte segura para a autenticação de usuários, fortalecendo a segurança e simplificando a gestão de identidades em ambientes interconectados.

Nos próximos passos deste artigo, exploraremos detalhadamente como realizar essa configuração, garantindo uma integração eficiente e confiável entre essas duas poderosas plataformas.

Escopo do Tutorial

Antes de começarmos, vamos definir o escopo das ferramentas mencionadas neste artigo. Em primeiro lugar, devemos considerar:

• Bitbucket da Atlassian: uma potente solução Git que agiliza os fluxos de trabalho de implantação e reforça as medidas de segurança focadas em equipes de desenvolvimento profissionais. Porém, neste caso específico, estamos mais interessados ​​no Bitbucket Pipelines.

• Bitbucket Pipelines: é uma solução de integração contínua e entrega contínua (CI/CD) fornecida pela plataforma Bitbucket. Ele permite que os desenvolvedores automatizem os processos de teste, build e deploy de seus códigos diretamente com o repositório Bitbucket. Com a integração Bitbucket CI/CD, você pode implantar perfeitamente sua infraestrutura e aplicativos na nuvem AWS.

Visão Geral e Vantagens

Se quisermos fazer o deploy de um aplicativo na AWS, ela nos permite criar credenciais de segurança (chaves de acesso programáticas) mais conhecidas como Access Key e Secret Access Key e passá-las para o pipeline de implantação por meio de variáveis ​​de ambiente, por exemplo:

Este tipo de processo de implantação é muito mais comum do que deveria, mas existem vários potenciais problemas nesta abordagem, destacando:

• Quando há erros de script, há risco de vazamento das chaves de acesso no código

• Quando as chaves de acesso mudam ou precisam ser alternados, você deve atualizá-los manualmente no Bitbucket

• Você deve garantir que eles não foram expostos acidentalmente

• Você deve mantê-los com segurança

• Pode ser um problema de conformidade em setores altamente regulamentados

Nesses casos, o OpenID Connect (OIDC) vem em nossa ajuda. Embora a maioria dos desenvolvedores que enfrentam a necessidade de implantar na AWS com Bitbucket usem a chave de acesso secreta, o OIDC pode nos ajudar a evitar o uso de chaves e simplificar significativamente implantações futuras.

Além disso, existem vários motivos pelos quais o uso do OIDC é melhor para os desenvolvedores em comparação ao uso de chaves de acesso:

• Mais seguro: se suas chaves secretas vazarem, usuários não autorizados poderão usar suas chaves de acesso para obter acesso aos seus recursos da AWS. OpenID depende de seu Role ARN da AWS que, mesmo se vazado, não dá acesso aos seus recursos da AWS, as credenciais também são temporárias e expiram limitando o uso indesejado.

• Mais fácil de gerenciar: para gerenciar o risco de segurança, quando os administradores de nuvem geram chaves secretas para os usuários, eles concedem permissões granulares com base nas necessidades do usuário. Isso significa ter que criar muitos pares de chaves de usuário. As permissões baseadas em funções no OpenID ainda se beneficiam de permissões granulares, mas são menos restritivas. Os administradores têm menos níveis de permissão para gerenciar.

• Não são necessárias atualizações: quando você precisa alterar sua chave secreta ou quando a AWS desabilita uma chave devido à inatividade, você não precisa atualizar suas chaves em seus aplicativos ou no Bitbucket porque o OpenID não depende de chaves de acesso.

Pré-Requisitos

Para usar o OpenID Connect (OIDC) em Bitbucket Pipelines relacionados à AWS, você precisa configurar o Bitbucket Pipelines como um provedor de identidade da web (IdP) na AWS e criar uma função AWS Identity and Access Management (IAM).

Então como premissa você precisa ter uma conta do Bitbucket e outra da AWS, como nosso exemplo prático será um site estático com domínio personalizado, assumimos como premissa também que você já tenha seu domínio no Route 53 da AWS, pois não abordaremos essa configuração para não deixar o artigo mais extenso do que já é.

Tutorial

Cenário

Para demonstrar melhor todas as configurações, vamos criar um site estático no Bucket S3 com domínio personalizado, configurar o OIDC entre o repositório do Bitbucket e AWS e realizar um deploy automático alterando o número da versão da página deste site.

Etapa 1 - Criando o Bucket S3

1- Acesse o console AWS → S3 → Create Bucket

2-

• Escolha a região

• Selecione a opção General Purpose

• Defina um nome (no nosso exemplo o nome é:

  tutorial-bitbucket-oidc-aws.simplescloud.io

• Desabilite o ACLs

• Desabilite o bloqueio público

• Desabilite o versionamento

• Deixe todas as outras opções padrões

• Clique em criar seu bucket S3

Etapa 2 - Fazendo Upload do index.html no Bucket S3

1- Em seu computador, abra seu editor de texto predileto e crie um arquivo chamado index.html, cole este conteúdo e salve o arquivo:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Tutorial OpenID Connect (OIDC)</title>
    <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Nunito:wght@400;700&display=swap">
    <style>
        body {
            font-family: 'Nunito', sans-serif;
            background: linear-gradient(45deg, #3498db, #2c3e50);
            margin: 0;
            padding: 0;
            display: flex;
            flex-direction: column;
            align-items: center;
            justify-content: center;
            height: 100vh;
            color: #fff;
        }

        h1, h2 {
            text-align: center;
            margin: 0;
            padding: 10px;
        }

        h1 {
            font-size: 2.5rem;
            margin-top: 20px;
        }

        h2 {
            font-size: 1.8rem;
            font-weight: 400;
        }
    </style>
</head>
<body>
    <h1>Tutorial OpenID Connect (OIDC)</h1>
    <h2>Between Bitbucket and AWS</h2>
    <h2>Version 1</h2>
</body>
</html>

2- Agora arraste para o bucket S3 ou clique no botão Upload, ao final você deve ver uma tela parecida com:

Etapa 3 - Habilitando o Site Estático no Bucket S3

1- No console AWS → Bucket S3 → acesse o bucket recém criado e navegue até a aba Properties → role a página para baixo até encontrar a opção Static Website Hosting → clique em Editar

2-

• Clique em Enable

• Escolha a opção Host a static website

• Defina o nome do documento como index.html

Etapa 4 - Tornando o Site Público

1- Agora alterne para a aba Permissions → em Bucket Policy clique no botão Edit

2- Insira a política abaixo e salve

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}

Etapa 5 - Criando o Registro DNS no Route 53

1- Acesse o console AWS → Route 53 → Hosted Zone → Crie um novo registro DNS:

• Nome igual ao do bucket S3

• Tipo A

• Alias habilitado

• Selecione o bucket S3

Etapa 6 - Verificando o Site Funcionando

1- Abra seu navegador → acesse o domínio personalizado que criou, em nosso exemplo isso é tutorial-bitbucket-oidc-aws.simplescloud.io, mas obviamente lembre-se de trocar para o valor real que você utilizou

Etapa 7 - Criando um Identity Provider (IdP) na AWS

1- Acesse sua conta Bitbucket → configurações do repositório → OpenID Connect → copie e anote:

• Identity Provider URL

• Audience

• Repository UUID

Que nós vamos precisar dessas informações mais para frente.

2- Agora acesse o console AWS → IAM → Identity Providers → Create Identity Provider:

• Selecione a opção OpenID Connect

• No campo Provider URL cole o que você copiou do campo Identity Provider URL do Bitbucket

• No campo Audience cole o que você copiou do campo Audience do Bitbucket

• Clique no botão Get thumbprint

• Por fim, clique no botão Add Provider

Etapa 8 - Criando Política de Acesso para o Bucket S3

1- Acesse o console AWS → IAM → Policies → Create Policy → cole o conteúdo

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::<your-bucket-name>",
                "arn:aws:s3:::<your-bucket-name>/*"
            ]
        }
    ]
}

2- Defina um nome e descrição de sua preferência, por exemplo:

• Nome:s3-bucket-tutorial-bitbucket-oidc-aws.simplescloud.io-policy

• Descrição:Policy with permissions required to access the bucket named tutorial-bitbucket-oidc-aws.simplescloud.io

Etapa 9 - Criando Política de Conexão

Repita os passos da Etapa 8, mas agora defina um outro nome e descrição de sua preferência, por exemplo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:GetCallerIdentity"
            ],
            "Resource": "*"
        }
    ]
}

• Nome:oidc_bitbucket_policy

• Descrição:Policy that allows OpenID Connect between Atlassian Bitbucket and AWS

Etapa 10 - Criando uma Role de Permissão

1- Acesse o console AWS → IAM → Role → Create Role

• Selecione a opção Web Identity

• Selecione em Identity Provider a identidade de provedor que criamos anteriormente

• Selecione em Audience a audiência de provedor que criamos anteriormente

2- Defina um nome e descrição de sua preferência, por exemplo:

• Nome:deploy-tutorial-bitbucket-oidc-aws.simplescloud.io-role-prod

• Descrição:Role with necessary permissions to deploy to the bucket called tutorial-bitbucket-oidc-aws.simplescloud.io in the production environment

• Observe a estrutura da política de confiança, nós vamos altera-la em breve, por enquanto apenas clique em Next

3- Depois de criado → selecione a aba Trust Relationships → Edit → e altere para a política abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<your-account-id>:oidc-provider/api.bitbucket.org/2.0/workspaces/<your-bitbucket-workspace>/pipelines-config/identity/oidc"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "api.bitbucket.org/2.0/workspaces/<your-bitbucket-workspace>/pipelines-config/identity/oidc:sub": "{<your-bitbucket-repo-uuid>}:*"
                }
            }
        }
    ]
}

É uma mudança sútil entre a política padrão para essa que editamos, em resumo as alterações são:

• Mudamos de StringEquals para StringLike

• Mudamos aud para sub

• Adicionamos um wildcard (*) ao final do endpoint do repositório

4- Agora sua Role de Permissão deve estar devidamente criada e configurada, ela deve se parecer com isso, e não se esqueça de copiar o ARN, pois usaremos essa informação mais para frente

Etapa 11 - Configurando seu Computador

1- Em seu computador crie um pasta de sua preferência, por exemplo estou usando:

~/home/projects/bitbucket-openid-connect-aws

2- Crie novamente o arquivo index.html das etapas iniciais dentro dessa pasta

3- Agora crie um outro arquivo chamado bitbucket-pipelines.yml → cole este conteúdo:

# Deploy to S3 Bucket

definitions:

  build_step: &build_step
    name: Build Artifact
    image: atlassian/default-image:4
    script:
      - mkdir artifact
      - cp index.html artifact/
    artifacts:
         - artifact/**

  deploy_step: &deploy_step
    name: Deploy to AWS S3
    oidc: true
    script:
      # Upload to S3 Bucket   
      - pipe: atlassian/aws-s3-deploy:1.6.0
        variables:
          AWS_OIDC_ROLE_ARN: $AWS_OIDC_ROLE_ARN
          AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
          S3_BUCKET: $S3_BUCKET
          LOCAL_PATH: "artifact"
          ACL: "bucket-owner-full-control"
          DELETE_FLAG: "true"

pipelines:

  branches:

    feature/*:
     - stage:
         name: Dev 
         deployment: dev
         steps:
          - step: *build_step
          - step: *deploy_step

    bugfix/*:
     - stage:
         name: Dev
         deployment: dev
         steps:
          - step: *build_step
          - step: *deploy_step

    release/*:
     - stage:
         name: Staging
         deployment: staging
         steps:
          - step: *build_step
          - step: *deploy_step

    # =======================================================
    # Write-protected main branch, 
    # pipeline runs only on merge of a pull request approved
    # by specific people
    # -------------------------------------------------------
    # Branch restrictions
    # Write Access: none
    # Merge via pull requests: specific people
    # =======================================================

    # main:
    main:
     - stage:
         name: Production 
         deployment: production
         steps:
          - step: *build_step
          - step: *deploy_step

Então ao final, você deve ter uma pasta com dois arquivos:

• index.html

• bitbucket-pipelines.yml

No meu exemplo, isso se parece com:

Etapa 12 - Habilitando o Pipelines no Bitbucket

1- Acesse o Bitbucket → Repositório → Configurações do Repositório → Settings → Enable Pipelines

Etapa 13 - Criando Variáveis de Ambiente no Bitbucket

1- Acesse o Bitbucket → Repositório → Configurações do Repositório → Deployments → crie as seguintes variáveis de ambiente em Production:

• AWS_OIDC_ROLE_ARN: cole o ARN da Role que você criou em uma das etapas anteriores. Certifique-se de deixar Secured marcado para isso

• AWS_DEFAULT_REGION: insira a região que seu bucket S3 foi criado, no nosso exemplo foi em Norte da Virgínia, então essa região é us-east-1. Você pode ver todos os nomes das regiões clicando no menu superior direito do console AWS

• S3_BUCKET: insira o nome do bucket que criou

Etapa 14 - Fazendo comandos Git

1- Acesse o terminal do seu computador e acesse a pasta que contém os 2 arquivos (index.html e bitbucket-pipelines.yml) das etapas anteriores

2- Inicie o Git nessa pasta

git init

3- Configure o git com o email da sua conta Bitbucket:

git config user.email "<your-bitbucket-email>"

4- Configure o git com o nome de usuário da sua conta Bitbucket:

git config user.name "<your-bitbucket-username>"

5- Adicione o repositório remoto nessa pasta:

git remote add origin git@<your-bitbucket-git>

6- Crie uma branch chamada local:

git checkout -b local

Etapa 15 - Verificando o Funcionamento do Pipeline

1- Envie um push local para o Bitbucket:

git add . && \
git commit -m "Deploy Pipeline with Open ID Connect on AWS" && \
git push origin local:main

2- Verifique o Bitbucket → Pipelines e deve ter agora um pipeline em andamento

3- Aguarde sua conclusão e abra os detalhes do pipeline

4- Volte para seu editor de texto novamente e altere agora o número da versão de 1 para 2 do arquivo index.html

5- Envie um novo push local para o Bitbucket:

git add . && \
git commit -m "Change index.html version" && \
git push origin local:main

6- Aguarde o Pipeline funcionar novamente, lembrando que ele está se autenticando com OpenID Connect corretamente entre Bitbucket e AWS

E pronto! Acessando novamente o bucket S3 através do seu domínio customizado, vemos o deploy realizado com sucesso.

Bônus

Restrição por Código de Repositório

Sim, nós já aplicamos isso no nosso passo a passo quando editamos a política de relação de confiança, mas inseri novamente aqui para reforçar a estrutura para você.

Restrição por Endereço IP

Para aumentar a segurança, podemos restringir um pouco mais o acesso à função permitindo apenas endereços IP do Bitbucket Pipelines e determinados UUIDs de repositório. Desta forma, outros repositórios não podem acessar essa função, exceto os repositórios especificados dos IPs descritos:

Melhore suas permissões com Assume Role

Vimos até aqui tudo funcionando, mas se observamos com um pouco mais de atenção, vamos notar que as permissões estão anexadas diretamente a Role OIDC que criamos:

Em nosso exemplo prático isso significa que as políticas:

• oidc_bitbucket_policy

• s3-bucket-tutorial-bitbucket-oidc-aws.simplescloud.io-policy

Foram anexadas diretamente na role

• deploy-tutorial-bitbucket-oidc-aws.simplescloud.io-role-prod

O fluxo se parece com:

1. Bitbucket se comunica com o provedor de identidade AWS através da Role OIDC

2. A AWS retorna as credenciais temporárias para o Bitbucket

3. O Bitbucket Pipelines agora obtém as permissões das políticas anexadas diretamente da Role OIDC e pode acessar seus respectivos recursos

Embora isso já seja uma grande melhoria, ainda há uma boa prática de segurança que seria não anexar as políticas de permissões diretamente em um usuário ou em uma role, mas sim criar uma role para o ambiente de deploy do aplicativo e anexar as permissões nessa role, então quando for de fato fazer essa implantação, acontecerá o seguinte fluxo:

1. Bitbucket se comunica com o provedor de identidade AWS através da Role OIDC

2. AWS retorna as credenciais temporárias para o Bitbucket

3. O Bitbucket Pipelines agora não tem as permissões para acessar os respectivos recursos, pois nenhuma política foi anexada diretamente nesta Role OIDC

4. Mas esta Role OIDC tem permissão para assumir uma segunda role de deploy que contém as permissões de acesso aos respectivos recursos

5. A Role OIDC assume a Role de deploy e obtém as permissões para os respectivos recursos

Desta forma, note que foi criada uma camada adicional de segurança, pois as permissões estão em uma segunda role assumida.

Não vou me estender mais nesse assunto para não tornar o artigo maior do que já é, mas se tiver dúvidas, talvez seja interessante dar uma olhada em nesta explicação aqui:

• 👉 Assume Role - Assumindo Permissões

Com isso compreendido, imagine agora que não estamos mais fazendo um deploy para um site estático no bucket S3 como nosso exemplo prático, mas imagine então que agora queremos fazer um deploy para um container do Lightsail, para aplicar isso então poderíamos ter por exemplo:

• Uma Role para o OpenID Connect (OIDC) chamada oidc-bitbucket-role

  • E anexar a política oidc_bitbucket_policy

  •         {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Sid": "VisualEditor0",
                        "Effect": "Allow",
                        "Action": [
                            "sts:AssumeRole",
                            "sts:GetCallerIdentity",
                            "sts:AssumeRoleWithWebIdentity"
                        ],
                        "Resource": "*"
                    }
                ]
            }
    

    E lembrando novamente para editar a aba Trust Relationships com seus valores reais da sua conta AWS e Bitbucket

  •         {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": {
                            "Federated": "arn:aws:iam::<your-account-id>:oidc-provider/api.bitbucket.org/2.0/workspaces/<your-bitbucket-workspace>/pipelines-config/identity/oidc"
                        },
                        "Action": "sts:AssumeRoleWithWebIdentity",
                        "Condition": {
                            "StringLike": {
                                "api.bitbucket.org/2.0/workspaces/<your-bitbucket-workspace>/pipelines-config/identity/oidc:sub": "{<your-bitbucket-repo-uuid>}:*"
                            }
                        }
                    }
                ]
            }
    

    

• Criar uma outra Role para o Deploy chamada myapp-deploy-prod-role

  • E anexar a política com acesso ao respectivo recurso, por exemplo uma política que permite ações no Lightsail

  • A dica aqui é editar a aba Trust Relationships permitindo a Role OIDC a assumir essa Role e obter as permissões anexadas a ela, no nosso exemplo permissões para o Lightsail. (Lembre-se de alterar para os valores reais da sua conta AWS)

  •         {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Sid": "",
                        "Effect": "Allow",
                        "Principal": {
                            "AWS": "arn:aws:iam::<your-account-id>:role/oidc-bitbucket-role"
                        },
                        "Action": "sts:AssumeRole"
                    }
                ]
            }
    

Pronto! Agora poderíamos criar um arquivo bitbucket-pipelines.yml que faz deploy com o processo do OpenID Connect e do Assume Role, veja como ficaria isso com esse trecho abaixo:

definitions:

  scripts:

    # Commands to install AWS CLI V2
    install_aws_cli: &install_aws_cli
      echo "========== Install AWS CLI V2 ==========" &&
      curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" &&
      unzip awscliv2.zip &&
      ./aws/install &&
      aws --version

    # Commands to install the Lightsail plugin in AWS CLI V2
    install_lightsail_cli_plugin: &install_lightsail_cli_plugin
      echo "===== Install AWS Lightsail CLI Plugin =====" &&
      curl https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-amd64/lightsailctl -o /usr/local/bin/lightsailctl &&
      chmod +x /usr/local/bin/lightsailctl

    # Commands to obtain temporary access keys for the 
    # aws role that authenticates through OpenID Connect
    auth_oidc: &auth_oidc
      echo "========== Bitbucket OIDC Assume Role ==========" && 
      export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $(aws sts assume-role-with-web-identity --role-arn "$AWS_OIDC_ROLE_ARN" --role-session-name "Bitbucket-OIDC-$BITBUCKET_DEPLOYMENT_ENVIRONMENT-$BITBUCKET_BUILD_NUMBER" --web-identity-token "$BITBUCKET_STEP_OIDC_TOKEN" --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' --output text))

    # Commands to assume another deploy role with 
    # permissions and obtain your temporary credentials
    aws_sts_assume_role: &aws_sts_assume_role
      echo "========== AWS CLI Assume Role ==========" &&
      STS_TEMP_CREDS=$(aws sts assume-role --region "$AWS_REGION" --role-arn "$AWS_DEPLOY_ROLE_ARN" --role-session-name "Bitbucket-Deploy-$BITBUCKET_DEPLOYMENT_ENVIRONMENT-$BITBUCKET_BUILD_NUMBER") &&
      export AWS_ACCESS_KEY_ID=$(echo $STS_TEMP_CREDS | jq -r .Credentials.AccessKeyId) &&
      export AWS_SECRET_ACCESS_KEY=$(echo $STS_TEMP_CREDS | jq -r .Credentials.SecretAccessKey) &&
      export AWS_SESSION_TOKEN=$(echo $STS_TEMP_CREDS | jq -r .Credentials.SessionToken) &&
      export AWS_SESSION_EXPIRATION=$(echo $STS_TEMP_CREDS | jq -r .Credentials.Expiration) &&
      aws sts get-caller-identity

Novamente não se preocupe senão entender esse arquivo ou os comandos, esse não é o foco deste artigo, a única coisa importante para observar é que há duas variáveis de ambiente importantes:

• AWS_OIDC_ROLE_ARN: esse é o ARN da Role OpenID Connect (OIDC) que criamos, ou seja em nosso exemplo seria o ARN de oidc-bitbucket-role que não possui nenhuma política anexada além de oidc_bitbucket_policy

• AWS_DEPLOY_ROLE_ARN: esse é o ARN da Role de Deploy que criamos, ou seja em nosso exemplo seria o ARN de myapp-deploy-prod-role e este sim possui a política que permite acesso aos recursos do Lightsail no nosso exemplo

Então o fluxo que está acontecendo é:

1. O primeiro trecho auth_oidc está solicitando ao provedor de identidade AWS através do OpenID Connect (OIDC), retornando as credenciais de acesso temporário para o Bitbucket e exportando esses valores em variáveis de ambiente

2. O segundo trecho aws_sts_assume_role está assumindo a Role myapp-deploy-prod-role e obtendo suas próprias credenciais de acesso temporário

E voltando os olhos para o Bitbucket Pipelines, podemos verificar ele executado com sucesso:

Conclusão

Vimos neste artigo um tutorial completo sobre OpenID Connect (OIDC) entre o Bitbucket e AWS, passamos pelas vantagens e demonstramos um exemplo prático.

O exemplo passou por várias etapas, em resumo nós criamos um provedor de identidade (IdP) na AWS para o Bitbucket, depois nós criamos políticas de permissões restritas aos recursos que usamos, então criamos uma role e anexamos essas políticas, ainda em roles editamos a relação de confiança para o número de id do repositório do Bitbucket, em geral essas são as etapas principais e em resumo o OIDC é configurado mesmo entre as etapas 7 a 10, porém todas as outras etapas foram escritas para exemplificar melhor.

O exemplo prático apresentado ainda pode ter muitas melhorias, como por exemplo adicionar uma distribuição Cloudfront para obter um HTTPS e adicionar no pipeline uma invalidação de cache por exemplo, embora os passos envolvam muitas coisas como comandos do git e arquivos de configuração de pipeline, o objetivo não era explicar isso, mas sim sobre o OIDC exclusivamente.

Uma vez que esse conceito e essa lógica foi entendida, o provedor de identidade (IdP) criado, a configuração do OIDC foi feita e a única coisa que você precisa fazer dai em diante é criar políticas e roles novas com a relação de confiança editada para o repositório, você não precisa criar um provedor de identidade (IdP) para cada projeto.

Por exemplo se você criar um novo repositório e quer fazer o deploy em um container do Fargate, você só precisaria criar uma política com permissões para o ECR e o ECS, por fim criar uma nova role com a relação de confiança editada para o UUID do repositório e com essas permissões anexadas, mas não precisaria criar novamente o provedor de identidade (IdP), pois ela já foi criada e precisa ser criada uma única vez.

Desta forma o Bitbucket poderá acessar sua variável de ambiente com o ARN da role criada e ela poderá obter chaves temporárias de acesso com sucesso com as permissões adequadas anexadas a ela.

Se preferir avançar ainda mais, você viu que é possível criar uma segunda role para o deploy e anexar as permissões nela, fazendo com que a role OIDC assuma as permissões da segunda role.

Se você utiliza o AWS Fargate como carga de trabalho para as suas aplicações, mais cedo ou mais tarde sentirá a necessidade de realizar um acesso SSH nos conteiners do Fargate para solucionar algum problema, fazer alguma depuração ou simplesmente testar algumas conexões e verificar alguns arquivos de configuração.

Se você usa o Lightsail Container, infelizmente descobrirá que não é possível fazer um acesso SSH nele, e por um tempo no Fargate também não era, porém agora é possível e vou descrever o passo a passo de como fiz isso.

Então se você está nessa situação e chegou até este artigo, ele é feito para você.

Etapa 1 - Instalar o AWS CLI

O primeiro passo é você instalar e configurar o AWS CLI V2 em sua máquina, se você estiver usando o Linux x86 por exemplo, pode instalar com o comando:

curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Se houver dúvidas sobre essa instalação e configuração, você pode consultar nosso outro artigo que explica por completo como fazer isso:

• 👉 AWS CLI - Instalação e Configuração

Ou ainda pode verificar diretamente na documentação da AWS se estiver usando um Sistema Operacional diferente:

• 👉 AWS CLI - Documentação Oficial

Etapa 2 - Instalar o Session Manager Plugin

Se você estiver usando o Linux x86 por exemplo, execute este comando:

curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "session-manager-plugin.rpm"
sudo yum install -y session-manager-plugin.rpm

Se houver dúvidas ou se estiver usando um outro Sistema Operacional, verifique a documentação oficial da AWS:

• 👉 Session Manager plugin para AWS CLI

Etapa 3 - Configure as Permissões

Crie uma Política IAM

1- Acesse o console AWS → IAM → Policies → Create Policy e defina o nome como por exemplo ECSFargateAllowExecuteCommand → insira o código json em sua política:

{
    "Statement": [
        {
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

Anexe a Role Adequada

1- Ainda no console AWS → IAM alterne de Policies para Roles e pesquise por ecsTaskExecutionRole → ao final, você deve obter uma tela parecida com:

Etapa 4 - Colete Informações para o Acesso

O comando AWS CLI ecs execute-command requer 3 parâmetros:

• O nome do cluster do ECS

• O ID da tarefa do ECS

• O nome do container

Então acesse o console AWS → ECS e anote as informações, por exemplo:

Etapa 5 - Faça o Acesso SSH no Container do Fargate

1- Execute o comando:

aws ecs execute-command \
--region <your-region> \
--cluster <your-ecs-cluster-name> \
--task <your-task-id> \
--container <your-container-name> \
--command "/bin/bash" \
--interactive

Etapa 6 (Opcional) - Bônus

Habilite o Serviço do Fargate para Acesso SSH

Se você estiver tentando acessar por SSH um ID de tarefa que está sendo gerenciada por um serviço do Fargate, poderá receber a seguinte mensagem de erro:

Isso acontece porque antes precisamos habilitar o serviço do Fargate para que suas tasks permitam o acesso SSH, então digite o comando:

aws ecs update-service \
--cluster <your-ecs-cluster-name> \
--service <your-ecs-service-name> \
--region <your-region> \
--enable-execute-command \
--force-new-deployment

Após isso é só repetir o mesmo comando da Etapa 5 e realizar o acesso SSH.

Conclusão

Vimos passo a passo como acessar através de SSH uma task do AWS Fargate, isso pode ser muito útil para soluções de problemas, por exemplo você pode querer testar a conexão da task do Fargate com o banco de dados RDS para garantir que não há problemas de conexão:

Ou imagine ainda que o deploy de um aplicativo construído em .Net Core nos containers do Fargate são realizados através de um pipeline CI/CD, e que o arquivo appsettings.json possui variáveis de ambiente por questões de segurança e muda os valores de acordo com o ambiente que está sendo implantado como production, qa, etc. Então você quer verificar se esses valores foram alterados corretamente:

Por fim, isso pode ser muito útil no seu dia a dia.

Quando comecei a usar mais a AWS, é comum criar cada vez mais grupos de segurança e com o tempo manter todos eles organizados acaba sendo tedioso, pois você observará que precisará atualizar com uma certa frequência cada grupo de segurança.

Para contextualizar melhor, imagine o seguinte cenário de exemplo:

• Uma equipe de desenvolvedores solicita para você a criação de um novo servidor web no Windows com IIS instalado, então você prontamente cria uma instância EC2 com um novo grupo de segurança chamado "SG-web-app1".

• Agora a mesma equipe de desenvolvedores solicita para você a criação de um outro servidor Windows com um novo serviço do Windows instalado, então você prontamente cria uma outra instância EC2 e prefere não utilizar o mesmo grupo de segurança, pois você é organizado e prefere criar um outro grupo de segurança com nome diferente que distingue melhor "SG-services-app1"

• Então em cada grupo de segurança você adiciona o IP de cada desenvolvedor para o protocolo RDP e permite que eles possam acessar remotamente cada instância, isso se pareceria por exemplo com:

Observe na tabela que você tem 2 IPs diferentes de 2 desenvolvedores diferentes em 2 grupos de seguranças diferentes e aí que todo o problema começa.

Cada desenvolvedor possui um IP dinâmico e não fixo, isso na prática significa que o IP que eles recebem do provedor de internet deles mudam frequentemente.

Então eles começam a enviar para você que perderam o acesso remoto, isso acontece porque o IP real e atual deles não é o mesmo que você liberou no grupo de segurança inicialmente.

Você então solicita o novo IP para eles e então atualiza cada grupo de segurança e o problema é resolvido.

Mas será que está resolvido mesmo? A resposta curta é sim. Mas comece a multiplicar essa situação para mais pessoas na equipe e para mais grupos de segurança e você passará muito tempo lembrando, organizando e atualizando esses grupos de segurança.

Se você está em uma situação semelhante, compartilho a solução que encontrei para reduzir essa complexidade usando o VPC Prefix List.

VPC Prefix List

A lista de prefixo da AWS é um recurso que existe já algum tempo e existem 2 tipos:

1. Lista de prefixos gerenciadas pela AWS:

   Como o nome indica, essas listas são gerenciadas pela AWS e são usadas para manter um conjunto de intervalos de endereços IP para serviços da AWS como o S3, DynamoDB e CloudFront.

2. Listas de prefixos gerenciadas pelo cliente:

   São criadas e mantidas por qualquer pessoa que tenha acesso ao Console AWS, as APIs da AWS ou aos SDKs da AWS. É nisso que nos concentraremos.

A lista de prefixo gerenciados pelo cliente da AWS VPC é uma ótima ferramenta disponível, pois fornece a capacidade de rastrear e manter uma lista de valores de bloco CIDR, que podem então ser referenciados por outros componentes de rede da AWS em suas regras.

Como criar um VPC Prefix List

1- Acesse a console AWS → VPC → Managed Prefix Lists

2- Clique em Create Prefix List

Para isso, atente-se as seguintes regras:

• Você deve escolher o tipo de família como IPv4 ou IPv6 e a quantidade máxima de IPs que poderá ter essa lista. E esses valores não podem ser alterados depois.

• Um grupo de segurança possui um limite de 60 regras

  • Cada entrada da sua lista consumirá uma regra do grupo de segurança

  • Por exemplo se sua lista de prefixo tiver 20 endereços IPs, isso consumirá 20 das 60 regras que o grupo de segurança pode ter

  • Então obviamente você não pode adicionar mais do que 60 IPs nessa lista, pois atingirá a cota limite do grupo de segurança e não dará certo

• Na prática isso significa, que ao adicionar no grupo de segurança uma lista de prefixo, mesmo que seja uma regra, na verdade a lista expandirá pela quantidade de IPs da lista e consumirá do seu limite no grupo de segurança

• A única exceção é que digamos que você tenha uma lista de prefixo IPv4 com 60 IPs e outra lista de prefixo IPv6 com outros 60 IPs, então você adiciona essas duas regras no grupo de segurança e irá ter então 120 IPs como total, isso iria funcionar porque a cota do grupo de segurança é imposta separadamente para IPv4 e IPv6

• O mesmo não se aplica por exemplo se você adicionar no grupo de segurança 2 listas de prefixos IPv4 com 60 IPs cada, isso daria um total de 120 IPs IPv4 e ultrapassaria a cota de 60 regras do grupo de segurança

• Para nosso exemplo, defini um limite de 20 entradas, isso dá uma margem para usar outras regras no grupo de segurança no futuro se for necessário

• E lembre-se de adicionar /32 ao final do IP que algum desenvolvedor te passar, pois esse é o formato correto do CIDR aqui.

Como configurar o Grupo de Segurança

1- Uma vez criado, você verá ela juntamente com as listas de prefixos gerenciados pela AWS:

2- Agora acesse o grupo de segurança e adicione a regra de entrada com o ID da lista de prefixo

Para manter ainda mais organizado, costumo criar o grupo de segurança com o nome SG-<name>-team-rdp-<env>, por exemplo SG-simplescloud-team-rdp-qa e sua regra de entrada ficaria parecido com a imagem acima.

Então o que está acontecendo na prática é que:

• As instâncias EC2 web-app1 e services-app1 do nosso exemplo, agora terão esse grupo de segurança adicional SG-<name>-team-rdp-<env> anexados nas instâncias e permitirá o acesso remoto para os IPs que serão consultados na lista de prefixo criada. Por exemplo a instância "web-app1" teria dois grupos de segurança anexados:

• Desta forma, sua instância terá grupos de segurança dedicados pelos protocolos que as regras permitem, evitando aqueles grupos de segurança "launch-wizard" que possui todas regras misturadas de HTTP, HTTPS, RDP, MSSQL, etc. Facilitando assim a administração a longo prazo

• Desta forma ainda, os desenvolvedores ainda sim precisarão fornecer para você seus respectivos IPs dinâmicos atualizados, a grande diferença agora é que você não precisará mais entrar em cada grupo de segurança e ir atualizando, atualizará apenas a lista de prefixo em um único lugar e isso será replicado para todos os grupos de segurança que fizer referência a ela

• Diminuindo muito então a sobrecarga de administração e organização dos grupos de segurança.

Se ainda não estiver convencido dos benefícios, passamos por mais um exemplo:

Imagine que você tenha os IPs repetidos nos grupos de segurança X, Y e Z:

Aplicando essa solução, isso poderia ser modificado por:

Observe então que não será mais necessário entrar em cada grupo de segurança para atualizar, uma vez que você atualizar a lista de prefixo centralmente, isso será aplicado automaticamente para todos os grupos de segurança que fazem referência para essa lista de prefixo em suas regras.

Conclusão

Administrar e organizar os grupos de segurança da AWS é uma tarefa importante relacionada a segurança, porém ela pode ser tediosa e trabalhosa ao longo do tempo. Seu tempo é valioso demais para ficar perdendo tempo com esse tipo de tarefa, então compartilhei uma solução com VPC Prefix List para reduzir drasticamente as atualizações diretamente nos grupos de segurança e então manter as coisas organizadas com o menor esforço possível.

Um cliente utiliza o AWS QuickSight como seu dashboard para apresentar visualmente alguns dados e informações através de gráficos. Então é comum enviarem um email de convite de acesso para este dashboard através do console AWS, porém o problema está nesta etapa, esses emails de convite do AWS QuickSight demoram para chegar ou nem sempre são recebidos pelo destinatário e é importante dizer que o problema não está no envio por parte da AWS, pois possuem uma taxa de entrega confiável.

Há várias possíveis causas para isso, mas o mais provável é que os servidores de emails das empresas que recebem esses convites, por acaso, estejam bloqueando o recebimento deste email por alguma política interna de segurança ou de spam.

Este fluxo se parece desta forma:

• No console do AWS QuickSigh → clique no botão Convidar Usuários

• 

  Insira os emails que deseja convidar → clique no botão +

• Defina o nível de acesso, no caso como Leitor → clique em Convidar

Isso parece ser muito fácil (e realmente é), além disso funciona quase que toda vez, mas este artigo é para demonstrar uma alternativa para se você estiver na mesma situação que me encontrei, ou seja, mesmo fazendo isso o destinatário reporta que não recebe os emails de convite enviados pela AWS.

Se você chegou até aqui e está nessa situação, este artigo é para você, compartilho abaixo uma alternativa para cobrir isso.

Solução

1- Faça login no console AWS → clique no botão Cloudshell

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "quicksight:CreateReader",
                "cloudshell:*",
                "quicksight:CreateUser",
                "quicksight:DeleteUser",
                "quicksight:ListUserGroups",
                "quicksight:DescribeUser",
                "quicksight:CreateAdmin",
                "quicksight:ListUsers",
                "quicksight:UpdateUser",
                "quicksight:RegisterUser",
                "quicksight:SearchUsers"
            ],
            "Resource": "*"
        }
    ]
}

Uma vez que você tenha feito login no console AWS, clicado no Cloudshell e seu usuário já possui as permissões discutidas acima, você deve estar vendo uma tela parecida com esta e pronto para seguirmos ao próximo passo:

2- Digite o comando:

aws quicksight register-user \
--aws-account-id <your-id> \
--identity-type QUICKSIGHT \
--email <recipient-email> \
--user-role READER \
--namespace default \
--user-name <recipient-email>

Por exemplo:

aws quicksight register-user \
--aws-account-id 111111111111 \
--identity-type QUICKSIGHT \
--email user1-test@simplescloud.io \
--user-role READER \
--namespace default \
--user-name user1-test@simplescloud.io

Se você fez isso, deverá obter uma resposta do seu comando parecido com essa tela:

Por questões de confidencialidade, ocultamos algumas informações do print acima, mas o que importa para nós é a parte final com o link, copie este link.

E isso é tudo, você agora pode compartilhar esse link com o destinatário da forma que achar melhor, sem depender do recebimento do email que enviaria esse mesmo link (que é a origem do problema que discutimos no início).

Apenas para demonstrar, o destinatário então veria algo parecido com isso ao acessar o link que você compartilhou com ele:

Conclusão

AWS QuickSight é uma excelente ferramenta para dashboards e convidar usuários para acessarem é relativamente fácil e simples, porém em alguns momentos isso pode ser frustrante se os convites nunca chegarem no email do destinatário.

Então compartilhei uma solução alternativa criando uma política IAM com permissões granulares necessárias para convidar um usuário sem acesso total ao QuickSight, demonstramos ainda como executar um comando no Cloudshell e gerar o link para compartilhar ao destinatário de outras formas.

Recentemente recebi um projeto para reiniciar uma instância EC2 todos os dias em um horário específico automaticamente. Havia uma premissa de não ter a necessidade de acesso ssh para configurações de scripts e crontab para minimizar um possível erro ou esquecimento no futuro.

Então aqui está o passo a passo que fiz para atingir esse objetivo, vamos lá!

ETAPA 1 - Permissões

1- Acesse o IAM → Policy → alterne para a aba JSON

Defina o nome como “ec2_reboot_instances_policy” → altere no bloco “Resource” para os IDs das instâncias reais para seu cenário

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:RebootInstances",
                "ec2:TerminateInstances",
                "ec2:StopInstances"
            ],
            "Resource": [
                "arn:aws:ec2:us-east-1:xxxxxxxxxxxx:instance/i-xxxxxxxxxxxx",
                "arn:aws:ec2:us-east-1:xxxxxxxxxxxx:instance/i-xxxxxxxxxxxx"
            ]
        }
    ]
}

2- Acesse o IAM → Role → selecione AWS Service → em Use cases for other AWS services → selecione CloudWatch Events

Defina o nome como “ec2_reboot_instances_role” → adicione a política criada no passo anterior → clique na aba Trust Relationships

Verifique se está igual o código abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

ETAPA 2 - CloudWatch Events

1- Acesse o CloudWatch → Events → Rules

2- Clique em Create Rule

3- Defina o nome da regra como “EC2_instance_reboot” por exemplo → alterne para Schedule → clique em Continue to create rule

4- Defina sua expressão cron como por exemplo 0 7 * * ? * (isso irá definir o cron para todos os dias as 7 horas UTC ou 4 horas em Brasília)

5- Selecione em Target a opção EC2 RebootInstances API Call → insira o ID da instância EC2 que deseja reiniciar → escolha Use execution role criada no primeiro passo

6- Repita o passo anterior para mais instâncias que precisar clicando no botão Add Another Target

CONCLUSÃO

Criamos uma solução para reiniciar automaticamente instâncias EC2 sem a necessidade de acessar ssh ou fazer qualquer configuração dentro da instância, minimizando qualquer problema, desta forma nosso CloudWatch Events possui um agendamento, e então no momento definido invocará a API necessária para reiniciar a instância EC2. Além disso essa é uma solução barata.

Recentemente recebi um projeto para reiniciar uma instância Lightsail todos os dias em um horário específico automaticamente. Essa instância Lightsail era uma pilha otimizada de WordPress de um site que recebia um alto tráfego de visitas, e por um motivo não relevante para este artigo, quando essa instância ficava muito tempo ligada, alguns problemas e lentidões aconteciam, porém um simples clique no botão reboot resolvia todos os problemas.

Embora haja outras abordagens que poderiam resolver esse problema, esse cliente em específico gostaria de manter as coisas simples, tão simples como apenas reiniciar essa instância Lightsail, nada além disso, isso era o suficiente, porém deveria ser de forma automática. Ainda esse projeto exigia como premissa não termos que acessar a instância através de ssh e realizar configurações como scripts ou crontab, preferencialmente deveríamos criar uma solução fora da caixa para que isso fosse feito sem qualquer acesso na instância.

Então aqui está o passo a passo que fiz para atingir esse objetivo, note que citei esse caso de uso real do site WordPress, mas isso pode ser aplicado para toda e qualquer instância Lightsail que você deseja reiniciar automaticamente, independentemente dos seus motivos.

Então vamos lá!

ETAPA 1 - Permissões

1- Acesse o IAM → Policy → alterne para a aba JSON

Defina o nome como “lightsail_reboot_policy”

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "lightsail:RebootInstance",
            "Resource": "*"
        }
    ]
}

2- Acesse o IAM → Role → selecione AWS Service e Lambda

Defina o nome como “lightsail_reboot_role” → adicione a política criada no passo anterior → clique na aba Trust Relationships

Verifique se está igual o código abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

ETAPA 2 - Função Lambda

1- Acesse o Lambda (author from scratch) → crie uma função com:

• Function Name:lightsail_reboot

• Runtime:Pyhton 3.9

• Architecture:x86_64

• Expanda a opção “Change default execution role” → Use existing role → selecione a role criada no passo anterior

import json
import boto3

def lambda_handler(event, context):
    client = boto3.client("lightsail", region_name="us-east-1")
    response = client.reboot_instance(instanceName="EXAMPLE")

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "Lightsail instance restarted successfully!"
        })
    }

ETAPA 3 - CloudWatch Events Rules

1- Acesse o Cloudwatch → Events → Rules → Create Rule → defina o nome “Site_Reboot” por exemplo ou qualquer outro nome que faça sentido para você

Defina sua expressão cron, por exemplo:

Cron express:0 7 * * ? * → expressão cron diária as 7 horas UTC e 4 horas no horário de Brasília.

Ou qualquer horário de sua preferência e que faça sentido para seu cenário

2- Em Target → selecione a função Lambda criada anteriormente

Bônus

As vezes em seu cenário pode ser que as instâncias Lightsail possuem um prefixo no nome, ou seja você em algum momento adotou um padrão de nomenclatura e suas instâncias começam sempre com um prefixo, por exemplo por SC-instance1, SC-instance2, etc.

Se esse for o caso, tudo que vimos acima ainda funcionará para você, mas se você está se perguntando se terá que criar uma função e uma regra para cada uma então a resposta curta é não.

Opção 1 - Use prefixos e reinicie várias instâncias ao mesmo tempo

Para esse cenário, mude o código da sua função Lambda para:

import json
import boto3

def lambda_handler(event, context):
    # Lightsail Configuration
    lightsail_client = boto3.client("lightsail", region_name="us-west-2")

    # Prefix to search for instances
    prefix = 'your-prefix'

    # List all instances
    response = lightsail_client.get_instances()

    # List of instance names to be restarted
    instance_names = []

    # Filter and add instances that begin with the prefix to the list
    for instance in response["instances"]:
        if instance["name"].startswith(prefix):
            instance_names.append(instance["name"])

    responses = {}  # Dictionary to store restart responses

    # Loop through the list of names and restart each instance
    for instance_name in instance_names:
        response = lightsail_client.reboot_instance(
            instanceName=instance_name
        )
        responses[instance_name] = response

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "Successfully restarted instances"
        })
    }

Opção 2 - Envie um email também com AWS SES

Para esse cenário, mude o código da sua função Lambda para:

import json
import boto3

def send_email(subject, body, recipient):
    ses = boto3.client('ses', region_name='us-west-2')
    response = ses.send_email(
        Source='your-email@example.com    ', 
        Destination={
            'ToAddresses': [recipient]
        },
        Message={
            'Subject': {
                'Data': subject
            },
            'Body': {
                'Text': {
                    'Data': body
                }
            }
        }
    )

def lambda_handler(event, context):
    # Lightsail Configuration
    lightsail_client = boto3.client("lightsail", region_name="us-west-2")

    # Prefix to search for instances
    prefix = 'your-prefix'

    # List all instances
    response = lightsail_client.get_instances()

    # List of instance names to be restarted
    instance_names = []

    # Filter and add instances that begin with the prefix to the list
    for instance in response["instances"]:
        if instance["name"].startswith(prefix):
            instance_names.append(instance["name"])

    responses = {}  # Dictionary to store restart responses

    # Loop through the list of names and restart each instance
    for instance_name in instance_names:
        response = lightsail_client.reboot_instance(
            instanceName=instance_name
        )
        responses[instance_name] = response

    # Send notification email
    subject = 'Lightsail - Restarted Instances'
    body = 'Lightsail instances were successfully restarted by lambda.'
    recipient = 'other-email@example.com'

   send_email(subject, body, recipient)

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "Instances restarted and email sent successfully"
        })
    }

CONCLUSÃO

Criamos uma solução para reiniciar automaticamente instâncias Lightsail sem a necessidade de acessar ssh ou fazer qualquer configuração dentro da instância, minimizando qualquer problema, desta forma nosso Cloudwatch Event Rules possui um agendamento, e então no momento definido invocará nossa função lambda que possui permissões necessárias para reiniciar a instância Lightsail.

Além disso essa é uma solução barata, pois Cloudwatch Event Rules e Lambda possuem bons níveis gratuitos, por exemplo o Lambda possui até um milhão de requisições gratuitas por mês.

AWS

Introdução

Personalizar seu ambiente de desenvolvimento é uma jornada única para cada pessoa. É aquele toque especial que torna as longas horas de código mais agradáveis e produtivas. E é exatamente sobre isso que vamos conversar hoje!

Vou guiá-lo através da minha experiência pessoal de customização do VSCode, compartilhando cada passo e configuração que implementei para criar um ambiente que funciona perfeitamente para mim. Mas lembre-se: isso é apenas um ponto de partida, um mapa que você pode usar para explorar suas próprias preferências.

Afinal, não existe certo ou errado quando falamos de personalização - o que importa é criar um ambiente que reflita seu estilo e otimize seu fluxo de trabalho. Seja nas escolhas de temas, extensões, atalhos de teclado ou configurações do editor, você terá total liberdade para adaptar essas sugestões ao seu gosto.

E para facilitar ainda mais sua jornada, ao final deste artigo, compartilharei meus arquivos de configuração completos do VSCode, incluindo minhas extensões favoritas e seus ajustes. Assim, você poderá usá-los como referência ou ponto de partida para criar seu próprio ambiente de desenvolvimento único e personalizado.

Vamos começar?

O que é VSCode?

O Visual Studio Code (VSCode) é um editor de código aberto desenvolvido pela Microsoft, atualmente ele é um dos editores de código mais utilizados no mundo.

Não confunda VSCode com o Visual Studio

O Visual Studio é uma IDE desenvolvida pela Microsoft, dedicada ao .NET Framework e a linguagens como C, C++, C# e F#. Por ser uma solução completa, é uma ferramenta bem mais pesada. Já o VSCode é um editor de código poderoso com vários plugins disponíveis.

Instalando o VSCode

1- Faça o download do Visual Studio Code no site oficial da Microsoft:

• 👉 https://code.visualstudio.com/download

E siga com a instalação Próximo → Próximo → Concluir para essa pasta criada

Instalando Plugins Locais

Remote Development

Pacote que acompanha três plugins:

• Remote WSL

• Remote SSH

• Remote Container

Útil e obrigatório para permitir que você use um ambiente de desenvolvimento completo com containers e WSL2.

1- Em seu VSCode → clique em Extensões → digite remote development → clique em Instalar

Material Icon

Útil para tornar os ícones em geral mais agradáveis.

1- Em seu VSCode → clique em Extensões → digite material icon → clique em Instalar

Instalando o VSCode no WSL2

1- Abra seu VSCode → clique no ícone verde >< (canto inferior esquerdo) → escolha a opção Usando um distro existente → selecione a distro e aguarde a instalação ser concluída

Instalando Plugins no WSL2

Docker

Útil para criar e gerenciar imagens e containers Docker, também pode ajudar a criar o Dockerfile.

1- Em seu VSCode → clique em Extensões → digite docker → clique em Instalar

Hashicorp Terraform

Hashicorp Terraform é uma ferramenta incrível de Infra As Code, esse plugin ajudará em sua sintaxe.

1- Em seu VSCode → clique em Extensões → digite hashicorp terraform → clique em Instalar

OpenTofu

OpenTofu é uma ferramenta incrível de Infra As Code, baseado e inspirado no Terraform, é um fork do Terraform desde sua mudança de licenciamento, tornando-o um projeto open source. Esse plugin ajudará em sua sintaxe.

1- Em seu VSCode → clique em Extensões → digite opentofu → clique em Instalar

Kubernetes

Útil para criar e gerenciar containers com Kubernetes, também pode ajudar nas sintaxes dos arquivos de configurações.

1- Em seu VSCode → clique em Extensões → digite kubernetes → clique em Instalar

YAML

Útil para verificar as sintaxes deste tipo de arquivo.

1- Em seu VSCode → clique em Extensões → digite yaml → clique em Instalar

Instalando Tema

codeSTACKr Theme

Há muitos temas por aí, mas particularmente me adaptei bem com esse excelente tema criado, suas cores padrões já fazem todo o trabalho, apenas fiz poucos ajustes nas cores que compartilho em meu arquivo settings.json no final deste artigo.

1- Em seu VSCode → clique em Extensões → digite codestack → clique em Instalar

Night Owl Theme

Outro tema que gosto bastante de usar é o Night Owl, suas cores padrões já fazem todo o trabalho, apenas fiz poucos ajustes nas cores que compartilho em meu arquivo settings.json no final deste artigo.

1- Em seu VSCode → clique em Extensões → digite Night Owl → clique em Instalar

Meu arquivo settings.json

Compartilho meu arquivo settings.json para se por acaso você queira usar o VSCode exatamente como eu, basta copiar e colar. Além de ser uma forma que posso consultar aqui para sempre restaurar quando eu precisar.

1- Abra o VSCode → aperte F1 no teclado → Preferences Open User Settings (JSON)

2- Copie e cole o conteúdo abaixo e salve seu arquivo

⚠️ Importante: Ao aplicar estas configurações no VSCode, você precisará adaptar alguns campos específicos para o seu ambiente de desenvolvimento:

• terminal.integrated.defaultProfile: Define qual terminal será iniciado automaticamente

• workbench.colorCustomizations: Permite personalizar as cores da sua interface

• editor.fontFamily: Especifica qual fonte será utilizada no editor

Abaixo você encontrará um exemplo completo dessas configurações, que serve como um ponto de partida para sua personalização. Sinta-se à vontade para ajustar cada campo de acordo com suas preferências e necessidades de desenvolvimento.

// SimplesCloud VSCode settings.json

{

    // Integrated Terminal Settings
    "terminal.integrated.defaultProfile.linux": "zsh",
    "terminal.integrated.defaultLocation": "editor",
    "terminal.integrated.fontSize": 16,
    "terminal.integrated.fontFamily": "SauceCodePro Nerd Font",

    // Theme and Appearance
    "workbench.colorTheme": "Night Owl",
    "workbench.iconTheme": "material-icon-theme",
    "workbench.startupEditor": "none",

    // Color Customization
    "workbench.colorCustomizations": {
        // VSCode Interface
        "editorLineNumber.activeForeground": "#49E287",
        "statusBarItem.remoteBackground": "#000000",
        "statusBarItem.remoteForeground": "#49E287",
        "menu.selectionBackground": "#000000",
        "menu.selectionForeground": "#49E287",
        "tab.activeBorder": "#49E287",
        "list.highlightForeground": "#FFE400",
        "list.activeSelectionBackground": "#000000",
        "list.activeSelectionForeground": "#49E287",
        "focusBorder": "#49E287",

        // Notifications
        "notifications.background": "#000000",
        "notifications.foreground": "#49E287",
        "notificationLink.foreground": "#49E287",
        "notificationsInfoIcon.foreground": "#49E287",

        // Terminal Colors
        "terminal.background": "#011627",
        "terminal.foreground": "#dddad6",
        "terminal.ansiBlack": "#011627",
        "terminal.ansiBrightBlack": "#575656",
        "terminal.ansiBrightBlue": "#82AAFF",
        "terminal.ansiBrightCyan": "#7FDBCA",
        "terminal.ansiBrightGreen": "#22DA6E",
        "terminal.ansiBrightPurple": "#C792EA",
        "terminal.ansiBrightRed": "#EF5350",
        "terminal.ansiBrightWhite": "#FFFFFF",
        "terminal.ansiBrightYellow": "#FFEB95",
        "terminal.ansiBlue": "#82AAFF",
        "terminal.ansiCyan": "#21C7A8",
        "terminal.ansiGreen": "#22DA6E",
        "terminal.ansiPurple": "#C792EA",
        "terminal.ansiRed": "#EF5350",
        "terminal.ansiWhite": "#FFFFFF",
        "terminal.ansiYellow": "#ADDB67"
    },

    // Editor Settings
    "editor.guides.bracketPairs": "active",
    "editor.fontFamily": "SauceCodePro Nerd Font",
    "editor.fontSize": 16,
    "editor.fontLigatures": true,
    "editor.minimap.enabled": false,
    "editor.wordWrap": "on",
    "editor.tabSize": 4,
    "editor.cursorBlinking": "expand",
    "editor.cursorStyle": "block",

    // Explorer Settings
    "explorer.confirmDragAndDrop": false,
    "explorer.compactFolders": false,

    // Terraform and Terragrunt Specific Settings
    "[terraform]": {
        "editor.formatOnSave": true
    },
    "[terragrunt]": {
        "editor.formatOnSave": true
    },

    // Git Settings
    "git.enableSmartCommit": true,

    // Miscellaneous Settings
    "hediet.vscode-drawio.theme": "atlas",
    "window.zoomLevel": 1,
    "extensions.ignoreRecommendations": true,
    "breadcrumbs.enabled": false,
    "editor.stickyScroll.enabled": false,

    /* Custom Dracula Theme (Commented)
    To use Dracula theme with custom colors, 
    uncomment this block and comment out the 
    workbench.colorCustomizations above */

    // "workbench.colorCustomizations": {
    //     // Interface
    //     "activityBar.background": "#000000",
    //     "activityBar.foreground": "#3884ff",
    //     "activityBar.inactiveForeground": "#ffffff",
    //     "sideBar.background": "#13121b",
    //     "sideBarSectionHeader.background": "#191622",
    //     "sideBar.foreground": "#dadada",
    //     "editor.background": "#1c1e27",
    //     "titleBar.activeBackground": "#191622",

    //     // Dropdowns and Inputs
    //     "dropdown.background": "#191622",
    //     "dropdown.listBackground": "#191622",
    //     "dropdown.border": "#191622",
    //     "dropdown.foreground": "#dadada",
    //     "titleBar.activeForeground": "#dadada",
    //     "input.background": "#191622",

    //     // Panels and Tabs
    //     "panel.background": "#191622",
    //     "panel.border": "#3884ff",
    //     "panelTitle.activeBorder": "#b470a0",
    //     "panelTitle.inactiveForeground": "#0078d4",
    //     "badge.background": "#0078d4",

    //     // Editor
    //     "editorCursor.foreground": "#FFE400",
    //     "editorCursor.background": "#000000",
    //     "editor.lineHighlightBorder": "#1c1e27",
    //     "editor.selectionBackground": "#393744",
    //     "editor.wordHighlightBackground": "#000000",
    //     "editor.wordHighlightStrongBackground": "#000000",

    //     // Status Bar and Breadcrumbs
    //     "statusBarItem.remoteBackground": "#1e9b0d",
    //     "statusBarItem.remoteForeground": "#ffffff",
    //     "breadcrumb.foreground": "#0078d4",
    //     "breadcrumb.background": "#191622",

    //     // Tabs
    //     "tab.activeBackground": "#000000",
    //     "tab.inactiveBackground": "#191622",
    //     "tab.activeForeground": "#0078d4",
    //     "tab.inactiveForeground": "#0078d4",

    //     // Terminal
    //     "terminal.background": "#1d2033",
    //     "terminal.foreground": "#ffffff",
    //     "terminalCursor.background": "#E9E9F4",
    //     "terminalCursor.foreground": "#E9E9F4",
    //     "terminal.ansiBlack": "#282936",
    //     "terminal.ansiBlue": "#0717ff",
    //     "terminal.ansiBrightBlack": "#626483",
    //     "terminal.ansiBrightBlue": "#62D6E8",
    //     "terminal.ansiBrightCyan": "#A1EFE4",
    //     "terminal.ansiBrightGreen": "#EBFF87",
    //     "terminal.ansiBrightMagenta": "#B45BCF",
    //     "terminal.ansiBrightRed": "#ff0909",
    //     "terminal.ansiBrightWhite": "#F7F7FB",
    //     "terminal.ansiBrightYellow": "#00F769",
    //     "terminal.ansiCyan": "#A1EFE4",
    //     "terminal.ansiGreen": "#49E287",
    //     "terminal.ansiMagenta": "#B45BCF",
    //     "terminal.ansiRed": "#ff0909",
    //     "terminal.ansiWhite": "#E9E9F4",
    //     "terminal.ansiYellow": "#00F769"
    // }
}

Conclusão

Demonstrei como instalei e configurei o VSCode, fizemos inicialmente a instalação no próprio Windows certificando de marcar a opção de adicionar ao Path, depois instalamos no Linux através do WSL2 e passamos brevemente por algumas extensões que estou usando.

Por fim, compartilhei meu arquivo settings.json para que se um dia eu precisar restaurar, possa consultar aqui e recuperar, além disso fica disponível para você se desejar fazer uma configuração semelhante.

Criar uma Chave SSH

Antes de qualquer coisa, precisamos e queremos criar nossa chave SSH.
Essa etapa pode ser repetida quantas vezes você preferir.

1- Abra seu terminal e crie uma pasta chamada .ssh

mkdir .ssh

2- Acesse a pasta .ssh que acabamos de criar:

cd ~/.ssh

3- Gere uma chave SSH com o comando:

⚠️ Substitua no comando abaixo:
- "example@simplescloud.io" para um email de sua preferência
- bitbucket_simplescloud_account_example para o nome da chave SSH de sua preferência

Não preencha nenhuma pergunta solicitada no terminal → apenas pressione Enter

ssh-keygen -t rsa -b 4096 -C "example@simplescloud.io" -f bitbucket_simplescloud_account_example

4- Em nosso exemplo, podemos ver que nesse momento foram gerados dois arquivos:

• bitbucket_simplescloud_account_example → chave privada e que não deve ser compartilhada com ninguém

• bitbucket_simplescloud_account_example.pub → chave pública que precisaremos para os próximos passos

Então é hora de copiarmos o conteúdo de nossa chave pública, você pode fazer isso de várias formas, mas prefiro usar o comando copyfile para isso.

Então acesse ~/.ssh → copie o conteúdo da sua chave pública bitbucket_simplescloud_account_example.pub com o comando copyfile

copyfile ~/.ssh/bitbucket_simplescloud_account_example.pub

Configurando o SSH no Bitbucket

1- Acesse sua conta do Bitbucket → canto superior direito na sua foto ou avatar → Personal Settings → SSH Keys → Add Key

2- No campo Label defina um nome fácil de você identificar e no campo Key cole o conteúdo da sua chave pública copiada → Add Key

Configurando o SSH no GitLab

1- Acesse sua conta do GitLab → Edit Profile → SSH Keys e cole o conteúdo da sua chave pública → defina um nome de sua preferência → não preencha o campo de data → clique em Add key

Configurando o SSH no GitHub

1- Acesse sua conta do GitHub → canto superior direito na sua foto ou avatar → Settings → SSH and GPG Keys → New SSH Key

2- No campo Title defina um nome fácil de você identificar, no campo Key Type deixe como Authentication Key e no campo Key cole o conteúdo da sua chave pública copiada → Add SSH Key

Múltiplas Chaves SSH para Múltiplas Contas

Agora que já vimos como gerar chaves SSH e adiciona-las nas hospedagens de controle de versões git de sua preferência, é muito provável que em algum momento, você seja adicionado em um projeto, queira criar uma conta, clonar o repositório e esmagar algum código.

Porém não é tão fácil como parece, para a maioria dos repositórios git como GitLab, GitHub e Bitbucket, acontecerá uma mensagem de erro parecida com:

Essa é uma mensagem um pouco frustrante, pois inicialmente parece fazer sentido querermos usar nossa mesma chave SSH que já temos para uma outra conta recém-criada. Mas não é assim que funciona, explicando melhor essa mensagem diz que sua chave SSH já está adicionada em outra conta, então na prática não podemos "reaproveitar" a mesma chave SSH que você gerou e adicionou na conta Bitbucket pessoal como também em uma segunda conta Bitibucket que você tenha criado por exemplo.

Felizmente há uma solução simples e se aplica da mesma forma para qualquer serviço de hospedagem de controle de versão como GitLab e GitHub, mas para não ficar repetitivo, usarei um passo a passo com o Bitbucket.

Gere várias chaves SSH

Se não podemos usar a mesma chave SSH em várias contas, a solução então é ter várias chaves SSH diferentes. Para esse exemplo, vamos criar:

• Chave SSH Pessoal

• Chave SSH para o Projeto do Cliente

Adicione as chaves SSH ao Agente

Aqui começam as dicas legais, para fazer uso das chaves SSH recém-criadas, precisamos adicioná-las ao ssh-agent que nada mais é do que um programa nativo que contém as chaves privadas usadas para a autenticação pública.

O ssh-agent provavelmente já está sendo executado em segundo plano no seu sistema operacional, mas por precaução vamos verificar com o comando:

eval "$(ssh-agent -s)"

E adicionando novas chaves SSH usando o comando ssh-add.

ssh-add ~/.ssh/key_name_personal
ssh-add ~/.ssh/key_name_client

Torne as alterações permanentes

Estamos caminhando bem, mas você notará que os passos acima se tornam repetitivos cada vez que abrir o terminal, vamos melhorar isso tornando essas alterações permanentes.

1- Em seu terminal digite o comando:

sudo nano ~/.zshrc

2- Vá para o final do arquivo de configuração do Zsh Shell e adicione os comandos que estávamos fazendo manualmente a cada vez que abríamos o terminal + &> /dev/null ao final para evitar algum output e "travar" a exibição inicial do terminal, ou seja:

eval "$(ssh-agent -s)" &> /dev/null
ssh-add ~/.ssh/bitbucket_personal_account_wsl2 &> /dev/null
ssh-add ~/.ssh/bitbucket_simplescloud_account_wsl2 &> /dev/null

Pressione Ctrl + X → Y → Enter para salvar as alterações

Configure o SSH

Estamos quase lá, como etapa final, aqui no arquivo de configuração do SSH é que está toda a mágica! Precisamos criar um arquivo de configuração (se você ainda não o tiver) e criar os aliases ou "apelidos" personalizados que irão impor o uso ou uma chave SSH específica para um determinado host. Então vamos fazer isso!

1- Digite o comando:

sudo nano ~/.ssh/config

2- Edite o arquivo conforme o exemplo. Lembre-se de pressionar Ctrl + X → Y → Enter para salvar as alterações

Host bitbucket-personal.org
  HostName bitbucket.org
  User git
  IdentityFile ~/.ssh/bitbucket_personal_account_wsl2
  IdentitiesOnly yes

Host bitbucket-simplescloud.org
  HostName bitbucket.org
  User git
  IdentityFile ~/.ssh/bitbucket_simplescloud_account_wsl2
  IdentitiesOnly yes

De agora em diante, toda vez que você clonar um repositório de conta do cliente, simplesmente substitua bitbucket.com por bitbucket-client, por exemplo:

❌ git clone git@bitbucket.org:client/project.git
✅ git clone git@bitbucket-simplescloud.org:client/project.git

Ao fazer isso, você está ignorando uma resolução de chave pública padrão e apontando explicitamente ssh-agent para sempre resolver a conexão bitbucket-client.org usando a ~/.ssh/bitbucket_simplescloud_account_wsl2 em nosso exemplo.

Altere a URL upstream do repositório já existente

Você pode estar se perguntando o que fazer com os repositórios já existentes. Clonar todos eles um por um não parece divertido. Não é e tem solução!

Para alterar uma URL do repositório atualmente existente, use o comando git remote set-url, por exemplo:

git remote set-url origin git@bitbucket-simplescloud.org:client/project.git

Testando a Conexão

Além do comando:

eval "$(ssh-agent -s)"

Já citado para verificar se o ssh-agent está em execução, outro comando que pode ser muito útil é o:

ssh -T git@bitbucket-simplescloud.org

Observe que no comando já estamos usando o bitbucket-simplescloud.org que é o alias ou "apelido" configurado no arquivo ~/.ssh/config. Desta forma conseguimos testar que a conexão foi realizada com sucesso.

Conclusão

Esta solução resolveu o meu problema e atendeu bem.

Introdução

JSON é um formato de dados estruturado amplamente utilizado na maioria das APIs e serviços modernos para compartilhar dados. É particularmente popular em aplicativos da web devido à sua natureza leve e compatibilidade como seu próprio nome sugere, o JavaScript.

Infelizmente terminais de comando como o bash não podem interpretar e trabalhar com json diretamente. Isso significa que trabalhar com json por meio da linha de comando pode ser complicado, vejamos por exemplo uma chamada para a API do filme Star Wars:

curl https://swapi.dev/api/people

E obtemos uma resposta em json com informações sobre os personagens do filme:

Bom, podemos ver que o json retornado não é muito amigável para nossa leitura, mas não se preocupe porque há uma forma simples e fácil de resolver isso, e o nome da solução se chama jq que acabará se tornando uma das suas ferramentas favoritas!

2- Veja como o mesmo request ficaria usando o jq:

curl https://swapi.dev/api/people | jq '.'

Instalação

1- Abra seu terminal e digite o comando:

sudo apt install jq

2- Verifique a instalação com o comando:

jq --version

Como usar o JQ

JQ é mais do que apenas "embelezar" o json em seu bash, ele foi construído em torno do conceito de filtros, como veremos abaixo e existem muitos filtros que podemos usar e combinar sem esforços usando o caractere "pipe" | para manipular os dados do json.

Então vamos começar pelo filtro mais simples de todos, que também será o que você acabará usando com mais frequência:

curl https://swapi.dev/api/people | jq '.'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando | jq '.'

• Esse '.' é um filtro que estamos dizendo ao jq "hey, pegue todos os dados e imprima em um formato json visualmente mais bonito para mim".

Avançando...

Ok, já conseguimos ver o json melhor agora, mas imagino que você deve estar se perguntando nesse momento "Certo, é só isso? Mas como que eu pego apenas o nome de um personagem por exemplo?".

Se você se questionou sobre isso, estamos no caminho certo aqui. Vamos detalhar como podemos filtrar apenas o nome do personagem Star Wars no meio de toda essa informação:

1- Se olharmos bem, um json é constituído de "chave":"valor" ou no inglês "key":"value":

2- E a key name está dentro de um array (matriz) chamado results:

3- Então para filtrarmos, poderíamos começar com:

curl https://swapi.dev/api/people | jq '.results'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando | jq '.results'

• Esse '.results' é um filtro que estamos dizendo ao jq "hey, pegue todos os dados do array (matriz) chamado results e imprima o json desses itens".

• Com isso as primeiras linhas que não fazem parte de results foram digamos assim "ignoradas".

Avançando ainda mais...

4- Se continuarmos olhando com atenção, poderemos ver que esse array (matriz) results possui uma lista de itens, onde:

• a primeira posição do array (matriz) é o index (índice) 0 e o nome é Luke Skywalker

• a segunda posição do array (matriz) é o index (índice) 1 e o nome é o C-3PO

Então podemos limitar nosso filtro passando como index (índice) 0 e isso nos retornará o nome Luke Skywalker como previsto:

curl https://swapi.dev/api/people | jq '.results[0]'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando | jq '.results[0]'

• Esse '.results[0]' é um filtro que estamos dizendo ao jq "hey, pegue todos os dados do array (matriz) chamada results e imprima o index (índice) 0 (primeira posição da matriz) em um json".

• Com isso o segundo item dessa matriz, no caso o C-3PO é digamos assim "ignorado", pois limitamos para o index (índice) 0 em nosso filtro.

Avançando mais e mais...

5- Até agora já descobrimos como chegar nesse valor, mas lembra que queríamos apenas o nome?

Bom, então só precisamos informar essa propriedade para o jq:

curl https://swapi.dev/api/people | jq '.results[0] | .name'

Mas aqui vale mais um pouco da sua atenção, vamos dividir nosso comando para entendermos melhor:

• curl https://swapi.dev/api/people → faz um request para a API do filme Star Wars

• | jq '.results[0] → filtra os dados do index 0 no array results

• | .name' → imprime na saída a propriedade name do index 0 no array results

Observe que depois do filtro, adicionamos novamente um "pipe" |, esse último bloco é responsável por "imprimir" as informações para nós como definirmos, isso é a mesma coisa que stdout. Grave essa informação, pois ela será útil em todos os próximos comandos, onde vamos mudar e manipular a forma que esses dados serão apresentados para nós.

Agora ao invés de listar apenas o nome do index (índice) 0 do array (primeira posição da matriz), vamos listar todos os nomes dessa matriz, para isso é só removermos o 0 de .results[0], ficando assim:

curl https://swapi.dev/api/people | jq '.results[] | .name'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando | jq '.results[] | .name'

• Esse '.results[] | .name' é um filtro que estamos dizendo ao jq "hey, pegue todos os dados do array (matriz) chamada results (ele inteiro sem qualquer índice) e imprima a propriedade name".

Avançando mais, mais e mais...

6- Legal, já conseguimos listar o nome de todos, mas eles ainda estão digamos assim "jogados", "soltos", vamos consertar isso:

curl https://swapi.dev/api/people | jq '.results[] | {name: .name}'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando | jq '.results[] | {name: .name}'

• Esse '.results[] | {name: .name}' é um filtro que estamos dizendo ao jq "hey, pegue todos os dados do array (matriz) chamada results (ele inteiro sem qualquer índice) e imprima a key (chave) name com o value (valor) da propriedade name entre {}".

Avançando mais, mais, mais e ainda mais...

7- Estamos melhorando, mas ainda podemos ver que essas informações estão "jogadas", não há formatação json e nem vírgulas no final de cada {}, vamos consertar isso:

curl https://swapi.dev/api/people | jq '[.results[] | {name: .name}]'

Vamos entender o que aconteceu aqui:

• A única diferença é que adicionamos colchetes [] no início e final do nosso filtro '[.results[] | {name: .name}]'

• Então estamos dizendo ao jq aqui "hey coloque o resultado desse filtro dentro de um array (matriz)".

Avançando e avançando...

8- Até agora vimos exemplos somente com uma propriedade name, mas e se quisermos usar várias propriedades juntas? A resposta é simples, separe por vírgulas, por exemplo:

curl https://swapi.dev/api/people | jq '[.results[] | {name: .name, eye_color: .eye_color}]'

Vamos entender o que aconteceu aqui:

• A única diferença é que separamos as propriedades name e eye_color por vírgulas → ou seja → '[.results[] | {name: .name, eyecolor: .eye_color}]'

• Então estamos dizendo ao jq aqui "hey coloque o resultado desse filtro dentro de um array (matriz) com as keys (chaves) name e eye_color com os values (valores) das respectivas propriedades".

Último avanço...

9- Mas e se já tivermos um valor e quisermos fazer uma pesquisa? Por exemplo queremos montar um novo array (matriz) com os nomes dos personagens que possuem olhos azuis, faremos um select:

curl https://swapi.dev/api/people | jq '[.results[] | select(.eye_color=="blue") | {name: .name}]'

Vamos entender o que aconteceu aqui:

• A única diferença é que adicionamos select(.eye_color=="blue").

• Então estamos dizendo ao jq aqui "hey vá para a array (matriz) results, ache o value (valor) blue (azul) na propriedade eye_color de cada item e coloque o resultado desse filtro dentro de um array (matriz) com a keys (chave) name com o seu respectivo value (valor).

Use JQ para Scripts

No seu dia a dia você vai se deparar várias vezes com a necessidade de obter dados de uma saída json, mas isso não se aplica somente a sistemas web, você também vai notar que precisará disso principalmente para seus scripts funcionarem corretamente, por exemplo pode ser comum você precisar obter o ID de uma instância na AWS, então para isso você faria:

aws ec2 describe-instances

Esse comando do AWS CLI faz uma chamada na API da AWS e te retornaria uma saída json com muitas informações, por exemplo:

Mas nós só queremos o ID dessa instância, é aqui que entra o jq e tudo que vimos nesse artigo, então bastaria nós retornarmos o valor da key InstanceID:

aws ec2 describe-instances | jq '.Reservations[] | .Instances[] | {Id: .InstanceId}'

Vamos entender o que aconteceu aqui:

• Adicionamos ao final do nosso comando AWS CLI | jq '.Reservations[] | .Instances[] | {Id: .InstanceId}'

• | jq '.Reservations[] → jq está indo no array Reservations

• | .Instances[] → jq está indo no array Instances

• | {Id: .InstanceId}' → jq está "imprimindo" a key Id com o value InstanceId

E essa informação poderia ser muito útil para um script que agenda o ligar/desligar dessa instância por exemplo.

Outro exemplo poderia ser se você estiver usando o AWS ECS Fargate para orquestrar seus contêineres e como parte de um Pipeline automático, você gostaria de fazer o Deploy da sua nova imagem em uma nova Task, para isso seria importante você descobrir o ID dessa Task, então você faria:

aws ecs list-tasks --cluster <clusterName>

Observe que é retornado um ARN que é o nome completo de um recurso da AWS, mas nós só precisamos do ID que está localizado depois do último /, então usaríamos o jq aqui para dividir esses caracteres assim:

aws ecs list-tasks --cluster <clusterName> | jq -Mr '.taskArns[] | split("/")[-1]'

Vamos entender o que aconteceu aqui:

• Adicionamos no final do nosso comando AWS CLI | jq -Mr '.taskArns[] | split("/")[-1]'

• | jq -Mr '.taskArns[] → jq está indo para o array taskArns

• | split("/")[-1]' → jq está "imprimindo" o último bloco depois da / que é o ID

Conclusão

Esses foram alguns exemplos reais e práticos de como usar o jq e de como ele pode ser útil no seu dia a dia, obviamente você poderia fazer várias combinações e filtros diferentes e para diferentes ferramentas como inspecionar containers do docker, kubernetes e muitas outras coisas.

Introdução

Hashicorp Packer é uma ferramenta open-source (gratuita). Com essa poderosa ferramenta somos capazes de automatizar a criação de qualquer tipo de imagem (AMI) para várias plataformas diferentes como AWS, Google Cloud, Microsoft Azure, etc. a partir de uma única configuração de origem JSON ou HCL2 que define o modelo da infraestrutura imutável.

Instalação ou Atualização do Hashicorp Packer

Você poderá instalar ou atualizar a versão do Hashicorp Packer a qualquer momento, para isso execute o comando abaixo:

# Import Hashicorp GPG key
if [ ! -f /etc/apt/trusted.gpg.d/hashicorp.gpg ]; then

  curl -fsSL https://apt.releases.hashicorp.com/gpg | 
    gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/hashicorp.gpg >/dev/null

fi && \

# Add Hashicorp repository without confirmation  
sudo apt-add-repository -y \
  "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" && \

# Update repositories
sudo apt update && \

# Install Packer 
sudo apt install packer -y && \

# Print version
packer --version

Mas se você quiser entender o que cada parte deste comando faz, é só continuar lendo abaixo.

Explicando o comando:

# Import Hashicorp GPG key
if [ ! -f /etc/apt/trusted.gpg.d/hashicorp.gpg ]; then

  curl -fsSL https://apt.releases.hashicorp.com/gpg | 
    gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/hashicorp.gpg >/dev/null

fi && \

Essa primeira parte verifica se a chave GPG da Hashicorp já está presente em /etc/apt/trusted.gpg.d/. Se não estiver, ele faz o download da chave, decodifica e salva no local correto.

# Add Hashicorp repository without confirmation
sudo apt-add-repository -y \
  "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" && \

Aqui adicionamos o repositório da Hashicorp ao APT, sem pedir confirmação (-y).

# Update repositories  
sudo apt update && \

Atualiza os repositórios para pegar a lista de pacotes do novo repositório adicionado.

# Install Packer
sudo apt install packer -y && \

Instala o Packer a partir do repositório da Hashicorp.

# Print version
packer --version

Por último, imprime a versão instalada do Packer para confirmar que está funcionando.

Introdução

Terragrunt é um wrapper open-source (gratuito) criado pela empresa Gruntwork que fornece ferramentas extras para manter suas configurações DRY (menos repetitivas) enquanto você trabalha com vários módulos Terraform e também precisa gerenciar seu estado remoto.

Instalação

1- Digite o comando:

sudo curl -L https://raw.githubusercontent.com/warrensbox/tgswitch/release/install.sh | sudo bash

2- Digite o comando → pressione Enter na versão do Terragrunt que você desejar instalar:

tgswitch

Agora precisamos adicionar o diretório /home/<user>/bin criado para o seu PATH. Então digite o comando:

sudo nano ~/.zshrc

E adicione a linha abaixo → pressione CTRL + X → Y → Enter para salvar:

export PATH=$PATH:/home/<user>/bin:PATH

3- Verifique a versão do Terragrunt instalado digitando o comando:

terragrunt --version

Então sempre que você precisar mudar de versão do terragrunt, basta digitar o comando tgswitch e selecionar a versão desejada. Bacana né?

Se você não quer procurar e selecionar uma versão no menu do tgswitch, pois já sabe exatamente a versão que deseja usar, você pode passar essa informação diretamente no comando:

tgswitch <version>

Por exemplo:

# tgswitch 0.36.0

E isso instalaria a versão 0.36.0 do Terragrunt.