Category: Novidades

Docker Global Mentor Week – Até aqui

Oi Pessoal,

Gostaríamos de trazer hoje um apanhado geral do que foi o Docker Mentor Week esse ano. Quais as percepções dos participantes, conteúdo abordado, dentre muitas outras informações sobre esse grande evento sobre Docker.

Quem participou das edições no Rio de Janeiro, São Paulo, Goiânia e Gravataí, pôde ter a experiência de como é realizar um treinamento tão focado e ao mesmo tempo descontraído, podendo interagir com outros usuários de Docker que tiveram ou tem as mesmas dificuldades, dúvidas e soluções. Esse tipo de experiência reforça cada vez mais a ideia de comunidade aberta, onde todos são bem vindos e todos tem seu papel, sendo você um iniciante ou ainda alguém com uma bagagem maior de conhecimento nessa tecnologia.

Segundo Fernando Ike, um dos organizadores e mentors do evento em São Paulo, é possível descrever o evento como:
“Muito gratificante compartilhar um pouco da experiência com os outros e também aprender alguns truques novos sobre containers.”

Em todos os eventos notamos que o público era o mais variado possível, desde quem nunca tinha trabalhado com Docker, Devs, Ops, etc. E o mais interessante, e que ocorreu em quase todas as edições foi o caso do pessoal de desenvolvimento realizar trilhas de ops e vise-versa, o que acaba gerando ainda mais engajamento por ambas as partes.

Será que todo o mundo pensa da mesma forma?

Nós do MundoDocker não poderíamos ficar sem essa resposta, não é mesmo? ;). Para isso contamos com a ajuda do pessoal do Imasters, que estiveram presentes no evento que ocorreu em São Francisco, na Califórnia mesmo (Durante o DevTrip). O Matheus Moreira e o Romulo Scampini que participaram do DevTrip e foram até o evento na sede do Docker, resumiram a participação deles no evento como:

Romulo:
“Foi o meetup mais produtivo que já fui, pois normalmente em meetups só temos a apresentação de algum conteúdo, e levamos de lição de casa a prática do conhecimento obtido.
No Global Mentor Week, além de aprender pudemos colocar em prática todo o conhecimento obtido, e ainda tivemos o apoio de engenheiros especialistas.”

Matheus:
“Foi bem legal porque tinha um monte de mentores a nossa disposição pra tirar todas as duvidas que quissemos e ai adivinha os mentores eram os devs do core do Docker”.
#sortudos

Separamos algumas fotos dos eventos, em São Francisco.

Em São Paulo:

Fonte: https://meetup.com/Docker-Sao-Paulo/events/235267786/

Em Goiânia:

Estivemos presente no evento que ocorreu na sede da Umbler em Gravataí no último sábado (26/11), e claro que registramos tudo :). Foi uma experiência incrível participar como Mentors desse evento, nem tudo foi perfeito, mas a troca de conhecimento e networking foram demais, foi muito gratificante poder ajudar a comunidade e dar nossa contribuição para o esclarecimento de dúvidas e passagem de conhecimento. Vamos ver umas fotos?

Quer contribuir também? Então fique ligado nos meetup de Docker de sua cidade, não sabe onde tem? Comenta ai e vamos achar um o mais próximo de você.

Acabamos por aqui, e como sempre, nos ajude divulgando o blog

Grande abraço a todos!

AKS – Azure Kubernetes Service – Parte 2.

Continuando nossa série de posts sobre o AKS, hoje vamos entender como o AKS cria os recursos no Azure. Se você não viu o post anterior mostrando como podemos criar um cluster de maneira rápida e fácil dentro do Azure, segue o link abaixo:

AKS – Parte 1

Quando você executa a criação de um cluster de Kubernetes no Azure, automaticamente a Microsoft cria diversos componentes, hoje vamos entender que componentes são esses criados pelo Azure e como eles se relacionam com o cluster de Kubernetes.

Estrutura

Na criação de um cluster simples igual foi criado no post anterior a Microsoft irá automaticamente no Azure criar recursos dos tipos: Load Balancer, Resource Group, Node Pools.

Na imagem acima é possível ver que em Resource Groups existem dois recursos, o resource_aks foi criado anteriormente, porem o MC_resource_aks_aksmundodocker_eastus é criado automaticamente pelo Azure e nesse momento não podemos renomear esse resource, então ele vai adicionar o prefixo: MC_{NOME DO RESOURCE GROUP}_{NOME DO CLUSTER}_{REGIÃO}. Dentro desse Resource Group é onde ficam os objetos criados especificamente para o cluster. Dentro do resource_aks você irá visualizar apenas um recurso do tipo Kubernetes Service, como na imagem abaixo:

Ao clicar em MC_resource_aks_aksmundodocker_eastus você poderá ver os recursos criados, se você copiou e colocou o exemplo de criação do post anterior, você deve ver algo parecido com isto:

É possível ver os tipos de recursos: Public IP address, Network security group, Route table, Virtual machine scale set, Virtual network e Load balancer. Por padrão são esses os tipos de recursos criados para um cluster de AKS.

Public IP address

Quando se cria um cluster de AKS padrão o endereço IP padrão para o Load Balancer é um IP público, então automaticamente o Azure cria um recursos do tipo Public IP address dentro do Resource group.

Network security group

O Networ security group (NSG) é um componente do Azure no qual é possível criar as regras para tráfego nas interfaces de rede, definindo assim se habilita o tráfego para determinado endereço ou recurso ou se habilita o mesmo.

Route table

O Route table como o nome já sugere é um recurso do Azure para definir a tabela de roteamento de alguns componentes.

Virtual machine scale set

Para conseguir realizar o dimensionamento de máquinas de maneira automática o Azure cria para o cluster de AKS um recurso do tipo Virtual machine scale set que faz com que o grupo de máquinas pode aumentar ou diminuir conforme a demanda de uso ou o agendamento criado.

Virtual network

Todo o cluster de AKS precisa ser criado dentro de uma Virtual network (VNET) ela pode ser criada automaticamente no momento de criação do cluster (Igual a gente fez) ou pode ser criada anteriormente e depois informada no momento da criação do cluster.

Load balancer

Dentro do Kubernetes existem 3 tipos de services: NodePort, ClusterIP e Load balancer. Quando o tipo de service Load balancer é criado o Azure atribui 1 IP da sua subnet para esse service e configura no recurso Load balancer um encaminhamento para esse service. Nos próximos posts a gente vai entender melhor e ver como essas regras são criadas.

Não sabe o que é service? da uma olhada em o que é service?

OBS* Os recursos criados pelo AKS de maneira automática não devem ser modificados ou excluídos por outras contas a não ser pela própria Azure, pois qualquer modificação pode fazer com que o recurso pare de funcionar e a Azure não de suporte a eles.

Os recursos acima são os criados de maneira default em um cluster simples no AKS. Agora que você aprendeu como funciona a estrutura do AKS e quais são os componentes básicos do cluster nos próximos posts você vai aprender como é possível realizar o deploy das aplicações, fazer integrações, monitoramento e obter o melhor desempenho para as suas aplicações em produção.

O que é dockerfile?

Olá!

Como mencionado neste post, o Docker possui alguns recursos que permitiram sua popularização pelo mundo a fora, além da API de integração, o Docker permite que possamos criar imagens a partir de um arquivo de definição, esse arquivo chama-se Dockerfile.

Vamos lá. Como explicado anteriormente em alguns posts, uma imagem nada mais é do que um ambiente totalmente encapsulado e pronto para ser replicado onde desejar. Podemos montar esse ambiente através de um container que esteja em execução (Exportando o mesmo), ou através da criação a partir do Dockerfile, que nada mais é do que um arquivo de definição onde é possível realizar ou preparar todo ambiente a partir de um script de execução. Em resumo, o Dockerfile é um arquivo texto com instruções, comandos e passos que você executaria manualmente, basicamente o Docker executa uma receita de bolo.

Através do comando docker build, o Docker realizar a execução desses passos e no final da execução ele encapsula cada layer gerada para dentro da imagem. Mas o Dockerfile deve seguir uma ordem ou formatação correta para que o build seja feito de forma certa, por exemplo, o formato do texto deve respeitar: INSTRUÇÃO argumento, onde INSTRUÇÃO é o comando que o build deve executar, e argumento são as instruções que deve fato serão feitas, por exemplo:

RUN yum update

Onde:

RUN: É a instrução;

yum update: Argumento que será executado.

Abaixo podemos visualizar todas as opções de instruções disponíveis:

  • FROM: Informa a partir de qual imagem será gerada a nova imagem, lembrando que em poucos casos (Veremos em posts futuros), uma imagem será gerada se um imagem base;
  • MAINTAINER: Campo opcional, que informa o nome do mantenedor da nova imagem;
  • RUN: Especifica que o argumento seguinte será executado, ou seja, realiza a execução de um comando;
  • CMD: Define um comando a ser executado quando um container baseado nessa imagem for iniciado, esse parâmetro pode ser sobrescrito caso o container seja iniciado utilizando alguma informação de comando, como: docker run -d imagem comando, neste caso o CMD da imagem será sobrescrito pelo comando informado;
  • LABEL: Adiciona metadados a uma imagem, informações adicionais que servirão para identificar versão, tipo de licença, ou host, lembrando que a cada nova instrução LABEL é criada uma nova layer, o Docker recomenda que você não use muitas LABEL. É possível realizar filtragens posteriormente utilizando essas LABEL.
  • EXPOSE: Expõem uma ou mais portas, isso quer dizer que o container quando iniciado poderá ser acessível através dessas portas;
  • ENV: Instrução que cria e atribui um valor para uma variável dentro da imagem, isso é útil para realizar a instalação de alguma aplicação ou configurar um ambiente inteiro.
  • ADD: Adiciona arquivos locais  ou que estejam em uma url, para dentro da imagem.
  • COPY: Copia arquivos ou diretórios locais para dentro da imagem.
  • ENTRYPOINT: Informa qual comando será executado quando um container for iniciado utilizando esta imagem, diferentemente do CMD, o ENTRYPOINT não é sobrescrito, isso quer dizer que este comando será sempre executado.
  • VOLUME: Mapeia um diretório do host para ser acessível pelo container;
  • USER: Define com qual usuário serão executadas as instruções durante a geração da imagem;
  • WORKDIR: Define qual será o diretório de trabalho (lugar onde serão copiados os arquivos, e criadas novas pastas);
  • ONBUILD: Define algumas instruções que podem ser realizadas quando alguma determinada ação for executada, é basicamente como uma trigger.

Veja abaixo um exemplo de Dockerfile completo:

# VERSION 0.1

FROM ubuntu
RUN echo foo > bar
# Saida parecida com ===> 907ad6c2736f

FROM ubuntu
RUN echo moo > oink
# Saida parecida com ===> 695d7793cbe4

EXPOSE 5900

# Você terá duas imagens, 907ad6c2736f com /bar, e 695d7793cbe4 com
# /oink.

Basta copiar esse código acima em um arquivo chamado Dockerfile e em seguir executar o comando: docker build -t minhaimagem . . E pronto, será criada uma imagem com o nome de minhaimagem, basta usa-la para o que precisar.

Nos próximos posts veremos como criar uma imagem mais complexa, iremos montar um ambiente completo para um site em WordPress, e aprendermos um pouco mais sobre outros recursos do docker build.

Fique atento, e tendo dúvidas já sabe, nos mande uma mensagem, abraço!

Docker 1.9

Olá pessoal,

Estou aqui hoje para divulgar as novas funcionalidades da versão 1.9 do Docker. Abaixo segue algumas de suas novas funções e como isso pode te ajudar.

Multi-host Networking

A funcionalidade de rede multi-host estava em fase experimental desde junho desse ano, agora ela foi lançada como versão estável dentro da engine do Docker, isso é muito útil principalmente se você está pensando em ter diversos hosts de Docker interligados, e claro criar cluster de Docker, pois ele possibilita a criação de redes virtuais entre os hosts. Outro beneficio é que agora a rede é como um plugin adicional do Docker, isso faz com que seja possível trocar o plugin de rede sem precisar mudar algo em sua aplicação ou ambiente, ou seja, não há tanto retrabalho.

Persistent Storage

Nessa nova versão a engine do Docker foi desenhada para trabalhar melhor com os plugins de volume, ou seja, agora além de ser mais fácil trabalhar com volumes, ainda os plugins que existiam foram adicionados como oficiais. Outro beneficio é que agora é possível integrar essas plugins de volumes com o Swarm, deixando ainda mais fácil a administração de um Cluster. Plugins oficiais: Blockbridge, Ceph, ClusterHQ, EMC e Portworx, explicaremos cada um melhor nos próximos posts.

Docker Swarm 1.0

Com as melhorias trazidas com a rede e storage persistente, agora o Swarm ficou ainda mais eficiente, além de algumas correções de bug essa nova versão permite que você crie Cluster de Docker e escale seus containers de forma ainda mais eficiente, em testes realizados pelo pessoal de engenharia do Docker foi possível 30.000 containers em 1.000 nós sem dificuldade alguma.

Docker Engine 1.9

Além das melhorias já apresentadas, a engine do Docker traz ainda:

  • Variáveis em tempo de compilação no Dockerfile: Agora é possível setar variáveis (ou na tradução livre: argumentos), apenas no momento geração da imagem via Dockerfile, isso é muito útil caso você tenha alguma restrição para construir sua imagem (proxy local por exemplo).
  • Pull de imagem concorrente: Até a versão 1.8 do Docker, quando você baixava duas imagens que tem layer iguais, uma das imagens (geralmente a mais recente que você mandou baixar) ficava presa aguardando o término da outra, na versão 1.9 isso foi melhorado e agora você poderá baixar as duas simultaneamente, a diferença é que uma não esperará pela finalização da outra.
  • Sinais de parada: No Dockerfile agora é possível adicionar a instrução: STOPSIGNAL, fazendo com que seja possível personalizar o final de parada enviado para seu aplicativo quando o container for parado.
  • AWS CloudWatch logging driver: Se você tiver sua infra na AWS é possível integrar o CloudWatch com seus containers para ter relatório e monitoramento dos logs de seus containers.
  • Métricas de I/O de disco: Agora comando stats retornará também informações sobre o uso de I/O de disco de cada container.

Docker Compose 1.5

Principais novidade no Compose 1.5:

  • Suporte a Windows: Foi adicionado ao Docker Toolbox Windows, isso agiliza bastante o desenvolvimento e permite você rodar os mesmos comandos do Windows no Mac e vice-versa.
  • Variáveis de ambiente Compose: Agora você pode fazer qualquer coisa em seu arquivo Compose em tempo de execução utilizando variávies de ambiente.
  • Melhor suporte para múltiplos ambientes: Você define qual será seu ambiente base a partir de um único arquivo e em arquivos adicionais acrescenta as definições e mapeamentos de produção, desenvolvimento, QA, e afins.
  • Integração com rede: Isso é experimental ainda, mas possibilidade que você faça deploy via compose em um cluster de Docker, ou ainda possa definir seu cluster através do Compose.
  • Validação de arquivo: Agora o Compose validará seu arquivo de definição e lhe trará mensagens melhoradas com relação a análise em caso de erro

Docker Toolbox

Com o Docker Toolbox é possível você montar seu ambiente de desenvolvimento independente do S.O utilizando, basta você instala-lo, ele trará todas as ferramentas citadas acima empacotadas em um único instalador.  Ele ainda permite que você se conecte com algum provedor de externo. Você ainda pode escrever seu próprio driver para ele.

Docker Registry 2.2

Novidades dessa nova versão do Registry:

  • Suporte ao Google Storage: Agora é possível você armazenar suas imagens no Google Storage Plataform;
  • Modo somente leitura: Se você quer manter a consistência de seu repositório em momentos de manutenção, basta colocá-lo em modo somente leitura e os usuários poderão apenas ler as imagens, sem permissão para acrescentar novas
  • Arquivo configurável de HealthCheck: Se você quer desativar um repositório sem afetar outras ferramentas que dependem dele, você pode adicionar um arquivo para invalidade as consultas e download das imagens contidas nele.
  • Cabeçalhos de resposta HTTP configuráveis: Agora é possível você personalizar os cabeçalhos resposta HTTP do registro, isso é útil para melhorar a segurança do repositório ou até mesmo personalizar para o seu ambiente.

Ufa! bastante coisa não? Imaginem o que virá na 2.0 :). Espero ter ajudado e nos ajude divulgando o Blog.

Abraço!

Docker no Windows 10

Oi pessoal!

Hoje o intuito é mostrar para vocês como instalar e utilizar o Docker for Windows no Windows 10 com apenas alguns cliques, com a ajuda do nosso amigo da Umbler, o Leo, estamos disponibilizando um vídeo com o passo-a-passo que deve ser seguido. Antes veja alguns requisitos que você precisa atender:

  1. Você deve ter o suporte a virtualização habilitado em seu computador;
  2. Seu Windows deve ser 64bits versão 1607 e build: 14393.0;
  3. Você deve habilitar o recurso do hyper-v;
  4. Baixe o Docker for Windows pelo link.

Basta você habilitar na Bios de seu computador o recurso de virtualização, para isso será necessário reiniciar seu computador. Em seguida habilite o recurso do hyper-v através do adicionar recursos do Windows (Painel de controle – programas – recursos do Windows). Execute o arquivo que você baixou lá do site do Docker e siga as instruções que aparecerem, logo em seguida aparecerá para você uma mensagem no canto inferior direito informando que o Docker está sendo iniciado, aguarde até a mensagem sair e pronto, o Docker estará instalado e configurado em seu computador.

Se você desejar, pode alterar as configurações dele pelo ícone que estará nos Ícones ocultos, por lá é possível parar e iniciar o serviço do Docker, assim como modificar o registry default, alterar configurações de rede, compartilhamento de volume, dentre outras opções.

Para usar é muito simples, abra o cmd e execute os comandos do Docker Cli, como se você estivesse em um terminal linux: docker ps -a, docker images, docker run xxx e assim por diante, note que a versão que ele instalará já é a 1.12 rc4, como você já viu nesse post, ela trás uma séria de melhorias e novas features, então bom divertimento :).

Esperamos que tenham gostado, e precisando nos enviem suas dúvidas para que possamos ajudar.

Grande abraço!

Docker Universal Control Plane – Parte 1

Oi Pessoal,

Depois de um tempo nas postagens, hoje vamos iniciar os trabalhos aqui no https://mundodocker.com.br, trazendo para vocês uma das soluções que o Docker disponibilizou (ainda em fase beta) e que veio como resultado da aquisição da Tutum, que é o Docker Universal Control Plane. Entenda um pouco mais sobre as suas funcionalidades e objetivos neste primeiro post.

O Docker UCP, assim como algumas ferramentas que já apresentamos aqui (vide Rancher) é uma alternativa de painel para administração de sua infraestrutura de Docker, seja ela local ou na nuvem, a diferença entre essas ferramentas é basicamente a empresa que presta suporte e mantem a ferramenta, no caso da UCP a própria Docker. Em questão de funcionalidades tanto Rancher quanto UCP são bem parecidas, com a diferença novamente de que a UCP é 100% compatível com o Docker e suas ferramentas nativas, como por exemplo a Docker Swarm e Compose. Veja abaixo uma listagem das funcionalidades e benefícios da Docker UCP:

Solução voltada para empresas:

Um dos recursos que existe no UCP é a opção de integrar o método de autenticação em seu LDAP ou AD, isso é muito mais seguro e claro ajuda na organização e delegação de funções dentro do painel.

Gerenciamento nativo de seu ambiente Docker:

Como mencionei acima, o Docker UCP é desenvolvido pela própria Docker, isso garante 100% de compatibilidade entre todas as ferramentas que a Docker já disponibiliza e este painel, e claro, torna mais fácil a integração entre as diferentes ferramentas.

Administração simplificada:

Você pode gerenciar desde containers individuais até aplicações mais complexas que utilizam o Docker Compose, você pode de forma fácil criar um conjunto de rede ou volume e associar a sua aplicação/container apenas via interface web, sem a necessidade de acessar os servidores.

Resultado mais rápido:

O UCP permite você gerenciar e otimizar seu deploy de aplicação, você pode configurar todo seu ambiente, incluindo repositório de imagens e servidores em poucos cliques, isso é muito mais prático do que ficar configurando o ambiente via linha de comando e claro gera retorno muito mais rápido, o que no mundo DevOps isso é imprescindível.

 Agilidade e Controle:

Crie, gerencie e faça deploy de qualquer aplicação, em qualquer lugar, quando quiser, escale, distribua e altere quando for necessário sem perder o controle, esse é um dos pontos fundamentais do UCP, e uma das vantagens mais interessantes para os times de desenvolvimento e infra estrutura.

Escalável e disponível:

O Docker UCP foi desenhado e desenvolvido para ser altamente disponível e para que você possa escalar de forma fácil e rápida, para isso ele utiliza como engine de clusterização o Docker Swarm, que como já explicado aqui no blog, é extremamente leve e fácil de se administrar. Para garantir uma maior disponibilidade o Docker UCP pode ser integrado com algum serviço de entrega de chave-valor, como Consul, Etcd, dentre outros, isso na verdade é uma das premissas para se ter o Docker UCP rodando em seu ambiente, pois apenas utilizando um desses serviços é que se garante a disponibilidade da ferramenta.

Fique atento, em breve postaremos mais alguns posts sobre essa ferramenta, e quem sabe um vídeo ;).

Gostou? Nos ajude divulgando o blog, abraço!

MundoDocker no DevWeek – POA

Oi Pessoal,

Ontem participamos de um evento realizado pela iMasters, o DeveloperWeek, e na edição de Porto Alegre fomos convidados a fazer uma apresentação sobre Docker, e claro nós fomos :), queremos neste post compartilhar com vocês o conteúdo que apresentamos, assim como o vídeo demonstrando na prática como o Docker pode auxiliar as equipes de DevOps. veja:

                                                                                                                                                                     

No final do evento recebemos um presente do pessoal da iMasters pela contribuição

DevWeek

E fica o convite para o segundo MeetUp sobre Docker em Porto Alegre: http://meetup.com/Docker-Porto-Alegre e claro para o TcheLinux POA: http://poa.tchelinux.org, estaremos em ambos os eventos

Fique atendo as novidades, e nos ajude divulgando o Blog.

Abraço!

WinDocks – Docker For Windows

Oi Pessoal,

No final do mês passado foi lançada uma StartUp com objetivo de criar uma forma de executar containers Windows utilizando como sistema base o Windows Server 2012, hoje compartilho com vocês um vídeo produzido pela equipe da WinDocks explicando como funciona a solução deles e como rodar um container com SqlServer e IIS, veja em:

https://youtube.com/watch?v=ZrLxiYy3ZZU

Agora em outubro eles pretendem lançar uma versão Beta ao público, isso fará com que a solução seja melhor avaliada e claro, melhorada.
É uma proposta bem interessante e tem muito a acrescentar no ecossistema Docker, ficamos no aguardo de novidades deles, e podem deixar que vou informando vocês por aqui. Quer ir mais afundo? Acesse: http://windocks.com/.

Grande Abraço!

MundoDocker no DevOpsWeek

Oi Pessoal,

O Ano começou a todo vapor aqui para o MundoDocker, e hoje queremos convidar a todos para se inscreverem no DevOpsWeek, um dos maiores eventos sobre o assunto DevOps, Desenvolvimento/Infra ágil do Brasil.

Participaremos do evento com a apresentação: Deploy Integrado com Docker, é o assunto do momento, e o objetivo é tirar dúvidas e dar ideias de como o você pode usar Docker para automatizar suas rotinas, e claro acelerar seus processo de desenvolvimento.

Veja abaixo a chamada para o evento que gravamos, te liga:

Ficou interessado? Então te inscreve, o evento é online e gratuito!!! Acesse: http://devopsweek.com.br

 

Por hoje era isso, e fique atento pois teremos mais novidade aqui no Blog.

Grande abraço!

Git e Docker

Fala pessoal,

Hoje vamos demonstrar como podemos utilizar Docker e Git dentro de nossos containers.

 

 

Legal não? Se gostou ajude-nos divulgando o mundodocker.com.br, abraço!

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!

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/

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

 

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.

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 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, Swarmkit, Docker 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 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!

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!