Escrever ubuntu:latest introduzi-la no campo “Instalar uma aplicação personalizada” do ZimaOS não cria automaticamente um pequeno servidor Ubuntu sempre ativo. A imagem é um sistema de ficheiros de contentor Ubuntu mínimo, não uma máquina virtual pré-configurada com uma sequência de arranque completa, um daemon SSH, um gestor de serviços e uma aplicação em segundo plano já em execução.
Essa distinção explica o caso da fonte de outubro de 2025. Foi possível obter a imagem e criar um contentor, mas este não permaneceu em execução da forma esperada pelo utilizador. A solução adequada depende do objetivo real: executar uma aplicação num contentor ou executar um sistema operativo Debian/Ubuntu completo e de uso geral dentro de uma máquina virtual.
Um contentor Docker não é uma pequena máquina virtual
Uma máquina virtual emula um ambiente informático completo e inicia a sua própria pilha do sistema operativo. Um contentor partilha o kernel Linux do anfitrião e executa um ou mais processos isolados no seu próprio espaço de utilizador.
O modelo do Docker centra-se no processo principal do contentor. Se o processo em primeiro plano terminar, um contentor em segundo plano também termina. Por isso, os contentores são normalmente construídos em torno de um serviço persistente, como um servidor Web, uma base de dados, um daemon de sincronização ou um trabalhador de aplicações.
As imagens oficiais do Ubuntu e do Debian são imagens base mínimas
A imagem oficial atual do Ubuntu é criada a partir do sistema de ficheiros raiz mínimo da Canonical, e o Docker descreve-a como uma instalação mínima, não como um dispositivo virtual completo. A imagem oficial do Debian utiliza igualmente um minbase sistema de ficheiros raiz.
Se iniciar uma delas interativamente com um terminal, esta parece um pequeno ambiente Linux, porque dispõe de uma shell. Quando essa shell termina, pode não existir nenhum serviço em primeiro plano para manter o contentor ativo.
Consulte as informações mantidas sobre a imagem base oficial do Ubuntu ou as informações mantidas sobre a imagem base oficial do Debian antes de considerar qualquer uma delas um dispositivo servidor pré-configurado.
Porque é que ubuntu:latest pode parar imediatamente
O ZimaOS espera que uma aplicação Docker instalada tenha um processo persistente e significativo. Uma imagem de distribuição simples é normalmente uma base para outra imagem ou um ambiente de shell interativo. Se não estiver configurado nenhum processo de serviço para permanecer como PID 1, o contentor pode terminar normalmente, em vez de “falhar”.
Verifique o registo do contentor e o estado de saída antes de presumir que o ZimaOS não conseguiu instalar a imagem. Um contentor terminado sem nenhuma aplicação configurada é um problema diferente de um serviço que inicia e apresenta um erro.
Se só precisa de uma aplicação, comece pela aplicação
O utilizador de origem esclareceu que, na realidade, não pretendia uma VM completa. Pretendia uma única aplicação — o iDrive — e acesso ao armazenamento NAS. Nessa situação, normalmente, a melhor abordagem Docker consiste em encontrar uma imagem mantida para a aplicação em causa ou criar uma imagem pequena que instale e inicie essa aplicação.
O contentor deve expor apenas as portas, os volumes, as credenciais e os dispositivos de que a aplicação necessita. Os ficheiros persistentes devem residir no armazenamento mapeado do ZimaOS, e não apenas na camada descartável do contentor.
Utilize o Docker Compose para um serviço de contentor real
A resposta da comunidade sugeriu uma definição Compose adequada, em vez de introduzir apenas ubuntu:latest e um nome de contentor. O ZimaOS atual avançou ainda mais nessa direção: pode importar Docker Compose, editar YAML e executar conjuntos de vários contentores com controlo do ciclo de vida.
As orientações atuais da IceWhale indicam que a configuração padrão do ambiente de execução do contentor deve pertencer ao Docker Compose, enquanto os metadados específicos da loja do ZimaOS devem pertencer a x-casaos.
Utilize o modelo Compose atual do ZimaOS para aplicações autoalojadas, em vez de tratar o nome de uma imagem de distribuição como uma definição completa da aplicação.
Mapear o armazenamento NAS para o contentor
Se a aplicação só precisar de acesso a um diretório, mapeie essa pasta real do ZimaOS para o contentor. O lado do anfitrião deve apontar para uma pasta de cópia de segurança ou de dados no conjunto de armazenamento pretendido, enquanto o lado do contentor expõe um caminho simples que a aplicação espera.
O ZimaOS atual explica como o armazenamento do anfitrião é mapeado para caminhos dentro do contentor. Normalmente, isto é mais leve do que executar uma VM Debian completa apenas para aceder a uma pasta.
Utilize o ZVM quando o software espera uma máquina Linux completa
Uma VM é a opção mais adequada quando o instalador da aplicação espera coisas como:
- um gestor de pacotes convencional e um sistema de ficheiros do sistema mutável;
- systemd ou vários serviços ao nível do sistema operativo;
- comportamento ao nível do kernel que não pode ser disponibilizado com segurança através de um contentor;
- um ambiente de servidor Linux tradicional administrado por SSH;
- software de um fornecedor que suporta explicitamente instalações Ubuntu/Debian, mas não Docker.
Isso corresponde à primeira resposta da comunidade: se o objetivo for um sistema operativo Debian ou Ubuntu autónomo, use o ZVM em vez de forçar uma imagem de contentor base a comportar-se como uma VM completa.
Em vez disso, não instale a aplicação no sistema de ficheiros raiz do ZimaOS
Passar de «o contentor Ubuntu termina» para «vou instalar o software com apt no próprio ZimaOS» é normalmente uma abordagem errada. O ZimaOS atual mantém a maioria das pastas do sistema como só de leitura por conceção e não é um anfitrião Debian/Ubuntu geral com apt como modelo normal de gestão de aplicações.
Os contentores e as VMs existem precisamente para manter as dependências das aplicações separadas do sistema base do ZimaOS.
Quando uma imagem base Debian/Ubuntu continua a ser útil
Existem razões legítimas para criar a partir de ubuntu ou debian: o software de destino pode publicar instruções de instalação apenas para essas distribuições, ou pode precisar dos respetivos repositórios de pacotes durante a criação da imagem.
Nesse caso, crie um Dockerfile ou uma imagem baseada em Compose que instale a aplicação e defina um comando real em primeiro plano. Não dependa da entrada manual numa shell, da instalação interativa de pacotes e da esperança de que o contentor modificado se torne uma aplicação persistente. A recriação do contentor pode eliminar alterações que não tenham sido incorporadas na imagem ou armazenadas em volumes persistentes.
Uma política de reinício não substitui a ausência de um processo principal
As políticas de reinício do Docker são úteis para um serviço real que deva voltar a iniciar após um reinício ou uma saída inesperada. Não transformam uma sessão de shell que já terminou num servidor de aplicações. Se o trabalho previsto do contentor já estiver concluído, reiniciá-lo repetidamente apenas cria um ciclo.
Escolha a camada de isolamento mais pequena que corresponda ao software
- A aplicação já tem uma imagem Docker mantida: use essa imagem.
- A aplicação pode ser empacotada a partir de dependências do Ubuntu/Debian: crie um contentor de aplicação adequado.
- A aplicação precisa de um anfitrião Linux convencional completo: use o ZVM.
- Só precisa de acesso ao armazenamento: mapeie as pastas NAS necessárias em vez de virtualizar o disco inteiro.
Perguntas frequentes sobre Ubuntu e Debian no ZimaOS
Porque é que o ubuntu:latest instala, mas não permanece em execução?
Uma imagem de distribuição base não é automaticamente um serviço sempre ativo. Um contentor Docker precisa de um processo principal que permaneça em execução.
O ubuntu:latest é uma máquina virtual Ubuntu completa?
Não. É um espaço de utilizador de contentor mínimo que partilha o kernel do anfitrião.
Devo usar o ZVM para todas as aplicações Linux?
Não. Uma aplicação Docker verdadeira é normalmente mais leve e fácil de gerir quando o software suporta contentores.
Quando é que o ZVM é a melhor escolha?
Use uma VM quando o software espera um servidor Ubuntu/Debian tradicional e mutável, com serviços ao nível do sistema ou pressupostos de instalação que não se adequam a um contentor.
