E aí, gente?

Você que lê meus artigos já está acostumado a ver por aqui as principais novidades sobre Docker e tecnologia associadas, e hoje não será diferente. Queremos trazer uma preview sobre as novas features que serão lançadas na versão 1.13 do Docker. Como todos os sabem, o ciclo de desenvolvimento dentro do Docker é algo fora da curva, e a cada nova versão alguma novidade aparece – e é possível acompanhar esse ritmo pelo próprio GitHub deles.

Mas se você não quiser esperar a versão estável para brincar com as novidades, pode utilizar a versão experimental do Docker, que obviamente não é recomendada para se colocar em produção, mas que pode ser usada para lab sem problema. Para isso, basta você instalar o Docker com o seguinte comando: curl -sS https://experimental.docker.com | sh. Com isso, você terá acesso à engine com as modificações mais atuais, mas em fase de desenvolvimento ainda.

Bom, chega de papo, vamos a uma pequenas lista das novidades do Docker 1.13:

Docker stack

Para quem usa docker-compose ou docker service, sabe das diferenças entre essas duas “ferramentas” e como, de certa foram, elas deveriam se complementar, não é mesmo? E essa é uma situação que vinha sendo trabalhada pelos engenheiros do Docker há algum tempo – essa função intermediária vinha sendo testada através do comando docker stack, que possibilita criar um serviço dentro do Swarm baseado em uma estrutura do docker-compose, ou seja, você conseguirá portar para o cluster de Swarm um serviço baseado no docker-compose, isso facilita em muito a administração de seu serviço e, claro, no deploy, pois garante que o serviço esteja rodando independentemente do nó onde ele está.

Nas versões de teste, você tinha que gerar um arquivo .dab (distributed application bundle ou pacote de aplicação distribuída) baseado em seu docker-compose.yml e depois, sim, você conseguiria fazer deploy dessa stack utilizando o Docker. Agora, no Docker 1.13, isso não é mais necessário, basta você chamar o arquivo docker-compose.yml diretamente no deploy da stack – algo como isto:

# docker stack deploy --compose-file ./docker-compose.yml minhastack

Muito mais simples e rápido, não?

Gerenciamento de senha

Ou gerenciamento de segredos, essa é uma função básica dentro de qualquer orquestrator – o Kubernetes já possuía esse conceito e aplicação há algum tempo já, e agora o Docker também implementa essa funcionalidade.

Mas, afinal, onde vou usar isso? Sua aplicação usa senha, não usa? Seja para banco, API etc., qualquer aplicação usa senha de acesso a algum serviço em algum momento, e como você faz hoje com Docker? Provavelmente via variável de ambiente ou compartilhando um arquivo com o container – existem outras formas, como ferramentas as a service de gerenciamento de identidade.

Agora, no Docker 1.13, você pode definir uma secret que pode ser utilizada pelo seu serviço dentro do Swarm, exatamente da mesma forma que o Kubernetes usa. Para isso, foram adicionados quatro comandos novos, são eles:

• docker secret create
• docker secret inspect
• docker secret ls
• docker secret rm

Veja um exemplo de como criar uma secret para ser utilizada dentro de seu serviço:

# echo "123456" | docker secret create senha-banco

Agora um exemplo de como utilizar essa secret em seu serviço:

# docker service create --name app --secret senha-banco ubuntu

Dentro do container, será criado um arquivo em /run/secrets/senha-banco com a informação da senha – isso, é claro, apenas dentro do container, sem precisar mapear nada do host para o container.

# docker exec -it app cat /run/secrets/senha-banco
123456

Um detalhe muito importante é: as secrets podem ser utilizadas apenas dentro de serviços; se você criar um container com o docker run, não poderá utilizar essa funcionalidade.

Novo parâmetro de rede no Swarm

Essa talvez seja uma das melhorias mais importante no core do Docker, pois permite que você adicione uma rede do Swarm mesmo se o container for criado fora de um serviço, ou seja, criado da forma tradicional com o docker run… Mas, afinal, por que isso é importante? É importante porque agora é possível adicionar um container à mesma rede do serviço criado no Swarm – isso é muito útil para debugs ou até mesmo testes de ambiente.

E como fica agora, então? Simples, veja:

# docker network create --driver overlay --attachable rede-plugavel

Com o comando acima, nós criamos uma rede overlay do Swarm, e a diferença agora é o parâmetro –attachable, que permite que essa rede seja plugada em qualquer container criado, e no comando abaixo nós plugamos um container a essa rede:

# docker run --rm -it --net rede-plugavel centos ping google.com

Plugins

Finalmente, alguns plugins que estavam sendo testados e aprimorados foram disponibilizados como estáveis dentro da engine do Docker. Entre eles podemos destacar o Flocker e o Weave, que agora têm integração total com Docker.

Docker Daemon –experimental

Até então, para você poder utilizar comandos e opções em desenvolvimento/teste do docker, você teria que instalar a versão experimental ou test da engine, mas agora basta você iniciar o daemon do Docker com a opção –experimental; com isso, serão habilitadas em momento de execução as opções da versão experimental, veja:

Melhorias no docker service

Essas, na verdade, são algumas das melhorias que a comunidade pediu ao longo do meses, e uma delas tem relação com o update da imagem no update do serviço. Para quem não notou, quando um serviço era atualizado (até então), você precisava executar um update com alguns parâmetros a mais para poder atualizar o serviço com uma nova imagem; na nova versão, esse processo pode ser feito passando o parâmetro –force junto, e o docker service update já verificará se há uma versão mais recente da imagem e atualizará o serviço baseado nisso.

Novo parâmetro no docker service

Além das melhorias no docker service, foi acrescentado também um novo parâmetro. Hoje nós acessamos um serviço através da porta exposta do mesmo, que você pode definir com o parâmetro –publish; no Docker 1.13, será possível você definir de forma mais detalhada essa regra, isso deve-se ao novo parâmetro –port, que, da mesma forma que o –mout, tem sintaxe parecida com csv, onde você define item=valor,item=valor… Veja um exemplo:

# docker service create --name servico_web --port mode=ingress,target=80,published=8080,protocol=tcp

Dessa forma você tem, de forma mais clara, as definições de porta do serviço.

Outras novidades

Entre outras novidades do Docker 1.13, podemos destacar ainda algumas que têm bastante relevância para quem o utiliza, como:

• Cache de Layer para o Build: Para que gera muitas imagens, sabe que esse era um problema a ser resolvido, exemplo: geramos um imagem agora com o docker build; caso tenha que modificar essa imagem, todas as layers anteriores à alteração não eram buildadas novamente, e o docker build usava o cache para elas. Agora, digamos que mandamos essa imagem para outro host e queremos fazer outra modificação nela, o que ocorre? Exatamente, todas as layers são buildadas novamente, isso pelo fato de o Docker não ter naquele host o cache de build dessa imagem. Parece ser trivial, mas quando se quer ganhar tempo, não é. No Docker 1.13, você pode especificar na hora do build de onde o Docker poderá buscar o cache de build, como:

docker pull imagem:v1.0
docker build --cache-from imagem:v1.0 -t imagem2:v1.1 .

Dessa forma o build da nova imagem utilizará o cache da imagem original, compilando assim apenas as layers diferentes.

A instrução MAINTAINER  foi removida do Dockerfile, agora essa informação deve ser utilizada através de label;

• Foi adicionado um novo comando, ainda experimental, que é o docker service logs, para visualizar os logs do serviço e não do container em si.
• Outra adição do docker service foi o parâmetro –rollback que tem por objetivo realizar o update do serviço através de uma versão anterior à atual;
• Remoção de container velhos através do docker system (ainda não há mais informações sobre como esse comando funcionará para remoção de containers antigos, então ficamos ligados no lançamento).

Ok, Cristiano, e quando a nova versão será lançada? Não há uma data 100% definida, o que se sabe é que será lançada até inicio de janeiro de 2017, então pode ser que seja lançada hoje mesmo ? . Pode haver mais modificações? Claro, sempre há e com certeza as novidades que trouxemos hoje serão melhor explicadas após o lançamento oficial. Então, o jeito é ficar ligado nos nossos artigos e, claro, no site do oficial do Docker.

Grande abraço!