Migrando do Docker Swarm para o Kubernetes

Post incialmente públicado em: https://dumpscerebrais.com/2019/01/migrando-do-docker-swarm-para-o-kubernetes

Começamos 2019 e ficou bem claro que o Docker Swarm perdeu para o Kubernetes na guerra de orquestradores de contêineres.

Não vamos discutir aqui motivos, menos ainda se um é melhor que outro. Cada um tem um cenário ótimo para ser empregado como já disse em algumas das minhas palestras sobre o assunto. Mas de uma maneira geral se considerarmos o requisito evolução e compararmos as duas plataformas então digo que se for construir e manter um cluster de contêineres é melhor já começarmos esse cluster usando Kubernetes.

O real objetivo desse artigo é mostrar uma das possíveis abordagens para que nossas aplicações hoje rodando num cluster Docker Swarm, definidas e configuradas usando o arquivo docker-compose.yml possam ser entregues também em um cluster Kubernetes.

Intro

Já é meio comum a comparação entre ambos e posso até vir a escrever algo por aqui mas no momento vamos nos ater a um detalhe simples: cada orquestrador de contêineres cria recursos próprios para garantir uma aplicação rodando. E apesar de em alguns orquestradores recursos terem o mesmo nome, como o Services do Docker Swarm e o Services do Kubernetes eles geralmente fazem coisas diferente, vem de conceitos diferentes, são responsáveis por entidades diferentes e tem objetivos diferentes.

O Kompose, uma alternativa

O kompose é uma ferramenta que ajuda muito a converter arquivos que descrevem recursos do Docker em arquivos que descrevem recursos do Kubernetes e até dá para utilizar diretamente os arquivos do Docker Compose para gerir recursos no Kubernetes. Também tenho vontade de escrever sobre ele, talvez em breve, já que neste artigo vou focar em como ter recursos do Docker Swarm e do Kubernetes juntos.

Um pouco de história

Sempre gosto de passar o contexto para as pessoas entenderem como, quando e onde foram feitas as coisas, assim podemos compreender as decisões antes de pré-julgarmos.

Na Dockercon européia de 2017, a primeira sem o fundador Solomon Hykes, foi anunciado e demostrado como usar um arquivo docker-compose.yml para rodar aplicações tanto num cluster Docker Swarm quanto num cluster Kubernetes usando a diretiva Stacks.

A demostração tanto na Dockercon quanto no vídeo acima foram sensacionais. Ver que com o mesmo comando poderíamos criar recursos tanto no Docker Swarm quanto no Kubernetes foi um marco na época. O comando na época:

docker stack deploy --compose-file=docker-compose.yml stackname

Só tinha um problema, isso funcionava apenas em instalações do Docker Enterprise Edition ($$$) ou nas novas versões do Docker for Desktop que eram disponíveis apenas para OSX e Windows.

Aí você pergunta: Como ficaram os usuário de Linux nessa história, Wsilva?

Putos, eu diria.

Protecionismo?

Assim como outros também tentei fazer uma engenharia reversa e vi que o bootstrap desse Kubernetes rodando dentro do Docker for Mac e Windows era configurado usando o Kubeadm. Fucei, criei os arquivos para subir os recursos Kubernetes necessários e quase consegui fazer rodar mas ainda me faltava descobrir como executar o binário responsável por extender a api do Kubernetes com os parâmetros certos durante a configuração de um novo cluster, todas as vezes que rodei tive problemas diferentes.

Até postei um tweet a respeito marcando a Docker Inc mas a resposta que tive foi a que esperava: a Docker não tem planos para colocar suporte ao Compose no Linux, somente Docker for Desktop e Enterprise Edition.

Ainda bem antes de tentar fazer isso na mão, lá na Dockercon de 2018 (provavelmente também escreverei sobre ela) tive a oportunidade de ver algumas palestras sobre extender a API do Kubernetes, sobre como usaram Custom Resource Definition na época para fazer a mágica de interfacear o comando docker stack antes de mandar a carga para a API do Kubernetes ou para a API do Docker Swarm e também conversei com algumas pessoas no conference a respeito.

A desculpa na época para não termos isso no Docker CE no Linux era uma questão técnica, a implementação dependeria muito de como o Kubernetes foi instalado por isso que no Docker para Desktop e no Docker Enterprise, ambientes controlados, essa bruxaria era possível, mas nas diversas distribuíções combinadas com as diversas maneiras de criar um cluster Kubernetes seria impossível prever e fazer um bootstrap comum a todos.

Docker ainda pensando no Open Source?

Na Dockercon européia de 2018, praticamente um ano depois do lançamento do Kubernetes junto com o Swarm finalmente foi liberado como fazer a API do Compose funcionar em qualquer instalação de Kubernetes. Mesmo sem as instruções de uso ainda mas já com os fontes do instalador disponíveis (https://github.com/docker/compose-on-kubernetes) era possível ver que a estrutura tinha mudado de Custom Resource Definition para uma API agregada e relativamente fácil de rodar em qualquer cluster Kubernetes como veremos a seguir.

Mão na massa.

Para rodarmos essa API do Compose no Mac e no Windows, assim como no final de 2017, basta habilitar a opção Kubernetes na configuração conforme a figura e toda a mágica vai acontecer.

No Linux podemos trabalhar com o Docker Enterprise Edition ou com o Docker Community Edition.

Para funcinar com o Docker Community Edition primeiramente precisamos de um cluster pronto rodando kubernetes e podemos fazer teoricamente em qualquer tipo de cluster. Desde clusters criados para produção com Kops – (esse testei na AWS e funcionou), ou Kubespray, ou em clusteres locais como esse que criei para fins educativos: https://github.com/wsilva/kubernetes-vagrant/ (também funcionou), ou Minikube (também funcionou, está no final do post), ou até no saudoso play with kubernetes (também funcionou) criado pelo nosso amigo argentino Marcos Nils.

Para verificar se nosso cluster já não está rodando podemos checar os endpoints disponíveis filtrando pela palavra compose:

$ kubectl api-versions | grep compose

Pré requisitos

Para instalar a api do Compose em um cluster Kubernetes precisamos do etcd operator rodando e existem maneiras de instalar com e sem suporte a SSL. Mais informações podem ser obtidas nesse repositório.

Neste exemplo vamos utilizar o gerenciador de pacotes Helm para instalar o etcd operator.

Instalação

Primeiro criamos o namespace compose em nosso Kubernetes:

$ kubectl create namespace compose

Em seguida instalmos ou atualizamos o Helm.

Se estivermos utilizando OSX, podemos instalar de maneira simples com homebrew.

$ brew install kubernetes-helm
Updating Homebrew...
Error: kubernetes-helm 2.11.0 is already installed
To upgrade to 2.12.3, run `brew upgrade kubernetes-helm`
$ brew upgrade kubernetes-helm
Updating Homebrew...
==> Upgrading 1 outdated package:
kubernetes-helm 2.11.0 -> 2.12.3
==> Upgrading kubernetes-helm
==> Downloading https://homebrew.bintray.com/bottles/kubernetes-helm-2.12.3.moja
######################################################################## 100.0%
==> Pouring kubernetes-helm-2.12.3.mojave.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d

zsh completions have been installed to:
/usr/local/share/zsh/site-functions
==> Summary
🍺  /usr/local/Cellar/kubernetes-helm/2.12.3: 51 files, 79.5MB

No Linux podemos optar por gerenciadores de pacotes ou instalar manualmente baixando o pacote e colocando em algum diretório do PATH:

$ curl -sSL https://storage.googleapis.com/kubernetes-helm/helm-v2.12.1-linux-amd64.tar.gz -o helm-v2.12.1-linux-amd64.tar.gz

$ tar -zxvf helm-v2.12.1-linux-amd64.tar.gz
x linux-amd64/
x linux-amd64/tiller
x linux-amd64/helm
x linux-amd64/LICENSE
x linux-amd64/README.md

$ cp linux-amd64/tiller /usr/local/bin/tiller
$ cp linux-amd64/helm /usr/local/bin/helm

Estamos em 2019 então todos os clusters Kubernetes já deveriam estar rodando com RBAC (Role Base Access Control) por questões de segurança. Para isso devemos criar uma Service Account em nosso cluster para o tiller.

$ kubectl --namespace=kube-system create serviceaccount tiller
serviceaccount/tiller created

$ kubectl --namespace=kube-system \
    create clusterrolebinding tiller \
    --clusterrole=cluster-admin \
    --serviceaccount=kube-system:tiller 
clusterrolebinding.rbac.authorization.k8s.io/tiller created

Neste exemplo fizemos o bind para o role cluster admin, mas seria interessante criar uma role com permissões mais restritas definindo melhor o que o helm pode ou não fazer em nosso cluster Kubernetes.

Instalamos o etcd operator:

$ helm init --service-account tiller --upgrade
$ helm install --name etcd-operator \
    stable/etcd-operator \
    --namespace compose

Monitoramos até os pods responsáveis pelo etcd operator estarem de pé:

$ watch kubectl get pod --namespace compose

Com etcd operator de pé podemos matar o watch loop com ctrl+c.

Próximo passo vai ser subir um cluster etcd usando o operator:

$ cat > compose-etcd.yaml <<EOF
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
name: "compose-etcd"
namespace: "compose"
spec:
size: 3
version: "3.2.13"
EOF

$ kubectl apply -f compose-etcd.yaml

Monitoramos novamente até os pods responsáveis pelo nosso etcd cluster estarem de pé:

$ watch kubectl get pod --namespace compose

Com etcd cluster rodando podemos matar o watch loop com ctrl+c.

Em seguida baixamos diretamente do GitHub e executamos o instalador da API do Compose.

Se estivermos utilizando OSX:

$ curl -sSLO https://github.com/docker/compose-on-kubernetes/releases/download/v0.4.18/installer-darwin
chmod +x installer-darwin
./installer-darwin \
    -namespace=compose \
    -etcd-servers=http://compose-etcd-client:2379 \
    -tag=v0.4.18

No Linux:

$ curl -sSLO https://github.com/docker/compose-on-kubernetes/releases/download/v0.4.18/installer-linux
chmod +x installer-linux
./installer-linux \
    -namespace=compose \
    -etcd-servers=http://compose-etcd-client:2379 \
    -tag=v0.4.18

Vamos checar se os pods estão rodando novamente com watch loop:

watch kubectl get pod --namespace compose 

Após todos os pods rodando usamos o ctrl+c para parar o watch loop e em seguida podemos verificar se agora temos os endpoints do compose:

$ kubectl api-versions | grep compose
compose.docker.com/v1beta1
compose.docker.com/v1beta2

Sucesso. Agora vamos baixar um arquivo docker compose de exemplo do repositório da própria Docker:

curl -sSLO https://github.com/docker/compose-on-kubernetes/blob/master/samples/docker-compose.yml

Para ver o conteudo do arquivo podemos usar um editor de texto ou o simples cat docker-compose.yml no terminal mesmo.

Agora vamos usar o docker para criar os recursos no kubernetes, como se estivessemos fazendo um deployment em um cluster de Docker Swarm mesmo:

$ docker stack deploy \
    --orchestrator=kubernetes \
    --compose-file docker-compose.yml \
    minha-stack

Podemos usar tando o kubectl como o docker cli para checar os status:

$ kubectl get stacks  
NAME        SERVICES  PORTS    STATUS                        CREATED AT
demo-stack  3         web: 80  Available (Stack is started)  2019-01-28T20:47:38Z

$ docker stack ls \
    --orchestrator=kubernetes
NAME           SERVICES      ORCHESTRATOR      NAMESPACE
demo-stack     3             Kubernetes        default

Podemos pegar o ip da máquina virtual rodando minikube com o comando minikube ip e a porta do serviço web-published e acessar no nosso navegador.

No próprio repositório temos uma matriz de compatibilidade entre as funcionalidades no Docker Swarm e funcionalidades no Kubernetes: https://github.com/docker/compose-on-kubernetes/blob/master/docs/compatibility.md

Conclusão

Se você está pensando em migrar seus workloads de clusters de Docker Swarm para clusters de Kubernetes você pode optar tanto pelo Kompose quanto pelo Docker Compose no Kubernetes.

Optando pelo Compose no Kubernetes podemos usar o Docker for Mac ou Docker for Windows, basta habilitar nas configurações a opção de cluster Kubernetes.

Se estiver no Linux pode optar por seguir os passos acima ou pagar pelo Docker Enterprise Edition.

Veja como cada uma dessas opções se adequa melhor aos seus processos e divirta-se.

Até a próxima.

Kubernetes – ConfigMap

Fala pessoal, estamos aqui novamente para continuar nossa série que fala sobre Kubernetes. Abaixo coloquei a lista de posts criados até o momento referente a Kubernetes, então se não tinha visto o ínicio é só clicar abaixo e ler cada um dos posts.

Conceitos de Kubernetes

Instalação e Configuração

Iniciando um servidor web

Entendendo Pods

Entendendo Services

Entendendo Namespaces

 

Então, o que é ConfigMap? É o desacoplamento dos artefatos de configuração do conteúdo da imagem para manter os aplicativos contidos em container. De forma simples podemos dizer que ConfigMap é um conjunto de pares de chave-valor para armazenamento de configurações, que ficará armazenado dentro de arquivos  que podem ser consumidos através de Pods ou Controllers,. Ele é muito parecido com Secrets, mas fornece um modo de se trabalhar com strings que não possuem dados confidências, como senhas, Chaves, Tokens e outros dados sigilosos.

Os arquivos de ConfigMap, podem ser tanto arquivos complexos que possuem poucas regras, como também arquivos no formato JSON complexos e cheio de regras. Podemos ver alguns exemplos abaixo de ConfigMaps tanto simples quanto complexos:
Podemos ver aqui um exemplo de criação de um ConfigMap através do client do Kubernetes “kubectl”

kubectl create configmap site --from-literal='url=mundodocker.com.br' Podemos ver 

Podemos ver aqui um outro exemplo que é um arquivo de configuração que a partir dele também podemos criar o nosso ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mundodocker
  labels:
    name: mundodocker
  namespace: test
data:
  config: |-
    ---
    :url: mundodocker.com.br

Como foi visto acima existe 2 formas nas quais podemos criar o nosso ConfigMap, mas ahhh Bicca, como integramos isso com nosso Pod? Existem algumas formas para isso a primeira é que você pode colocar isso dentro do arquivo de criação do Pod, como mostro abaixo:


apiVersion: v1
kind: Pod
metadata:
  name: mundodocker
spec:
  containers:      
  - image: gcr.io/google_containers/busybox      
    name: container
    volumeMounts:
    - name: configmap
      mountPath: "/tmp"
  volumes:
  - name: configmap
    condigMap:
      name: site

 

Essa seria a forma de criação de um Pod com ConfigMap habilitado por exemplo, esses são exemplos simples de arquivos que mostram como funciona o uso de ConfigMaps.

ALGUMAS DICAS:

  • Lembre-se que para que seja possível criar o seu Pod com ConfigMap, você precisa primeiro criar o ConfigMap ou coloca-lo como opcional, pois caso contrario o Pod não irá ser iniciado por causa que o ConfigMap ainda não foi criado.
  • ConfigMap estão dentro de Namespaces, então apenas Pods do mesmo Namespace podem acessa-los
  • Podem ser consumidos de 3 formas: Argumentos, Variaveis de ambiente e Arquivos em volumes. Essa quantidade de modos faz com que ConfigMap se enquadre em grandes partes das aplicações.

 

Pessoal, vamos continuar criando posts para explicar alguns componentes do Kubernetes e em breve vamos colocar mais conteúdos para demonstrar como é possível utilizar Kubernetes em produção com exemplos de uso no dia-a-dia, fique ligado que em breve estaremos com muitas novidades em nosso site e também.

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!

 

MundoDocker – Eventos

Oi Pessoal,

Hoje o post é rápido, apenas para trazer a vocês nossa experiência no TcheLinux Caxias do Sul. Para quem nos acompanha nas rede sociais, ficou sabendo que iriamos participar de mais um edição do TcheLinux (um dos maiores eventos de tecnologia open source do Rio Grande do Sul), dessa vez em Caxias do Sul, na serra gaúcha.
O evento estava muito bem organizado, e o lugar não poderia ser melhor, com infraestrutura suficiente para atender os participantes, sem falar na localização. Com a ajuda de alguns amigos, conseguimos alguns registro fotográficos do evento, veja:

A nossa contribuição ao evento foi com uma palestra: Escalonando o mundo com Kubernetes, como o Google sobrevive. Essa apresentação teve como objetivo mostrar aos presentes como o Kubernetes funciona, como ele é utilizado dentro do Google e como você utiliza ele sem nem saber 🙂 . Compartilhamos a apresentação em nosso Slideshare, para você, que não estava no evento, possa ver um pouco sobre o que levamos ao evento:

http://www.slideshare.net/MundoDocker/escalonando-o-mundo-com-kubernetes

Gostaríamos de agradecer ao TcheLinux pela oportunidade e a Ftec que disponibilizou o local para o evento. Por hoje era isso, grande abraço! Ahhh e nos ajude divulgando o blog 😉

SwarmKit

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:

[[email protected] ~]# go get github.com/docker/swarmkit/

Acesse o diretório, e execute:

[[email protected] ~]# make binaries

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

[[email protected] ~]# make setup
[[email protected] ~]# 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:

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

Nos demais nós, execute:

[[email protected] ~]# swarmd -d /tmp/node-2 --hostname docker2 --join-addr 10.1.1.1:4242
[[email protected] ~]# 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:

[[email protected] ~]# export SWARM_SOCKET=/tmp/manager1/swarm.sock
[[email protected] ~]# 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:

[[email protected] ~]# swarmctl service create --name redis --image redis:3.0.5
6umyydpxwtzfs3ksgz0e

Listando os serviços:

[[email protected] ~]# swarmctl service ls
ID                         Name   Image        Replicas
--                         ----   -----        ---------
6umyydpxwtzfs3ksgz0e      redis  redis:3.0.5  1

Inspecionando o serviço:

[[email protected] ~]# 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:

[[email protected] ~]# swarmctl service update redis --replicas 6
6umyydpxwtzfs3ksgz0e

[[email protected] ~]# 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?

[[email protected] ~]# swarmctl service update redis --image redis:3.0.6
6umyydpxwtzfs3ksgz0e

[[email protected] ~]# 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:

[[email protected] ~]# 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:

[[email protected] ~]# swarmctl node drain docker1

[[email protected] ~]# 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

[[email protected] ~]# 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!

ProjectAtomic.io

Olá pessoal,

Com o passar dos anos as tecnologias vem evoluindo cada vez mais rápido, surgem novos conceitos porém muitos morrem e poucos acabam se tornando tendência. No passado muito se falou sobre “Máquinas Virtuais” muitas empresas apareceram no mercado de virtualização porém apenas algumas se destacaram que é o caso de Microsoft, VMWare e Oracle.

Agora chega a hora da tendência de containers (Sim, LXC existe há um grande tempo já) que cada vez mais vem se popularizando e com isso surgem diversas empresas no mercado oferecendo integrações, plataformas, contentores e entre outros produtos. Com essa gama de ofertas decidi realizar uma série mostrando as empresas que acreditamos que serão as grandes donas do mercado de containers nos próximos anos.

O ProjectAtomic: É um sistema operacional desenvolvido pela RedHat, foi projetado para a execução de aplicações em containers docker. O Project Atomic depende de vários projetos de código aberto as várias distribuições Linux específicas. A comunidade Atomic vai trabalhar para o desenvolvimento do projeto atômico de forma inclusiva, contribuindo para os projetos upstream relacionados, resolvendo problemas de integração nas diversas distribuições sendo usado e desenvolver as ferramentas de gestão específicas necessárias para atualizações de gestão e de sistema. As principais ferramentas utilizadas foram:

– Docker – Implementação dos aplicativos

– Kubernetes – Orquestração

– rpm-ostree – Atualizações

– systemd – Gerencia de serviços

O Project Atomic possui uma ferramenta Web chamada Cockpit para realizar o gerenciamento de containers e hosts, com o Cockpit você pode:

– Visualizar os recursos utilizado pelos containers.

– Limitar recursos dos containers.

– Iniciar, parar, salvar e realizar o commit dos containers.

– Executar e excluir imagens.

– Administrar o host.

– Configurar serviços no host e outras funcionalidades.
cockpit-screenshot

Exemplo de imagem do Cockpit

Aqui possui o link para o download da imagem do sistema operacional http://www.projectatomic.io/download/

Por hoje era isso, espero que tenham gostado e tendo dúvidas nos avisem, e claro ajudem divulgando o https://mundodocker.com.br

Abraço!

Kubernete parte III

Olá pessoal,

 

Depois de algum tempo sem falar sobre Kubernetes hoje vamos mostrar como podemos criar um ambiente altamente disponível de servidores web.

Conforme comentado nos posts anteriores, podemos criar um service Web e dentro desse service eu posso ter milhões de containers, onde o Kubernetes fará toda a parte de Balanceamento de carga com o que chamamos de Replication Controller.

Vamos criar então o Replication Controller:

 

vim web-rc.yml

apiVersion: v1
kind: ReplicationController 
metadata:
 name: web-controller
spec:
 replicas: 2
 selector:
   name: nginx
 template:
   metadata:
     labels:
       name: nginx
   spec:
     containers:
       - name: nginx
         image: nginx
         ports:
           - containerPort: 80

kind: É o tipo de objeto que o Kubernetes ira criar, nesse caso ele vai criar

Replicas: Quantos pods dessa imagem sempre deve existir, caso exista um número menor que o indicado, o Kubernetes irá criar outros pods até chegar ao número determinado em replicas.

 

Para criar o Replication Controller execute:

kubectl create -f web-rc.yml

 

Você poderá ver RC criado com o comando:

kubectl get replicationcontrollers

 

Agora vamos criar o Service que é aquele que faz com que o usuário consiga criar a aplicação:

 

vim web-service.yml

kind: Service
apiVersion: v1
metadata:
  name: web-service
spec:
  selector:
    name: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
kubectl create -f web-service.yml

Feito isso você pode executar o comando abaixo e verá que existe 2 pods de Nginx rodand:

kubectl get pods

Com tudo isso pronto você pode pegar e testar executando um curl no ip do seu servidor, no meu caso estou executando a partir do minion1, então vou acessar o minion2 e executar:

curl -qa http://seuip

E a página inicial do nginx será mostrada, você pode pegar e parar um pod e notará que o Kubernetes irá criar outro, pois no Replication Controller colocamos como 2 replicas.

Então tá pessoal por hoje era só, continue ligado em nosso canal e em breve estaremos fazendo um vídeo mostrando mais sobre o Kubernetes.

Aguarde...

Inscreva-se em nossa newsletter

E fique por dentro das novidades.