Documento com o conteúdo ministrado na palestra "Docker: Introdução à Conteinerização de Aplicações" apresentada dia 2 de junho de 2017

1. Docker:
Introdução à Conteinerização de Aplicações.
Palestrante: Marcel Fox.
contato@marcelfox.com
Este documento é parte da palestra de mesmo nome integrada no evento “Palestras sobre
Computação em Nuvem” apresentada no dia 2 de Junho de 2017 no IFPB. Apesar do
documento em si ser bastante esclarecedor, o mesmo se destina aos participantes da
palestra onde os tópicos foram abordados. Dito isto, é importante enfatizar que o documento
tenta ilustrar uma introdução ao Docker como solução à aplicações web priorizando o deploy
independente do sistema base.
Tópicos:
• O que são Containers?
Breve conversa sobre Nuvem, Container e a que ponto estamos.
• Docker.
Conteinerizando Aplicações.
• Build, Ship and GO!
Desenvolvedores e SysAdmins em paz ♥.
• Integração com a Nuvem.
Todo esse Hype Docker.

2. Introdução:
Antes de começarmos diretamente nos Containers, faz sentido iniciarmos a conversa
compreendendo melhor à respeito da estrutura da Nuvem por que o tópico é tão
atual porém, muitas vezes é negligenciado já que, a abstração é tão ampla neste
assunto, que acabamos por deixar de lado alguns detalhes importantes que envolvem
uma parcela grande do mercado de TI, que é a área de Web Hosting.
O início da Web:
Apesar de ser funcional na proposta e crescente em número de usuários, a Web era
bastante precária no início. As aplicações eram praticamente estáticas, muitas vezes
resumidas à e-mail e html puro, não chegando a consumir a totalidade dos recursos
que os servidores ofereciam. Com a popularização do Kernel Linux como força
motriz da Web e o auxilio do mesmo na nova prática da virtualização à partir do
Hypervisor ESXi, as máquinas virtuais surgiam.
A solução veio para aproveitar a totalidade de recursos que os servidores ofereciam,
trabalhando melhor também, o consumo de energia dos servidores. Logo outras
práticas de compartilhamento de recursos à nível de serviço surgiam e, em conjunto
com as máquinas virtuais (VPS), começavam a tornar os servidores mais flexíveis.
Essa melhora na estrutura abstraía cada vez mais os serviços, criando ambientes
completamente virtuais e compartilhados.
Grandes empresas começavam a enxergar na Web, possibilidades nunca antes
imaginadas, fomentando assim, uma corrida para alcançar novas propostas que
melhoravam a interação do usuário final tornando a Web cada vez mais intuitiva. A
Web como um ‘substantivo’, se tornava uma Web ‘verbo’ onde o usuário podia
interagir cada vez mais com os serviços.
Com o batismo da Web 2.0 e o surgimento de novos meios de acesso à web, as
aplicações traziam funcionalidades complexas e dependentes de recursos. Novas
tecnologias e linguagens de alto nível surgiam para adicionar cada vez mais
funcionalidade às aplicações que começavam a providenciar serviços de fato.
No lado da estrutura, a solução de virtualização precisava sair do conceito de
verticalização de estrutura para uma horizontalização de recursos. Para que isso
fosse possível, fazia-se necessário abstraír máquinas reais de forma que estas
trabalhassem em conjunto virtualizando camadas específicas para armazenamento

3. de dados, rede e demais componentes retornando assim soluções em escalabilidade,
load balance e alta-disponibilidade na Web.
A Nuvem:
Podemos definir o conceito básico da Nuvem em
serviços online onde os dados podem ser
trabalhados individualmente junto a plataforma da
aplicação, podendo ser acessados por quaisquer
dispositivo com acesso à Web.
Seguem abaixo os modelos principais de
Computação em Nuvem:
• SaaS (Software as a Service): Providencia serviços de software on-demand.
Ex: Office 365, Google Apps.
• PaaS (Platform as a Service): Providencia plataformas para a deploy de
aplicações, abstraíndo o ambiente.
Ex: Heroku, Azure.
• IaaS (Infrastructure as a Service): Abstrai todo um conjunto de máquinas,
rede, armazenamento e demais componetes de uma infraestrutura Web,
disponibilizando a mesma como um serviço.
Ex: OpenStack, Amazon EC2, Rackspace.
Assim, esses conceitos vieram para melhorar a interatividade com a Web trazendo
serviços e abstraíndo a forma como os mesmos funcionam, no entanto, existem ainda
muitos limites junto a Web. Um problema que ainda é bastante comum é o deploy de
aplicações no ambiente de produção.

4. O que são Containers?
Com a implementação da nova funcionalidade cgroups junto ao Kernel Linux desde a
versão 2.6.24, se tornou possível a abstração de sistemas completos à nivel de
processamento, sem a necessidade de um Hypervisor como o ESXi, que cria uma
camada acima do Kernel para simular todos os componentes de uma máquina real de
forma a servir a máquina virtual (VPS).
Com a chegada do Linux Containers (LXC), já era possível isolar sistemas
operacionais inteiros à nível de processamento, podemos então chegar a uma
definição da seguinte forma:
Container é o encapsulamento de sistemas inteiros à nível de processamento, onde
esses sistemas compartilham do hardware do host.
Ou seja, um Container LXC é executado de forma isolada e possui um PID. O LXC é
administrado por uma interface de linha de comando para criar, acessar e gerenciar
Containers.
Importante mencionar no entanto que existem outras ferramentas que providenciam
conteinerização para outros sistemas, como o Jails para FreeBSD, mas a idéia era a
mesma.
Limitações:
A grande maioria das ferramentas de conteinerização até então, eram baseadas no
módulo cgroup do Linux e só funcionava neste, e para este Kernel, isolando apenas
sistemas baseados em Linux. Isso contrastava diretamente com a virtualização
tradicional através de Hypervisors, que podiam simular diversos outros sistemas
operacionais e em diversos Hosts, independente de Kernel.
O deploy de aplicações permanecia sendo uma etapa problemática para os
desenvolvedores. A complexidade de configuração continuava a mesma, afinal, o
Container simula um sistema operacional completo, sendo necessário levatar todas
as dependências necessárias para que a aplicação fosse executada, bem como
serviços paralelos como base de dados e demais fatores para a produção.
Apesar do grande passo, os Containers eram específicos para sistemas dentro do
sistema principal, muitas vezes a conteinerização era indicada como uma forma de
isolar sistemas, para que estes, trabalhassem em conjunto sendo independente do
sistema principal. Deploy não era o foco principal de Containers até então.

5. Docker.
No envento PyCon de 2013, Solomon Hykes conseguiu falar em 5 minutos a respeito
do futuro dos Containers, trazendo em uma apresentação improvisada, uma prévia da
nova ferramenta, baseada no core da empresa DotCloud, utilizado para abstraír o
ambiente no deploy de aplicações em sua estrutura.
O que antes era um projeto complexo e sigiloso, foi melhorado para se tornar um
projeto Open Source que opera utilizando Conteiners de uma forma nunca antes
vista; conteinerização de aplicações à nível de processo sem a necessidade de se
levantar um sistema operacional, como ocorre no LXC.
Dessa vez as aplicações trabalhavam em um ambiente mínimo com dependências
básicas para o funcionamento, compartilhando das funcionalidades do próprio Kernel
do Host para criar estrutura de processos, rede, protocolos mesmo executando de
forma encapsulada. Os expectadores estavam presenciando uma tecnologia
revolucionária que permitia deploy de aplicações em diversos ambientes, abstraíndo
as dependências necessárias para a aplicação sem interferir no sistema real.
Não demorou muito para a empresa DotCloud mudar de nome para Docker e focar
apenas na nova ferramenta. A ferramenta solucionava principalmente o problema
clássico de “Dependency Hell” que ainda hoje, cria guerras homéricas entre DevOps
e SysAdmins, com o famoso: “Roda na minha máquina”.
Pela primeira vez, o deploy de aplicações em ambientes diversos estava sendo
simplificado, ampliando possibilidades para todo o mercado de Web Hosting. No lado
do desenvolvimento, a produção agora podia focar apenas na aplicação sem a
necessidade de lidar com gambiarras para se adequar ao ambiente de produção das
quais na maioria das vezes utilizam sistemas, serviços e versões diferentes de um
ambiente de desenvolvimento.
A Estrutura do Docker:
• Docker Daemon: Serviço principal de contêineres Docker (LXC) no host.
• Docker CLI: Interface de linha de comando que gerencia os contêiners.
• DockerFile: Imagem onde ambientes e configurações podem ser criados.
• DockerHub: Repositório de Imagens prontas.
(detalharemos melhor no próximo tópico, na prática!)

6. Build, Ship and GO!
O Docker é uma ferramenta que possui uma interface simples para uma tarefa tão
complexa executada à nível mais baixo. No tópico anterior tentamos esboçar a
funcionalidade da ferramenta e enfatisamos a importância deste serviço para o
deploy de aplicações de forma descomplicada.
A melhor forma para compreendermos a funcionalidade da aplicação no entanto, é a
prática! Segue abaixo um resumo das principais funcionalidades da interface de linha
de comando do Docker.¹
The action is GO!
Um comando básico para testes de funcionalidade após a instalação do Docker é o
“hello-world”, que na prática, não é um simples “Hello World” tradicional, veja a
saída:

7. Montando um Container com Dockerfile:
Com o Dockerfile, nós podemos criar um conjunto de instruções simples para
montarmos um Container exatamente de acordo com o que desejamos, salvando o
mesmo em uma imagem que poderá ser compartilhada junto ao DockerHub onde a
comunidade poderá melhorar a imagem se assim desejar, vamos começar?
Primeiro criamos um diretório específico para configurarmos a nossa Imagem, no
caso abaixo eu criei o seguinte diretório “../simple_flask/Dockerfile”. E neste
diretório configurei uma aplicação mínima baseada em Flask para o nosso exemplo,
veja os arquivos:
O único arquivo importante para a montagem da imagem de fato é o Dockerfile, os
outros arquivos dentro do diretório “app” fazem parte da aplicação Flask. Vejamos
como é a estrutura do Dockerfile:
(estrutura do Dockerfile)

8. Exmplicando em detalhes as intruções:
• FROM: Comando que especifica qual a imagem base a ser utilizada, como por
exemplo “FROM base/debian”.
• MAINTAINER: Aqui é onde informamos o responsável pela imagem.
• RUN: Executar comandos importantes na montagem, quando executamos a
mesma com o comando “docker build”.
• COPY: Executar uma cópia de um arquivo/diretório local para um local
específico junto à imagem.
• EXPOSE: Determinar a porta em que queremos que a container responda.
Existem diversas intruções para o Dockerfile que configuram melhor o ambiente
como “HOME” e “ENV”, mas os comandos acima são suficientes para nosso
ambiente basico.
Montando a Imagem do Dockerfile:
Agora que já compreendemos melhor a estrutura do Dockerfile, podemos prosseguir
montando a imagem com o seguinte comado:
$ docker build -t=marcelfox/simple_flask simple_flask/
Onde:
Usage: docker build [OPTIONS] PATH | URL | -
• “-t=”: Indica o repositório/nome_da_imagem que queremos salvar. E este é o
meu repositório no Dockerhub, para facilitar o envio com o “docker push”
Em execução:

9. É importante ressaltar que as instruções do configuradas no Dockerfile estão todas
sendo executadas na montagem (imagem anterior).
Para carregarmos ou baixarmos a imagem criada do container, bem como atualizar
modificações executadas posteriormente, podemos executar os seguintes comandos:
• “docker login”: Para efetuar o login em seu repositório no Dockerhub.
• “docker push repo/image”: Enviar a imagem para o Dockerhub.
• “docker pull repo/image”: Baixar a imagem para a máquina local.
Veja a execução:
Por fim, vamos analisar a execução do nosso container “simple_flask” exibindo uma
página baseada em flask localmente porém executada de dentro do container. Para
executarmos um container utilizamos o comando “docker run”.
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Vamos analisar em detalhes o comando:
• “--name”: Dá um nome ao container, se este parâmetro não for declarado, o
docker escolhe um nome inusitado para o container.
• “--net”: Este parâmetro especifica qual configuração de internet o container
irá utilizar, no caso estamos usando o parâmetro “host” que indica que o
container irá utilizar a rede do host, nos possibilitando executar um aplicativo
de forma local, sem a necessidade de configurar um ambiente inteiro para isso.
• “--rm”: Remove quaisquer instâncias ativas da imagem a executar.
• “-d”: Parâmetro que indica que o processo será executado em background.

10. Integração com a Nuvem:
Este mínimo e que finaliza nossa palestra para dar sentido a seguinte palestra: “Do
Zero ao Openstack” que foi apresentada no mesmo dia e em sequência.
Vimos que o Docker é uma ferramenta que veio para inovar o conceito de conteiner
priorizando o deploy, no entanto o docker ainda é uma ferramenta nova que já
caminha para versões mais estáveis com praticamente 4 anos de jornada até então.
Com certeza será uma tendência pro futuro e empresas grandes como a Google já
começaram a investir em ferramentas de Integração com a nuvem, como por
exemplo o Kubernets que é um sistema de automatização de criação, deploy e
escalonamento de Containers no ambiente Cloud, como por exemplo um ambiente
baseado no OpenStack, ferramenta cujo os detalhes vocês poderão ver na palestra da
sequência.
Obrigado pela atenção e espero que tenha gostado do material, quanto da
apresentação.
Seguem as fontes de pesquisa:
https://www.youtube.com/watch?v=wW9CAH9nSLs
https://prakhar.me/docker-curriculum/
http://anandmanisankar.com/posts/container-docker-PaaS-microservices/
https://www.ted.com/talks/philip_evans_how_data_will_transform_business?
language=pt-br#t-821291
https://developer.ibm.com/dwblog/2016/what-is-docker-containers/?
cm_mmc=PSocial_Twitter-_-Developer_Productivity-_-WW_US-_-
21289202_Tracking+Pixel&cm_mmca1=000019RT&cm_mmca2=10004795&cvosrc=
social%2520network%2520paid.twitter.US%2520%2520Handles%2520Docker_SD
%2520Behav_DesktopMobileTablet_1x1&cvo_campaign=Developer_Productivity-
WW_US&cvo_pid=21289202
“Stay Hungry, Stay Foolish”