Por Maicon Baum*

doker
Objetivo
O objetivo deste post é passar uma introdução ao Docker. Este post servirá como base para todos os posts do blog que teremos relacionados ao Docker, desde provisionamento até a orquestração propriamente dita.
Mas afinal, o que é Docker?
Enquanto a transformação digital acontece, inúmeras tecnologias surgem todos os dias para suprir necessidades, sejam elas conhecidas ou novas. Problemas acontecem o tempo todo no decorrer desta evolução e novas formas de pensar uma aplicação podem surgir a qualquer momento. Foi nesta linha de pensamento que nasceu o Docker: para suprir necessidades já conhecidas com uma nova forma de pensar aplicações, aplicando conceitos desde a infraestrutura como o isolamento de recursos até conceitos de micro serviços e aplicações distribuídas.

Princípios
Este post é puramente conceitual e não requer um conhecimento prévio.

Conceitos básicos

Docker Engine é uma aplicação client-server do Docker, composta pelos principais componentes:
Um server propriamente dito, o daemon do Docker. (dockerd);

  • O daemon é responsável por todo o core das principais tarefas do Docker. É o daemon que faz o build das imagens, que roda suas aplicações, cria os volumes, isola recursos e distribui seus containers.
  • O daemon do Docker pode tanto estar no mesmo sistema que o client, quanto você pode conectar o client em um daemon remoto. O daemon e o client se comunicam utilizando o Docker REST API através de UNIX sockets ou da própria interface de rede;
  • Um REST API que se comunica diretamente com o daemon, fazendo o meio de campo com interfaces para gerenciar o daemon, através de UNIX sockets ou da própria interface de rede. (Docker REST API);
  • Um client de interface de linha de comando, que interage com o daemon através do REST API. (docker);
  • Quando você utiliza comandos como docker run e docker build, você está utilizando o client do Docker para se comunicar com o daemon, seja ele local ou remoto. O client do Docker serve como ponto de acesso entre você e o daemon, onde cada request feita usando o client é uma request do REST API para o daemon, tornando possível um nível de abstração sobre tarefas mais comuns. Existem outros clients que abstraem ainda mais a interação com o daemon, mas o Docker client é geralmente o primeiro contato dos usuários de Docker.

doker

Imagens

Pense em uma imagem como sendo a sua sua aplicação como um todo (ou parte da sua aplicação, dependendo do caso). Uma imagem contém tudo que é preciso para rodar um container ou até para servir de base para outras imagens customizadas. Digamos que você quer subir um WebServer com um site em PHP utilizando Docker, você precisará ter em uma imagem:

  • O Sistema Operacional que a imagem utilizará (Ex: CentOS);
  • O WebServer que a imagem utilizará (Ex: Nginx);
  • O PHP;
  • O fonte da sua aplicação propriamente dita.

Todos estes componentes estarão em uma mesma imagem e servirão para subir o container com a sua aplicação de maneira fácil e rápida. Da mesma forma, você pode basear a sua aplicação em outras imagens e criar uma customizada.

Container

Pense em containers como unidades que servem parte da sua aplicação (ou ela como um todo, dependendo do caso) rodando logicamente isoladas, utilizando uma imagem como source. Vocė pode criar, iniciar, parar, mover ou remover containers através do Docker client. Com container você pode distribuir a sua aplicação (desde que ela tenha sido pensada desta forma) e isolar o uso de recurso baseado no que está naquele container. Por exemplo, você não precisa de uma quantidade de recurso gigante para utilizar apenas um serviço de mensageria, por outro lado, o core da sua aplicação precisará. Utilizando containers para rodar sua aplicação é possível definir, isolar, monitorar e até escalar a quantidade de recurso alocada para cada parte da sua aplicação. Você também pode adicionar storages, interfaces de rede e até fazer o build de uma nova imagem baseada em um container.

Um container é baseado em uma imagem e seu conteúdo pode ser alterado uma vez que está up, no entanto, se um container não utilizar um storage persistente, qualquer modificação feita será perdida quando o container for parado.

Dockerfile

Pense no Dockerfile como sendo instruçōes de como criar a sua imagem, pois é exatamente isso que ele faz. Você faz o build de imagens utilizando o Dockerfile como sendo o source e nele contém tudo que o Docker daemon precisa realizar para entregar sua imagem “fechada”. Tudo que você faria para realizar o setup de uma aplicação em um servidor manualmente é descrito no Dockerfile, desde utilizar uma imagem como base(S.O.), copiar arquivos externos para dentro da imagem ou até expor portas.

# Exemplo de Dockerfile utilizando uma imagem do Ubuntu 12.04 como base para realizar o build de um Apache
FROM ubuntu:12.04

MAINTAINER Kimbro Staken version: 0.1

RUN apt-get update && apt-get install -y apache2 && apt-get clean && rm -rf /var/lib/apt/lists/*

ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD [“/usr/sbin/apache2”, “-D”, “FOREGROUND”]

Docker Registry

Pense em Docker Registry como sendo o repositório onde você armazenará estas imagens, para que possa versionar e utilizar em outros sistemas. O Docker Registry default do Docker é o Docker Hub. Quando você utiliza comandos como docker pull ou docker push, o daemon interage diretamente com o Docker Registry configurado. (ou o default, Docker Hub)

Caso Prático

O Docker é ideal para aplicações distribuídas e arquitetura de micro serviços. Altamente gerenciável e customizável, torna-se prático e eficiente desenvolver pensando em containers Docker.

Imagine um cenário onde exista uma aplicação com vários serviços acoplados, rodando em um único servidor, consumindo recursos de forma nebulosa e escalável apenas verticalmente. Torna-se difícil e principalmente caro conforme a aplicação cresce em popularidade, certo?

Agora imagine um segundo cenário com a mesma aplicação, porém, desta vez, desacoplada, distribuída e com todos os seus serviços rodando em containers Docker. Totalmente passível de escala horizontal, lhe oferecendo a visão clara de qual parte está consumindo mais recurso e com containers rodando distribuidamente entre vários servidores. Torna-se fácil e principalmente previsível gerenciar custos e o ambiente como um todo conforme sua aplicação cresce em popularidade, certo?

Este é apenas um dos inúmeros casos práticos de uso para o Docker, sendo este uma ferramenta poderosa e um aliado valioso na transformação digital.

Docker Container x VM

Existem muitas dúvidas para quem está iniciando com o Docker e talvez a principal delas é: Como um container Docker é diferente de uma VM?

Observe as duas imagens abaixo:

doker

doker

Docker Containers e VMs são diferentes em vários pontos internos, mas principalmente porque containers possuem uma forma de virtualizar o SO para que vários workloads sejam executados no mesmo host, isto é, virtualizando apenas o kernel. Já as VMs, virtualizam o hardware propriamente dito para, em cima deste hardware, oferecer o S.O. inteiro virtualizado. A velocidade, agilidade, portabilidade e facilidade dos containers fazem dele a melhor escolha.

Conclusão

Se vocė está pensando em fazer parte de uma imensa comunidade que cresce todos os dias e adotar a transformação digital, avalie a proposta de usar Docker. Não só você estará utilizando o que há de mais moderno em “containerização” mas também terá acesso a uma gama de serviços, possibilidades e interações incontáveis! Claro, tudo o que foi dito neste post é conceitual e introdutório. Existe um caminho a ser percorrido tanto na parte de arquitetura de aplicação quanto no amadurecimento profissional para utilização do Docker.

O Docker foi desenvolvido pensando no isolamento total, seja entre containers ou onde ele está rodando. A partir do momento que o build da sua imagem foi finalizado, é absolutamente transparente para o Docker gerenciar esta imagem onde quer que seja feito o deploy. Isto é, você não perceberá diferença alguma desenvolvendo sua aplicação e testando ela em um Docker local e depois, subindo esta aplicação para produção, realizando o deploy em um cloud provider. (AWS, por exemplo)

Considerações

Este é um post introdutório que servirá como base para outros posts sobre Docker.

Docker: https://www.docker.com/

Docker Hub: https://hub.docker.com

Docker Docs: https://docs.docker.com

Quer saber mais? http://levelup.cloud

*Autor

Maicon Baum
Cloud Solution Architect

AWS Certified DevOps Engineer – Professional Level
AWS Certified Solutions Architect – Associate Level
AWS Certified SysOps Administrator – Associate Level
AWS Certified Developer – Associate Level

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

CAPTCHA
Change the CAPTCHA codeSpeak the CAPTCHA code