Prefácio, por Jérôme Petazzoni

Em março de 2013, durante a PyCon US em Santa Clara, nós fizemos a primeira demonstração pública do Docker. Não tínhamos ideia de que estávamos prestes a começar a "revolução do container".

O que seria essa "revolução do container"? Seria mesmo uma revolução, ou um exagero? Afinal, containers têm estado conosco por muito tempo, então, por que só agora estamos falando sobre uma revolução?

Eu gostaria de responder essas questões com uma pequena história. Mais de 10 anos atrás, descobri um projeto chamado Xen. Você provavelmente já ouviu falar sobre ele. Na verdade, se você já usou a Amazon EC2, você com certeza o usou.

Xen é um hypervisor. Ele permite que você rode múltiplas máquinas virtuais em apenas uma única máquina física. Em 2004, o Xen tinha várias limitações: só funcionava no Linux, e requeria kernels personalizados.

Xen podia fazer algo incrível: ele era capaz de fazer live migration (migração em tempo real), ou seja, você podia mover uma máquina virtual funcionando para outra máquina física, sem parar (ou mesmo reinicializar) a máquina virtual.

Eu achei isso bastante impressionante. Mais importante ainda, máquinas virtuais Xen podiam iniciar em alguns segundos, e suas perfomances eram ótimas. Foi difícil dizer a diferença entre uma máquina física e uma máquina virtual. Essas máquinas virtuais eram quase tão boas quando as reais, mas elas eram muito mais fáceis de serem instaladas, movidas de lugar, de debuggar ─ e elas eram mais baratas, porque nós podíamos colocar várias máquinas virtuais em um único servidor.

Isso me convenceu de que as máquinas virtuais poderiam ser a base para uma hospedagem melhor e mais barata, e eu comecei minha própria companhia para vender servidores baseados em máquinas virtuais.

A tecnologia era boa, porém muitas pessoas eram céticas e queriam os servidores de verdade. Lembre-se de que isso foi poucos anos antes da Amazon Web Services lançar a EC2.

Dez anos depois, o sentimento havia mudado. Claro que ainda havia aplicações que não podiam ser rodadas "na nuvem" por diversos motivos; mas a maioria dos novos deploys agora envolviam IAAS (Infrastructure as a Service) ou PAAS (Platform as a Service) em algum ponto.

Qual foi a razão para essa mudança? Seria essa feature mágica de migração em tempo real? Não. Seria porque máquinas virtuais são mais baratas que as físicas? Não. A verdadeira razão é a automatização. Agora, nós podemos escrever programas e scripts para criar servidores, implantar nossas aplicações neles, e escalá-las verticalmente de forma fácil.

Em nossos repositórios, nós temos arquivos infrastructure as code (infraestrutura como código), descrevendo arquiteturas complexas compostas por dezenas, centenas, milhares de servidores; e quando nós mudamos esses arquivos, as máquinas são provisionadas e destruídas da forma correta. Essa é a revolução que a virtualização tornou possível.

Com containers, nós vamos ver uma revolução similar. Muitas coisas que eram consideradas impossíveis ou impraticáveis estão se tornando não só possíveis, como fáceis. Teste e integração contínua; infraestrutura imutável; blue/green e canary releases; golden images... Todas essas técnicas (e mais) estão agora disponíveis para a maioria dos desenvolvedores, em vez de serem um luxo ou um privilégio das maiores e modernas organizações como Amazon, Google, ou Netflix.

Hoje, quando eu ouço alguém dizer "containers não vão trabalhar para nós", eu ouço a mesma voz que diziam "máquinas virtuais não vão trabalhar para nós" há dez anos. Não seja essa voz. Não estou pedindo para você abraçar os containers para todos os usos e propósitos. Porém, neste livro, você verá muitas formas nas quais o Docker e os containers podem melhorar o desenvolvimento e deploy de sua aplicação. Com certeza você achará pelo menos uma que fará o seu trabalho e sua vida mais fáceis!