Salve, Deus, beleza? Continuando a nossa saga aqui no nosso módulo de Docker, agora vamos falar de um outro recurso indispensável para containers, que são Cgroups. Lembra que a gente viu ali um histórico, um pouquinho do histórico dos containers, que em 2006 a Google criou esse recurso, que depois foi incorporado ali no kernel do Linux? Então, um Cgroup, que é um Control Group, ele é um grupo de configurações que vai incidir em um ou mais processos, fazendo com que isso limite o que esses processos podem usar de recursos do nosso sistema. Então, a gente consegue limitar CPU, memória, e isso é indispensável para os containers. Porque, imagina, a gente está rodando ali um monte de containers, de várias empresas, várias aplicações de uma mesma empresa, a gente não vai querer que tudo esteja disponível, 100% de memória, 100% de CPU, a gente vai querer fazer limitações, porque se isso consumir tudo, imagina mais um servidor, vai derrubar o servidor e vai derrubar todos os processos, vai derrubar todos os containers. Então, Cgroups é um recurso essencial não somente para os containers, mas também para sistemas operacionais. Então, eu coloquei aqui mais um texto para a gente poder consolidar o que vai ser visto aqui na aula. Vamos chegar aqui no Linux e a gente vai rodar o comando systemctl status. Nós vamos ver aqui uma árvore de coisas, que são os chamados slices. Todo o processo vai estar aliado a um cgroup e o slice é uma forma da gente delimitar isso. Então, eu tenho um slice que pode herdar de outro slice, acabando de formar essa árvore que a gente tem aqui. Eu posso dar um enter aqui, ele vai durante muito tempo ainda. Eu tenho até o Firefox aqui, tá vendo? Os processos do... Eu tenho o Firefox em aberto, eles estão também herdando ali de um slice, hoje em dia os navegadores acabam tendo vários processos, tem o parent que vai acabar cuidando dos child process dos navegadores, cada aba roda num processo para poder não derrubar. Se uma aba crachar, se está vendo alguma coisa ali, não derruba as outras. Então, todo processo, sem exceção, está dentro de um Cgroup. Tem, inclusive, formas de a gente delimitar esses Cgroups. Vou fazer um ls em barra cis. Barra cis, fs, C-group. A gente vai ver aqui vários tipos. Tem o Prox Pressure, o próprio Slice. Enfim, não vou entrar em mais detalhes, para a gente não é um curso avançado de Linux também, só para a gente poder ter uma ideia de como funciona ali por trás. Beleza. Como eu estou com o Firefox rodando aqui, a gente pode fazer um PS-AUX, um Gret Firefox, aqui a gente pode fazer um ps aux grep firefox que eu consigo pegar aqui um pd qualquer vamos pegar esse primeiro aqui então se eu for lá no diretório montado em barra proc vamos fazer um ls em barra proc, mais o id. Qual é o id? Onde usar a máquina virtual? Às vezes o ctrl 3685. 3685. Então aqui eu tenho as informações desse processo, são arquivos também, para não ficar fazendo lá system calls. E eu consigo acessar o cgroup. Então ele vai ser um arquivo que a gente acessa com o catcher. Então, aqui está o slice que define as limitações do processo. Então, tem... Está vendo como é um caminho? User slice, user new slice. Aí depois tem o app slice com o snapfirefox.scope. Então, a gente tem um slice para cada processo, a gente já viu isso, vamos brincar de fazer uma limitação agora. Eu vou fazer aqui um sudo vim barra etc. Barra systemd system limit app.slice. Todos os slices que eu quiser criar para poder brincar com eles e atribuir a outros processos, eu posso colocar exatamente nesse diretório. Na verdade, eu já criei o arquivo, e aí a gente coloca ali uma tag slice, e aí tem o CPU cota com 20%, que então vai usar no máximo 20% de CPU, e o máximo de memória. Eu tenho também outras informações que eu posso colocar, o mínimo de memória, enfim. Então, a gente delimita ali os recursos. Se eu fizer um ls nessa pasta aqui, nós vamos ver também que existem várias outras delimitações para os processos e tudo mais. Então, o nosso limite app.slice está aqui. Agora, a gente pode rodar aqui o comando sudo systemd run. Eu estou usando o systemd para poder rodar com o slice. .slice é igual ao limit app.slice com o meu usuário, que ele vai abrir aqui um novo shell. Vou colocar o meu usuário convencional, o UID Luiz, e menos menos shell, ele vai abrir uma telinha aqui para poder digitar, ah não, eu já tinha digitado o sudo aqui antes, mas nesse caso aqui ele valida com uma telinha. Então, apesar de não ter acontecido nada, ele abriu o novo terminal aqui para mim, e ele está sob esses lá sobre sobre essa limitação aí eu tenho um script python que a gente vai fazer ali um a outro é só para poder mostrar qualquer coisa pode fazer isso aí com que você quiser rodar um processo mas pelo menos que use alguma coisa de memória usa alguma coisa coisa de CPU pra gente poder brincar. Então eu vou rodar aqui um Python main.py. Ele vai ficar eternamente fazendo os prints. Ah, tem Python 3 aqui, né? Então pronto. Agora eu vou abrir aqui um outro terminal. Vamos rodar o comando htop e... Nossa, ficou muito grande. A gente vai ver aqui que tem ali o processo do Systemd run, que é um processo, mas o Python está aqui com um processo sobre o PID 4769. Está vendo que a CPU está fixa em 20%? A memória até que ficar fazendo um monte de print ali não vai executar nada em memória. A gente poderia ficar concatenando uma string ali e ia chegar um momento que iria chegar ao máximo de memória. Mas, enfim, então não somente esse processo, mas qualquer outro que eu rodar sobre esses slides, eu posso ter vários processos dentro desses slides. Estaria limitado lá aos 20% de memória, aos 20% de CPU e os 20 megas de memória. Então, a gente consegue aplicar essas limitações também aos containers. Isso é extremamente necessário. Então, pessoal, é legal isso, porque pegando aquele conceito lá do chroot, com onshare e os cgroups, a gente pode montar aí uma base para poder rodar containers. Mas como eu falei, a gente não vai ficar rodando containers dessa forma, e por trás acontecem outras coisas, inclusive já tem uma ferramenta que facilita rodar ali containers sem docker que a gente vai vendo aí nas próximas aulas. Mas o entendimento desse conceito de container, que ele é um processo que não tem virtualização aqui por trás, que eles estão compartilhando o kernel e que eles estão em um ambiente isolado rodando a mesma máquina é um entendimento crucial para você poder saber o que está acontecendo no final das contas. E até esclarece outras coisas em relação ao desenvolvimento de software. Então, vamos evoluindo na nossa saga. É isso aí e até a próxima.