Pesquisar este blog

terça-feira, 9 de abril de 2019

Introdução ao Docker Container. Kubernetes e OpenShift




 O uso de containers tem se popularizado e trazido mais agilidade e menor custo no momento de desenvolver aplicações e entregar serviços, abstraindo a camada de infraestrutura, antes de difícil escalabilidade e portabilidade.

Apesar do Docker ter se popularizado, a gerência de muitos containers se tornou complexa, portanto surgiram os orquestradores que passaram a garantir a saúde dos muitos itens que rodavam, sem a necessidade de alguém que tomasse conta.

Temos diversas ferramentas que cumprem esse papel, entre elas o  Kubernetes que ganhou força à partir da quantidade de features, robustez e quantidade de contribuidores que decidiram tornar o processo de orquestração amigável  e permitiram a compatibilidade com os principais Provedores Cloud (AWS, Google e Azure), bem como os servidores de sua infra.

Muitos problemas como escalabilidade automática, balanceamento de carga, comunicação entre containers, exposição de aplicações e serviços foram resolvidos e muitas empresas adotaram a tecnologia

Uma camada acima do Kubernetes, temos as plataforma como serviços, os famosos PaaS (Plataform as a Service). O Openshift, que embora use o Kubernetes por baixo, está nessa camada, possui um “self-service” de componentes que podem ser selecionado conforme desejado, tendo soluções internas de registry, build de imagens a partir de código fonte (S2I), monitoria, segurança, logs, integração contínua, etc.

A ferramenta é mantida pela Red Hat e  possui versões pagas e gratuitas. A versão free – denominada OKD (The Origin Community Distribution of Kubernetes) pode ser utilizada pela comunidade e se encontra no github,  já a Enterprise é paga e incluí suporte e uma maior estabilidade.

A final o que é Docker?


Docker é um projeto OpenSource que fornece uma plataforma para desenvolvedores e administradores de sistemas permitindo que se crie containers leves e portáteis para diversas aplicações.

Sua funcionalidade é basicamente uma forma de isolamento de processo e sistemas, quase como uma virtualização, porém mais leve e integrada ao host. O Docker permite criar aplicações em Containers que isolam o SO base de toda pilha de dependências de forma leve.

Além disso, os containers oferecem maior flexibilidade para você criar, implantar, copiar e migrar um container de um ambiente para outro. Isso otimiza as aplicações na cloud.

O que é um Container Linux?


Os containers Linux são tecnologias que permitem empacotar e isolar aplicativos com todo o seu ambiente de tempo de execução, ou seja, com todos os arquivos necessários para executar os aplicativos. Dessa forma, é mais fácil migrar a aplicação em container de um ambiente para outro (desenvolvimento, teste, produção etc.) sem perder nenhum aspecto da funcionalidade.

O Container é como se fosse um chroot, um tipo de partição isolada dentro de um único sistema operacional. Os containers oferecem muito dos mesmos benefícios das maquinas virtuais, como segurança, armazenamento e isolamento de rede e ao mesmo tempo exigem menos recursos de hardware. É possível definir recursos como memória, rede, cpu, sistema, aplicação, serviços e etc.
 
Aplicativos de software são normalmente implantados como um único conjunto de bibliotecas e arquivos de configuração em um ambiente de tempo de execução.
Tradicionalmente , eles são implantados em um sistema operacional com um conjunto de serviços em execução, como um servidor de banco de dados ou um servidor HTTP, mas também podem ser implantados em qualquer ambiente que possa oferecer os mesmos serviços, como maquinas virtuais ou um host físico.

A maior desvantagem em usar aplicativos de software é que ele está atrelado ao ambiente em execução. Qualquer atualização ou patch aplicado o SO base pode interromper a aplicação.

Como alternativa, um administrador de sistema pode trabalhar com containers. Como mencionado anterior mete, exige menos recursos de hardware e são mais ágeis na hora de iniciar e finalizar. O uso de containers aumenta tanto  e eficiência, a flexibilidade e a reusabilidade das aplicações de containers.


A imagem a seguir ilustra a diferença entre container e sistema operacional





Algumas das principais vantagens dos containers:

 

 - Baixa área de ocupação de hadrware: Usa recursos internos do SO para criar um ambiente isolado em que os recursos são gerenciados usando funcionalidades do SO, como namespaces e cgroups. Essa abordagem minimiza a quantidade de sobrecarga de CPU e na memória em comparação a um hipervisor de máquina virtual.

- Isolamento de Ambiente: Funciona em um ambiente fechado onde as alterações feitas no SO de host ou outros aplicativos não afetam o contêiner. Como as bibliotecas necessárias para um contêiner são autocontidas, o aplicativo pode ser executado sem interrupções. Por exemplo, cada
aplicativo pode existir em seu próprio contêiner com seu próprio conjunto de bibliotecas. Uma atualização feita em um contêiner não afeta outros contêineres, que podem não funcionar com a atualização.

- Implantação rápida: Implanta qualquer contêiner rapidamente porque não há necessidade de uma instalação ou reinicialização total do SO. Normalmente, para suportar o isolamento, uma nova instalação do SO é necessária em um host físico ou VM, e qualquer atualização simples pode precisar de uma reinicialização total do SO. Um contêiner precisa somente de reinicialização sem interromper nenhum serviço no SO do host.

- Reusabilidade: Um mesmo contêiner pode ser usado por vários aplicativos sem a necessidade de configurar um SO completo.


Visão geral da arquitetura do Docker

 

O Docker usa uma arquitetura de servidor e cliente, descrita abaixo:

- Cliente: A ferramenta de linha de comando (docker) que é responsável pela comunicação com um servidor usando uma API RESTful para solicitar as operações.

- Servidor: Esse serviço, que é executado como um daemon em um sistema operacional, faz o trabalho de compilar, executar e baixar imagens de contêiner. O daemon pode ser executado no mesmo sistema que o cliente do docker ou remoto.


Elementos do Docker

 

- Registry: O registry armazena imagens para uso público ou privado. O registry público mais conhecido é o Docker Hub que armazena várias imagens desenvolvidas pela comunidade, mas registries privados podem ser criados para suportar o desenvolvimento interno de imagens de acordo com os critérios de uma empresa.

- Contêineres: Os contêineres são ambientes segregados de espaço de usuário para executar aplicativos isolados de outros aplicativos compartilhando o mesmo SO de host.

 - Imagens: As imagens são modelos somente leitura que contêm um ambiente de tempo de execução que inclui bibliotecas de aplicativo e aplicativos. As imagens são usadas para criar contêineres. Imagens podem ser criadas, atualizadas ou baixadas para uso imediato.


Contêineres e o kernel do Linux


Os contêineres são ambientes segregados para executar aplicativos isolados de outros aplicativos compartilhando o mesmo SO de host.


- Namespaces: O kernel pode colocar em um namespace recursos de sistema específicos que normalmente são visíveis a todos os processos. Dentro de um namespace, somente processos que forem membros desse namespace podem ver tais recursos. Os recursos que podem ser colocados em um namespace incluem interfaces de rede, a lista de ID de processo, pontos de montagem, recursos IPC e as próprias informações de nome do host do sistema.

- Control Groups (cgroups): Os cgroups particionam conjuntos de processos e seus filhos em grupos a fim de gerenciar e limitar os recursos consumidos por eles. Os cgroups estabelecem restrições na quantidade de recursos de sistema que os processos pertencentes a um contêiner específico podem usar. Isso impede que um contêiner use recursos em excesso no host do contêiner.

- SELinux: O SELinux é um sistema de controle de acesso obrigatório que é usado para proteger contêineres uns dos outros e para proteger o host de contêiner contra seus próprios contêineres em execução. O mod de SELinux padrão enforce é usado para proteger o sistema de host contra contêineres em execução.


Terminologia do OpenShift


O Red Hat OpenShift Container Platform (OCP) é um conjunto de componentes e serviços modulares desenvolvidos com base no Red Hat Enterprise Linux e no Docker. O OCP adiciona capacidades PaaS como gerenciamento remoto, multilocação, segurança aumentada, gerenciamento de ciclo de vida de aplicativo e interfaces de autosserviço para desenvolvedores.

A figura a seguir ilustra a stack de software do OpenShift.


Na figura, da parte inferior para a parte superior e da esquerda para a direita, a
infraestrutura básica de contêiner é exibida, integrada e aperfeiçoada pela Red Hat:

• O SO de base é o Red Hat Enterprise Linux (RHEL).

• O Docker fornece a API de gerenciamento básica de contêiner e o formato de arquivo de imagem de contêiner.

• O Kubernetes gerencia um cluster de hosts (físicos ou virtuais) que executam contêineres. Ele funciona com recursos que descrevem aplicativos de vários contêineres compostos por vários recursos e de que maneira eles se interconectam. Se o Docker é o "cérebro" do OCP, o Kubernetes é o "coração" que o mantém em movimento.

Etcd é um armazenamento de chave-valor distribuído, usado pelo Kubernetes para armazenar informações de configuração e estado dos contêiners e outros recursos dentro do cluster do Kubernetes. O OpenShift adiciona à infraestrutura de contêiner do Docker + Kubernetes as capacidades necessárias para fornecer uma plataforma PaaS de produção.

• Os OCP-KubernetesExtensions são tipos de recursos adicionais armazenados em Etcd e gerenciados pelo Kubernetes. Estes tipos adicionais de recursos formam o estado interno e a configuração do OCP.

Containerized Services cumprem muitas funções de infraestrutura, como de rede e autorização. O OCP utiliza a infraestrutura básica de contêiner do Docker e do Kubernetes para a maioria das funções internas. Ou seja, a maioria dos serviços internos do OCP funciona como contêineres orquestrados pelo Kubernetes.

Runtimes e xPaaS são imagens de contêiner de base prontas para serem
usadas pelos desenvolvedores, cada uma pré-configurada com um banco de dados ou linguagem de tempo de execução particular. A oferta de xPaaS é um conjunto de imagens de base para produtos JBoss middleware, como o JBoss EAP e ActiveMQ entre outros.

DevOps Tools e User Experience: o OCP oferece ferramentas de
gerenciamento da Web e de CLI para gerenciar aplicativos de usuário e serviços do OCP. As ferramentas Web e CLI do OpenShift são desenvolvidas com base nas APIs do REST, que podem ser aproveitadas por ferramentas externas como IDEs e plataformas de CI. Um cluster do Kubernetes é um conjunto de servidores de nó que executam contêineres e são gerenciados centralmente por um conjunto de servidores masters. Um servidor pode
atuar tanto como servidor quanto como nó, mas tais funções são normalmente segregadas para obter maior estabilidade.


Tipos de recurso do Kubernetes


O Kubernetes possui cinco principais tipos de recursos que podem ser criados e configurados com um arquivo YAML ou JSON ou por meio das ferramentas de gerenciamento do OpenShift:

Pods: Representam uma coleção de contêineres que compartilham recursos, como endereços IP e volumes

Services: Definem uma combinação IP/porta única que fornece acesso a um pool de pods. Por padrão, os services conectam os clientes aos pods em round-robin.

Replication Controller: Uma estrutura para definir os pods que são destinados a serem escalonados horizontalmente. Um replication controller inclui uma definição de pod que deve ser replicada e os pods criados a partir dela podem ser agendados para diferentes nós.

Persistent Volumes (PV): Provisionam armazenamento em rede persistente para pods que podem ser montados dentro de um contêiner para armazenar dados.

Persistent Volumes Claims (PVC): Representam uma solicitação de armazenamento por um pod ao Kubernetes. Embora os pods do Kubernetes possam ser criados de forma independente, eles normalmente são criados por recursos de alto nível, como replication controllers.


Tipos de Recursos do OpenShift


A seguir, os principais tipos de recurso adicionados pelo OCP ao Kubernetes:


Deployment Configurations (DC): Representam um conjunto de pods criados a partir da mesma imagem de contêiner, gerenciando fluxos de trabalho, como atualizações sem interrupção. Um DC também oferece um fluxo de trabalho básico, porém extenso, de entrega contínua.

Build Configurations (BC): Usados pelo recurso Source-to-Image (S2I) do OpenShift para compilar uma imagem de contêiner a partir do código-fonte de aplicativo armazenado em um servidor Git. Um BC funciona junto com um DC para oferecer um fluxo de trabalho de integração contínua/entrega contínua básico, porém extenso.

Routes: Representam um nome de host DNS reconhecido pelo roteador OpenShift como um ponto de ingresso para aplicativos e microsserviços.
Embora os replication controllers do Kubernetes possam ser criados de forma
independente no OpenShift, eles normalmente são criados por recursos de alto nível, como deployment controllers.


Como funciona a comunicação de rede


Cada contêiner implantando por um daemon docker tem um endereço IP atribuído de uma rede interna que é acessível somente a partir do host executando o contêiner. Devido à natureza efêmera do contêiner, os endereços IPs são constantemente atribuídos e liberados.

O Kubernetes oferece uma rede definida por software (SDN) que gera redes internas de contêiner a partir de vários nós e permite que os contêineres acessem os pods de outros hosts a partir de qualquer pod, dentro de qualquer host. O acesso à SDN só funciona de dentro do mesmo cluster do Kubernetes.

Os contêineres dentro dos pods do Kubernetes não se conectam aos endereços IP dinâmicos uns dos outros diretamente. É recomendado que eles se conectem aos endereços IP mais estáveis atribuídos aos services e, assim, se beneficiem da escalabilidade e da tolerância a falhas.

O acesso externo a contêineres, sem OpenShift, exige o redirecionamento de uma porta em um host para o endereço IP interno do contêiner, ou de um nó para um endereço IP do serviço na SDN. Um serviço Kubernetes pode especificar um atributo NodePort que é uma porta de rede redirecionada por todos os nós do cluster à SDN. Infelizmente, nenhuma dessas abordagens apresenta um bom dimensionamento.

Ao definir os recursos de rota , o OpenShift torna o acesso aos contêineres escalável e mais simples. Os acessos HTTP e TLS a uma rota são encaminhados aos endereços de serviço dentro da SDN do Kubernetes. O único requisito é que os nomes de host DNS sejam mapeados para os endereços IP externos nos nós dos roteadores OCP.


Referencias



Encerro por aqui este post. Retomando um velho projeto de escrer blog, compartilhar conteúdo, espero em breve conseguir compartilhar novo tópico.

Dúvidas, comentários, sugestões fico a inteira disposição.

Obrigado, valeu!!













 


terça-feira, 21 de junho de 2016

Fazendo Upgrade Fedora 23 para Fedora 24

Lançado o Fedora 24 release, chegou a hora de atualizar.


A Atualização pode ser feita efetuando o download da imagem ISO e efetuar o upgrade via boot mídia ou via dnf plugin, procedimento no qual será mostrado aqui.

Antes de qualquer coisa, precisamos garantir de termos os pacotes mais recentes para a versão do fedora atual (Fedora 23). Além disso cetifique-se de ter um backup de seu sistema, uma ferramenta muito útil e simples de usar é o deja-dup.

1. Para atualizar o sistema, execute o seguinte comando:


# sudo dnf upgrade --refresh




2. Instale o Plugin do DNF


Precisamos instalar o plugin de upgrade do dnf.

# sudo dnf install dnf-plugin-system-upgrade




3. Atualização com DNF


Agora que já temos o Fedora 23 atualizado com os pacotes mais recentes e o plugin do dnf instalado, vamos realizar o upgrade do sistema.

# sudo dnf system-upgrade download --releasever=24
















Este comando irá baixar todas as atualizações para a maquina local para preparar o upgrade, se ocorrer algum problema para baixar os pacotes devido a dependências quebradas, pacotes obsoletos, adicione o seguinte parâmetro no final do comando: --allowerasing. Esta opção permitirá ao dnf remover pacotes que podem estar bloqueando a atualização do sistema.


4. Reboot e Upgrade do Sistema.


Finalizado o download de todas as atualizações, o sistema está pronto para ser reiniciado, para isso precisamos rebootar com o seguinte comando para que possa ser inciando o processo de upgrade.

# sudo dnf system-upgrade reboot




Ao bootar pelo kernel do fedora 23 será dado inicio ao processo de upgrade do sistema.

































Pronto, Fedora 24 atualizado com sucesso!




sexta-feira, 8 de abril de 2016

Um pouco sobre GlusterFS - Part 1

 

Introdução ao GlusterFS (File System)


GlusterFS é um sistema de arquivos em cluster capaz de escalar a vários peta-bytes. Ele agrega vários Bricks de armazenamento. Os casos de uso para GlusterFS incluem computação em nuvem, streaming de mídia e distribuição de conteúdo. sistemas de armazenamento com base em GlusterFS são adequados para dados não estruturados, como arquivos de documentos, imagens, áudio e vídeo, e arquivos de log.

 

O que é GlusterFS?


GlusterFS é um sistema de arquivos distribuído e descentralizado, trata-se de um sistema cujo principal objetivo é a escabilidade.

Basicamente, GlusterFS agrega múltiplas unidades de armazenamento remotas em um único volume. As unidades de armazenamento, chamadas de Bricks, são distribuídas pela rede em um único sistema de arquivos paralelo, permitindo uma escabilidade de milhares de bricks e vários petabytes de armazenamento.

Os clientes, que também podem ser simultaneamente servidores de dados, montam os diretórios compartilhados pelos servidores, tendo assim acesso a uma parte ou a todo o conteúdo compartilhado.


Vantagens do GlusterFS


- Elasticidade: Adaptado ao crescimento e á redução do tamanho dos dados

- Dimensionar Linearmente: Tem disponibilidade de crescimento  além dos petabytes.

- Simplicidade: É fácil de gerenciar e independente do kernel durante a execução no espaço do usuário.

- Flexivel: GlusterFS é um software único de sistema de arquivo, os dados são armazenados em sistema de arquivos nativos como ext4, xfs etc.

- Alta disponibilidade: Os dados podem ser altamente disponível por espelhamento síncrono em vários servidores. GeoReplication pode ser usado para espelhamento em um centro de dados remoto.

- Open Source: Atualmente o GlusterFS é mantida pela Red Hat Inc como parte do Red Hat Storage.


Conceitos de Armazenamento


Brick: Brick é basicamente qualquer diretório que se destina a ser compartilhado entre o pool de armazenamento confiável.

Trusted Pool de Armazenamento:  É uma coleção desses arquivos/diretórios compartilhados.

Block Storage: São dispositivos dos quais os dados estão sendo motivos entre os sistemas na forma de blocos.

Cluster: Dois ou mais servidores que fazem parte de um pool de armazenamento confiável.

Distributed File System: Um sistema de arquivos no qual os dados são distribuídos por diferentes nós, onde os usuários podem acessar os dados sem saber a localização real do arquivo.

FUSE: É um modulo de kernel carregavel que permite aos usua´rios criar sistemas de arquivos acima do kernel sem envolver qualquer código do kernel.

Glusterd: glusterd é o daemon de gerenciamento do GlusterFS.

Volume: Um volume é um conjunto lógico de 'bricks'. Todas as operações são com base nos diferentes tipos de volumes criado pelo usuário.


Diferentes Tipos de Volumes


  • Distributed Volume:
É o tipo de volume padrão que será criado quando não há opções especifica ao criar o volume. Em um volume distribuído, qualquer arquivo sempre aloca em um 'brick' aleatório.





Replicated Volume
Num volume replicado, 'bricks' são espelhados um para o outro. Isso significa que um arquivo que está escrito em um 'brick' também vai ser escrito para um ou mais 'bricks'. Um volume replicado é criado pela opção "replica" durante a criação do volume.





Striped Volumes
Neste tipo de volume, os arquivos maiores são dividido em pedaços e distribuídos pelos 'bricks'. O tamanho da faixa padrão é de 128KB, mas isso pode ser configurado para atender a necessidade de desempenho. O volume é criado pela opção 'stripe' durante a criação do volume.





Combinando Tipos de Volume
Os diferentes tipos de volumes pode ser combinados, como por exemplo: "distributed-replicated, distributed-striped, striped-replicated e distributed-striped-replicated"

Ao criar um volume combinado, deve-se especificar o numero de 'bricks' múltiplos de replica. Por exemplo, ao criar 2 stripes e 3 replicas, o numero de 'bricks' deve ser múltiplo de 6 (2 x 3), significa 6 'Bricks'.




Instalação do GlusterFS no RHEL7 / CentOS7 / Fedora


Passo 1: Ambiente Necessário (Este passo não será abordado)


* Ter instalado pelo menos DOIS NODES.
* Ter configurado os hostnames "server1.example.local" e "server2.example.local"
* Conexão de rede entre os NODEs deve estar funcionando.
* Desabilitar os seguintes serviços: SELinux e FirwallD
* Ter um disco/partição adicional montado em ambos os nodes "/data/brickX/" onde X indica o numero do host, no nosso exemplo 1 e 2 respectivamente.

 

 Passo 2: Ativar o repositorio de EPEL e GlusterFS:

  
Instalando o repositorio GlusterFS


Instalando o repositorio EPEL

# rpm -ivh epel-release-7-5.noarch.rpm


Passo 3: Instalando o GlusterFS


Instalar os pacotes em todos os servidores:

# yum install glusterfs-server

 Inicie o daemon de gerenciamento do GlusterFS em ambos os hosts.

# systemctl start glusterd

Verifique o status do serviço

# systemctl status glusterd
 

Passo 4: Configurar o "Trusted Pool"

Execute o seguinte comando somente no server1

# gluster peer probe server2

Verifique o status

# gluster peer status



Passo 5: Configurar o Volume do GlusterFS


Primeiro devemos criar o diretório nos seus respectivos server's que será usado para criar o volume distribuído do GlusterFS .

OBS: É necessário ter previamente um segunda partição montada no destino: /data/brick1 e /data/brick2 dos seus respectivos servidores, não será abordado como criar e montar novas partições.

# mkdir /data/brick1/brick
# mkdir /data/brick2/brick

Agora vamos Criar e Iniciar o Volume do GlusterFS (Distributed Volume)
 
# gluster volume create distvol  server1:/data/brick1/brick server2:/data/brick2/brick
 # gluster volume start distvol


# gluster volume info



Passo 6: Montando e Testando a configuração do GlusterFS


Monte o compartilhamento do GlusterFS no próprio servidor ou em algum cliente linux.

# mount -t glusterfs server1.example.local:/distvol /mnt

Agora vamos criar alguns arquivos para ver como será gravado nos NODEs do GLusterFS, lembrando que estamos usando a configuração de distributed.

# touch /mnt/distvol-file{1..10}.txt

Ao listar o conteúdo nos NODEs teremos uma saída parecida como nas imagens abaixo:

Server1

Server2


Neste Próximo exemplo vamos criar volumes de Replica (Replicated Volume)


OBS: Vamos precisar ter uma nova partição previamente montada em "/data/brickX", onde X é referente ao respectivo server.

Passo 1: Configuração do Volume do GLusterFS

Primeiro vamos criar o diretório nos seus respectivos server's que será usado para  o compartilhamento do GLusterFS.

# mkdir /data/brick3/brick
# mkdir /data/brick4/brick

Vamos criar e iniciar o volume do GlusterFS como replicated.
 
# gluster volume create replvol replica 2 server1:/data/brick3/brick server2:/data/brick4/brick



 # gluster volume start replvol



# gluster volume info


Note que na imagem acima onde temos os dois volumes criados, um do tipo "Distributed" e outro do tipo "Replicate"


Recursos do GlusterFS


Geo-replication: Fornece backup dos dados para recuperação de desastres. Aí vem o conceito de volumes "Master" e "Slave". De modo que se o Master ficar indisponivel, os dados podem ser acessados através de Slave. Este recurso é usado para sincronizar dados entre servidores separados geograficamente, Inicializar uma sessão de geo-replicação requer uma série de comandos do Gluster.

IP Failover: Possibilita a configuração de um IP virtual que será usado para acessar os Nodes do Gluster, assim se um dos servidores ficar indisponível vamos continuar tendo acesso ao compartilhamento pelo mesmo endereço de IP ao outro servidor, tornando transparente para o usuário.

Quota:  Permite limitar o tamanho de usdo de dados armazenado dentro de um compartilhamento gluster, ou subpasta.

Snapshot: Este recurso possibilita criar um snapshot do volume gluster e restaurar quando e se necessário, voltando ao estado original que do momento que foi criado o snapshot.


Estes recursos veremos em um próximo post.


Referências: https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/index.html


Dúvidas, criticas, sugestões serão bem vindas e respondidas assim que possível.
Obrigado, até a próxima.