Virtualização em nível de sistema operacional
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:
- Capacidades de hardware que podem ser empregadas, como a CPU e a conexão de rede
- Dados que podem ser lidos ou gravados, como arquivos, pastas e compartilhamentos de rede
- Periféricos conectados com os quais pode interagir, como webcam, impressora, scanner ou fax
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.
Usos
[editar | editar código]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]Notas
[editar | editar código]- ↑ O usuário root pode escapar facilmente do chroot. O chroot nunca foi planejado para ser usado como um mecanismo de segurança.[9]
- ↑ Para drivers de armazenamento btrfs, overlay2, windowsfilter e zfs. [13]
- ↑ 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.
- ↑ A limitação da taxa de E/S é suportada ao usar Btrfs.
- ↑ 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]
- 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.
- ↑ Contêineres Docker podem rodar dentro de contêineres OpenVZ.[24]
- ↑ Cada contêiner pode ter acesso root sem possivelmente afetar outros contêineres.[25]
- ↑ Disponível desde a versão 4.0, janeiro de 2008.
- ↑ Contêineres Docker podem rodar dentro de contêineres Virtuozzo.[27]
- ↑ Sim com illumos[28]
- ↑ Veja Virtualização de rede e controle de recursos do Solaris para mais detalhes.
- ↑ Apenas quando o nível superior é uma zona KVM (illumos) ou uma zona kz (Oracle).
- ↑ Começando no Solaris 11.3 Beta, as Solaris Kernel Zones podem usar migração ao vivo.
- ↑ Migração a frio (desligar-mover-reiniciar) está implementada.
- ↑ 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]
- ↑ 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.
- ↑ Disponível desde TL 02.[42]
- ↑ Para KVM, o contêiner pai requer acesso rw a /dev/kvm.
- 1 2 Usando o escalonador CFQ, existe uma fila separada por convidado.
- 1 2 A rede é baseada em isolamento, não em virtualização.
- 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]- ↑ 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.
- ↑ Rami, Rosen. «Namespaces and Cgroups, the basis of Linux Containers» (PDF). Consultado em 18 de agosto de 2016
- ↑ 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
- ↑ «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
- ↑ 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
- ↑ 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
- ↑ «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
- ↑ «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
- ↑ «3.5. Limiting your program's environment». freebsd.org
- ↑ «Docker drops LXC as default execution environment». InfoQ
- ↑ «Install Docker desktop on Windows | Docker documentation». Docker. 9 de fevereiro de 2023
- ↑ «Get started with Docker desktop for Mac». Docker documentation. 6 de dezembro de 2019
- ↑ «docker container run - Set storage driver options per container (--storage-opt)». docs.docker.com. 22 de fevereiro de 2024
- ↑ «Docker - CRIU». criu.org. Consultado em 20 de julho de 2026
- ↑ «podman-volume-create — Podman documentation». docs.podman.io. Consultado em 19 de outubro de 2025
- ↑ «podman-container-checkpoint — Podman documentation». docs.podman.io. Consultado em 19 de outubro de 2025
- 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.
- ↑ «Community Announcement | Apptainer - Portable, Reproducible Containers». apptainer.org. 30 de novembro de 2021. Consultado em 19 de outubro de 2025
- ↑ «Sylabs brings Singularity containers into commercial HPC | Top 500 supercomputer sites». Top500.org
- ↑ «SIF — Containing your containers». Sylabs.io. 14 de março de 2018
- ↑ 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 5426675
. PMID 28494014. doi:10.1371/journal.pone.0177459
- ↑ Bronnikov, Sergey. «Comparison on OpenVZ wiki page». OpenVZ Wiki. OpenVZ. Consultado em 28 de dezembro de 2018
- ↑ «I/O priorities for containers». OpenVZ Virtuozzo Containers Wiki
- ↑ «Docker inside CT». Openvz.org
- ↑ «Container». Wiki.openvz.org
- ↑ «Initial public prerelease of Virtuozzo (named ASPcomplete at that time)». Paul.sladen.org. Consultado em 20 de julho de 2026
- ↑ «Parallels Virtuozzo now provides native support for Docker». Consultado em 3 de junho de 2015. Cópia arquivada em 13 de maio de 2016
- ↑ Pijewski, Bill (1 de março de 2011). «Our ZFS I/O Throttle». wdp.dtrace.org
- ↑ Network virtualization and resource control (Crossbow) FAQ Arquivado em 2008-06-01 no Wayback Machine
- ↑ «Managing network virtualization and network resources in Oracle® Solaris 11.4». docs.oracle.com
- ↑ Oracle Solaris 11.1 administration, Oracle Solaris zones, Oracle Solaris 10 zones and resource management E29024.pdf, pp. 356–360.
- ↑ «Contain your enthusiasm - Part two: Jails, zones, OpenVZ, and LXC».
Jails foram introduzidos pela primeira vez no FreeBSD 4.0 em 2000
- ↑ «Hierarchical resource limits - FreeBSD Wiki». Wiki.freebsd.org. 27 de outubro de 2012. Consultado em 15 de janeiro de 2014
- ↑ Zec, Marko (13 de junho de 2003). «Implementing a clonable network stack in the FreeBSD kernel» (PDF). usenix.org
- ↑ «VPS for FreeBSD». Consultado em 20 de fevereiro de 2016
- ↑ «[Announcement] VPS // OS virtualization // alpha release». 31 de agosto de 2012. Consultado em 20 de fevereiro de 2016
- ↑ «3.5. Limiting your program's environment». Freebsd.org. Consultado em 15 de janeiro de 2014
- ↑ Matthew Dillon (2006). «sys/vkernel.h». BSD cross reference. DragonFly BSD
- 1 2 «vkd(4) — Virtual kernel disc». DragonFly BSD.
trata a imagem de disco como copy-on-write.
- 1 2 Sascha Wildner (8 de janeiro de 2007). «vkernel, vcd, vkd, vke — virtual kernel architecture». DragonFly miscellaneous information manual. DragonFly BSD
- ↑ «vkernel, vcd, vkd, vke - virtual kernel architecture». DragonFly On-Line Manual Pages. DragonFly BSD
- ↑ «IBM fix pack information for: WPAR network isolation - United States». ibm.com. 21 de julho de 2011
- ↑ «Live application mobility in AIX 6.1». Ibm.com. 3 de junho de 2008
- 1 2 3 4 «systemd-nspawn». Freedesktop.org
- 1 2 3 4 «2.3. Modifying control groups Red Hat Enterprise Linux 7». Red Hat Customer portal
- ↑ «Paper - Linux-VServer». linux-vserver.org