Micro serviços e cloud computing

Micro serviços em estrutura cloud

Micro serviços em estrutura cloud

Para a edição de hoje gostaria de mostrar um pouco da arquitetura de micro serviços utilizando uma estrutura em cloud computing. Assim, mostrarei um pouco sobre esta estrutura e como podemos tirar ganhos em diversos projetos.

Os micro serviços

Antes de mais nada é preciso entender alguns pontos chaves do conceito de micro serviços. Imagine um cenário onde você possui uma aplicação que deve suportar uma gama diferente de usuários que utilizam browsers desktop, mobile e alguns ainda utilizam sua aplicação através de um app nativo. Complicando um pouco mais esta aplicação possui uma API aberta para integração do seu sistema com outros sistemas (Algo muito comum por exemplo, no facebook, google, twitter e etc).

Concordam que está aplicação, sem nem mesmo falarmos das funcionalidades, teria um corpo complexo e demasiadas responsabilidades para conseguir gerenciar? Mas porque deixar isto tudo nas mãos de apenas um sistema?!

Desde que comecei a aprender um pouco sobre orientações a objetos (há uns 8-9 anos atrás) comecei a relacionar sistemas como o próprio sistema orgânico. Ou seja, cada coisa deve ter sua responsabilidade específica e simples. Assim, ela pode exercer melhor e com mais desempenho sua determinada função.

Quando comecei a conhecer a arquitetura de micro serviços consegui enxergar perfeitamente esta organicidade no macro de um projeto. Poxa, porque um projeto com tantos requisitos e tantas responsabilidades precisam sem emaranhar em apenas uma estrutura monolítica gigantesca. Consegue imaginar a complexidade de códigos, classes que vão se desembrulhando para responder às regras exemplificadas acima?!

O conceito de micro serviços traz uma proposta simplicadora. Vamos reduzir este grande sistema em um sistema com N serviços auxiliares e específicos que serão responsáveis por cada regra. Um serviço responsável pelo tratamento de clientes, um pela comunicação da API que por sua vez trabalhará com um serviço que montará a interface para o usuário e assim por diante… Posso trazer mil analogias com o que vemos no mundo real em grandes organizações, orquestras, times e etc. Os micro serviços trabalham de forma grupal para trazer um resultado unificado.

Resultado disto tudo

  • Micro serviços devem ser considerados como sistemas relativamente pequenos assim temos maior simplicidade em entender seu código
  • Maior produtividade no desenvolvimento, desde o processamento de menos arquivos pela IDE de desenvolvimento até menor curva de aprendizado do serviço.
  • Facilidade ao escalar seu desenvolvimento. Já que estes serviços trabalham em paralelo é possível que diferentes times de desenvolvimento possam trabalhar e fazer o deploy de cada serviço de forma independente.
  • Atualizar apenas um serviço para novas tecnologias (como um novo framework, uma nova versão de PHP etc) se torna mais simples, rápido e menos custoso do que readaptar todo o sistema.

Onde o cloud computing entra nisto tudo?

Com a separação de cada serviço, imagine estes serviços trabalhando em paralelo, cada um com sua própria instância e configuração ideal para o funcionamento mais otimizado possível do projeto. Cheguei apenas a esta lista de possibilidades.

  • Otimização de recursos: Você pode elevar ou descer recursos ajustando de acordo com a necessidade específica de cada serviço.
  • Otimização dos custos: Com a maior flexibilidade no ajuste dos recursos você notará que seus custos serão otimizados apenas para o que você realmente utiliza.
  • Otimização do sistema: Como cada instância é isolada você pode configurar o servidor de acordo com a necessidade específica do serviço em questão. Ex.: Você pode configurar um sistema de cacheamento para serviços que demandem informações estáticas, configurar um instância apenas com otimizações para bancos de dados.
  • Estabilidade do sistema: Se um serviço tiver um pico de uso, de memória por exemplo, por conta de um processo, um outro serviço não será penalizado por isto. O mesmo ocorre com o funcionamento do sistema, como um todo, se houver um deploy bugado de apenas um serviço.
  • Escalabilidade: É bem mais rápido e econômico escalar em diversas instâncias um único serviço que já não é suportado mais com apenas uma instância do que o sistema completo.

Como integrante da equipe de desenvolvimento da DialHost, vi e participei da implementação de alguns micro serviços em nossos projetos e conseguimos ver principalmente uma melhora grande na produtividade da equipe em manutenções e maior facilidade para resolver bugs que ocorriam. Conseguimos também dinamizar e escalar de forma mais eficiente ao utilizar nossa solução de Cloud computing colocando apenas os recursos ideais para cada serviços que criamos

Mas, Nem tudo são flores

A principal questão a se avaliar antes de seguir na arquitetura de micro serviços é que o time de desenvolvedores precisa ter o conhecimento para criar um sistema que funcione de forma distribuida. Como em um trabalho em equipe na vida real, se os serviços não trabalharem com sintonia seu sistema não funcionará. A equipe de desenvolvimento fica responsável por criar um mecanismo de comunicação entre estes serviços, afinal eles são serviços isolados que podem trabalhar em conjunto.

As principais IDE’s do mercado hoje em dia, ainda são focadas na criação de aplicações monolíticas. Assim, você não terá muito apoio destas ferramentas para a criação de aplicações distribuídas.

Por fim, se não for muito bem planejado o uso dos microserviços pode ter um efeito reverso na otimização dos seus recursos. É preciso avaliar bem até que ponto você quer ou precisa separar um sistema em diversos micro serviços para que ele não acabe aumentando seu consumo de memória ou até mesmo processamento.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Kubernetes, quais a vantagens em utilizá-lo mesmo depois do docker swarm?

Kubernetes

Kubernetes

No último artigo apresentei um exemplo prático de como montar o docker em um cloud. Hoje avanço um pouco nos conceitos de contêineres trazendo o Kubernetes  para automatizar e gerenciar seus aplicativos em contêineres. Ao fim farei um breve comparativo entre o Kubernetes e o docker Swarm.

Kubernetes

O Kubernetes é uma plataforma desenvolvida pela Google para gerenciar aplicativos em contêineres através de múltiplos hosts de um cluster e assim, ampliar a estabilidade e controle do serviço.

Com ele se tornou possível o que por muito tempo não era possível, nativamente, através do Docker: criar balanceamento de cargas e a migração de contêineres sem perda de dados. Além disto é possível automatizar estas ações para ter alta disponibilidade dos seus serviços.

ReplicaSet

O ReplicaSet é a nova geração do já conhecido Replication Controller, este controlador é responsável por manter a disponibilidade dos seus contêineres (no Kubernetes estes contêineres são encapsulados em Pods, individualmente ou, em alguns casos, em grupos). Ele irá gerenciar a replicação dos Pods de forma que:

  • Se você necessita de 10 Pods sempre rodando, quando um destes Pods cair ou travar, outro Pod será iniciado em seu host para manter o serviço funcionando.
  • Você também pode definir regras para que um novo Pod seja criado sempre que o consumo de CPU de seus Pods, em execução, alcancem 70% de uso, por exemplo.

Lembro que o ReplicaSet não é responsável por definir configurações do seu Pod. Para editar qualquer configuração você deve atualizar o Pod através do Deployment.

Services

Um serviço do Kubernetes é responsável por abstrair das definições lógicas dos Pods, além de definir as regras de acesso a estes Pods. Em outras palavras, aqui atrelamos uma faixa de IP para o ReplicaSet, definimos as regras de acesso do mesmo e configuramos o Load Balance para manter o uso de recursos de cada Pod estável.

Gerenciamento de Storage

Como os Pods são vulneráveis a travamentos e restarts, o Kubernetes trouxe o conceito de volumes independentes, ou seja, possuem suas próprias características de tempo de vida etc. Isto permite que um volume permaneça vivo fora de um contêiner e assim, os dados vinculados a um contêiner “morto” não se percam no meio do caminho. Além disto, um Pod pode utilizar diversos tipos de volumes e inúmeros volumes simultaneamente. Isto porque as regras de como o diretório é e seus conteúdos são determinados pelo tipo de volume utilizado.

Ok. Agora que entendemos um pouco melhor sobre o Kubernetes deu pra ver que ele faz um trabalho de automatização bem completo.

Mas, mesmo depois do Docker ter lançado o Swarm mode, porque o Kubernetes ainda é uma opção mais interessante?

Sem dúvida o Docker swarm é uma opção interessante para criarmos clusters de contêineres e gerenciarmos de forma simples, mas o Kubernetes traz uma proposta bem mais automatizada para fazermos isto.

Enquanto através do Docker Swarm você criará manualmente um cluster, o Kubernetes fará isto tudo automaticamente para você. Ele seguirá suas regras predefinidas (de uso de recursos ou de quantidade de Pods) para manter a estabilidade do serviço.

Um segundo ponto é o isolamento dos volumes que garante que os dados de um Pod estejam da forma que estavam quando ele precisou ser reiniciado.

Não mencionei anteriormente neste post, mas, pelo Kubernetes também é possível definir namespaces para criarmos ambientes isolados de produção e testes. Assim, podemos limitar os recursos de cada ambiente, para que um não interfira no outro.

E para finalizar, um ponto que achei interessante é a flexibilidade dele trabalhar com outros modelos de contêiner que não seja o Docker, como o Rockets (Containers no CoreOS).

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Configurando o contêiner Docker em um Cloud

Configurando Contêiner Docker em um cloud

Imagem ilustrativa sobre Contêiner Docker

Seguindo o assunto de conteinerização hoje trago um artigo prático onde vou configurar o Contêiner Docker dentro de uma instância Cloud. Para isto Utilizarei a nossa plataforma DialCloud.

Para quem quiser seguir desde o começo, deixo aqui o link do primeiro post sobre o assunto VMS vs Containers quais diferenças e usos?

Contêiner Docker

Só para recaptular o Contêiner Docker trabalha em cima do Kernel do Linux para permitir que uma aplicação ganhe em portabilidade, isolamento, segurança contra violação externa, Além de permitir o melhor gerenciamento de recursos.

Cada contêiner Docker irá iniciar uma imagem Docker, o que equivaleria a uma imagem virtual para a virtualização de máquina. Mas, no caso do Docker temos o benefício de eles utilizarem muito menos recursos, já que eles são baseados em um mesmo kernel. Através dele conseguimos uma base confiável de tudo que é necessário para executar as aplicações. Desta forma o Contêiner fica livre dos riscos externos causados pelas dependências.

Dockerfiles

Estes scripts são os responsáveis pelas orientações que devem ser executadas na montagem de uma nova imagem. Estes Scripts substituem o processo manual de configurar uma imagem para cada Contêiner que você for utilizar.

Prontos para começar

Agora que já deixamos claro os conceitos básicos para a conteinerização vamos iniciar a instalação. Primeiramente temos que criar uma instância. No caso peguei uma instância simples com 8GB de RAM e 40GB de disco e Ubuntu 14.04. Chamei ela em meu painel de docker-test, como podem ver abaixo.

Painel DialCloud

Imagem do Painel DialCloud

Com esta instância montada e com todos os dados SSH em mãos vamos aos comandos de instalação.

Instalando o Docker

Com o acesso root em mãos vou entrar na máquina e buscar por atualizações do droplet. Para isto basta executar os comandos:

Só por garantia, confira se seu sistema tem suporte ao  aufs (Ele é um controlador de armazenamento utilizado pelo Docker).

Agora temos que adicionar a chave e o repositório do Docker aos arquivos, apt-key e ao sources list

Faça um novo update no droplet com o primeiro comando que eu passei aqui e então instale o docker 🙂 \o/!

O Ubuntu possui um Firewall padrão que bloqueia o encaminhamento de pacotes. Este encaminhamento de pacotes é necessário para o funcionamento do docker. Assim, teremos que editar o arquivo ufw para liberar o encaminhamento.

Para isto entre no arquivo e então configure a opção DEFAULT_FORWARD_POLICY como “ACCEPT”

Salve o arquivo e recarregue o UFW

 

Pronto, agora que seu docker está instalado você pode começar a montar seus contêineres utilizando imagens criadas por você, ou o que é mais legal ainda, buscando uma imagem publica oficial ou deixada pela comunidade através da docker Store.

Baixando uma imagem

Para um exemplo prático, vou buscar a imagem oficial hello world do Docker para fazer a instalação. Primeiramente a gente baixa a imagem para a máquina.

Agora que a imagem já está na minha máquina eu posso criar um novo contêiner. Vale lembrar que não é possível criar um contêiner vazio, sem nenhuma execução. Por isso precisamos de uma imagem base. No exemplo abaixo eu vou criar um contêiner definindo o nome dele de my-hello e instalar minha imagem hello-world.

Uma vez instalado você pode executar ele rodando o comando abaixo com o ID do contêiner

Agora basta você usufruir do contêiner Docker e a cada atualização que você fizer, não se esqueça de atualizar o dockerfile para não perder a portabilidade dele.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

VMS vs Containers quais diferenças e usos?

vms vs container

Ilustração: vms vs container – Designed by Freepik

O Cloud computing trouxe consigo novas possibilidades de arquiteturas de TI como a instauração de instâncias cloud específicas para cada tipo de serviço. Como a arquitetura em cluster de banco de dados que traz instâncias configuradas para trabalhar com melhor desempenho para banco de dados ou aplicação. Neste ambiente cada VPS tem suas bibliotecas, SO, componentes específicos.

Com a evolução destas novas arquiteturas surgiu também um problema na criação e manutenção das VPS. Já que para a migração ou expansão do produto era necessário remontar cada configuração e refazer cada instalação. Mas como para cada problema, mais cedo ou mais tarde, surge uma nova ideia, surgiram os conceitos de virtualização de máquina (VM) e criação de containers.

Cada um com suas especificidades mas, ambos buscando uma solução em comum, facilitar a portabilidade e manutenção da infraestrutura da sua aplicação final. Mas, vamos as especificidades de cada um para termos, ao fim, um norte de qual adotar para o nosso projeto.

Virtual Machine

Brevemente falando a virtualização de máquina consiste em empacotar determinada aplicação em um modelo padrão com seu próprio ambiente operacional. Assim, agora independente da máquina que você for rodar esta aplicação suas configurações serão as mesmas desde o nível de SO até as bibliotecas e dependências necessárias.

Voltemos a arquitetura de cluster de banco de dados. Você possui uma estrutura dividida com Load Balance entre 10 VPs. Todas elas precisam ter o mesmo funcionamento e configuração. Agora imagine você ter que fazer isto uma a uma manualmente… Já deu pra sentir uma gota de suor escorrendo pelo rosto neh?! Com o uso da virtualização estas configurações seguirão automaticamente o modelo feito. Além disto você pode facilitar sua vida utilizando um gerenciador de máquinas virtuais como o Vagrant.

Containers

Os containers também fazem empacotamento, mas no caso ele não virtualizará o ambiente todo da máquina. Ele trabalhará em cima da aplicação e suas dependências criando uma virtualização apenas a nível do SO e não da máquina. Desta forma você terá o benefício de rodar ambientes isolados dentro de uma única VPs, por exemplo. Além disto você terá o benefício sobre o tamanho do sistema virtual, já que ele só integrará as configurações da sua aplicação e não da máquina inteira. Para este conceito sem dúvida hoje o maior exemplo seria o docker. Pelo seu caráter aberto, simples e colaborativo ele se tornou o sinônimo de container.

Virtualização ou containers

Se você ainda está com dúvidas do que utilizar, não se preocupe. Existem alguns pontos que podemos analisar antes desta decisão. É fato que ambos permitem uma melhor portabilidade, menor conflito de ambientes, aumento da segurança e manutenção mais fácil. Mas por trabalharem de forma diferente eles também permitem níveis diferentes para estes resultados.

A virtualização permite o isolamento total do ambiente da sua aplicação, já que ela virtualiza a máquina por completo. O container por ser uma virtualização que compartilha um mesmo kernel do sistema operacional traz um isolamento apenas parcial. O que isto quer dizer? Isolamento total igual a mais segurança.

A virtualização dá garantia de recursos para sua aplicação em nível de hardware, algo que não ocorre na conteinerização.

A Virtualização também permite o trabalho com sistemas operacionais diversos em um mesmo projeto. Já o container possui a dependência do Sistema operacional que ele está rodando.

Por outro lado os containers necessitam de menos recursos, muito menos recursos, já que eles não possuem todo o SO dentro deles. Este fator também implica na maior rapidez de reposta na inicialização de um container.

Hoje o artigo foi mais teórico, mas para o próximo artigo trarei informações sobre a configuração do docker em um cloud que tenho aqui na DialHost.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Instalando o GitLab em um cloud – Integrando equipes de desenvolvimento

Instalando o GitLab

Imagem ilustrativa: Instalando o GitLab

O Gitlab é uma ferramenta que unifica a comunicação entre a equipe, auxilia no gerenciamento de projetos, faz revisão de códigos, versionamento, continuous integration e continuous delivery em uma só plataforma. O projeto “similar” ao github oferece a plataforma, em forma de serviço na nuvem. Mas, também libera  a integração gratuita do sistema, em sua estrutura.

Aqui na DialHost, começamos a utilizar esta ferramenta dentro da nossa estrutura cloud. Ele está sendo utilizado para integrar o desenvolvimento de todos os nossos projetos. Com ele conseguimos organizar o que está sendo feito em cada projeto, definir novas metas de lançamento, além de ter facilitado extremamente no versionamento dos produtos e todos os updates que fazemos. Após um bom tempo de uso chegamos à segurança de falar que vale realmente muito a pena contar com esta plataforma em um ambiente cloud próprio.

Dentre as grandes vantagens em ter o GitLab em sua própria estrutura está…

  • Ter a plataforma gratuitamente e sem limitação de escala pelo sistema.
  • Segurança de ter os dados em seus próprios servidores.
  • Instalação bem fácil, através do bash do seu servidor cloud ou dedicado.

Colocando o GitLab para funcionar

Agora que sabemos o básico sobre a plataforma vamos a parte prática. Instalar o GitLab. Neste exemplo utilizarei o DialCloud + 4GB. O pensamento desta instalação é para uma equipe pequena. Caso necessite de uma estrutura para suportar até 100 usuário, por exemplo, o próprio site do GitLab recomenda que se tenha pelo menos 4GB de memória. Para casos ainda maiores eles deixam uma série de recomendações em sua página de requerimentos do sistema

Então nossa estrutura ficou assim

  • 4 GB de RAM (Os 4 GB são recomendados pois teremos uso do sistema operacional além do utilizado pelo GitLab).
  • 2 vCPUs
  • 40 GB de storage (Lembre-se que o espaço em disco deve ser sempre o suficiente para alocar pelo menos todos os projetos em seu repositório).
Tela de instância para o GitLab

Tela de instância para o GitLab

Agora que minha instância está 100% instalada e configurada é importante pegar sua senha de root e o IP público para fazermos um acesso ao bash. No caso vou utilizar a ferramenta MRemote para o acesso.

Com o MRemote aberto vamos às configurações. Você precisa atentar apenas a parte de conexão e protocolo, sendo que em conexão você colocará os dados referentes ao seu servidor.

Configuração do servidor no MRemote

Configuração do servidor no MRemote

Após configurar o acesso basta conectar ao servidor configurado. Este programa é interessante pois uma vez configurado o acesso não preciso mais ficar me preocupando em gravar senhas e etc. E sempre que você precisar atualizar o GitLab você simplesmente conecta novamente e faz o update.

Alterando os hostnames e definindo pingback

Com o acesso ao servidor precisamos adicionar apenas os comandos que vou explicar abaixo e em poucos minutos  seu gitlab estará funcionando.

O primeiro passo aqui é definir um hostname para o seu servidor. Ele será importante mais pra frente, para não surgir erros na instalação das dependências do gitlab.

Dica: Não é necessário colocar um subdomínio ou domínio apontado para o servidor, apenas um hostname válido. Neste exemplo utilizarei o subdomínio gitlab-blog.dialhost.com.br.

 

Em seguida insira o hostname também no arquivo /etc/hostname, com o conteúdo  gitlab-blog.dialhost.com.br

 

Acesse o arquivo /etc/hosts com o vim (assim como foi feito no comando acima) e insira os valores abaixo:

 

Instalando o Ruby

Como o GitLab é baseado no ruby precisaremos ter a última versão dele rodando em nossa VM. Vamos instalar a versão 2.3.1

 

Instalando o PostGreSQL

Para gerenciar todas as informações do sistema o GitLab utiliza o banco PostGreSQL. Assim, precisaremos instalar e configurar o banco de dados para funcionar na plataforma.

 

Tudo certo… vamos iniciar o serviço

 

Agora vamos criar o usuário e o banco de dados para o gitlab ser instalado corretamente

 

Pronto… o banco de dados está configurado agora vamos a parte que interessa realmente.

Instalando de fato

Agora precisamos instalar as dependências do sistema. Mas não se preocupe isto pode ser facilmente resolvido com o comando

 

A última dependência a ser instalada é o postfix. Esta aplicação é responsável por enviar e-mails de notificação do GitLab. Ela pedirá algumas configurações que seguem abaixo.

Na primeira tela selecione a opção “Internet Site”.

Instalação do servidor de e-mail do GitLab

Selecionando a opção de instalação do servidor de e-mail

Por fim, configure o do hostname responsável por enviar os e-mails que o GitLab utiliza. Coloque o seu domínio para isto. No caso irei cadastrar o domínio gitlab-blog.dialhost.com.br e dar ok.

Cadastro do domínio para o servidor de e-mail

Cadastro do domínio para o servidor de e-mail

O processo demorará menos de um minuto e assim que instaladas as dependências vamos instalar o package do GitLab.

Viu como é fácil instalar… Para finalizar você só precisa dar início ao serviço no servidor e fazer as configurações iniciais. Para isto utilize o comando

 

Finalizada a parte do bash, podemos ir para o browser digitar o endereço apontado para o seu cloud. No caso vou utilizar o IP da minha máquina. Mas, caso você tenha configurado um domínio é possível acessá-lo por ele. Eu fui direcionado a tela abaixo pedindo para resetar a senha inicial da conta de administrador do GitLab(root).

Tela para resetar senha de root do GitLab

Tela para resetar senha de root do GitLab

Coloquei a nova senha desejada e confirmei. Prontinho… agora estou na tela de login onde posso fazer o primeiro acesso ao meu GitLab.

Tela de login do GitLab

Tela de login do GitLab

Como administrador eu posso mudar o nome do meu usuário root e criar novos usuários para toda a equipe. Além disto eu posso definir permissões diferenciadas entre os usuários de forma geral e por projeto. O que facilita para o gerente definir quem cuidará de qual projeto e o que ele poderá fazer em cada projeto.

Integrando as equipes

Ao entrar no GitLab, é possivel ver um painel bem intuitivo e cheio de recursos para cada usuário. Mas ao meu ver, o mais interessante é a capacidade que ele tem de integrar toda a comunicação da equipe de desenvolvimento. Você pode criar Issues que receberão toda a discussão da equipe referente a ela. O versionamento em git é mostrado de forma extremamente intuitiva e a todo momento temos explicações de como agir para comitar, darmos os merge-request e etc.

Então… espero que tenham gostado deste post e que vocês consigam ter melhores resultados ao integrar esta ferramenta a metodologia de desenvolvimento de sua equipe.

DialHost
DialHost

Contamos com nosso DataCenter no Brasil de alta qualidade, estabilidade e confiança para hospedar seu site. Utilize poderosas ferramentas para otimizar o uso do seu serviço e seja sempre atendido de forma rápida e clara pelo nosso atendimento 24h.