Tag: Docker Deploy

MundoDocker no DevOpsWeek

1 Comment

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!

Docker 1.13 – O que vem por ai

Leave a comment

Eai gente!

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

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

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

 

Docker stack

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

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

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

Muito mais simples e rápido não?

 

Gerenciamento de senha

Ou gerenciamento de segredos, essa é uma função básica dentro de qualquer orquestrator, o Kubernetes já possuía esse conceito e aplicação á algum tempo já, e agora o docker também implementa essa funcionalidade.
Mas afinal, onde vou usar isso? Sua aplicação usa senha não usa? Seja para banco, API, etc, qualquer aplicação usa senha de acesso a algum serviço em algum momento, e com você faz hoje com Docker? Provavelmente via variável de ambiente ou compartilhando um arquivo com o container, existem outras formas, como ferramentas as a service de gerenciamento de identidade.

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

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

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

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

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

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

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

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

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

 

Novo parâmetro de rede no Swarm

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

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

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

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

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

 

Plugins

Finalmente alguns plugins que estavam sendo testados e aprimorados foram disponibilizados como estáveis dentro da engine do Docker. Dentre ele podemos destacar o Flocker e o Weave, que agora tem integração total com docker.

 

Docker Daemon –experimental

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

 

Melhorias no docker service

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

 

Novo parâmetro no docker service

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

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

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

 

Outras novidades

Dentre outras novidades do docker 1.13 podemos destacar ainda algumas que tem bastante relevância para quem o utiliza, como por exemplo:

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

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

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

 

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

 

Grande abraço!

 

 

Docker Global Mentor Week – Review

Leave a comment

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://www.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!

Docker Service

2 Comments

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!

 

Docker e Jenkins para build de aplicações

5 Comments

Olá pessoal,

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

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

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

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

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

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

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

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

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

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

1

Para pegar a senha você irá executar

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

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

2

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

3

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

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

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

14

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

15

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

Obrigado!

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

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

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

Docker 1.12 – O que vem por aí

2 Comments

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 Machine

6 Comments

Olá!

Umas das ferramentas mais interessantes do ecossistema Docker, e que é mantido pela própria Docker é o Docker Machine, com ele é possível você fazer deploy de seu ambiente na infra-estrutura que desejar, você pode portar sua aplicação do seu notebook para AWS, Digital Ocean, ou o que for. Veja no vídeo um exemplo prático disso:

Você pode ainda integrar com Docker Compose, e automatizar ainda mais essas tarefas, legal né? Espero que tenham gostado, tendo dúvidas nos contatem, estamos dispostos a sanar todas as dúvidas.

Abraço!