Docker está para o desenvolvimento de software como o IPOD esteve para a indústria da música. Não inventou a música portátil, mas revolucionou a experiência dos usuários.

Se você trabalha com algum backend, java, .NET, node, python, ruby… e docker não está no teu radar, meu amigo… você tá ferrado!

Se você nunca ouviu falar de docker, você esteve em uma caverna nos últimos 9 anos. Desde 2013 docker é amado por desenvolvedores de todas as tecnologias.

Docker usa algo velho, containers (que já existem desde 2006), para criar um ambiente de execução de aplicações totalmente independente e imutável, entretanto extensível.

Funciona assim

A galera das principais distros linux criam imagens-base com os binários e configurações das distros. Ou seja Ubuntu, Debian, Alpine, etc.

A partir daí, as plataformas (node, java, .net e dezenas de outras) evoluem imagens-base, colocando seus runtimes e skd’s criando assim novas imagens prontinhas para nós.

E nós, no 3° nível dessa cadeia, nós empacotamos nossas aplicações em novas imagens.

Mas como isso funciona?

O processo de criação de cada imagem depende de uma receita, um dockerfile, que descreve cada comando que deve ser executado para preparar o ambiente para receber sua aplicação. Esses comandos são executados durante o build da imagem. Deixando o ambiente preparado para que ao rodar a aplicação, tudo já esteja pronto e não seja necessário preparar nada para sua aplicação, apenas rodar.

Esse ambiente, é o container em si. Isso quer dizer que eu posso ter lado-a-lado, Ubuntu, CentOS, Debian, Alpine posso ter aplicações que rodam melhor em cada uma dessas distros, sem que uma interfira na outra.

No nosso caso, com .NET, posso ter todas as versões do .NET core, cada container rodando uma aplicação de uma versão diferente. 1, 1.1, 2, 3, 3.1, 5, 6 e 7.

É incrível porque simplesmente estão independentes e, principalmente, não depende de nenhuma instalação no servidor. O docker em si é essa abstração. Para uma aplicação conteinerizada em java, rodar, só precisamos do docker, o resto já está na imagem dela.

A mecânica faz lembrar uma máquina virtual, no entanto nem de longe pode ser comparado.

Não importa da tecnologia, se estamos falando de backend, docker é must have.

No desktop

Você quer subir um MySQL, SQL Server, Postgres, até Oracle para validar um detalhe em uma base de dados, um snapshot. Vai instalar em um servidor? Poderia, mas teria de aprender a instalar, e como subir essa instância.

Com docker, basta um simples comando. Isso porque antes de nós, a equipe que construiu o banco, empacotou em uma imagem imagem docker. De forma customizável ao ponto de ser parametrizável. Nós também podemos fazer isso, sabia?

A mágica começa a acontecer assim:

quando você reduz drasticamente a carga cognitiva entre o estado de total ignorância e o up and runing.

E não estou falando de criação de ambientes produtivos aqui.

Eu não estou advogando a favor da ignorância, dizendo que você não deveria estudar de fato como subir esse banco decentemente. Eu estou dizendo que a maior e esmagadora parte do que fazemos é para simular situações, configurações, cenários hipóteses em nosso ambiente local, no nosso desktop de desenvolvimento. E docker sem sombra de dúvidas é extremamente eficiente em entregar uma experiência incrível para quem tem essas demandas.

No server

Nosso ambiente de desenvolvimento é caótico e complexo. Com instalação de IDE’s, ferramentas auxiliares, e muita coisa que não existe no ambiente de produção.

Isso faz com que recriar as condições exatas do ambiente produtivo no seu desktop de desenvolvimento seja algo complexo e improdutivo.

É aí que docker atua. Cada container é isolado por definição, e não consome nada do host. Ou seja, instalações do host não afetam o container, que roda isolado em seu mundo à parte. Isso faz com que o container não seja contaminado com seu host e portanto conseguimos assim ter uma experiência muito mais fiel a produção.

Do ponto de vista de deployment, conseguimos ver as aplicações precisando se conectar umas às outras via rede, e conseguimos lidar com isso da mesma forma como a aplicação rodará em produção.

Do ponto de vista financeiro

Imagine desenvolver um backend sem se preocupar com o local onde sua aplicação rodará. Imagine definir configurações, premissas e não mais produzir conflitos com outras instalações nos mesmos servidores. No passado eu já escrevi que com Docker você pode escolher:

Cobrar mais caro,
porque você gera menos dores de cabeça para todo mundo,
portanto vale mais.

Cobrar mais barato,
porque você tem menos dores esforço e dor de cabeça,
portanto você consegue ser mais eficiente.

A escolha é sua: as duas coisas são perfeitamente cabíveis

Alguns mercados possuem como solução, entregar appliances, hardware pré-configurado e homologado. Já funcionando. Docker permite mais ou menos a mesma coisa, só que com software. Permite que entreguemos imagens prontas, que já possuem o software instalado nela. Homologado e testado. Como uma black box. Configurado da forma como você decidir.

Você já imaginou a praticidade disso?

Claro, como tudo na vida, tem um custo envolvido.

Uma tecnologia nova, técnicas novas, uma forma perfeitamente engessada de conduzir o desenvolvimento, resolvendo problemas e mais problemas de 3 gerações. Eu estou falando dos deployments parciais. Aqueles deployments em que só levamos alguns arquivinhos… isso finalmente morre!

Coisas bobas mas que vão dando segurança e paz.

Docker na minha opinião é tão relevante quanto o próprio advento das clouds públicas. Em 20 anos desenvolvendo profissionalmente eu nunca vi nada parecido. Por exemplo, não é toda empresa que pode usar Cloud. Não é todo projeto que pode usar um banco NoSQL. Não é todo projeto que consegue tirar proveito de mensageria.

Mas inequivocamente todo projeto que tem um backend, de alguma forma, consegue direta ou indiretamente tirar muito proveito do docker.

Isso é um fenômeno em capilaridade.

Seja você um amante de tecnologia ou profissional de outra área, ou m Dev, DevOps ou Sysadmin profissional. Beira o impossível não ter argumentos para usar Containers em Desenvolvimento, Teste ou até em mesmo Produção.

Docker é uma das ferramentas mais versáteis que você vai encontrar para ajudar no seu dia-a-dia.

A flexibilidade é tamanha, que a lista de possibilidades é monumental. De estudantes e amadores a grandes corporações como Microsoft, Google, Pinterest, Udemy, Twitter, Nubank, NYC, Medium, Ebay, Coursera, Slack, Hubspot, Asana, ViaVarejo, Booking.com e milhões de outros, todos conseguem usar Docker em níveis de maturidade diferentes.

Para quê?

Não há o que negar, Docker traz uma camada de complexidade, mas te força a trabalhar com setups imutáveis e isolados. Ou seja, ao invés de você depender de um setup de um servidor, você constrói todas as dependências em um script que é usado para criar a imagem.

Outra coisa incrível é que as imagens só são produzidas a partir de dockefiles (não é a única forma, embora seja a única correta). No final do dia, você tem a garantia de consistência.

Embora uma parte das suas definições de infra estejam no dockerfile, na prática o fato da imagem ser produzida a partir dele, faz com que ignoremos dependências de servidor. Nos preocupamos agora com densidade computacional, ou seja, como atochar nossos servidores, claro que respeitando algum critério.

E o que você ganha é a capacidade de rodar local um ambiente muito mais próximo ao de produção. Com os isolamentos de rede, IP, semelhantes aos de produção, com capacidade para rodar um ou diversos contêineres, da mesma imagem ou de ouras imagens, simulando um ambiente clusterizado.

Esse poder facilita o desenvolvimento de microsserviços e monólitos.

A natureza imutável da imagem, faz com que seu pipeline de CI/CD faça mais do que sentido, praticamente seja obrigatório. Mas você ganha a capacidade de fazer rollback com segurança, pois a imagem anterior com toda certeza é imutável.

Essa capacidade te transporta para um mundo com capacidade de apply/rollback e óbvio, rollouts como blue/green deployments e Canary Releases.

Embora a tendência seja que o novato subestime docker, ele é incrivelmente poderoso para entregar tranquilidade para o time.

Para Estudantes e Amadores

Estudantes e amadores, conseguem usar aplicações de terceiros com comandos muitos simples e uniformes. Se você quer subir um SQL Server, para fazer um teste, ou tentar fazer algum trabalho de faculdade com Power BI, é super simples e fácil.

Basta rodar docker run blablabla nome_da_imagem ou docker-compose up e pronto!

Pronto!

Isso é o suficiente para você dar seus primeiros passos.

Quer começar a usar Redis, RabbitMQ, talvez Elastic: Ótima ideia também! Docker simplifica o modo como subimos esses serviços em nossos desktops.

Na prática, no desktop você pode fazer muita coisa e ganhar muito tempo no seu dia-a-dia.

Subir um SQL Server pode levar mais de meia hora, já com Docker não passa de 5 minutos.

Subir um RabbitMQ pode levar algumas horas se você não pegar um tutorial detalhado que fale qual a versão certa do Erlang deve instalar. E a instalar a versão errada vai fazer com que potencialmente não funcione. Pois bem, com docker você pode ter diversas instâncias do RabbitMQ com versões diferentes dele e do Erlang, lado-a-lado. Pratico não é?

Ou projetos que dependem do Java, como Jenkins, SonarQube ou Keycloak: Em minutos você consegue subir todos eles.

Profissionais

Quanto mais caminhamos para um modo mais profissional de usar Docker, vamos ver cada vez mais complexidade. Quando você é um usuário eventual, você pode se dar ao luxo de aprender apenas alguns poucos comandos para subir aplicações. Basta um docker run aqui, um docker-compose up ali, e tudo ok. Quando começamos a usar docker de forma séria, precisamos considerar boas práticas e code smells.

Na prática, é um pouco mais burocrático porque aqui estamos preocupados com o dia-a-dia de produção. Estamos preocupados em não atrapalhar a vida do amiguinho!

Por exemplo, o estudante pode facilmente subir um banco de dados em um contêiner no seu desktop. O profissional, vai fazer o mesmo no seu desktop, mas o profissional muito provavelmente nunca subirá um banco de dados em contêiner em produção. Por que ele sabe o impacto que isso gera.

O amador pode até evitar a criação de um dockerfile, optando por entrar no contêiner e executar comandos. Já quando pensamos no uso profissional do docker, evitar a criação de um dockerfile não existe, e acessar o terminal do contêiner é usado somente para troubleshooting.

Na prática a diferença consiste em fazer as coisas certas, do jeito certo.

Os 6 níveis de maturidade

Enquanto escrevia esse post eu acabei trazendo para ele os 6 níveis de maturidade no uso de containers. Mas acabei achando que o texto ficaria extenso demais e complexo demais. Portanto resolvi separar isso em um novo post. A intenção é descrever os 6 níveis de maturidade no uso de containers, desde a execução de containers até a criação dos seus próprios operators.

Mas vamos deixar isso para um outro post.