Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: e4ae7f553b
Fetching contributors…

Cannot retrieve contributors at this time

183 lines (144 sloc) 6.931 kb

Scenarios de Déploiement Avancés

Survol

Voici deux exemples d’implémentation. Le premier représente une configuration minimale qui peut être implémentée d’un bloc ou avec un frontend et backend séparés. Par définition, ce n’est pas une solution adéquat pour un projet amené à s’élargir.

Le deuxième exemple est au contraire extrêmement évolutif de par sa redondance. Il peut se diviser en huit blocs.

{{{ [client] —-> [Front-end] —- [Back-end] }}}

{{{ /–[Back-end 1A] /–[Front-end 2]–+ ——————- / --[Back-end 2A]

[Load Balancer 1] /

[client] —-> |(fail-over w/ CARP)|–+

[Load Balancer 2] \

——————- \ /–[Back-end 1B] --[Front-end 1]–+ --[Back-end 2B] }}}

Front-End

Premièrement, vous avez besoin d’un front-end (FE) qui va prendre en charge les requêtes client (navigateurs) ou celles d’un répartiteur de charge et déléguera celles-ci aux back-ends (BE). Ce que l’on appelle reverse-proxy (RP). Le front-end peut se présenter sous la forme d’un web-server ou tout autre type de logiciel.

Quelques Front-Ends

  • OpenBSD’s native pf/relayd layer 3/7 proxy/load balancer
  • HAProxy
  • pen
  • pound
  • Apache (mod_cgi, mod_fastcgi, mod_proxy/mod_proxy_http)
  • nginx (ngx_http_proxy_module)
  • lighttpd (mod_proxy, mod_fastcgi, mod_scgi)

Dans le cas d’un web-server, il peut efficacement servir tout le contenu statique de l’application. Aussi certains front-end ne supportent pas SSL, ce qui peut être important dans le choix de votre implémentation.

Protocole entre Front-end et Back-end

Ensuite, vous devez décider quel protocole va être utiliser pour la communication entre front-end et back-end. Suivant le reverse-proxy utilisé, vous n’aurez pas énormément le choix. En fait, il y a SCGI, FastCGI et HTTP. HTTP semble être le plus populaire aujourd’hui. Il y a du pour et du contre dans chacun d’eux, et leur stabilité ou performance dépendra de votre schémas de déploiement, et aussi de l’OS. Suivant le protocole utilisé, la communication s’effectuera au travers d’un socket ou via TCP.

Back-End

Enfin, il va falloir choisir un back-end qui acceptera les requêtes du front-end au travers de ce fameux protocole. Ramaze utilise Rack qui est une interface modulaire à un large panel de servers HTTP comme Mongrel ou Webrick. Rack SCGI peut aussi être utilisé à la place. D’origine, Rack peut parler LSWS, CGI, SCGI, FastCGI, mongrel et webrick. Ramaze est donc adapté à ces solutions, excepté LSWS.

Quelques Back-Ends

  • rack-mongrel
  • rack-evented_mongrel
  • rack-swiftiplied_mongrel
  • rack-webrick
  • rack-cgi
  • rack-scgi
  • style/rack-scgi
  • rack-fastcgi
  • spawn-fcgi/rack-fastcgi
  • thin

Pour prendre en charge la concurrence des requêtes, un server TCP/socket peut lancer plusieurs instances d’une application Ramaze. Voici quelques exemples:

{{{ bash thin start –servers 4 –socket /tmp/thin-socket -R start.ru }}}

Thin va démarrer 4 instances de l’application Ramaze et communiquera avec le front-end à travers 4 sockets, /tmp/thin-socket*. NGINX prend en charge la communication par socket en HTTP. Lighttpd en revanche, utilise SCGI pour les sockets.

{{{ bash ramaze –adapter mongrel –port 3000 & ramaze –adapter mongrel –port 3001 & }}}

Cette commande lance 2 instances de l’application Ramaze en tâche de fond. Le front-end s’adressera à celle-ci via mongrel, en HTTP, à travers les ports 3000 et 3001.

Il est important de noter que ces deux exemples ne permettent pas de visualiser l’état ou les actions de l’application. Nous n’avons fait que démarrer celle-ci. Il est néanmoins trivial de créer un script un peu plus complet qui pourrait par exemple redémarrer les instances “crashées”, ou faire état des erreurs sur un fichier log.

Conclusion

Il existe une multitude de configurations pour un déploiement lorsque l’on prend le temps d’examiner toutes les options possibles en terme de front-end ou de back-end. C’est pourquoi il est avantageux de faire des essais avant de se lancer une application en production. Quoi qu’il en soit, il est possible d’obtenir de l’aide sur le Ramaze Google Group ou sur le canal Freenode (#ramaze) si vous cherchez une configuration plus ou moins “standard”.

Exemples de Déploiements

{{{ /- rack-webrick/ramaze pf/relayd –[HTTP]–+ - rack-webrick/ramaze }}}

Les back-ends peuvent être démarrés par un script global et doivent servir le contenu statique. SSL n’est pas supporté. pf et relayd viennent de OpenBSD.

{{{ /- ramaze(port 3000) lighttpd/mod_proxy –[HTTP/TCP]– thin –+– ramaze(port 3001) - ramaze(port 3002) }}}

Thin contrôle et prend en charge les requêtes par reverse-proxy destinées à l’application Ramaze. Démarrez avec `thin start <opts>`.

{{{ /- rack-mongrel/ramaze(port 3000) nginx/http_proxy –[HTTP/TCP]–+ - rack-mongrel/ramaze(port 3001) }}}

Cette configuration est la plus recommandée:

{{{ /- ramaze(socket 1) nginx/http_proxy –[HTTP/sockets]– thin –+ - ramaze(socket 2) }}}

Front-end et Back-end doivent tourner sur la même machine. Je n’ai pas trouvé de socket plus rapide que TCP sur mon OpenBSD.

{{{ lighttpd/mod_scgi –[SCGI/TCP]– rack-scgi/ramaze }}}

Extremement simple et minimal, mais pas évolutif.

{{{ /- rack-scgi/ramaze lighttpd/mod_scgi –[SCGI/TCP]– style –+ - rack-scgi/ramaze }}}

Voir Gem ruby-style (Supervised TCPServer, Yielding Listeners Easily). STYLE peut dynamiquement faire état de l’application et relancer les instances “crashées”.

{{{ /- dispatch.fcgi/rack-fcgi/ramaze lighttpd/mod_fastcgi –[FCGI/sockets]–+ - dispatch.fcgi/rack-fcgi/ramaze }}}

Lighttpd démarrera le back-end dynamiquement. D’après mon expérience, ce n’est pas une solution très stable s’il y a beaucoup de requêtes concurentes. Front-end et Back-end doivent tourner avec le même utilisateur (mauvais pour des raisons de sécurité). Ils doivent aussi faire partie du même bloc. Simple et facile à déployer.

Jump to Line
Something went wrong with that request. Please try again.