WordPress sur Lighttpd + APC dans Squeeze (I)

Salut les amis! Je vous apporte une proposition sur la façon de publier un blog basé sur WordPress, avec Lighty comme serveur de page Web, Spawn-FastCGI, PHP, APC Alternative PHP Cache (Alternative PHP Cache), et tout dans Debian Squeeze. Je précise que les traductions que je fais de l'anglais vers l'espagnol sont très gratuites de ma part et peuvent ne pas être tout à fait exactes d'un point de vue linguistique ou sémantique. Personnellement, ils me suffisent.

Et messieurs, cet article est juste le "Porte d'entrée«Dans le monde fascinant des pages Web statiques et / ou dynamiques. Je ne suis pas un expert des serveurs Web. Cependant, beaucoup m'ont déjà demandé quel serveur préférez-vous, Federico, avec le Nginx, le Lighty ou l'Apache? Je réponds toujours à cela avec les trois. Chacun a son charme et l'Apache est l'Apache. Dans les prochains articles, nous aborderons des solutions comme celle-ci avec Nginx et Apache. Au fait, il y a des rumeurs dans le village www sur la fin de Lighty, et la vérité est que Debian 7 le maintient toujours dans ses dépôts. Pour quelque chose, non?

Nous verrons:

• Définitions pour les débutants
• Solution recommandée par Lighty
• Solution que nous aborderons
• Exemple de données de serveur
• Installation des packages requis
• Mise en place et vérification

Définitions utiles pour les débutants

Serveurs Web: C'est la technologie qui a des programmes informatiques implicites qui traitent les applications établissant des connexions bidirectionnelles et / ou unidirectionnelles et synchrones ou asynchrones avec le client, générant ou donnant une réponse dans n'importe quel langage ou application côté client. […] Les Web Services sont nés d'un besoin de standardiser la communication entre les différentes plateformes (PC, Mainframe, Mac, etc.) et les langages de programmation (PHP, C, Java, etc.). Des tentatives antérieures avaient été faites pour créer des normes, mais elles ont échoué ou n'ont pas été suffisamment couronnées de succès, certaines d'entre elles étant DCOM et CORBA, car elles dépendent de l'implémentation du fournisseur DCOM - Microsoft et CORBA - ORB. […] Malgré la limitation de l'utilisation des services Web au protocole HTTP, les services Web n'ont pas été conçus pour un protocole particulier, c'est-à-dire que rien n'empêchait l'utilisation de SOAP sur un autre protocole Internet (SMTP, FTP, etc.). HTTP est principalement utilisé car il s'agit d'un protocole largement utilisé et moins restreint par les pare-feu (les ports tels que FTP sont généralement bloqués, mais HTTP n'est probablement pas bloqué).

Lighttpd: Serveur Web pour les systèmes d'exploitation Unix / Linux et Microsoft Windows. Aussi connu comme légerEst un alternative au serveur Web Apache. Il est conçu pour être sécurisé, rapide (très rapide en fait), conforme aux normes et flexible. Spécialement conçu pour supporter de lourdes charges sans perdre l'équilibre en utilisant peu de RAM et peu de CPU. Fournit des vitesses de réponse élevées. Certains sites qui l'utilisent sont YouTube, Wikipédia et d'autres, qui supportent un trafic important. Il est distribué sous une licence BSD.

De Wikipédia. CGI: Interface d'entrée commune (en anglais Interface de passerelle commune, en abrégé CGI) est une technologie importante sur le World Wide Web qui permet à un client (navigateur Web) de demander des données à un programme exécuté sur un serveur Web. CGI spécifie une norme pour le transfert de données entre le client et le programme. Il s'agit d'un mécanisme de communication entre le serveur Web et une application externe dont le résultat final de l'exécution est des objets MIME. Les applications qui s'exécutent sur le serveur sont appelées CGI.

FastCGI est un protocole pour connecter des programmes interactifs à un serveur Web. FastCGI est une variante de la célèbre Common Gateway Interface (CGI ou Common Input Interface). L'objectif principal de FastCGI est de réduire la charge associée à la connexion du serveur Web et des programmes Ccommun Gmangé Interface, qui permet à un serveur de traiter plus de requêtes en même temps.

Frayer, en informatique fait référence à une fonction qui charge et exécute un nouveau processus enfant ou enfant. Le processus parent ou parent peut attendre la fin du processus enfant ou il peut continuer à s'exécuter de manière asynchrone. La création de nouveaux processus enfants nécessite suffisamment de mémoire pour exécuter le processus parent et le processus enfant, ou plusieurs processus enfants.

Solution recommandée dans la documentation du Wiki Officiel du Lighttpd pour de hautes performances

Si nous lisons le document Docs_ModFastCGI sur le site susmentionné, il y a un paragraphe qui, traduit très librement en espagnol de ma part, dirait:

Reproduction externe: L'exécution des processus FastCGI Spawning directement sur le serveur de pages Web présente certains inconvénients tels que:

• Le processus FastCGI ne peut être exécuté que sur le serveur local.
• Il a la même autorisation que le serveur de pages Web.
• Il a le même répertoire de base que le serveur de pages Web.

Lorsque nous utilisons un serveur FastCGI Séparé -ou Externe- pour alléger la charge du serveur Web, nous devons contrôler le processus FastCGI via un programme externe tel que "spawn-fcgi». Le programme "spawn-fcgi" est utilisé pour démarrer le processus FastCGI dans son propre environnement, corriger son identifiant d'utilisateur, identifiant de groupe, et passez à un autre répertoire racine (chroot).

Je précise que la traduction de Frayer comme nom c'est "oeuf de fruits de mer», Alors qu'en tant que verbe, Frai signifie plus ou moins "frai extérieurement». Les Anglais plaisantent un peu quand ils utilisent ce mot en informatique, non?

Les bases à des fins pratiques est que, grâce à la solution proposée dans la documentation, le processus FastCGI et autant de processus enfants ou enfants que nécessaire seront exécutés sur un ou plusieurs serveurs externes au serveur de page Web. Que lorsqu'il est exécuté sur un serveur différent de celui que nous utilisons comme serveur Web, il sera bien sûr soumis à une charge moindre. Et enfin, que pour utiliser un serveur FastCGI externe, le processus FastCGI doit être démarré et contrôlé par le programme spawn-fcgi.

External Spawning est destiné à ceux qui ont besoin d'installer un ou plusieurs serveurs et de répondre à un grand nombre de demandes, comme dans le cas d'un fournisseur d'accès Internet (FAI), ou des sites tels que blog.desdelinux. Net, etc. Expliquer cette solution en détail est totalement hors de notre portée.

Solution que nous aborderons dans le post

Un seul serveur pour accueillir tous les services nécessaires. Il fonctionne et convient à un site à faible performance, tel qu'un réseau local d'entreprise. La méthode expliquée peut servir de guide à ceux qui ont besoin d'une plus grande disponibilité et sécurité.

Exemple de données de serveur

Nom: web.amigos.cu Adresse IP: 192.168.10.20 Domaine: amigos.cu

Bien sûr, dans un environnement de production -et même de test ou à domicile-, il faut avoir les enregistrements DNS direct et inverse qui se réfèrent à notre serveur.

Installation des packages requis

En tant qu'utilisateur racine nous exécutons:

aptitude installer lighttpd lighttpd-doc php5-cgi php5-gd aptitude installer mysql-server mysql-client php5-mysql

Les fichiers de configuration Lighty sont installés dans / etc / lighttpd. Le programme spwan-fcgi s'installe automatiquement. Les fichiers du package de documentation se trouvent à l'adresse / usr / share / doc / lighttpd-doc. Nous vous recommandons vivement de lire la documentation, qui est en anglais. Pendant l'installation du package Mysql-server, ils nous demandent le mot de passe de l'utilisateur racine pour MySql. Nous vous recommandons d'utiliser le même mot de passe que celui que vous avez déjà déclaré pour cet utilisateur.

Mise en place et vérification

Comme nous en avons terminé avec l'installation du support WordPress, nous devons commencer par la configuration et les tests.

Nous activons les modules Lighty:

lighttpd-enable-mod service fastcgi-php simple-vhost redémarrage de lighttpd

Nous vérifions si notre serveur fonctionne. Nous ouvrons le navigateur et écrivons l'URLhttp://web.amigos.cu, et au moins nous pourrons lister le répertoire / Var / www.

Indice de /

nano /etc/lighttpd/lighttpd.conf

Nous supprimons le commentaire ou le symbole de hachage # ce qui est devant "Mod_rewrite" et ajoutez en dessous de cette ligne "Mod_fastcgi", de sorte que le début du fichier soit le suivant:

server.modules = ("mod_access", "mod_alias", "mod_compress", "mod_redirect", "mod_rewrite", "mod_fastcgi",)

Nous vérifions que le PHP fonctionne correctement. Pour ce faire, nous créons un fichier (temporairement) dans le répertoire / Var / www:

nano /var/www/index.php

et le contenu du fichier précédent sera uniquement:

Ensuite, nous redémarrons le service:

redémarrage du service lighttpd

Si nous pointons dans notre navigateur vers http://web.amigos.cu, nous verrons la page d'information de PHP version 5.3.3-7. Par conséquent, tout fonctionne correctement.

Il est très intéressant de connaître les changements dans la configuration de Lighty après avoir activé le module mod_fastcgi. Par moins /etc/lighttpd/conf-enabled/15-fastcgi-php.conf, nous pouvons le découvrir. Comparez la configuration lue avec celle de la documentation du package lighttpd-doc.

Nous devons maintenant indiquer à Lighty dans quel répertoire il doit diriger le trafic via le port 80, en configurant un hôte virtuel. Les valeurs que nous modifierons dans le fichier /etc/lighttpd/conf-enabled/10-simple-vhost.confIls sont personnels et répondront aux caractéristiques de chaque installation. Nous accepterons les valeurs du répertoire racine du serveur et du répertoire racine des documents, ce que Lighty recommande par défaut et nous ne modifierons que le nom FQDN de l'hôte virtuel.

nano /etc/lighttpd/conf-enabled/10-simple-vhost.conf

Et le contenu final du fichier doit être (pensez à l'adapter à vos besoins):

# /usr/share/doc/lighttpd-doc/simple-vhost.txt server.modules + = ("mod_simple_vhost") ## La racine du document d'un hôte virtuel est document-root = ## simple-vhost.server-root + $ HTTP ["host"] + simple-vhost.document-root simple-vhost.server-root = "/ srv" simple-vhost.document-root = "htdocs" ## l'hôte par défaut si aucun hôte n'est envoyé simple -vhost.default-host = "web.amigos.cu"

Après avoir enregistré les modifications, nous procédons à la création des répertoires nécessaires selon ce qui a été précédemment indiqué. Annuaire / srv a été créé lors de l'installation de Squeeze, nous n'avons donc pas besoin de le créer:

mkdir -p /srv/web.amigos.cu/htdocs

Comme nous avons déjà correctement déclaré l'hôte virtuel et le répertoire associé à notre nom de domaine, nous pouvons nous passer des fichiers créés dans / var / www, et en créer un nouveau. index.php plus personnalisé dans le répertoire / htdocs o répertoire racine des documents de l'hôte virtuel:

rm /var/www/index.* nano /srv/web.amigos.cu/htdocs/index.php

Nous ajoutons le contenu suivant au fichier précédent:

Salut les amis! Bien sûr que tout va bien

Nous enregistrons les modifications et redémarrons le service:

redémarrage du service lighttpd

Rafraîchissons notre navigateur et vérifions que la page affichée a changé et reflète maintenant, en plus de la sortie de la commande phpinfo (), salutation. Il ne sera pas nécessaire de redémarrer le service à l'avenir si nous modifions le contenu de l'index.php ou d'une autre page Web. Cette opération ne sera effectuée que si nous modifions la configuration du Lighty.

Et félicitations les amis!. Nous avons déjà un Squeeze Debian 6.0 avec le serveur de pages Web Lighttpd configuré pour fonctionner avec le langage PHP5 et MySql comme serveur de base de données. Nous avons également la bonne configuration de fichier Lighty Vhost pour gérer plusieurs domaines.

A suivre ...

Et puis, comment vais-je? Demandera M. WordPress. Suivez-nous sur II partie et fin et à la fin de cet article.