Publicando imagens no Docker Hub

Fala pessoal,

Hoje vamos falar de como é possível a gente realizar a publicação de uma imagem para o Docker Hub, mas a final o que é o Docker Hub?

Introdução

Docker Hub é um repositório de imagens fornecidos pela Docker de maneira pública e privada onde existem milhões de imagens disponibilizadas para o publico realizar o download. Por padrão quando o Docker é instalado ele vai realizar o download de todas as suas images a partir desse repositório público.

Na imagem acima é possível ver na interface do Docker Hub que existem atualmente 2.829.269 imagens disponíveis, provavelmente quando você ler esse post o número já sera maior. Pela interface é possível filtrar por imagens de categorias como: Databases, Security, Storage e por ai vai. Além disso algumas imagens possuem o selo de Official Image que são as imagens oficiais de algumas tecnologias, na imagem é possível verificar as imagens oficiais de: Couchbase, Ubuntu, Redis e Node.

No Docker Hub você também pode visualizar os plugins disponíveis para integrar a sua instalação de Docker para deixa-lá mais robusta e completa, desde a: Logging, Security, Network e Storage.

Criando uma imagem

Agora que já fomos apresentando ao Docker Hub vamos criar uma imagem customizada e vamos publicar ela, para você que quer entender o que é uma imagem, da uma lida nesses links:

O que é uma imagem?
O que é Dockerfile?

Agora que você já sabe o que é uma imagem e que o melhor jeito de gerar ela é a partir de um Dockerfile, vamos criar nossa imagem para publicá-la no Docker Hub. Para isso vamos criar um arquivo chamado: Dockerfile

FROM ubuntu:latest
RUN apt-get update -y
RUN apt-get install -y python-pip python-dev build-essential
COPY requirements.txt /app/
WORKDIR /app
RUN pip install -r requirements.txt
RUN rm -f /app/requirements.txt
COPY . /app
ENTRYPOINT ["python"]
CMD ["app.py"]

Criado o nosso Dockerfile a gente precisa ir até o diretório onde está o arquivo e executar:

docker build . -t mundodocker/demo-flask:1.0.0

Com isso o Docker irá interpretar o arquivo e começar a executar os comandos que nele estão, gerando assim a nossa imagem. Após finalizar o processo você pode verificar que a imagem já está criada de maneira local, para isso basta executar:

docker image ls

Para conseguir pegar esse exemplo completo você pode acessar este repositório que estamos disponibilizando e realizar o clone do projeto:
https://github.com/mundodocker/demo-flask

Agora falta a gente realizar a publicação dela para o Docker Hub, para isso precisamos fazer o login e depois fazer o push dela, então os comandos são:

docker login
docker push  mundodocker/demo-flask:1.0.0

O mundodocker antes do / é o nome do seu repositório criado dentro do Docker Hub, nesse caso é o mundodocker.

Após a execução dos comandos, você pode ir até a sua página do Docker Hub e irá visualizar a imagem dentro do seu repositório, agora é só passar o nome da imagem para todo mundo e pronto sua imagem está pronta para uso.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

AKS – Azure Kubernetes Service – Parte 1.

Olá pessoal,

Para aqueles que nâo conseguiram realizar a implantaçâo do EKS (Elastic Kubernetes Service) que o Cristiano comentou no post anterior, pois a sua empresa está usando o Azure por exemplo,
hoje vamos falar a respeito do AKS (Azure Kubernetes Services) quem sabe você convence o seu chefe a pelo menos realizar uma POC? emmmm 😀

Ahhh, mas antes você sabe o que é Kubernetes? Caso ainda não esteja familiarizado recomendo que leias os posts que fizemos sobre o assunto 😉 Segue os links:

Kubernetes Parte 1

Kubernetes Parte 2

Kubernetes Parte 3

AKS

O AKS é um serviço de Kubernetes gerenciado pelo Azure que abstrai a instalaçâo, configuraçâo e boa parte do gerenciamento de um cluster de Kubernetes. Quando você cria um AKS o mesmo já disponibiliza uma interface onde é possível ver o status atual de seu cluster, containers e ainda por cima nâo cobra valor algum pelos servidores Master do cluster, apenas pelos Workers.
Com toda essa facilidade não tem porque você criar uma estrutura de máquinas virtuais e depois realizar a instalação do Kubernetes, sendo que você irá precisar de pessoas para administrar ou automatizar essa instalação.

Prós:

  • Integração de RBAC simples com o Azure Active Diretory (É possível definir pessoas e grupos do AD que podem acessar diretamente o seu cluster de Kubernetes)
  • Integração com o Azure Disks (É só dizer qual tipo de disco seu Pod vai usar que automaticamente o disco é criado no Azure)
  • Azure CNI (Definir uma subnet especifica já criada e colocar IPs válidos nos Pods para realizar alguma integração com algum recurso do Azure)
  • Escalar automaticamente (Deixe configurado para aumentar a quantidade de nós quando chegar em x% de CPU)
  • Integração com Log Analytics (Enviar os logs dos containers diretamente para o Log Analytics e gerar Dashboards e alertas a partir dele)

Contras:

  • Caso queira fazer alguma configuração especifica nos Managers nâo é possível.
  • Não é possível mudar a engine de containers (Usam Docker).

Hands On

Partiu? vamos ver como é fácil realizar a instalaçâo e configuraçâo de um AKS?

Para isso existem duas maneiras, caso vocês utilizem Windows, é possível realizar a instalação do az-cli ou via Powershell realizar a instalação do módulo Powershell para o Azure. Para Linux deve ser feita a instalaçâo do az-cli

Windows

  • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-windows?view=azure-cli-latest

Linux

  • Debian/Ubuntu
    • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-apt?view=azure-cli-latest
  • RedHat/Centos
    • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-yum?view=azure-cli-latest

Feito a instalação do az-cli, você deve realizar o login no azure para isso vamos executar:

az login

Após executar o comando irá aparecer na tela uma URL para você acessar e se autentica no portal do Azure, após realizar essa autenticação o az-cli estará pronto para uso.

Para realizar a criação do AKS vamos utilizar o comando az aks create esse comando possuí apenas 2 parâmetros obrigatórios são eles:

--name: Nome do cluster de AKS.
--resource-group: Grupo de recursos onde o cluster será criado.

Porém vamos utilizar outros parâmetros para ver o que mais a gente pode definir, então vamos utilizar mais os seguintes parâmetros:

--max-pods: Máximo de pods por worker.
--disable-rbac: Desabilita RBAC.
--node-count: Quantidade de Workers iniciais
--zones: Zona de disponibilidade do Azure
--nodepool-name: Nome do pool de máquinas para o AKS
--max-count: Quantidade máxima de Workers que podem ser criadas.

Para realizar a criação do cluster de AKS basta executar

az aks create --name aksmundodocker --resource-group resource_aks --max-pods 100 --disable-rbac --node-count 2 --zones 1 --nodepool-name aks --min-count 1  --max-count 3 --location eastus --enable-cluster-autoscaler

A criação deve demorar algo em torno de 7 minutos, após a criação do cluster basta você executar.

az aks get-credentials --name aksmundodocker --resource-group aks 

Com isso você já tem acesso ao seu cluster de AKS e pode começar a trabalhar nele. Para validar você pode executar o kubectl para testar a comunicação com o cluster:

kubectl get nodes

Eai, curtiu? Então manda para alguém que talvez tenha interesse, e claro, fique a vontade para conversamos 😉
Grande Abraço!

Prometheus + Docker

Fala pessoal, hoje vamos entrar em uma série de posts referentes a métricas, para quem está ligado no mundo da tecnologia, vem se falando há bastante tempo sobre SRE [ Ebook do Google ] (https://landing.google.com/sre/) um dos principais temas falado pelo pessoal do Google é em questões de métricas, pois são as métricas que nos fornecem uma visão geral referente a como está o nosso ambiente e nos proporciona a capacidade cada vez maior nossas equipes serem orientadas a dados: Data driven

Prometheus

Prometheus é um Kit de ferramentas de Monitoramento e Alertas Open Source que foi criada pela SoundCloud . Muitas empresas estão adotando o Prometheus para trabalhar com a questão de métricas de seus sistemas e aplicações. Em 2016 o Prometheus foi incorporado dentro da Cloud Native Computing Foundation sendo o segundo projeto hospedado após o Kubernetes.

Componentes

 Prometheus

Iniciando

Vamos monitorar o nosso servidor de Docker com o Prometheus, para isso vamos editar o arquivo daemon.json que já é criado por padrão em:

  • Linux /etc/docker/daemon.json
  • Windows C:\ProgramData\docker\config\daemon.json

Dentro desse arquivo vamos adicionar as seguintes linhas:

{
    "metrics-addr" : "127.0.0.1:9000"
    "experimental" : true
}


Após a criação desse arquivo, ou edição dele, vamos precisar criar o arquivo de configuração do nosso Prometheus, para isso vamos criar o arquivo config.yml

global:
    scrape_interval: 15s
    evaluation_interval: 15s

  external_labels:
    monitor: 'codelab-monitor'

scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'docker'
         # metrics_path defaults to '/metrics'
         # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9323']


Com o conf criado vamos criar o serviço para começar a armazenar as métricas, para isso vamos executar:

docker service create --replicas 1 --name my-prometheus \
    --mount type=bind,source=/tmp/prometheus.yml,destination=/etc/prometheus/prometheus.yml \
    --publish published=9090,target=9090,protocol=tcp \
    prom/prometheus


  • –replicas=1 # Quantos containers de prometheus vamos ter
  • –mount # type = Tipo de mapeamento que iramos fazer, source = Caminho de origem para o arquivo de configuração, destination = Caminho de destino no container
  • –publish # publish = A porta que será exposta para o mundo, target = A porta que a gente configurou no config do prometheus, protocol = protocolo utilizado
  • prom/promtheus # Imagem utilizada.

Após isso basta abrir o seu browser e navegar até http://iphost:9090 e você terá acesso ao seu prometheus. Você pode ir até http://iphost:9000/targets/ onde você poderá ver as informações que configramos e verificar se está tudo ok com as coletas de nossas métricas.

Como podemos notar é meio complexo conseguirmos ver as informações referente ao nosso ambiente diretamente pelo Prometheus, então para facilitar esssa visão, vamos utilizar o Grafana como Dashboard, ja falamos dele em um post anterior: Grafana + Influx + Cadvisor

Para criar o container do Grafana vamos executar:

docker run -d --name=grafana -p 3000:3000 grafana/grafana

Passo 1 – Autenticação

feito isso vamos acessar http://localhost:3000 após o acesso será solicitado um username e password, por padrão o inicial é admin e admin, em seguida será solicitado um novo password, então basta colocar o seu novo password.

Passo 2 – Criação do Data Source

Agora vamos adicionar o nosso prometheus como Data Source, para que sejá possível realizarmos as consultas para preencher os nossos gráficos, para isso vamos clicar no icone conforme a imagem abaixo:

E vamos escolher a opção Data Source

Agora vamos ir até Add Data Source, onde vamos ter alguns campos que são padrões e outros que devem aparecer conforme o tipo de Data Source que será escolhido, nesse caso vamos utilizar o Prometheus.

  • url: http://localhost:9090
  • Access: Browser

Dessa vez vamos criar sem autenticação, então pode deixar as questões de AUTH em branco.

  • Marcar a opção: Skip TLS Verification (Insecure)

Após isso é só clicar em Save & Test.

Passo 3 – Criação dos Dashboards

Vá até a opção de New Dashboard dentro do Grafana e escolha a opção de “Graph”

Agora vamos editar o nosso Dashboard:

Agora a imaginação é sua, basta verificar no Prometheus quais os dados que você possui para poder fazer seus Dashboards.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

Cluster de Docker Swarm com Ansible

Fala pessoal, faz tempo que não criamos conteúdo para o site, foram alguns meses de conversa sobre o futuro do blog. E a partir de hoje vamos iniciar os nossos posts de 2018, o Mundo Docker por mais que contenha a palavra “Docker” em seu nome não é um blog que contenha só posts referentes a essa tecnologia, mas sim as tecnologias mais usadas no momento. No decorrer desse ano vamos falar de muita coisa que está sendo usada hoje em dia.

Então para nosso primeiro post do ano vamos mostrar como é possível realizar a configuração de um cluster de Docker Swarm com 3 managers e 1 Worker utilizando Ansible. para quem ainda não possui familiaridade com as nomenclaturas do Docker, Manager é o papel responsável por gerenciar o cluster de Docker Swarm, já o Worker é o responsável por hospedar os containers.

Mas o que é o Ansible? Basicamente é uma ferramenta de automatização de tarefas que é muito utilizada para provisionamento e configuração de servidores, muito semelhante a Chef e Puppet. Você pode ver mais detalhes dela em nosso outro post que detalha mais sobre o ansible:

Ansible

Para esse post vamos utilizar 5 máquinas virtuais, das quais:
3 Ubuntu 16.04 que serão utilizados como Managers
1 Ubuntu 16.04 que será utilizado como Worker
1 Ubuntu 16.04 que estará com o Ansible instalado

Nosso principal objetivo é realizar a configuração de nossos servidores de forma declarativa através do Ansible e disparar os Playbooks de configuração de nossos servidores.

Vamos iniciar fazendo a instalação do Ansible em nosso servidor que será o responsável por conectar nos outros 4 servidores. Como o Ansible conecta através de ssh nas máquinas então não é preciso realizar a instalação de agentes nas máquinas de destino, o único requisito é ter o acesso ssh liberado para a máquina que irá executar o Ansible. No momento da criação desse post a versão mais recente do Ansible é a 2.5 então vamos utilizar essa versão. Na máquina que estamos utilizando para servir como Ansible você irá executar os seguintes comandos:

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Após a execução desses comandos você estará com o Ansible instalado em sua máquina, o Ansible cria o diretório /etc/ansible/ dentro deste diretório temos o arquivo ansible.cfg que é o responsável por gerenciar algumas configurações como métodos de conexões, portas, protocolo, entre outras configurações. Alguns exemplos de configurações que muitas vezes são alteradas no ansible.cfg:

remote_port = 22
sudo_user = root
host_key_checking = False
# SSH timeout
timeout = 10

Esse foi um exemplo simples de alteração, você pode acessar o arquivo e verificar todas as opções de mudança. Vamos continuar então realizando a nossa configuração. Vamos criar o diretório que irá conter as nossas configurações para os servidores:

mkdir /home/exemplopost
mkdir /home/exemplopost/roles
mkdir /home/exemplopost/group_vars
cd /home/exemplopost
touch /home/exemplopost/hosts
touch /home/exemplopost/main.yml

Esses são os diretórios base que utilizamos em um projeto com Ansible, essa é uma nomenclatura padrão com quem trabalha com ansible. Dentro de “Roles” é onde vamos colocar os nossos “Playbooks” responsáveis pela configuração dos servidores onde segmentamos por funcionalidades, “group_vars” é onde colocamos os nossos templates de variáveis que utilizamos dentro dos nossos Playbooks. Ainda temos os arquivos “hosts” onde estão as informações dos servidores que vamos conectar e também o arquivo “main.yml” que é o início da execução do nosso Ansible, onde estará descrito as Roles que serão executadas e quais os hosts que serão usados. Então vamos iniciar adicionando os nossos hosts no arquivo hosts.

vim /home/exemplopost/hosts

[docker_swarm_manager]
MANAGER1 ansible_ssh_host=10.10.10.2 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER2 ansible_ssh_host=10.10.10.3 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER3 ansible_ssh_host=10.10.10.4 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
[docker_swarm_worker]
WORKER1 ansible_ssh_host=10.10.10.5 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost

Esse é o conteúdo do nosso arquivo de hosts, dentro deles temos dois grupos de máquinas, um que chamamos de “docker_swarm_manager” e “docker_swarm_worker” com a criação de grupos conseguimos definir que determinado grupo irá executar Roles X e outro grupo irá executar Roles Y, visto que nesse caso Managers e Workers possuem diferentes configurações. Vamos criar uma hierarquia de diretórios e arquivos conforme a imagem abaixo:

Vamos agora editar o arquivo /home/exemplopost/roles/docker/tasks/main.yml:


---
  - name: Realizando apt-get update
    apt:
     update_cache: yes
  - name: Modificando hostname
    shell: hostname {{ inventory_hostname }}

  - name: Instalando a versão mais recente do Docker
    shell: curl -sS https://get.docker.com | sh

  - name: Reiniciar serviço do Docker
    systemd:
     state: restarted
     enabled: yes
     daemon_reload: yes
     name: docker

Com isso temos todos os passos que são comuns em todos os servidores de Manager e Worker. Agora vamos realizar a configuração dos Managers: Abra o arquivo /home/exemplopost/roles/manager/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Cria o cluster no primeiro servidor
    shell: docker swarm init --advertise-addr {{ docker_swarm_manager_ip }}:{{ docker_swarm_manager_port }}
    when: "docker_info.stdout.find('Swarm: active') == -1 and inventory_hostname == groups['docker_swarm_manager'][0]"

  - name: Armazena o token de manager
    shell: docker swarm join-token -q manager
    changed_when: False
    register: docker_manager_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"
 
  - name: Adiciona os outros swarms Managers no cluster.
    shell: docker swarm join --token "{{ docker_manager_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }} 
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
     and docker_info.stdout.find('Swarm: pending') == -1
     and 'docker_swarm_manager' in group_names
     and inventory_hostname != groups['docker_swarm_manager'][0]"

 

Após criar o cluster e adicionar os servidores de Managers, vamos adicionar o nosso Worker para isso vamos editar /home/exemplopost/roles/worker/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado.
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Pega o token do worker.
    shell: docker swarm join-token -q worker
    changed_when: False
    register: docker_worker_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"

  - name: Adiciona o servidor de Worker no cluster.
    shell: docker swarm join --token "{{ docker_worker_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }}
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
           and docker_info.stdout.find('Swarm: pending') == -1"

Os playbooks acima são os responsáveis pela criação do cluster de Docker Swarm. Agora vamos criar as variáveis que serão utilizadas.

/home/exemplopost/group_vars/all


---
  docker_swarm_manager_ip: "10.10.10.2"
  docker_swarm_manager_port: "2377"

Vamos agora definir o nosso arquivo main para chamar as roles a serem executadas. Para isso vamos criar o arquivo em /home/exemplopost/main.yml


---
 - name: Configurando Managers
   hosts: docker_swarm_manager

   roles:
     - docker
     - manager

 - name: Configurando Workers
   hosts: docker_swarm_worker
   roles:
    - docker
    - worker

Agora sim, criamos todos os arquivos necessários para rodar o nosso playbook, após fazer isso basta você executar o comando:

 ansible-playbook -i hosts main.yml

.
Feito isso temos o nosso cluster de Docker Swarm configurado e funcionando. Fizemos uma configuração simples que funciona muito bem para um ambiente de teste.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

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.

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.

 

 

 

 

 

 

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 😀

 

Aguarde...

Inscreva-se em nossa newsletter

E fique por dentro das novidades.