Ejemplo completo y tutorial de Webinoly

Cristhian Martínez Ochoa

Seguramente ya has leído y experimentado nuestra Guía Rápida – la ya famosa instalación de Webinoly en menos de 5 minutos -, donde en cuestión de minutos tu servidor Nginx y tu primer sitio están listos y completamente configurados.

En el siguiente tutorial mostraremos algunos ejemplos comunes y casos prácticos con un grado de complejidad ligeramente mayor usando Webinoly con el objetivo de mostrarte algo del potencial de esta herramienta de manera que puedas usarlo como guía para aprender de manera práctica el uso de algunos comandos.

Instalación personalizada de Webinoly

Actualizar tu sistema operativo debiera ser siempre tu primer paso: sudo apt update && sudo apt -y upgrade

Empezaremos instalando Webinoly con la opción “-clean”, esto significa que solo se instalará Webinoly, pero aún no se instalará ningún paquete extra en el servidor.

wget -qO weby qrok.es/wy && sudo bash weby -clean

A continuación modificaremos algunos valores previo a la instalación de los paquetes.

# Webinoly Archivo de Configuración
sudo nano /opt/webinoly/webinoly.conf

# Modificar variables
max-mb-uploads:200
nginx-ppa:mainline
timezone:America/Mexico_City

Definimos un máximo en PHP para carga de archivos de 200Mb, instalaremos la rama “mainline” de Nginx y definimos la zona horaria de nuestra preferencia.

Ahora estamos listos para instalar y configurar todos los paquetes necesarios en el servidor. Usamos la opción “lemp” para una instalación, configuración y optimización completa de Nginx, PHP y MariaDB (MySQL).

sudo stack -lemp

Como referencia debes consultar la documentación oficial de Webinoly, además de las instrucciones de instalación.

Suscríbete a nuestro Newsletter para recibir una notificación cuando una actualización de Webinoly esté disponible.

Herramientas de desarrollo

Iniciaremos por crear un sitio de desarrollo en un subdominio:

sudo site dev.example.com -wp -env=development

El tipo de entorno WP “development” habilita de manera automatica el modo “debug” de WordPress, desactiva la cache y pone “noindex” para buscadores.

Para acceder al área de administradores del nuevo sitio WordPress es necesario crear un usuario para la autenticación HTTP, ya que es un área protegida.

sudo httpauth -add

Una vez terminado el desarrollo vamos a configurar un sitio de muestra para aprobación del cliente.

sudo site staging.example.com -env=staging -clone-from=dev.example.com

El entorno “staging” desactiva el modo debug, desactiva la cache y sigue en “noindex” para los buscadores.

Los sitios puedes ser activados o desactivados para evitar visitantes inesperados según sea necesario:

sudo site dev.example.com -off
sudo site dev.example.com -on

Webinoly cuenta con las funciones del comando “log” para además de visualizar los eventos en tiempo-real, también nos facilita la activación y control de los logs de WordPress muy útil cuando desarrollamos temas y plugins, o los logs de aplicaciones como PHP y MySQL, entre otros, siempre necesarios durante el proceso de desarrollo de casi cualquier proyecto.

Una vez finalizado el projecto podemos sobrescribir el sitio anterior con el nuevo en el entorno de producción:

sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on

El modo debug se desactivará y el indexamiento se activará en buscadores. Además, el cache es habilitado en el comando anterior.

Y finalmente hacemos la entrega del proyecto agregando un certificado SSL al sitio.

sudo site example.com -ssl=on

Finalmente, haremos una copia local donde actualizaremos el sitio de manera frecuente:

sudo site local.example.com -env=local -clone-from=example.com

Para enviar las actualizaciones a producción:

sudo site example.com -clone-from=local.example.com -cache=on -env=production -overwrite=on

Creando sitios con Webinoly

La empresa ha crecido y nuestro cliente ha creado un proyecto sin fines de lucro, por lo que ha adquirido un dominio “.ORG” para promocionarlo.

Proponemos una sola pagina HTML con la información general del proyecto y datos de contacto, incluyendo un formulario para que los visitantes nos envíen sus dudas y algún representante se ponga en contacto con ellos.

Un proyecto realmente sencillo, por lo iniciamos creando el sitio con soporte PHP para ejecutar el formulario de contacto.

sudo site example.org -php

Y habilitamos el acceso SFTP para subir los archivos del nuevo sitio.

sudo webinoly -login-www-data=on

Tras una serie de revisiones se finaliza el proyecto y entregamos el sitio, no sin antes agregar un certificado SSL.

sudo site example.org -ssl=on

WordPress instalado en un subdirectorio

Finalmente el cliente decide agregar un blog para publicar artículos, por lo que de manera rápida y sencilla agregamos un sitio WordPress instalado en un subdirectorio del sitio PHP actual.

sudo site example.org -wp=custom -subfolder=/articulos

Debido a que serán miles de publicaciones en este sitio, se decidió usar una base de datos externa del servicio RDS de Amazon Web Services, por lo que usamos la opción “custom” para instalar WordPress y de esta manera Webinoly nos solicitará los datos para conectar con la base de datos y configurar el sitio automáticamente.

Además, como medida adicional han solicitado remover la autenticación HTTP para ingresar al área de administradores de WordPress de este sitio en específico. Aunque no es recomendable, es necesario por la cantidad de autores y usuarios que utilizará este sitio.

sudo httpauth example.com -wp-admin=off -subfolder=/articulos

Muy importante activar la cache para WP:

sudo site example.org -cache=on -subfolder=/articulos

WordPress Multisite

La empresa de nuestro cliente ha crecido y después de varias actualizaciones y mejoras al sitio principal example.com, ahora nos solicita agregar a este sitio un área privada para publicaciones internas de la empresa. Además de un nuevo sitio para la recientemente creada escuela para vender certificaciones de la empresa.

La primer decisión es convertir el sitio principal en “Multisite” de esta manera podremos agregar sitios y administrarlos desde un mismo lugar.

sudo site example.com -multisite-convert

Configuramos el sitio con la opción “subdirectorio” y veremos que Webinoly de manera automatica detecta nuestra selección y realiza todas las configuraciones necesarias.

Creamos un nuevo sitio dentro de WordPress Multisite: example.com/members el cual se administrará de manera independiente. Y además agregamos autenticación HTTP para restringir el acceso únicamente a empleados.

sudo httpauth example.com -path=/members

Anteriormente usaban un dominio exclusivo example.net para un sitio privado donde alojaban un viejo blog con algunas publicaciones internas. Se ha decidido migrar el contenido del viejo blog al nuevo sitio y área para miembros, por lo que la mejor estrategia es redireccionar el viejo dominio.

sudo site example.net -forward=https://example.com/members

Ahora, por ejemplo: example.net/news será redireccionado de manera automática a example.com/members/news.

WordPress Multisite con dominios mapeados

Una de las características actuales de WordPress que en lo personal más me gustan es que ya no es necesario usar un plugin para hacer “Domain Mapping” y esta función ahora la encontramos de manera nativa.

¿Qué quiero decir con esto?

Pues que ya es posible usar un dominio independiente para cada subsitio de tu instalación multisite, es decir, en lugar de usar un subdirectorio o un subdominio, puedes usar un dominio nuevo y de esta manera administrar diferentes sitios web completamente independientes desde una misma instalación de WordPress.

Te recomiendo consultar la documentación oficial “WordPress Multisite Domain Mapping“. Webinoly integra de manera nativa esta función como se describe en el ejemplo siguiente.

Para crear el nuevo sitio de la escuela hemos decidido usar esta opción. Creamos en la instalación Multisite un nuevo sitio: example.com/escuela al cual accederemos usando el nuevo dominio www.example.edu como se muestra a continuación:

sudo site example.edu -parked=example.com -domain-mapping-wp-id=2

Ya hemos creado dos sitios independientes usando dos dominios diferentes y administrados desde una misma instalación de WordPress.

Agregamos un certificado SSL y forzamos el uso de “www”.

sudo site example.edu -ssl=on -root=example.com
sudo site example.edu -force-redirect=www

Este sitio en especifico será administrado por un departamento en la empresa del cliente distinto a los demás sitios, por lo que han solicitado crear usuarios independientes para la autenticación HTTP.

sudo httpauth example.edu -add

De esta manera agregamos todos los usuarios necesarios y que solo tendrán acceso a este sitio, además los usuarios con acceso general que se crearon en los sitios anteriores, no tendrán acceso a este sitio.

Finalmente, FastCGI debe ser habilitado y debido a que este sitio usa query-strings para mostrar contenido en diferentes idiomas, debemos agregar una excepción a FastCGI para almacenar en caché estas páginas.

sudo site example.edu -cache=on
sudo webinoly -query-string-cache=lang

Algunos sitios adicionales

En el sitio del proyecto example.org tienen un repositorio de archivos para descarga en el servicio S3 de AWS, el cual necesitan acceder desde su propio dominio.

Vamos a crear un sitio “Reverse Proxy” para acceder con nuestro propio dominio al repositorio en S3.

sudo site download.example.org -proxy=[https://s3.amazonaws.com/download.example.org/] -dedicated-reverse-proxy

Y agregamos un certificado SSL:

sudo site download.example.org -ssl=on -manual=http

Ahora podemos acceder al repositorio usando: download.example.org/file.jpg.

Para la administración de la flotilla de autos de la empresa han implementado un software de seguimiento GPS (Java App) llamado Traccar, el cual viene configurado para usar el puerto 8082 y necesitamos integrarlo con nuestros sitios.

sudo site gps.example.com -proxy=[localhost:8082]

Cualquier app/site de tu preferencia puede ser configurado de esta manera: Laravel, Java, Node, Angular, React, Vue, etc.

Y le agregamos un certificado SSL indicando la ruta donde se encuentra instalado el software de rastreo.

sudo site gps.example.com -ssl=on -root-path=/opt/traccar/web

Y finalmente el equipo de desarrollo de la empresa se encuentra desarrollando un nuevo sistema interno de tickets usando un framework de PHP y para su acceso y alojamiento en el servidor estaremos creando un nuevo sitio:

sudo site internal.example.com -mysql

Despues de ejecutar el comando se muestran los datos de la base de datos recién creada que usaremos para configurar la nueva aplicación de tickets en el servidor. Básicamente es un sitio PHP con una base de datos.

En resumen…

Hemos creado una cantidad de sitios con requerimientos muy distintos.

  • example.com (WP Multisite)
    • example.com/members (Subsitio protegido)
    • www.example.edu (Subsitio con dominio mapeado y auth desabilitada)
  • gps.example.com (Java App con Nginx Reverse proxy)
  • internal.example.com (PHP con MySQL)
  • example.org (PHP)
    • example.org/artículos (WP en subfolder con auth independiente y base de datos externa)
  • download.example.org (Dedicated Reverse Proxy a S3)
  • example.net (Redireccionado a example.com/members)

Respaldos con Webinoly

Con Webinoly vienen pre instalados Duply y Duplicity, un par de herramientas para realizar respaldos en prácticamente cualquier medio conocido. En este tutorial usaremos los respaldos a AWS S3 y los respaldos locales.

Webinoly soporta de manera nativa cualquier servicio Compatible con S3, como: Backblaze B2, Digital Ocean Spaces, Wasabi, Vultr Object Storage, Linode Object Storage, DreamObjects, etc.

Empezaremos por realizar un respaldo completo de todo el directorio de datos de nuestros sitios /var/www, los respaldos se realizan de manera incremental, por lo que solo la primera vez se envía el total de los datos, después solo se envían los cambios.

Para conectarnos con nuestro bucket en S3 debemos contar con las credenciales IAM necesarias, en este caso nuestro servidor es una instancia EC2 de AWS a la que hemos adjuntado un IAM Role, por lo que no es necesario guardar las credenciales en nuestro servidor.

sudo webinoly -aws-s3-credentials=awsiamrole

Con esto le indicamos a Webinoly que tenemos un IAM role adjunto en nuestro servidor, por lo que no es necesario introducir las credenciales.

Ahora estamos listos para configurar el primer respaldo:

sudo webinoly -backup=s3 -profile=DataBackup -bucket=america/data -source=/var/www -max-age=3M

Una de las funciones que personalmente encuentro mas útil, es la posibilidad de incluir un respaldo de una base de datos que se realizará de manera automática inmediatamente antes de ejecutar el respaldo que configuramos en el paso anterior.

sudo webinoly -backup=s3 -profile=DataBackup -add-db-pre=example.com -destination=/var/www/example.com/db-backup -max=10 -bucket=america/db_com
sudo webinoly -backup=s3 -profile=DataBackup -add-db-pre=example.org -subfolder=/articles -max=3

Es decir, cada que ejecutemos el respaldo “DataBackup”, primero se realizará el respaldo de ambas bases de datos de los sitios WordPress configurados en el paso anterior.

Además, en AWS es posible configurar la replicación automática de un bucket S3, en este caso podemos replicar el bucket “america” a una región distinta, por ejemplo, en Asia.

Ahora agregamos un CronJob para ejecutar este respaldo de manera automática todos los días a las 3am. Ejecutamos sudo crontab -e y agregamos las siguientes líneas:

0 3 * * * sudo webinoly -backup=s3 -profile=DataBackup -run

# Respaldo extra para la base de datos de ambos sitios
0 15 * * * sudo webinoly -backup=local -wp=example.com -max=10 -bucket=america/db_com
30 15 * * * sudo webinoly -backup=local -wp=example.org -max=5

# Respaldo de un log del sistema de tickets
30 3 * * * sudo webinoly -backup=s3 -send-to-s3=/var/log/internal.log -bucket=america/internal

En caso de usar un usuario distinto a root, como es el caso en AWS, es necesario agregar la ruta del usuario antes de ejecutar ‘RUN’ un respaldo en el Cron (root):

0 20 * * * env HOME=/home/user sudo webinoly -backup=s3 -profile=name -run

En resumen, hemos configurado los siguientes respaldos:

  • Diariamente a las 3:00am
    • Respaldo local de la base de datos /var/www/example.com/db-backup del sitio example.com y se envía de manera automática a S3 a la carpeta /db_com.
    • Respaldo local de la base de datos $HOME/webinoly-backups/example.com del sitio example.org.
    • Respaldo en S3 de todo el directorio de datos, incluyendo el respaldo de la base de datos de example.com por estar dentro de este directorio.
    • Respaldo en S3 del log del sistema de tickets.
  • Diariamente a las 3:00pm
    • Respaldo local de la base de datos $HOME/webinoly-backups/example.com del sitio example.com y se envía de manera automática a S3 a la carpeta /db_com.
    • Respaldo local de la base de datos $HOME/webinoly-backups/example.org del sitio example.org.

Como puedes observar la base de datos se respalda dos veces por día y en el caso de example.com contamos con 3 copias de los respaldos (local, américa bucket, asía bucket) además de la original. Y si no es suficiente, en cada bucket hay dos copias de la DB, una en la carpeta /data y otra en /db_com. ¿Suficiente?

Rendimiento, seguridad y ajustes adicionales de Nginx

Normalmente la FastCGI cachede NGINX viene configurada por Webinoly para expirar cada 30 días, esto es un valor recomendado para sitios web de muy bajo tráfico.

Les explico de manera breve, la primera vez que visitas una determinada página de tu sitio esta queda guardada en la cache FastCGI y así será hasta cumplir el periodo para expirar.

Si nuestro sitio tiene poco tráfico y tenemos configurado un valor, por ejemplo de “1 hora”, la mayoría de los visitantes recibirá una versión no guardada en cache de la página, por lo que no serviría de nada tener la cache habilitada.

Para modificar la configuración y valores de FastCGI en Webinoly utilizamos el siguiente comando:

sudo webinoly -cache-valid

Vamos a configurar tiempos de 1 hora en cache, 20 minutos de inactividad y 10 minutos para redirecciones [1h,20m,10m]. Esta sería una configuración que podría funcionar muy bien en sitios de muy alto tráfico.

También vamos a modificar el acceso a las herramientas del servidor. 

sudo webinoly -tools-port=18915
sudo webinoly -tools-site=example.com

Ahora accederemos con el dominio y puerto asignados: example.com:18915.

Terminado el desarrollo del proyecto, vamos a modificar nuevamente la respuesta predeterminada de Nginx como medida de seguridad.

sudo webinoly -default-site=blackhole

Aun cuando ya tenemos instalado Postfix para el envío de correos electrónicos, prefiero usar un servicio SMTP externo como Amazon SES, Mailgun, SendGrid, etc.

sudo webinoly -smtp

Además, configuraremos algunas cabeceras HTTP.

Activamos la opción “preload” para HSTS y configuramos de manera personalizada el “Referrer” y “Content-Security-Policy”.

# Webinoly Archivo de Configuración
sudo nano /opt/webinoly/webinoly.conf

# Modificar variables
header-hsts:preload
header-referrer:origin-when-cross-origin
header-csp:default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
header-permissions:floc

Certificados Wildcard

De manera opcional pudiéramos usar un solo certificado para los sitios:

  • example.com
  • example.com/members
  • gps.example.com
  • internal.example.com

Removemos los certificados actuales de los sitios -ssl=off y creamos un certificado de tipo wildcard para el sitio principal.

sudo site example.com -ssl=on -wildcard

Y finalmente agregamos el resto de los sitios a este certificado.

sudo site gps.example.com -ssl=on -add-to-wildcard=example.com
sudo site internal.example.com -ssl=on -add-to-wildcard=example.com

API-Interna de Webinoly

El cliente finalmente tenia un requerimiento especial, debido a un complejo proceso de auditorias internas llevan un estricto control de sus servidores, por lo que necesita que cada sitio que es creado en su servidor sea reportado a una API de su sistema y al finalizar se muestre un mensaje.

Haciendo uso de la API-Interna de Webinoly podemos agregar cualquier accion en casi cualquier punto de la ejecución de Webinoly. Siguiendo las instrucciones, renombramos y usamos el archivo /opt/webinoly/lib/api-events agregando el siguiente código:

api-events_catch_status() {
	if [[ $1 == "si1" ]]; then
		wget --timeout=10 -t 1 -qO- https://api.example.net/?crearsitio=true
	elif [[ $1 == "sie" ]]; then
		echo "Todos los sitios son reportados a la API de example.net en cumplimiento de la auditoria de sistemas informaticos."
	fi
}

Conclusión

Con Webinoly como pudimos observar en el ejemplo anterior nuestra idea es siempre facilitar las tareas rutinarias para administrar un servidor web Nginx, todo está a un comando de distancia.

De esta manera es que Webinoly se a convertido en la herramienta predilecta de los profesionales tanto en el desarrollo web, como en las areas empresariales de DevOps e Ingenieria de Software como un aliado para automatizar y agilizar el despliegue de servidores.

Si tienes alguna sugerencia, idea o comentario, por favor visita y únete a nuestra Comunidad.

,