Tag: Docker Deploy

SwarmKit

Leave a comment

Oi Pessoal,

Hoje, você não pode pensar em utilizar Docker em produção em larga escala sem ter alguma forma de automação e orquestração dessa “coisa”, graças a comunidade e algumas empresas, temos ferramentas que podem nos auxiliar nessas tarefas, todas juntas ou em partes, é claro. Atualmente as ferramentas mais conhecidas para orquestração e scale em Docker são Kubernetes e Mesos, existem muitos projetos mantidos pela comunidade nesse sentido, mas nenhum deles com tanta representatividade quanto aos mencionados anteriormente. Para não ficar de fora desse mundo, a Docker vem trabalhando bastante em uma suite que atenda essa necessidade, e que futuramente seja incorporado ao Docker Data Center, o projeto chama-se Swarmkit, e hoje, aqui no MundoDocker, vamos ver um pouco mais sobre ele.

O Que é?

O Swarmkit é uma suite para escalonamento e orquestração para sistemas distribuídos, ele possui um sistema de descoberta de nós, agendamento de tarefas, e utiliza o raft-based consensus para coordenação do cluster.

O que tem de bom?

  • Como já mencionado, ele utiliza o raft-based consensus, isso garante uma melhor coordenação do cluster, eliminando assim o ponto único de falha.
  • Todo os nós do cluster Swarm conversam de forma segura, e para ajudar nisso o Swarmkit utiliza TLS para autenticação, autorização e transporte dos dados entre os nós.
  • Swarmkit foi projeto para ser simples, por isso ele é independente de base de dados externas, ou seja, tudo que você precisa para utiliza-lo já está nele.

Ele é composto basicamente de duas camadas: Worker e Manager nodes, para entender cada um:

Worker: Responsável por executar as tarefas utilizar um Executor, por padrão o Swarmkit vem com o Docker Container Executor, mas que pode ser trocado caso deseja.

Manager: Basicamente é o nó eleito pelo administrador para ser o ponto central de administração, lembrando que quanto você adiciona um nó no cluster de Swarm você define se esse nó será Manager ou não.

Como outras ferramentas, para o Swarmkit as tarefas são organizadas em serviços, e para esse serviço você define o que deseja fazer, por exemplo: Crie replicas desse serviço todo dia as 10h, ou: Atualize um container por vez baseado nessa nova imagem.

Features

  • Oquestração
  1. Estado desejado: O Swarmkit analise constantemente o cluster, garantindo que todos os serviços estejam de acordo com o pretendido pelo usuário, isso faz com que um serviço seja provisionado em outro nó caso algum falhe.
  2. Tipo de serviço: atualmente o Swarmkit suporta apenas 2 tipos: 1 – Replicas, onde você define quantas cópias daquele container deseja, e 2 – Global, onde você especifica o que deve ser executado em cada nó do cluster.
  3. Atualização: Você pode modificar a qualquer momento o estado de um serviço, seja para para-lo ou escala-lo, quando você atualiza um serviço, por padrão ele executa essa tarefa de atualização de uma vez só para todos os nós do cluster, mas você pode definir de outras duas formas essa atualização: 1 – Paralela, onde o administrador define quantas tarefas de atualização podem ser executadas por mês ou 2 – Delay, dessa forma o Swarmkit executará as tarefas de atualização de serviço de forma sequencial, ou seja, uma tarefa só será executada caso a anterior já tenha terminado.
  4. Politicas de restart: A camada de orquestração monitora o estado das tarefas e reage as falhas aplicando a regra definida pelo usuário, dentro dessas regras o administrador pode definir número máximo de tentativos de restart de um serviço, quanto tempo depois de uma falha esse serviço deve ser reiniciado, etc. Por padrão o Swarmkit reinicia o serviço dentro de outro nó disponível no cluster, isso garante que os serviços dos nós defeituosos sejam iniciados em outros nós o mais rápido possível.
  • Agendamento
  1. Recursos: O Swarmkit sabe, através das checagens constantes, como está a saúde de cada nó, com isso, quando um serviço precisa ser reiniciado ou realocado, por padrão essa tarefa será realizada no melhor nó do cluster;
  2. Restrições: O administrador pode limitar o reinicio de um serviço em determinados nós, isso pode ser feito através de labels, exemplo: node.labels.foo!=bar1
  • Gerenciamento de cluster
  1. State Store: Permite ter uma visão macro de todo o cluster, como suas informações ficam em memória, permite ao nó de gerenciamento tomar decisões de forma muito mais rápida e segura.
  2. Gerenciamento da topologia: O administrador pode alternar quais são os nós de gerenciamento e qual são os Workers através de chamadas de API ou CLI.
  3. Gerenciamento de nós: É possível definir um nó como pausado, por exemplo, com isso os serviços que estavam alocados neste nó serão iniciados nos demais nós, assim como a execução de novas tarefas permanece bloqueada.
  • Segurança
  1. TLS: Todos os nós se conversam através de TLS, e os nós de gerenciamento agem como autoridade certificadora de todos os demais nós, e são responsáveis pela emissão de certificados para os nós que entram no cluster.
  2. Politica de aceitação: O administrador pode aplicar regras de auto-aceitação, aceitação manual ou troca de chaves, isso claro na adição de novos nós ao cluster, por default o Swarmkit utiliza auto-aceitação.
  3. Troca de certificados: É possível definir a frequência com a qual serão alterados os certificados ssl utilizados para comunicação do cluster, por padrão o tempo é de 3 meses, mas pode-ser definir qualquer período maior que 30 minutos.

Vamos brincar?

Instalando

O Swarmkit foi desenvolvido em GO, então tenha todo o ambiente pré-configurado e claro, baixe os fontes para seu $GOPATH, você pode utilizar:

[root@docker1 ~]# go get github.com/docker/swarmkit/

Acesse o diretório, e execute:

[root@docker1 ~]# make binaries

Isso fará com que sejam instaladas as ferramentas para utilização do Swarmkit, em seguida você pode testar sua instalação:

[root@docker1 ~]# make setup
[root@docker1 ~]# make all

Agora adicione o swarmd e swarmctl ao seu $PATH e seja feliz utilizando ele, veja abaixo alguns exemplos.

Montando o Cluster

No primeiro nó, execute:

[root@docker1 ~]# swarmd -d /tmp/docker1 --listen-control-api /tmp/manager1/swarm.sock --hostname docker1

Nos demais nós, execute:

[root@docker2 ~]# swarmd -d /tmp/node-2 --hostname docker2 --join-addr 10.1.1.1:4242
[root@docker3 ~]# swarmd -d /tmp/node-3 --hostname docker3 --join-addr 10.1.1.1:4242

Você pode agora, utilizar outro host para administrar o cluster, no nosso exemplo utilizando o docker4, veja:

[root@docker4 ~]# export SWARM_SOCKET=/tmp/manager1/swarm.sock
[root@docker4 ~]# swarmctl node ls
ID             Name    Membership  Status  Availability  Manager status
--             ----    ----------  ------  ------------  --------------
6rj5b1zx4makm  docker1  ACCEPTED    READY   ACTIVE        REACHABLE *
91c04eb0s86k8  docker2  ACCEPTED    READY   ACTIVE        
nf6xx9hpf3s39  docker3  ACCEPTED    READY   ACTIVE

Criando os serviços

Vamos começar devagar, veja como subir um ambiente em redis:

[root@docker4 ~]# swarmctl service create --name redis --image redis:3.0.5
6umyydpxwtzfs3ksgz0e

Listando os serviços:

[root@docker4 ~]# swarmctl service ls
ID                         Name   Image        Replicas
--                         ----   -----        ---------
6umyydpxwtzfs3ksgz0e      redis  redis:3.0.5  1

Inspecionando o serviço:

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicass         : 1
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
6umyydpxwtzfs3ksgz0e         redis      1           redis:3.0.5    RUNNING          RUNNING Up About an hour    docker1

Atualizando serviço:

Conforme mencionado anteriormente, podemos atualizar o status de um serviço, no nosso exemplo vamos aumentar o número de replicas dele, veja:

[root@docker4 ~]# swarmctl service update redis --replicas 6
6umyydpxwtzfs3ksgz0e

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.5    RUNNING          RUNNING Up About an hour     docker1
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker2
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker1
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker3
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker3

Vamos atualizar a imagem do serviço?

[root@docker4 ~]# swarmctl service update redis --image redis:3.0.6
6umyydpxwtzfs3ksgz0e

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.6

Task ID                      Service    Instance    Image          Desired State    Last State                Node
-------                      -------    --------    -----          -------------    ----------                ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.6    RUNNING          RUNNING 5 seconds ago    docker3
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker1
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.6    RUNNING          RUNNING 5 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker1
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker2
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker3

Por padrão todos os containers foram atualizados de uma única vez, isso tem suas vantagens e desvantagens, mas como explicado, você pode mudar essa execução para fazer em partes, veja:

[root@docker4 ~]# swarmctl service update redis --image redis:3.0.7 --update-parallelism 3 --update-delay 20s

Com isso, serão refeitos 3 containers por vez e entre eles terá um intervalo de 20 segundos.

Gerenciando nós

O Swarmkit monitora a saúde de cluster, e baseado nisso toma ações em cima dos serviços, você pode realizar ações manuais também, como por exemplo, retirar um nós do cluster, veja:

[root@docker4 ~]# swarmctl node drain docker1

[root@docker4 ~]# swarmctl node ls
ID             Name    Membership  Status  Availability  Manager status
--             ----    ----------  ------  ------------  --------------
6rj5b1zx4makm  docker1  ACCEPTED    READY   DRAIN         REACHABLE
91c04eb0s86k8  docker2  ACCEPTED    READY   ACTIVE        REACHABLE *
nf6xx9hpf3s39  docker3  ACCEPTED    READY   ACTIVE        REACHABLE

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.7

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.7    RUNNING          RUNNING 2 minute ago     docker2
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.7    RUNNING          RUNNING 2 minute ago     docker3
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.7    RUNNING          RUNNING 30 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.7    RUNNING          RUNNING 34 seconds ago    docker3
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.7    RUNNING          RUNNING 28 minutes ago    docker2
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.7    RUNNING          RUNNING 29 seconds ago    docker3

O Swarmkit é uma ferramenta em desenvolvimento ainda, mas você pode utilizar ela em seus labs e entender um pouco melhor como pode trabalhar em cluster com Docker. Espero que tenham gostado, e nos ajude divulgando o blog 😉

Abraço!

Kubernetes parte I

12 Comments

Olá pessoal,

Hoje vamos iniciar uma série de posts demonstrado como podemos utilizar o Kubernetes como ferramenta de automatização, distribuição de carga, monitoramento e orquestração entre containers.

Kubernetes é um sistema de código aberto que foi desenvolvido pelo Google para gerenciamento de aplicativos em containers através de múltiplos hosts de um cluster. Tem como principal objetivo facilitar a implantação de aplicativos baseados em microservices. Ele foi baseado na experiência do Google de muitos anos trabalho com containers, adaptando o  para se trabalhar com Docker.

O Kubernetes foi muito útil para ser utilizado até o Docker Swarm 1.0, pois disponibilizava muitos recursos que o Docker não disponibilizava até aquele momento, entre eles: Balanceamento de carga e movimento de containers sem perda de dados.

A principal vantagem que se tem ao utilizar o Kubernetes é que você não está preso as limitações da API do Docker (O Problema do Swarm) você tem total liberdade já que o Kubernetes não foi desenvolvido especialmente para o Docker, você pode trocar a sua estrutura de Docker para Rockets (Containers no CoreOS). Você pode escolher a simplicidade do Swarm ou o poder do Kubernetes.

Dentro do Kubernetes possuímos alguns termos para determinadas funções:

Minions: É o nome dado para cada host do cluster.

Kubelet: Agente que roda nos hosts do cluster.

Pods: É a menor unidade dentro de um cluster, nada mais é do que containers rodando dentro de seu cluster de Kubernetes. Pode ser um container rodando nginx, php, apache, etc…

Replication Controller: É o responsável por manter um número determinado de pods em execução. No RC é onde você diz quantos containers de nginx, php, apache você desejá que fiquem rodando, caso um caia, o RC cria outra instância automaticamente.

Services: É o responsável por atrelar uma faixa de IP para um determinado RC. Para que cada vez que o RC crie uma nova instância de pod o mesmo inicie com um IP determinado pelo service.

Namespace: Com o namespace você pode dividir seu Cluster de Kubernetes em dois ambientes, Produção e Teste, podendo limitar os recursos computacionais para ambos.

No proximo post vamos mostrar como podemos instalar e configurar o kubernetes para que você use em seu ambiente da melhor maneira possível.

Docker Universal Control Plane – Parte 1

1 Comment

Oi Pessoal,

Depois de um tempo nas postagens, hoje vamos iniciar os trabalhos aqui no https://www.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!

Portando aplicação para Docker

5 Comments

Oi Pessoal,

Para você que acompanha nosso blog, o www.mundodocker.com.br, hoje vamos mostrar um pouco mais de prática no Docker, vamos colocar em containers algumas aplicações e ver como é fácil ter seu ambiente totalmente portável. Para você que está começando com Docker, esse post será útil para entender e aprender como você pode começar, em casa mesmo, a mexer com Docker e fazer deploy de aplicações com ele. Já você que conhece Docker e já utiliza ele em seu ambiente, terá a oportunidade de pegar algumas dicas de como pode melhorar seu processo de deploy e criação de imagens.

Vamos lá:

 NodeJS

Vamos montar primeiro uma imagem de nossa aplicação, neste exemplo vamos utilizar o Framework Express do node. Primeiro crie um pasta, neste caso chamamos de app:

mkdir app

Crie dentro dessa pasta dois arquivos, package.json:

{
 "name": "app-node-mundodocker",
 "private": true,
 "version": "0.0.1",
 "description": "Teste App Node em Docker",
 "author": "MundoDocker <[email protected]>",
 "dependencies": {
 "express": "3.2.4"
 }
}

E index.js:

var express = require('express');

// Constants
var PORT = 8080;

// App
var app = express();
app.get('/', function (req, res) {
 res.send('Minha App Node\n');
});

app.listen(PORT);
console.log('Running on http://localhost:' + PORT);

Em seguida crie o arquivo Dockerfile:

FROM centos:centos6

# Habilita o repositório epel no CentOS
RUN yum install -y epel-release
# Instala o node e o npm
RUN yum install -y nodejs npm

# Instala as dependências 
COPY package.json /src/package.json
RUN cd /src; npm install

# Copia a app para a pasta src do container
COPY . /src

EXPOSE 8080
CMD ["node", "/src/index.js"]

Agora vamos criar a imagem:

docker build -t mundodocker/app-node-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -p 9090:8080 -d mundodocker/app-node-mundodocker

Se você acessar: http://seuip:9090 deve aparecer uma página como essa:

NodeApp

Rails

Agora vamos montar uma imagem utilizando uma aplicação em rails, primeiro vamos criar a pasta onde em seguida coloque nela os arquivos da aplicação e crie o Dockerfile:

FROM ruby:latest 
ENV HOME /home/rails/webapp 

# Instala as dependencias
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 
WORKDIR $HOME 

# Instala as gems necessárias
ADD Gemfile* $HOME/ 
RUN bundle install 

# Adiciona os arquivos a pasta home 
ADD . $HOME 

# Executa o comando
CMD ["rails", "server", "--binding", "0.0.0.0”]

Vamos criar a imagem:

docker build -t mundodocker/app-rails-mundodocker .

Agora só criar o container e testar:

docker run -p 3000:3000 -d mundodocker/app-rails-mundodocker

Acesse http://seuip:3000 e você deverá ter um retorno desses:

RailsApp

Python

Para uma aplicação python vamos criar uma pasta chamado app e dentro dela criar um arquivo chamado app.py:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
 return 'Minha App em Python!\n'

if __name__ == "__main__":
 app.run(host="0.0.0.0", debug=True)

E também um Dockerfile:

FROM orchardup/python:2.7
RUN pip install Flask
ADD . /code
WORKDIR /code
CMD python app.py

Em seguida vamos gerar uma imagem desse ambiente:

docker build -t mundodocker/app-python-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -d -p 5000:5000 mundodocker/app-python-mundodocker

Se você acessar: http://seuip:5000 deve aparecer uma página como essa:

PythonApp

Baseado nesses exemplos você pode ir modificando e acrescentando o que for necessário para sua aplicação, não esquecendo que você pode criar links entre as aplicações, trazendo maior facilidade e segurança para seu ambiente.

Gostou? Nos ajude divulgando o Blog, grande Abraço!