Você está na página 1de 45

Docker: Uma visão geral

e estudo de caso do DCC

Luis Felipe Cunha Martins


PoP-MG/RNP - DCC/ICEX/UFMG
As aplicações mudaram nos últimos tempos

~2000 ~2014

Ciclo de vida longo, sem modificações O desenvolvimento é iterativo e constante

Monolítica e construída em uma única pilha Construída a partir de componentes


de softwares acoplados livremente

Em um único servidor Infinidade de servidores


Google Trends

Comparação com outros termos populares:

● Docker
● Big Data
● Micro Services
Stack Overflow

Comparação com outros termos populares:

● Docker
● Big Data
● Micro Services
Quem está usando
É muitas outras empresas e projetos
Comunidade

● Um dos pontos mais fortes.


● Centenas de grupos de meetups.
● Fóruns, grupos de facebook, twitter, github, youtube, slideshare,
etc…
● Crescimento de 30% na adoção no último ano.
● 30% dos containers estão rodando em produção.
● 29% das empresas planejam usar Docker no futuro próximo.
História dos Containers

● FreeBSD Jails (2000).


● Oracle Solaris Zones (2004).
● LinuX Containers (LXC) - 2008.
● Google’s lmctfy (Let Me Contain That For You) - 2013.
● Docker (libcontainer) - 2013
O que são Containers

● Os containers são um método de virtualização em nível de S.O., que


permite executar uma aplicação e suas dependências em processos
com recursos isolados.

● Permite empacotar facilmente o código, as configurações e as


dependências da aplicação, oferecendo consistência de ambiente,
eficiência operacional, produtividade e controle de versões.

● Os containers podem ajudar a garantir rapidez, confiabilidade e


consistência de implantação, independentemente do ambiente de
homologação. Além disso, os containers oferecem um controle mais
granular dos recursos, aumentando a eficiência da infraestrutura.
Containers leves (Lightweight containers)

● Os recipientes são isolados (ambiente totalmente segregado,


inclusive a rede - ip/rede própria ).

● Mas compartilham o kernel do S.O. e, onde apropriado, binários e


bibliotecas.

● ... o resultado é uma implantação


significativamente mais rápida, com
muito menos sobrecarga (overhead),
uma migração mais fácil e uma
inicialização mais rápida.
O que é o Docker?

● Docker é uma tecnologia Open Source que permite criar, executar,


testar e implantar aplicações distribuídas dentro de containers.
● Permite que você empacote um software, contendo tudo que é
necessário para sua execução: código, runtime, ferramentas,
bibliotecas, etc.
● O Docker permite que você implante as aplicações rapidamente, de
modo confiável e estável, em qualquer ambiente.
● Versionamento e histórico de mudanças.
● “Like Git” (docker {commit, pull, request, diff, tag})
VM vs Docker
Motivação

● Nós queremos entregar nosso software funcional para os diferentes


ambientes de forma simples e rápida.

● Mover do ambiente de desenvolvimento para produção é difícil:


○ Bibliotecas conflitantes / diferentes versões de softwares.
○ Diferentes S.O.
○ Diferentes versões de BD.
Produção

Teste de Integração
Desenvolvimento ?
Notebook do desenvolvedor

…..
Principais problemas a serem resolvidos

● Na minha máquina funciona


● Criar, atualizar e manter toda a pilha de
softwares é difícil:
○ O projeto usualmente contém muitas
libs, bd’s, serviços, …
○ Difícil de manter uma versão do projeto
reproduzível.

● Teste / Integração contínua / Entrega


contínua é difícil de automatizar.
Como resolver isso (DIY)

● Faça você mesmo:

1. Copiar / instalar dependências (manualmente);


2. Preparar o banco de dados;
3. Instalar a versão mais recente do projeto;
4. Configurar o ambiente;
5. Testar o projeto;
6. Detectar os erros (na minha máquina funciona);
7. Consertar os erros;
8. Repetir os testes (até funcionar);
9. Escrever guia para outros configurarem o “frankenstein” gerado.
Como resolver isso (VMs)

● Empacotar tudo em uma VM e executar o deploy em ambientes


diferentes.

● Desvantagens:
○ Pesada ⇒ quantas VMs você pode rodar em sua máquina?
○ Consumo alto de recursos ⇒ Virtualização completa (OS, I/O, …).
○ Tamanho (GBs para cada VM).
○ Problema com portabilidade ⇒ Diferentes soluções de virtualização.
○ Gerenciamento: Difícil de manter/configurar/reusar diferentes versões de
cada VM.
■ Geralmente resolvidos com Vagrant, Chef, Puppet, ...
Como resolver isso (Docker)

● Empacotar tudo em containers Dockers...


Benefícios do Docker

Entrega consistente e rápida das aplicações:


● Os containers abstraem as diferenças entre cada máquina física e são excelentes para
integração e desenvolvimento contínuo (CI/CD).

Considere o seguinte cenário:


● Os desenvolvedores escrevem o código localmente e compartilham o seu trabalho com
os colegas usando containers Docker;
● Ele usam docker para subir a aplicação no ambiente de testes e executar testes
manuais e automáticos;
● Quando encontram bugs, eles consertam eles no ambiente de desenvolvimento e
re-executam os testes e validação (subindo os containers novamente);
● Quando os testes são finalizados, aplicar a correção para o usuário é simples como
subir a imagem atualizada no ambiente de produção.
Benefícios do Docker

Implementação e dimensionamento responsivos:


● A plataforma do docker permite cargas de trabalho altamente portáveis. Os containers
podem ser executados em qualquer local, como o laptop do desenvolvedor, máquinas
físicas ou virtuais em um DC, provedores de nuvem ou ambientes heterogêneos.
● A portabilidade Docker e sua natureza leve também torna-o fácil de gerenciar cargas
de trabalho dinamicamente, escalando ou reduzindo aplicações e serviços conforme a
necessidades do negócio, em tempo quase real.
Compatibilidade e manutenabilidade:
● Elimina o problema de “na minha máquina funciona”, de uma vez por todas. Sua
imagem executa da mesma forma, não importando o servidor ou laptop em que estão
executando. Para os desenvolvedores isso significa menos tempo gasto na
configuração do ambiente e em depurar problemas específicos do ambiente,
resultando em um ambiente de produção mais confiável e fácil de manter.
Benefícios do Docker

Melhor aproveitamento de recursos:


● Docker é leve e rápido. Dessa forma provê uma alternativa viável, de baixo
custo à virtualização baseada em hypervisors (VM), permitindo usar mais da
capacidade da máquina para alcançar os objetivos do negócio.
● Docker é perfeito para ambientes de alta densidade e para implementações
onde você precisa fazer mais, com menos recursos.
Benefícios do Docker

Plataformas multi-cloud:
● Um dos grandes benefícios do Docker é a sua portabilidade. Nos últimos anos, todos
os grandes players de computação em nuvem (AWS, GCP, …), ‘abraçaram’ o Docker e
disponibilizaram suporte individual a ele.
● Os containers podem ser executados no RackSpace, AWS, GCP, VirtualBox, e em
qualquer outro local onde o S.O. hospedeiro suporte o docker.

Segurança:
● Do ponto de vista de segurança, Docker garante que as aplicações estejam
executando em containers completamente segregados e isolados entre si, garantindo
completo controle sobre o fluxo de dados e gerência. Nenhum container pode acessar
os processo executando em outro container.
● De um ponto de vista arquitetural, cada container possui seu próprio conjunto de
recursos, desde o processamento até a pilha de rede.
Benefícios do Docker

Isolamento:
● Cada container tem seus próprios recursos que são isolados de outros
containers.
● Docker permite que você remova sua aplicação de forma limpa, uma vez que
elas só executam dentro do container. Se você não precisa mais dela, basta
deletar o container, sem deixar arquivos temporários ou de configuração no
S.O. do hospedeiro.
● Além disso, é possível que cada aplicação utilize apenas os recursos
associados para ela. Uma aplicação não irá usar todos os recursos
disponíveis, o que tornaria o sistema lento, degradando o desempenho ou
deixando as demais aplicações fora do ‘ar’.
Benefícios do Docker

E muitos outros:
● Retorno do investimento e redução de custos.

● Versionamento.

● Ambiente controlado de desenvolvimento e homologação.


Docker - Arquitetura

Docker usa uma arquitetura cliente-servidor.


A parte cliente fala com o Docker daemon, que
faz o trabalho pesado de construção, execução
e distribuição de seus containers e imagens
Docker e controla os recursos em execução.

O cliente e servidor podem ser executados no


mesmo sistema, ou o cliente pode se conectar
em um daemon remoto.

Essa comunicação se dá através de um API


REST, através de sockets UNIX ou uma
interface de rede, para execuções de
comandos e scripts.
Principais partes do Docker

● Images

● Containers

● Dockerfile
Principais partes do Docker

● Images Containers docker: Containers tem como base


sempre uma imagem. Uma analogia de Java é “A
● Containers imagem é uma classe e um container é como um
objeto instância dessa classe”.

● Dockerfile Através de uma imagem você pode instanciar vários


containers e definir limitações de uso de recursos e
isolamento parcial ou total dos mesmos (usando
chroot, cgroups, ...).

Características: Portabilidade, isolamento de


processos, prevenção de violação externa,
gerenciamento de consumo de recursos.
Principais partes do Docker

● Images Docker pode construir imagens automaticamente lendo as


instruções do arquivo Dockerfile.
● Containers
Dockerfile é um arquivo de texto que contém todos os
comandos necessários para se criar uma imagem, que é
● Dockerfile construída através do comando “docker build”.

Formato
# Comentario
Instruções argumentos

O docker executa as instruções em ordem. A primeira deve ser


sempre um “FROM” para especificar a imagem Base da qual você
está construindo

# Meu container
FROM ubuntu:trusty
… … ...
Dockerfiles: Instruções

● FROM

● RUN

● ADD/COPY

● EXPOSE

● ENV

● VOLUME

● CMD / ENTRYPOINT
Vamos ver como isso funciona?

Linus Torvalds
Caso de uso do CRC/DCC/UFMG

● Serviço de páginas WEB do DCC

EVENTOS
PROJETOS
DISCIPLINAS
LABORATORIOS
………
Estrutura antiga

● 65 virtual hosts sendo executados no mesmo servidor WEB:


○ Servidor: Apache22 + PHP;
○ Dados: Externo, montado via NFS;
○ Mesma instância do Apache;
○ Mesmo usuário/grupo (www-data/www-data) executando cada vhost (de
usuários diferentes e não relacionados);
○ Administradores do vhost (diversos usuários) precisam ter acesso de
escrita aos dados.
Estrutura antiga - Problemas

● Problemas:
○ Arquivos precisam ter leitura para o usuário do apache (www-data):
■ Senhas e outros dados sensíveis ficam vulneráveis;
■ Incluir o www-data como membro de todos os grupos.
○ Especificidades de cada ambiente não podem ser atendidas.
○ Ataques (vulnerabilidades) a um site específico derrubam todo o sistema.
○ Atualizações difíceis de serem planejadas e executadas.
○ Permitir a utilização de recursos de forma diferenciada por cada vhost
(de acordo com a necessidade individual).
○ Toda a raiz do diretório de dados remoto precisa ser montada na
servidora.
Como resolver?

● Problemas:
○ Arquivos precisam ter leitura para o usuário do apache (www-data):
■ Apache executando como o próprio usuário e grupo do projeto
■ Retirar permissão de “outros” de todos os arquivos;
○ Especificidades de cada ambiente não podem ser atendidas.
○ Ataques (vulnerabilidades) a um site específico derrubam todo o
sistema:
■ Ambiente isolado para cada usuário;
Como resolver?

● Problemas:
○ Atualizações difíceis de serem planejadas e executadas:
■ Ambiente de produção = Ambiente de desenvolvimento (migração
transparente).
○ Permitir a utilização de recursos de forma diferenciada por cada vhost:
■ Gerenciamento de recursos.

○ Toda a raiz do diretório de dados remoto precisa ser montada na


servidora:
■ Acesso apenas ao diretório do site (vhost).
Solução - Docker !!!

● Imagem padronizada para o servidor WEB (apache+php+sssd+...).


● Cada vhost é mapeado em um container próprio.
● Cada container mapeia apenas o diretório remoto (nfs) de seus
arquivos.
● Todos os containers (vhosts) utilizam a mesma imagem padrão
(+/- 15MB de memória por container).
● Parâmetros repassados durante a execução do container alteram os
arquivos de conf da imagem padrão para a especificidade de cada
vhost.
Solução - Docker !!!

● Os containers são criados com recursos (cpu e memória) limitados.


● Cada container roda um processo do apache executado pelo usuário
e grupo dos arquivos do vhost em questão.
● Possibilidade de customizar o container de cada vhost.
● Possibilidade de versionamento do container, com rollback e diff
entre versões.
● Auto documentado.
● Executa em qualquer infra-estrutura e ambiente.
● Puppet (orquestrador) gerencia a execução dos containers e garante
que todos estejam sempre executando.
Containers em execução
Dockerfile: www2-docker

FROM ubuntu:trusty # COPY APACHE


ADD data/apache2 /etc/apache2
MAINTAINER Luis Martins
(luisf@crc.dcc.ufmg.br) #COPY data/php5 /etc/php5
ADD data/php5 /etc/php5
# APT não interativo
ENV DEBIAN_FRONTEND noninteractive #COPY data/certs/ /etc/php5
ADD data/certs /etc/ssl/certs
EXPOSE 80
COPY data/sssd.conf /etc/sssd/sssd.conf
RUN apt-get update && apt-get install -yqq \
msmtp \ RUN mkdir -p /opt
sssd-ldap \ COPY data/startup.sh /opt/startup.sh
apache2 \ RUN chmod 775 /opt/startup.sh
php5 \
... VOLUME ["/var/lib/sss"]

CMD ["/opt/startup.sh"]
Dockerfile: entrypoint

#!/bin/bash …

CONF_DIR="/etc/apache2"
SITES="sites-enabled"
VHOSTDEFAULT="www.vhost.dcc.ufmg.br.conf" if ! [ -z ${append} ]; then
echo "Append is set";
echo "Inicializacao do Container" echo "append is set" >> /root/append;
sed -i "/<EXTRA>/c$append" \
if [ -f "/etc/apache2/.first_run_wwwdcc" ]; then $CONF_DIR/$SITES/$VHOSTDEFAULT;
exec /usr/sbin/apache2ctl -D FOREGROUND fi
exit 0
fi mv $CONF_DIR/$SITES/$VHOSTDEFAULT $CONF_DIR/$SITES/$vhostconf

sed -i -e "/APACHE_RUN_USER/s/www-data/$APACHE_USER/g" \
-e "/APACHE_RUN_GROUP/s/www-data/$APACHE_GROUP/g"\ touch /etc/apache2/.first_run_wwwdcc
$CONF_DIR/envvars
echo "Bind no processo do APACHE"
sed -i -e "/ServerAdmin/s/admin/$APACHE_USER/g" \ exec /usr/sbin/apache2ctl -D FOREGROUND
-e "/ServerAlias/s/vhost/$vhost/g" \
-e "/ServerName/s/vhost/$vhost/g" \ exit 0
-e "/DocumentRoot/s/dir/${WEB_DIR//\//\\/}/g" \
-e "/ErrorLog/s/vhost/$vhost/" \
-e "/CustomLog/s/vhost/$vhost/" \
-e "/Directory/s/dir/${WEB_DIR//\//\\/}/g" \
$CONF_DIR/$SITES/$VHOSTDEFAULT
Exemplo de execução de um container

● Laboratório labx :

docker run -v /www/laboratorios/labx:/www/laboratorios/labx \


-p 80:80 --rm --name labx --env WEB_DIR=/www/laboratorios/labsoft \
--env APACHE_USER=lucas.sg --env APACHE_GROUP=labsoft \
--env vhostconf=www.labsoft.dcc.ufmg.br.conf --env vhost=labsoft \
-i -t ambar-www2

● Mas são 65 containers. Criar todos manualmente e garantir que todos


estejam executando é inviável
○ NÃO ESCALA
Escalabilidade e monitoramento

● PUPPET !!!
○ O puppet deverá gerenciar toda a criação dos containers, além de
checar se os containers estão em execução, reiniciando-os caso
necessário.
○ Escalabilidade.
○ Configuração centralizada.
○ Fácil manutenção e modificação.
Benefícios

● Cada usuário possui seu próprio espaço WEB, que pode ser
customizável e versionado.

● O servidor WEB executa com o próprio usuário e, em uma falha que


explore as permissões de acesso, apenas os dados desse projeto
estariam ameaçados:
○ Como o serviço é executado como o usuário, os dados de múltiplos
usuários não estão visíveis um para os outros.

● As vulnerabilidades de um site, que possa gerar uma sobrecarga no


sistema, não afetará os demais sites.
Benefícios

● Excelente utilização dos recursos da máquina hospedeira. Todos os


containers juntos ocupam 1GB de espaço apenas (800MB da imagem
+ 209MB de todos os discos dos containers) !!!

● Cada container ocupa entre 15 MB e 250 MB de memória, sendo


3GB de memória total (em média 47.3 MB por container).
Conclusão

● (Acredito) que o Docker veio para ficar, e que não é por acaso que os
grandes provedores de cloud computing estão investindo em tornar
deploys de aplicações em containers Docker cada vez mais fáceis e
rápidos.

● A comunidade só tem a se beneficiar com todos os repositórios


públicos que vem surgindo a cada dia, e desenvolvedores e
sysadmins, poderão desfrutar de maior produtividade por terem mais
controle e estabilidade em seus ambientes de execução.

● O uso do Docker no DCC levou a um sistema mais seguro, leve,


rápido e flexível.
OBRIGADO !
Luis Martins
<luisf@dcc.ufmg.br>

Você também pode gostar