Coleta de métricas no Docker Swarm

Oi Pessoal!

Queremos trazer para vocês hoje uma solução para coleta e visualização de métricas para o Docker Swarm. Um dos maiores desafios, principalmente para as equipes de operações, é saber quanto está sendo utilizado por cada container, OK, existem soluções na engine do Docker, como é o caso do docker stats, mas e quando você tem um diversos hosts, e eles estão em cluster e não tem definido quais containers estão em cada host, complicou né?

A intenção com este post é mostrar como é possível ter, de forma fácil, todas as informações de consumo de seu cluster, utilizando soluções simples, e que a maioria de vocês já deve ter visto. Para este lab vamos usar o Cadvisor, Influxdb e Grafana, vamos entender melhor onde cada um irá atuar neste ambiente.

Cadvisor

Como já vimos aqui no blog, o Cadvisor é uma ferramenta desenvolvida justamente para realizar a coleta de recursos de containers/aplicações dentro de um servidor. É possível estender seu uso através de integração com a API que essa ferramenta disponibiliza, e enviar os dados coletados para diversos backends, em nosso lab vamos utilizar o InfluxDB, que você verá logo abaixo o que é e como funciona.

 

InfluxDB

Para quem não conhece, o InfluxDB faz parte de um conjunto de soluções da empresa InfluxData, que tem seus produtos voltadas para analise, monitoramento e armazenamento de informações cronológicas. O InfluxDB é conhecido como um data series database, que serve justamente para armazenar dados em ordem cronológica.

 

Grafana

O Grafana talvez seja uma das mais completas ferramentas para criação e exibição de gráficos, e uma ferramenta extremamente flexível e adaptável, tendo como input diversos tipos de backend, o que facilita ainda mais o nosso lab 😉 . Você pode inclusive ter mais datasources e montar o seu dashboard unindo todas as essas informações, bacana né?

 

Ok, teoria é muito bonita, mas… vamos praticar?

Primeiramente você deve ter em execução o seu cluster, caso não tenha feito isso ainda, faça agora, caso tenha dúvidas, veja este post, onde mostramos na prática como fazer isso 🙂 . Certo agora vamos criar os serviços de coleta para o nosso cluster, para isso, você pode executar o seguinte passo-a-passo:

  •  Crie uma rede do tipo overlay para que seja possível a comunicação entra as ferramentas, e que essa comunicação seja realizada de forma isolada:
$ docker network create -d overlay --attachable coleta
  • Em um dos dos hosts (de preferência o menos utilizado), crie o servidor de Influx, que será utilizado como backend para as informações coletadas:
$ docker run -d --restart=always -v /data:/var/lib/influxdb --network coleta --name influx influxdb
  • Devemos criar a database dentro do influx para que seja possível salvar as informações:
$ docker exec -it influx influx -execute 'CREATE DATABASE cadvisor'
  • Ok, agora basta criar o serviço de coleta no cluster:
$ docker service create --name agentes --network coleta --mode global --mount type=bind,source=/,destination=/rootfs,readonly=true --mount type=bind,source=/var/run,destination=/var/run  --mount type=bind,source=/sys,destination=/sys,readonly=true  --mount type=bind,source=/var/lib/docker,destination=/var/lib/docker,readonly=true google/cadvisor -logtostderr -docker_only -storage_driver=influxdb -storage_driver_db=cadvisor -storage_driver_host=influx:8086

Se tudo correu bem, você deve terá criado um serviço do tipo global, ou seja, cada host de seu cluster terá um container desse tipo (Cadvisor), e todos eles enviarão os dados para o banco influx. Para ter certeza de que tudo correu bem, você pode executar o comando:

$ docker service ls

Dessa forma você visualizará os serviços que estão em execução, e terá ter certeza de que os containers iniciaram em todos os nós, o retorno do comando deverá ser algo parecido com isso:

$ docker service ls
ID           NAME    MODE   REPLICAS IMAGE                  PORTS
5ras37n3iyu2 agentes global 2/2      google/cadvisor:latest

Viu, tudo certo 🙂 Mas ainda não acabou, continuando:

  • A última etapa é subir nosso serviço de Grafana para podermos visualizar as informações que foram coletadas pelo Cadvisor, e armazenadas no InfluxDB, execute:
$ docker run -d --restart=always -v /data:/var/lib/grafana --network coleta --name grafana -p 80:3000 grafana/grafana

Simples né? Agora temos que acessar a interface do Grafana para podemos configurar e termos os gráficos que desejamos, acesse: http://ip-do-host/login, você visualizará a interface de acesso dele, como ilustrado abaixo:

Os dados de acesso default do Grafana são:

User: admin
Password: admin

Estando dentro da interface do Grafana, vá até “Source” e adicione uma nova fonte de dados, nela informe “InfluxDB”, conforme imagem abaixo:

Após clique em “save & test” para validar o acesso ao seu InfluxDB. Se tudo ocorrer conforme o planejado, você terá sucesso nessa adição, e em seguida deverá montar o gráfico baseado nas informações que estão no banco, para isso existem duas formas, uma mais complexa onde você precisará montar as querys e depois criar o gráfico com essas querys, ou importar um template pronto para isso, e neste caso eu agradeço ao Hanzel Jesheen, pela contribuição a comunidade, em ter criado o template e disponibilizado em seu github 🙂 . Você pode baixar este arquivo, salvar em seu computador e depois ir até a área de Dashboard de seu Grafana e clicar em import, informe o caminho de onde salvou o template, escolha o source criado anteriormente e depois clique em “import”, conforme imagem abaixo:

Parabéns! Você acaba de montar seu sistema de coleta e visualização de recursos para todo o seu cluster! Indo até Dashboards – Cadvisor você terá uma visualização parecida com esta:

Bacana não?

A partir desse protótipo você pode evoluir seu ambiente para atender a sua demanda, em nosso lab a coleta é realizada pelo Cadvisor e enviada ao InfluxDB a cada 60 segundos, isso quer dizer que o gráfico tem um delay de 1 minuto entre a coleta e a visualização, para alguns isso é problema, para outros não. Outro ponto que você deve se atentar é: Quantos mais containers você tiver, mais poluído ficará o seu gráfico, isso por motivos óbvios, então talvez você precisa alterar o layout do dashboard. Ahhh não esqueça de trocar a senha do usuário admin do Grafana 😉

Por hoje era isso gente, esperamos que isso ajude vocês, e continuaremos com alguns posts mais técnicos trazendo alguns soluções ou implementações legais utilizando Docker. Nos ajude divulgando o blog, e tendo dúvida nos avise!

Grande abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

Segurança do Docker Swarm

Olá gente!

Com a grande ajuda do wsilva, estamos trazendo um post que levanta um ponto bem interessante do ambiente de Docker Swarm : Como deixar meu cluster mais seguro?

Existem diferentes forma de se fazer isso, algumas nativas, e outras envolvendo ferramentas de terceiros, nesse post replicaremos o post do Dumps Cerebrais, que aborda uma das formas nativas de se garantir maior segurança no cluster de Swarm. Vamos lá!

O Auto Locking

é uma das grandes funcionalidades adicionadas na versão 1.13.0 do Docker e presente nas novas versões 1.13.1, 17.03.0-ce, 17.03.1-ce e 17.04.0-ce (versões disponíveis até a data de publicação desse artigo).

Você deve estar se perguntando: “Versões 1.12, 1.13 e agora 17.03.x-ce? Que zona é essa?” Na verdade não é zona, é reorganização, na versão 1.13 uma das novidades foi a reorganização dos comandos no CLI, agora a Docker está reorganizando os release e versões. Ela lançou um novo ciclo de releases, renomeou as versões baseando-se em datas (ano e mês) e separou a parte open source, Docker CE (community edition) da parte proprietária com licensa e com planos de suporte da própria Docker, o EE (enterprise edition). Resumindo reorganização. Mas essa é uma história que podemos detalhar em outro artigo, nosso foco aqui será mostrar o que é e como funciona o Auto Locking

A motivação por trás do Auto Locking

Tanto a comunicação entre os nós do Swarm quanto os logs do Raft consensus são por padrão encriptados por chaves TLS que ficam nos discos das máquinas managers. Tá, mas o que isso quer dizer?

Vamos imaginar que uma máquina manager reinicia, tanto a chave TLS usada para a encriptação da comunicação entre os nós, quanto a chave TLS usada para encriptar os logs do Raft são carregados na sua memória. Isso por um lado é bom pois permite que um nó seja reiniciado sem intervenção humana e sistema continua funcionando normalmente. Por outro lado se alguém conseguir essas chaves seja por um backup que vaze ou disco corrompido essa pessoa vai conseguir acesso aos logs do Raft e também às informações sensíveis como onde estão rodando os serviços, às configurações de acesso dos serviços e inclusive aos secrets dessas aplicações rodando nesse cluster.

Como funciona o Auto Locking.

O auto locking é uma camada de proteção a mais e é super simples. Quando você iniciar ou atualizar um cluster Swarm passando a flag --autolock uma chave é gerada para encriptar as demais chaves, porém essa nova chave é responsabilidade nossa e deve ser mantida por nós, devs e operadores. Seja via password manager, seja guardando de cabeça (o que duvido), seja anotando em papel de pão.

Com o auto lock ativo se por um acaso a máquina reiniciar ninguém conseguirá rodar comandos nela sem antes desbloqueá-la e para desbloquear aquela chave de nossa responsabilidade será solicitada.

Podemos iniciar um cluster já utilizando a funcionalidade de auto lock:

$ docker swarm init --autolock
Swarm initialized: current node (drr4hrzngqoh90cpp0t5lnuv1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1infi7fei781xasqoh1q1k5i7p47ocvyptaoq1r6dmmp1bwz0p-e37ividr81a45qzhq9ptkb836 \
    192.168.65.2:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-nly8Gmulj+xuPwFF4ks4evN6OxdUtVFdD1QlIhdVvto

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Ou adicionar a um cluster já em produção:

$ docker swarm update --autolock
Swarm updated.
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-av+McYBAyjy6o1RMYsDqUsS8lkjH05t5HMnP7USjk+4

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Podemos perceber o token gerado nos dois casos, ambos começam com SWMKEY, essa é a chave que devemos guardar, ela não é persistida no cluster.

Se a máquina manager não estiver travada você consegue recuperar essa chave com seguinte comando:

$ docker swarm unlock-key
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-av+McYBAyjy6o1RMYsDqUsS8lkjH05t5HMnP7USjk+4

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Se a máquina estiver travada qualquer comando administrativo não será executado e vai retornar a seguinte mensagem:

$ docker node ls
Error response from daemon: Swarm is encrypted and needs to be unlocked before it can be used. Please use "docker swarm unlock" to unlock it.

Para mudarmos a key que destrava o Swarm usamos o seguinte comando:

$ docker swarm unlock-key --rotate
Successfully rotated manager unlock key.

To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-ECkuyhW8Zgc9nZthmkMpZd5f+mxPuOEC5K6CyA89xNk

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Para ficar mais claro, o wsilva ainda gravou um vídeo, esse mesmo foi utilizado no meetup de docker em SP (grupo do qual ele ajuda a organizar), confere:

Bem bacana né? Então não deixe de utilizar, como visto é bem simples a sua configuração, se quiser ter certeza antes de sair colocando em produção, usa o Play-With-Docker para montar seu lab e testar, é uma ferramenta free e bem simples de se usar, através dela você pode subir todo seu ambiente, validar e depois disso colocar a mão na massa em seu ambiente, há obviamente uma limitação, que é o tempo de uso, mas garanto que facilita horrores 🙂 .

Então era isso, nos ajude divulgando o blog, e deixe suas dúvidas, elogios ou críticas nos comentários 😉 .

Grande abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

Docker Swarm na Prática

Oi Pessoal!

Fizemos um vídeo mostrando na prática como é possível criar um cluster de Swarm e gerenciar seus serviços com ele, veja também como você pode portar sua stack do Docker Compose para dentro do cluster via o Docker Stack. Veja:

Este é apenas um vídeo de lab, lembramos que você deve se ater a alguns outros pontos nesse ambiente antes de colocar em produção, OK? 😉

Contamos com a ajuda de vocês para divulgação do blog, grande abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

Docker Secrets

Oi pessoal! 

Para o artigo de hoje, contamos com a ajuda de um grande amigo nosso, o Wellington F. Silva, que colocou em seu blog um texto muito bacana sobre o que é e como funcionam as secrets no Docker 1.13. No decorrer desse post entenderemos como essa nova funcionalidade trabalha, sua origem e claro, o impacto disso em nosso dia-a-dia, #vamoslá?

 

O que é o secret?

Quando estamos trabalhando em um projeto e precisamos passar informações sensíveis para o ambiente, tais como senhas, chaves privadas, tokens, chaves de APIs e afins sempre passamos pelo problema de não podermos deixar no controle de versão e devemos sempre utilizar uma maneira segura de trafegar esses segredos.

Muitas vezes acabamos trabalhando com variáveis de ambiente para guardar essas informações, o que não é recomendado por alguns motivos.

Diogo Monica que é um dos engenheiros de software da Docker mencionou em um comentário que variáveis de ambiente quebram o princípio de “least surprise” e podem levar a eventuais vazamentos de segredos já que estão acessíveis de várias maneiras, tais como linked containers, através do *docker inspect*, de processos filhos e até de arquivos de logs já que em caso de exceptions da aplicação muitos frameworks fazem o dump do contexto, inclusive o valor das variáveis de ambiente no arquivo de log.

 

Um pouco da história

Em Janeiro de 2015 houve uma proposta de adicionar o comando `docker vault` numa alusão ao Vault Project da Hashicorp para fazer a gerencia de segredos dentro do próprio Docker. Segue o link para a issue 10310 no GitHub. A discussão evoluiu e virou a issue 13490, onde trataram do roadmap para o atual Docker Secrets.

 

Como funciona?

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

 

Dicas

  • Só funciona no Swarm Mode onde toda a comunicação entre os nós é por padrão encriptada.
  • Se utiliza do algoritmo de RAFT para persistir o segredo de forma encriptada por todos os nós managers e distribuir aos containers que fizerem parte do serviço ao qual a chave for atribuída.

Segue diagrama da própria Docker:

Criando um secret

Podemos criar um secret de duas maneiras, usando o STDIN:

$ echo "ConteudoDoSecret" | docker secret create um-secret -

Ou lendo um arquivo:

$ docker secret create novo-secret $HOME/senhas.txt

 

Listando, removendo e demais opções

Para listar as secrets disponíveis:

$ docker secrets ls
  ID NAME CREATED UPDATED
  8ulrzh4i1kdlxeypgh8hx5imt um-secret 3 minutes ago 3 minutes ago
  n95fprwd2trpqnjooojmpsh6z novo-secret About an hour ago About an hour ago

Demais opções do que fazer com os secrets como remover, inspecionar, etc podem ser listadas com o help:

$ docker secret --help

 

Usando o secret criado

Podemos criar um serviço usando um secret criado com o comando:

$ docker service create --name demo --secret um-secret mysql:5.7

Podemos remover um secret de algum serviço existente

$ docker service update --secret-rm um-secret demo

Ou podemos adicionar um secret a algum service que esteja de pé:

$ docker service update --secret-add novo-secret demo

 

Quando atrelamos um secret a um service podemos então acessar qualquer um dos containers que estejam rodando nesse service no path /run/secrets. Dentro do container nesse path vai existir um arquivo plain text com o nome igual ao definido no nome do secret e com o conteúdo desejado, o secret em plain text. No nosso caso seria no path /run/secrets/novo-secret.

 

Bem legal não é? Ajude divulgando o blog, e fique ligado teremos muitas novidades em breve, então se não se inscreveu em nossa newsletter, inscreva-se ;). Até a próxima.

 

Fonte: http://dumpscerebrais.com/2017/02/como-trabalhar-com-secrets-no-docker-1-13-x/

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

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!

 

Trabalha em uma Startup com foco em Plataforma como Serviço (PaaS), é especialista em Cloud Computing e Conteinerização, desenvolve todo dia uma nova maneira de resolver problemas e criar coisas novas.

Docker Service

Oi Pessoal,

Hoje queremos trazer em detalhes para vocês uma das features implementadas no Docker 1.12 (que foi lançado no último dia 29), e que já mencionamos aqui, que é o Docker Service. Para quem ainda não leu o nosso post sobre as novidades do Docker 1.12, o Docker Service é uma feature que foi incorporada pela engine Docker em sua última versão e que permite ao administrador criar e administrar sua stack de serviço dentro de um cluster Swarm, sem precisar utilizar uma segunda ferramenta para isso. Ela é parte integrante de uma série de melhorias que permitiram ao Docker 1.12 ter a camada de orquestração nativa em sua engine.

Mas afinal, como isso me ajuda? Bem, nas versões anteriores do Docker, para você ter algum tipo de orquestração você teria que utilizar uma série de ferramentas, como por exemplo: Docker Swarm, Docker Compose isso sem falar, que, se você quisesse provisionar isso em larga escala mesmo, o recomendado era utilizar Kubernetes, Mesos ou alguma outra forma de orquestração mais adequada. Agora está tudo dentro da própria engine do Docker, o que permite você ter maior controle sob o que está utilizando, e claro, permite você manipular esse ambiente de forma mais simples.

Para serviço especificamente, foi adicionado o sub-comando: docker service, e dentro dele alguns itens, veja:

  1. docker service create: Possibilita a criação de sua stack de serviço, é ele o que você mais vai ver hoje ;)
  2. docker service inspect: Verifica as informações sobre seu serviço e retorna informações sobre parametro utilizados para inicialização do mesmo, imagem utilizada, etc.
  3. docker service ls: Lista todos os serviços que você tem criado, e lhe retorna informações sobre nome, quantidade de replicas, etc.
  4. docker service rm: Remove o serviço desejado do cluster
  5. docker service ps: 2° comando mais útil, retorna para você o status de cada container que atende um serviço, é muito parecido com o docker ps, com a diferença de lhe trazer apenas informações sobre os container que fazem parte de um serviço criado, você pode ainda utilizar filtros para ter um retorno mais simplificado.
  6. docker service scale: Com o scale é possível realizar o escalonamento de seu serviço, é possível você aumentar a quantidade de containers que atenderão o seu serviço.
  7. docker service update: Comando que lhe permite realizar modificações no serviço criado, através dele é possível modificar informações sobre quantidade de memória, cpu, dentre muitas outras coisas em seu serviço.

Tudo certo com a teoria? Então vamos a prática :), nosso problema: Queremos criar uma stack para nosso ElasticSearch, nosso objetivo é escalar esse ambiente quantas vezes eu quiser e atualiza-lo de forma consistente.

Primeiro temos que criar nosso service:

docker service create --replicas 1 --update-delay 10s --update-parallelism 1 --name elasticsearch elasticsearch

O que isso quer dizer? Vamos lá:

  • Replicas – Número de containers que eu quero criar nesse momento, deve ser no mínimo um (por motivos óbvios);
  • Update-delay – Quando for realizado uma procedimento de atualização do ambiente, qual será a cadência de atualização dos containers.
  • Update-parallelism – Quantidade de containers que desejamos atualizar por vez
  • Name – Nome do serviço e por último a imagem que vamos utilizar para esse serviço.

O retorno do comando será algo parecido com isso:

docker-service1

Certo, meu serviço está criado, como escalono ele agora? Fácil, olha o print 🙂

docker-service2

Note que para escalar, basta executar o comando: docker service scale $(seu-servico)=numero. Agora vamos atualizar o nosso ambiente, certo? Muito fácil, basta executar o comando: docker service update, com ele é possível modificar diversos atributos do serviço, como por exemplo: Portas publicadas, limites de recursos, número de replicas, imagem, politica de escalonamento, etc.

Em nosso exemplo vamos atualizar a imagem que nosso serviço utiliza, veja que quando criamos, a imagem utilizada era a elasticsearch:latest, agora queremos testar a última versão do elasticsearch, que está em alpha (no dia da criação desse post) que é a 5.0, para isso basta executar: docker service update –image elasticsearch:5.0 elasticsearch, veja o que aconteceu:

docker-service3

Veja que nosso serviço não foi atualizado de uma vez só, esse processo foi sendo realizado conforme os containers iam sendo atualizados, isso devido a nossa politica de update que definimos na criação do serviço. Com o update você pode realizar diversas ações, veja mais em: docker service update –help, ele lhe mostrará todas as opções disponíveis.

Como removemos um serviço? Bem, você já deve ter imaginado como: docker service rm nome_do_servico.

Ahh, você se lembra que falamos aqui que no Docker 1.12 era possível criar um serviço distribuído dentro Swarm e acessá-lo de qualquer lugar? Pois bem, quando você criar um serviço você pode especificar qual será a porta publica dele, no exemplo acima não utilizamos isso, mas você pode definir (através do parâmetro -p) que a porta 8080 seja a porta de seu serviço, com isso todo o trafego enviado para a porta 8080 nos ips de seus nós do cluster de Swarm será redirecionado para os containers que atendam esse serviço. Lembrando que para você criar um serviço distribuído é necessário ter um cluster de Swarm ativo.

Gostaram do post? Deixe seu feedback e novamente, nos ajudem divulgando o blog.

Grande abraço!

 

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

Docker 1.12 – O que vem por aí

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!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.