Salve, Deus, beleza? Continuamos essa saga aqui no nosso módulo de Docker. Agora, vamos definir a diferença entre virtualização e containers. Eu tenho certeza que essa é uma dúvida que perdura e vai perdurar durante um bom tempo. Porque, primeiramente, a gente deva, pelo menos na minha época, a gente conhecia a virtualização, depois veio o container, e aí vem a comparação, né? Será que container vai substituir virtualização? Qual é a diferença? Se é a mesma coisa? Enfim, é muito importante que a gente saiba isso. Então, vamos aqui para o nosso material da aula. Essa imagem define justamente a diferença entre um e outro. Do lado direito, aqui a arquitetura de virtualização, que tem relação muito com o que a gente viu na aula passada com o Hypervisor. E do lado esquerdo, containers. Essa imagem que eu tirei lá da documentação da Docker. Na última aula, a gente viu que máquinas virtuais precisam de um Hypervisor, que vai ser um software que vai estar rodando em cima do seu sistema operacional, que vai estar gerenciando o hardware. Então, cada máquina virtual é um sistema operacional completo. Se eu tenho ali um Windows que está virtualizando o Linux, cada máquina virtual vai ser um Linux completo, com kernel, com tudo mais, para a gente poder rodar a nossa aplicação Java, para a gente poder rodar a nossa aplicação Python. Você já entendeu aonde eu estou querendo chegar. O custo disso é muito grande. Para eu poder compartilhar os recursos de hardware, para eu poder rodar aplicações diferentes, eu levanto uma máquina inteira. Então, foi por isso que surgiu containers. A ideia de um container é ser apenas um processo que vai compartilhar o sistema operacional com os outros processos. Eu não tenho um sistema operacional novo sendo emulado aqui. Então, por isso, uma diferença crucial para a máquina virtual é que se eu tiver um Windows, eu posso rodar containers Windows. Só, eu não posso rodar container Linux. Até no Windows eu consigo rodar um container Linux, mas é porque eu estou virtualizando lá o WSL. É uma máquina virtual. Como eu estou rodando o Linux, eu posso rodar um container Linux. Mas tirando isso fora, o container é feito para poder rodar no seu sistema operacional hospedeiro. Ele é apenas um processo que compartilha os recursos. Então, olha como que é mais eficiente, porque eu não tenho um novo sistema operacional que vai fazer overhead, etc. Vamos pensar assim, em alguns cenários, a gente quer ter máquinas que sejam capazes de emular um sistema operacional inteiro, que vão ter necessidades de indústria e de mercado que vão exigir isso. Mas boa parte hoje das aplicações, elas só querem rodar de forma isolada ali dentro de um Linux ou dentro do próprio Windows, porque a gente tem os containers do Windows. Então, isso aqui é muito mais eficiente. Ah, eu posso ter várias empresas compartilhando os recursos de hardware com seus containers totalmente isolados uns dos outros, mas eles estão utilizando ali o kernel. a Docker, esquece Docker, posso rodar container sem Docker. Eu não tenho que ter essa camadinha necessariamente aqui, essa camada não tem virtualização. Normalmente tem um software aqui só para poder gerenciar os containers, porque a gente tem que levantar o container, desligar o container, enfim, fazer essas coisas, então normalmente tem Docker ou alguma outra coisa. Então, em termos de vantagens e desvantagens em relação aos containers, eu tenho performance. Uma máquina virtual precisa de um hypervisor para funcionar, o que causa uma degradação de desempenho. A gente vai ter que essa camada, ali entra o sistema operacional e as máquinas virtuais. O tamanho também. Uma máquina virtual precisa de um sistema operacional completo. Então, eu gasto muito mais recursos, não só de CPU e memória, mas também de disco. Porque eu preciso ter um sistema operacional completo para poder rodar. Isso aí gasta disco. Inicialização. Como é um sistema operacional completo, faz com que seja muito mais custoso, vai demorar muito mais para iniciar, enquanto um container é um sistema operacional completo, faz com que seja muito mais custoso, vai demorar muito mais para iniciar, enquanto um container é um processo. Você pode, inclusive, fazer lá um comando no seu sistema operacional, você vai ver todos os processos dos containers. Enquanto numa máquina virtual, a máquina virtual está rodando dentro de um processo, você não consegue ver. Você consegue ver os processos lá da máquina virtual está rodando dentro de um processo, você não consegue ver. Você consegue ver os processos da máquina virtual se você entrar nela e usar algum monitor de processos. A gente tem também o gerenciamento. Como é um sistema operacional completo, faz com que ele seja difícil de gerenciar. Segurança, é aquela mesma história. Mas é o que eu falei também. Às vezes, você quer uma máquina virtual. Máquina virtual não vai acabar. Às vezes, você quer alugar uma máquina virtual para alguma situação específica. Mas hoje, boa parte do mercado necessita apenas de um container. Na verdade, essa ideia de container já surgiu na década de 70. A gente pode colocar o marco como o comando chroot do Unix, que é o change root, a gente vai trabalhar com ele nas próximas aulas. Ele permite que você pegue processos, processos, enjaula esses processos num subsistema de pastas ali do seu sistema operacional. Caso, aí do próprio Linux, um comando aqui nativo do próprio Linux. Então, a gente tem esse cenário aqui. Imagina que você tem lá o seu sistema operacional Linux rodando bonitinho, com a pasta bin, etc, home, usr e tudo mais. Então, tem uma subpasta ali que você executa esse chroot, e aí você vai ter essas subpastas que vão parecer que é um sistema operacional completo, mas, na verdade, vai ser apenas uma montagem, porque Linux é um sistema dinâmico, não necessariamente você está ali no sistema de passos, que isso está sendo representado fisicamente no disco. Mas você enjaula todos os processos. Então, tudo que a gente executasse ali de Java, PHP, veria somente essa parte. Até depois a gente teve o comando jail sendo lançado pela FreeBSD, mas o chroot permitia isso. Hoje ele é totalmente quebrável, você pode criar um script para poder hackear, ele quebra e um processo conseguiria ver toda a árvore do seu servidor. Mas aí você conseguiria fazer vários chroots para poder isolar aquela execução de processos ali. Então, o chroutes permitiu esse marco e ainda é utilizado, mas foi muito utilizado para poder fazer esse isolamento sem precisar de máquinas virtuais. A gente pode estabelecer que os anos 2000 foi um marco que surgiu tantas novas coisas que permitiu os containers como eles existem hoje. Em 2001, a FreeBSD lançou o Jail, que é essa jaula, que é essa ferramenta para poder isolar os processos num subsistema de pastas. Às vezes, dependendo do sistema operacional que você está usando e o seu Linux, já pode ter esse comando dentro dele para você poder brincar. Já em 2004, a Solaris lançou o Solaris Container, permitindo o isolamento desses ambientes com o Solaris Zones. A Zonas permitia que você isolasse usuários, processos, sistemas de arquivos, redes e outras coisas também. Mas aí, em 2006, aqui começou a gente ter um recurso que muda totalmente o jogo na hora de trabalhar com esses processos. A Google lançou o Cgroups. A gente vai trabalhar com isso aqui também. A gente vai entender. Ele, na prática, chama Control Groups, apenas um acrônimo. Ele permite isolar e limitar os recursos de um processo. Porque aqui com o Cegahoot, que isolava os processos somente nesse sistema de arquivos, você não conseguia limitar para os processos que eram rodados aqui dentro. Ah, não, você vai usar apenas tanto de CPU e de memória. Você usava o que tinha de disponível da máquina. Então, com o Cgroups, a gente consegue fazer essas limitações para os processos. Aí aconteceu que em 2008, esse Cgroups foi integrado ao kernel do Linux. Então, o Linux que você está na sua máquina hoje, já tem esse recurso nativamente. A gente vai brincar com ele na prática e vai ficar claro essas limitações. Um outro recurso também que ajudou bastante a trabalhar com os containers como a gente tem hoje são os namespaces, permitindo de fato ter um isolamento das montagens do barra proc e de outras coisas também do Linux. Em 2008 também, por iniciativa da Google, da IBM, da Virtuoso e outras empresas, foi criado o LXC, que é a Linux Containers, uma ferramenta que permitia isolar os processos. Você conseguia fazer esse isolamento todo e acabou se criando um padrão que várias empresas foram utilizando. Se utilizava bastante o chroot também como princípio. Enfim, em 2010 nós tivemos a fundação da Docker Company. Depois a gente vai ver um pouco mais de detalhes sobre isso. E aí em 2013, somente três anos depois da empresa, teve o lançamento do Docker como um projeto open source, e aí o uso de containers ficou ainda mais popularizado. E eles acabaram lançando uma ferramenta chamada de libcontainers, que acabou depois substituindo o LXC, que acabou depois virando o RunC. A gente vai entender tudo isso, mas só para você poder entender que esse RunC acabou depois virando o padrão para poder fazer a execução de containers, mas também em 2015 foi criada a Open Container Initiative como um projeto open source para poder ter um padrão de mercado, porque não adianta nada cada empresa criar o seu padrão e isso não evoluiria, a gente não conseguiria ter essa forma tão simples hoje de rodar containers como a gente tem hoje. Qualquer um pode criar o seu padrão de containers, mas deixe que respeite o que está aqui no OCI. Então, esse projeto hoje está na Linux Foundation e conta com a participação de várias empresas, a própria Doc, a Google, a IBM, Microsoft, Oracle, Red Hat, enfim. Então, esse aqui foi o cenário que a gente teve. Então, isso aqui é muito esclarecedor, a esse aqui foi o cenário que a gente teve então isso aqui é muito esclarecedor a gente saber que o container é apenas um processo a gente vai ver na prática aí vai ficar totalmente claro, mas a ideia é sempre essa, container vai ser sempre infinitamente mais leve do que máquinas virtuais, então pessoal vamos continuar nossa saga, é isso aí e até a próxima