O KVM, as máquinas virtuais, os contentores e o hardware dedicado descrevem limites operacionais diferentes. Escolha o limite de que o seu projeto necessita, verifique as funcionalidades expostas pela oferta e mantenha o software dentro desse ambiente.
Uma máquina virtual é um ambiente convidado
Uma máquina virtual apresenta um sistema operativo com hardware virtualizado, como processadores, discos e interfaces de rede. O anfitrião físico executa a maquinaria que torna esses convidados possíveis. Um VPS é um produto de alojamento construído em torno de um servidor virtual, com uma atribuição de recursos declarada e um ambiente operativo que o cliente pode utilizar. Leia a atribuição como parte da oferta, em vez de imaginar uma máquina física por trás de cada CPU virtual.
Um servidor dedicado confere ao projeto um limite de máquina física. Pode executar um sistema operativo ou alojar as suas próprias máquinas virtuais quando o hardware e a implementação suportam esse design. Isto altera a propriedade dos recursos e a administração, mas não elimina vulnerabilidades de software, trabalho de atualização ou a necessidade de cópias de segurança. Escolha o limite a partir de uma necessidade real de isolamento ou capacidade.
O KVM identifica uma tecnologia de virtualização
O KVM fornece suporte de virtualização no kernel Linux. O QEMU fornece um modelo de máquina e pode usar o KVM como acelerador de virtualização, enquanto software de gestão como o libvirt pode organizar a configuração e o ciclo de vida dos convidados. Estes componentes explicam como um ambiente pode ser construído; as letras KVM não especificam o agendamento de CPU, o desempenho do armazenamento ou a disponibilidade do serviço.
A documentação de virtualização distingue por vezes hipervisores de Tipo 1 e Tipo 2 de acordo com a sua relação com a plataforma anfitriã. Para uma decisão de alojamento, um rótulo é menos útil do que conhecer o limite do convidado, a responsabilidade de manutenção e o hardware exposto. Pergunte se o sistema operativo convidado e os controladores necessários são suportados. As funcionalidades descritas por um projeto de software não são automaticamente ativadas no produto de todos os fornecedores.
Não confunda o controlo do convidado com o controlo do anfitrião
O acesso de root ou de administrador dentro de um convidado permite-lhe gerir esse convidado. Não lhe dá acesso ao hipervisor físico, a outro inquilino ou a todas as funcionalidades possíveis do anfitrião. A virtualização aninhada, o encaminhamento de dispositivos e as configurações de rede especializadas exigem suporte explícito. Não selecione um VPS partindo do princípio de que uma capacidade disponível no seu portátil será exposta de forma idêntica pelo ambiente de alojamento.
Compare o CPU, a memória, o armazenamento, a rede e as licenças do plano real. Observe a latência e a pressão sobre os recursos da sua aplicação com trabalho representativo após a entrega. Uma tecnologia de virtualização pode criar um limite de isolamento útil enquanto continua a partilhar recursos de hardware subjacentes de acordo com a política do fornecedor. Nem um rótulo de convidado nem um rótulo dedicado substituem medições e uma especificação operacional completa.
| Limite | O que o projeto gere | Uma capacidade a verificar |
|---|---|---|
| Máquina virtual | O sistema operativo convidado e os seus serviços | Sistema operativo, controladores e funcionalidades expostas suportados |
| Contentor | Configuração de processos e imagens | Funcionalidades do kernel, limites e âmbito de montagem |
| Servidor dedicado | O ambiente de máquina física selecionado | Requisitos de hardware e virtualização |
Os contentores organizam processos dentro de um ambiente
Um contentor partilha normalmente o kernel do seu anfitrião enquanto agrupa processos e os seus recursos. Uma máquina virtual executa um kernel convidado. Pode executar contentores dentro de um VPS quando o sistema operativo e o runtime suportam a configuração pretendida. Essa combinação pode facilitar o empacotamento de dependências sem substituir a manutenção de segurança ou o plano de recuperação do convidado.
Os controlos de recursos do Docker exigem definições deliberadas: por predefinição, o runtime não impõe limites de CPU e de memória a cada contentor. Limite o uso de recursos e evite privilégios ou montagens do anfitrião desnecessários. Separe as cargas de trabalho com requisitos de confiança diferentes sempre que possível. Mantenha o anfitrião e as imagens atualizados. Trate uma imagem de contentor como software que tem de verificar, e não como uma decisão de segurança automática por ser fácil de iniciar.
A shell é um interpretador, não o próprio servidor
Um terminal fornece uma superfície de interação; uma shell interpreta comandos e inicia programas. No Linux, o Bash é uma shell comum, enquanto outras shells oferecem sintaxe e funcionalidades interativas diferentes. Um script tem de visar o interpretador que espera. Alterar a shell de início de sessão não altera o interpretador de todas as aplicações nem torna compatível um script escrito para outra shell.
A entrada da shell pode sofrer expansão, redirecionamento e substituição de comandos antes de um programa receber os seus argumentos. Compreenda esse processamento antes de construir comandos de manutenção a partir de nomes de ficheiros ou dados do utilizador. Mantenha entradas não fidedignas fora do texto de comandos executáveis, cite os argumentos corretamente e prefira a interface estruturada de um programa para trabalho automatizado. O histórico, os registos e os argumentos dos processos podem reter valores sensíveis, por isso utilize o mecanismo de credenciais privadas adequado à aplicação.
Opere o limite que escolheu
Após a entrega, identifique o sistema operativo convidado, a via de acesso e o mecanismo de recuperação. Aplique atualizações, crie uma conta de administração restrita e exponha apenas os serviços de que o projeto necessita. Teste uma pequena implementação antes de transferir dados importantes. Registe o runtime, as imagens e a configuração necessários para a reconstruir; o limite não lhe diz se o estado da aplicação é recuperável.
Utilize a comparação do SwissOctet para pré-selecionar a gama Vector, DeskLink ou Metal de acordo com a carga de trabalho e o ambiente operativo. Confirme as capacidades especializadas antes de preparar uma encomenda. Mantenha o trabalho do sistema operativo, o trabalho da aplicação e o trabalho do fornecedor distintos no manual de operações. Um limite claro é útil porque lhe diz o que pode configurar e o que tem de perguntar, preservando ao mesmo tempo um percurso prático para a migração e o restauro.
A sua lista de verificação prática.
- Distinga o acesso ao convidado do acesso ao anfitrião.
- Verifique os requisitos especializados de hardware e virtualização.
- Meça a configuração completa, não um rótulo de hipervisor.
- Configure os limites e as permissões dos contentores.
- Utilize a shell pretendida e proteja as entradas de comandos.
Os detalhes que importam.
O KVM significa que recebo núcleos CPU físicos dedicados?+
Não. O KVM identifica uma tecnologia de virtualização. Leia separadamente a atribuição de CPU e a política de recursos do produto.
Os contentores podem substituir a manutenção do convidado?+
Não. O ambiente anfitrião, o runtime de contentores e as imagens precisam todos de manutenção, permissões adequadas e planeamento de recuperação.
Um terminal e uma shell são a mesma coisa?+
Não. Um terminal fornece uma interface. Uma shell interpreta a entrada de comandos e inicia programas dentro dessa interface.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- Projeto KVM: Kernel Virtual Machine www.linux-kvm.org
- QEMU: Introdução à emulação de sistemas www.qemu.org
- Docker: Restrições de recursos docs.docker.com
- GNU Bash: Expansões da shell www.gnu.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.