Fabric

Em uma tarefa de deployment de uma aplicação em servidor LAMP no estágio, eu e meu g gerente tivemos a idéia de usar o Fabric, ferramenta de deployment escrita em Python, opensource e que seria em tese o equivalente ao Capistrano para o Rails.

Resumindo, o Fabric é uma biblioteca Python e uma ferramenta de linha de comando para o uso de SSH para a implantação do aplicativos ou administração de tarefas de sistemas.

Ele fornece um conjunto básico de operações para executar comandos shell localmente ou remotamente (normalmente ou via sudo) e fazer o upload / download de arquivos, bem como funcionalidades auxiliares, tais como prompt de usuário que está executando para a entrada, ou abortar a execução.

Porem, pesquisando sobre assunto, podemos ver poucos posts de blogs e informação disseminada sobre o assunto, em relação ao seu irmão do mundo Rails.

Vendo a documentação , podemos notar que o projeto ainda esta no começo(v0.9), e tem muito potencial, devido ao poder que o Python proporciona á ferramenta.

Basicamente você instala o Fabric no Ubuntu 9.10(Karmic)através do comando:


Automaticamente o Fabric já esta no seu $PYTHONPATH e com isso a proxima tarefa seria criar um arquivo fab da seguinte forma:


Dentro do fabfile.py você deve escrever suas tarefas em Python.Sendo assim dentro deste arquivo você pode mesclar ShellScript com codigo Python, solução matadora em ambiente Linux(Ubuntu).

Estando no mesmo diretorio do seu fabfile.py, você pode executar suas tarefas Fabric(metódos python) da seguinte forma:



No tutorial basico encontrado no site, existe um bom exemplo de um script simples para fazer um deployment e montar um pack com a aplicação alem de rodar os testes do Django.



Partindo desse script, a idéia era fazer o deployment de varios build's sucessivos, de forma incremental, baseado nos seguintes requesitos :

• Tags do controle de versão , no caso, o Mercurial(HG)
  
• Cobrir e rodar os testes da aplicação
  
• package com timestamp, versionando assim os releases
  
• Deployment em varios servidores(staging, production)
  
• Restart do Apache e do Memcached.

Alem disso, uma boa estrategia no caso de ocorrer algo de errado no deployment de uma versão, ou até na versão atual, seria uma função de rollback, como acontece no Capistrano que resgataria o server para uma versão estavel da aplicação.

Ao meu ver, qualquer tarefa administrativa pode ser executada de forma automatica usando o Fabric, mas claro, não existe bala de prata, e por isso devemos sempre colocar na balança os motivos e desvantagens de usar alguma tecnica.

Algumas coisas como gerenciar o firewall, ou proteger de bruteforce attacks, seriam simples, bastando apenas a criação de uma fab_task que manipula o iptables,ou usa alguma ferramenta como o UFW Uncomplicated Firewall.

Em soluções onde ocorrem grandes e as vezes devastadoras mudanças de DBschema, o uso do SOUTH para criar migrations é interessante, tornando as modificações do DB transacionais ,consistentes e claro ,menos doloridas.

O Fabric tambem pode ser alternativa para o deployment de aplicações escritas em outras linguagens da plataforma LAMP, como:

• Perl
• PHP
• Python
• Erlang¹

Fanatismos á parte, deve se levar em conta o fato de que no Rails e para o mundo Ruby ,já existe uma otima ferramenta, o Capistrano.

Fabric ao meu ver tem potencial para atuar como peça importante na pilha LAMP, sendo tambem alternativa para automatização de tarefas em outras plataformas como Java² e PHP/MySQL.

Erlang¹: ver LYME stack, Linux/Yaws/Mnesia(CouchDB)/Erlang

Referencias:

• Fabric
  
• Stack Solution
  
• South

Coisas legais do dia-a dia

Na ultima semana, em um projeto interno da empresa onde trabalho, mais uma vez me dei conta de como conceitos basicos e bem consolidados podem fazer realmente a diferença entre algo simples ou complexo e sobre uma solução ser boa ou ruim.

Conversando com a galera da empresa sobre frameworks web modernos, tecnologias atuais e o ciclo das tecnologias, tal como acontece nas artes, pude ver o quão a minha idéia realmente fazia sentido.

Principio da Localidade

Basicamente a localidade define o melhor aproveitamento da hierarquia de memória em um sistema definindo assim o conceito de cache.

O princípio da localidade de referência diz que o dado usado mais recentemente tem grande probabilidade de ser acessado novamente num futuro próximo (localidade temporal). Favorecendo-se o acesso a tais dados, aumenta-se o desempenho do sistema.

Já o principio da localidade espacial diz que um endereço em memoria , tende a ter endereços proximos acessados em um futuro proximo, devido a natureza dos loops(repetição) e das estruturas de dados de armazenamento sequencial(vetores).

Uma definição mais simples de cache poderia ser: uma área de armazenamento temporária onde os dados frequentemente acedidos são armazenados para acesso rápido.

O uso do Memcached se justifica devido a tudo isso, tornando aplicações que possuam muitos acessos ao banco de dados incrivelmente performaticas.Quando o assunto for alta disponibilidade do banco de dados, o Memcached tambem pode ser uma ótima pedida.


Estrutura de Dados

Saber implementar e entender as estruturas de dados faz grande diferença na hora de solucionar problemas.Saber onde e porque usar uma Stack, uma Queue, um Map, um Set ou uma Tree, suas politicas de uso e seus variados tipos de interface pode fazer você pensar Out-of-The-Box =).

Na hora de parsear texto, inverter strings, trabalhar com interpretação de linguagens, ou automatizar etapas , usar Stack/Pilha com politica LIFO é preciso!

Em um contexto de concorrencia, eventos do tipo Publish/Subscribe,caixa de email e computação distribuida em geral, vale a pena dar uma boa olha em Queue/Fila com politica FIFO.

Cache , Sessões, DNS entre outras aplicações ficam a cargo dos HashMaps.

Para Foruns , Conceitos de Memória, e Lógica em Geral vale a pena estudar sobre Arvores e Heaps.

Existem milhares de aplicações individuais e conjuntas destas estruturas de dados e um bom conhecimento sobre suas interfaces e aplicações pode fazer a diferença em muitos casos.


Teoria da Computação

Coisas como O(1), O(n),O(logn) podem ser horriveis se você não gosta de matematica ou não entende seus algoritmos e sua complexidade.Porem , se você olhar , mesmo que intuitivamente para seus algoritmos, poderá entender o que pode estar acontecendo e quem saber fazer isso acontecer mais rapido.

Em uma dada tarefa, eu e meu gerente percebemos que em um script de deploy automatizado com o Fabric, possuíamos um repositorio de estáticos, que devia ter sua consistencia preservada após varios redeploys.

O primeiro ataque ao problema foi copiar todo o repositorio para um repositorio auxiliar e posteriormente copia-los de volta. Basicamente um swap, que pra quem ja viu alguns algoritmos de ordenação, pode ser custoso, já que em principio,neste caso, quanto maior o numero de arquivos estaticos, o tempo da tarefa passa a ser quadrado O(n²).

O segundo ataque, em um passo de refatoração, foi de criar switch's com links simbolicos, de forma a manter a aplicação disponivel por maior tempo e tornar o tempo de consumo praticamente constante O(1) como num lookup feito em um hashmap .

Tal raciocinio, nao leva em conta calculos avançados, benchmarks ou falacias da rede como banda infinita e rede sempre disponivel, sendo apenas um leve esboço de logica.

LAMP/Web Frameworks

Podemos ver que Django, Rails dentre outros frameworks novos para desenvolvimento web, possuem comunidades fortes, principios notaveis como DRY E COC, arquitetura MVC, alem de manter suas raízes na pilha LAMP OpenSource, revolucionando ou reensinando a forma como se escreve para web nos dias de hoje.

Contudo,no mundo Java, que muitas vezes possui pensamentos megalomaniacos de contrução de foguetes(rsrsrs), podemos ver uma mudança de comportamento , dada a grande adoção de frameworks como VRaptor, Play e Scooter que aprenderam principalmente com o Rails como o desenvolvimento web pode ser produtivo, divertido e em Java.

Coisas como JSF, Wicket, GWT, Struts podem até fazer sentido em alguns contextos, mas se você parar e pensar, pra que você precisa de milhares de build's complexos, milhões de dependencias, e lógica de processamento rebuscada que "esconde" as coisas do programador?

Não é preciso reinventar rodas, nem criar engenhocas complexas para web, apenas usar o bom senso e conceitos já batidos como:

• Client-side com JQuery, ExtJS, MooTools
  
• WebFrameworks como Rails, Django
• Linguagens Script como Python,Ruby
  
• Linux como OS, geralmente Ubuntu
  
• MySQL/PostgreSQL como banco de dados
• ApacheHTTPD, Ngix ou Lighttpd como servidor web

Conhecimentos sólidos em computação distribuida,arquitetura de sistemas, shell script, sql, http, smtp, javascript, e linguagens dinamicas pode ser uma boa opção de "munição" para seus combates diários na web.


Obrigado pelo seu tempo.