Recientemente, echamos un vistazo al servidor web Caddy. Hoy, vamos a retroceder un poco y veremos la A de la pila LAMP clásica: el servidor web Apache.
Apache tiene una mala reputación por ser antiguo, crujiente y de bajo rendimiento, pero esta idea proviene principalmente de la persistencia de guías antiguas que aún muestran a los usuarios cómo configurarlo de formas extremadamente anticuadas. En esta guía, vamos a configurar un droplet de Ubuntu 20.04 en Digital Ocean con un servidor web Apache configurado correctamente y capaz de manejar niveles importantes de tráfico.
Instalación
Después de activar una nueva máquina virtual de $5/mes (Digital Ocean las llama «gotas»), lo primero que haremos es lo que cualquiera debería hacer con cualquier servidor Linux nuevo. Verificamos e instalamos actualizaciones y, dado que una de ellas era una nueva versión del kernel de Linux, reiniciamos el servidor.
root@apache:~# apt update root@apache:~# apt dist-upgrade root@apache:~# shutdown -r now
Con ese pequeño trabajo de limpieza fuera del camino, es hora de instalar Apache y el lenguaje PHP que requieren la mayoría de las aplicaciones web.
root@apache:~# apt install apache2 php-fpm
Los amigos no permiten que sus amigos usen mod_php de manera inapropiada
Quiero dejar increíblemente claro lo que tenemos no instalado: no instalamos ni instalaremos el mod_php Módulo apache.
root@apache:~# 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 favorita de integrar el soporte de PHP en su servidor web. En general, reemplazó el antiguo método CGI (Interfaz de puerta de enlace común), que pasaba los archivos con extensiones específicas a una aplicación diferente para que los procesara; el más común en esos días era Perl.
Mod_php hace las cosas de manera diferente: en lugar de un ejecutable PHP separado que maneja el código PHP, el lenguaje PHP está integrado directamente en el propio proceso de Apache. Esta es una forma extremadamente eficiente de procesar el código PHP, pero apesta absolutamente para un servidor que se espera que maneje contenido que no sea PHP, porque cada proceso de Apache debe traer consigo un entorno de ejecución de PHP completo, lo que limita drásticamente la cantidad de procesos de Apache totales disponibles. debido a la hinchazón de la memoria.
Instalando mod_php también significa exigir que Apache funcione con los ancianos prefork MPM (Módulo de procesos múltiples), que no escala a tantos procesos de trabajo disponibles como el MPM predeterminado moderno, event. La razón mod_php-y prefork—todavía están disponibles es que son muy buenos para un servicio de aplicación puro, una carga de trabajo PHP del 100 por ciento, con todo el CSS, HTML estático, imágenes, etc. descargados en un servidor o servidores diferentes.
Php-fpm es la elección correcta para un servidor web multipropósito
En su lugar, instalamos el php-fpm, el administrador de procesos PHP FastCGI. En este modelo, Apache no trae las capacidades de manejo de PHP a los propios procesos de Apache; en cambio, Apache transfiere sus necesidades de ejecución de código a un grupo de trabajadores de PHP dedicados, que a su vez pasan los resultados a Apache.
La descarga de las tareas de ejecución de PHP a un conjunto de subprocesos de trabajo de PHP dedicados permite a Apache utilizar su escalado más moderno y mejorado. event controlador MPM. También significa que cada subproceso de Apache individual se puede activar sin la mayor parte de un entorno de ejecución de PHP, lo que reduce drásticamente la cantidad necesaria de RAM para cada subproceso.
La página principal de mi blog personal incluye 31 solicitudes HTTPS separadas. Diez de ellos son para otros dominios: fonts.googleapis.com, fonts.gstatic.com y mi propia instancia de Matomo. Index.php en sí mismo es otro, y los veinte restantes son archivos estáticos entregados desde el mismo servidor.
La RAM es fácilmente el recurso más preciado en esa máquina virtual, y dado que ahora sabemos que estoy sirviendo archivos estáticos en una proporción de aproximadamente 20: 1 a páginas dinámicas, obviamente no debería desperdiciar RAM en un entorno PHP completo para cada Apache. proceso de trabajo!
Habilitación de php-fpm e instalación de los paquetes de soporte restantes
La mayoría de las aplicaciones web del mundo real querrán instalar un montón de módulos PHP adicionales. Si quisiéramos instalar WordPress, por ejemplo, querríamos la siguiente lista de extensiones de PHP:
root@apache:~# 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
Uf. Si no está familiarizado con el uso de la barra invertida allí, es una forma de forzar un salto de línea en la terminal sin afectar la ejecución del código: así que en realidad es solo una línea grande, instalando todas las extensiones de PHP adicionales que WordPress querrá.
Con los instalados, necesitamos habilitar php-fpm mismo, con los siguientes comandos:
root@apache:~# a2enmod proxy_fcgi root@apache:~# a2enconf php7.4-fpm.conf root@apache:~# 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í:
root@apache:~# 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 un nuevo vhost—host virtual— para contener el nuevo sitio de WordPress. Nosotros pudo solo use la configuración predeterminada de vhost, pero no vamos a hacerlo, vamos a hacer esto como profesionales y esté preparado para administrar un entorno de múltiples sitios.
Configuración del sitio, el módulo y la configuración de Apache (¡eso no es un error tipográfico!)
Lo que más disfruto de usar Apache en lugar de los servidores web de la competencia es el enfoque altamente segmentado que utiliza para la administración de la configuración. En los viejos tiempos, que no recuerdo con mucho cariño, un servidor tendría un único servidor monolítico httpd.conf archivo que fácilmente podría tener miles de líneas y contener configuraciones globales para el servidor, así como todas las configuraciones individuales para cada sitio en el servidor. ¡Puaj!
Felizmente, Apache eventualmente introdujo el Include directiva, que permitió que el archivo de configuración principal de Apache se vinculara con otros archivos de configuración y, lo mejor de todo, directorios que se esperaba que estuvieran llenos de archivos de configuración. Esto permitió a los administradores del sitio crear un individuo corto archivo de configuración para cada sitio y, con solo volcarlo en el directorio apropiado, haga que las configuraciones de ese sitio se agreguen automáticamente a la configuración del servidor existente después de un systemctl reload apache2 (o, en máquinas que no sean systemd, apache2ctl reload).
La buena gente de Debian, a su vez, tomó ese concepto y lo siguió. Cuando instala Apache en un sistema moderno derivado de Debian como Ubuntu, obtiene los siguientes directorios creados automáticamente:
/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 módulo, como php-fpm sí mismo—a Apache. No necesita jugar con el archivo de configuración global en /etc/apache2/apache2.confporque el php-fpm el paquete simplemente elimina su configuración y carga los archivos en /etc/apache2/mods-available. Todavía no han hecho efecto porque solo están en mods-availableno mods-enabled—pero recuerda cuando ejecutamos el comando a2enmod proxy_fcgi en la última sección?
root@apache:~# 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 ese comando realmente hizo fue symlink el archivo de configuración /etc/apache2/mods-available/proxy_fcgi.load a /etc/apache2/mods-enabled/proxy_fcgi.load. Y la próxima vez que reiniciemos Apache como nos lo pide, Apache Include todos los archivos en mods-enabled—incluido nuestro nuevo amigo, proxy_fcgi.load—y por lo tanto tendremos disponible el proxy FastCGI.
Si recuerdas, hicimos otro comando inmediatamente después de ese:
root@apache:~# a2enconf php7.4-fpm Enabling conf php7.4-fpm. To activate the new configuration, you need to run: systemctl reload apache2
Ese comando enlazado /etc/apache2/conf-available/php7.4-fpm.conf a /etc/apache2/conf-enabled/php7.4-fpm.confy de manera similar, Apache Include todo lo que encuentra en conf-enableden cada inicio, por lo que ahora tenemos habilitadas las siguientes directivas de configuración necesarias:
root@apache:/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 la belleza en eso… No sé qué decirte. Si está confundido acerca de cómo Apache maneja exactamente los archivos PHP cuando los encuentra, tiene una único archivo donde puede mirar para ver esas estrofas de configuración, y solamente esas estrofas de configuración. Puedes verlo sin que te confundan ni te molesten cientos o miles de otras líneas de configuraciones, y puedes editar si es necesario sin temor a arruinar accidentalmente esos otros cientos o miles de líneas de configuración que no está tocando, ya que solo está trabajando en este único archivo autónomo.
Esto no es solo para las estrofas de configuración proporcionadas por el sistema, nada le impide escribir sus propias estrofas de configuración para un propósito particular, colocándolas en /etc/apache2/conf-availabley a2enconfing ellos como se desee. ¿Quieres conocer todos los módulos que están habilitados? ls /etc/apache2/mods-enabled. ¿Quieres ver si hay más disponibles? mods-available. Lo mismo ocurre con las configuraciones en conf-enabled y conf-availabley sitio (vhost) configuraciones en sites-enabled y sites-available.
Eso hace que mi corazón de administrador de sistemas cante, realmente lo hace.
