Onde o Docker fica no Proxmox: a decisão de colocação e a armadilha do compose

O Proxmox está instalado e você quer rodar contêineres. A pergunta não é "como eu instalo", é onde eu coloco. E isso não é questão de gosto, é questão de quantas coisas quebram quando uma quebra.

Três colocações

Direto no host. O mais fácil, e justamente o que não se deve fazer. O host é a camada sobre a qual tudo o mais se apoia. Qualquer coisa que você instale ali passa a estar dentro do raio de dano de cada máquina virtual: um conflito de dependências, um disco cheio ou uma atualização ruim leva não só os seus contêineres, mas tudo de uma vez.

Dentro de um contêiner de sistema. Leve e rápido de montar. Em troca, você está rodando contêineres dentro de um contêiner, e esse arranjo tem arestas próprias: o modelo de permissões, as camadas de sistema de arquivos, o kernel compartilhado. Escolhido de propósito é razoável; escolhido porque "era mais fácil" produz surpresas.

Dentro de uma máquina virtual. O mais pesado no papel e o mais limpo na prática. Quando o arranjo de contêineres cai, o que cai é uma máquina virtual, não o seu servidor. E quando quiser refazer, você refaz uma máquina.

A única pergunta que decide

"Se isso quebrar, o que acontece com todo o resto?" No host a resposta é "tudo", dentro de uma máquina virtual a resposta é "uma só". Uso de recursos, facilidade de instalação, tudo isso fica em segundo plano ao lado dessa resposta.

A segunda metade: compose é um programa

Um arquivo compose parece configuração. Não é. Executá-lo é executar código, e roda com as suas permissões. Duas linhas ali dentro podem entregar ao contêiner a máquina inteira.

Quando as pessoas copiam um arquivo compose da internet, não sentem o desconforto que sentem ao copiar um comando. A diferença não está no perigo, está na aparência: um comando parece um comando, enquanto o compose parece um arquivo de configurações. Parecer não o torna seguro.

Quatro linhas para olhar antes de executar

Ele monta o sistema de arquivos do host lá dentro? Pede modo privilegiado? Passa para dentro o socket da própria gerência de contêineres? Usa a rede do host diretamente?

Essas quatro são as linhas que furam a fronteira do contêiner: se uma delas está lá, aquele contêiner não é mais um contêiner, é o próprio host. Ler leva dez segundos, e esses dez segundos valem mais do que todo o resto deste verbete.

O que o Atlas faz

O Atlas examina arquivos compose e scripts de instalação antes da instalação, e esse exame fica no servidor e não na interface. Ou seja, mande o que a interface mandar, a checagem não pode ser pulada.

As constatações vêm em dois níveis. Vermelho significa algo que tira o contêiner para fora da fronteira do contêiner, isto é, privilégio equivalente ao do host; nesse caso é pedida aprovação explícita. Amarelo significa algo que pode ser feito de propósito mas sobre o que você precisa ser informado. No lado do catálogo de aplicações, vermelho não é aceito de jeito nenhum.

Há mais um detalhe e ele importa: o analisador não opina, ele relata o fato. Não diz "isso é perigoso", diz "esta linha faz aquilo". Quem lê é quem decide, porque a mesma linha pode ser aceitável em uma instalação e inaceitável em outra.