Quem nunca teve que instalar um servidor e ficar como um louco procurando infindáveis pacotes de dependências que satisfaçam os pré-requisitos de sua aplicação? Quantos anos de vida já perdi neste dependency hell. Se eu conhecesse o Docker as coisas seriam diferentes?
Você já desenvolveu um software que funciona na sua máquina mas não funciona no servidor? Pois é… Quantas horas você passou em busca do vilão nessas situações para depois descobrir que era uma reles diferença entre versões de um componente da sua máquina e do server.
História Rápida do Docker
Em 2010 uma empresa chamada dotCloud foi fundada. Em 2013 estava prestes a falir quando liberou o Docker 0.9 como open source. Em 2015 recebeu salvadores investimentos de 50 milhões de dólares e fechou parcerias com a RedHat e IBM e a partir daí só cresceu para facilitar nossa vida.
A proposta da dotCloud com o Docker foi de te ajudar a organizar sua infra para não perder suas valiosas horas de desenvolvimento solucionando estes tipos de questões. Para isto o caminho escolhido foi a conteinerização de ambientes. Nada novo em termos de tecnologia mas foi uma mão na roda.
O pulo do gato da conteinerização
Imagine sua aplicação rodando com PHP, MySQL, REDIS, Python, MongoDB. Sua necessidade é bem heterogênea devido a um cache, a uma performance que tem que ser alta mantendo um persistência de dados em um sistema legado. Não importa o motivo, isso pode ser uma grande dor de cabeça.
Há algum tempo você teria um servidor rodando a aplicação e outro rodando os bancos de dados. Ou poderia ter uma máquina rodando tudo. E se precisar escalar esta máquina ou mudar de servidor? Dependendo de como estivesse a sua infra era um “Deus nos acuda”.
Com a conteinerização, você pode definir onde cada serviço destes rodará e utilizando quantos containers quiser. Cada container é isolado e tem sua característica individual. Podemos ter versões de softwares ou até distribuições de sistemas operacionais diferentes rodando em cada container. Podemos até ter um container rodando na Amazon, outro na Digital Ocean e outro em seu próprio host, por exemplo
Caso um dos containers caia os outros continuarão trabalhando normalmente de forma independente. Isso pode ser de suma importância para manter seu serviço disponível.
Outro fator relevante para a utilização de containers é ele ser extremamente leve em relação a um servidor tradicional como conhecemos. Como isso é possível? O container funciona utilizando o kernel do host sobre o qual está rodando. Isto diminui drasticamente o seu tamanho e aumenta muito a velocidade de boot.
Cabe lembrar que a conteinerização é diferente da virtualização. Na virtualização você simula o hardware de uma máquina, por exemplo. Isto não acontece com o Docker. Segue abaixo uma ilustração sobre algumas diferenças.
Onde devo utilizar o Docker?
Se você tem um ambiente de desenvolvimento de software com diversos requisitos de infraestrutura, na minha opinião, você deve utilizar o Docker.
Seguem alguns dos motivos:
- Facilidade de replicação;
- Recuperação da arquitetura de sua infra de forma ágil em caso de desastre;
- Possibilidade de versionamento dos seus scripts de criação da infra de forma que em caso de algum problema você possa voltar atrás;
- Gerenciamento feito de forma isolada de cada item de sua infraestrutura assim como suas características individuais;
- Replicação de sua infra de forma rápida ganhando velocidade em situações que demandem acréscimo rápido de capacidade de processamento e vice-versa;
- Necessidade de um ambiente de desenvolvimento em que você coloca programadores trabalhando em uma mesma infra com componentes, sistema operacional e versões de softwares iguais.
Conclusão
Quer parar de perder tempo formatando máquina, procurando o sistema operacional com a versão que você precisa e reinstalando todo o sever? Abrace o Docker e seja feliz!