Author: admin

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!

Cristhian Bicca

Trabalha em uma consultoria 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.

Olá pessoal!

Para você que está começando a ler nossos posts agora, sugiro que leia antes esse e esse link que explicam o que é o Docker e como ele funciona. Hoje nós abordaremos um dos assuntos mais importantes dentro do Docker: O Filesystem.

O sistema de arquivos do Docker é chamado de layered, ou seja, é um sistema de arquivo em camadas, o que isso quer dizer?

Um sistema de arquivo comum, possui basicamente duas camadas:

bootfs: Onde ficam o sistema de Boot do sistema e o Kernel.

rootfs: Inclui o sistema de arquivo do sistema, incluindo a arquitetura de diretório, em sistemas unix-like: /dev, /proc, /bin, /etc, /lib, /usr, e /tmp assim como os arquivos de configuração e binários do sistema.

Quando o sistema é iniciado ele carrega o rootfs primeiramente em modo somente leitura, verifica sua integridade e em seguida remonta-o como leitura/escrita e assim fica disponível para o usuário/aplicação.

No Docker temos essa arquitetura também, mas com um diferencial, a camada de escrita que o processo/aplicação visualiza não é o mesmo rootfs base, e sim uma camada de abstração do rootfs, isso é o que faz com que um container torne-se portável, pois as modificações realizadas não são aplicadas ao sistema origem do container, e sim na camada a qual o sistema visualiza.

Para ficar mais claro, veja na figura abaixo como é um sistema tradicional:

Agora veja como é o filesystem no docker:

Como podem notar o bootfs em vez de ser único por sistema/container, é compartilhado entre eles, mas o rootfs é isolado por camadas, ou seja, o que deve ser em comum entre o host e container é compartilhado via AUFS, que monta uma camada de leitura/escrita em cima do filesystem em somente leitura, isso garante que modificações feitas dentro do container não afetem o sistema de arquivos do host.

A imagem abaixo ilustra melhor como funciona essas camadas:

Um detalhe nessa arquitetura é que a cada modificação e commit do container é gerada uma nova camada, ou seja, digamos que eu inicie um container a partir de uma imagem do Debian, e instale o serviço apache dentro desse container, quando eu for transformar esse container em uma imagem, essa imagem possuirá a primeira camada que é do sistema Debian, e uma camada adicional que refere-se a instalação do serviço apache. Na imagen abaixo podemos visualizar melhor esse ambiente.

Lembrando que uma imagem pode ser utilizada diversas vezes, ou seja, há compartilhamento da imagem entre os containers, mas os containers depois de iniciados são isolados uns dos outros, na imagem abaixo podemos visualizar essa arquitetura.

Como podemos notar, há o compartilhamento das camadas inferiores, pois elas fazem parte da imagem que originou o container, e a camada de escrita, que faz parte do container rodando, é isolada para cada container.

Por hoje é isso, veremos em breve um pouco mais sobre filesystem no Docker, e algumas outras questões relacionadas a essa arquitetura. Ficou com dúvida? Gostaria de saber mais? Algum feedback a nos dar? Deixe sua mensagem e vamos conversando.

Abraço!

Cristiano Diedrich

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.

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!

Cristhian Bicca

Trabalha em uma consultoria 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.