Ir para o conteúdo

Virtualização em nível de sistema operacional

Origem: Wikipédia, a enciclopédia livre.

A virtualização em nível de sistema operacional é um paradigma de virtualização de sistema operacional (SO) no qual o núcleo (kernel) permite a existência de múltiplas instâncias isoladas de espaço de usuário, chamadas de contêineres (LXC, Solaris Containers, AIX WPARs, HP-UX SRP Containers, Docker, Podman, Guix), zonas (Solaris Containers), servidores virtuais privados (OpenVZ), partições, ambientes virtuais (VEs), núcleos virtuais (DragonFly BSD) e jails (FreeBSD jail e chroot).[1] Tais instâncias podem parecer computadores reais do ponto de vista dos programas executados nelas. Um programa de computador executado em um sistema operacional comum pode ver todos os recursos (dispositivos conectados, arquivos e pastas, compartilhamentos de rede, potência da CPU, capacidades de hardware quantificáveis) daquele computador. Programas executados dentro de um contêiner só podem ver o conteúdo do contêiner e os dispositivos atribuídos a ele.

Em sistemas operacionais Unix-like, esse recurso pode ser visto como uma implementação avançada do mecanismo padrão chroot, que altera a pasta raiz aparente para o processo atual em execução e seus filhos. Além dos mecanismos de isolamento, o núcleo frequentemente fornece recursos de gerenciamento de recursos para limitar o impacto das atividades de um contêiner em outros contêineres. Os contêineres Linux são todos baseados nos mecanismos de virtualização, isolamento e gerenciamento de recursos fornecidos pelo núcleo Linux, notadamente namespaces e cgroups.[2]

Embora a palavra contêiner se refira mais comumente à virtualização em nível de SO, às vezes é usada para se referir a máquinas virtuais mais completas que operam em variados graus de concerto com o SO hospedeiro,[carece de fontes?] como os contêineres Hyper-V da Microsoft.[carece de fontes?] Para uma visão geral da virtualização desde 1960, consulte Cronologia das tecnologias de virtualização.

Operação

[editar | editar código]

Em sistemas operacionais comuns para computadores pessoais, um programa de computador pode ver (embora possa não ser capaz de acessar) todos os recursos do sistema. Eles incluem:

O sistema operacional pode permitir ou negar o acesso a tais recursos com base em qual programa os solicita e na conta de usuário no contexto em que é executado. O sistema operacional também pode ocultar esses recursos para que, quando o programa de computador os enumerar, eles não apareçam nos resultados da enumeração. No entanto, do ponto de vista da programação, o programa de computador interagiu com esses recursos e o sistema operacional gerenciou um ato de interação.

Com a virtualização em nível de sistema operacional, ou conteinerização, é possível executar programas dentro de contêineres, aos quais apenas partes desses recursos são alocadas. Um programa que espera ver o computador inteiro, uma vez executado dentro de um contêiner, pode ver apenas os recursos alocados e acredita que eles são tudo o que está disponível. Vários contêineres podem ser criados em cada sistema operacional, para cada um dos quais um subconjunto dos recursos do computador é alocado. Cada contêiner pode conter qualquer número de programas de computador. Esses programas podem ser executados simultaneamente ou separadamente e podem até interagir uns com os outros.

A conteinerização tem semelhanças com a virtualização de aplicativos: nesta última, apenas um programa de computador é colocado em um contêiner isolado e o isolamento se aplica apenas ao sistema de arquivos.

A virtualização em nível de sistema operacional é comumente usada em ambientes de hospedagem virtual, onde é útil para alocar de forma segura recursos de hardware finitos entre um grande número de usuários que desconfiam mutuamente entre si. Os administradores de sistema também podem usá-la para consolidar o hardware do servidor, movendo serviços em hosts separados para contêineres em um único servidor.

A virtualização em nível de sistema operacional também pode ser usada para executar software criado para uma determinada distribuição Linux em outra distribuição; um exemplo é o Distrobox.[3]

Outros cenários típicos incluem a separação de vários programas em contêineres distintos para melhor segurança, independência de hardware e recursos adicionais de gerenciamento de recursos.[4] No entanto, a segurança aprimorada fornecida pelo uso de um mecanismo chroot não é perfeita.[5] Implementações de virtualização em nível de sistema operacional capazes de migração ao vivo também podem ser usadas para balanceamento de carga dinâmico de contêineres entre nós em um cluster.

Sobrecarga

[editar | editar código]

A virtualização em nível de sistema operacional geralmente impõe menos sobrecarga do que a virtualização total porque os programas em partições virtuais de nível de SO usam a interface de chamada de sistema normal do sistema operacional e não precisam ser submetidos a emulação ou ser executados em uma máquina virtual intermediária, como é o caso da virtualização total (como VMware ESXi, QEMU ou Hyper-V) e da paravirtualização (como Xen ou User-mode Linux). Esta forma de virtualização também não requer suporte de hardware para um desempenho eficiente.

Flexibilidade

[editar | editar código]

A virtualização em nível de sistema operacional não é tão flexível quanto outras abordagens de virtualização, pois não pode hospedar um sistema operacional convidado diferente do hospedeiro, ou um núcleo convidado diferente. Por exemplo, com o Linux, diferentes distribuições funcionam bem, mas outros sistemas operacionais, como o Windows, não podem ser hospedados. Sistemas operacionais que usam sistemáticas de entrada variável estão sujeitos a limitações dentro da arquitetura virtualizada. Métodos de adaptação, incluindo análises de retransmissão de servidor em nuvem, mantêm o ambiente virtual de nível de SO dentro dessas aplicações.[6]

O Solaris supera parcialmente a limitação descrita acima com seu recurso de branded zones, que fornece a capacidade de executar um ambiente dentro de um contêiner que emula uma versão mais antiga do Solaris 8 ou 9 em um host Solaris 10. "Linux branded zones" (referidas como zonas de marca "lx") também estão disponíveis em sistemas Solaris baseados em x86, fornecendo um espaço de usuário Linux completo e suporte para a execução de aplicativos Linux; além disso, o Solaris fornece utilitários necessários para instalar as distribuições Red Hat Enterprise Linux 3.x ou CentOS 3.x dentro de zonas "lx".[7][8] No entanto, em 2010, as zonas de marca Linux foram removidas do Solaris; em 2014, elas foram reintroduzidas no Illumos, que é a bifurcação (fork) de código aberto do Solaris, suportando núcleos Linux de 32 bits.

Armazenamento

[editar | editar código]

Algumas implementações fornecem mecanismos de copy-on-write (CoW) em nível de arquivo. (Mais comumente, um sistema de arquivos padrão é compartilhado entre as partições, e aquelas partições que alteram os arquivos criam automaticamente suas próprias cópias.) Isso é mais fácil de fazer backup, mais eficiente em termos de espaço e mais simples de armazenar em cache do que os esquemas de copy-on-write em nível de bloco comuns em virtualizadores de sistema completo. Virtualizadores de sistema completo, no entanto, podem trabalhar com sistemas de arquivos não nativos e criar e reverter snapshots de todo o estado do sistema.

Implementações

[editar | editar código]

Implementações mantidas ativamente / em desenvolvimento

[editar | editar código]
Mecanismo Sistema
operacional
Licença Início
do
desenvolvimento
Recursos
Isolamento de
sistema de arquivos
Limitação de
taxa de E/S
Limites de memória
Isolamento
de rede
Virtualização
aninhada
Checkpointing e
migração ao vivo
Isolamento de
privilégios de root
chroot A maioria dos sistemas UNIX-like Varia por sistema 1982 Parcial
[a]
Não Não Não Não Não Não Sim Não Não
Docker Linux,[10] Windows x64[11] macOS[12] Apache License 2.0 2013 Sim Sim Parcial
[b]
Sim (desde 1.10) Sim Sim Sim Sim Apenas em modo experimental com CRIU[14] Sim (desde 1.10)
Podman Linux, Windows, macOS, FreeBSD Apache License 2.0 2018 Sim Sim Sim
[15]
Sim Sim Sim Sim Sim Sim
[16]
Sim
LXC Linux GNU GPLv2 2008 Sim
[17]
Sim Parcial
[c]
Parcial
[d]
Sim Sim Sim Sim Sim Sim
[17]
Apptainer (fork do Singularity[18]) Linux Licença BSD 2015
[19]
Sim
[20]
Sim Sim Não Não Não Não Não Não Sim
[21]
OpenVZ Linux GNU GPLv2 2005 Sim Sim
[22]
Sim Sim
[e]
Sim Sim Sim
[f]
Parcial
[g]
Sim Sim
[h]
Virtuozzo Linux, Windows Trialware 2000
[26]
Sim Sim Sim Sim
[i]
Sim Sim Sim
[f]
Parcial
[j]
Sim Sim
Solaris Containers (Zones) illumos (OpenSolaris),
Solaris
CDDL,
Proprietário
2004 Sim Sim (ZFS) Sim Parcial
[k]
Sim Sim Sim
[l]
[29][30]
Parcial
[m]
Parcial[n][o] Sim
[p]
FreeBSD jail FreeBSD, DragonFly BSD Licença BSD 2000
[32]
Sim Sim (ZFS) Sim
[q]
Sim Sim
[33]
Sim Sim
[34]
Sim Parcial
[35][36]
Sim
[37]
vkernel DragonFly BSD Licença BSD 2006
[38]
Sim
[39]
Sim
[39]
? Sim
[40]
Sim
[40]
Sim
[41]
? ? Sim
WPARs AIX Software proprietário comercial 2007 Sim Não Sim Sim Sim Sim Sim
[r]
Não Sim
[43]
?
iCore Virtual Accounts Windows XP Freeware 2008 Sim Não Sim Não Não Não Não ? Não ?
Sandboxie Windows GNU GPLv3 2004 Sim Sim Parcial Não Não Não Parcial Não Não Sim
systemd-nspawn Linux GNU LGPLv2.1+ 2010 Sim Sim Sim
[44][45]
Sim
[44][45]
Sim
[44][45]
Sim
[44][45]
Sim Sim
[s]
? Sim
Turbo Windows Freemium 2012 Sim Não Não Não Não Não Sim Não Não Sim

Implementações históricas / defuntas

[editar | editar código]
Mecanismo Sistema
operacional
Licença Ativamente
desenvolvido
desde
ou
entre
Recursos
Isolamento de
sistema de arquivos
Limitação de
taxa de E/S
Limites de memória
Isolamento
de rede
Virtualização
aninhada
Checkpointing e
migração ao vivo
Isolamento de
privilégios de root
Linux-VServer
(contexto de segurança)
Linux, Windows Server 2016 GNU GPLv2 2001~2018 Sim Sim Sim Sim
[t]
Sim Sim Parcial
[u]
? Não Parcial
[v]
lmctfy Linux Apache License 2.0 2013~2015 Sim Sim Sim Sim
[t]
Sim Sim Parcial
[u]
? Não Parcial
[v]
sysjail OpenBSD, NetBSD Licença BSD 2006~2009 Sim Não Não Não Não Não Sim Não Não ?
rkt (rocket) Linux Apache License 2.0 2014~2018 Sim Sim Sim Sim Sim Sim Sim ? ? Sim

Ver também

[editar | editar código]
  1. O usuário root pode escapar facilmente do chroot. O chroot nunca foi planejado para ser usado como um mecanismo de segurança.[9]
  2. Para drivers de armazenamento btrfs, overlay2, windowsfilter e zfs. [13]
  3. Cotas de disco por contêiner são possíveis ao usar partições separadas para cada contêiner com a ajuda do LVM, ou quando o sistema de arquivos do host subjacente é btrfs, caso em que os subvolumes btrfs são usados automaticamente.
  4. A limitação da taxa de E/S é suportada ao usar Btrfs.
  5. Disponível desde o núcleo Linux 2.6.18-028stable021. A implementação é baseada no escalonador de E/S de disco CFQ, mas é um esquema de dois níveis, portanto a prioridade de E/S não é por processo, mas sim por contêiner.[23]
  6. 1 2 Cada contêiner pode ter seus próprios endereços IP, regras de firewall, tabelas de roteamento e assim por diante. Três esquemas de rede diferentes são possíveis: baseado em rota, baseado em bridge e atribuição de um dispositivo de rede real (NIC) a um contêiner.
  7. Contêineres Docker podem rodar dentro de contêineres OpenVZ.[24]
  8. Cada contêiner pode ter acesso root sem possivelmente afetar outros contêineres.[25]
  9. Disponível desde a versão 4.0, janeiro de 2008.
  10. Contêineres Docker podem rodar dentro de contêineres Virtuozzo.[27]
  11. Sim com illumos[28]
  12. Veja Virtualização de rede e controle de recursos do Solaris para mais detalhes.
  13. Apenas quando o nível superior é uma zona KVM (illumos) ou uma zona kz (Oracle).
  14. Começando no Solaris 11.3 Beta, as Solaris Kernel Zones podem usar migração ao vivo.
  15. Migração a frio (desligar-mover-reiniciar) está implementada.
  16. Zonas não globais são restritas para que não afetem outras zonas através de uma abordagem de limitação de recursos. A zona global pode administrar as zonas não globais.[31]
  17. Verifique a opção "allow.quotas" e a seção "Jails and file systems" na página de manual do jail do FreeBSD para detalhes.
  18. Disponível desde TL 02.[42]
  19. Para KVM, o contêiner pai requer acesso rw a /dev/kvm.
  20. 1 2 Usando o escalonador CFQ, existe uma fila separada por convidado.
  21. 1 2 A rede é baseada em isolamento, não em virtualização.
  22. 1 2 Um total de 14 capacidades de usuário são consideradas seguras dentro de um contêiner. O restante não pode ser concedido a processos dentro desse contêiner sem permitir que esse processo interfira potencialmente em coisas fora dele.[46]

Referências

[editar | editar código]
  1. Hogg, Scott (26 de maio de 2014). «Software containers: Used more frequently than most realize». Network World. Network world, Inc. Consultado em 9 de julho de 2015. Existem muitos outros sistemas de virtualização em nível de SO, como: Linux OpenVZ, Linux-VServer, FreeBSD Jails, AIX Workload Partitions (WPARs), HP-UX Containers (SRP), Solaris Containers, entre outros.
  2. Rami, Rosen. «Namespaces and Cgroups, the basis of Linux Containers» (PDF). Consultado em 18 de agosto de 2016
  3. Brockmeier, Joe (10 de dezembro de 2025). «Mix and match Linux distributions with Distrobox». LWN.net (em inglês). Consultado em 17 de janeiro de 2026
  4. «Secure Bottlerocket deployments on Amazon EKS with KubeArmor | Containers». aws.amazon.com (em inglês). 20 de outubro de 2022. Consultado em 20 de junho de 2023
  5. Korff, Yanek; Hope, Paco; Potter, Bruce (2005). Mastering FreeBSD and OpenBSD security. Col: O'Reilly Series. [S.l.]: O'Reilly Media, Inc. p. 59. ISBN 0-596-00626-8
  6. Huang, D. (2015). «Experiences in using os-level virtualization for block I/O». Proceedings of the 10th Parallel Data Storage Workshop (PDF). [S.l.: s.n.] pp. 13–18. ISBN 978-1-4503-4008-3. doi:10.1145/2834976.2834982
  7. «System administration guide: Oracle Solaris containers-resource management and Oracle Solaris zones, Chapter 16: Introduction to Solaris zones». Oracle Corporation. 2010. Consultado em 2 de setembro de 2014
  8. «System administration guide: Oracle Solaris containers-resource management and Oracle Solaris zones, Chapter 31: About branded zones and the Linux branded zone». Oracle Corporation. 2010. Consultado em 2 de setembro de 2014
  9. «3.5. Limiting your program's environment». freebsd.org
  10. «Docker drops LXC as default execution environment». InfoQ
  11. «Install Docker desktop on Windows | Docker documentation». Docker. 9 de fevereiro de 2023
  12. «Get started with Docker desktop for Mac». Docker documentation. 6 de dezembro de 2019
  13. «docker container run - Set storage driver options per container (--storage-opt)». docs.docker.com. 22 de fevereiro de 2024
  14. «Docker - CRIU». criu.org. Consultado em 20 de julho de 2026
  15. «podman-volume-create — Podman documentation». docs.podman.io. Consultado em 19 de outubro de 2025
  16. «podman-container-checkpoint — Podman documentation». docs.podman.io. Consultado em 19 de outubro de 2025
  17. 1 2 Graber, Stéphane (1 de janeiro de 2014). «LXC 1.0: Security features [6/10]». Consultado em 12 de fevereiro de 2014. LXC agora tem suporte para namespaces de usuário. [...] O LXC não é mais executado como root, portanto, mesmo que um invasor consiga escapar do contêiner, ele se encontrará com os privilégios de um usuário comum no host.
  18. «Community Announcement | Apptainer - Portable, Reproducible Containers». apptainer.org. 30 de novembro de 2021. Consultado em 19 de outubro de 2025
  19. «Sylabs brings Singularity containers into commercial HPC | Top 500 supercomputer sites». Top500.org
  20. «SIF — Containing your containers». Sylabs.io. 14 de março de 2018
  21. Kurtzer, Gregory M.; Sochat, Vanessa; Bauer, Michael W. (11 de maio de 2017). «Singularity: Scientific containers for mobility of compute». PLOS ONE. 12 (5). Bibcode:2017PLoSO..1277459K. PMC 5426675Acessível livremente. PMID 28494014. doi:10.1371/journal.pone.0177459Acessível livremente
  22. Bronnikov, Sergey. «Comparison on OpenVZ wiki page». OpenVZ Wiki. OpenVZ. Consultado em 28 de dezembro de 2018
  23. «I/O priorities for containers». OpenVZ Virtuozzo Containers Wiki
  24. «Docker inside CT». Openvz.org
  25. «Container». Wiki.openvz.org
  26. «Initial public prerelease of Virtuozzo (named ASPcomplete at that time)». Paul.sladen.org. Consultado em 20 de julho de 2026
  27. «Parallels Virtuozzo now provides native support for Docker». Consultado em 3 de junho de 2015. Cópia arquivada em 13 de maio de 2016
  28. Pijewski, Bill (1 de março de 2011). «Our ZFS I/O Throttle». wdp.dtrace.org
  29. Network virtualization and resource control (Crossbow) FAQ Arquivado em 2008-06-01 no Wayback Machine
  30. «Managing network virtualization and network resources in Oracle® Solaris 11.4». docs.oracle.com
  31. Oracle Solaris 11.1 administration, Oracle Solaris zones, Oracle Solaris 10 zones and resource management E29024.pdf, pp. 356360.
  32. «Contain your enthusiasm - Part two: Jails, zones, OpenVZ, and LXC». Jails foram introduzidos pela primeira vez no FreeBSD 4.0 em 2000
  33. «Hierarchical resource limits - FreeBSD Wiki». Wiki.freebsd.org. 27 de outubro de 2012. Consultado em 15 de janeiro de 2014
  34. Zec, Marko (13 de junho de 2003). «Implementing a clonable network stack in the FreeBSD kernel» (PDF). usenix.org
  35. «VPS for FreeBSD». Consultado em 20 de fevereiro de 2016
  36. «[Announcement] VPS // OS virtualization // alpha release». 31 de agosto de 2012. Consultado em 20 de fevereiro de 2016
  37. «3.5. Limiting your program's environment». Freebsd.org. Consultado em 15 de janeiro de 2014
  38. Matthew Dillon (2006). «sys/vkernel.h». BSD cross reference. DragonFly BSD
  39. 1 2 «vkd(4) — Virtual kernel disc». DragonFly BSD. trata a imagem de disco como copy-on-write.
  40. 1 2 Sascha Wildner (8 de janeiro de 2007). «vkernel, vcd, vkd, vke — virtual kernel architecture». DragonFly miscellaneous information manual. DragonFly BSD
  41. «vkernel, vcd, vkd, vke - virtual kernel architecture». DragonFly On-Line Manual Pages. DragonFly BSD
  42. «IBM fix pack information for: WPAR network isolation - United States». ibm.com. 21 de julho de 2011
  43. «Live application mobility in AIX 6.1». Ibm.com. 3 de junho de 2008
  44. 1 2 3 4 «systemd-nspawn». Freedesktop.org
  45. 1 2 3 4 «2.3. Modifying control groups Red Hat Enterprise Linux 7». Red Hat Customer portal
  46. «Paper - Linux-VServer». linux-vserver.org