Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 2
Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 2 – Parte 1
“Não é só ir para a nuvem. Não é só ir para microserviços. É a gente conseguir ter sucesso nessa arquitetura.”
Event Driven: É a forma de controlar o envio de mensagens de um microserviço para o outro.
Existem basicamente dois tipos de serviços para controlar os eventos:
- Fila: First in first out – (FIFO)
- Topico: Quem grava mensagens no tópico é o Publisher e quem lê estas mensagens são os subscribers. (Muitos para muitos N:N)
CI/CD: O conceito de CI/CD deve estar sempre atrelado ao emprego de microserviços e de certa forma, com o uso de containers o emprego do CI/CD fica mais simples de ser feito.
Criar a esteira do CI com build e teste do código e posteriormente e não menos importante mas de acordo com a maturidade da empresa, o CD, este então pode ponderar de fazer ou não o deploy de forma automática, mas a entrega do artefato deve ser feita.
Base de dados: Isolamento da base de negocio para aquele microserviço em especifico.
Reuso: Sera que este microserviço será reutilizado por outro time? Outras aplicações também vão utilizar?
Tamanho: Não é por que é microserviço que consome microrecursos. Microserviço refere-se a pequena parcela de um sistema ou serviço como todo, mas nem sempre isso vai demandar poucos recursos.
Arquitetura de Microsserviços e Microcontainer: O Negócio como Serviço (e Saiba Como Evitar as Armadilhas) – Aula 2 – Parte 2
Ler os conceitos de Cloud moderno:
Portabildade: O uso de containers padroniza a infraestrutura e suas características e tras o beneficio da portabilidade e reduz os riscos de lock-in.
Container é uma forma que eu consigo empacotar o meu sistema operacional e todas as minhas libs e runtime necessários para que meu código seja executado de forma consistente.
“O objetivo do container é possibilitar que você execute o seu código de forma isolada e contida em um mesmo servidor.”
Introduzido em 2002, na versão 2.4.19 do kernel Linux, Namespace é uma feature que permite criar e lidar com diversos contextos em um mesmo sistema, vendo propriedades globais diferentes e isoladas em cada contexto. Para facilitar o entendimento, com namespace é possível criar um contexto (ou ambiente) de rede isolado do ambiente físico. Nesse novo contexto, existirão interfaces de rede física que não são visíveis no contexto do sistema; essas interfaces terão endereços físicos e lógicos diferentes do contexto do sistema e todo tráfego, regras de firewall, existentes nesse novo contexto, não são vistos por nenhum outro contexto, incluindo o contexto do sistema.
Essa é a feature que é utilizada para garantir isolamento. Embora exemplifiquei utilizando recursos de rede, existem diversos recursos que podem ser isolados utilizando namespaces. Os principais são:
· Process identify (pid) namespace
· Unix timesharing system (UTS) namespace
· inter-process comunication (IPC) namespace
O Mount namespaces é responsável por criar um contexto isolado do sistemas para dispositivos que podem ser montados pelo sistema. Aqui, você pode observar que nem todo dispositivo montado no contexto físico deve ser disponibilizado para containers, ou algo que é montado em um container não deve ser também montado em outro. Precisa existir um isolamento e o mount namespaces garante isso para o recurso de dispositivos montados.
Além desses, existem também artigos que complementam a necessidade de isolar outros recursos encontrados nos sistemas Linux através de namespaces. Eles foram propostos e que ainda não foram implementados, como por exemplo:
· system log (syslog) namespace
Arquitetura de namespaces
A maneira que o sistema operacional irá criar e gerenciar namespaces depende principalmente da arquitetura de namespace que é implementado no kernel do sistema operacional. Existem duas arquiteturas básicas que os namespaces podem ser implementados: a arquitetura hierárquica e a não-hierárquica.
A arquitetura hierárquica relaciona os recursos em diferentes contextos. Geralmente os recursos dos novos contextos são relacionados com o contexto do sistema já criado. Embora os namespaces sejam isolados entre si, eles podem ser mapeados para que o contexto principal possa, de alguma maneira saber que existem outros contextos em execução. A Figura 1 demonstra como podem diferentes namespaces podem ser relacionados hierarquicamente.
Figura 1- Arquitetura hierárquica de namespaces
Para fins de exemplo, suponhamos que os círculos enumerados sejam processos. Na arquitetura hierárquica, os namespaces filhos (Child namespaces) foram originados do namespace pai (Parent namespace), e, com isso, estabeleceu-se uma hierarquia onde, os processos executados pelos filhos são mapeados através de processos no pai. Vale salientar que o identificar nos namespaces filhos são diferentes dos nomeados pelo namespace pai.
A arquitetura não-hierárquica não relaciona os recursos em diferentes contextos. Quanto mais simples for o recurso, mais candidato ele será a utilizar essa arquitetura (UTS, por exemplo). Nessa arquitetura os recursos do namespace filhos não são mapeados para o namespace que o criou (contexto de sistema, por exemplo).
Mas, qual das duas arquiteturas é utilizada atualmente?
Ambas. Dependendo do recurso que está se isolando atráves do namespace, uma ou outra arquitetura é utilizada. E isso pode ser visto em containers LXC e Docker: quando rodamos um processo dentro de um container LXC (um contexto LXC), ele pode ser visto fora do container (no contexto do sistema) pois foi mapeado.
O PID do processo no contexto do lxc será diferente do PID no contexto do sistema. Logo, o PID é um tipo de recurso que utiliza a arquitetura hierárquica em seus namespaces e nos recursos que ele isola.
Namespace é algo incrível, uma feature que alavancou o uso de containers. Existe outra técnina que permite um “isolamento do sistema”, como é o caso do chroot, mas a maneira que ele trabalha é primitiva e não permite integrar com outros elementos de controlo (como o caso do cgroups).
Somente essa pequena explanação já foi capaz de abrir os horizontes e entender como um container funciona e como seus recursos são isolados. Isso responde muitas das dúvidas mais frequentes como: Porque meu pendrive não aparece no meu container? porque minhas regras de firewall não são aplicadas no meu container?
Futuramente, pretendo explanar mais sobre o assunto, mostrando algo mão na massa (Show me code, show me commands!). Qualquer dúvida, ou comentário contrutivo, deixem logo abaixo.
Os cgroups permitem alocar recursos — tais como tempo da CPU, memória do sistema, largura de banda de rede ou combinações destes recursos — entre grupos de usuários definidos de tarefas (processos) rodando em um sistema. Você pode monitorar os cgroups que configurar, negar acesso dos cgroups a certos recursos e mesmo reconfigurar seus cgroups dinamicamente em um sistema em execução. O serviço cgconfig (“control group config ”) pode ser configurado para iniciar no momento do boot e restabelecer seus cgroups pré definidos, fazendo-os persistentes através de reboots.
Usando cgroups, os administradores de sistema ganham controle refinado sobre a alocação, prioridades, negação, gerenciamento e recursos de monitoramento do sistema. Recursos de hardware podem ser divididos inteligentemente entre tarefas e usuários, aumentando a eficiência geral.
1.1. Como os Grupos de Controle são Organizados
Os cgroups são organizados hierarquicamente, como processos, e cgroups filhos herdam alguns atributos de seus pais. Entretanto, existem diferenças entre os dois modelos.
O Modelo de Processo do Linux
Todos os processos em um sistema Linux são processos filhos de um pai comum: o processo init, que é executado pelo kernel no momento de boot e inicia todos os outros processos (que por sua vez iniciam seus próprios processos filhos). Por causa que todos os processos descendem de um pai único, o modelo de processamento do Linux é uma hierarquia única, ou árvore.
Adicionalmente, todos os processos do Linux exceto o init herdam o ambiente (tal como a variável PATH) [1] e outros certos atributos (tal como abrir arquivos descritores) de seu processo pai.
Os cgroups são similares aos processos em:
· eles seguem uma hierarquia, e
· Os cgroups filhos herdam certos atributos de seus cgroups pais.
A diferença fundamental é que muitas hierarquias diferentes de cgroups podem existir simultaneamente em um sistema. Se o modelo de processo Linux é uma árvore única de processos, então o modelo cgroup é uma ou mais árvores desconectadas e separadas de tarefas (exemplo: processos).
Múltiplas hierarquias separadas de cgroups são necessárias porque cada hierarquia é anexada a um ou mais subsistemas. Um subsistema [2] representa um recurso único, tal como tempo de CPU ou memória, O Red Hat Enterprise Linux 6 fornece nove subsistemas cgroups, listados abaixo por nome e função.
Subsistemas Disponíveis no Red Hat Enterprise Linux
· blkio — este subsistema define limites de acesso de entrada/saída para e a partir de dispositivos de bloco tais como drives físicos (disco, estado sólido, USB, etc).
· cpu — este subsistema usa o agendador para fornecer acesso às tarefas de cgroups para o CPU.
· cpuacct — este subsistema gera relatórios automáticos nos recursos de CPU usados pelas tarefas em um cgroup.
· cpuset — este subsistema atribui CPUs individuais (em sistema multicore) e nós de memória para atribuir em um cgroup.
· devices — este subsistema permite ou nega acesso aos dispositivos por tarefas em um cgroup.
· freezer — este subsistema suspende ou retoma tarefas em um cgroup.
· memory — este subsistema define limites no uso de memória pelas tarefas em um cgroup e gera relatórios automáticos nos recursos de memória usados por essas tarefas.ol
· net_cls — este subsistema marca os pacotes de rede com um identificador de classe (classid) que permite que o controlador de tráfego do Linux (tc) identifique os pacotes que originam de um cgroup em particular.
· ns — o subsistema do namespace.
Você pode encontrar o termo controlador de recursos (resource controller) ou simplesmente controlador (controller) nas literaturas do cgroup tais como as páginas man ou documentação do kernel. Ambos destes termos são sinônimos com “subsistemas”, e partem do fato que um subsistema tipicamente agenda um recurso ou aplica um limite aos cgroups na hierarquia que está anexada.
A definição de um subsistema (controlador de recurso) é bem geral: é algo que age sobre um grupo de tarefas, como exemplo os processos.
chroot é uma operação que altera o diretório raiz aparente para o processo atual de execução e seus filhos. Um programa que é executado em tal ambiente modificado não consegue acessar os arquivos e comandos fora dessa árvore de diretórios ambiental. Esse ambiente modificado é chamado de um prisão chroot (ou chroot jail).
Lançamento do Docker em 2013.
Outros benefícios do uso de containers:
- Infraestrutura imutável. (Stateless)
- Deployment muito mais rápido.
- Reuso da imagem do container por outras pessoas ou serviços.
- Versionamento do container.
“Coloca a imagem do container em um lugar único, compartilha, né? Essa é a ideia da colaboração ela é muito importante e ela também vai ser fator crucial para alavancar o seu negocio , seu aplicativo e etc.”
Já existem Windows containers com IIS, DOTNET framework e etc.
Para tratar das limitações de escala e proxy de acesso a aplicações em containers foi criado os orquestradores de containers:
2013 o google começou a trabalhar com o desenvolvimento do Kubernetes com base no BORG.
Kubernetes é um orquestrador de containers.
