{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"O que \u00e9 Docker: um breve hist\u00f3rico e as principais abstra\u00e7\u00f5es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

10 de agosto come\u00e7ou em Sloerm um curso em v\u00eddeo sobre Docker<\/a><\/noindex>, onde analisamos completamente \u2014 desde as abstra\u00e7\u00f5es b\u00e1sicas at\u00e9 par\u00e2metros de rede. <\/p>\n

<\/p>\n

Neste artigo, vamos falar sobre a hist\u00f3ria do Docker e suas principais abstra\u00e7\u00f5es: Image, CLI, Dockerfile. A palestra \u00e9 voltada para iniciantes, por isso dificilmente ser\u00e1 interessante para usu\u00e1rios experientes. N\u00e3o haver\u00e1 sangue, apendicite ou mergulhos profundos. Apenas o b\u00e1sico.<\/p>\n

<\/p>\n

\"O<\/p>\n

<\/a><\/noindex><\/p>\n

O que \u00e9 Docker<\/h2>\n

<\/p>\n

Vamos conferir a defini\u00e7\u00e3o do Docker na Wikip\u00e9dia.<\/p>\n

<\/p>\n

Docker \u00e9 um software para automa\u00e7\u00e3o do deploy e gest\u00e3o de aplica\u00e7\u00f5es em ambientes que suportam containeriza\u00e7\u00e3o.<\/p><\/blockquote>\n

Dessa defini\u00e7\u00e3o, nada \u00e9 claro. Especialmente o que significa 'em ambientes que suportam containeriza\u00e7\u00e3o'. Para entender, vamos voltar no tempo. Come\u00e7aremos na \u00e9poca que chamo de 'Era Monol\u00edtica'.<\/p>\n

<\/p>\n

Era Monol\u00edtica<\/h2>\n

<\/p>\n

A Era Monol\u00edtica \u00e9 o in\u00edcio dos anos 2000, quando todas as aplica\u00e7\u00f5es eram monol\u00edticas, com muitas depend\u00eancias. O desenvolvimento era demorado. Naquela \u00e9poca, havia poucos servidores, conhec\u00edamos todos pelo nome e monitor\u00e1vamos. H\u00e1 uma compara\u00e7\u00e3o interessante:<\/p>\n

\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Pets \u2014 s\u00e3o animais de estima\u00e7\u00e3o. Na era monol\u00edtica, trat\u00e1vamos nossos servidores como animais de estima\u00e7\u00e3o, cuid\u00e1vamos e os zel\u00e1vamos, tirando a poeira. E para melhor gest\u00e3o dos recursos, utiliz\u00e1vamos virtualiza\u00e7\u00e3o: peg\u00e1vamos um servidor e divid\u00edamos em v\u00e1rias m\u00e1quinas virtuais, garantindo assim o isolamento do ambiente.<\/p>\n

<\/p>\n

Sistemas de virtualiza\u00e7\u00e3o baseados em hipervisor<\/h2>\n

<\/p>\n

Certamente, todos j\u00e1 ouviram falar de sistemas de virtualiza\u00e7\u00e3o: VMware, VirtualBox, Hyper-V, Qemu KVM etc. Eles fornecem isolamento de aplica\u00e7\u00f5es e gest\u00e3o de recursos, mas t\u00eam suas desvantagens. Para fazer a virtualiza\u00e7\u00e3o, \u00e9 necess\u00e1rio um hipervisor. E um hipervisor significa um overhead de recursos. Al\u00e9m disso, a pr\u00f3pria m\u00e1quina virtual geralmente \u00e9 grande \u2014 uma imagem pesada, com sistema operacional, Nginx, Apache e possivelmente MySQL. A imagem \u00e9 grande, operar com a m\u00e1quina virtual pode ser inconveniente. Como consequ\u00eancia, o trabalho com m\u00e1quinas virtuais pode ser lento. Para resolver esse problema, foram criados sistemas de virtualiza\u00e7\u00e3o em n\u00edvel de kernel.<\/p>\n

<\/p>\n

Sistemas de virtualiza\u00e7\u00e3o em n\u00edvel de kernel<\/h2>\n

<\/p>\n

A virtualiza\u00e7\u00e3o em n\u00edvel de kernel \u00e9 suportada por sistemas como OpenVZ, Systemd-nspawn, LXC. Um exemplo claro dessa virtualiza\u00e7\u00e3o \u00e9 o LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 um sistema de virtualiza\u00e7\u00e3o no n\u00edvel do sistema operacional que permite executar v\u00e1rias inst\u00e2ncias isoladas do sistema operacional Linux em um \u00fanico n\u00f3. LXC n\u00e3o utiliza m\u00e1quinas virtuais, mas cria um ambiente virtual com seu pr\u00f3prio espa\u00e7o de processos e pilha de rede.<\/p>\n

<\/p>\n

Basicamente, o LXC cria cont\u00eaineres. Qual \u00e9 a diferen\u00e7a entre m\u00e1quinas virtuais e cont\u00eaineres?<\/p>\n

<\/p>\n

\"O<\/p>\n

<\/p>\n

Um cont\u00eainer n\u00e3o \u00e9 adequado para isolar processos: em sistemas de virtualiza\u00e7\u00e3o no n\u00edvel do kernel, foram encontradas vulnerabilidades que permitem escapar do cont\u00eainer para o host. Portanto, se voc\u00ea precisa isolar algo, \u00e9 melhor usar uma m\u00e1quina virtual.<\/p>\n

<\/p>\n

As diferen\u00e7as entre virtualiza\u00e7\u00e3o e conteineriza\u00e7\u00e3o podem ser vistas no esquema.
\nExistem hipervisores de hardware, hipervisores sobre o sistema operacional e cont\u00eaineres. <\/p>\n

<\/p>\n

\"O<\/p>\n

<\/p>\n

Os hipervisores 'de ferro' s\u00e3o uma \u00f3tima solu\u00e7\u00e3o, se voc\u00ea realmente quer isolar algo. Porque existe a possibilidade de isolar no n\u00edvel das p\u00e1ginas de mem\u00f3ria e dos processadores.<\/p>\n

<\/p>\n

Existem hipervisores como programas, e h\u00e1 cont\u00eaineres, que ser\u00e1 nosso foco a seguir. Em sistemas de conteineriza\u00e7\u00e3o, n\u00e3o h\u00e1 hipervisor, mas existe um Container Engine, que cria e gerencia os cont\u00eaineres. Essa abordagem \u00e9 mais leve, portanto, devido \u00e0 intera\u00e7\u00e3o com o kernel, a sobrecarga \u00e9 menor ou inexistente.<\/p>\n

<\/p>\n

\n

O que \u00e9 usado para conteineriza\u00e7\u00e3o no n\u00edvel do kernel<\/h2>\n

As principais tecnologias que permitem criar cont\u00eaineres isolados de outros processos s\u00e3o o Namespaces e os Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount e User. Existem outros, mas para simplificar, vamos nos concentrar nesses.<\/p>\n

O Namespace de PID limita os processos. Quando, por exemplo, criamos um Namespace de PID e colocamos um processo nele, ele se torna PID 1. Normalmente, em sistemas, o PID 1 \u00e9 o systemd ou init. Portanto, ao colocarmos um processo em um novo namespace, ele tamb\u00e9m recebe o PID 1.<\/p>\n

O Networking Namespace permite limitar\/isolacionar a rede e dentro dele, alocar suas pr\u00f3prias interfaces. Mount \u00e9 a limita\u00e7\u00e3o do sistema de arquivos. User \u00e9 a limita\u00e7\u00e3o de usu\u00e1rios.<\/p>\n

Control Groups: Mem\u00f3ria, CPU, IOPS, Rede \u2014 cerca de 12 configura\u00e7\u00f5es no total. Tamb\u00e9m s\u00e3o conhecidos como Cgroups ('C groups').<\/p>\n

Os Control Groups gerenciam os recursos para o cont\u00eainer. Atrav\u00e9s dos Control Groups, podemos especificar que o cont\u00eainer n\u00e3o deve consumir mais do que uma certa quantidade de recursos.<\/p>\n

Para que a containeriza\u00e7\u00e3o funcione plenamente, s\u00e3o utilizadas tecnologias adicionais: Capabilities, Copy-on-write e outras.<\/p>\n

Capabilities s\u00e3o quando informamos ao processo o que ele pode ou n\u00e3o pode fazer. No n\u00edvel do kernel, isso \u00e9 apenas uma m\u00e1scara de bits com uma s\u00e9rie de par\u00e2metros. Por exemplo, o usu\u00e1rio root tem plenas permiss\u00f5es e pode fazer tudo. Um servidor de tempo pode alterar a hora do sistema: ele tem capabilities sobre o Time Capsule, e \u00e9 isso. Com as permiss\u00f5es, \u00e9 poss\u00edvel configurar restri\u00e7\u00f5es de forma flex\u00edvel para os processos, garantindo assim a seguran\u00e7a.<\/p>\n

O sistema Copy-on-write nos permite trabalhar com imagens Docker, tornando seu uso mais eficiente.<\/p>\n

Atualmente, o Docker tem problemas de compatibilidade com Cgroups v2, por isso, este artigo se concentra especificamente em Cgroups v1.<\/em><\/p><\/blockquote>\n

Mas vamos voltar \u00e0 hist\u00f3ria. <\/p>\n

<\/p>\n

Quando os sistemas de virtualiza\u00e7\u00e3o no n\u00edvel do kernel surgiram, come\u00e7aram a ser amplamente utilizados. O overhead do hypervisor desapareceu, mas alguns problemas permaneceram:<\/p>\n

<\/p>\n