Monday, April 6, 2015

OpenShift - PaaS "de verdade"





Esses dias, procurando por uma solução mais inteligente para

automatizar deploys de aplicações, me deparei com o
OpenShift, que logo de início me pareceu ser

mais complexo do que o necessário. Mas, ao criar uma conta,

experimentar o serviço e ler a documentação eu simplesmente

pirei imaginando as milhares de possibilidades para automação

que eu tinha em mãos.




"http://s.profissionaisti.com.br/wp-content/uploads/2015/03/openshift.png"

alt="openshift" width="914" height="753">



Primeiras impressões



A primeira coisa que notei foi a incrível simplicidade do

conceito: aplicações rodam em máquinas (gears) compostas por

serviços, chamados de cartuchos (cartridges). Para um site em

PHP com base em MySQL, cria-se uma aplicação que rodará numa

máquina com os cartuchos php-5.4 e mysql-5.5, por exemplo. Se

também precisarmos usar crontabs ou um phpMyAdmin, basta

adicionar o cartucho.



A segunda coisa que me impressionou foi a forma adotada para o

modo de operação e deploy: ssh (sem ele eu não viveria) e git!

Nada mais óbvio, simples e eficiente! Deploy de aplicação? “git

push” e já era! Perfeito! Isso me fez querer mais… e tinha:

facilidade de administração do ambiente tanto via navegador

quanto via terminal (é aqui que as coisas começam a ficar

realmente interessantes).



Terceira super-impressão: o comando “rhc”. Só para ter uma

idéia da simplicidade: “rhc app create site php-5.4 mysql-5.5″

cria uma aplicação de nome “site” com os cartuchos de php e

mysql, clona o repositório e está tudo pronto. Adicionar outro

cartucho? “rhc add-cartridge”. Quer conectar diretamente nas

portas dos serviços (como apache e mysql)? “rhc port-forward”.



Um rápido “overview” da estrutura dessa mágica toda



A mágica começa com o uso de cgroups para definir

limites de ciclos de processamento e memória, quota para

limitar uso de disco e o SELinux para “blindar” o ambiente e

permitir somente o acesso necessário as aplicações e seus

envolvidos (administradores, desenvolvedores, fuçadores e por

aí vai). É uma implementação bem simples e funcional que

garante acesso e funcionamento controlado das aplicações sem

detrimento de funcionalidades necessárias tanto para

desenvolvedores quanto para administradores.



É estruturado com broker e nodes. O
broker é a “central de comando” do
OpenShift, é ele o responsável pela alocação e

controle dos recursos dos nodes, que por sua vez são

as máquinas (físicas ou virtuais) que serão “divididas” pelas

aplicações.



Com esse nível de magia, conseguimos aumentar ainda mais a

densidade de um data center. Combinando o poder do OpenShift

com um ambiente de cloud computing, podemos ainda automatizar

todo o processo de criação de VMs (sob demanda) e inclusão de

nós no sistema tornando a infraestrutura totalmente

transparente e de certa forma irrelevante para as equipes de

desenvolvimento e suporte.



Alta disponibilidade



O broker também é capaz de mover aplicações entre os

nós conforme necessidade causada por indisponibilidade ou carga

do servidor, sendo capaz de garantir disponibilidade e

responsibilidade das aplicações (lógico que isso também depende

muito da carga média total da infraestrutura).



Há, ainda, opções de HA que garantem tanto o uptime da

aplicação quanto a distribuição de carga (haproxy) bem como

escalabilidade horizontal automática baseada na carga das

aplicações. O OpenShift é capaz de subir novas gears

automaticamente para suprir as necessidades.



Outra mágica: DNS



Dentre as diversas funcionalidades espetaculares do
OpenShift, tem uma que gostei muito: a gestão

de nomes. Para mapear um domínio ou subdomínio para uma

aplicação, basta criar um alias. Assim como em todas as outras

funcionalidades, não existe a necessidade de configurações

manuais. E ainda existe a gerência automática de zonas de DNS

para os domínios utilizados (mais explicado em seguida).



O esquema de nomes é baseado na estrutura de

aplicação-domínioAPP.domínio, onde domínioAPP representa o

“domínio” conforme nomeado no OpenShift (são como “divisões”) e

domínio representa o domínio (DNS) propriamente dito, ex:
loja-meucliente.minhaempresa.com.br. Essa atualização

de DNS para inclusão de aplicação-domínio também é feita de

forma automatizada.



Três “sabores” disponíveis



Podemos encontrar o OpenShift em três formas distintas:

"_blank">Online (serviço oferecido pela própria

Red Hat, com servidores na Amazon, que inclui plano gratuito

para 3 small gears),

"https://www.openshift.com/products/enterprise" target=

"_blank">Enterprise (o top, conforme imaginado,

pago e com suporte) e

"https://www.openshift.com/products/origin" target=

"_blank">Origin (versão da comunidade que pode ser

utilizada livremente).



Sem complicações



Imaginando algo dessa magnitude já tendemos a prever os

seguidos dias de dores de cabeça para colocar um sistema desses

em funcionamento. Mas acredite: até nesse momento o OpenShift

surpreende. Conforme pode ser visto em

"https://install.openshift.com/" target=

"_blank">install.openshift.com, basta executar um único

comando para efetuar a instalação.



Quando se trata de utilização e administração, tudo segue a

mesma linha de simplicidade. A WebUI é extremamente simples e a

utilização via terminal é igualmente descomplicada com a

ferramenta rhc, que te guia até mesmo na hora de

configurar a conexão com o broker.



Tudo também é facilmente ajustável, como definições de

“tamanho” (ou capacidade) de gears ou de
quotas. Até mesmo as aplicações podem ter seus

recursos alterados bastando um “rhc app scale-up” ou

rhc app scale-down“.



Segurança e densidade



Sem dúvidas essas são as palavras mais utilizadas na hora de

projetar um data center.



Fazendo “uso pesado” do SELinux e cgroups, as aplicações ficam

“isoladas” umas das outras e são incapazes de “invadir” o

espaço (falando em consumo de recursos) das demais. Toda

autenticação é baseada em chaves (usuários das aplicações não

conseguem mudar isso) e apenas os recursos necessários para o

funcionamento e manutenção das aplicações são disponibilizados.



Já no quesito densidade, podemos imaginar o seguinte:

compartilhar máquina física (com virtualização) já parece

promissor, então compartilhar máquinas virtuais maiores

(reduzindo overhead ocasionado por SO tanto em memória quanto

processamento quanto armazenamento) é uma opção ainda mais

promissora. Outro benefício obtido, ainda, será a “dupla

camada” de

"Projetando um ambiente virtual com alta disponibilidade" href=

"http://www.profissionaisti.com.br/2013/10/projetando-um-ambiente-virtual-com-alta-disponibilidade/">

alta disponibilidade (HA na aplicação e na

infraestrutura).



Opinião final



Parabéns a Red Hat… como de costume surpreendeu.



Se abstrairmos toda a tecnologia utilizada e integrada na

construção do OpenShift, ainda sim teremos um sistema

impressionante capaz de reduzir ao máximo a necessidade de

trabalho para deploy de aplicações e “áreas” para que elas

sejam executadas. É certamente parte do futuro de meus projetos

e implantações e altamente recomendado para qualquer gestor de

infraestrutura e administrador de sistemas que ocasionalmente

tem problemas com segurança, disponibilidade, estabilidade,

densidade de data center e continuidade.



Quer uma dica? Experimente!




0 comments:

Post a Comment