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.

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.

NodeJS com Docker na Umbler

Eai pessoal, blz?

O post hoje será um pouco diferente, queremos trazer para vocês como a Umbler desenvolveu sua plataforma de NodeJS utilizando Docker. SIM, falaremos sobre o que deu certo e, claro, o que deu errado nesse caminho. O intuito é mostrar mais um case de sucesso e tudo que foi preciso para isso :).

A Umbler  já utiliza Docker há alguns anos (obviamente para aplicações/serviços internos) e isso ajudou no desenvolvimento de sua plataforma NodeJs. Mas até chegar à experiência ideal levou tempo, pesquisa, testes, prototipação e muita paciência.

Abaixo compartilhamos com vocês uma apresentação que foi realizada durante o Meetup de NodeJS em Porto Alegre no dia 11/07, onde mostramos aos participantes os detalhes dessa jornada:

Vamos detalhar o que foi apresentado.

Quem mesmo?

A Umbler é uma StartUp gaúcha de cloud hosting sob demanda, seu objetivo é facilitar cada vez mais a vida de quem cria a web, ou seja, as agências e desenvolvedores. Atualmente possui cerca de quarenta mil clientes e conta com setenta funcionários distribuídos pelo mundo.

O caminho até aqui

Como sempre, não existe uma solução mágica para todos os problemas, ou uma única solução infalível. Às vezes, temos que nos aventurar com o máximo de alternativas possíveis para ter certeza de que aquilo não nos atenderá ou, pelo menos, não nos atenderá naquele momento.

Foi assim que, depois de muito meses de testes e prototipação, foi possível observar algumas coisas e descobrir o porquê de algumas soluções não atenderem a demanda que a Umbler queria resolver. Entre as soluções testadas é possível destacar:

OpenShift

Plataforma pronta para criação de containers, baseada em Kubernetes. É uma plataforma que funciona muito bem, tem instalação relativamente fácil, possui gerenciamento centralizado e conta com integração com diversas outras ferramentas/soluções. Esta é uma ferramenta com muitos pontos positivos, pois atende aos mais variados problemas, mas que não se encaixou, até então, no que a Umbler precisava. Dos pontos negativos que se destacam são:Curva de aprendizagem: Openshift possui, além de kubernetes, uma série de outras soluções para que seja possível a criação e gerenciamento dos containers nela hospedado. Seu uso é simples e intuitivo, mas eventualmente algo daria manutenção, e aí estava um dos empecilhos. Além de saber tudo sobre Docker, Kubernetes, OpenVswitch, era obrigatório entender cada um dos demais componentes da plataforma, justamente para se antecipar a algum problema.

  • Restrições: Apesar de todas as facilidades, o OpenShift possui algumas restrições que, para as necessidades mapeadas, impossibilitaram o seu uso ou, pelo menos, gerariam mais demanda para adaptar a plataforma. O objetivo da Umbler é criar uma plataforma completa e fácil, com a menor quantidade de amarras possíveis, garantindo assim a melhor experiência dos usuários, infelizmente o Openshift tornaria isso mais complexo de ser realizado.
  • Inovação: Obviamente inovar é preciso, no mercado de tecnologia isso é além de bom, obrigatório, com as restrições que foram encontradas inovar utilizando o Openshift dependeria muito do que a plataforma teria a oferecer,  ou seja, a inovação do produto estaria presa a inovação da plataforma, restando pouco, ou quase nada de margem para adaptação.
  • Custo: Existem basicamente duas versões do Openshift, a Origin que é opensource e você pode utilizar para resolver seus desafios sozinho, e contar com o apoio da comunidade. Ou a versão enterprise, que garante suporte comercial à plataforma e atualizações dos softwares que a compõem. Independente da versão, o custo/benefício não compensava, pois mesmo com a versão opensource o tempo de resposta ou atualização para algo crítico era muito grande, tornando assim a versão “gratuita” não tão gratuita assim.

Kubernetes

Kubernetes é um orquestrador para containers totalmente opensource, e mantido por uma comunidade gigantesca. Tendo em vista o histórico de testes/prototipação com o Openshift, a segunda abordagem naturalmente seria algo mais voltado ao que já foi visto. Como a base do Openshift é Kubernetes, a ideia era utilizar o Kubernetes e adaptar o que fosse necessário para a plataforma. Simples não? Sim e não, vamos ver algumas restrições dele:

  • Curva de aprendizagem: Realmente, utilizando apenas o Kubernetes a quantidade de tecnologias que deveriam ser dominadas foi reduzida a apenas duas: Docker e Kubernetes. Mesmo assim, o tempo para aprender tudo e saber resolver tudo dessas tecnologias era elevado. Menor do que com Openshift, mas ainda assim algo que faria a plataforma levar mais tempo a ser finalizada.
  • Restrições: Depois de muita leitura, estudo e testes, foram encontradas ainda assim algumas restrições, a mais clássica delas é o Kubernetes não suportar as últimas versões do Docker, ou seja, sempre haveria um gap entre o que foi lançado de novidade pela engine do Docker e o que realmente está sendo utilizado.
  • Inovação: Como no caso da Openshift, o uso do Kubernetes resolveria diversos pontos da plataforma, mas ainda assim seria algo que poderia travar a inovação e adaptação da plataforma.

Docker Swarm

O Swarm é o método nativo de cluster na engine do Docker, a partir da versão 1.12 do Docker é possível utilizar esse recurso sem a necessidade de uma ferramenta ou solução de terceiros. Assim como no Kubernetes, com o Swarm é possível criar e gerenciar todos os serviços/containers do cluster. Com o Swarm foi possível resolver algumas das pendências das demais soluções, como por exemplo:

  • Curva de aprendizagem: Como já mencionado, a Umbler utiliza Docker há algum tempo, então já havia em casa mesmo o conhecimento prévio, bastando apenas a adaptação para o modo de cluster.
  • Custo: Existe a versão opensource e a versão enterprise do Docker, a grande diferença entre depender da comunidade Docker e comunidade Openshift é a velocidade na resolução de alguma issue ou até mesmo melhoria para a engine, isso facilita na tomada de decisão, sem contar no tamanho das comunidades 😉
  • Inovação: Ainda há uma amarra quanto a tecnologia, no entanto, com o Swarm é possível criar/modificar a plataforma na mesma velocidade da engine de containers.

Existe algo em que o Swarm não atendeu? Sim, obviamente, e isso é natural, visto que não existe solução mágica para tudo. No entanto, foi possível adaptar algumas outras soluções para que fosse possível mitigar ou até mesmo sanar esses casos.

Sim, foi um processo longo, às vezes demorado, mas que rendeu bons frutos, seja de nível técnico (com o incremento de conhecimento para a equipe), ou de negócio, pois foi necessário o entendimento de todos quanto a necessidade real dos usuários, e, claro, a moldagem das ideias para atender essas necessidades. Desafios que foram sendo resolvidos durante a caminhada, é possível destacar:

  • Isolamento: Sim, containers são isolados, mas para isolar o tráfego entre os serviços, como faz? Esse foi um dos pontos onde se investiu algum tempo para encontrar a melhor resposta.
  • Inovar de forma responsável: A cada três meses é lançada uma nova versão do Docker, atualiza-se o ambiente a cada três meses? Usa-se as features novas já de cara? Este também foi motivo para algumas horas de conversa.
  • Complexidade: Não é porque foi utilizada uma tecnologia base que o ambiente não seria complexo. Quanto mais features para a plataforma, maior a complexidade para se atender essa demanda.
  • Simplificar: Como simplificar então? Como deixar tudo fácil de ser entendido, e, principalmente, replicável?
  • Deploy: De que forma o usuário vai utilizar a plataforma, como deve ser o melhor fluxo para colocar uma aplicação no ar com Docker? Às vezes a resposta certa não é a óbvia 😉
  • Cobrança: Como quantificar o gasto de cada cliente, existe na “caixa” isso? Quanto cobrar, e mais importante, vamos cobrar?

Além de desafios, ficaram também diversos aprendizados, que não custa nada compartilhar, certo?

  • Pesquisa e Prototipação são fundamentais. Mesmo que tu saiba tudo na teoria, ás vezes um comportamento só é validado na prática, tentando fazer dar erro.
  • Perseverança é muito importante. Às vezes a solução mais fácil parecer ser a melhor, o que pode não se confirmar. Por isso é preciso cuidado, pois você estará fazendo algo não para você, e nem para seu colega, e sim para dezenas, centenas, milhares de pessoas. É nelas que você deve pensar.
  • Ouvir todos os interessados é fundamental. Seja seu cliente (aquele que já paga pelo serviço), seja seu usuário (aquele que apenas usa, mas não gasta), seja seu colega, seu chefe, e principalmente a comunidade, apenas ouça, processe, e aí sim pense em algo que faça sentido para todos.
  • Outro ponto interessante é separar o “que” precisa ser feito do “como” deve ser feito. Em alguns casos (muitos por sinal), quando recebemos um problema para resolver já saímos com a solução pronta, montada em nossa cabeça. Mas será que o problema é realmente o apresentado? Será que essa solução se encaixa realmente na resolução? Lembre-se: O que eu preciso fazer define como eu vou fazer, e não o contrário.
  • Admita, você não terá todas as respostas em uma única solução, isso é improvável. Mas você precisará estar aberto a isso, e, principalmente, você precisará saber lidar com isso.
  • Última, mas não menos importante dica: Entenda exatamente o que você está fazendo. Não apenas aceite e saia executando. Entenda! Isso fará o seu trabalho ter mais valor e você terá outra visão daquilo que está criando.

Esperamos que isso ajude vocês durante suas próprias jornadas. Para nós foi uma experiência bem divertida, além de enriquecedora, e é uma honra compartilhar com vocês, quer conhecer mais sobre o NodeJs na Umbler? Então acessa este link, tem tudo que você precisa saber 😉

Como sempre, se ficou com dúvidas ou quer entender melhor, nos avise, e nos ajude divulgando o blog \o/. 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.

Kubernetes – Namespaces

Fala galera, hoje vamos fazer mais um post referente a Kubernetes e vamos falar um pouco mais sobre Namespaces e como ele nos beneficia em nosso dia a dia. Para isso vamos entender um pouco mais o que é e como funciona o Namespace:

O Kubernetes diferente do Docker suporta com que a partir de um único cluster sejam criados diversos clusters virtuais dentro desse cluster e isso é chamado de Namespaces, possibilitando que seja possivel criar uma estrutura macro no qual futuramente possa ser dividia em vários namespaces. O Namespace foi projetado para suprir a demanda de equipes compostas pro diversos usuários e projetos nos quais cada equipe possui um ambiente diferente da outra equipe, fornecendo assim recursos dos quais facilitam muito o seu dia a dia como por exemplo a limitação de recursos que veremos mais a frente.

Para listar os namespaces atuais em um cluster de Kubernetes, basta executar

kubectl get namespaces

Por padrão já existem dois namespaces criados no Kubernetes são eles:

default: Onde todos os objetos que não possuem Namespace especificado são criados.

kube-system: Todos os objetos que o Kubernetes cria para gerenciar o cluster estão nesse Namespace.

Para criar um namespace você precisa criar um arquivo .yml como o abaixo:

apiVersion: v1
kind: Namespace
metadata:
  name: nomenamespace

kubectl -f arquivo.yml

Ou você também pode executar comando kubectl create namespace mundodocker

Quando o Kubernetes criar um serviço ele vai criar junto uma entrada DNS dentro do seu cluster e essa entrada DNS possui a seguinte nomeclatura: service-name.namespace-name.svc.cluster.local no qual pode ser utilizado pela sua aplicação para conectar em seu serviço, geralmente os Namespaces criados possuem nomeclaturas como: Produção, Homologação, Teste….

Para realizar a criação de um Pod dentro de um determinado Namespace é possível fazer executando:

kubectl --namespace=mundodocker run nginx --image=nginx


Limitação de recursos ou objetos.

Quando se utiliza um ambiente compartilhado, sempre existe uma preocupação com as questões de recursos, e dentro do Kubernetes existe a possibilidade de resolver isso utilizando “Resource Quota” que fornece uma limitação de recursos por Namespace, essa limitação pode ser desde limitação de Hardware (Memória,Cpu….) quanto há quantidade de objetis que podem ser criados por tipo dentro do Namespace. Quando o Kubernetes verifica se é possível criar um “Pod,Service,Replication Controller” dentro do Namespace, o Kubernetes verifica se existe alguma limitação de recursos no Namespace, caso exista o Kubernetes já notifica o usuário sobre não ser possível realizar a criação do componente desejado. Um exemplo de política de recursos que pode ser criado é o seguinte:

– Namespace Teste: Possui 20GB de memória e 20 Núcleos.
– Namespace Producao: Possui 40GB de memória e 20 Núcleos.

Porém se seu ambiente possuí um total de 50GB de memória, o Kubernetes irá alocar a memória o CPU para o componente que realizar o pedido primeiro, não tendo assim como colocar a prioridade para determinado Namespace. Além de fazer limitações de CPU e memória é possível também realizar a limitação de disco e também limitação de objetos.

Um exemplo de criação de “Resource quota” você pode ver abaixo:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: limitacao-recursos
spec:
  hard:
    pods: "10"
    limits.cpu: "10"
    limits.memory: 20Gi

Após criar o seu arquivo .yaml basta você executar kubectl create -f ./limitacao-recursos.yaml --namespace=teste e você terá criado o seu Resource Quota. Caso queira verificar se tudo ocorreu da forma certa, você pode executar kubectl get quota --namespace=teste e você irá visualizar o retorno bem parecido com esse:

NAME                    AGE
limitacao-recursos       5s

Também é possível verificar de uma forma mais detalhada sobre o seu Resource Quota utilizando kubectl describe quota limitacao-recursos --namespace=teste. Isso irá mostrar de forma detalhada como está configurado a sua quota.

Pessoal, nos próximos posts sobre Kubernetes vamos demonstrar na prática como é possível colocar algumas aplicações dentro do Kubernetes e como utilizamos os componentes mostrados até aqui na prática. Por hoje é isso, fique ligado em nossos próximos posts, um grande abraçõ e até a próxima.

 

 

 

 

 

 

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.

Kubernetes – Iniciando com services

Olá pessoal como foi mencionado nesse post https://www.mundodocker.com.br/iniciando-com-pods/  há algumas semanas atrás, vamos dar continuidade a nossa série sobre Kubernetes, na primeira etapa mostramos como realizar a instalação, configuração e como poderíamos iniciar nossos primeiros Pods(containers) e hoje vamos demonstrar como podemos abstrair os nossos Pods e trabalhar diretamente com Services.

Pods é o menor objeto que pode ser criado no Kubernetes, eles são processos mortais  sendo executados em um cluster. Eles nascem e morrem porém não são ressuscitados.  Quem pode fazer o papel de ficar criando e destruindo os Pods dinamicamente é o Replication Controller que é um objeto do Kubernetes que faz com que sempre existam x Pods dentro de um Cluster.

Cada Pod ao ser criado recebe um endereço IP, porém ao ser destruído e recriado esse endereço IP é alterado. Então se temos um conjunto de Pods chamados de Backend que dependem de acesso de um outro conjuntos de Pods por exemplo Frontend como o conjunto de Frontend pode saber quais os componentes do Backend?

É nesse caso que usamos services, que é uma abstração que define um conjunto de Pods e sua politica de acesso, geralmente esse conjunto de Pods é identificado através de um Label Selector. Como exemplo de uso de um service podemos dizer que temos 3 Pods de MongoDB nos quais temos um Frontend que realiza o acesso, com a criação de um service o Frontend não vai precisar associar a aplicação aos Pods e sim ao service então os Pods podem ser recriados a qualquer instante que o Frontend continuará funcionando devido ao service realizar toda a parte de gerenciamento dos Pods abstraindo isso para o Frontend.

Agora vamos poder visualizar qual seria uma construção básica do meu service, nesse caso estamos usando como exemplo um conjunto de Pods que espoem a porta 8500 e que possuem como Selector “MeuApp” :

kind: Service
apiVersion: v1
metadata:
name: meu-service
spec:
selector:
app: MeuApp
ports:
- protocol: TCP
port: 80
targetPort: 8500

Com Kubernetes é possivel querer expor o serviço a um IP externo para acesso de alguma aplicação ou algum cliente, então para esse caso existe “ServiceTypes” onde é possivel especificar o tipo de serviço desejado, por padrão o criado é o ClusterIP que faz com que o serviço seja exposto com um IP do cluster, tornando o acessível apenas através do cluster. Existem outros 3 tipos de serviços:

– NodePort: Expõe o serviço em cada IP do Nó em uma porta estática (o NodePort). Um serviço ClusterIP, ao qual o serviço NodePort encaminhará, é automaticamente criado. Você poderá entrar em contato com o serviço NodePort, de fora do cluster, solicitando : .

– LoadBalancer: Expõe o serviço externamente usando o balanceador de carga de um provedor de nuvem. Os serviços NodePort e ClusterIP, aos quais o balanceador de carga externo encaminhará, são criados automaticamente.

– ExternalName: Mapeia o serviço para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro CNAME com seu valor. Nenhum proxy de qualquer tipo é criado. Isso requer a versão 1.7 ou superior do kube-dns.

Caso você escolha o Type NodePort o Kubernetes irá definir por padrão uma porta entre (30000-32767) para expor em cada nó de proxy do Kubernetes. Caso você deseje especificar um número de porta é possivel utilizar a propriedade nodeport para escolher uma porta fixa, porem deve se ter cuidado para não colocar mais serviços na mesma porta, o que acarretará em um erro na hora de subir o serviço.

Então hoje podemos entender um pouco mais de como funciona o componente “Service” dentro do Kubernetes e nos próximos capítulos vamos trabalhar mais a questão prática com o deploy de algumas aplicações.

 

Obrigado e uma ótima semana a todos 😀

 

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.

Iniciando com Pods

Olá pessoal,

Hoje quero fugir um pouco do tema “Docker” e quero mostrar para vocês um pouco mais de “Kubernetes”. Em dois posts anteriores mostrei como era complicada a instalação e configuração do Kubernetes caso não quizesse usar AWS ou Google Cloud. Com a comunidade sempre mostrando o quanto a instalação do Kubernetes era sempre trabalhosa, a partir da versão 1.4 foi criado o utilitario “kubeadm” que é utilizado para realizar a instalação de um cluster de Kubernetes de maneira rápida e fácil possibilitando assim uma maneira fácil de instalação e assim aderiando mais pessoas utilizando a ferramenta.

 

Passo 1 – Vamos iniciar agora a instalação do Kubernetes em alguns passos simples e depois vamos realizar algumas operações básicas para que você possa conhecer mais sobre essa ferramenta tão poderosa.

apt-get update && apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat < /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

 
apt-get update
# Install docker if you don't have it already.
apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Passo 2 – Parecido com a sintaxe do comando para iniciar um cluster com o “docker swarm” com o comando abaixo vamos estar iniciando o cluster com Kubernetes. Caso tenha 2 placas de redes em seu servidor você poderá especificar qual deseja utilizar com --api-advertise-addresses <ip-address> passando como parâmetro para o comando kubeadm init

Na saída do comando será possível visualizar, no final a instrução para você adicionar um outro nó ao seu cluster, para isso basta você repetir o passo 1 em seu outro nó e colar a saída do comando acima onde mostra:

kubeadm join --token=<token> <master-ip>

Após realizar os passos acima você estará com seu cluster de kubernetes quase pronto, porém ainda para que você possa fazer funcionar o seu cluster perfeitamente, você ainda precisa que seja instalado um plugin de rede para que o cluster de Kubernetes esteja a funcionar 100% para isso basta você executar:

kubectl apply -f https://git.io/weave-kube

Nesse caso o plugin escolhido foi o do Weave. Agora pronto estamos com nosso cluster de Kubernetes no ar e podemos começar a realizar as operações básicas em um cluster. Para isso vamos iniciar trabalhando com Pods.

Se você não sabe ainda os principais componentes do Docker, então você pode acompanhar um outro post nosso que fala sobre isso aqui. Então vamos por a mão na massa:

Com o comando kubectl é possivel fazer todas as operações que precisamos que sejam feitas em caso de lidarmos com containers. Então para listarmos os Pods que temos criados podemos executar o comando:

kubectl get pods 

Isso irá trazer os pods que foram criados no Namespace default. Namespaces são clusters virtuais dentro de um cluster físico, então eu posso ter dezenas de Namespaces em 1 cluster de kubernetes e em cada Namespace ter diversos Pods nos quais possuem total isolamento entre eles. Com namespace então eu posso limitar recursos como: CPU, Memória, Disco e Rede. Para que eu liste todos os Pods criados em todos os namespaces basta eu executar:

kubectl get pods --all-namespaces 

Para criar um Pod com uma imagem do Node.Js por exemplo você utiliza:

kubectl run --image=ghost --port=2368

Estou utilizando a porta 2368, pois é a que está com o EXPOSE no Dockerfile. Também é possivel criar 1 Pod com n container no caso você deve utilizar o parâmetro --replicas

kubectl run node --image=ghost --replicas=5 --port=2368

Nesse caso será criado os cinco containers no Docker porém apenas 1 Pod estará visivel no Kubernetes. Agora para que possamos acessar a nossa aplicação através do Browser devemos expor a porta 2368 para alguma porta do Host, o mesmo conceito do Docker, porém sintaticamente de uma forma diferente. Para isso utilizamos o comando:

kubectl expose deployment node --target-port=2368 --type=LoadBalancer

Com o comando acima estamos dizendo para o Kubernetes pegar alguma porta livre no host e redirecionar o tráfego para a porta 2368 dentro do container e que o tipo de envio seja um LoadBalancer entre as replicas que eu mandei criar, então no caso das 5 réplicas que foram criadas acima, cada requisição será enviada para uma replica diferente da outra.


Mais para frente entraremos mais a fundo no Kubernetes, mas agora quando executamos o comando kubectl expose o Kubernetes criou um service de forma abstrata, podemos agora de forma resumida dizer que um service tem o papel de Habilitar um endpoint para que o usuário consiga acessar a aplicação". Então se você executar o comando:

kubectl get services

Você irá ver algo parecido com isso:


NAME         CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
node         10.100.162.143        2368:31529/TCP   10s

Então a porta para que possamos acessar nossa aplicação será a porta 31529


Conforme criamos os primeiros posts sobre como criar containers, imagens e coisas mais simples com Docker, começaremos a fazer também com o Kubernetes, então vamos evoluir cada vez mais o conteúdo para que possa ser útil tanto para as pessoas que estão pensando em começar a usar, como também as que estão usando a um certo tempo.


Obrigado e fique ligado, pois em breve estaremos lançando novidades para os nossos leitores que estão se cadastrando em nossas Newsletter.

Grande abraço!

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 EE e CE

Oi Pessoal!

No último dia 02 de março, o Docker anunciou uma grande mudança em sua plataforma, lançando oficialmente a versão enterprise da engine de containers mais utilizada atualmente. Mas o que muda? Responderemos isso e mais algumas outras dúvidas neste post!

Esse movimento adotado pelo Docker em, dividir, as versões da sua engine é algo já esperado pela comunidade, e para alguns veio até tarde. Mas por que isso agora? Por um motivo simples, produto. O Docker vem já algum tempo sendo desenvolvido como uma plataforma, agregando a cada nova release alguma correção que resolve um problema ou uma feature que melhora algum aspecto da engine.

Agora temos claro as linhas de trabalho do Docker, e como serão realizadas as atualizações na plataforma. As entregas de novas features, correção de bug, etc, seguiram a mesma linha adotada por outras empresas, ou seja, correção de bug e fix mais frequentes do que novas features, com isso a comunidade não precisará aguardar tanto tempo para ter uma correção já na engine.

Para ficar mais claro, dá uma olhada nessa imagem:

Docker Enterprise Edition

Fonte: https://blog.docker.com/2017/03/docker-enterprise-edition

Como você pode notar, as entregas para a versão community serão mais frequentes, e serão baseadas em correções e fix, tendo uma cadência mensal. Já entregas que envolvem novas features ou mudanças significativas nas engine serão realizadas a cada três meses. Já a versão enterprise terá apenas entregas trimestrais, com correções e novas features (caso tenha é claro) e o suporte será de um ano, baseado na data de lançamento.

Mas por que essa agora?

Há algum tempo estamos divulgando, ensinando e ajudando diversos públicos ao uso do Docker, tendo em vista versatilidade dessa plataforma, é claro e obvio a necessidade de adaptação do modelo de negócio para atender esses públicos, por exemplo:

Note que são perfis diversos, com necessidades e expectativas diferentes, mas em algum momento complementares. A versão enterprise do Docker visa o público que não quer apenas brincar, mas sim colocar em produção e disponibilizar para cliente.

Na imagem acima temos um apanhado geral das diferenças e onde cada versão é aplicada. Isso quer dizer que não posso colocar o Docker CE em produção? Não, isso quer dizer que se você usar a versão enterprise terá mais facilidade, já com a versão community será possível mas você terá mais trabalho.

 

Mudou o nome?

Sim, a versão community será algo parecido com isso:

# docker -v
Docker version 17.03.0-ce, build 60ccb22


Não teremos mais a nomenclatura de 1.xx, teremos então: ano.mes com a distinção entre CE e EE.

 

Tem mais alguma coisa nova?

Sim!!! Você já deve ter visto no anuncio oficial, agora há uma forma de você certificar seu ambiente seguindo as diretrizes do Docker, está disponível a Docker Store, um hub para publcação de recursos oficialmente homologados pelo Docker. Com isso, se você desejar criar um plugin para o Docker, por exemplo, você pode, atendendo uma série de requisitos, ter este plugin homologado e com certificado do Docker, o que obviamente aumenta sua relevância para quem usa.

Mas o que o Docker quer com isso? Te lembra daquelas imagens ali de cima, onde eram ilustrados os diferentes públicos que o Docker atende? Pois bem, dessa forma o Docker provê um recurso oficial, homologado e com o selo de aprovação deles para plugins, imagens, S.O, etc., atendendo assim a uma necessidade do mundo enterprise: “É confiável? Quem mantém?” dentre outras questões que este publico levanta no momento de decidir entre tecnologias.

Resumo, sim, o Docker acaba de se dividir em Community e Enterprise, até onde as coisas legais estarão na versão community só Deus sabe, mas a tendência é que sempre tenhamos  com o que brincar. E claro, para quem não quer perder tempo fazendo tudo na mão, existe a enterprise, que facilita tudo o que é possível.

Ufa, agora sim acabou 🙂

Nos ajude 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 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.