CLImbaprenda AWS CLI digitando Praticar de graça

🏗️Entenda o AWS CodeBuild

O CodeBuild é um montador de código de aluguel: você entrega o repositório e a receita (o arquivo buildspec.yml), ele sobe um contêiner limpo, roda os comandos — instalar dependência, testar, empacotar — e desaparece. Não existe servidor de CI pra você manter ligado.

Pra que serve

É o "CI" do CI/CD na AWS: todo commit dispara um build que roda os testes e gera o pacote que vai pra produção. Você paga só os minutos de máquina, e cada build nasce numa máquina zerada — sem o "na minha máquina funciona".

Onde se usa no mundo real

Todo push na branch main dispara um build que roda os testes da API e bloqueia o deploy se algum quebrar.
Um time monta a imagem Docker da aplicação no CodeBuild e publica no ECR, sem ninguém rodar docker build no notebook.
O CodePipeline chama o CodeBuild no meio da esteira: fonte → build → deploy.

Vocabulário

Projeto: a receita do build: de onde vem o código, em que máquina roda e com qual role.
Build: cada execução da receita, com id <projeto>:<uuid>.
buildspec.yml: o arquivo no repositório com os comandos de cada fase (install, pre_build, build, post_build).
Fase: cada etapa do build (DOWNLOAD_SOURCE, INSTALL, BUILD...). A que deu FAILED diz onde quebrou.
Artefato: o que o build produz e guarda (um .zip no S3, por exemplo). Build que só testa usa NO_ARTIFACTS.
Service role: a role do IAM que o build assume pra ler o código, escrever log e publicar artefato.

💰 Como cobra: Paga por minuto de build, e o preço sobe com o tamanho da máquina (computeType). Build parado ou encerrado não cobra. Comparando: é o equivalente AWS do runner do GitHub Actions — a diferença é que ele vive dentro da sua conta, com acesso direto à sua rede e às suas roles.

Comandos que você aprende nesta trilha

Cada um deles roda de verdade no terminal do CLImb, com a mesma saída e as mesmas mensagens de erro que a AWS devolve.

`aws codebuild list-projects`

USO

aws codebuild list-projects [--sort-by NAME|CREATED_TIME|LAST_MODIFIED_TIME] [--sort-order ASCENDING|DESCENDING]

`aws codebuild create-project`

USO

aws codebuild create-project --name <nome> \
--source type=GITHUB,location=https://github.com/<org>/<repo> \
--artifacts type=NO_ARTIFACTS \
--environment type=LINUX_CONTAINER,image=aws/codebuild/standard:7.0,computeType=BUILD_GENERAL1_SMALL \
--service-role arn:aws:iam::<conta>:role/<role>

`aws codebuild batch-get-projects`

USO

aws codebuild batch-get-projects --names <projeto> [<projeto2> ...]

`aws codebuild start-build`

USO

aws codebuild start-build --project-name <projeto> [--source-version <branch|commit>] [--environment-variables-override name=VAR,value=valor]

`aws codebuild batch-get-builds`

USO

aws codebuild batch-get-builds --ids <id-do-build> [<id2> ...]

`aws codebuild list-builds-for-project`

USO

aws codebuild list-builds-for-project --project-name <projeto> [--sort-order ASCENDING|DESCENDING]

`aws codebuild stop-build`

USO

aws codebuild stop-build --id <id-do-build>

`aws codebuild retry-build`

USO

aws codebuild retry-build --id <id-do-build>

`aws codebuild update-project`

USO

aws codebuild update-project --name <projeto> [--timeout-in-minutes <n>] [--environment ...] [--source ...] [--description ...]

`aws codebuild delete-project`

USO

aws codebuild delete-project --name <projeto>

O que você pratica (21 atividades)

Cada atividade é um pedido de trabalho, do jeito que ele chega no dia a dia — você resolve digitando os comandos, não escolhendo alternativa.

Quem monta o código aqui?

O time vai tirar o build do notebook do dev e passar pra nuvem. Antes de criar qualquer coisa, veja se já existe algum projeto de build na conta.

A receita do build da API

Crie o projeto api-loja-build: código no GitHub em https://github.com/climb-labs/api-loja, sem artefato (por enquanto ele só testa), máquina LINUX_CONTAINER com a imagem aws/codebuild/standard:7.0 no tamanho BUILD_GENERAL1_SMALL, e a role arn:aws:iam::123456789012:role/codebuild-servico.

O que ficou configurado?

Confira a receita do api-loja-build: de onde vem o código, em que máquina roda e com qual role.

Em ordem alfabética

Com a conta crescendo, liste os projetos em ordem de nome, de A a Z.

Rode o primeiro build

A receita está pronta. Rode um build do api-loja-build e anote o id que volta — é ele que você vai acompanhar.

Passou ou quebrou?

O build está rodando. Consulte o estado dele pelo id — e consulte de novo até o buildStatus sair de IN_PROGRESS.

Só o veredito

O script do deploy só quer saber se o build passou. Consulte o build trazendo só o buildStatus.

O histórico da API

O gestor quer ver todos os builds já rodados da API. Liste os builds do api-loja-build.

O build da branch de release

A versão candidata está na branch release, e o build dela precisa saber que é homologação. Rode o api-loja-build na branch release com a variável AMBIENTE=homolog.

Do primeiro build pro último

Pra um relatório, liste os builds do api-loja-build na ordem em que aconteceram — do mais velho pro mais novo.

O build vermelho

O projeto de testes de integração, testes-api-build, usa o repositório https://github.com/climb-labs/testes-quebrados. Crie o projeto (mesma máquina e role), rode um build e consulte até ele terminar. Descubra em que fase ele quebrou e por quê.

Build disparado na branch errada

Alguém rodou o api-loja-build na branch experimento por engano, e cada minuto é cobrado. Rode esse build (pra ver o cenário) e pare ele antes de terminar.

O teste vermelho não precisa rodar de novo

Os testes de integração estão quebrados de propósito enquanto o time corrige. Alguém disparou mais um build do testes-api-build — pare antes de gastar minuto.

A rede caiu no meio do build

O projeto do app, app-mobile-build (repositório https://github.com/climb-labs/app-instavel), falhou na primeira vez — e não foi o código. Crie o projeto, rode, consulte até terminar e veja a fase que falhou. Depois, repita o build igualzinho.

A repetição passou?

Confira o build repetido do app-mobile-build até ele terminar — agora tem que dar SUCCEEDED.

Repetir não conserta código

Pra fixar a diferença: repita o último build do testes-api-build e consulte até terminar. Ele vai falhar igual — erro de código não passa na base da insistência.

Build travado não pode rodar uma hora

Um build do api-loja-build travou e ficou cobrando até o timeout padrão de 60 minutos. O build normal leva 5. Baixe o timeout do projeto pra 15 minutos.

O build do app precisa de mais máquina

O build do app mobile está lento na máquina pequena. Troque o ambiente do app-mobile-build pra BUILD_GENERAL1_MEDIUM (mesma imagem e tipo).

Compare as duas receitas

Antes da reunião de custo, compare lado a lado o api-loja-build e o app-mobile-build: máquina e timeout de cada um.

Os testes de integração foram pra outro lugar

O time moveu os testes de integração pra dentro do projeto da API. Apague o testes-api-build.

O projeto da documentação

Alguém criou o docs-build (repositório https://github.com/climb-labs/docs) pra testar e esqueceu. Crie pra ver o cenário e apague.

Continue por aqui

Ler explica. Digitar fixa. No CLImb você roda os comandos de verdade num terminal AWS simulado — o estado persiste entre eles, como na nuvem real.

As 3 primeiras atividades desta trilha são abertas; o resto faz parte do plano Pro.

Começar — 3 atividades grátis

Todas as lições · Instalar a AWS CLI · Comandos básicos · Erros comuns · Praticar no terminal · Sobre