Apache 101: 0-WordPress en 15 minutos

Misiles Hellfire no incluidos.
Acercarse / Misiles Hellfire no incluidos.

Recientemente echamos un vistazo al servidor web Caddy. Hoy vamos a hacer una pequeña copia de seguridad de las cosas y veremos A desde la clásica pila LAMP: el servidor web Apache.

Apache tiene una mala reputación por ser viejo, crujiente y de bajo rendimiento, pero esta idea se deriva principalmente de la persistencia de guías antiguas que aún muestran a los usuarios cómo configurarlo de maneras extremadamente anticuadas. En esta guía, instalaremos una gota Ubuntu 20.04 en Digital Ocean con un servidor web Apache configurado correctamente y capaz de manejar niveles de tráfico graves.

Instalación

Después de comenzar una nueva máquina virtual de $ 5 / mes (Digital Ocean los llama «gotitas»), lo primero que haremos es lo que cualquiera debería hacer con cualquier nuevo servidor Linux. Verificamos y luego instalamos las actualizaciones y, dado que una de ellas era una nueva versión del kernel de Linux, reiniciamos el servidor.

[email protected]:~# apt update
[email protected]:~# apt dist-upgrade
[email protected]:~# shutdown -r now

Con ese poco de limpieza secundaria fuera del camino, es hora de instalar Apache y el lenguaje PHP requerido por la mayoría de las aplicaciones web.

[email protected]:~# apt install apache2 php-fpm

Los amigos no permiten que los amigos usen mod_php de manera inapropiada

Quiero dejar lo que tenemos increíblemente claro no instalado: no hemos instalado y no instalaremos el archivo mod_php Módulo Apache

[email protected]:~# apt policy libapache2-mod-php
libapache2-mod-php:
Installed: (none)
Candidate: 2:7.4+75
Version table:
2:7.4+75 500
500 http://mirrors.digitalocean.com/ubuntu focal/main amd64 Packages

los mod_php El módulo fue una vez la forma preferida de integrar el soporte de PHP en su servidor web. En general, reemplazó el antiguo método de interfaz de pasarela común (CGI), que pasaba los archivos con extensiones específicas a una aplicación diferente para ser procesados, El más común en aquellos días era Perl.

Mod_php hace las cosas de manera diferente: en lugar de un ejecutable PHP separado que administra el código PHP, el lenguaje PHP se incorpora directamente en el proceso de Apache. Esta es una forma extremadamente eficiente de procesar código PHP, pero es un asco absoluto para un servidor que debe manejar contenido que no sea PHP, porque cada proceso de Apache tiene que llevar consigo un entorno de ejecución PHP completo, limitando drásticamente la cantidad total de procesos de Apache disponible debido a la hinchazón de la memoria.

Instalación mod_php también significa pedirle a Apache que corra con los ancianos prefork MPM (Módulo de proceso múltiple), que no se ajusta a todos los procesos de trabajo disponibles, como el MPM predeterminado moderno, event. La razón mod_php-es prefork—En todos los aspectos es que son muy buenos para un servicio de aplicaciones puro, una carga de trabajo 100% PHP, con todo el CSS, HTML estático, imágenes, etc., descargadas a un servidor o servidor diferente.

Php-fpm es la elección correcta para un servidor web multipropósito

En cambio, instalamos el php-fm, PHP FastCGI Process Manager. En este modelo, Apache no incorpora las capacidades de administración de PHP en los procesos de Apache, en cambio, Apache pasa sus necesidades de ejecución de código a un grupo de trabajadores dedicados de PHP, quienes a su vez devuelven los resultados a Apache.

La transferencia de funciones de ejecución de PHP a un conjunto de subprocesos de trabajo PHP dedicados permite a Apache usar su escalamiento más moderno y mejor event Gerente de MPM. También significa que cada subproceso Apache se puede ejecutar sin la mayoría de un entorno de ejecución de PHP, lo que reduce drásticamente la cantidad de RAM necesaria para cada subproceso.

Los informes de GTMetrix son una herramienta valiosa para los administradores web que desean optimizar la entrega de sus sitios.
Acercarse / Los informes de GTMetrix son una herramienta valiosa para los administradores web que desean optimizar la entrega de sus sitios.

La primera página de mi blog personal tiene 31 solicitudes HTTPS separadas. Diez de estos son de otros dominios: fonts.googleapis.com, fonts.gstatic.com y mi instancia Matomo. Index.php en sí es otro y los veinte restantes son archivos estáticos proporcionados por el mismo servidor.

RAM es fácilmente el recurso más valioso en esa VM, y dado que ahora sabemos que estoy ofreciendo archivos estáticos con una proporción de aproximadamente 20: 1 en comparación con las páginas dinámicas, obviamente no debería desperdiciar RAM en un entorno PHP completo para cada proceso de trabajo de Apache.

Habilitar php-fpm e instalar los paquetes de soporte restantes

La mayoría de las aplicaciones web del mundo real querrán instalar un grupo de módulos PHP adicionales. Si quisiéramos instalar WordPress, por ejemplo, nos gustaría la siguiente lista completa de extensiones PHP:

[email protected]:~# apt install php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-mysql 
                           php-xml php-intl php-mysql php-cli php-ldap php-zip php-curl

Maldición. Si no está familiarizado con el uso de la barra diagonal inversa allí, es una forma de forzar un salto de línea en el terminal sin afectar la ejecución del código: por lo que es realmente una gran línea, instalando todas las extensiones PHP adicionales que WordPress querrá

Con los instalados, necesitamos habilitar php-fpm en sí, con los siguientes comandos:

[email protected]:~# a2enmod proxy_fcgi
[email protected]:~# a2enconf php7.4-fpm.conf
[email protected]:~# systemctl restart apache2

Eso es todo: ahora hemos creado nuestro entorno de servidor web completo y listo para WordPress. El siguiente paso es crear una base de datos MySQL para WordPress, que se ve así:

[email protected]:~# mysql -u debian-sys-maint -p
mysql> create database wordpress;
mysql> create user 'wordpress'@'localhost' identified by 'supersecretpassword';
mysql> grant all on wordpress.* to 'wordpress'@'localhost';
mysql> quit;

Ahora estamos listos para crear uno nuevo. vhost—A host virtual – para mantener el nuevo sitio de WordPress. Nosotros el podria solo use la configuración de vhost predeterminada, pero no lo haremos, lo haremos de esta manera profesionales y esté preparado para administrar un entorno de múltiples sitios.

Configuración de sitio, módulo y configuración de Apache (¡lo cual no es un error tipográfico!)

Lo que más me gusta de usar Apache en lugar de competir con servidores web es el enfoque altamente segmentado que usa para la administración de la configuración. En los viejos tiempos, que no recuerdo con mucho cariño, un servidor tendría un solo monolítico httpd.conf archivo que puede tener fácilmente miles de líneas y contener configuraciones de servidor globales y todas las configuraciones individuales para cada sitio arriba el servidor. ¡Qué asco!

Afortunadamente, Apache finalmente introdujo el Include directiva, que permitía vincular el archivo de configuración principal de Apache con otros archivos de configuración y, sobre todo, directorios que se esperaba que estuvieran llenos de archivo de configuración. Esto permitió a los administradores del sitio crear un individuo corto archivos de configuración para cada sitio y, simplemente descargándolo al directorio apropiado, las configuraciones de ese sitio se agregan automáticamente a la configuración del servidor existente después de un systemctl reload apache2 (o, en máquinas sin resolver, apache2ctl reload)

La buena gente de Debian, a su vez, tomó ese concepto y corrió con él. Cuando instala Apache en un sistema moderno derivado de Debian como Ubuntu, automáticamente crea los siguientes directorios:

/etc/apache2
/etc/apache2/sites-available
/etc/apache2/sites-enabled
/etc/apache2/mods-available
/etc/apache2/mods-enabled
/etc/apache2/conf-available
/etc/apache2/conf-enabled

Entonces, digamos que desea agregar un formulario, por ejemplo php-fpm él mismo – a Apache. No necesita andar con el archivo de configuración global en /etc/apache2/apache2.conf, porqué el php-fpm el paquete abandona su configuración y carga los archivos en /etc/apache2/mods-available. En realidad, aún no han entrado en vigor porque solo están presentes mods-availableNo mods-enabled—Pero recuerda cuando ejecutamos el comando a2enmod proxy_fcgi en la ultima seccion?

[email protected]:~# a2enmod proxy_fcgi
Considering dependency proxy for proxy_fcgi:
Enabling module proxy.
Enabling module proxy_fcgi.
To activate the new configuration, you need to run:
  systemctl restart apache2

Lo que realmente hizo ese comando fue symlink el archivo de configuración /etc/apache2/mods-available/proxy_fcgi.load para /etc/apache2/mods-enabled/proxy_fcgi.load. Y la próxima vez que Apache se reinicie como está pidiendo, Apache lo hará Include todos los archivos en mods-enabled—Incluyendo a nuestro nuevo amigo, proxy_fcgi.load—Y entonces tendremos el proxy FastCGI disponible.

Si recuerdas, hicimos otro comando justo después de eso:

[email protected]:~# a2enconf php7.4-fpm
Enabling conf php7.4-fpm.
To activate the new configuration, you need to run:
  systemctl reload apache2

Ese comando tiene un enlace simbólico /etc/apache2/conf-available/php7.4-fpm.conf para /etc/apache2/conf-enabled/php7.4-fpm.confy de la misma manera, Apache lo hará Include todo dentro conf-enableden cada inicio, por lo que ahora hemos habilitado las siguientes directivas de configuración necesarias:

[email protected]:/etc/apache2/conf-available# cat php7.4-fpm.conf
# Redirect to local php-fpm if mod_php is not available

   
      # Enable http authorization headers
      
         SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
      

      
         SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"
      
      
         # Deny access to raw php sources by default
         # To re-enable it's recommended to enable access to the files
         # only in specific virtual host or directory
         Require all denied
      
      # Deny access to files without filename (e.g. '.php')
      
         Require all denied
      
   

Ahora, si no ves belleza en esto … No sé qué decirte. Si está confundido acerca de cómo Apache maneja exactamente los archivos PHP cuando los encuentra, tiene un soltero archivos donde puede mirar para ver esas salas de configuración e solamente Esas habitaciones de construcción. Puede verlo sin confundirse y molestarse por cientos o miles de otras líneas de configuración, y puede hacerlo cambio si es necesario sin temor a arruinar accidentalmente esos otros cientos o miles de líneas de configuración que no se tocan, ya que solo trabaja en este único archivo independiente.

Esto no es solo para las salas de configuración proporcionadas por el sistema: nada le impide escribir sus salas de configuración para un propósito particular, dejándolas caer /etc/apache2/conf-available, es a2enconfing como lo desee. ¿Quieres conocer todos los módulos habilitados? ls /etc/apache2/mods-enabled. ¿Quieres ver si hay otros disponibles? mods-available. Lo mismo ocurre con las configuraciones. conf-enabled es conf-availableSalir (vhost) configuraciones en sites-enabled es sites-available.

Esto hace que el corazón de mi administrador del sistema cante, realmente lo hace.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *