Innovation
Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos
Cet article fait suite à celui ci : http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11
Nous allons voir comment configurer varnish-cache afin d’optimiser notre serveur apache sur un seul serveur dédié (destiné à un public averti maitrisant la configuration d’apache).
Sur le post précédent nous avons compilé et installé varnish-cache, qui est donc dans un état fonctionnel, sur un port qui lui est propre. En suivant les différents documents cité en bas de ce poste comme sources, je vous propose ce petit mémo.
Comme toujours, il s’agit pour moi de garder une référence sur les travaux réalisés afin de prendre en main une technologie.
Dans cet article nous allons :
-Configurer varnish-cache avec des règles de base en VCL (varnish configuration language), pour prendre en charge nos virtualhost apache, et personnaliser les configurations selon le type de site.
-Configurer apache pour travailler avec varnish sur le même serveur, et pas forcément dans cet ordre :D
En ayant suivi mon POST précédent, votre installation de varnish-cache écoute actuellement le port 8080 (où le port que vous avez défini dans /etc/sysconfig/varnish pour la variable « VARNISH_LISTEN_PORT ». Apache écoute donc le port 80 (http), et varnish le 8080.
Pour que varnish-cache soit activé par défaut nous allons inverser ceci !
C’est varnish-cache qui va recevoir les demandes, et les gérer en fonction de règles que nous allons établir (le port que vous avez choisi doit être ouvert dans votre firewall évidemment).
On édite le fichier /etc/sysconfig/varnish et on change la variable « VARNISH_LISTER_PORT » en lui attribuant la valeur 80 (port http).
On édite le fichier /etc/varnish/default.vcl, et on va redéfinir le backend default en conséquence,votre fichier devra pour commencer contenir :
[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}[/bash]
Ceci défini que varnish-cache va par défaut demander le contenu au serveur local sur le port 8080, et tant qu’on ne redémarre pas le service, aucun soucis, les modifications n’ont pas d’impact.
On va maintenant éditer la configuration apache, afin de le faire écouter sur le port 8080.
Vous devez éditer le (ou les) fichier(s) de configuration apache qui définissent vos virtualhost (hôtes virtuels), ainsi que le port d’écoute par défaut. Généralement tout ceci est paramétré dans /etc/httpd/conf/httpd.conf.
Il faut donc remplacer le port par défaut sur l’ensemble des champs présents dans votre fichier de configuration comme suit :
FAITES UNE COPIE DE SAUVEGARDE AVANT DE MODIFIER POUR POUVOIR REVENIR EN ARRIERE AU BESOIN.
Listen 80 devient Listen 8080
NameVirtualHost *:80 devient NameVirtualHost *:8080
Il faut ensuite formater les logs de apache pour que ça soit compatible avec varnish-cache, pour cela, il faudra ajouter la directive suivante (en plus de celles existantes, cherchez LogFormat dans votre configuration) :
[bash]LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishcombined[/bash]
Puis, remplacer dans vos VirtualHost (hôtes virtuels), le format du log à utilisé :
CustomLog logs/xxxdomaine_access_log common devient CustomLog logs/xxxdomaine_access_log varnishcombined
A ce stade, nous sommes prêt à basculer sur le fonctionnement avec Varnish, mais avec les règles par défaut, ce qui peut conduire à des incompatibilités avec vos produits installés (wordpress, phpbb etc.). Si vous redémarrez tout de suite vos services (apache et varnish), chacun va utiliser le nouveau port et assurer le service, vous pouvez le faire, mais tant que vous n’aurez pas placé les règles, certains sites ne réagirons pas comme attendu (authentification impossible ou autre élément utilisant les cookies).
Pour adapter cela nous allons créer les règles qui vont bien en VCL, !
Je vais donner l’exemple avec quelques sites à moi, bien entendu vous adapterez à votre besoin.
L’idée pour moi et d’avoir une configuration par type de site (une pour wordpress, phpbb, sites autres etc.) et donc de conditionner la configuration selon le VirtualHost traité.
Voici donc les ajouts aux paramètres par défaut du fichier /etc/varnish/default.vcl :
[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}
#On va gérer les regles VCL selon les vhosts par hostname comme expliqué ici http://www.varnish-software.com/blog/virtual-hosts-varnish
#Traitement des requetes reçue depuis le net sur varnish-cache
sub vcl_recv {
if (! req.http.Host)
{
#soit j’affiche une erreur
#error 404 "Need a host header";
#Mais perso je prefere pouvoir appeler le serveur par son ip pour le site par défaut
#Alors je bypass et c’est le site par défaut sans cache qui sera affiché :
return (pass);
}
#On peut supprimer le www devant le host demandé si besoin, utile si on ne veut gérer que le site par défaut et unifier les logs.
#set req.http.Host = regsub(req.http.Host, "^www\.", "");
#Supprime l’eventuel :80 en fin de requete sur le host (permet de garantir que le filtre sera bien effectif.
set req.http.Host = regsub(req.http.Host, ":80$", "");
#Ici je pose une condition pour appeler le backend (serveur) et le fichier de configuration pour les sites donnés
#Pour les conditions, avec la tilde ~ je déclare que j’utilise les expression régulière regexp pour poser ma condition
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
#Permet de définir un backend (serveur) par site si besoin, comme chez moi tout est sur le meme serveur, ça sera identique partout !
set req.backend = default;
#appelle le fichier de règle RECV dédié à wordpress
include "/etc/varnish/wordpress_recv.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com|just-cs.maumautte.com")
{
#Sinon (eslif) si ce sont les virtualhosts dans la condition ci dessus, je traite comme ceci :
set req.backend = default;
include "/etc/varnish/wordpress_recv.vcl";
#Oui c’est la meme configuration, mais j’aurai pu, par exemple renvoyer sur un autre serveur en backend, qui ne serait pas celui de cache (un autre serveur qui hebergerait le blog dont le backend peut être défini en haut du fichier)
}
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum à la base j’avais un bypass (pas de cache) car je n’avais pas les regles pour ignorer les cookies d’auth dans le cache, mais bande de veinards maintenant c’est fait, on verra le fichier plus bas.
set req.backend = default;
#return (pass);
#Application des règles dediées RECV à phpbb :
include "/etc/varnish/phpbb_recv.vcl";
}
else
{
#Par defaut, pour tous les autres sites "classiques", j’utilise le cache par défaut de varnish-cache
#Je défini quand même le serveur sur lequel le trafic est dirigé (oui toujours le même ici)
set req.backend = default;
return (lookup);
}
#ci dessous fin sub vcl_recv (fin du traitement des requêtes provenant du web)
}
##########################################################################
#On attaque la partie qui traite la lecture des pages sur le(s) serveur(s) source
sub vcl_fetch {
#Meme chose que pour le traitement amont, je ne redétaille pas, seul les fichiers associés sont différents.
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
#Attention, ne fonctionne pas avec le ou logique
#elsif (req.http.Host =="forum.inforeseau.com||www.forum-scrapbooking.com")
#On pass en regexp avec la tilde ~ comme indiqué plus haut
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum je bypass à la base, puis finalement non, j’ai tout corrigé comme plus haut.
#return (pass);
#J’ai mes propres règles (la loi c’est moi gnark gnark gnark) :
include "/etc/varnish/phpbb_fetch.vcl";
}
else
{
#Finalement on va delivrer le contenu caché (en cache hein, pas celui qui est sous la table!) pour augmenter les performances du reste des sites :
return (deliver);
}
#Fin vcl_fetch
}
########################################################################
#Puis tout ça c’est pour ajouter un peu de sécurité, masquer le fait que les pages sont traitées par varnish etc (bon avec ce post c’est sûr on se doute un peu que c’est le cas! niarf!)
sub vcl_deliver {
# Secure the header
remove resp.http.Via;
remove resp.http.X-Varnish;
remove resp.http.Server;
remove resp.http.X-Powered-By;
}[/bash]
Maintenant les 4 fichiers contenant les règles pour les sites qui sont en include (bah ouai, je ne suis pas un chien, je ne vous laisse pas en plan :) ) :
wordpress_recv.vcl (oui c’est de la récup de chez nicolargo, un grand merci à lui pour son super blog!) :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}
# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; }
elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; }
else { remove req.http.Accept-Encoding; }
}
# Remove has_js and Google Analytics __* cookies.
if (req.http.cookie) {
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}
}
# Serve the page
unset req.http.vary;
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}
# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]
wordpress_fetch.vcl :
[bash] if (req.request == "POST") {
return (pass);
}
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if (req.http.cookie ~ "wordpress_logged_in") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]
phpbb_recv.vcl :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}
# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; }
elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; }
else { remove req.http.Accept-Encoding; }
}
# Serve the page
unset req.http.vary;
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/(admin|adm)" || req.http.Cookie ~ "phpbb2hirikiki" || req.http.Cookie ~ "phpbb3_5xoui" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static (sauf html/htm car on utilise url rewriting donc html=php)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}
# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]
Note : oui ça ressemble à celui de wordpress, notez juste les noms des cookies qui doivent correspondre aux noms de cookies que vous avez choisi dans votre config phpbb (on peut aussi identifier ça dans les préférences firefox, quand vous êtes sur votre site, en affichant les cookies dans l’onglet « vie privée »), et les pages html qui ne sont pas cachée car j’utilise de l’url-rewriting,et donc les pages html ne sont pas des pages statiques :D .
phpbb_fetch.vcl :
[bash]# Do not cache POST requests
if (req.request == "POST") {
return (pass);
}
# If the request is static (sauf html/htm utilisé en url_rewriting et donc dynamique)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if (req.http.Cookie ~ "phpbb2ronours" || req.http.Cookie ~ "phpbb3_5xr75") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]
Voilà pour les fichiers contenant les règles pour chacun des sites.
Pour en apprendre plus en VCL vous trouverez plein d’exemples ici :
http://www.varnish-cache.org/trac/wiki/VCLExamples
Maintenant on est prêts à la mise à feu :
[bash]/etc/rc.d/init.d/httpd restart
/etc/rc.d/init.d/varnish restart[/bash]
Ayé, on est à fond ! :D, c’est maintenant Varnish qui gère les requêtes HTTP sur le port 80, puis qui, en fonction du site demandé, va réaliser les traitements adaptés.
Comme dirait Nicolargo, les commandes utiles :
varnishlog : affiche les log de varnish
varnishstat : affiche les stats depuis le dernier lancement de varnish et les tâches s’évanouissent! (arf désolé j’ai pas pu résister)
Explication sur les valeurs de varnishstat : http://kristianlyng.wordpress.com/2009/12/08/varnishstat-for-dummies/
varnishhist : Affiche un historique des requêtes faites sur votre machine.
varnishadm : pour administrer votre varnish en local.
Avec tout ça vous devriez pouvoir personnaliser la configuration à souhait, avec je l’espère une meilleure compréhension du système.
Ah oui j’oubliais! Varnish vous permet aussi de faire du load balancing / failover ! Vous pouvez en lire plus ici :
http://www.varnish-cache.org/trac/wiki/LoadBalancing
Bien sûr ça implique d’avoir plusieurs machines (au moins un frontal et 2 serveurs de contenu – backend)
Note : Si vous utilisiez des outils de statistiques en php, ceux-ci ne fonctionneront plus correctement car les pages distribuées par le cache ne sont donc plus traitées en php, c’est le but !
La doc en détail : http://www.varnish-cache.org/docs/2.1/
Sources :
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
http://www.varnish-cache.org/trac/wiki
http://www.varnish-cache.org/trac/wiki/VarnishAndWordpress
http://www.varnish-cache.org/docs/2.1/tutorial/vcl.html
http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11
http://www.varnish-software.com/blog/virtual-hosts-varnish
Installation de GFS pour utilisation avec volume DRBD sous Centos 5.5 ou redhat
Pour faire suite à la mise en place de DRBD dans mon post précédent (http://blog.inforeseau.com/2011/03/installation-drbd-sur-centos-5-5-ou-redhat), nous allons voir la mise en place de GFS, un système de fichier supportant les accès concurrentiels, et permettant ainsi à 2 systèmes (dans le cas présent) d’accéder à un support de stockage simultanément.
A réaliser sur les deux machines concernées (les machines qui partagent le volume DRBD et qui vont constituer notre cluster) :
Il nous faut tout dabord, CMAN (cluster manager) et le support GFS2 :
[bash]yum install gfs-utils gfs2-utils cman
yum groupinstall Clustering[/bash]
Pour configurer le fichier de configuration de base du cluster, j’ai utilisé l’interface graphique « system-config-cluster » pour avoir un modèle, mais on peut créer le fichier à la main directement et définir les éléments du cluster (Ce fichier permet de définir les éléments du cluster pour CMAN qui va gérer les verrous).
[bash]<?xml version="1.0" ?>
<cluster config_version="3" name="mon_cluster">
<fence_daemon post_fail_delay="1" post_join_delay="6"/>
<clusternodes>
<clusternode name="pcmsi" nodeid="1" votes="1">
<fence/>
</clusternode>
<clusternode name="pchp" nodeid="2" votes="1">
<fence/>
</clusternode>
</clusternodes>
<cman expected_votes="1" two_node="1"/>
<fencedevices/>
<rm>
<failoverdomains/>
<resources/>
</rm>
</cluster>[/bash]
(man cluster.conf ou man fenced pour plus d’infos sur les paramètres du fichier ci dessus, j’ai augmenté le post_fail_delay à 1 seconde qui est à 0 par défaut à cause de latence sur mon réseau d’expérimentation qui est loin d’être performant! Plus d’infos sur les paramètres notamment liés au quorum (système d’élection dans le cluster) : http://sourceware.org/cluster/wiki/FAQ/CMAN#cman_quorum).
A noter également, la possibilité de modifier le délai de coupure considéré comme étant une rupture de liaison, entrainant le blocage du service (fence = ejection du noeud qui ne répond pas, bloquant l’accès au système GFS avec seulement 2 noeuds dans le cluster) : http://sourceware.org/cluster/wiki/FAQ/CMAN#cman_deadnode_timer
On autorise le trafic dans le firewall entre les noeuds du cluster (attention ici en réseau protégé, limitez les connexions aux machines de confiance, idéalement sur un réseau dédié au cluster).
ATTENTION SI VOUS AVEZ DEJA UNE CONFIGURATION IPTABLES SAUVEZ LE FICHIER AVANT D’UTILISER CE SCRIPT (EN CAS DE DOUTE, PRÉFÉRER LA MÉTHODE MANUELLE EN AJOUTANT LES RÈGLES IPTABLES A LA MAIN COMME INDIQUÉ JUSTE APRÈS).
Avec Iptables, on va utiliser un petit script pour configurer iptables afin d’autoriser le trafic pour le cluster.
Le fichier qui va bien (source : http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/ports-being-in-use-by-the-red-hat-cluster-software) :
[bash]#!/bin/bash
IPTABLES=/sbin/iptables
CLUSTER_INTERFACE=eth0
TCP_PORTS="41966 41967 41968 41969 50006 50008 50009 21064"
UPD_PORTS="50007 5405"
echo -n "Applying iptables rules"
for port in $TCP_PORTS; do
$IPTABLES -I INPUT -i $CLUSTER_INTERFACE -p tcp -m tcp –sport $port -j ACCEPT
$IPTABLES -I INPUT -i $CLUSTER_INTERFACE -p tcp -m tcp –dport $port -j ACCEPT
$IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p tcp -m tcp –dport $port -j ACCEPT
$IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p tcp -m tcp –sport $port -j ACCEPT
done
for port in $UPD_PORTS; do
$IPTABLES -I INPUT -i $CLUSTER_INTERFACE -p udp -m udp –sport $port -j ACCEPT
$IPTABLES -I INPUT -i $CLUSTER_INTERFACE -p udp -m udp –dport $port -j ACCEPT
$IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p udp -m udp –dport $port -j ACCEPT
$IPTABLES -I OUTPUT -o $CLUSTER_INTERFACE -p udp -m udp –sport $port -j ACCEPT
done
echo "[OK]"
echo -n "Saving new rules"
(/etc/init.d/iptables save && \
echo "[OK]") || echo "[FAILED]"[/bash]
On l’exécute évidemment pour appliquer les règles qui permettent le trafic. Attention encore, cette configuration ne filtre rien, et considère que vous utilisez une carte réseau dédiée (la CLUSTER_INTERFACE eth0 ici) pour le cluster, sans interception de trafic possible, un câble réseau dédié en gros (pas utilisable sur un réseau ouvert).
Note : on peut sauver la configuration iptables de manière permanente comme suit (recommandé pour le relancement du cluster en cas de reboot) :
[bash]/sbin/iptables-save>/etc/sysconfig/iptables[/bash]
SI LE SCRIPT AU DESSUS VOUS POSE PROBLEME – METHODE MANUELLE (ce qui a été le cas sur une machine pour moi) :
Voici simplement les lignes à ajouter dans /etc/sysconfig/iptables avant les 2 lignes du bas (REJECT et COMMIT) pour permettre la communication du cluster, si vous utilisez ETH0 pour la communication du cluster :
[bash]-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp –dport 5405 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp –sport 5405 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp –dport 50007 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p udp -m udp –sport 50007 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 21064 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 21064 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 50009 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 50009 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 50008 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 50008 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 50006 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 50006 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 41969 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 41969 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 41968 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 41968 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 41967 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 41967 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –dport 41966 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp –sport 41966 -j ACCEPT[/bash]
Après avoir ajouté ces lignes, relancez iptables et c’est réglé.
Puis on active les services au démarrage :
[bash]chkconfig cman on
chkconfig gfs2 on[/bash]
On lance les services :
[bash]service cman start
service gfs2 start[/bash]
On crée le système de fichier gfs2 sur le volume géré par DRBD (uniquement sur la machine principale) :
[bash]mkfs.gfs2 -p lock_dlm -t mon_cluster:vbox /dev/drbd1 -j 2[/bash]
On passe les 2 machines en primary sur DRBD si ça n’est pas le cas (nécessaire pour le montage simultané des ressources):
[bash]drbdadm primary resource[/bash]
On monte le volume une fois créé sur les deux machines :
[bash]mkdir /mnt/drbd
mount -t gfs2 /dev/drbd1 /mnt/drbd[/bash]
Voilà, c’est opérationnel, les deux machines peuvent lire et écrire sur le volume /dev/drbd1 grâce à la gestion du verrou par le cluster.
Quelques références utilisées pour la réalisation de ce post :
http://www.redhat.com/gfs/
http://www.cyberciti.biz/faq/linux-cluster-suite-software/
http://securfox.wordpress.com/2009/08/11/how-to-setup-gfs/
http://sources.redhat.com/cluster/wiki/FAQ/CMAN#two_node
http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/ports-being-in-use-by-the-red-hat-cluster-software
http://www.sourceware.org/cluster/wiki/DRBD_Cookbook
http://www.drbd.org/users-guide/ch-gfs.html
Ici un autre tuto complet et très clair avec Debian, GFS2 et DRBD :
http://gcharriere.com/blog/?p=73
et à lire un commentaire très pertinent sur la procédure qui s’applique également à mon post :
http://gcharriere.com/blog/?p=73#comment-15
Un article assez complet sur la haute disponibilité chez Redhat :
http://docs.redhat.com/docs/fr-FR/Red_Hat_Enterprise_Linux/5/html-single/Cluster_Suite_Overview/index.html#fig-intro-cluster-CSO
Installer ruby on rails sur fedora 11
Ceci est un cas d’école qui reproduit une situation rencontrée en prod. Comme toujours, à lire en entier avant de modifier votre système :)
Télécharger les sources ruby à la bonne version (1.8.7 mini pour le support de Rails) :
[bash]wget ftp://ftp.ruby-lang.org//pub/ruby/ruby-1.8.7-p334.tar.gz[/bash]
Décompresser :
[bash]tar xvzf ruby-1.8.7-p334.tar.gz[/bash]
Entrer dans le dossier :
[bash]cd ruby-1.8.7-p334[/bash]
Configurer :
[bash]./configure[/bash]
Compiler :
[bash]make[/bash]
tester :
[bash]make test[/bash]
installer :
[bash]make install[/bash]
Voilà, l’interpréteur RUBY est installé sur le système. On va maintenant installer « RubyGems », le gestionnaire de packages.
RubyGems est une plateforme gestionnaire de paquets pour Ruby (comme apt pour ubuntu ou yum pour fedora/centos/redhat).
Télécharger les sources à la dernière version :
[bash]wget http://production.cf.rubygems.org/rubygems/rubygems-1.6.0.tgz[/bash]
Décompresser :
[bash]tar xvzf rubygems-1.6.0.tgz[/bash]
Entrer dans le dossier :
[bash]cd rubygems-1.6.0[/bash]
On lance l’install en Ruby :
[bash]ruby setup.rb[/bash]
Gem est installé ! On continue et on install rails grâce à gem :
[bash]gem install rails –include-dependencies[/bash]
(si il y a une erreur sur la documentation de ri, on relance, si ça persiste on ignore, vous devez avoir le message « Successfully installed rails-3.0.5 »).
Rails est maintenant installé. On va s’occuper d’installer « Passenger », qui est le module apache permettant de publier les applications utilisant Rubyonrails (et de les interpréter par la même occasion!).
Nous allons utiliser gem tout juste installé pour paramétrer « passenger » :
[bash]gem install passenger[/bash]
Puis on allons installer le module apache « passenger » :
[bash]passenger-install-apache2-module[/bash]
Si il manque des éléments il suffit de suivre les instructions (j’ai fait un ctrl+c pour interrompre et installer les manquants, puis relancé) ! L’installateur vous guide et est extrêmement bien fait! Pour ma part j’ai du installer ces quelques packages manquants (ça peut être différent selon ce qui est présent ou non sur votre système) :
[bash]yum install gcc-c++ curl-devel zlib-devel httpd-devel apr-devel apr-util-devel[/bash]
Après ça, l’installateur m’indique de copier les lignes suivantes dans ma configuration apache :
[bash] LoadModule passenger_module /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.4
PassengerRuby /usr/local/bin/ruby
[/bash]
J’ai donc créé un fichier rubyonrails.conf dans /etc/httpd/conf.d/ contenant ces lignes, et relancé apache.
Pour finir l’installateur me donne un exemple de configuration pour déployer une application rubyonrails :
[bash]
——————————————–
Deploying a Ruby on Rails application: an example
Suppose you have a Rails application in /somewhere. Add a virtual host to your
Apache configuration file and set its DocumentRoot to /somewhere/public:
<VirtualHost *:80>
ServerName www.yourhost.com
DocumentRoot /somewhere/public # <– be sure to point to ‘public’!
<Directory /somewhere/public>
AllowOverride all # <– relax Apache security settings
Options -MultiViews # <– MultiViews must be turned off
</Directory>
</VirtualHost>
[/bash]
C’est clair et net, rien à dire, votre installation est terminée, vous pouvez maintenant déployer une application !
Évidemment vous l’aurez compris, j’avais déjà ici une installation de apache 2 fonctionnelle (LAMP pour être exact). Sur ce type d’installation vous pouvez vérifier la prise en charge du module « passenger » en créant une fichier php dans un site géré par votre serveur apache, contenant la commande phpinfo.
[bash]
<?php
phpinfo();
?>
[/bash]
En appelant la page php qui contient ce code, dans la rubrique « Loaded Modules » de « apache2handler » vous devriez trouver « mod_passenger ».
Sources :
http://www.ruby-lang.org/fr/
http://rubyonrails.org/download
http://rubygems.org/
http://yken.org/2008/10/18/ruby-rails-and-httpd-on-fedora-8/
http://www.modrails.com/
Links
Calendrier
L | M | M | J | V | S | D |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
Recherche
Derniers articles
Tresronours Twitter
Keywords cloud topic
Membre de la FSF
Liens qui vont bien
Mots clés vrac – keyword cloud
License du contenu – CC By NC SA
Archives
- Resumed posting and expanding on X
- Linkedin Access to your account has been restricted – Final debrief and resilience plan
- I’m thankful for the support I get in rough time
- Cyber security news of the day – 2024 May 31
- Alexandre Blanc Cyber Kicked out from Linkedin
- You’ll most likely find me on LinkedIn
- The Russian roulette landing page !
- RTSP, Debian, VLC, not playing, IP Camera
- 5G network hosted in the cloud, no internet, no phone ! So smart ! And I ended on TV, This week in cyber
- They lock the door for privacy… but they keep a copy of the key, and couple of backdoors
- Worst is yet to come, but they all warned you
- Migrating an old WordPress and handling character set, UTF8, latin1, latin1_swedish_ci
- From a broken TLS CA, to Facebook, to FIN12 hit and run
- Yes we can fix this mess, but do we want to ? That’s another story
- Criminals are still dominating the game, why are we doing so wrong, and what can we learn in this tech ocean ?
- Riding cloud can be tricky, don’t fall from it, in the weekly cyber !
- The threat landscape is very dynamic – Cyber news this week
- Cybersecurity is not obvious even for this newsletter !
- Install Slack desktop app on Kali rolling fixing libappindicator3-1 missing dependency
- How to delete all resources in azure to avoid charges after trial on your forced credit card registration
- Proxmox – ZFS – Dead drive on active VM, recover from replicated disk
- Restrict access to proxmox web admin interface
- Migrate your ESXI VMs to proxmox ZFS
- Install your VPN server with pi-hole on OVH VPS in 30 min
- Using raspberry pi 3 as wifi bridge and repeater and firewall
- Raspberry 3 – create a wifi repeater with USB wifi dongle
- raspberry 3 – routeur pare feu point d’acces wifi avec filtrage pub et tracking – router firewall access point with ads and tracking filtering
- Dell XPS 13 touchpad – corriger la sensibilité
- Utiliser Zazeen set top box depuis une connexion videotron
- Fermeture de mon compte facebook – la dernière goutte
- Choisir un kernel par defaut au demarrage de Centos 7.2 – configuration grub2
- Openvpn access server 2.0.25 et android
- Régler la luminosité du laptop par ligne de commande
- chromium outlook web app version complete sous linux
- Nexus 7 2012 – android 5 lollipop solution au probleme de lenteur
- HDD led sur Xubuntu – xfce
- xubuntu 14.04 verrouiller ecran de veille et desactiver mise en veille a la fermeture de l’ecran
- Authentification avec Radmin en utilisant Wine sur Gentoo
- Patcher bash sur une distribution plus supportee comme fedora 11
- Zimbra desktop sous xubuntu 14.04 64bit – fix
- xubuntu 12.10 probleme de son avec VLC – pulse audio – alsa – toshiba L855D – solution
- Evolution sous xubuntu 12.10 – bug affichage a la configuration – solution temporaire
- Booster son acces internet en changeant de DNS pour opendns
- Serveur DLNA sous ubuntu – minidlna
- sshfs sous windows – dokan sshfs
- xubuntu 11.10 Installer le plugin java pour firefox
- Installer Google Earth sur Xubuntu 11.10
- Installer nagios sur Fedora 11 depuis les sources
- Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos
- Installer Varnish depuis les sources sur Fedora 11