Docker e Travis

Olá pessoal,

Hoje vamos demonstrar como é utilizado o Travis CI juntamento com Docker.

Travis CI é um serviço de integração continua na nuvem que pode ser integrado com repositórios do Github, ele é gratuito para repositórios públicos e pago para repositórios privados. Possui suporte as principais linguagens de programação como: C, PHP, Java, Perl, Ruby, Python, Go, C++, Erlang e etc…

O Travis trabalha da forma que a cada push que é dado para o Github:

  • Travis cria uma máquina virtual onde será excutado o código.
  • Pega o seu código do Github.
  • Faz o deploy da aplicação na máquina que ele criou anteriormente.
  • Executa os testes configurados pelo usuário.
  • Notificar o usuário sobre os processos ocorridos no Travis.

O ciclo de build completo do Travis possuindo 10 passos que podem ser executados, possuindo 3 dos passos como sendo opcional:

  1. Installapt addons (Você pode instalar diversos pacotes como gcc,time,make,etc..)
  2. before_install 
  3. install
  4. before_script
  5. script
  6. after_success or after_failure
  7. OPTIONAL before_deploy
  8. OPTIONAL deploy
  9. OPTIONAL after_deploy
  10. after_script

   Como você pode ver nos passos acima, existem diversas configurações que podem ser feitas dentro do arquivo .yml, o tornando um arquivo gigantesco de configuração, em nosso próximo post sobre DevOPS vamos nos deter a criar um ambiente real e dai sm usar muitas dessas opções.

   Mas como podemos utilizar isso com Docker então? Utilizamos o Travis na parte de criar nossas imagens, para que tenhamos um maior controle sobre nossos deploy e também para que nada de errado ocorra em nosso ambiente de produção. A cada modificação em nossa aplicação que é publicada no Github o Travis nos auxilia para a criação de uma nova imagem onde será executada a aplicação, mantendo a imagem sempre atualizada e também sempre nos notificando quando possui algum erro.

Exemplo do arquivo Travis.yml que é onde é feita a parte de configuração para cada aplicação.

#Diz que os comandos serão executados com sudo
sudo: required
#Qual a linguagem será utilizada
language: ruby

#Diz que o docker será utilzado para ser feito o deploy
services:
  - docker

#Irá rodar todos os comandos abaixo antes de fazer o build da aplicação
before_install:
- docker pull carlad/sinatra
- docker run -d -p 127.0.0.1:80:4567 carlad/sinatra /bin/sh -c "cd /root/sinatra; bundle exec foreman start;"
- docker ps -a
- docker run carlad/sinatra /bin/sh -c "cd /root/sinatra; bundle exec rake test"

#Executara o comando de criação do build
script:
- bundle exec rake test

Pessoal demonstrei aqui apenas um pouco de como podemos utilizar o Travis para a integração com Docker, no próximo post sobre DevOps irei fazer um tutorial mostrando como podemos utilizar Travis na pratica mesmo. Fique ligado em nossos posts e tire suas dúvidas.

Entrevista com Jérôme Petazzoni

Oi Pessoal!

Hoje vamos reproduzir aqui uma entrevista concedida pelo Jérôme Petazzoni para o site: opensource.com. Para quem não o conhece, o Jérôme é um dos principais evangelistas Docker, esteve presente na QCon que ocorreu em agosto em São Paulo. A entrevista foi realizada por Sandeep Khuperkar que é um dos moderadores do site. Veja abaixo:

O que são containers? Quais tecnologias de containers existem e como o Docker é diferente delas?

De um ponto de vista mais abrangente, containers são máquinas virtuais mais leves. Você pode instalar qualquer coisa em um container, independente de  (e sem afetar!) outros containers em seu servidor. Cada container possuí sua própria camada de rede, processo (PID), sistema de arquivo, etc. A carga de trabalho é significantemente menor do que em VMs: containers iniciam mais rápido, requerem menos memória e espaço em disco. Isso por que, de um ponto de vista mais técnico, containers são processos regulares dentro do servidor, utilizando features do kernel como namespaces e cgroups para garantir isolamento. Iniciar um container é iniciar um processo UNIX normal; Criar um container  é apenas uma clonagem instantânea de um sistema de arquivos copy-on-write (Que hoje é extemamente barato, tanto em tempo de criação quanto em uso de espaço em disco).

O Docker é diferente das demais tecnologias, pois ele não é apenas uma engine para criação de containers, Docker é uma plataforma composta pela Docker Engine (para criar e executar containers), o Docker Hub (um repositório de armazenamento de imagens publicas, onde é possível o usuário criar e armazenar imagens customizadas), e ainda um vasto ecosistema de ferramentas como Docker Compose, Docker Machine, Docker Swarm, e muitas outras, todas girando em torno de um API pública e aberta.

De que forma o Docker diferente de outras tecnologias de hypervisor para virtualização?

Pode-se dizer que Docker é um “hypervisor para containers”, mas muitos não aprovarão esse metafora, uma vez que hypervisors geralmente gerenciam VMs, e Docker gerencia containers. Os detalhes técnicos são muito diferentes, quando um hypervisor inicia uma VM, ele cria hardware virtual, e aproveita instruções da CPU ou de recursos específicos, como VT-x, AMD-V. Quando Docker cria um container, ele aproveita recursos do kernel como namespaces e cgrups , sem depender de recursos de hardware específicos.

Por um lado os containers são mais portáteis, pois podem ser executados tanto em VMs quanto em servidores físicos, Por outro eles não são portáteis devido ao fato de serem atrelados ao kernel do servidor onde estão, isso quer dizer, por exemplo, que você não pode executar um container Windows dentro de um kernel Linux (exceto se o seu Linux conseguir executar binários do Windows).

O que você sugere para gerenciar armazenamento em containers Docker? Como é possível vincular dados com containers Docker?

Docker tem trabalha com o conceito de “volumes”, que são os diretórios compartilhados entre o container e seu servidor. Volumes são conceitualmente semelhante as “pastas compartilhadas” em máquinas virtuais, exceto elo fato de que eles não necessitam de qualquer configuração particular no container, e tem  zero de overhead, pois eles são implementados utilizando pontos montagens.

Quando você tem dados que encontram-se em um disco (seja disco local, ou um pool de RAID, ou algo montado através da rede, ou qualquer outra coisa) a opção mais fácil é montar esse disco no host, e em seguida, expô-lo ao container através de um “volume”.

Docker também tem (uma nova marca, ainda experimental) mecanismo de plug-in que permite que um container forneça armazenamento para outros containers. Isto significa que um container pode ser responsável pelo execução de um agente ou membro de uma rede Ceph, Gluster, ou qualquer outro cluster de armazenamento, e expor os dispositivos de bloco e os pontos de montagem para outros containers.

Como você faz para mover os dados de um container Docker para outro iniciado em outro servidor?

Exatamente como fizemos isso antes dos containers: armazenamento de rede, sistemas de arquivos distribuídos, a transferência de dados ou sincronização com rsync, unison, etc. Há, porém, duas vantagens ao usar containers: Em primeiro lugar, a nossa forma de acessar os dados são abstraídos do container, Se eu mudar, por exemplo, de DRBD para Ceph, meu container não precisa saber qual é a tecnologia utilizada, na verdade, o mesmo container será executado de forma idêntica em armazenamento local, ou em armazenamento distribuído. A outra vantagem vem desses novos plugins de armazenamento, eles vão fazer o acesso aos dados mais simples, separando corretamente o container de aplicação do container de armazenamento.

Como você pode garantir que as modificações de um container em execução são salva na criação de uma nova imagem?

Docker oferece chamadas de API para comparar um container com sua imagem original, e para criar uma nova imagem a partir de um container existente. Os comandos CLI para essas chamadas de API são “docker diff” e “docker commit”.

Como os containers Docker podem ajudar a criar soluções altamente disponíveis?

Quando você  cria um sistema altamente disponível, você geralmente passa um bom um tempo pensando em uma lista de coisas que devem ser feitas. Docker tornará algumas dessas etapas mais fácil, por exemplo, garantindo que você possa implantar novas versões de seu software nas máquinas de produção de forma mais ágil. O Docker não vai resolver problemas magicamento (o uso da magia na criação de sistemas é não é aprovado geralmente), mas ele vai tornar muitas das coisas mais fáceis, mais rápidas, mais confiáveis – da mesma forma do que usar um gerenciador de pacotes é geralmente mais conveniente do que a compilação de tudo, desde o código fonte.

Como você vê a crescente adoção do Docke em clientes empresariais e ambientes de produção?

De um modo geral, a visão é essa:: Docker inicia como uma ferramenta para desenvolvimento para consistência e repetição do ambiente, similar como o Hashicorp’s Vagrant faz. Então, gradualmente se forma CI/CD, onde ele ajuda a reduzir tempos de teste pela metade (ou até mais). Dai em diante ele é utilizado em testes de  pre-produção, onde o risco é menor. Eventualmente, uma vez que a equipe operacional ganhou experiência e confiança suficiente com o funcionamento do Docker, ele vai passa a atender todo o tráfego do ambiente de produção.

Legal não? Quer ver na íntegra? acesse: http://opensource.com/business/15/8/interview-jerome-petazzoni-docker-linuxcon

Fique atento e nos ajude divulgando do blog! Grande abraço.

Docker 1.10

Oi Pessoal,

Novidades no Docker, é claro que tem aqui no  mundodocker.com.br ;). Vamos trazer um apanhado do que há de novo na última versão da engine, assim como nas ferramentas do seu ecossistema. Vamos lá:

Docker Engine 1.10

  • Melhoramento na captura de eventos: A instrução docker events foi reformulada e teve uma melhoria significativa nos métodos utilizados, isso garante um tempo de resposta menor e mais precisão nos dados capturados.
  • Aperfeiçoamento no trabalho com imagens: Foram refatorados diversos trechos de código o que tornou o download e upload de imagens cerca de 3 vezes mais rápida, e garante um melhor controle em caso de falha do download.
  • Alteração de configuração online: Quando você seta os valores de limite (como cpu, memória, etc), tradicionalmente você precisaria reiniciar o container ou até mesmo recria-lo, agora na versão 1.10 você pode fazer essa alteração online, utilizando o comando: docker update.
  • Arquivo de configuração: Agora é possível redefinir alguns parâmetros e recarregar o docker sem a necessidade de reiniciar nada.
  • Sistema de arquivo temporário: A partir da versão 1.10 ficou mais fácil criar um ponto de montagem temporário, isso é muito útil quando você tem um container read-only mas sua aplicação precisa escrever em disco (log, sessão, etc), basta passar o parâmetro: –tmpfs no docker run.
  • Restrições de I/O de disco: É possível definir diversos parâmetros para restringir acesso a disco, entre eles: --device-read-bps, --device-write-bps, --device-read-iops, --device-write-iops, e --blkio-weight-device
  • Novo plugin de log: Agora é possível integrar o Splunk ao Docker para coleta dos logs.
  • Entre outras diversas correções de segurança e performance.

Docker Swarm 1.1

  • Reagendar containers quando um nó falhar: Essa é uma solução em fase de testes ainda, mas permite que o Swarm recrie o container em um nó que esteja disponível para atender, lembrando que esse é um recurso de teste, é possível que tenha alguns bug ainda.
  • Foram realizadas diversas melhorias para definição da ‘saúde’ do nó, isso garante um melhor gerenciamento dos recursos utilizados e claro possibilita criar um politica mais eficiente de deploy.

Docker Network

Na parte de rede do Docker foram feitas algumas melhorias significativas, algumas apenas ajustes e resolução de problemas encontrados na versão anterior, outras novidades mesmo, entre elas:

  • Rede Interna: Agora é possível criar uma rede para trafego interno (de entrada e saída), facilitando assim a sub-divisão das redes e facilita a organização topológica de seus ambiente.
  • IP personalizado: Você pode definir um ip personalizado independente da rede onde ele está criado, você não fica restrito ao range de ip de onde sua rede pertence.
  • Rede multi-host: Suporte todas as versões antigas do kernel (do 3.10 em diante), até a versão 1.9 você só poderia utilizar esse recursos em uma versão especifica do kernel.

Docker Compose, Machine e Registry: Tiveram algumas correções de bug e refatoração em seus códigos para que ficassem mais performáticos, mas nenhuma grande novidade, mas com certeza serão trabalhados para a próxima versão.

Espero que tenha ajudado, e não fique esperando, baixe e utilize essa última versão, para a comunidade isso é muito importante, quanto mais feedback melhor, e isso vale para o nosso blog também

Se gostou, ajuda divulgando o blog, grande abraço!

Auto Complete para Docker

Olá!

Hoje o post será um pouco diferente dos que geralmente publicamos, queremos mostrar para vocês como é possível utilizar a funcionalidade de auto complete do shell para os comandos Docker. Mas para que isso? Simples, facilidade e agilidade na execução de comandos, quem aqui nunca apertou o tab depois de digitar ‘./conf’? Então, você deve sentir falta dessa facilidade quando se utiliza os subcomandos do docker, certo? Queremos mostrar pra vocês como resolver isso.

Como você já viu aqui, existem diversos subcomandos do docker, e cada um possui diversos parâmetros que podem ser utilizados, com o docker –help você poderá visualizar as opções disponíveis.

Mas isso é chato algumas vezes, é mais fácil começar a digitar docker run --vol...[tab][tab]e deixar o autocomplete fazer o trabalho:

$ docker run --volume
--volume         --volume-driver  --volumes-from

#vamosinstalar?

No Mac OS X

O processo é simples, estando no Mac OS X temos que instalar o auto completion usando o brew:

$ brew install bash-completion

E em seguida adicionar as linhas em nosso arquivo de profile ($HOME/.bash_profile ou /Users//.bash_profile)

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
fi

Você pode executar os seguintes comandos, que devem ser utilizados nesta sequência:

$ echo "if [ -f $(brew --prefix)/etc/bash_completion ]; then" | tee -a $HOME/.bash_profile
$ echo "    . $(brew --prefix)/etc/bash_completion" | tee -a $HOME/.bash_profile
$ echo "fi" | tee -a $HOME/.bash_profile

Atenção: Se não temos o homebrew instalado, veja em http://brew.sh/ mais informações de como instala-lo e utiliza-lo.

 
No Linux

No Linux, como sempre, é mais simples, basta instalar via gerenciador de pacotes da sua distribuição. Se for Debian like (Ubuntu, Mint, etc) usamos o apt-get:

$ sudo apt-get install bash-completion

Se for Red Hat like (RHEL, CentOS, Fedora, etc) então usamos yum:

$ sudo yum install bash-completion

Completion do Docker Engine

O arquivo está disponível em https://github.com/docker/docker/blob/master/contrib/completion/bash/docker portanto sempre que fizer uma atualização é recomendável que você baixe novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker.

Ao baixar devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux, se estivermos em um Mac OS X:  $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > $(brew --prefix)/etc/bash_completion.d/docker
No Linux
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > /etc/bash_completion.d/docker

Completion do Docker Compose

De maneira similar o arquivo está disponível emhttps://github.com/docker/compose/blob/master/contrib/completion/bash/docker-compose . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Compose.

Ao baixar também devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > $(brew --prefix)/etc/bash_completion.d/docker-compose
No Linux
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

Completion do Docker Machine

O processo é praticamente o mesmo porém o docker-machine possui 3 arquivos de auto complete. Os arquivos estão disponíveis em https://github.com/docker/machine/tree/master/contrib/completion/bash .

Como dito anteriormente devemos colocá-los na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

Como são mais arquivos recomendo utilizarmos um loop para baixarmos todos em sequência utilizando apenas um comando.

No Mac OS X
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > `brew --prefix`/etc/bash_completion.d/$file
done
unset machineVersion
No Linux
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > /etc/bash_completion.d/$file
done
unset machineVersion

Observe que:

  1. Se você utilizar alguma versão específica de uma dessas ferramentas basta baixar os arquivos da pasta correspondente.  Por exemplo o docker engine, da maneira que mostramos vamos pegar o arquivo que está na branch master, atualmente versão 1.12.1, para pegar na versão 1.11.0 por exemplo o arquivo fica em https://github.com/docker/docker/blob/v1.11.0/contrib/completion/bash/docker
  2. O Docker disponibiliza alguns arquivos de completion para outros shells. O Docker Engine disponibiliza bash, zsh, fish e powershell como podemos ver em https://github.com/docker/docker/tree/master/contrib/completion .
  3. O Docker Compose e o Docker Machine disponibilizam apenas para bash e zshcomo vemos nas urls https://github.com/docker/compose/tree/master/contrib/completionhttps://github.com/docker/machine/tree/master/contrib/completion .

E era isso por hoje pessoal, agradecimento especial ao @wsilva pela dica. Já sabe, ajude divulgando o blog, e tendo dúvidas ou sugestões deixa ai nos comentários

Abraço!

Fonte: http://dumpscerebrais.com/2016/09/auto-complete-para-docker-engine-machine-e-compose/

Segurança e hacking de containers Docker

Olá gente! Tudo bem?

Como vocês podem ter notado, meu nome é Fernando e este é o meu primeiro post aqui no blog, e minha contribuição será no sentido de esclarecer e ajudar vocês com algumas questões que pouca gente se preocupa, ou até mesmo implementa, mas que eventualmente pode prejudicar a sua aplicação ou seu negócio, sim, hoje falaremos sobre Segurança .

A alguns meses iniciei uma busca por informações sobre segurança relacionado a Docker, pois não via quase ninguém falar, na época até pensei que era porque eu estava por fora dos grupos de discussões, mas ao ir conversando com algumas pessoas bem envolvidas com a comunidade Docker fui vendo que em português temos bem pouco sobre este assunto. Então comecei a buscar por este assunto e fui encontrando materiais em inglês, assim fui montando um compilado de materiais sobre para tentar criar uma apresentação ou artigo. Conversando com o Cristiano do Mundo Docker, que é um membro muito ativo na comunidade Docker, recebi bastante incentivo pois ele também achou que o assunto é bem importante e pouco abordado, e nesta conversa surgiu a ideia de fazer uma pesquisa com a comunidade para saber de quem está usando Docker o que estão fazendo com relação a segurança.

Foi um questionário bem simples, com 3 perguntas  que foi realizado entre 14 e 25 de agosto 2017, com 36 participantes.

Primeira pergunta: Já utilizou Docker em produção?

Mais de 55 por cento das pessoas que participaram da pesquisa responderam que utilizam Docker em produção.

Segunda pergunta: Verifica vulnerabilidades nas imagens utilizadas?

Dos 36 participantes menos de 20 por cento faz algum tipo de verificação para tentar identificar vulnerabilidades nas imagens Docker utilizadas.

Terceira pergunta: Como verificar vulnerabilidades?

E na última pergunta a ideia era identificar se é utilizado algum tipo de ferramenta para fazer as verificações de vulnerabilidades. Dos 19.4% que responderam que fazem alguma verificação somente um respondeu que utilizava alguma tipo de ferramenta, os outros informaram fazer verificações manuais, analisando o dockerfile e suas dependências, verificando autenticação, permissões e qualquer tipo de comunicação com o host.

Com base nessa pesquisa eu passei a focar o desenvolvimento deste material em ferramentas que podem ajudar no dia-a-dia para verificação de vulnerabilidades, em imagens, container e host. E com isso também encontrei ferramentas para fazer hacking de containers Docker. Para se proteger nada melhor que saber como pode ser atacado, então acompanhem até o final que vamos ter bastante dicas e ferramentas bacanas.

Mas para começarmos a utilizar as ferramentas primeiro precisamos estar ciente de algumas preocupações e práticas de segurança  ao usar Docker.

Preocupações com segurança ao usar Docker

Kernel exploits (exploração do kernel)

Ao contrário de uma VM, ao usar containers o kernel é compartilhado entre todos os containers e o host, aumentando a importância de qualquer vulnerabilidade que explore o kernel.

Denial-of-service attacks (ataque de negação de serviço)

Como todos os containers compartilham  recursos do kernel, se um container pode monopolizar o acesso a certos recursos, incluindo memória, ou até IDs de usuário (UIDs), pode faltar recursos para outros containers, resultando em uma negação de serviço (DoS).

Container breakouts (invasão de container)

Um invasor que tem acesso a um container não pode ter acesso a outros containers ou ao host. Se você usa root no container, você será root no host.

Poisoned images (imagens “envenenadas”)

Como você sabe que as imagens que você está usando são seguras, não foram adulteradas, e vêm de onde elas afirmam vir?

Application secrets (segredos de aplicações)

Quando um container acessa um banco de dados ou serviço, provavelmente exigirá credenciais, como um token ou mesmo usuário e senha. Se um invasor tiver acesso ao container terá acesso a estes dados.

Práticas de segurança

No tópico anterior foi levantada algumas preocupações de segurança que devemos ter ao usar containers, agora vamos ver algumas possíveis soluções para tentar resolver estes problemas.

Inicio este tópico com uma pergunta.

Como devemos armazenar dados sensíveis, como senhas, chaves privadas, tokens, chaves de APIs?

Para começar a responder esta pergunta, eu acho mais fácil e direto responder como não devemos armazenar dados sensíveis.

Não use variáveis de ambiente ou incorpore na imagem de container. É uma dica meio óbvio mas acontece e muito. Se quiserem ler sobre um caso, de utilização de credenciais incorporadas na imagem e que vazou,  tem um consideravelmente conhecido que aconteceu com a IBM: IBM Data Science Experience: Whole-Cluster Privilege Escalation Disclosure.

Mas como então devemos armazenar nossas credenciais de acesso quando usamos containers? Uma ótima solução é utilizar o Docker Secrets Management.

Docker Secrets Management

O Docker Secrets funciona como um cofre onde você pode colocar coisas sensíveis lá e só quem tem a chave do cofre consegue utilizar, no caso essa chave é designada aos nós dos serviços que a chave for atribuída. Mais de como funciona pode ser visto no blog Mundo Docker – Docker Secrets.

Outras dicas de segurança menciono abaixo em forma de tópicos:

Proteja seu host

  • Certifique-se de que seu host e a configuração do Docker engine sejam seguras
  • Mantenha seu SO atualizado
  • Impor controle  de acesso para evitar operações indesejadas, tanto no host como nos containers, usando ferramentas como SecComp, AppArmor ou SELinux

Redução dos privilégios

  • Tomar cuidado ao executar como root
  • Crie namespaces isolados
  • Limitar privilégios ao máximo
  • Verifique se o container é confiável (verifique a imagem)

Alto uso de recursos do container

  • Limite os recursos no kernel ou no container
  • Fazer testes de carga antes de pôr em produção
  • Implemente monitoramento e alertas

Autenticidade da imagem

  • De onde veio?
  • Você confia no criador?
  • Quais políticas de segurança está usando?
  • Identificação do autor
  • Não use se não confia na fonte
  • Use um servidor Docker Registry próprio
  • Verifique a assinatura da imagem

Vulnerabilidades de segurança presentes na imagem

  • Inspecionar as imagens
  • Atualize para pegar novos patches de segurança
  • Utilize uma ferramenta de scanner de vulnerabilidades
  • Integre esse scanner como etapa do seu CI/CD

Ferramentas de análise de segurança e hacking

Até aqui vimos algumas preocupações que devemos ter e algumas soluções relacionadas a segurança quando usamos containers, agora vamos ver algumas ferramentas que podem nos auxiliar e muito no nosso dia-a-dia.

Docker Security Scanning

Anteriormente conhecido por Projeto Nautilus, a solução fornece um perfil de segurança detalhado das imagens Docker com objetivo de tornar o ambiente em conformidade com as melhores práticas. A ferramenta faz uma varredura das imagens antes de serem utilizadas e monitoramento de vulnerabilidades. Esta ferramenta está disponível no Docker Hub, Store e Cloud.

No Docker Hub por exemplo está disponível para as imagens oficiais e pode ser visto o nível de vulnerabilidade destas imagens ao acessar as tags.

Ao clicar em uma das tags é possível identificar em qual camada está esta vulnerabilidade.

Abaixo algumas ferramentas separadas por projetos Open Source e Aplicações Web gratuitas ou pagas. São ferramentas que podem auxiliar no dia-a-dia na verificação de vulnerabilidades.

Ferramentas Web

  • Anchore – anchore.io – Descubra, analise e certifique as imagens e containers
  • Image Layers – imagelayers.io – Inspeciona as imagens dos containers e seus metadados
  • Micro Badger – microbadger.com – Inspeciona as imagens dos containers e seus metadados
  • Quay – quay.io – Constrói, analisa e distribui imagens de containers
  • Twistlock – twistlock.com – Segurança para containers Docker, Kubernetes e mais
  • Aqua – aquasec.com – Plataforma de segurança para containers

Ferramentas Open Source

  • Docker Bench for Security – https://dockerbench.com/ – O Docker Bench for Security é um script que verifica dezenas de melhores práticas comuns em torno da implantação de containers Docker na produção.
  • Open Scap – open-scap.org – Esta ferramenta faz revisão de imagens e containers para identificar vulnerabilidades.
  • Docke Scan – github.com/kost/dockscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades.
  • Docker Scan – github.com/cr0hn/dockerscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades e também possui funcionalidade para injetar vulnerabilidades.

Isso é tudo por enquanto, mas se você conhece outras dicas ou ferramentas que não são mencionadas aqui, deixe um comentário abaixo. Obrigado pela leitura e um grande abraço!

 

Docker e Tutum

Oi pessoal,

Post rápido apenas para divulgar uma grande novidade: A Docker acaba de anunciar oficialmente a compra da Tutum, um serviço em Cloud para desenvolvedores e administradores de sistema onde é possível criar seu ambiente Docker. Essa é uma noticia muito boa pois fecha uma fase do Docker e inicia outra mais interessante ainda.

Na prática o que muda nesse momento é apenas o fato de que a partir de agora a Tutum tem o apoio da Docker Inc. para novas iniciativas, os clientes não serão afetadas por essa “fusão” por assim dizer. A forma como a Tutum faz o deploy e provisionamento da infra estrutura continuará exatamente igual, isso não muda. Outro ponto é que a partir de agora iniciará uma integração melhor do Docker Hub com a Tutum, isso fará com que os usuários tenham uma melhor experiência na integração de suas aplicações com a infra estrutura Docker utilizando a Tutum.

Muito legal não? Quer saber mais, veja o post no Blog do Docker:

http://blog.docker.com/2015/10/docker-acquires-tutum/

Docker – Device mapper

Olá pessoal,

No primeiro post da série falamos sobre AUFS e hoje vamos falar um pouco sobre Device Mapper.

Origem

No começo o Docker era suportado apenas em distribuições Ubuntu, Debian e usavam AUFS para o seu armazenamento. Depois de algum tempo o Docker começou a se popularizar e as pessoas começaram a querer utilizar Docker com RedHat, porêm o AUFS era suportado apenas em sistemas (Debian,Ubuntu).

Então os engenheiros da Redhat baseados no código do AUFS decidiram desenvolver uma tecnologia própria de armazenamento baseado no já existente “Device mapper”. Então os engenheiros da RedHat colaboraram com o “Docker inc” para contribuir com um novo driver de armazenamento para containers. Então o Docker foi reprojetado para fazer a conexão automática com o dispositivo de armazenamento baseado em Device Mapper.

Layers

O Device Mapper armazena cada imagem e container em seu disco virtual, esses discos virtuais são dispositivos do tipo Copy-on-Write no nível de bloco e não a nível de arquivo. Isso significa que ao invés do Device Mapper copiar todo um arquivo para o seu dispositivo, ele vai copiando por blocos o que o torna muito rápido comparado ao AUFS. No processo de criação de uma imagem com o Device Mapper é criado um pool e em cima desse pool é criado um dispositivo base que é a partir dele que as imagens são construídas, a partir dai temos as imagens base do Docker que a cada modificação vão criando camadas de snapshots a cima da camada anterior. Conforme a imagem abaixo:

https://docs.docker.com/engine/userguide/storagedriver/images/two_dm_container.jpg

Read

Quando um container deseja ler algum arquivo que está nas camadas anteriores o Device Mapper cria um ponteiro na camada do container referenciando a camada da imagem onde possui esses dados colocando transferindo esse bloco para a memória do container.

Write

Quando o Docker faz uma alteração no arquivo utilizando Device Mapper esse arquivo é copiado apenas o que sera modificado cada bloco de modificação copiado é de no máximo 64KB. Por exemplo na escrita de um arquivo de 40KB de novos dados para o container o Device Mapper aloca um único bloco de 64KB para o container, caso a escrita seja de um arquivo maior que 64KB então o Device Mapper aloca mais blocos para realizar essa gravação.

O Device Mapper já é padrão nas em algumas distribuições do linux como:

  • RedHat/Centos/Fedora
  • Ubuntu 12.04 e 14.04
  • Debian

Docker e Device Mapper

O Device Mapper atribui novos blocos para um container por meio de uma operação chamada “Allocate-on-Demand”, isso significa que cada vez que uma aplicação for gravar em algum lugar novo dentro do container, um ou mais blocos vazios dependendo do tamanho de gravação terão que ser localizados a partir do pool mapeado para esse container. Como os blocos são de 64KB então muitas gravações pequenas podem sofrer com problemas de performance, pois acaba causando lentidões nas operações. Com isso aplicações que gravam arquivos pequenos sequencialmente podem ter performance piores com Device Mapper do que com AUFS.

Legal né? Se gostou nos ajude divulgando o blog.

Grande abraço!

 

Amazon EKS – Parte 1

Eai gente,

Bora falar de facilidades? Então, o objetivo deste post é trazer uma introdução ao uso da Amazon EKS (Elastic Kubernetes Service), vamos entender melhor o que é essa ferramenta e como você pode começar a “brincar” com ela de forma simples e rápida.

Ahhh mas antes, você sabe o que é Kubernetes? Caso ainda não esteja familiarizado recomendo que leias os posts que fizemos sobre o assunto Segue os links:

Kubernetes Parte 1

Kubernetes Parte 2

Kubernetes Parte 3

O que é o EKS

O Elastic Kubernetes Service nada mais é do que uma forma de você poder ter um cluster (ou mais) de Kubernetes sob demanda e sem a necessidade de administração dos managers (que para muitos é o mais complexo e oneroso dentro do Kubernetes), ou seja, a Amazon mais uma vez disponibiliza mais uma facilidade e tira um peso de quem precisa gerenciar o ambiente, é claro que isso gera outros pontos de atenção, como é o caso do vendor lockin, porém, se bem pensado, pode ser uma decisão que valha a pena.

Como Funciona

O objetivo da Amazon é disponibilizar para você uma infraestrutura completa, inclusive, no caso do EKS, tendo o gerenciamento dos manager sendo realizado pela própria Amazon. 

Fonte: https://aws.amazon.com/pt/eks/

Temos então basicamente três pontos principais nessa arquitetura:

     

Manager

Você não terá acesso a essa estrutura, toda a gerencia e configuração fica por conta da AWS mesmo, então, menos um ponto para se preocupar.

Workers:

São os nós do cluster onde você poderá executar todos os seus conteirners, ou seja, quando você instanciar um novo pod, ele será provisionado em um desses hosts.

Client:

Você precisa ter o binário do kubectl no host para poder geranciar o cluster, e ai que vem um ponto bem legal, você gerencia o cluster de forma transparente, da mesma forma como se fosse um Kubernetes on premise.

Mãos a obra?

A criação do master pode ser realizado utilizando a console da AWS mesmo, CloudFormation ou via CLI, o que veremos hoje será via CLI pois é o mais simples, para isso, você deve ter configurado em seu computador o awscli, para isso, siga os passos: https://docs.aws.amazon.com/pt_br/cli/latest/userguide/cli-chap-install.html, para resumir, se seu host for linux, siga a sequência:

Instale o Python 3:

apt-get/yum install python3

Baixe o pip para instalar o aws cli:

curl -O https://bootstrap.pypa.io/get-pip.py

Instale o pip:

python get-pip.py --user ou python3 get-pip.py --user

Adicione um novo caminho em seu path:

export PATH=~/.local/bin:$PATH
source ~/.bash_profile

Instale o AWS Cli:

pip3 install awscli --upgrade --user

Verifique a instalação:

aws version

Feito isso, você precisa configurar o cli para as credenciais da AWS, para isso, execute os passos:

aws configure

Informe os dados conforme for sendo lhe solicitado e pronto, basta seguir para o próximo passo.

Você precisará configurar o aws-iam-authenticator, para isso, siga:

curl -o aws-iam-authenticator 
https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.7/2019-03-27/bin/linux/amd64/aws-iam-authenticator
chmod +x ./aws-iam-authenticator
mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$HOME/bin:$PATH
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

Além desses binários, você precisará também ter configurado no host o eksctl, então siga os passos abaixo:

Baixe o eks:

curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

mv /tmp/eksctl /usr/local/bin/

Verifique se o eksctl está ok:

eksctl version

Certo, agora você precisará baixar o client do Kubernetes, o kubectl, você pode seguir os passos:

curl -o kubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl.sha256

chmod +x ./kubectl

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

Feito, basta verificar se está ok, execute:

kubectl version --short --client

E agora José?

Agora bora subir esse cluster ai que o pessoal ta louco pra ver funcionando :).

Pra isso, você pode executar o eksctl da seguinte forma:

eksctl create cluster 
--name prod
--version 1.13
--nodegroup-name workers
--node-type t3.medium
--nodes 3
--nodes-min 1
--nodes-max 4
--node-ami auto

Dessa forma o eksctl criará toda a escrutura necessária para o funcionando do cluster, desde VPC até regras de security group, esse novo cluster será formado com 3 instâncias t3.medium. O retono do comando será algo parecido com este:

[ℹ]  using region us-west-2
[ℹ]  setting availability zones to [us-west-2b us-west-2c us-west-2d] 
[ℹ]  subnets for us-west-2b - public:192.168.0.0/19 private:192.168.96.0/19 
[ℹ]  subnets for us-west-2c - public:192.168.32.0/19 private:192.168.128.0/19 
[ℹ]  subnets for us-west-2d - public:192.168.64.0/19 private:192.168.160.0/19 
[ℹ]  nodegroup "standard-workers" will use "ami-0923e4b35a30a5f53" [AmazonLinux2/1.12] 
[ℹ]  creating EKS cluster "prod" in "us-west-2" region 
[ℹ]  will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup 
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-west-2 --name=prod' 
[ℹ]  building cluster stack "eksctl-prod-cluster" 
[ℹ]  creating nodegroup stack "eksctl-prod-nodegroup-standard-workers" 
[✔]  all EKS cluster resource for "prod" had been created 
[✔]  saved kubeconfig as "/Users/ericn/.kube/config" 
[ℹ]  adding role "arn:aws:iam::111122223333:role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-IJP4S12W3020" to auth ConfigMap 
[ℹ]  nodegroup "standard-workers" has 0 node(s) 
[ℹ]  waiting for at least 1 node(s) to become ready in "standard-workers" 
[ℹ]  nodegroup "standard-workers" has 2 node(s) 
[ℹ]  node "ip-192-168-22-17.us-west-2.compute.internal" is not ready 
[ℹ]  node "ip-192-168-32-184.us-west-2.compute.internal" is ready 
[ℹ]  kubectl command should work with "/Users/ericn/.kube/config", try 'kubectl get nodes' 
[✔]  EKS cluster "prod" in "us-west-2" region is ready

Ahh mas eu quero personalizar… Não se preocupe amigo, o eksctl permite você definir qual VPC vai usar, quais subnet, security group, imagem (desde que homologada pela AWS), chave, dentre outras opções.

Depois de criado o cluster, bem, agora ficou fácil, basta você administrar da mesma forma como se fosse um cluster de Kubernetes instalado ai, nas suas máquinas locais ;).

Valide se tudo está ok com o cluster executando os comandos para verificar os nós do cluster:

kubectl get nodes

Você pode visualizar se foi criado o serviço default também, para isso:

kubectl get svc

O retorno será algo parecido com este:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m

Legal, e agora?

Bem, agora a sua imaginação é limite, encare o EKS como um cluster normal, neste sentido, o deploy de suas apps seguirá o mesmo processo, e caso você queria, pode utilizar outras facilidades da AWS para agilizar a publicação, mas isso é conto para outro post.

Queremos ainda, falar sobre monitoramento no EKS, Logs, e claro, vamos criar e fazer deploy de alguns serviço neste cluster, vamos ver como ficam as questões de segurança, ingress de serviço, dentre outros pontos.

Eai, curtiu? Então manda para alguém que talvez tenha interesse, e claro, fique a vontade para conversamos
Grande Abraço!

Kubernetes – Iniciando com services

Olá pessoal como foi mencionado nesse post /iniciando-com-pods/  há algumas semanas atrás, vamos dar continuidade a nossa série sobre Kubernetes, na primeira etapa mostramos como realizar a instalação, configuração e como poderíamos iniciar nossos primeiros Pods(containers) e hoje vamos demonstrar como podemos abstrair os nossos Pods e trabalhar diretamente com Services.

Pods é o menor objeto que pode ser criado no Kubernetes, eles são processos mortais  sendo executados em um cluster. Eles nascem e morrem porém não são ressuscitados.  Quem pode fazer o papel de ficar criando e destruindo os Pods dinamicamente é o Replication Controller que é um objeto do Kubernetes que faz com que sempre existam x Pods dentro de um Cluster.

Cada Pod ao ser criado recebe um endereço IP, porém ao ser destruído e recriado esse endereço IP é alterado. Então se temos um conjunto de Pods chamados de Backend que dependem de acesso de um outro conjuntos de Pods por exemplo Frontend como o conjunto de Frontend pode saber quais os componentes do Backend?

É nesse caso que usamos services, que é uma abstração que define um conjunto de Pods e sua politica de acesso, geralmente esse conjunto de Pods é identificado através de um Label Selector. Como exemplo de uso de um service podemos dizer que temos 3 Pods de MongoDB nos quais temos um Frontend que realiza o acesso, com a criação de um service o Frontend não vai precisar associar a aplicação aos Pods e sim ao service então os Pods podem ser recriados a qualquer instante que o Frontend continuará funcionando devido ao service realizar toda a parte de gerenciamento dos Pods abstraindo isso para o Frontend.

Agora vamos poder visualizar qual seria uma construção básica do meu service, nesse caso estamos usando como exemplo um conjunto de Pods que espoem a porta 8500 e que possuem como Selector “MeuApp” :

kind: Service
apiVersion: v1
metadata:
name: meu-service
spec:
selector:
app: MeuApp
ports:
- protocol: TCP
port: 80
targetPort: 8500

Com Kubernetes é possivel querer expor o serviço a um IP externo para acesso de alguma aplicação ou algum cliente, então para esse caso existe “ServiceTypes” onde é possivel especificar o tipo de serviço desejado, por padrão o criado é o ClusterIP que faz com que o serviço seja exposto com um IP do cluster, tornando o acessível apenas através do cluster. Existem outros 3 tipos de serviços:

– NodePort: Expõe o serviço em cada IP do Nó em uma porta estática (o NodePort). Um serviço ClusterIP, ao qual o serviço NodePort encaminhará, é automaticamente criado. Você poderá entrar em contato com o serviço NodePort, de fora do cluster, solicitando : .

– LoadBalancer: Expõe o serviço externamente usando o balanceador de carga de um provedor de nuvem. Os serviços NodePort e ClusterIP, aos quais o balanceador de carga externo encaminhará, são criados automaticamente.

– ExternalName: Mapeia o serviço para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro CNAME com seu valor. Nenhum proxy de qualquer tipo é criado. Isso requer a versão 1.7 ou superior do kube-dns.

Caso você escolha o Type NodePort o Kubernetes irá definir por padrão uma porta entre (30000-32767) para expor em cada nó de proxy do Kubernetes. Caso você deseje especificar um número de porta é possivel utilizar a propriedade nodeport para escolher uma porta fixa, porem deve se ter cuidado para não colocar mais serviços na mesma porta, o que acarretará em um erro na hora de subir o serviço.

Então hoje podemos entender um pouco mais de como funciona o componente “Service” dentro do Kubernetes e nos próximos capítulos vamos trabalhar mais a questão prática com o deploy de algumas aplicações.

 

Obrigado e uma ótima semana a todos

 

Criando um servidor web com docker

Olá!

Você está procurando uma forma de criar um ambiente web fácil e rápido? pois bem, hoje vamos mostrar como criar um ambiente web de maneira rápida e fácil. Nosso ambiente será constituído por 3 containers, sendo eles: Weave, HAProxy e Apache.

Com esse comando estamos criando o nosso container onde vamos colocar nosso apache

docker run -it --name apache centos /bin/bash

Agora já dentro do container vamos executar os seguintes comandos:


yum install wget -y
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm #Estamos utilizando a versão 7 do CentOS em nosso container.
rpm -ivh epel-release-7-5.noarch.rpm

yum install httpd -y
yum install php -y

/usr/sbin/httpd -DFOREGROUND -k start &

vi /var/www/html/index.html #Dentro do arquivo index.php vamos colocar o código abaixo:

<?php
 echo "Mundo Docker";
?>

Feito isso acima agora vamos pressionar CTRL + P + Q assim estamos saindo do container e voltando para o nosso Host. Vamos instalar agora o Weave para conseguir trabalhar com a parte de redes de uma maneira mais simples.


curl -L git.io/weave -o /usr/local/bin/weave
chmod a+x /usr/local/bin/weave

weave attach 192.168.0.2/24 apache #Estamos vinculando o ip 192.168.0.2/24 ao container apache através da rede Weave.

Agora vamos criar o container com o HAProxy.

docker run -it --name haproxy -p 80:80 centos /bin/bash

yum install wget -y
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm #Estamos utilizando a versão 7 do CentOS em nosso container.
rpm -ivh epel-release-7-5.noarch.rpm

yum install haproxy -y
echo "" > /etc/haproxy/haproxy.cfg
vi /etc/haproxy/haproxy.cfg 

Copiar e colar dentro desse arquivo



global
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon



defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000

frontend localnodes
    bind *:80
    mode http
    default_backend nodes

backend nodes
    mode http
    balance roundrobin
    option forwardfor
    server web01 192.168.0.2:80 check

Agora vamos iniciar o HAProxy



/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg &

Feito isso acima agora vamos pressionar CTRL + P + Q para sair do container e vamos anexar um IP para esse container.


weave attach 192.168.0.1/24 haproxy

 

Após isso é só acessar http://seuip e você estará visualizando a sua página.

 

Por hoje era isso pessoal, em nossos próximos posts vamos mostrar como criar um ambiente web com alta disponibilidade, replicação de arquivos e muito mais. Então fique ligado e nos ajude a divulgar o mundodocker.com.br obrigado!.

O que é uma imagem?

Olá pessoal,

Hoje vamos falar a sobre images, mas a final o que são images no Docker?

Images Docker são compostas por sistemas de arquivos de camadas que ficam uma sobre as outras. Ela é a nossa base para construção de uma aplicação, ela pode ser desde o base do CentOS como também um CentOS com Apache, PHP e MySQL.

Em uma Image temos o que chamamos de base que é um sistema de arquivos de inicialização bootfs, que é muito parecido com o sistema de boot do Linux / Unix. Nessa parte é onde temos toda a criação dos cgroups para fazer todo o controle e limitações de processos, namespace para blindar o container. O Docker nunca irá interagir com o sistema de arquivos de inicialização, pois quando o recipiente é iniciado ele é movido para a memória e o boot do sistema de arquivos é desmontado para liberar a memória RAM usada pela imagem de disco initrd. Isso parece muito com a pilha de virtualização típica do Linux. A próxima camada de uma imagem é a raiz na qual trabalha o rootfs, na parte superior do sistema de arquivos de inicialização, este rootfs pode ser um ou mais sistemas operacionais (Ex: Ubuntu, CentOS).

No momento do boot o sistema de arquivos raiz é montado somente leitura e depois de uma checagem de integridade é alterado para leitura e gravação. Isso no começo pode ser muito confuso, mas com a imagem abaixo vocês devem entender melhor como funciona.

docker-filesystems-busyboxrw

Como podemos ver na imagem, temos a parte dobootfs que é a parte do Kernel e a também a camada do rootfs que é a do Debian. Mais acima temos algumas adições de features na imagem que são add emacs e add apache. Todas essas camadas abaixo são somente leitura então nada será alterado nessas partes, a camada de escrita é apenas a que está acima dessas outras quatro camadas, é nessa camada que o usuário ou administrador do container irá interagir e poderá criar novas imagens, por exemplo adicionando um serviço php e dai criará uma nova imagem com mais uma camada somente leitura e assim vamos criando nossas imagens.

Por hoje é isso pessoal, em breve vamos estar mostrando como criar uma imagem, então fique ligado em nossos posts.

Docker e Jenkins para build de aplicações

Olá pessoal,

Hoje queremos demonstrar para vocês como podemos utilizar Docker e Jenkins para o build de aplicações de forma rápida e fácil, primeiro vamos entender como é o ambiente de diversas empresas de TI hoje e você que estiver lendo este post possivelmente estará se identificando com isso.

Hoje diversas empresas utilizam a ferramenta Jenkins para build e deploy de aplicações, muitas vezes (Se não forem todas) essa maquina de Jenkins é compartilhada entre diversos times, Java, PHP, Python, Rails e NodeJS acabam utilizando. O que deixa essa máquina com ferramentas desnecessárias para as equipes, sobrecarregando o sistema e qualquer problema acaba parando todas as equipes.

Porém existem alguns casos mais organizados que a maquina onde irá ocorrer o build será uma máquina para cada equipe, o que torna o processo um pouco melhor, porém sempre que sair uma nova versões de softwares alguém precisa ficar atualizando essa máquina, o que pode acabar por muitas vezes impactando em prazos do projeto.

Então existe o que acreditamos que seja a melhor solução que seria a utilização de containers para o build de suas aplicações. mas porque usar containers?

  • Só dependências para aquela aplicação
  • Fácil manutenção
  • Ambiente de produção e local iguais.
  • Escabilidade

Então visto o porque que devemos utilizar containers para realizar o build, vamos mostrar como podemos utilizar essas duas ferramentas em sincronia.

Primeiramente vamos até as configurações do nosso repositório e clicar em “WebHooks & Services:4

Vamos até “Add Service” e adicionar o “Jenkins (Github Plugin)”
5
Agora em nosso servidor com Docker instalado, vamos iniciar o container que terá o Jenkins Master instalado.

############# SERVIDOR1 #################
docker run -p 8080:8080 -p 50000:50000 -d jenkins

Iniciado, agora vamos até o nosso browser e digitar http://ipserver:8080 e vamos fazer a configuração base do Jenkins.

1

Para pegar a senha você irá executar

docker exec idcontainer cat /var/jenkins_home/secrets/initialAdminPassword

Na pŕoxima página você pode escolher a opção de usar os plugins recomendados, então depois irá pedir para você criar um usuário.

2

Feito isso agora estamos na página inicial do jenkins.

3

Esse será nosso servidor de Jenkins Master que sera o responsável por avisar e mandar rodar alguns comandos no nosso servidor onde estará o Docker. Para isso, vamos acessar o servidor 2 e realizar a instalação do Jenkins:

############# SERVIDOR2 #################
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins -y
sudo yum install java -y 
sudo service jenkins start/stop/restart
sudo chkconfig jenkins on
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
sudo yum install java-1.7.0-openjdk -y

Após realizar a instalação do servidor2, vamos até o nosso servidor de Jenkins Master e adicionar o outro nó nele, colocando o IP e a forma pela qual o agente fosse instalado: Para isso você deve ir até “Gerenciar Jenkins” >> “Gerenciar nós”

6

Após isso você irá clicar em novo nó, colocar o ip desse novo servidor e clicar na opção de “Permanent” e OK. Após isso irá aparecer algo parecido com a tela abaixo então, você tera que fazer download do slave.jar, ir até o outro servidor e executar o comando do java que é mostrado na imagem abaixo, porem com as suas configurações.

7

Feito isso, vamos até a tela da esquerda na opção de configurações e configurar parecido com a imagem abaixo: A parte mais importante dessa tela é a configuração do “rótulo” que é o apelido que vamos dar a esse servidor, e também o “uso” que estamos dizendo que vamos executar esse servidor apenas como jobs.

8

Agora vamos até a página inicial do nosso jenkins e então criar o nosso build. Vamos até “Novo Build”

9

Após selecionar “Novo Build” vamos até a opção de configuração:

10

Vamos colocar o nome do nosso servidor de slave na opção de “Restringe onde este projeto pode ser executado”

11

Abaixo vamos colocar o nosso caminho do “GitHub” e também de qual branch irá baixar o código.

12

Vamos marcar  a opção de “Build when a change is pushed to github” e também a opção de quanto em quanto tempo vamos ir consultar o nosso “SCM”.

14

Em nosso ultimo passo, vamos colocar os comandos que iremos executar em nosso servidor. Vamos criar uma imagem a partir do Dockerfile que está em nosso GitHub e após isso vamos iniciar o container com essa imagem.

15

Então por hoje era isso pessoal, espero que tenham gostado do post e gostaríamos que vocês interagissem através de comentários propondo novos posts e arquiteturas que vocês gostariam que a gente fizesse com Docker. Em breve teremos mais posts nesse estilo.

Obrigado!

Referências: https://docker.com/sites/default/files/RA_CI%20with%20Docker_08.25.2015.pdf

: https://jenkins.io/solutions/docker/

: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins

Coleta de Recursos

Olá pessoal,

Hoje vamos ver como mostrar os recursos sendo utilizado por cada container, como: Rede, Memória, Disco e CPU.

Vamos mostrar quatro maneiras de coletar os recursos. São elas:

– Docker stats

– API

– Cadvisor

– Cgroups

Docker stats: o comando docker stats foi adicionado nas ultimas versões do Docker, com ele agora podemos verificar as métricas de cada container em tempo real, porém não temos acesso ao histórico desses containers. Para usar este comando basta colocar docker stats id_container.

API: Em cada distribuição Linux o modo de habilitar a API é de uma maneira diferente. Vou mostrar aqui como fazer no CentOS 7. Abra o arquivo /etc/sysconfig/docker e altere a linha que tem OPTIONS= por OPTIONS=--selinux-enabled -H fd:// -H tcp://0.0.0.0:4243. Após isso reinicie o serviço do docker para que a porta da API seja aberta no host. Isso quer dizer que a porta 4243 deste servidor estará acessível de qualquer outro computador. Executando o seguinte comando podemos ver os containers que estão iniciados:

curl -X GET http://ipservidor:4243/containers/json

Esse comando retorna o JSON com as informações dos containers que estão iniciado.

Cadvisor: Fornece aos usuários a visualização de consumo por processo no host e também do container em tempo real. Com ele podemos verificar os recursos de Rede, Memória, CPU e informações do sistema. Para tudo isso basta executar o seguinte comando:
docker run
--volume=/:/rootfs:ro
--volume=/var/run:/var/run:rw
--volume=/sys:/sys:ro
--volume=/var/lib/docker/:/var/lib/docker:ro
--publish=8080:8080
--detach=true
--name=cadvisor
google/cadvisor:latest

Agora vá até o seu navegador coloque o seguinte endereço http://ip:8080

Cgroups: O Docker cria a limitação de seu containers através de CGROUPS (Acesse Aqui para saber mais sobre o que é CGROUPS) com ele podemos visualizar quanto de recursos aquele processo está usando. Dentro de /sys/fs/cgroup estão os recursos que podemos limitar no Docker. Podemos acessar o diretório memory/system.slice/docker-xxxxxxx.scope e dentro dele dar um cat memory.usage_in_bytes que nos mostra a quantidade de memória que o container xxxxxxx está usando. Dentro desse diretório temos outras contadores também que nos próximos posts apresentaremos.

Bom pessoal, por hoje foi isso então, em nossos próximos posts estaremos trabalhando outros tópicos avançados dentro do ambiente Docker, então fique atento, e tendo dúvidas já sabe, nos mande uma mensagem, abraço!

Docker Private Registry

Olá Pessoal!

Hoje o post será um pouco mais curto, isso por que queremos compartilhar com vocês alguns vídeos sobre as ferramentas que cercam o Docker, entre elas o Private Registry, que nada mais é do que um repositório privado de imagens.

Veja abaixo o vídeo que fala sobre isso, assine nosso canal no Youtube, ajude divulgando o mundodocker.com.br e fique por dentro das novidades!

 

Sysdig para Ops

Oi Pessoal,

Queremos mostrar para vocês hoje como é possível analisar seu ambiente Docker e ver a saúde de seus containers de forma fácil e bem prática, conheça nesse post o Sysdig. O Sysdig é uma ferramenta escrita em Lua que vem como uma opção, principalmente para quem é de operações, para realizar algum troubleshooting em seu sistema. Ele trás de forma rápida e fácil todas as informações que você precisa saber, não havendo mais a necessidade de executar dois, três comandos para ter uma noção do que está acontecendo, com o Sysdig em um único comando você já terá visibilidade do que é importante você saber e do que pode estar ocorrendo em seu sistema. O Sysdig também é multiplataforma, então é possível instalar ele tanto em Windows, quanto Linux e Mac, e claro, ele suporta containers, ótimo! Veja abaixo um mini tutorial que montamos para você:

1 – Instalação:

Simples, se for em um host Linux você pode utilizar o comando abaixo:

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash

Você ainda pode baixar os repositório e utilizar sua ferramenta para instalação (yum, apt-get e afins), que saber como? Da uma olhada aqui e veja também como instalar o Sysdi em Windows e Mac.

2 – Utilização:

Mas claro o que nos interessa é saber como mais como está o uso de recursos do meu host, e descobrir qual container está utilizando mais em relação aos outros, ou ainda ver como está a saúde do meu ambiente Docker, mas como o Sysdig faz isso? Ele fica ‘ouvindo’ as chamadas de sistema e com base nessas informações monta os reports para você, veja na imagem abaixo como ele trabalha tanto com Docker quanto com LXC puro:

Perceba que o Kernel envia para o Sysdig todas as informações que foram processadas por ele, seja de acesso a memória, disco, rede, processador, etc. e com base nisso o Sysdig consegue mapear qual processo está vinculado a qual arquivo, ou quanto de trafego está sendo gerado por um container.

Veja abaixo o exemplo de alguns comandos que pode lhe ser muito uteis (existe um lista bem grande disponível, vamos colocar aqui apenas os essenciais e extremamente úteis para fazer um troubleshooting em seu ambiente Docker):

  • Listagem dos containters existentes:
    sysdig -c lscontainers
  • Top por containers que mais utilizam CPU:
    sysdig -c topcontainers_cpu
  • Você ainda por visualizar quais processos estão consumindo mais recursos dentro de cada container, para isso:
    sysdig -pc -c topprocs_cpu

O retorno desse comando será algo parecido com este gif:

 

topproc_cpu

  • Você pode ainda filtrar a saída do comando pelo nome de seu container:
    sysdig -pc -c topprocs_cpu container.name contains wordpress
  • Quer ver quanto de rede um container está utilizando?
    sysdig -pc -c topcontainers_net
  • E qual processo dentro de cada container está utilizando mais rede?
    sysdig -pc -c topprocs_net
  • Quais portas estão trafegando mais?
    sysdig -pc -c topconns
  • Consigo filtrar por nome de container também?
    sysdig -pc -c topconns container name=wordpress
  • Eu consigo saber quais containers estão utilizando mais I/O em meu host?
    sysdig -c topcontainers_file
  • Consigo saber qual processo dentro do container está fazendo isso?
    sysdig -pc -c topprocs_file
  • E quais arquivos realmente estão sendo mais lidos ou escritos?
    sysdig -pc -c topfiles_bytes

 

Ufa, já é um começo certo? Existem muitas outras opções disponíveis, como por exemplo agregar logs de todos os containers em uma única visualização, com o Sysdig isso é simples de se fazer, quer ver mais? Acessa a Wiki dele, ela é rica em informações: http://sysdig.org/wiki

Por hoje era isso, fique por dentro das novidades aqui do Blog e se você ainda não viu, montamos um fórum aqui no blog, acessa o link ai em cima e poste a sua dúvida ou dificuldade, assim tanto nós quantos outras pessoas da comunidade Docker podem te ajudar e claro nos ajude divulgando o MundoDocker, Abraço!

Docker Global Mentor Week

Olá Pessoal!

Para quem não viu ainda, na quinzena final de novembro será realizado uma das maiores ações do Docker para treinamento e troca de experiência entre seus usuários, esse evento foi chamado de Docker Global Mentor Week.

Essa é uma ação coordenada diretamente pela equipe do Docker com a ajuda dos organizadores dos grupos de meetup docker pelo mundo, o objetivo é simples: Dar treinamento técnico de alto nível de maneira abrangente e uniforme, ou seja, o conteúdo abordado em Singapura, é o mesmo no México, na Inglaterra e claro aqui no Brasil :). SIM teremos esse evento ocorrendo aqui no Brasil também, vou deixar abaixo os links desses eventos para que você possa se inscrever.

Mas afinal, esse é apenas mais um encontro do grupo de Meetup? Sim e Não, sim porque os canais utilizados para divulgação desse evento são os grupos de meetup e não porque esse evento tem conteúdo definido pela equipe do Docker e é repassado através de seus Mentors, que são pessoas ativas na comunidade docker e que auxiliam na divulgação de conteúdo, disseminação da tecnologia e enriquecimento da comunidade local. Você encontrará em cada evento no mínimo 1 Mentor, então não deixe de tirar suas dúvidas com ele(s).

Ok Cristiano, gostei, mas e valor? Bom, isso é um problema, por ser um evento oficial realizado no mundo inteiro, o valor para realizar esse treinamento é……. ZERO, sim é evento totalmente de graça, e agora, qual a sua desculpa?

E o conteúdo?

A equipe do Docker definiu uma série de trilhas que podem ser abordadas durante o evento, é claro que todas é impossível de serem realizadas num período de 3 a 4 horas, então cada usuário defini o que deverá ver no evento, e os mentor auxiliaram na execução do treinamento e esclarecimento de dúvidas. Os conteúdos em si vão do básico (criação de containers, Dockerfile, etc) até o avançado (orquestração, serviços, rede, volume, etc).

Onde serão realizados aqui no Brasil?

Temos por enquanto, 4 eventos confirmados aqui no Brasil, são eles:

Docker Global Mentor Week – Goiania – 14/11

http://meetup.com/pt-BR/Docker-Goiania/events/234750966/?eventId=234750966

 

Docker Global Mentor Week – Rio de Janeiro  – 16/11

http://meetup.com/pt-BR/Docker-Rio-de-Janeiro/events/234784863/?eventId=234784863&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – São Paulo – 19/11

https://meetup.com/pt-BR/Docker-Sao-Paulo/events/235267786/?eventId=235267786&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – Porto Alegre – 26/11

http://meetup.com/pt-BR/Docker-Porto-Alegre/events/235451287/?eventId=235451287&chapter_analytics_code=UA-48368587-1

 

O MundoDocker estará presente? Claro! Vamos auxiliar o pessoal do grupo de Porto Alegre!

 

Era isso por hoje pessoal, ajude você também divulgando os eventos e claro o blog

 

Grande abraço!

Publicando imagens no Docker Hub

Fala pessoal,

Hoje vamos falar de como é possível a gente realizar a publicação de uma imagem para o Docker Hub, mas a final o que é o Docker Hub?

Introdução

Docker Hub é um repositório de imagens fornecidos pela Docker de maneira pública e privada onde existem milhões de imagens disponibilizadas para o publico realizar o download. Por padrão quando o Docker é instalado ele vai realizar o download de todas as suas images a partir desse repositório público.

Na imagem acima é possível ver na interface do Docker Hub que existem atualmente 2.829.269 imagens disponíveis, provavelmente quando você ler esse post o número já sera maior. Pela interface é possível filtrar por imagens de categorias como: Databases, Security, Storage e por ai vai. Além disso algumas imagens possuem o selo de Official Image que são as imagens oficiais de algumas tecnologias, na imagem é possível verificar as imagens oficiais de: Couchbase, Ubuntu, Redis e Node.

No Docker Hub você também pode visualizar os plugins disponíveis para integrar a sua instalação de Docker para deixa-lá mais robusta e completa, desde a: Logging, Security, Network e Storage.

Criando uma imagem

Agora que já fomos apresentando ao Docker Hub vamos criar uma imagem customizada e vamos publicar ela, para você que quer entender o que é uma imagem, da uma lida nesses links:

O que é uma imagem?
O que é Dockerfile?

Agora que você já sabe o que é uma imagem e que o melhor jeito de gerar ela é a partir de um Dockerfile, vamos criar nossa imagem para publicá-la no Docker Hub. Para isso vamos criar um arquivo chamado: Dockerfile

FROM ubuntu:latest
RUN apt-get update -y
RUN apt-get install -y python-pip python-dev build-essential
COPY requirements.txt /app/
WORKDIR /app
RUN pip install -r requirements.txt
RUN rm -f /app/requirements.txt
COPY . /app
ENTRYPOINT ["python"]
CMD ["app.py"]

Criado o nosso Dockerfile a gente precisa ir até o diretório onde está o arquivo e executar:

docker build . -t mundodocker/demo-flask:1.0.0

Com isso o Docker irá interpretar o arquivo e começar a executar os comandos que nele estão, gerando assim a nossa imagem. Após finalizar o processo você pode verificar que a imagem já está criada de maneira local, para isso basta executar:

docker image ls

Para conseguir pegar esse exemplo completo você pode acessar este repositório que estamos disponibilizando e realizar o clone do projeto:
https://github.com/mundodocker/demo-flask

Agora falta a gente realizar a publicação dela para o Docker Hub, para isso precisamos fazer o login e depois fazer o push dela, então os comandos são:

docker login
docker push  mundodocker/demo-flask:1.0.0

O mundodocker antes do / é o nome do seu repositório criado dentro do Docker Hub, nesse caso é o mundodocker.

Após a execução dos comandos, você pode ir até a sua página do Docker Hub e irá visualizar a imagem dentro do seu repositório, agora é só passar o nome da imagem para todo mundo e pronto sua imagem está pronta para uso.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

Docker 1.12

Oi Pessoal,
Já vimos aqui no blog algumas ferramentas e soluções, como por exemplo: Docker Compose, Docker Swarm, SwarmkitDocker Network, dentre outros. Bom, o que você sabe sobre elas é essencial para entender a nova versão do Docker, que será lançada em agosto e que está em RC4 atualmente.

A grande novidade no Docker 1.12 é ter a orquestração nativa, sem a necessidade de ter duas ou mais ferramentas para criar seu cluster de Docker, basta apenas que você tenha a engine instalada e a partir dela poderá montar seu ambiente. Outra grande novidade é o conceito de serviço, esse conceito nós já tratamos em Swarmkit, e é algo que foi incorporado ao Docker para facilitar o deploy e escalonamento das aplicações. Vamos ver o que muda?

Orquestração:

Agora para você criar um cluster de Docker, basta rodar:

docker swarm init

Com isso você iniciará o primeiro nó do cluster, para adicionar mais nós ao cluster execute o seguinte comando em outro nó:

docker swarm join IP-DO-MANAGER:2377

Veja na imagem abaixo a sequência de comandos:

docker_swarm

Serviços:

No Docker 1.12 foi introduzido o conceito de serviço, que já existe no Kubernetes, e que agora possibilita a criação, atualização e escalonamento da sua camada de serviço (seja ela de frondend ou backend) de forma muito mais fácil. Por exemplo:

docker service create --replicas 1 --name servico1 alpine echo "Ola Mundo"

Dessa forma você estará criando um serviço com um container de Alpine, você pode aumentar a quantidade de containers que irão atender este serviço, para isso execute:
docker_service

Além de poder criar e escalonar, você pode ainda realizar a atualização de seu ambiente, basta utilizar o comando update, e pode ainda definir uma politica de atualização (por exemplo, executar a atualização em um container por vez, com isso ele removerá um container e iniciará um novo baseado na nova imagem). Você pode ainda, definir um bloco de rede para cada serviço, com isso você isola totalmente os ambientes, veja:

docker service create --replicas 3 --name webservers --network web --publish 80:80/tcp nginx

Dessa forma, serão criados 3 containers (caso você tenha colocar 2 ou mais hosts no cluster de Swarm, será criado um container por host). O mais interessante nesse ambiente é que, se você acessar a porta 80 de qualquer host que esteja no cluster Swarm, seu acesso será redirecionado ao serviço, independente se o container esteja nele ou não, isso por que o Docker garante que o serviço esteja acessível mesmo que um nó venha a falhar. E como o Docker faz isso? Simples, através da 3 feature adicionada nessa versão:

Roteamento:

Quando você criar um cluster via Docker Swarm, o Docker se encarregará de atribuir ao serviço um identificador único dentro do cluster, com isso, quando for solicitado acesso á porta exposta na criação do serviço, o acesso será roteado para o container que é responsável por aquele serviço (ou mais de um é claro), ele faz isso através do algoritmo de routing mesh que está presente na engine, ele identifica quem possuí o container que atende o serviço e redireciona o trafego para ele, por isso é importante que, quando você criar um novo serviço define uma rede também, pois reduzirá o tempo de processamento que a engine precisará para identificar onde encontra-se o container.

Segurança:

Por último e não menos importante, vem a questão de segurança. No Docker 1.12, toda a comunicação do cluster é realizada via tls, e quem garante o rotacionamento desses certificados (renovação e deploy) assim como a criação de certificados para novos nós é o nó manager, que é eleito baseado em uma série de parâmetros (disponibilidade e saúde), mas que de maneira geral é o primeiro nó onde você iniciou o cluster. Os certificados são rotacionados de tempos em tempos, e você pode modificar essa politica também.

Há mais coisas? Claro! Foi adicionado também um sub comando do comando docker plugin que permite você plugar de forma mais fácil os plugins do Docker, quando você realizar um docker plugin install nome_do_plugin, lhe será informado ao que exatamente aquele plugin terá acesso, e poderá assim permitir ou não sua instalação.

Bacana né? Se gostou nos ajude divulgando o blog e caso tenha dúvida nos avise

Grande Abraço!

Docker – API Autenticada

Oi Pessoal,

Uma das grandes vantagens em se utilizar o Docker em vez de LXC puro é a facilidade de se trabalhar utilizando uma API de integração, isso facilita e agiliza a vida tanto de programadores quanto do pessoal de operações. Alguns cuidados devem ser tomados é claro, entre eles em não expor a API de seu host Docker, pois nativamente não há um método de limitar o acesso. Existem soluções para isso? É claro, e hoje o mundodocker.com.br abordará um delas: Docker API com Basic Authentication.

Passo 1:

Primeiramente você deve expor a API do Docker apenas localhost, para isso você deverá editar o arquivo de configuração, no nosso exemplo (CentOS 7) é no /etc/sysconfig/docker, e deixe-o assim:

OPTIONS='-H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock'

Em seguida reinicie o serviço do Docker:

systemctl restart docker.service

Passo 2:

Agora precisamos instalar e configurar um proxy http (Nginx, Apache, etc), no nosso exemplo vamos utilizar o Nginx, para isso:

yum install nginx -y

Agora precisamos definir as credenciais de acesso, é simples, basta criar .htpasswd e fazer com que o proxy exija usuário e senha em uma determinada url, vamos lá:

htpasswd -c /etc/nginx/.htpasswd USUARIO

Ele solicitará a senha, digite-a duas vezes e está pronto seu arquivo de autenticação.

Agora vamos a configuração do proxy, para isso precisamos editar o arquivo: /etc/nginx/conf.d/default.conf e deixe-o da seguinte forma:

server {
 listen 2375 default_server;
 server_name localhost;
 location / {
 proxy_pass http://127.0.0.1:2376;
 auth_basic_user_file /etc/nginx/.htpasswd;
 auth_basic "Acesso restrito a API do Docker";
 }
}

O que falta? reiniciar o serviço do Nginx:

systemctl restart nginx.service

Testes

Depois de tudo configurado (se fosse não encontrar nenhum erro no caminho também ) basta você testar de uma forma bem simples: http://ipdoservidor:2375/info ele solicitará os dados informados anteriormente via htpasswd e retornará algumas informações do Docker e dos containers que está em execução neste host.

Você pode optar por outro método, que é o certificado SSL diretamente na API do Docker, isso garante que apenas clientes confiáveis tenham acesso ao host (pois deverão tem o certificado client configurado). E claro, você pode configurar para que o Nginx trabalhe sob SSL, isso garante que, além da autenticação com usuário e senha, você ainda tenha todos os seus dados trafegados de forma criptografada (esse sim é um ótimo método).

Por hoje era isso gente, gostaram? Ajudem divulgando o Blog por ai

Abraços!

Docker e Weave

Olá pessoal,

Hoje vou demonstrar através de um vídeo, como podemos utilizar uma aplicação do ecossistema Docker para que se possa trabalhar de uma maneira mais fácil com a parte de rede, Essa ferramenta se chama Weave e você pode fazer download dela a partir do endereço: https://github.com/weaveworks/weave.

 

Ficou dúvida? Curiosidade? Deixe sua dúvida e vamos conversando, divulgue o mundodocker.com.br e nos ajude disseminando conhecimento!

Persistindo dados – Flocker

Olá,

Hoje, no terceiro post da série: Persistindo dados, vamos abordar mais uma forma de como você pode persistir os dados de sua aplicação, garantindo maior disponibilidade para seu ambiente, hoje o assunto é sobre o Flocker.

 A proposta do Flocker é muito parecida com demais soluções para sistema de arquivos distribuídos, a grande diferença esta no foco que a ClusterHQ (desenvolvedora da solução) está dando para o projeto, pois o objetivo tem sido tornar o Flocker cada vez mais especializado em Docker, ou seja, o objetivo do Flocker não é atender a qualquer tipo de problema, mas sim, atender muito bem uma das deficiências que há no Docker , que é a persistência de dados, tanto que o Flocker em si já é um plugin de volumes oficial do Docker. Veja abaixo uma imagem que ilustra muito bem o que o Flocker se propõem a atender:

Fonte: https://clusterhq.com/flocker/introduction/

Atualmente, quando você instância um container em outro host, você precisa cuidar se o volume de onde está sua aplicação também tem mapeamento nesse novo host, o objetivo do Flocker abstrair esse tipo de preocupação, e garantir que, quando um container for movido de um lado para o outro, os dados que estavam mapeados nele também acompanhem esse movimento.

Veja abaixo como é a arquitetura dessa plugin:

Fonte: https://clusterhq.com/flocker/introduction/

Note que, diferentemente do GlusterFS, você precisa ter um ambiente mais complexo, envolvendo basicamente 3 camadas: Flocker Plugin, que é responsável pela comunicação entre o Docker e o Flocker; Flocker Conrol, responsável pelo monitoramento dos volumes, e controle sob o funcionamento do ambiente; Flocker Agent, responsável por executar as ações de criação, remoção e demais ações do Flocker no host que faz parte do ambiente.

Novamente, e o Docker?

Como já falamos em posts anteriores, a intenção não é mostrar a vocês como realizar a instalação e configuração do cluster de Flocker, e sim, seu uso final, juntamente com o Docker, talvez daqui a pouco possamos montar um material com isso ;).

Mãos a massa:

Primeiro vamos criar o volume Docker utilizando o plugin do Flocker, para isso:

$ docker volume create --name volume-1 -d flocker

Agora basta mapear esse volume criado aos containers que desejar:

$ docker run -v volume-1:/data -it centos /bin/bash

Basta criar algum arquivo ou pasta no diretório /data do container e essa informação será salva no volume Flocker que você criou, para ter certeza de que o dado estará nesse volume, crie outro container mapeando esse volume, e você verá que no /data desse novo container estará o arquivo/pasta que você criou no primeiro.

Fácil né? O mais interessante no Flocker é que você não perde os dados caso dê algum problema no host, o volume será criado no cluster Flocker que você montou, e isso é o que garante a disponibilidade da informação.

Por hoje era isso, espero que tenham gostado e tendo dúvidas nos avisem, e claro ajudem divulgando o Blog

Abraço!

Docker ToolBox

Oi Pessoal,

Você, sim você mesmo, que não tem grandes conhecimentos em Linux mas quer aprender Docker, criar seus containers e montar suas imagens, pois bem, esse post é pra você ;). Queremos mostrar como instalar e utilizar a ferramenta Docker ToolBox, que é um ótimo utilitário para subir seu ambiente Docker dentro de seu Windows ou Mac de forma fácil e rápida, montamos esse vídeo para lhe auxiliar, veja:

Basta você acessar: https://docker.com/docker-toolbox, fazer download da ferramenta e instalar como está ilustrado no vídeo. Ficou com dúvida ou dificuldade? Sem problema, deixa seu comentário ou ainda posta lá no nosso fórum: /forum que vamos lhe ajudando.

Esperamos ter ajudado e nos ajude divulgando o Blog.

Container no Windows Server 2016 TP3

Olá pessoal !

Como já publicado aqui no mundo docker Docker no Windows Server Server 2016, hoje vou explicar como funciona a criação e administração de um container no Windows server 2016 TP3. Mas antes quero deixar dois links para vocês onde há uma explanação mais aprofundada de como o Windows manipula containers, é basicamente uma leitura obrigatória ehehe:

https://msdn.microsoft.com/virtualization/windowscontainers/about/about_overview
http://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Requerimentos:
Windows Server 2016 TP3
10GB disponível para imagem sistema operacional de scripts
Permissão de admin na máquina.

Sem mais demora, vamos ao vídeo onde estarei ensinando vocês a criarem containers e acessá-los remotamente:


Gostou do vídeo ou do post? Divulga nosso Blog, ajude-nos a disseminar cada vez mais o conhecimento sobre Docker.

Docker Compose V3

Olá pessoal, tudo bem?

 

Conforme falamos em um post anterior o Docker lançou uma nova versão a 1.13 e nessa nova versão tivemos diversas melhorias e com a entrada dessa nossa versão também tivemos a criação de uma nova versão no Docker Compose que é a v3. Essa nova versão é totalmente compatível com o Docker Swarm que hoje é nativo na mesma engine no Docker, então agora com Docker Compose podemos gerenciar nossos serviços através do Docker Swarm.

Agora com a V3 existe opção chamada deploy que é responsável por realizar as implantações e execução de serviços. Dentro dessa opção temos as seguintes funções:

  • Mode
    • Onde é possível escolher a opção “Global” (Um container por nó de swarm) ou “Replicated” (Onde posso escolher a quantidade de réplicas que estarão distribuídas entre os nós). O padrão é replicated.
    • Replicas
      • replicas: x
    • Global
  • Placement
    • Especifica restrições de posicionamento são elas:
      • node.id = idworker
      • node.hostname = nomeworker
      • node.role = manager ou worker
      • node.lables = nome
      • engine.labels = Sistema Operacional ou Driver
  • Update_config
    • Configura como devem ser as opções de atualizações dos serviços.
    • Parallelism: 5 #O Numero de containers que vão ser atualizados em paralelo.
    • delay: 10s #O tempo entre cada grupo de containers será atualizado
    • failure_action: pause ou continue #O que irá acontecer se a atualização falhar. O padrão é pause.
    • monitor: 0s # Duração após cada atualização para monitorar a falha. O padrão é 0s.
    • max_failure_ratio: #Taxa de falha para atualizar.
  • resources
    • Configura a restrição de recursos
      • limits:
        • cpus: ‘0.5’ # 0.5 representa 50% de um núcleo, porem pode ser 1 ou 1.5 ou 2….
        • memory: ‘512M’ #apenas especificar o prefixo M, G, K….
  • Restart_policy
    • Configura como reiniciar os containers quando eles derem exit.
      • condity: none on-failure any #Por padrão é any
      • delay: 0s #Tempo entre as tentativas de reiniciar o containers #Por padrão é 0s
      • max_attempts: 0 #Quantas vezes irá tentar subir o container antes de desistir #Por padrão é nunca desistir.
      • window: 0s #Quanto tempo demora para decidir se um reinicio foi bem sucedido  #Por padrão é imediatamente,

 

Alem dessas opções, com a entrada da V3 foram descontinuadas as seguintes opções do Docker Compose: volume_driver, volumes_from, cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit

Agora vamos demonstrar um exemplo de como ficaria o docker-compose.yml com essas opções que mostramos acima.

version: "3"
services:

  redis:
    image: redis
    ports:
      - "6379"
    deploy:
      placement:
        constraints: [node.role == manager]
  nginx:
    image: nginx
    ports:
      - 80:80
    depends_on:
      - redis
    deploy:
      mode: replicated
      replicas: 2
      placement:
        constraints: [node.role == manager]
      resources:
        limits:
          memory: 512M
      restart_policy:
        condition: on-failure
        delay: 10s

Executando o comando docker deploy --compose-file docker-compose.yml nomedastack criamos a stack mencionada acima em nossa estrutura. Após executar esse comando é possível dar um docker stack ls e você poderá ver que a sua stack foi criada, com o nome da sua stack você pode executar o docker stack services nomedastack e poderá ver os serviços criados e qual o seu status.

Então ta pessoal, por hoje era isso, espero que tenham gostado e qualquer dúvida é só deixar um comentário que estaremos felizes em lhe ajudar, nos ajude divulgando o blog obrigado!