DevOpsQuest
0 XP
Módulo 0 · Boas-vindas e Ambiente

Instalando o arsenal: Docker, Node, AWS CLI, Terraform, kubectl e Helm

Iniciante 50 min+25 XPDockerNodeAWS CLITerraformkubectlHelm

Objetivos desta aula

  • Entender o papel de cada ferramenta no ciclo de entrega
  • Instalar as ferramentas do curso e validar cada uma com um teste real
  • Fixar versões para evitar surpresas em máquina e em pipeline
  • Diagnosticar os erros de instalação mais comuns

1. Cada ferramenta tem um lugar no ciclo

  • Docker — empacota a aplicação com suas dependências em uma imagem que roda igual em qualquer lugar.
  • Node — runtime do CloudShop; roda a aplicação e seus testes.
  • AWS CLI — conversa com a nuvem pela linha de comando, de forma automatizável.
  • Terraform — descreve a infraestrutura em arquivos versionados.
  • kubectl — opera o cluster Kubernetes.
  • Helm — empacota manifests em releases parametrizáveis.

Instalar tudo agora evita interromper o estudo no meio de um módulo.

2. Duas formas de instalar, e quando usar cada uma

Gerenciador de pacotes (apt, snap, brew) traz atualização automática e é bom para a máquina de trabalho. Gerenciador de versão (nvm para Node, tfenv para Terraform) permite ter várias versões e trocar por projeto — indispensável quando um repositório exige Terraform 1.6 e outro 1.9.

3. Docker: instalar e entender o que aconteceu

O instalador coloca no sistema o daemon (serviço que cria e gerencia containers) e o cliente docker. O cliente conversa com o daemon por um socket em /var/run/docker.sock, que pertence ao grupo docker. Por isso você adiciona seu usuário a esse grupo — e por isso precisa reabrir a sessão para o novo grupo valer.

Consciência de segurança: pertencer ao grupo docker equivale, na prática, a acesso administrativo à máquina, porque você pode montar qualquer diretório dentro de um container.

4. Validar Docker de verdade

docker --version só prova que o binário existe. A validação real é rodar um container (docker run --rm hello-world), listar imagens e conferir o serviço com docker info. Se aparecer permission denied ... /var/run/docker.sock, o problema é grupo/sessão, não instalação.

5. Node com nvm

Instale o nvm e depois a versão LTS. Com nvm install --lts e nvm use, cada projeto pode fixar sua versão em um arquivo .nvmrc. Isso evita o clássico "funciona na minha máquina": a versão do runtime passa a ser parte do repositório.

6. AWS CLI v2

A versão 2 é distribuída como pacote próprio (não via pip) e inclui recursos como login por SSO. Após instalar, valide com aws --version; a validação de credencial vem na próxima aula, com aws sts get-caller-identity.

7. Terraform, kubectl e Helm

Terraform é um binário único; prefira instalar por repositório oficial ou tfenv para controlar a versão. kubectl deve estar próximo da versão do cluster (a regra suportada é uma versão menor de diferença). Helm v3 não tem componente no cluster, é só um cliente que gera e aplica manifests.

8. Por que fixar versão é tão importante

Terraform muda comportamento entre versões menores e o arquivo de estado é sensível a isso. Em pipelines, ferramenta sem versão fixa gera build que quebra sem ninguém ter mudado código — um dos incidentes mais frustrantes que existe. A regra é: versão explícita na máquina, no arquivo do repositório e no workflow de CI.

9. Documentando o arsenal

Crie docs/ferramentas.md com a versão de cada ferramenta e a data. Esse arquivo responde em segundos a pergunta "o que mudou desde que funcionava?" e é o mesmo hábito que empresas formalizam em bill of materials.

10. Erros comuns e o que eles significam

  • permission denied /var/run/docker.sock → falta grupo docker ou sessão não reaberta.
  • command not found após instalar manualmente → binário fora do PATH; mova para /usr/local/bin.
  • nvm: command not found em novo terminal → falta carregar o nvm no ~/.bashrc.
  • kubectl muito novo/antigo em relação ao cluster → mensagens estranhas de API; alinhe versões.

11. Cuidado com instalação por script da internet

Baixar um script e executá-lo direto no shell exige confiança total na origem. Em ambiente corporativo, use o repositório de pacotes aprovado, verifique checksum ou assinatura e prefira versões fixas em vez de "latest".

12. Checagem final da aula

Rode a bateria de validação: docker run --rm hello-world, node -v, aws --version, terraform -version, kubectl version --client, helm version. Registre a saída no diário e no docs/ferramentas.md.

Na prática

Instalação e validação

bash

# Docker Engine (Ubuntu/WSL2)
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker "$USER"   # reabra a sessao depois (exit e entrar de novo)
docker run --rm hello-world       # "Hello from Docker!" = cliente + daemon ok

# Node via nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc && nvm install --lts && node -v && npm -v   # v22.x / 10.x

# AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o awscliv2.zip
unzip -q awscliv2.zip && sudo ./aws/install && aws --version  # aws-cli/2.x

# Terraform, kubectl e Helm
sudo snap install terraform --classic
curl -LO "https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -m 0755 kubectl /usr/local/bin/kubectl
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

terraform -version && kubectl version --client && helm version

Nota de segurança: Baixar script e executar direto no shell exige confiança na origem. Em ambiente corporativo, use o repositório de pacotes aprovado e verifique checksum.

Diagnóstico rápido de Docker

bash

docker info | head -8        # mostra versao do servidor, storage driver, containers ativos
# Se der: permission denied while trying to connect to the Docker daemon socket
id -nG                       # confira se 'docker' aparece nos seus grupos
newgrp docker                # aplica o grupo na sessao atual (alternativa a reabrir o terminal)
docker run --rm alpine sh -c 'echo dentro do container; uname -r'
# dentro do container
# 5.15.167.4-microsoft-standard-WSL2   <- mesmo kernel do host: container nao e VM

Nota de segurança: Quem está no grupo docker pode montar / dentro de um container e ler qualquer arquivo: trate como acesso administrativo.

Fixando versões no repositório

bash

cd ~/projetos/cloudshop-app
node -v | sed 's/^v//' > .nvmrc          # ex.: 22.11.0 -> quem clonar roda 'nvm use'

cat > docs/ferramentas.md <<EOF
# Ferramentas (atualizado em $(date +%F))
- docker: $(docker --version | awk '{print $3}' | tr -d ,)
- node: $(node -v)
- aws-cli: $(aws --version | awk '{print $1}')
- terraform: $(terraform -version | head -1 | awk '{print $2}')
- kubectl: $(kubectl version --client -o json | jq -r .clientVersion.gitVersion)
- helm: $(helm version --short)
EOF
cat docs/ferramentas.md

As mesmas versões no GitHub Actions

yaml

name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc      # usa a MESMA versao da sua maquina
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.8       # versao fixa, nunca "latest"
      - run: node -v && terraform -version

Por que isso importa

Ambiente padronizado é pré-requisito de automação. Se o comando não roda igual na sua máquina e no runner, o pipeline é loteria.

Erro comum

Esquecer de reabrir a sessão após entrar no grupo docker e concluir que a instalação falhou.

Dica de produção

Registre as versões em docs/ferramentas.md e use as mesmas versões nos workflows do GitHub Actions.

Pergunta de entrevista

Por que fixar versões de ferramentas em CI e como você faria isso no GitHub Actions?

Glossário

CLI
Interface de linha de comando: forma automatizável de operar uma ferramenta.
nvm
Gerenciador de versões do Node, permitindo trocar de runtime por projeto.
daemon
Processo que roda em segundo plano prestando um serviço, como o motor do Docker.
socket Unix
Arquivo especial usado para comunicação entre processos na mesma máquina, como /var/run/docker.sock.
PATH
Lista de diretórios onde o shell procura os comandos que você digita.
tfenv
Gerenciador de versões do Terraform, útil quando cada repositório exige uma versão diferente.
Helm
Empacotador de manifests Kubernetes em charts com valores parametrizáveis.
checksum
Impressão digital de um arquivo, usada para verificar se o download não foi alterado.

Conexão com o CloudShop

Documentar as versões usadas no CloudShop para reproduzir builds no CI.

Quiz da aula

  1. 1. Qual ferramenta descreve infraestrutura de forma declarativa e versionada?

  2. 2. Por que é necessário reabrir a sessão após 'usermod -aG docker $USER'?

  3. 3. Qual é o risco de usar 'latest' para a versão do Terraform no pipeline?

  4. 4. Qual comando valida de verdade que o Docker está funcional?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima