Aviso: esse post não contem detalhes sobre o Consul, ele tenta colocar esse tipo de ferramenta em um contexto histórico, justificando sua existência e utilização bem como ser um repositório com links para sites que já possuem boa referência sobre o assunto e também para locais onde se possa aprender na prática sobre o serviço.


Microservices. Pronto, agora que o Google indexou essa página com a palavra mágica da moda eu posso começar a falar sobre o Consul.io 😉 Na verdade eu não associo o Consul.io necessariamente a microservices e vou explicar o porquê depois de falar sobre service registry.

Mas primeiro um pouco de história àqueles de vinte e poucos anos

#begin TLDR;

Pensando em tecnologia de forma abstrata, integrações sempre existiram e elas são o cerne do problema e parte da solução que envolve um service registry. Nos idos de 199x, quando eu comecei em TI, a forma mais comum de integrar aplicações era através de cargas. App1 gera dados em um formato conhecido por App2 em um horário T1 e App2 os processa em um horário T2, ou seja, não era online. App1 precisava saber quatro coisas sobre App2: os dados que queria, o formato que deveria ser disponibilizado, onde colocar os dados (qual o servidor FTP, pasta de rede, etc) e o horário limite para gerar todo o conjunto de informações.

Aos poucos o ambiente passou a requerer integrações online (blerg para esse termo) e surgiram os diferentes formatos de RPC (CORBA, DCOM, RMI, …), assim as aplicações (geralmente que compartilhavam uma mesma tecnologia) poderia invocar métodos remotos de aplicações na rede. Dessa forma, App1 precisava saber três informações sobre App2 (para o mesmo cenário anterior): os dados que queria, o formato que deveria ser disponibilizado e onde colocar os dados (qual o endpoint). O problema do horário foi resolvido pois agora era uma integração em tempo real.

Contudo, como dito anteriormente, essas tecnologias geralmente não permitiam muita interoperabilidade (CORBA resolvia isso) e tentaram abstrair demais problemas de sistemas distribuídos (procurar no Google sobre “The Eight Fallacies of Distributed Computing”), o que tornou algumas integrações problemáticas. Eu lembro quando o XML passou a ser a reposta para quase qualquer integração entre sistemas. Não que as outras técnicas não tivessem formas de representar dados (comparar CORBA com XML é o mesmo que maçã com banana – ah mas tem o XML-RPC), mas a combinação de XML com HTTP foi revolucionária por alguns fatores (que fogem ao escopo atual – que já está bem amplo). Nesse ponto App1 precisava saber ainda as mesmas três informações sobre App2 do que no exemplo acima, mas se fosse implementada a abordagem XML-RPC e o protocolo HTTP para transporte, a ideia de App1 ser na sua empresa e App2 ser na filial ou em um parceiro já se tornava mais viável.

Até aqui estamos nos idos dos anos dois mil, a era em que o HTTP tomou conta de tudo, veio a Web 2.0, B2B se tornou uma realidade entre muitas empresas e o software já era distribuído. Mas no datacenter a coisa era mais estanque. Os servidores ainda tinham um nome específico, as aplicações ainda eram modularizadas somente em biliotecas e as integrações entre aplicações da empresa geralmente eram feitas por bancos de dados (views). As aplicações cresceram e os servidores ganharam mais processamento e memória, qualquer TI que se prezasse pensava em escalabilidade (ou pelo menos redundância – dentro do datacenter). Era uma época interessante em que não se era xingado por ter o banco de dados, a aplicação e o servidor web em uma só máquina.

A evolução natural foi a serparação dos papéis, ter um proxy reverso, um servidor de aplicação e um servidor de banco de dados – tudo dedicado! oh! -, permitindo que crescessem cada parte de forma independente. Mas os servidores todos eram físicos, tinham nome e IPs bem-definidos e eram poucos. A virtualização acabou com isso. A gremlinizadora de servidores VMware tornou criar servidores uma coisa mais fácil e fez explodir o número deles no datacenter. SOA surgiu com força, marketing e todos começaram a fazer dos webservices a língua franca da integração entre aplicações. App1 ainda precisava das mesmas três informações sobre App2, mas agora, provavelmente, App1 rodava em cluster e App2 também. Havia outras questões em jogo, compartilhamento de memória, concorrência, paralelismo. Mesmo com clusters, o endpoint deveria ser conhecido, surgiram os ESBs e a coisa ficou feia e cara.

No início os ESBs eram um monolito que orquestrava uma miríade de serviços. Ele se tornou a peça central de uma arquitetura desenhada para ser distribuída e dinâmica. Eu penso que muita gente associou os termos SOA e ESB a elefantes brancos, que ninguém usa ou sabe para que serve ao certo (isso eu falo de mim que sou parte do público geral). Mas em 2006 uma empresa de fundo de quintal, a Amazon, começou a vender um serviço de cloud, as startups começaram a aparecer em sites de notícias como grandes usuárias desse tipo de serviço e as siglas terminadas em “aS” surgiram com força (SaaS, PaaS, IaaS). Algumas organizações compraram as ideias mágicas de private e hybrid cloud. Mas na nuven a vantagem é ser dinâmico, não ter o controle manual da infra, configurar o comportamento, fornecer o SLA e deixar a máquina gerenciar quantas instâncias são necessárias no momento para a carga de trabalho corrente.

E agora?! Perdi o determinismo da infra, perdi o controle dos meus servidores, meus pets, minha aplicação foi pulverizada nesse enxame de VMs (nem estou falando em containeres). Hoje eu diria que existe uma indústria de servidores dentro de cada datacenter (ou pelo menos deveria existir) e não conheço indústria com processos manuais, então, por que deveria uma aplicação ou uma infra ser feita de forma artesanal, que não garante homogeneidade, padrão e rapidez? Ainda mais em um mundo onde as aplicações estão mais segmentadas, especializadas e distribuídas, requerendo mais das equipes de infra? Sem falar que ainda se tem os mesmos três problemas para a integração da App1 com App2: qual é o endpoint, qual é o formato de dados e quais são os dados.

Os dois últimos problemas são resolvidos hoje geralmente com SOAP/XML e REST/JSON independentemente da tecnologia que adotarmos. O primeiro problema, do endpoint, hoje em dia é resolvido com utilização do protocolo HTTP, com uma URL (como antigamente). A diferença é que no passado a URL http://www.meudominio.com/app1 te levava de forma determinística ao servidor webserver01; hoje ela pode te levar tanto para o servidor huicdhuidc01.srv quanto para o UHuiHUgyuIMh769kIPO.srv, além disso, pode ser que daqui a cinco minutos o servidor UHuiHUgyuIMh769kIPO.srv não exista mais.

Eu diria que se esta não é a situação atual em que tua TI se encontra ou se encontrará em pouco tempo, talvez o Consul não seja o que estás procurando.

Ufa.

#end TLDR;

O Consul.io é um service registry, portanto ele se propõe a resolver o problema específico de descoberta de serviço, saber onde está disponível um determinado recurso na rede, qual a combinação IP:PORTA que me possibilita consumir um serviço.

Àqueles que leram o textão acima, esse componente arquitetural resolve o problema atual da infraestrutura dinâmica para aplicações, pois se os servidores podem ser criados e excluídos rapidamente, essas alterações afetam o endpoint onde um determinado serviço está acessível, não sabemos se o servidor de nome huds90372jdsdjios.srv existe agora ou existirá ainda daqui a cinco minutos, por isso precisamos de um recurso que informe a um load balancer ou diretamente a um cliente do serviço quais são os servidores que respondem nesse momento pelo endpoint que se deseja acessar.

Ele não é o único, há o Eureka por exemplo, mas foi do Consul que eu mais gostei por ser pequeno, não ter dependências externas (é feito em Go), ser simples de operar e ter uma interface DNS para consulta ao registro.

Preparei um laboratório, que está disponível em https://github.com/howtoseries/consul-demo para explicar o funcionamento dos agentes, simulando escala horizontal dos serviços em diferentes camadas e como eles se configuram automaticamente baseados nas informações contidas no Consul para quem quer ir para a mão na massa.

Quem quiser mais referências técnicas, como não curto ser repetitivo ou reinventar a roda (até porque já é uma ferramenta consolidada e possui um material muito bom disponível), vou deixar referências abaixo que são muito boas e que eu consumi:

Considerações pessoais

Como dito inicialmente, eu não penso que o Consul seja necessariamente uma ferramenta para microservices e justifico: ter webservices não é ter microservices, ter muitos servidores ou propiciar um ambiente que possa escalar de acordo com a demanda não é ter microservices e ter integração de aplicações através de webservices sem precisar de um proxy reverso (deixar um servidor poder “falar” com outro diretamente) também não é ter microservices e o Consul possibilita tudo isso.

Pode parecer idiota à primeira vista fazer as coisas que eu mencionei anteriormente, mas eu penso que há cenários diferentes que necessitam de soluções particulares, seja por cultura, seja por recursos humanos e/ou financeiros, seja por outro motivo qualquer.

Outro ponto importante sobre o Consul é ter atenção aos lançamentos de versão, pois funcionalidades ou mudanças de comportamento são introduzidos a cada minor release. Passei por isso pois implantamos a versão 0.6, que era a última, e foi lançada a 0.7 com algumas melhorias que precisávamos e fizemos ajustes através de configuração do serviço para resolver.

Além disso, é necessário entender muito bem o que os desenvolvedores pensaram quando optaram por protocolos como gossip e consensus, esse entendimento é vital ao se configurar o cluster. Também é vital a leitura da documentação de outage, há um texto bacana aqui que ilustra algumas possíveis pegadinhas.

Por último, mas não menos importante, aconselho que se experimente muito e com todos os cenários onde pretendes utilizar o Consul, teste o cluster, as falhas, as consultas e dedique tempo considerável para implantar a monitoria dos serviços com o agente. Se fizer isso, a garantia de se ter um ótimo service registry virá e com um bônus de se ter um sistema que tenha mais chance de sobreviver a falhas eventuais de nodos em mau funcionamento.

Começando a série de howtos, vai uma dica bem simples para quem gerencia servidor Apache Httpd como proxy reverso, que é exibir uma mensagem de indisponibilidade do sistema enquanto se faz manutenção em servidor ou deploy de aplicação em backend.

O cenário nesse caso é o seguinte (no fluxo do protocolo HTTP):

Situação normal: Cliente -> REQUEST -> servidor proxy reverso/load balancer -> REQUEST -> servidor backend

Situação de indisponibilidade: Cliente -> REQUEST -> servidor proxy reverso/load balancer -> REDIRECT p/ página de erro

O problema que se tenta resolver é que durante um deploy ou uma manutenção o usuário não recebe uma notificação do que está ocorrendo, geralmente recebe uma tela de erro 404 do servidor de aplicação no primeiro caso ou uma mensagem de erro do Apache ao não conseguir contatar o backend no segundo.

A solução é alcançada utilizando o mod_rewrite e um arquivo de mapa (hashtable), o código deve ser posto no início da configuração do VirtualHost (explicações abaixo):

1: RewriteEngine On
2: RewriteMap maintenanceApps txt:/var/www/unavailable-apps/vhost.conf.maintenance
3: RewriteCond %{REQUEST_FILENAME} ^(/\w+)/?
4: RewriteCond ${maintenanceApps:%1|NOT_FOUND} !NOT_FOUND
5: RewriteRule ^(.*) /messages/unavailable/index.html?app=${maintenanceApps:%1} [R=302,NE,L]

Vamos explicar o que ocorre na configuração do Apache exibida anteriormente linha a linha:

Linha 1: RewriteEngine On

Ligamos o módulo mod_rewrite.

Linha 2: RewriteMap maintenanceApps txt:/var/www/unavailable-apps/vhost.conf.maintenance

Declaramos que “maintenanceApps” é um mapa a partir de conteúdo texto contido no arquivo “/var/www/unavailable-apps/vhost.conf.maintenance”.

Linha 3: RewriteCond %{REQUEST_FILENAME} ^(/\w+)/?

Definimos a primeira condição de match para o redirecionamento, sendo: REQUEST_FILENAME deve ser uma palavra iniciada por “/”, seguida por uma ou mais letras e terminada com “/”, além disso, criamos um grupo de expressão regular com “/” e a palavra a seguir.

Linha 4: RewriteCond ${maintenanceApps:%1|NOT_FOUND} !NOT_FOUND

Definimos a segunda condição de match, procuramos no mapa “maintenanceApps” o valor que encontramos no grupo de captura da linha anterior, caso ele não exista, retornamos o valor “NOT_FOUND”, sendo que o critério é verdadeiro quando o valor for diferente de “NOT_FOUND”.

Obs.: quando duas ou mais linhas RewriteCond estão em sequência são avaliadas com operador lógico AND, caso se queira utilizar OR se deve definir [OR] ao final da linha.

Linha 5: RewriteRule ^(.*) /messages/unavailable/index.html?app=${maintenanceApps:%1} [R=302,NE,L]

Redirecionamos o cliente para a página de aviso, enviando a ele um HTTP 302 com a URL “/messages/unavailable/index.html?app=[VALOR ENCONTRADO NO MAPA CORRESPONDENTE AO INÍCIO DA URL REQUISITADA]”. As flags entre [] significam:

  • R=302, força um redirect externo (via cliente) com código HTTP 302.
  • NEnoescape: não escape caracteres.
  • L, last, para de executar regras do mod_rewrite.

O conteúdo do arquivo “/var/www/unavailable-apps/vhost.conf.maintenance” para exibir mensagem de indisponível para a aplicação “/appteste” seria:

1: /appteste "Aplicação de teste"

O primeiro campo da hashtable é a URL a procurar no cabeçalho da requisição e o segundo é o valor do parâmetro “app” enviado à página para customização de mensagem. O código HTML de “/messages/unavailable/index.html” pode, então, utilizar o parâmetro “app” e exibir uma mensagem explicativa ao cliente utilizando o segundo parâmetro.

A vantagem desse método com mapa é que o servidor não precisa receber um HUP ou USR1 para se reconfigurar com novos valores de aplicações indisponibilizadas, a contrapartida é que o acesso a disco pode aumentar (mas aí contamos com o buffercache do Linux ;).

Então, o fluxo de trabalho ao realizar um deploy ou uma manutenção em um cluster inteiro fica:

  1. Inserir linha /app-context “mensagem ou nome da aplicação para exibição ao user” no arquivo “/var/www/unavailable-apps/vhost.conf.maintenance”
  2. Realizar operação
  3. Remover linha /app-context “mensagem ou nome da aplicação para exibição ao user” do arquivo “/var/www/unavailable-apps/vhost.conf.maintenance”

O processo de aviso fica totalmente automático, os usuários são avisados com uma mensagem amigável e nenhuma request chegará ao backend desnecessariamente.

Em um post futuro mostrarei como automatizar melhor utilizando o consul-template em substituição ao arquivo de mapa.

Note que é importante esse trecho estar no início da configuração do VirtualHost, pois se a aplicação estiver em manutenção, o usuário é logo redirecionado à página de aviso.

 

Hoje começará um novo tipo de post e será denominado “how to”. A ideia é apresentar como utilizar algumas ferramentas ou como fazer algumas coisas de um jeito que eu já tenha feito ou ao menos pensado.

Sete tópicos já estão no forno, são eles:

  1. Como apresentar uma “tela de manutenção” em servidores Apache Flash proxy reverso (facilmente pode ser implementado também com nginx) enquanto faz deploy em seu backend.
  2. O que é, o que faz, do que se alimenta o Consul.IO.
  3. Como melhorar o que fizemos no item #1 com o Consul.IO e consul-template.
  4. Como fazer inventário de suas aplicações publicadas em Weblogic 12c através de WLST.
  5. Como fazer inventário de seu servidor proxy reverso Apache (com python).
  6. Como automatizar seu servidor proxy reverso Apache com Ansible.
  7. Como monitorar seu servidor Apache proxy reverso com BASH, xmllint e mod_status.

Então, se já não deu para perceber, a ideia é ser mão na massa, mas terá um pouco de teoria quando necessário. Pretendo por todos os códigos necessários no Github.

O cronograma é um tópico dos acima por semana, sendo o primeiro na próxima quinta-feira.

😉

CoreOS CTO Brandon Philips shares his views on CoreOS, Docker, and next steps in container development.

Não sei avaliar ainda se isso será o futuro, recém estou começando nesse mundo de containers, mas parece que ele está certo ao menos no que diz respeito a aplicações corporativas, no desktop a história é outra.

Fonte: CoreOS CTO: Containers Are the Next Linux Package Manager | Linux.com

Hoje, 11/01/2016, morreu David Bowie. Não sou um grande fã de sua obra, mas com certeza aprecio algumas de suas músicas e, principalmente, aprecio música o suficiente para saber de sua influência em vários artistas que o seguiram e nos próprios rumos da música e da arte performática que a acompanha. Isso, por si só, já basta para que se lembre da data e se preste o merecido respeito póstumo, um dia que se dedica a lembrar o legado de uma pessoa tão importante em um determinado segmento humano. Não sei o motivo disso, mas esse fato do dia 11, que abriu a minha segunda-feira quando minha esposa me acordou dizendo: “Não vais acreditar, sabes quem morreu hoje?”, me pôs no pensamento a insistente idéia do que se deixa como legado quando morremos.

Assunto esse um tanto mórbido pode alguém pensar, mas eu estou pensando o oposto: o que fica. Certo é que nem todos seremos em quaisquer outros segmentos humanos o que o Sr. Bowie foi para a música, mas não penso que seja errado querer isso. Ser ateu tem vantagens e desvantagens e talvez se enquadre em ambas essa noção de finitude do humano, uma vida só e pouca, pequena. Uma chance de fazer valer a pena… ou não. Quando se vê as horas não há mais tempo, por isso não se pode errar, não se pode dar algo menos do que o melhor para a vida: a primeira chance é sempre a última. Todos esses clichês servem apenas para afirmar a óbvia falha de sua finitude: não se quer o fim do que se deixa para trás.

Esse conceito de “potencial legado”, chamemos assim, ficou comigo durante o dia, a reflexão não me deixou em paz: o que eu vou deixar (não no sentido material)? Não penso que essa reflexão seja uma forma negativa de perceber a vida, apenas representa uma inquietude ingênua, ideológica e ao mesmo tempo uma pequenez madura de saber que se é somente mais um passageiro, que divide um período de tempo com outros e que deixa uma parte mínima de si para o proveito dos próximos. Não há forma melhor de descrever a eternidade e quem é louco de não querer viver para sempre? Essa é a “preocupação”.

É isso mesmo, ateus também acreditam na eternidade, ela só não é uma eternidade do indivíduo, são infinitas eternidades das influências em cada um de nós. Nesse ponto, obrigado, Sr. Bowie, sua eternidade manteve minha inquietude que, um dia, deixará de ser meu “potencial legado” para ser também, espero, eternidade em outros.


Obviamente, uma música para encerrar o pensamento.