Docker

O que permite fazer?

O Docker na ArduMaker tem duas partes: o daemon, que é uma capacidade do VPS, e os apps Docker, cada um um projeto Compose próprio que a plataforma escreve, sobe, observa e remove.

• Instalar o daemon com um clique (ou deixar que o primeiro app que precisar o instale).
• Publicar uma imagem pública, uma imagem de um registro privado com token, ou um repo do GitHub com Dockerfile.
• Publicar um Compose avançado (como objeto JSON) com vários serviços.
• Iniciar, parar e reiniciar o projeto, e publicá-lo com HTTPS se expuser uma porta web.
• Pela aba Docker do VPS: listar contêineres, ver seus logs, pará-los, reiniciá-los ou apagá-los, e ver imagens, volumes e redes.

Quando convém usar?

• Uma aplicação já empacotada como imagem (um painel, uma ferramenta interna, um serviço de terceiros).
• Vários serviços que sobem juntos com Compose.
• Para código próprio no GitHub com um processo que não é Docker, o deploy do GitHub é mais adequado.

Como funciona na ArduMaker?

O daemon

Os VPS novos nascem com as permissões de contêiner que o Docker precisa, sem serem privilegiados. Um VPS antigo que não as tem as recebe ao instalar o Docker e precisa de um reinício (o preflight avisa com requiere_reinicio_vps). O daemon é instalado com o pacote docker.io e fuse-overlayfs, com userns-remap ativado: os processos dos contêineres não rodam como o root real do VPS.

Um app Docker

1. A configuração e o preflight são validados (função do sistema, Docker possível no host, memória e disco).
2. Se o daemon faltar, é instalado; se outra instalação estiver em andamento, a operação aguarda e é tentada de novo.
3. É escrito /opt/ardumaker-apps/app<id>/docker-compose.yml (com cópia do anterior) e validado com docker compose config; se não validar, o anterior é restaurado.
4. É executado docker compose -p app<id> up -d --remove-orphans como passo longo, assim um download pesado não estoura o tempo.
5. Se houver port, é publicado com HTTPS e o link é verificado.

Todos os contêineres levam o rótulo ardumaker.app_id e o projeto se chama app<id>: o nome não é escolhido pelo usuário e a plataforma nunca toca nada fora dele. Repetir o deploy é idempotente: o mesmo arquivo e up -d não recriam o que não mudou.

O que muda realmente?

Configuração de um app Docker

• image, compose e repo_id são mutuamente exclusivos.
• port é a porta do VPS (a partir de 1024 e nunca uma protegida); com port é preciso container_port. "auto" escolhe uma livre.
• As portas são publicadas só em 127.0.0.1: um contêiner nunca fica aberto direto para a internet.
• env não aceita nomes de segredo (*_PASSWORD, *_TOKEN…): a configuração não guarda segredos.

O que um Compose recusa

Cada serviço aceita uma lista branca de chaves (image, command, entrypoint, environment, ports, volumes, restart, depends_on, healthcheck, working_dir, user, expose, networks, mem_limit, cpus, labels, tmpfs, stop_grace_period, read_only, init). As recusas vêm com um código por caminho (compose.services.<serviço>.<chave>):

Também não são aceitos build, container_name, env_file, configs, secrets, extends nem name, nem rótulos com.docker.* ou ardumaker.*.

Desinstalar e dados

A desinstalação roda docker compose down --remove-orphans, força a remoção dos contêineres com o rótulo do projeto e apaga o arquivo Compose. Os volumes e a pasta ./datos ficam, salvo se for pedido apagar os dados: então roda down -v e a pasta do projeto é apagada. Nada fora de app<id> é tocado.

Esquema

Resultado esperado

O app aparece em Apps com o estado observado: running se todos os contêineres rodam, stopped se todos estão parados, degraded se há mistura e missing se não sobra nenhum. Com port, a URL HTTPS aparece só quando o link respondeu sem erro 5xx.

docker compose -p app<id> ps
docker ps --filter label=com.docker.compose.project=app<id>

Erros e resolução

Relação com MCP

Os apps Docker são operados via MCP com as ferramentas de Apps; a referência está em /mcp/docs e /mcp/servicios.

• Leitura: ver_catalogo_apps, ver_preflight_app (valida a config exata antes de instalar), listar_apps_empresa, ver_app, ver_operacion_app.
• Modificam: instalar_app com app_type: docker (exige idempotency_key), controlar_app (start, stop, restart), reintentar_operacion_app, refrescar_apps.
• Destrutiva: desinstalar_app (só admin, confirm=true; os volumes só são apagados com delete_data e confirm_delete_data).

Funcionalidades relacionadas

• Servidores VPS
• n8n
• Deploy do GitHub
• Nginx
• Certificados SSL