Olá Pessoal,

Este é nosso primeiro post aqui no Blog, antes de começar a falar sobre o que é Docker, Containers, DevOps e afins gostaríamos de agradecer a você que chegou até nós e agora está lendo um pouco sobre o que é esse mundo.

Você já deve ter ouvido falar em Containers ou no mínimo, Docker, bom o que é tudo isso afinal de onde veio essa história de container?

O projeto LXC (Linux Container) nasceu em agosto de 2008, no inicio, o site oficial trazia a seguinte frase: LXC, chroot com esteroides. O objetivo do projeto era ser uma alternativa a já consolidada tecnologia de chroot, sendo um meio termo entre máquina virtual e chroot, possibilitando a criação de um ambiente mais próximo possível de uma instalação Linux sem a necessidade de  um kernel separado.

Através do chroot é possível encapsular um sistema inteiro dentro de uma estrutura de diretório, fazendo com que o sistema hospede não acesse nada além daquilo que é definido dentro dessa arquitetura. Isso é muito útil pois elimina a sobrecarga de uma máquina virtual inteira para executar um processo ou serviço simples.

Voltando ao LXC, algumas das features do LXC são:

Kernel Namespaces:

Possibilita a abstração de processos dentro do kernel, isso quer dizer que um processo ou grupo de processo é isolado dentro do kernel, podendo visualizar os pontos de montagem, id de processos, id de usuário, hostname e fila de processo, isolados de outros processos ou grupo de processo.

Apparmor and SELinux:

Responsável por carregar politicas de acesso no host, isso quer dizer que são definidas regras de acesso a determinados arquivos/diretórios dentro do host, isso garante que em uma possível brecha de segurança, um container não consiga visualizar ou executar algo malicioso no host.

Seccomp policies:

Realiza uma filtragem das chamadas de sistema (syscall) e aceita ou não essa chamada. Como o host e container compartilham do mesmo kernel, é necessário algumas politicas especificas a nível de interface do kernel para que o hóspede não consiga escalar privilégios dentro do sistema host.

Chroots (pivot_root):

Responsável pelo mapeamento de diretórios e ponto de montagem do sistema container, é a chamada de sistema que cria a árvore de diretórios que o container terá acesso.

Kernel Capabilities:

Todos os sistema UNIX dividem os processos em duas grandes categorias, processo privilegiados  (sendo executados como root) e processos não privilegiados (executados com usuário comum), por padrão todo container executa comando não privilegiados, ou seja, um processo dentro de um container é executado como root dentro do host (mesmo que este esteja como root dentro do container). Sendo assim, a partir do kernel 2.2  foram inseridos dispositivos que possibilitam ao container executar de forma privilegiados alguns comandos, para esses dispositivos foi dado o nome de Capabilities ou CAP.

Cgroups:

Ou Control Groups, é responsável pelo controle de uso dos recursos por processo/grupo de processo, podendo assim executar diferentes containers com diferentes limites de uso (memória, cpu, I/O).

Devido a essas características é que chamamos de container todo sistema criado utilizando essa tecnologia, pois o sistema fica “enjaulado” dentro de uma caixa de recursos alocados exclusivamente para ele, e claro limitado a esses recursos. Abaixo há uma imagem ilustrando a diferença entre uma máquina virtual comum e um sistema em containers.

 

 

Ótimo, já sabemos um pouco sobre o que é e de onde vieram os containers, agora temos outras dúvidas:

O que é o docker afinal?

No que os containers podem me ajudar?

Ok, ok, vamos responder a essas e muitas outras dúvidas em nossos próximos posts, fiquem atentos e caso tenham dúvidas ou quiserem conversar um pouco mais sobre esse mundo, deixem suas mensagens!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.
  • Epifanildo

    Então, estou achando o texto confuso. Olha o seguinte:
    por padrão todo container executa comando não privilegiados, ou seja, um processo dentro de um container é executado como root dentro do host (mesmo que este esteja como root dentro do container).
    Se os comandos são não privilegiados, como que o container só usa comandos como root?

    Apparmor and SELinux: O container não isola como no chroot?Como então que garante que o container consiga visualizar ou executar comandos maliciosos no host?
    Por enquanto acho que é isso, se puderem sanar as dúvidas

  • Oi Epifanildo,
    Obrigado pelo questionamento, vamos lá:

    1 – Quando você cria um container e não especifica algum usuário para executá-lo, você terá dentro do container o usuário root, ou seja, você será root dentro do container, mas apenas para processos vinculados a este container, ele não será root dentro do host. Os processos que executam dentro do container são não privilegiados no host, ou seja, os processos do container são executados como root dentro do container, isso não quer dizer que executam como root (super user) no host.
    2 – Peço desculpas, a frase correta ali no post seria: “isso garante que em uma possível brecha de segurança um container não consiga visualizar ou executar algo malicioso no host.” Agora que notei que está errado, vou corrigir no post.
    Mais uma vez obrigado! 😉

  • André Franklin

    Salve Cristiano, tudo beleza?

    Primeiro, agradeço os artigos, é sempre bom encontrar pessoas que compartilham o conhecimento.

    Agora estou querendo investir algum tempo estudando o docker, mas primeiro, quero saber se ele pode me atender nas minhas demandas.

    Exemplo, preciso sempre fazer a instalação de uma aplicação open source, montando uma em estrutura L.A.P.P (Linux,Apache,Postgress e PHP) e configurar a mesma com alguns detalhes chatinhos, que algumas vezes utiliza até de scripts shell.

    Nesse sentido o docker pode me ser útil? ou seja depois dessa estrutura montada bastaria “exportar” tudo para ele? e reutilizar sempre que for necessário?

    A outra pergunta que é condicional da primeira , é se essa estrutura que pretendo utilizar já precisa ser montada dentro do container docker?

    Desculpe o amadorismo nas perguntas e mais uma vez muito obrigado por compartilhar o conhecimento.

    Att,

  • Oi André, obrigado pelo Feedback, sempre é muito útil pra nós 😉
    Seu caso, existem formas de converter hosts (VM ou físico) em container (lxc puro, não em containers Docker), você pode neste caso montar todo o ambiente em uma VM e converte-la em container e assim portar para outros hosts, é algo que pode ser feito, mas é bem trabalhoso.
    Outra forma que é mais comum é montar o ambiente já dentro de um container, ou seja, subir um container com o S.O que desejar, acessá-lo via docker attach e fazer todas as instalações e configurações que precisa (da mesma forma que em uma VM) e depois commita-lo em uma imagem do Docker. Ou ainda utilizar o Dockerfile para montar sua imagem a partir de um arquivo, com ele você pode passar todas as instruções que precisa (inclusive copiar scripts para dentro da imagem). Podemos fazer uma demo se quiser com esse ambiente pra você identificar qual o melhor.
    Abraço!

  • André Franklin

    Ok, galera, muito obrigado pelo retorno, em breve investirei tempo em estudos sobre o docker, e vou incomodar muito vocês ainda.

    Valeuu!!!

  • Oi André, por favor, não fique com dúvida, Docker é algo muito legal e acreditamos muito que é a solução para qualquer tipo de projeto. Abraço e vamos nos falando!

  • Davi Busanello

    Olá Cristiano, poderia ter uma lista de tags/categorias ou uma forma melhor de encontrar os posts para iniciantes?

    Obrigado, gostei muito do site, está me ajudando

  • Oi Davi,
    Vou repensar isso sim, obrigado pelo feedback!