Salve, data beleza? Continuamos essa saga aqui no nosso módulo de Docker. Agora que a gente já aprendeu o que são containers, a diferença para a virtualização e principalmente containers são processos que estão sendo enganados, que eles compartilham os recursos do sistema operacional. São apenas processos, mas estão sendo feitos de bobo. Ele está achando que está com o sistema operacional completo, tudo está ok, mas ele está em um ambiente que é o namespace ilimitado, também sendo capado pelos cgroups. Então agora nesse capítulo nós vamos entender a evolução desses containers, principalmente de 2010 para frente, o surgimento do Docker e várias iniciativas na indústria, no mercado de tecnologia, para poder criar padrão entre esses containers, para permitir que ferramentas se conversem, etc. A gente não poderia ficar com cada empresa criando o seu padrão. Então, bora lá. Então, temos o nosso novo capítulo aqui com a primeira aula do capítulo. Então na verdade a Docker Company que criou o projeto Docker foi fundada em 2010 por esses três camaradas aqui, o Solomon Hikes, o Kemel Fonad e o Sebastiano Paul, que eu não sei se pronuncia dessa maneira. Na verdade eles entraram com um projeto de aceleração de uma startup nesse Y Combinator e depois acabou se nascendo o Docker. Mas depois dessa iniciação da startup, o Hikes, que é esse primeiro cara, ele iniciou o projeto Docker com a DotCloud, que era uma plataforma ali, CES, que vendia infraestrutura para desenvolvedores, permitindo que eles não se preocupassem com implantar aplicativos, se preocupando com o servidor. Hoje em dia, a gente já tem isso muito comumente utilizado, que é você vai hospedar sua linguagem de programação numa plataforma qualquer, você nem tem que se preocupar com instalação, com o que está acontecendo, você só quer hospedar o seu aplicativo. Então, a ideia do Docker nasceu aqui. Aí, passou três anos, eles lançaram o Docker como projeto open source na PyCon de 2013 em Santa Clara, na Califórnia, e aí foi popularizando mesmo a ideia de containers. Nesse tempo, o projeto Docker utilizava o LXC, que era aquele padrão de containers que a gente estava falando, que é um chroot tunado, mas a Docker resolveu criar o seu próprio padrão para poder gerenciar esses containers. Eles chamaram de LibContainer, que é um projeto escrito em Golang. E acabou que esse LibContainer foi tão bom que ele acabou virando o RunC, ou RunContainers, e ele foi incubado mais tarde na OCI, ou Open Container Initiative, que é uma iniciativa do mercado para poder criar padrões para esses containers. A gente está justamente nessa ideia de criar um padrão. O que vai diferenciar essas ferramentas vão ser os serviços das bordas, os serviços adicionais que essas ferramentas vão fornecer. Então, o Run-C acabou vindo para cá. E essa Open Container Initiative é uma iniciativa criada por IBM, Microsoft, Oracle, Google, essas empresas participam dessa iniciativa. A gente pode até pegar aqui a página deles, se você quiser acessar opencontainers.org. E eles têm também um GitHub. Então, tem a Open Containers lá, eles têm várias coisas, tem várias especificações e outros projetos aqui. Então, o Run-C, ele está dentro, você pode fazer a instalação, a gente vai mexer com ele daqui a pouco para poder... A gente vai ver ali que não precisa de dock, nenhuma outra ferramenta, é possível criar containers apenas com RunC. Aí em 2017, essa coisa foi evoluindo, a Docker acabou lançando um outro projeto que é o MobiProject, que é um projeto open source para poder gerenciar containers, não é necessariamente só para poder fazer a criação. A Docker, com o passar do tempo, foi quebrando várias coisas que ela tinha ali em projetos menores. Então, a Mobi Project também é uma outra iniciativa que tem a participação de várias empresas e ela permite que a gente faça gerenciamento de imagens, secrets e outras coisas que a gente precisa lidar. O container em si não é suficiente. A gente tem que ter uma série de ferramentas para poder organizar a execução desses caras. Em 2016, já com essa ideia de containers popularizada, a Docker decidiu quebrar, como eu já falei, os seus projetos em partes menores. E aí nasceu o Container D, que é várias siglas aqui nessa aula. Não precisa ficar preocupado, você não precisa decorar isso. O conhecimento vai vindo à medida que você vai trabalhando com o Docker e vai ficando na sua cabeça. Mas o importante é que você entenda que foram criando projetos, iniciativas, para cada vez mais o uso de containers ficasse mais fácil, portável. A palavra está aqui. O que esse container D faz? Imagina que você tem os containers rodando na sua máquina, a gente precisa a todo momento saber o que ele está usando de CPU, de memória e outros metadados do container. E fazer system call, fazer chamada para o sistema para poder ficar puxando essas informações é muito ruim. Então, o container D vai acabar sendo um serviço, que é container daemon. Daemon vai ser um serviço que vai ficar rodando ali em background, na sua máquina, que vai gerenciar a execução desses containers. A gente consegue saber informações desses containers através de APIs que vão ser muito melhores para a gente poder lidar. Então, isso aqui acabou virando um projeto que foi incubado lá na CNCF, a Cloud Native Computer, que tem ali como projeto incubado o Kubernetes, o Argo CD, o Keycloak, o Envoy e vários outros projetos. Então a gente tem esse gráfico aqui para poder entender como que as coisas estão acontecendo. Imagina que a gente tem ali o nosso sistema operacional, pode ter aí uma máquina com ARM, com Intel, com Windows, com Linux, tanto faz. Mas aí a gente vai ter essa divisão de camadas. Vamos ter um serviço chamado de Container Scheme, que é esse cara aqui que vai, de fato, provisionar o container. Então, está vendo que o RunC é uma das ferramentas? Mas a gente tem várias aqui no mercado. São várias. São várias no mercado. Então, a ideia é que a gente possa usar qualquer uma dessas ferramentas sem que isso afete, que isso seja portável. Então, esse container-shim está rodando aqui mais perto do sistema operacional, e aí eu vou ter o container D rodando também, que vai fazer o gerenciamento junto com o shim ali para poder provisionar esses containers. Então, a gente faz o gerenciamento das imagens e outros serviços também que são necessários. Então, ele vai sempre comunicando aqui com o container para ele poder provisionar os containers conforme for necessário. E aí, eu posso ter aqui em cima, como clientes, qualquer coisa. Eu posso ter a minha cloud, posso ter um serviço, posso ter o Kubernetes, posso ter o próprio client do Docker. Então, isso aqui abre as portas para qualquer empresa que quiser trabalhar com os containers, ela possa trocar aqui o shim por algum que está disponível, mas ela sempre vai trabalhar com o container D ali, e se eu trocar o que está rodando aqui por debaixo, o container D vai me dar as mesmas informações para o meu cliente que está, de fato, requisitando. O cliente que vai pegar uma nova imagem, pegar um novo container, pedir para poder remover um container, criar um novo container, fazer outras coisas. Então, a gente tem essas interfaces que não quebram justamente porque existe esse padrão. O Docker vai rodar exatamente dessa forma. A gente vai ter o container de ir lá que vai provisionando tudo para a gente, tanto as informações quanto a criação de objetos. tudo para a gente, tantas informações quanto a criação de objetos. Então, olhando um pouquinho aqui para a infraestrutura que a gente tem, então posso ter ali o Windows e o Linux, um hardware da vida, então tem o container que está rodando o run-seq, normalmente é assim. E aqui, num nível mais próximo do client que vai utilizar, aí eu posso ter segurança, rede, volumes para poder armazenar dados persistentes, os secrets para poder gerenciar variáveis de ambiente e outras coisas, orquestração. Então, essa camada aqui, ela organiza, ela faz essa inter-apelabilidade, ela cria essa API para que a gente não tenha containers sempre cada um com o seu padrão. Então, você pode dar uma olhada aqui também com mais detalhes nos links que eu coloquei. Então, a ideia é justamente essa. Então, a gente viu aqui que o libcontainer se tornou o runc, que foi incubado na Open Container Initiative, que foi criado aqui nos anos 2010 pra frente. Os anos 2010 foi o boom de popularização dos containers. Então, pessoal, vamos seguir na nossa saga, é isso aí e até a próxima.