Caddy ofrece TLS, HTTPS y más en un servidor Web Go sin dependencia

¿Listo para la producción en pocas líneas? Coloranos interesados.
Ampliar / ¿Listo para la producción en pocas líneas? Coloranos interesados.

Ayer, el servidor web Caddy alcanzó un hito importante, con su versión 2.0.0. Caddy se define a sí mismo como «The Ultimate Server», sin dependencias, adquisición automática y renovación de certificados TLS y archivos de configuración mucho más pequeños que Apache o Nginx.

Lee Hutchinson, editor senior de tecnología, expresó tanto la curiosidad de Caddy como su inercia personal en el juego Ars:

Caddy es una aplicación donde cada vez que la veo o pienso en ella, digo «Debería bromear sobre eso, se ve limpio» y luego nunca lo hago. Estoy tan encantado en mi pila de halógeno – pintura – nginx que explotar parece más un problema de lo que vale.

Nunca había oído hablar de Caddy hasta que Lee lo mencionó, pero conozco un llamado a la acción cuando escucho uno.

Los primeros (mis) pasos del niño con Caddy

Realmente divertido de usar, dijeron ... HTTPS funciona, dijeron. Advertencia de spoiler: un poco depende de cómo lo hagas.
Ampliar / Realmente divertido de usar, dijeron … HTTPS funciona, dijeron. Advertencia de spoiler: un poco depende de cómo lo hagas.

Después de ver una breve animación que demuestra el rápido despliegue de Caddy, me sumergí en los documentos de inicio rápido HTTPS vinculados. Esto resultó no ser la mejor manera de experimentar Caddy por primera vez, en pocas palabras. El tutorial de inicio rápido cubrió la instalación real de Caddy y ya había salido de la página de lanzamiento de Github, por lo que mi siguiente pensamiento fue buscar Caddy en los lugares habituales en una nueva máquina virtual Ubuntu 20.04.

cuando apt search caddy vino vacío, lo intenté snap search caddy en cambio – y, bingo:

No puede ser tan fácil ... ¿verdad?
Ampliar / No puede ser tan fácil … ¿o sí?

Jim Salter

El caddy no solo estaba disponible en los repositorios instantáneos de Ubuntu, ¡sino que era 2.0.0, la versión recién lanzada! Entonces hice un snap install caddyy salí a las carreras. Desafortunadamente, no había ido bien en las carreras. El complemento caddy no solo instaló el caddie, sino que también lo inició como un servicio, en algún lugar, que descubrí cuando intenté seguir la directiva de inicio rápido para ejecutar caddy start en cualquier directorio aleatorio donde había creado un archivo llamado Caddyfile.

Incluso si fuera posible para hacer que Caddy ejecutara mis ofertas de esta toma, nunca entendí dónde guardaba la configuración de Caddy, así que la única forma de hacerlo funcionar fue snap stop caddy, ps wwaux | grep caddy | grep -v grep para asegurarse de que el complemento aún no tuviera un proceso furtivo (que a veces sí lo hizo) y elimine en ese caso, luego ejecútelo manualmente.

Para ser honesto, los documentos de inicio rápido parecen distinguir manualmente la ejecución de caddy como algo bueno, y muchos de los mejores resultados que encontré cuando busqué en Google «instalar caddy» me enseñaron curl https://getcaddy.com/ directamente a sudo bash -s personal.

Como administrador del sistema, no desarrollador y administrador del sistema especialmente consciente de la seguridad, tuve una reacción bastante violenta a ese consejo. Todavía me hace parpadear mirada en eso. Por favor, amigos, no solo canalicen Internet directamente en el cerebro de su sistema, con privilegios de root.

Instale Caddy de la manera correcta

Afortunadamente, hay caminos mucho más saludables para un feliz Caddy-ing. Hay paquetes nativos para diferentes distribuciones y arquitecturas disponibles en la página de lanzamiento de Github, y así es como instalé Caddy más tarde, pero si se aleja de los motores de búsqueda y se limita al documento de instalación de Caddy, hay una ruta aun mejor; mantienen su repositorio apto.

Cuando Caddy se instala directamente desde un .deb a la versión de Github, o desde el repositorio en apt.fury.io, obtienes un servidor web integrado y funcional que está listo para usar, bueno, sobre todo, de todos modos. El archivo caddy predeterminado ejecuta el servidor localhost:80, pero su comportamiento predeterminado también incluye una redirección HTTPS obligatoria, por lo que todo lo que verá en un navegador es «No se puede conectar».

Actualice la línea de host en su Caddyfile desde :80 para localhost y luego haciendo caddy reload le emitirá un certificado de aceite de serpiente automático emitido. Caddy también parece haber intentado agregar el nuevo certificado de aceite de serpiente al almacén de certificados de mi máquina virtual Ubuntu, pero Firefox ciertamente no confió y se nos presentan errores de confianza y advertencias terribles.

Al menos se puede hacer clic en ellos, y finalmente tenemos una prueba de función: una página web predeterminada extrañamente inclinada. Esa página web predeterminada nos dice algo que debería ser obvio ahora: todo esto realmente funcionaría mucho mejor si tuviéramos un dominio real para jugar. Caddy no está limitado a HTTPS / TLS de forma predeterminada, realmente no quiere tener nada que ver contigo sin TLS: esto significa un dominio real, públicamente solucionable.

Cero en WordPress – al final

Ahora que sabía que podía hacer que Caddy funcionara, era hora de que realmente funcionara, o al menos, «lo suficiente» como para escribir un artículo al respecto. Una simple página web estática «hello world» no fue suficiente para una prueba y, dado que WordPress alimenta aproximadamente el 36% de los sitios web del planeta, parecía un excelente punto de partida.

También quería hacer una comparación directa con un servidor web más tradicional, ya que mi primera exposición a Caddy fue su afirmación de ser simple, divertido y mucho más fácil de configurar. Francamente, estaba un poco dudoso acerca de la última declaración: la mayoría de las veces, cuando un desarrollador le dice que algo es «fácil de configurar», en realidad deberían decir «Conozco muy bien todas las trampas aquí».

Hay una trampa de novatos al acecho en este ejemplo Caddyfile: la directiva try_files no es necesaria para la mayoría de los sitios y ha causado nuestro ciclo de redireccionamiento de WordPress.
Ampliar / Hay una trampa de novatos al acecho en este ejemplo Caddyfile: la directiva try_files no es necesaria para la mayoría de los sitios y ha causado nuestro ciclo de redireccionamiento de WordPress.

Jim Salter

Una de estas trampas es el ejemplo Caddyfile presentado en https://caddyserver.com/docs/caddyfile. El tutorial le dice con orgullo que «es un Caddyfile real listo para producción que sirve a un sitio Craft CMS totalmente administrado con HTTPS». Lo que no le dice es que una de las directivas en ese archivo simple romperá la mayoría de los sitios No soy el Craft CMS. la try_files la directiva mostrada reemplaza el try_files directiva implícita en fastcgi directiva en sí, y provocó un ciclo de redireccionamiento desagradable en el panel de WordPress una vez que lo instalé y lo ejecuté.

Caddy 2.0.0 vs Apache 2.4.41: ¡lucha por la instalación!

Tenía dos preguntas importantes sobre Caddy 2.0.0: ¿era realmente más fácil de configurar que un servidor web más convencional y cuánto funcionaría? Si este fue un combate de boxeo, Caddy fue claramente el contendiente y elegí a Apache como el campeón defensor para desafiarlo.

Encontré dos nuevas gotas de Digital Ocean con Ubuntu 20.04 y configuré WordPress desde cero en cada una de ellas: una con Caddy 2.0.0 de su repositorio externo y otra con Apache 2.4 directamente desde los repositorios de Focal Fossa de Ubuntu.

El rumor habitual es que Apache es viejo y lento en comparación con los otros pesos pesados ​​del servicio web común, Nginx. Gran parte de esta reputación no se merece: Apache siempre ha existido y guía tras guía, tras guía, aconseja a los usuarios que lo configuren mal. Sí, si configura Apache para usar el antediluviano mod_php el módulo, el rendimiento como servidor de aplicaciones apestará, esto obliga a Apache a usar el prefork MPM.

Si no fuerza Apache en uso prefork, con Ubuntu moderno es el valor predeterminado event Módulo de procesamiento múltiple, que es mucho más ligero. por debajo prefork y mod_php, Apache y PHP se ejecutan como un gigantesco proceso híbrido, que es extremadamente costoso para RAM y poder de procesamiento cuando necesita archivos estáticos como CSS, imágenes o HTML puro.

Cuando evitas mod_php y usar event con php-fpm en cambio, Apache se convierte de una bestia perezosa en un verdadero contendiente que puede caminar de puntillas con nginx.

Pasos comunes de preinstalación

Se requiere mucha instalación para obtener una instancia de WordPress que funcione y que no tenga nada específico que ver con Apache o Caddy. Enumeraré aquí los pasos necesarios, idénticos para ambos servidores web como (posiblemente) configurados.

[email protected]:~# apt update ; apt install mysql-server php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl php-mysql php-cli php-ldap php-zip php-curl
[email protected]:~# grep pass /etc/mysql/debian.cnf

Primero, instalamos el servidor de base de datos MySQL, el administrador rápido de procesos PHP y toda una serie de extensiones PHP que WordPress tendrá que ejecutar correctamente. Entonces obtenemos la contraseña de usuario de mantenimiento de /etc/mysql/debian.cnf, para que podamos instalar una base de datos para usar en nuestra instancia de WordPress.

[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';

Esto fue realmente un poco dolor de cabeza: la sintaxis de MySQL para otorgar privilegios a una base de datos ha cambiado con MySQL 8.0, que ahora es la configuración predeterminada en Ubuntu Focal. ¡La sintaxis que se muestra arriba es correcta!

El otro paso que necesita es un dominio con el que jugar y un DNS funcional que realmente apunte a su servidor. He usado nuevos nombres de host en uno de mis dominios y acabo de actualizar mi archivo de zona BIND para agregarlos. Para alguien con menos infraestructura existente, es más fácil usar el DNS proporcionado en un registrador como Namecheap.

Independientemente de cómo lo administre, necesitará una dirección IP de acceso público, accesible en los puertos 80 y 443 y necesitará un DNS público y resoluble para señalarlo. Los detalles que lamentablemente no entran dentro del alcance aquí

Instalación y configuración de Apache 2.4

No es sorprendente que Apache esté allí en el repositorio principal de Ubuntu 20.04. La instalación es lo más simple posible, con una mínima reconfiguración necesaria para que las cosas funcionen.

[email protected]:~# apt install apache2 python3-certbot-apache
[email protected]:~# a2enmod proxy_fcgi
[email protected]:~# a2enconf php7.4-fpm
[email protected]:~# sed -i 's/#ServerName www.example.com/ServerName yourdomain.com/' /etc/apache2/sites-enabled/000-default.conf
[email protected]:~# systemctl restart apache2
[email protected]:~# certbot

Si eso sed el comando te pone nervioso, no lo dejes, es solo un pequeño atajo para alejarte de no poner un nano en medio del flujo de trabajo. Todo yo sed el comando que está haciendo es encontrar la línea comentada en el archivo de configuración de vhost predeterminado, que establecerá el archivo ServerName directiva y reemplácela con una directiva real para usar nuestro nombre de host DNS en funcionamiento.

Eso es todo para configuraciones específicas de Apache: con eso hecho, pasemos a la post-instalación y tengamos un WordPress que funcione.

Instalación y configuración de Caddy 2.0.0

Realmente no he encontrado que Caddy vaya más fácil que Apache. Por supuesto, técnicamente tengo más de 20 años de experiencia en Apache, pero ni siquiera fue mi primer viaje al rodeo con el nuevo software con el mismo propósito.

Estoy omitiendo la mayor parte de la prueba y error que me eluden hacia el objetivo que encontré en el camino para finalmente lograr una configuración de Caddy que funcione, con el interés de hacer que esta comparación sea lo más justa posible con Caddy a pesar de mi propia experiencia. más grande con Apache.

[email protected]:~# echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" > /etc/apt/sources.list.d/caddy-fury.list
[email protected]:~# apt update
[email protected]:~# apt install caddy

En este punto, tengo que salir del flujo de trabajo que tenía con Apache: no hay una opción simple como simplemente descomentar una línea en la configuración predeterminada; Tuve que empezar de nuevo con un nuevo Caddyfile. Utilicé el ejemplo Caddyfile proporcionado en caddyserver.com, pero con la desafortunada trampa novata modificada.

[email protected]:~# cat /etc/caddy/Caddyfile

yourdomain.com
root * /var/www/html

# this wasn't in the sample Caddyfile—
# and without it, Caddy gets no logging at all!
#
log {
output file /var/log/caddy/access.log
format console
}

# this is the noob trap that caused a wp-admin redirect loop
#try_files {path} /index.php?{query}&p={path}

php_fastcgi unix//run/php/php-fpm.sock
file_server

Hasta ahora todo bien, pero la propiedad de la php-fpm La piscina también debe ser cambiada. Por defecto, es propiedad de www-data usuario, pero Caddy funciona como caddyno www-data. Sin actualizar esta autorización, Caddy no tendrá autorización para acceder al socket Unix que php-fpm está operativo desde entonces.

También podríamos evitar esto ejecutando php-fpm en un socket TCP conmutado localhost—Pero esto también requeriría más configuración y daría como resultado una pila de rendimiento menor.

[email protected]:~# sed -i 's/www-data/caddy/g' /etc/php/7.4/fpm/pool.d/www.conf
[email protected]:~$ systemctl restart php7.4-fpm
[email protected]:~$ systemctl restart caddy

Necesitaba un conocimiento mucho más profundo de php-fpm apilar para hacer que las cosas funcionen aquí más que con Apache. Además, no había ningún registro de trabajo disponible en el archivo Caddy de muestra proporcionado y una trampa de novatos en esa muestra que permite una configuración muy inusual (Craft CMS, con una participación de mercado de 0.2% CMS), mientras se detenía la mayoría de configuraciones, incluidas las más comunes en el planeta (WordPress, con una cuota de mercado de 63.3% CMS).

Soy muy consciente de que tengo mucha más experiencia con Apache que con Caddy, pero no veo cómo puede darle razonablemente a Caddy una victoria fácil de usar aquí.

Pasos comunes posteriores a la instalación

También necesitamos descargar WordPress, descomprimirlo y ponerlo en el directorio donde será servido.

[email protected]:~# mkdir -p /var/www
[email protected]:~# cd /var/www/
[email protected]:/var/www# wget https://wordpress.org/latest.tar.gz
[email protected]:/var/www# tar zvxf latest.tar.gz
[email protected]:/var/www# mv html html-dist ; mv wordpress html
[email protected]:/var/www# chown -R $webserveruser html

Bien, tuvimos que confundir un poco las cosas en este paso: Apache realmente no necesita que crees el archivo /var/www directorios y Caddy no te necesita mv html html-dist, ya que no tenía un directorio en /var/www empezar con Pero en aras de eliminar las cosas comunes, llamaremos a esto un empate.

Si alguna pobre alma está tratando de usar esto como una guía para hacer que WordPress funcione, también debo señalar que $ webserveruser no es literal aquí: para Apache, es www-datay para Caddy es caddy.

Una vez hecho esto, estás listo para apuntar el navegador más cercano a https://yourdomain.com/ y recorre la instalación de WordPress.

Caddy 2.0.0 vs Apache 2.4.41: ¡lucha por el rendimiento!

Una vez que WordPress fue instalado y completamente operativo en ambas gotas, llegó el momento de una prueba de rendimiento. Utilicé la venerable herramienta apachebench que se ejecuta en localhost en cada gota para la prueba; esto se proporcionó con el propio Apache en la gota de Apache y se envió con apt install apache2-utils en la gotita del carro.

La versión corta aquí es que Caddy gana. Con un simple ab -c5 -t10 https://yourdomain.com/ ejecutándose en una versión predeterminada de WordPress virgen con la única publicación Hello World, Apache obtiene 37.8 solicitudes por segundo en Caddy’s 42.4. Caddy también envió solicitudes medias ligeramente más rápidas, a 114 ms a 129 ms de Apache, y las solicitudes de percentil 99 más rápido a 182 ms a 184 ms de Apache.

Dicho esto, este es un punto de referencia artificial bastante tonto que no es muy útil, aparte de darnos una idea general razonable del rendimiento del servidor web. Se necesitará un sitio de WordPress del mundo real para sobrevivir a una barra oblicua (¿Arsdotting?) mucha configuración y ajustes más allá de lo que hemos hecho aquí: necesitamos más php-fpm Trabajadores disponibles, necesitamos instalar un complemento de rendimiento de WordPress como W3-Total-Cache instalado, y necesitamos configurar ese complemento de rendimiento para almacenar en caché objetos, archivos, consultas y más.

En el lado de Apache, esto significa instalación php-apc al menos preferiblemente memcached seguirlo y configurar ambos. Tengo que admitir de inmediato que no estoy seguro de cuál o ambos son necesarios para Caddy: veo uno de los engranajes en un gráfico promocional llamado «Almacenamiento en caché», pero no está del todo claro qué implican las capacidades nativas de Caddy. Encontré los documentos para un complemento de caché opcional para Caddy 1.x, pero esto no parece ser aplicable a 2.0.0.

Si realmente necesita obtener el máximo rendimiento de una pila web, se alejará rápidamente de la promesa inicial de Caddy de «instalación fácil y divertida» e ingresará a la rutina habitual de determinación e integridad del administrador del sistema, independientemente de su plataforma. También es probable que sus resultados difieran mucho de una carga de trabajo a otra: «más rápido» para WordPress y «más rápido» para Craft o algo más podrían ser respuestas muy diferentes.

conclusiones

Caddy es un servidor web capaz que parece estar en buenas direcciones con la versión 2.0.0. El consejo de instalación de la versión anterior es solo tuberías curl para sudo bash me hizo rechinar los dientes, pero parece que el proyecto ha madurado considerablemente y ahora va a tener configuraciones mucho más saludables y recomendadas.

También funciona bastante bien, logrando una victoria pequeña pero medible contra Apache 2.4.41 que ejecuta el mpm_event modelo. Esto lo coloca en el mismo estadio que el rendimiento general de nginx. Si está configurado correctamente, Apache, nginx y Caddy tendrán un rendimiento bastante similar, por lo que si el estilo y el diseño general de Caddy flotan en su barco, esta parece ser una opción sólida.

Por otro lado, es difícil superar las décadas de experiencia y flexibilidad que aporta el diseño de configuración de Apache. Si todo lo que le preocupa es uno o dos sitios, es posible que no vea mucha diferencia entre la configuración de Caddy o Apache. Pero si administra sistemáticamente docenas o cientos de sitios, la capacidad de Apache para separar claramente las configuraciones específicas de host virtual en sus archivos individuales puede comenzar a parecer bastante indispensable.

Lo bueno

  • Todo integrado sin dependencias hace que Caddy sea fácil de instalar y actualizar, incluso fuera de los sistemas tradicionales de administración de paquetes
  • Rendimiento de clase mundial en comparación con Apache 2.4.41 (evento MPM) y, por extensión, Nginx
  • Caddy tiene sus propios repositorios aptos para distribuciones basadas en Debian
  • La falta de dependencias hace que Caddy sea extremadamente portátil entre distribuciones, sin posibles conflictos de biblioteca en compilaciones binarias
  • Archivos de configuración cortos, aunque ocasionalmente algo arcanos

El malo

  • La documentación puede ser un poco tosca: los archivos de ejemplo no se pueden usar por completo para casos de uso estándar, faltan funciones, etc.
  • Conflictos entre la sintaxis de configuración v2.0 y v1.x: son casi completamente incompatibles y es fácil terminar accidentalmente en un documento 1.x si está buscando respuestas en Google
  • Los «documentos» y los «tutoriales» a menudo parecen estar en conflicto: algunos se centran en el estilo vaquero que ejecuta la CLI, otros en una configuración orientada al sistema más saludable y tradicional

El feo

  • Solo HTTPS significa certificados de aceite de serpiente y advertencias de seguridad si se encuentra en un entorno sin IP pública y / o DNS que no funciona
  • Una «cuota de mercado de servidores web» muy baja, inferior al 0.1%, según w3techs, significa que usted está en el camino menos transitado
  • Sin administración de paquetes de distribución: usted confía directamente en el proyecto en sí para todo control de calidad y seguridad

Deja una respuesta

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