Desenvolvimento Local

Esta página é para desenvolvedores que desejam clonar o repositório, compilar a imagem localmente ou personalizar o Dockerfile. Se você apenas deseja usar o container pré-compilado, consulte Primeiros Passos.

Clonar o Repositório

git clone https://github.com/f5-sales-demo/devcontainer.git
cd devcontainer

Estrutura do Projeto

.
├── Dockerfile                  # Multi-stage image build
├── docker-compose.yml          # Base compose — pulls pre-built image
├── docker-compose.build.yml    # Build override — use explicitly with -f
├── .devcontainer/              # VS Code Dev Container config
│   └── devcontainer.json
├── entrypoint.sh               # Container startup script
├── .env.example                # Example environment variables
├── docs/                       # Documentation site (Starlight)
├── claude-config/              # Claude Code configuration files
├── codex-config/               # Codex configuration
├── pi-config/                  # Pi configuration
└── omp-config/                 # Oh-My-Pi (omp) configuration

Arquivo de Build

O arquivo docker-compose.build.yml adiciona suporte a build local. Ele não é mesclado automaticamente — você deve passá-lo explicitamente com as flags -f. Isso significa que docker compose up -d (ou podman-compose up -d) sempre puxa a imagem pré-compilada do GHCR, independentemente de você ter clonado o repositório ou não.

Docker

Você pode verificar que um simples docker compose up usa apenas a imagem pré-compilada (sem contexto build:):

docker compose config

Compare com a configuração explícita de build:

docker compose -f docker-compose.yml -f docker-compose.build.yml config

Podman

Você pode verificar que um simples podman-compose up usa apenas a imagem pré-compilada (sem contexto build:):

podman-compose config

Compare com a configuração explícita de build:

podman-compose -f docker-compose.yml -f docker-compose.build.yml config

Compilando Localmente

Docker

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Podman

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Isso mescla o arquivo de build com o arquivo compose base, compila a imagem a partir do Dockerfile local e inicia o container. A flag --build força uma recompilação mesmo se uma imagem em cache existir.

Arquitetura de Build em Dois Estágios

O Dockerfile usa um build em dois estágios otimizado para cache de camadas do Docker:

Estágio 1: deps (fundações estáveis, ~4,5 GB)

Essas camadas só são recompiladas quando um ARG de versão é atualizado ou os pacotes APT mudam. Em alterações típicas apenas de ferramentas, o BuildKit pula este estágio inteiro.

Seção	Conteúdo
1. Repositórios APT	NodeSource, deadsnakes, HashiCorp, GitHub, Docker, Microsoft, Google Cloud, Dart SDK
2. Pacotes APT	Ferramentas de sistema, Node.js, Python, Java, Terraform, GitHub CLI, Docker engine, Azure CLI, PowerShell, locales
2b. Pacotes APT de segurança	Análise de rede, scanners web, ferramentas de senha, engenharia reversa, forense (~80 pacotes)
3. Bootstrap do Python	Symlinks + pip via get-pip.py
4. Go	Tarball oficial (última versão estável, resolvida no momento do build)
5. Rust	rustup (instalação global, última versão estável)
6. Maven + Gradle	Downloads binários para /opt
7. Stack VNC	Xvfb, x11vnc, noVNC, fluxbox — exibição remota via navegador
8. Nerd Fonts	JetBrainsMono, Hack, FiraCode (últimas versões)

Estágio 2: final (ferramentas voláteis + configuração do usuário, ~1,5 GB)

Essas camadas mudam com mais frequência (atualizações npm/pip, alterações de configuração), mas recompilam rapidamente porque o estágio pesado deps está em cache.

Seção	Conteúdo
9. AWS CLI v2	Instalador oficial
10. Ferramentas binárias	kubectl, helm, tflint, terraform-docs, act, actionlint, yt-dlp, uv
10b. Binários adicionais	VS Code CLI, oc, yq, terragrunt, ibmcloud, fzf, hadolint, codex
10c. Binários do Super-linter	shfmt, gitleaks, editorconfig-checker, trivy, clj-kondo, dotenv-linter, golangci-lint, goreleaser, kubeconform, protolint, scalafmt, ktlint
10d. Ferramentas Java JAR	checkstyle, google-java-format (scripts wrapper)
10e. Linters PHP	phpcs, phpstan, psalm (downloads PHAR)
10f. Módulos PowerShell	PSScriptAnalyzer, arm-ttk
10g. Binários de segurança	nuclei, subfinder, httpx, ffuf, gobuster, feroxbuster, dalfox, amass, trufflehog, grype, syft, bettercap (amd64)
10h. OWASP ZAP	Scanner de aplicações web baseado em Java
10i. Ghidra	Framework de engenharia reversa
10j. Metasploit	Framework de exploração (apenas amd64)
11. Ferramentas npm globais	claude-code, prettier, markdownlint-cli2, devcontainers-cli, playwright, pi-coding-agent, oh-my-pi
12. Ferramentas pip	pre-commit, ansible, black, pylint, yamllint, playwright
12c. Linters Ruby	rubocop + extensões
12e. Módulos linter Perl	Extensões Perl::Critic
12f. Linter Lua	luacheck
12g. Linter R	lintr
12h. Gems Ruby de segurança	wpscan, evil-winrm
12i. Ferramentas de segurança clonadas via Git	testssl.sh, exploitdb (searchsploit), SecLists, docker-bench-security, recon-ng, spiderfoot
13. Navegadores Playwright	Chromium + dependências do sistema via playwright install --with-deps
13b. Chrome DevTools MCP	Symlink do Chrome + pré-cache MCP + patch headless
14. Homebrew	Linuxbrew (dependências de assistente IA + formatadores)
15. Plugins ZSH	Plugins personalizados do oh-my-zsh
16. Bootstrap do shell	npm-global, tfenv, compinit
17. Configuração Claude Code + Codex	Memória de reconhecimento de ferramentas, política gerenciada, script de autoteste, configuração Codex
18. Entrypoint	Script de inicialização do container (último COPY absoluto)

Adicionando Ferramentas

Edite o Dockerfile e adicione sua ferramenta à seção apropriada. Recompile após adicionar:

Docker

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Podman

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Ou no VS Code: Dev Containers → Recompilar Container.

Pacotes APT

Adicione ao bloco apt-get install da seção 2:

RUN apt-get update && apt-get install -y --no-install-recommends \
    your-package-here \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

Ferramentas npm

Adicione ao bloco npm install -g da seção 11:

RUN npm install -g \
    your-npm-tool

Ferramentas pip

Adicione ao bloco pip install da seção 12:

RUN pip install --no-cache-dir --break-system-packages \
    your-python-tool

Downloads binários

Adicione à seção 10 ou crie uma nova camada RUN com detecção de arquitetura:

RUN ARCH=$(dpkg --print-architecture) \
    && curl -fsSL "https://example.com/tool-linux-${ARCH}.tar.gz" \
       | tar -xz -C /usr/local/bin tool

Cache de Build

O CI usa cache baseado em registro — as camadas de build são armazenadas no GHCR (ghcr.io/f5-sales-demo/devcontainer:cache-*) em vez do cache do GitHub Actions. Isso evita o limite de 10 GB do cache GHA que causava recompilações completas frequentes para esta imagem multi-arquitetura de ~6 GB.

A arquitetura em dois estágios funciona com o cache de registro de forma que:

• Atualizações de versão de ferramentas (npm, pip, ferramentas binárias) — recompila apenas o estágio final (~5 min)
• Alterações em arquivos de configuração (claude-config/, entrypoint.sh) — recompila apenas as últimas camadas (~1 min)
• Alterações de fundação (pacotes APT, versões Go/Rust/Java) — recompilação completa de ambos os estágios (~30 min)