Rodando sua aplicação WSGI como um *nix daemon

For english readers, pease see post below.

Quase sempre quando pensamos em aplicações web (eu inclusive), pensamos na apache stack. Esse post apresenta uma forma diferente de fazer o deploy de sua aplicação, começando pelo fato de usarmos o servidor web apache.

Primeiro de tudo, precisamos conhecer uma peça chave diso tudo:

Mongrel2

Mongrel2 é um servidor web escrito por Zed A. Shaw. Esse é um servidor que simplismente não se importa em que linguagem sua aplicação foi escrita, tudo que você precisa fazer é seguir algumas regras bem simples para conseguir juntar mongrel2 e sua aplicação.

A primeira regra é que sua aplicação precisa saber se comunicar através de uma fila, nesse caso ØMQ (http://zeromq.org) e a segunda regra é que sua aplicação precisa entender o protocolo definido pelo mongrel2. Você pode (e deve!) saber mais sobre o mongrel2 no site oficial: http://mongrel2.org.

A grande sacada do mongrel2 é que, o fato dele usar uma fila para se comunicar com sua aplicação faz com que sua aplicação possa rodar de forma desacoplada do servidor, isso significa que sua aplicação não roda com a ajuda de um mod_algumacoisa ou como um processo filho do servidor web. Uma outra vantagem é que o ØMQ permite enviar mensagem por TCP, isso significa que sua aplicação pode estar rodando em uma máquina diferente de onde o mongrel2 está rodando.

Poder rodar sua aplicação em máquinas diferentes é fantástico pois sempre que necessário você pode adicionar mais uma máquina ao seu cluster e startar mais instâncias da sua apliação, todas as instâncias vão se comunicar com o mesmo mongrel2, que vai balancear as requisições entre todas as instâncias conectadas, usando uma politica round-robin.

wsgid

wsgid é o projeto que desenvolvi para tornar possível rodar suas aplicações WSGI usando como servidor web o mongrel2. O wsgid é a ponte entre o mongrel2 e a especificação WSGI (PEP-333), isso significa que basta a sua aplicação obedecer à especificação WSGI para já estar pronta para rodar com o mongrel2.

O wsgid entende tanto a língua do mongrel2 (zeromq + protocolo) quanto a especificação WSGI. Além disso, sua aplicação agora é um processo separado, com PID e tudo mais. Isso te traz algumas vantagens, como:

  • Pode rodar com permissões de qualquer usuário, a sua escolha;
  • Por ser um processo do sistema operacional, está automaticamente sujeito a quaisquer configurações que o S.O possa oferecer, como por exemplo: limite de banda, memória, CPU e etc;
  • Pode ser rodado dentro de um chroot, caso você precise rodar código não confiável;
  • Entre outras.

Iniciar uma nova instância de sua aplicação é tão fácil quanto:

   $ wsgid --app-path=/path/to/wsgid-app-folder/ --recv=tcp://127.0.0.1:8888 --send=tcp://127.0.0.1:8889
      --workers=4

Nesse exemplo simples estamos conectando ao endpoint 0MQ que está na mesma máquna em que nossa aplicação, mas nada impede de usarmos –recv=tcp://129.168.0.2:8888, sendo esse IP o de uma máquina qualquer em seu cluster. Ainda nesse exemplo a opção –workers=4 cria 4 processos que vão ser responsáveis por atender requisições de sua aplicação.

wsgid, principais funcionalidades

Além de facilitar o deploy de aplicações WSGI com o mongrel2, o wsgid possui ainda outras funcionalidades importantes:

workers

Com a opção workers você pode iniciar quantos processos desejar, de uma só vez. Isso significa que você não precisa rodar o comando 4 vezes caso queira 4 instâncias, apesar de você poder fazer isso, sem problema nenhum. Mas essa opção te dá a possibilidade de fazer –workers=4, que te dará o mesmo resultado.

keep alive

Com a opção keep-alive o wsgid reinicia automaticamente qualquer processo que tenha terminado sua execução. Isso significa que uma chamada ao wsgid com –workers=4 –keep-alive manterá sempre 4 workers trabalhando para sua aplicação.

hot deploy

Sempre que o wsgid restarta um dos processos, o código de sua aplicação é recarregado, afinal é um novo processo que está sendo criado. Isso significa que você pode atualizar o código-fonte de sua aplicação e apenas mandar um SIGTERM para todos os seus workers, isso fará com que o wsgid restarte cada um deles, mas dessa vez já rodando o novo código-fonte.

chroot

O wsgid já pode, automaticamente, fazer o chroot para uma localidade onde a aplicação está. Isso faz com que essa aplicação possa rodar de forma isolada, criando assim um ambiente um pouco mais seguro (não totalmente) caso você esteja rodando códigos não confiáveis.

Sistema plugável para carregar diferentes aplicações

O wsgid conta com um sistema de plugins muito simples porém bem poderoso. Com ele você pode escrever seu próprio Application Loader, caso o wsgid não consiga carregar sua aplicação. Com isso será muito simples adicionar suporte a outros frameworks WSGI para que mais aplicações possam fazer uso desse projeto.

Espero que tenha gostado do projeto, qualquer feedback é bem vindo. Para saber mais sobre o projeto visite o site oficial: http://wsgid.com e saiba mais.

Mas lembre-se, use o que for melhor para você, use o que te atende melhor. Não estou dizendo que a solução mongrel2+wsgid é a melhor sempre, estou apenas dizendo que essa combinação é fantástica, e deve ser considerada no momento de publicar uma nova aplicação WSGI.

Apenas por curiosidade, o site wsgid.com é uma aplicação django e está rodado usando o próprio wsgid.


Running your WSGI app as a *nix daemon

Almost every time we think about web apps (at least me) we think about the apache stack. This post will show you a different method to deploy your aps, starting by not using apache as the web server.

First of all, we need to know a key piece of all this:

Mongrel2

Mongrel2 is a webserver written by Zed A. Shaw. The server is language agnostic, which means that it just doesn’t care which language you wrote you app, all you have to do is follow some very simple rules and you will be able to plug mongrel2 and your app together.

The first rule is that your app must know how to communicate through a queue, in this case ØMQ (http://zeromq.org) and the second one is that you must follow the very simple protocol specified by mongrel2. You can (and must!) know more about mongre2 on the official website: http://mongrel2.org.

The key feature of mongrel2 is that, that fact of using a queue to communicate with the applications makes it possible to run the apps decoupled from the server, this means that your app doesn’t run with a mod_something or as a child process of the webserver. Another advantage is that ØMQ allows you to communicate over TCP, that’s how you can run your app on a machine other than where mongrel2 is running.

The ability to run your app this way, that is, on different machines is fantastic, because whenever needed you can add a new node to your cluster and start new instances of your app. All these instances will connect to the same mongrel2, and the requests will be load-balanced among all instances in a round-robin policy.

wsgid

wsgid is a project I developed to make possible to run your WSGI apps with mongrel2 webserver. wsgid is the brifge between mongrel2 and the WSGI specification (PEP-333), this means that just by conforming with the WSGI spec your app is ready to run with mongrel2+wsgid.

wsgid talks both mongrel2 and WSGI, also from now on your app will be a separated process, with it’s own PID and everything a process has. This brings you some advantages:

  • Can run as any user on your operating system;
  • As being a O.S process, is automatically submitted to all characteristcs and O.S process has, eg: bandwith limit, memory limits, CPU scheduling, etc;
  • Can run inside a chroot, in caso you are running untrusted code;
  • Many others.

Start new instances of your app is as easy as:

   $ wsgid --app-path=/path/to/wsgid-app-folder/ --recv=tcp://127.0.0.1:8888 --send=tcp://127.0.0.1:8889
      --workers=4

I this very simple example we are connecting to a ØMQ endponit in same machine that the app will be running, but nothing prevents us from using –recv=tcp://192.168.0.2:8888, being this IP the address of another node on the cluster. Still in this example, the option –worker=4 starts 4 processes that will respond to requests for your app.

wsgid, key features

Besides facilitating the deployment of WSGI applications with mongrel2, wsgid also has other important features:

workers

With this option you will be able to start any number of processes you want at once. That means you don’t need to run the same wsgid command 4 times if you want four instances, although you can do this without any problem. But this option gives you the possibility to do –workers=4, which gives you the same result.

keep alive

With the keep-alive option wsgid automatically restarts any process which has finished its execution. This means that with a call to wsgid with –workers=4 –keep-alive, wsgid will always keep 4 processes working for your application.

hot deploy

Whenever wsgid re-starts one of the processes, the code of your application is reloaded, after all is a new process being created. That means you can update the source code of your application and just SIGTERM all its workers, it will make  wsgid restart all workers, but this time already running the new source code.

chroot

wsgid can chroot to the location where the application is. This makes such application run in isolated, thus creating an environment a little safer (not entirely) if you are running untrusted code.

Plugable system for Application Loading

wsgid has a very simple but very powerful plugin sub-system . With it you can write your own application loader, in case wsgid is not able to load your WSGI app. With such a sub-system, it will be very simple to add support for other WSGI frameworks so that more applications can make use of this project.

That’s it! Hope you enjoyed the project, any feedback is more than welcome. To learn more about the project visit the official website: http://wsgid.com.

But remember, use what works best for you, use what best serves you. I’m not saying that the solution mongrel2+wsgid is the best ever, I’m just saying that this combination is fantastic and should be considered whenever you are thinking of publishing a new WSGI application.

Just out of curiosity, the wsgid.com website is a django application and runs with wsgid.

,

  1. O que aprendi desenvolvendo projetos de código aberto « ~ #_
  2. Finalmente meu site pessoal está lançado: daltonmatos.com « ~ #_

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: