Gomex: Lançamento do Docker 1.6

O Docker continua crescendo muito rápido e com pouco mais de 2 meses, lança uma nova versão recheada de novidades.

Entre as novidades desse lançamento temos: Label para containers, cliente Docker para Windows, driver para log. Isso sem contar com os lançamentos do compose 1.2, Swarm 0.2 e machine 0.2. Vamos detalhar um pouco esse mega release.

Label para containers

Esse recurso é muito interessante a nível de organização e agrupamento. Uma vez que as tags tem um papel quase como “versionamento”, as labels assumem a marcação que pode incluir “assuntos”, “funcionalidades”, “ambiente” e afins nos containers. Pode parecer pouca coisa para quem usa o Docker para uma situação específica, mas para grandes soluções é uma ajuda e tanto.

Quer aprender a usar? Leia aqui.

Cliente Docker para Windows

Finalmente parece que a Microsoft conseguiu entrar em alguma tendência no momento certo, pois está apostando fortemente no Docker. A demonstração disso foi a submissão de 70 pull requests. Assim como no MAC, O Windows somente poderá ser utilizado como cliente remoto que deve ser conectar a um Docker “Server”, que ainda é só pode ser instalado nativamente apenas no GNU/Linux.

Muitos amantes do GNU/Linux podem ficar tristes com essa declaração, mas a grande funcionalidade do Docker que é “Faça uma vez, rode em qualquer lugar” talvez dependa desse suporte nativo mais amplo da Microsoft. Isso levando em consideração que ela cumpra sua promessa de manter a compatibilidade.

Você pode ler mais sobre isso no blog da Azure.

Driver para log

Tem havido um número crescente de propostas para uma API de registro que lhe permitiria enviar logs de containers para outros sistemas, como Syslog ou um terceiro. Esse novo driver de log  segue o mesmo conceito de storage e exec já presente no Docker.

A opção docker run –log-driver tem três possibilidades:

json-file (padrão): Que é basicamente o que já usado no Docker atualmente. Todos os logs dos containers são armazenados na pasta /var/lib/docker/containers/<Containers ID>/<container id>-json.log

syslog: Como o próprio nome já revela, é uma forma de enviar esse log via syslog do host “hospedeiro”. Veja como funciona:

# docker run -d –log-driver=syslog gomex/debian:padrao echo “Hello”
c2ed7a98583c82a90111ffba5fb89e73dcd6e681a03c921da538a84ffd7216d0

No /var/log/syslog estará assim:

Apr 17 23:29:18 gondor docker[15432]: c2ed7a98583c: Hello

Perceba que temos tanto o nome aplicação docker como o ID resumido do container, o que é o suficiente para fazer uma boa gerência desse log. Ótimo para quem deseja minimizar o máximo de processos em execução no container, mas não abre mão de um log centralizado e organizado.

none: Como o próprio nome também já revela, é uma forma de não gerar log do container para o host “hospedeiro”. Essa opção é ótima para containers que geram logs desnecessários.

Outros lançamentos

A comunidade Docker promoverá alguns Meetups para apresentação das novidades do Swarm, Compose e Machine. Não perca!

Referência:

https://blog.docker.com/2015/04/docker-release-1-6/

Gomex: Criação automatizada de imagens Docker (GitHub e Docker Hub)

Como expliquei no artigo anterior sobre Docker, o processo de criação de imagens no Docker é bem simples, mas requer algum esforço e acompanhamento para saber se ele concluiu corretamente e esse resultado será visualizado em linha de comando, normalmente imagem a imagem. Um trabalha “manual”.

Criação em massa

Quando você trabalha com muitas imagens, e a mudança dessas imagens é constante, você precisará de uma solução mais automatizada e de um processo mais simples pra viabilizar a criação dessas imagens. É nesse momento que entra o serviço de automatização de criação das imagens do Docker Hub junto ao GitHub.

Docker e GitHub, Juntos! :)

Automação de builds

O Docker Hub tem um serviço de Automação da criação de imagens (Build), com integração com GitHub, ou seja, toda vez que você efetuar um commit e push no Dockerfile do seu repositório será realizado automaticamente um novo build da imagem, já armazenando no Docker Hub e apresentando o log de criação dessa imagem. Praticamente uma integração contínua da sua imagem

Olha como é fácil a interface!

Para configurar isso é muito simples. Basta seguir os passos abaixo:

1. Crie uma Conta no Docker Hub e efetue login.
2. Link sua conta do GitHub através do menu “Link Accounts”.
3. Configure o build automatizado.
4. Escolha o projeto GitHub que deseja utilizar. Lembre-se que ele precisa ter um Dockerfile para efetuar a build.
5. Escolha a branch que você quer efetuar a build (Por padrão é usada a branch master).
6. Dê um nome a esse build automatizado.
7. Opcionalmente, aplique uma tag Docker tag para a build.
8. Especifique onde o Dockerfile está localizado. O padrão é “/".

Uma vez o build automatizado é configurado ele será ativado automaticamente e em poucos minutos você pode visualizar sua imagem Docker Hub. Ela será mantida sincronizada com base no Dockerfile do seu repositório GitHub até que você desative o Build automatizado em questão.

Visualizando a situação da build

Se você quiser visualizar a situação do seu build automatizado, basta acessa o menu “Build detail” na sua imagem dentro da sua conta do Docker Hub, assim conseguirá visualizar o status da sua build e todo o histórico.

Como funciona a atualização

Vale lembrar que você o build automatizado não será ativado com o comando “docker push", você apenas poderá enviar modificação, e por consequência efetuar automaticamente o build dessa imagem, através do git commit e push para o repositório previamente configurado no link entre GitHub e Docker Hub.

Você pode criar múltiplos builds automatizados por repositório e configurar ele para apontar para um específico Dockerfile ou branch diferente.

Build Triggers

É possível ativar o build automatizado a partir de uma url. Basta habilitar o “Build triggers” em sua build automatizada. Agora você conseguirá gerar uma build por demanda e não apenas com base em commit e push.

Atenção!

Vale a pena lembrar que todo processo descrito aqui não leva em consideração repositórios e imagens privadas. Caso seja sua situação de não publicizar esse trabalho, tenha cuidado com relação a isso.

Referência

https://docs.docker.com/userguide/dockerrepos/