Dá para administrar o Proxmox sem linha de comando: a resposta honesta

A maioria de quem faz essa pergunta na verdade quer saber duas coisas diferentes: "eu consigo?" e "vou perder alguma coisa?". As duas respostas são melhores do que se imagina, mas no meio há um aviso importante.

O painel não é um caminho menor

A ideia difundida é que a interface é um shell simplificado e que o trabalho de verdade acontece na linha de comando. Não é assim. O painel e a linha de comando falam com a mesma interface: a interface de programação do próprio Proxmox. O botão que você aperta no painel e o comando que você digita no terminal passam pela mesma porta.

Ou seja, o trabalho feito pelo painel não é uma "versão leve". É o mesmo trabalho, por outra superfície.

Quase todo o trabalho diário já está no painel

Criar máquinas, ligar, desligar, tirar snapshots, fazer backups, definir armazenamento, arrumar a rede, criar usuários e dar permissões, atualizar. Tudo isso existe na interface, e para a maior parte a linha de comando é de qualquer forma mais lenta.

Onde a linha de comando é realmente necessária

Esses casos são poucos mas não são zero, e a honestidade manda dizer. Costumam cair em três famílias: quando um componente quebra de um jeito inesperado (ler os registros do sistema, ver por que um serviço não inicia), quando se trabalha em massa (aplicar a mesma mudança a cem máquinas), e quando se usa uma capacidade nova ou muito específica que a interface ainda não cobre.

Repare no que essas três têm em comum: todas são fora do comum. Nenhuma faz parte do trabalho diário.

O perigo real não é o não saber

Esta é a frase mais importante deste verbete: o perigo não é desconhecer a linha de comando, é colar um comando que você não entende.

Um comando encontrado na internet roda na sua máquina com as suas permissões, e ninguém olha o resultado. Este wiki tem dois exemplos concretos: o comando de uma linha que supostamente cala o aviso de assinatura e que na verdade destrói toda a biblioteca da interface, e os arquivos compose que parecem configuração mas podem entregar ao contêiner a máquina inteira.

Em nenhum dos dois casos o problema foi a pessoa não saber linha de comando. O problema foi ela executar algo que não conhecia. Quem nunca encosta na linha de comando não cai em nenhuma das duas armadilhas; quem sabe pela metade cai.

Se quiser aprender, a ordem certa

Não estamos dizendo para evitar. Mas a ordem importa: aprenda primeiro os comandos que leem, depois os que escrevem. Comandos que mostram estado, leem registros e listam não quebram nada, e ensinam como o sistema raciocina. Passe para os comandos que escrevem só quando conseguir ler o que eles fazem.

E uma regra: não execute um comando que você não entende numa máquina que carrega o seu trabalho. Se quiser experimentar, crie uma máquina para experimentar; todos os verbetes de backup e restauração deste wiki existem exatamente para isso.

O que o Atlas faz

O Atlas fica do lado de trazer o trabalho diário para o painel, ou seja, tenta alargar a lista do "quase tudo" acima. Mas ao fazer isso ele não esconde nada: diz o que uma operação vai fazer e, nas operações sem volta, diz isso antes da operação.

A mesma postura aparece em dois lugares diretamente ligados a este verbete. Scripts de instalação e arquivos compose são examinados antes de rodar, e as linhas que furam a fronteira do contêiner são mostradas a você. Trabalhos que tocam arquivos, como calar o aviso de assinatura, são feitos dentro do produto em vez de à mão, e depois de escrever o arquivo é lido de volta e verificado.

Então o objetivo não é esconder a linha de comando de você. O objetivo é que você nunca precise colar um comando que não entende.