Administrar Sitios

El comando “Site” nos permite administrar los sitios web hospedados en el servidor. Crea cualquier tipo de sitio en tu nuevo servidor, añade un certificado SSL, activa FastCgi Cache para tu instalación WordPress y más funciones que te permitirán tener control total sobre tus sitios de manera fácil y confiable, siempre a un comando de distancia y sin complicaciones.

Sintaxis:

sudo site <dominio> <opcion> <opcion2>

Opciones:

  • -cache
  • -clone-from
  • -delete
  • -delete-all
  • -empty
  • -force-redirect
  • -forward
  • –html
  • -info
  • -list
  • -multisite-convert
  • –mysql
  • -on
  • -off
  • -parked
  • –php
  • -proxy
  • -redirection
  • –ssl
  • -wp

Ejemplos:

# Crear sitio PHP
sudo site example.com -php

# Crear sitio WP con cache
sudo site example.com -wp -cache=on

# Desactivar cache
sudo site example.com -cache=off

# Certificado SSL
sudo site example.com -ssl=on

# Listado de tus sitios
sudo site -list

# Clonar un sitio WP
sudo site example.com -clone-from=staging.example.com

# Redireccionar una página
sudo site example.com -redirection

Crear un nuevo sitio web

Crea cualquier sitio web: HTML, PHP, WordPress, Reverse Proxy, etc.

Para crear un sitio HTML básico, utiliza el siguiente comando:

sudo site example.com -html

Para crear un sitio con soporte PHP.

sudo site example.com -php

Todos los sitios usando el dominio principal (no un subdominio) están configurados para responder a solicitudes example.com y www.example.com (Ver la opción force-redirect).

Además, es importante tomar en consideración cuando se crea un sitio PHP la configuración Nginx que usa Webinoly: try_files $uri $uri/ /index.php$is_args$args;. Esto significa que todo recae en tu archivo “index”, por lo que los códigos 404 deberán ser procesados desde tu aplicación PHP.

Para crear un sitio PHP en conjunto con una base de datos:

sudo site example.com -mysql

Los datos para conectar con la base de datos se mostrarán al ejecutar el comando.

También puedes usar la opción “custom” para introducir tus propios datos para crear la base de datos sudo site example.com -mysql=custom o de igual manera puedes pasar los datos directamente.

# TIP Hack
# Usa la opción -mysql sin dominio para crear una DB y User (MySQL) 
sudo site -mysql

# Custom
sudo site example.com -mysql=custom

# O con datos personalizados
sudo site -mysql=[host,dbname,dbuser,password]
sudo site example.com -mysql=[host,dbname,dbuser,password,external_dbuser,external_dbpass]

# TIP
Usa "random" (sin commillas) como password o clave para generar de manera automatica una clave aleatoria.

La Cache FastCGI es también es soportada en cualquier sitio PHP, de esta manera puedes reducir la carga y el uso de CPU asociado a los procesos php-fpm.

WordPress

Instalar WordPress nunca había sido tan sencillo, Webinoly configura de manera automática toda la instalación.

sudo site example.com -wp

¡Y eso es todo! ¡Es así de simple!

Instalación personalizada de WordPress

Usted puede personalizar lo que sea que quieras durante la instalación de acuerdo a sus necesidades.

Usa la configuración “custom” para modificar algunos aspectos de la base de datos, de cualquier manera puedes simplemente presionar <Enter> en cada pregunta para usar los datos sugeridos.

# Script de instalación de un sitio WordPress usando la configuración "custom"
sudo site example.com -wp=custom -cache=on

De igual manera puedes pasar los datos directamente desde la línea de comandos:

# Script de instalación de WordPress con datos personalizados.
sudo site example.com -wp=[<setup_db>,<setup_wp>,<host>,<dbname>,<dbuser>,<dbpass>,<wp_prefix>,<external_db_user>,<external_db_pass>]

# Ejemplo:
sudo site example.com -wp=[true,true,localhost,example_com,example_user,password,wp_]

# TIP
Usa "random" (sin commillas) como password o clave para generar de manera automatica una clave aleatoria.

También puede modificar los privilegios predeterminados asignados a el usuario de la base de datos de cada sitio creado: sudo site example.com -wp -db-role=extra. Lea la sección de “Privilegios en la base de datos” para más detalles.

Webinoly siempre crea automáticamente un archivo de configuración de WordPress wp-config.php y se guarda una carpeta abajo para mayor seguridad: /var/www/example.com/wp-config.php, fuera de la carpeta de acceso público (htdocs). Excepto cuando WP está instalado en un subdirectorio. Si por alguna razón, copia o mueve este archivo, o crea su propio archivo en htdocs, elimine o cambie el nombre del antiguo para evitar un comportamiento no deseado debido a que Webinoly lo verá como archivos duplicados.

Base de datos externa

Webinoly soporta el uso de bases de datos externas, por ejemplo Amazon RDS o cualquier otro (de hecho, puedes configurar tu propio servidor DB externo con Webinoly).

# Ejemplo
sudo example.com -wp=custom

# Se te preguntarán algunos datos.
Database Host [localhost]: myinstance.123456789012.us-east-1.rds.amazonaws.com:3306

Incluso puedes guardar los datos de tu base de datos externa en el Archivo de Configuración de Webinoly y de esta manera Webinoly la usará de manera predeterminada (como si fuera localhost).

* Es importante considerar que la url no debe contener el esquema (http/https) al inicio, para conectar con la base de datos externa y debe tenerse en cuenta que un diseño o implementación deficiente en la arquitectura de una solución de este tipo puede tener un impacto negativo en la velocidad de tu sitio, alta latencia o incluso múltiples errores o “timeouts” en la conexión.

** Se ha probado de manera exitosa con Amazon RDS usando como motor de base de datos MySQL, MariaDB y Amazon Aurora.

*** Todas las credenciales para Bases de Datos externas son guardadas en un archivo CNF de MySQL siguiendo las recomendaciones oficiales, de esta manera Webinoly no necesita solicitarlas cada vez que sea necesario. Algunas opciones de Webinoly tienen soporta para el parámetro -external-db=[user,pass], es importante notar que este parámetro tiene mayor precedencia, por lo que podría ser usado para reescribir/actualizar estas credenciales cuando es soportado.

WordPress Multisite

Es muy fácil convertir tu sitio WordPress en Multisite.

sudo site example.com -multisite-convert

Te solicitará y deberás ir a “Herramientas -> Configuración de la Red” y seleccionar el tipo de instalación (subdominio o subdirectorio); Webinoly hará toda la configuración de manera automatica una vez que hayas seleccionado el tipo de configuración.

* Si tu sitio ha sido instalado con la opción -subfolder únicamente estará disponible la opción “subdirectory” cuando hagas la conversión a multisite, WordPress no permite la configuración en subdominio en este tipo de instalación.

Remplazar Contenido

La función para remplazar contenido puede ser usada de manera independiente en cualquier otro sitio WordPress para buscar y remplazar cualquier palabra o cadena de caracteres en el contenido.

sudo site example.com -replace-content

Se te pedirá introducir los términos para buscar/remplazar, o también puedes usar el siguiente ejemplo para omitir las preguntas.

# Saltar preguntas
# Tomar en cuenta que algunas restricciones aplican cuando se usa esta opción, los espacios y comillas no son permitidas.

sudo site example.com -replace-content=[buscar-esto,remplazar-con]

En caso de que tu sitio WP para clonar o remplazar contenido esté conectado a una base de datos externa será necesario introducir el usuario y password. Para omitir estas preguntas puedes usar la opción -external-db=[user,pass].

Tipo de Entorno en WordPress

Configura la variable WP_ENVIRONMENT_TYPE en WordPress:

  • production
  • staging
  • development
  • local
sudo site example.com -env=staging

En staging, development y local la FastCGI Cache se desactiva automáticamente. Además, la opción “Disuade a los motores de búsqueda de indexar este sitio” de WordPress “Ajustes > Lectura” se activará de manera automática.

En development y local el modo “debug” de WordPress se activa automáticamente. Y se desactiva al cambiar a “staging” o “production”.

# Ejemplos:

# Mantener activada la cache
sudo site example.com -env=staging -cache=on

# Crear sitio WordPress
sudo site example.com -env=development -wp

# El sitio clonado será configurado como "staging"
sudo site example.com -env=staging -clone-from=sub.example.com -overwrite=on

Subdirectorios Configurables

Una de las herramientas más poderosas para configurar tus sitios en el servidor es la capacidad para configurar de manera independiente cada subdirectorio de un sitio en particular.

sudo site example.com -html -subfolder=/one
sudo site example.com -php -subfolder=/two
sudo site example.com -wp -subfolder=/three
sudo site example.com -proxy -subfolder=/four

# Eliminar sitio en subdirectorio
sudo site example.com -delete -subfolder=/xxx

Incluso, es opcional tener un sitio en la raíz del dominio, es decir, es posible únicamente tener soporte en los subdirectorios configurados en cualquier combinación de configuraciones que sean necesarias.

# Ejemplo con subdirectorios y raíz vacía
+ example.com <empty>
  - /blog <wp>
  - /downloads <proxy>
  - /tickets <php>

# Otro ejemplo con un sitio estático en la raíz
+ example.com <html>
  - /news <wp>
  - /clientes <php>

* NOTA: Todos los sitios instalados en una subcarpeta usando este método, incluido WP como se describe a continuación, tendrán una configuración independiente, y la mayoría de estos archivos se pueden encontrar en la carpeta apps.d de Nginx. Eso significa que algunos cambios en algunas configuraciones no afectarán estas subcarpetas.

Instalar WordPress en un subdirectorio

Puedes tener más de una instalación de WordPress en el mismo dominio.

sudo site example.com -wp -subfolder=/test

Siempre deberás especificar el argumento -subfolder para hacer referencia a este sitio y de esta manera diferenciarlo de una instalación común en la raíz del dominio.

sudo site example.com -delete -subfolder=/test
sudo site example.com -cache=on -subfolder=/test
sudo site example.com -multisite-convert -subfolder=/test
sudo site example.com -clone-from=dev.example.com -subfolder=/test
sudo site example.com -replace-content -subfolder=/test
sudo site example.com -env=staging -subfolder=/test
sudo site example.com -info -subfolder=/test
sudo webinoly -backup=local -export=example.com -subfolder=/test
sudo webinoly -backup=local -wp=example.com -subfolder=/test
sudo webinoly -backup=s3 -add-db-pre=example.com -subfolder=/test
sudo webinoly -clear-cache=example.com -subfolder=/test
sudo httpauth example.com -wp-admin=on -subfolder=/test
sudo httpauth example.com -path=/test/folder/ -subfolder=/test
sudo log example.com -wp=on -subfolder=/test

Dominio parqueado o alias

Un dominio parqueado es un dominio adicional o alternativo que apunta hacia un sitio principal. Es una manera simple de acceder a tu sitio desde diferentes nombres de dominio.

sudo site example.com -parked

Al ejecutar el comando te pedirá ingresar el nombre del dominio principal hacia donde apuntará tu nuevo dominio parqueado. De igual manera puedes utilizar el comando de la siguiente manera para facilitar su uso:

sudo site example.com -parked=mainsite.com

Asegúrate de que el sitio principal se encuentre alojado en el mismo servidor.

Mapeo de Dominio automático en WordPress

Si estás creando un sitio parqueado y el sitio principal es un WordPress Multisitio, con Webinoly podemos hacer el mapeo de dominio de manera automática en WordPress, solo necesitas saber el “WP Blog ID” del subsitio.

 sudo site example.com -parked=mainsite.com -domain-mapping-wp-id=3

O puedes hacerlo de manera manual siguiendo los pasos para Mapeo de Dominio descritos en la documentacion oficial de WordPress.

Redireccionamiento de dominio

Todas las solicitudes a este dominio serán redireccionadas o reenviadas a otro dominio.

sudo site example.com -forward=example.org

Todos los parámetros de la solicitud son pasados al nuevo dominio. Si deseas eliminar estos parámetros y forzar la redirección a un único sitio puedes usar la opción -root=on.

# example.com/news  -->  example.org/news
sudo site example.com -forward=https://example.org

# example.com/news  -->  example.org
sudo site example.com -forward=https://example.org -root=on

Configuración Reverse Proxy

Un servidor Reverse-Proxy es un tipo de servidor proxy que redirige las solicitudes de los clientes al servidor backend apropiado.

Para crear un sitio con la configuración de Reverse Proxy en Nginx:

sudo site example.com -proxy=[localhost:8080]
# Ejemplos:
sudo site example.com -proxy=[127.0.0.1:8080]
sudo site example.com -proxy=[https://example.com]
sudo site example.com -proxy=[http://example.com:8080]

# Ejecutas tu app Node.js en el puerto 3000
sudo site example.com -proxy=[localhost:3000]

# Ejecutas tu app Java en el puerto 8082
sudo site example.com -proxy=[localhost:8082]

# Ejecutas tu app Vue en el puerto 8080
sudo site example.com -proxy=[localhost:8080]

# Ejecutas tu app Python con Django y Gunicorn
sudo site example.com -proxy=[localhost:8000]
# En caso de usar sockets con Gunicorn
sudo site example.com -proxy=[http://unix:/home/<user>/<project_name>/<project_name>.sock]

# Ghost
sudo site example.com -proxy=[localhost:2368]

* Como se puede observar en los ejemplos anteriores, la parte de la URI no se permite debido a restricciones de Nginx http://localhost:8000/uri/ o http://unix:/tmp/backend.socket:/uri/, las URI no son soportadas en el upstream y además nuestra configuración de Reverse Proxy incluye algunos bloques “location” que usan expresiones regulares. Hemos creado un caso especial para cuando no hay otra opción más que soportar la URI, lea sobre la opción “simple” de los Reverse-Proxy-Dedicados en la siguiente sección.

** La configuración Nginx de los sitios Reverse Proxy puede ser modificada fácilmente para agregar tus propias reglas, consulte la sección de Nginx.

De la misma manera que en los demás sitios, los Reverse Proxy también cuentan con algunas reglas de básicas de seguridad, archivos con puntos (ocultos), así como algunos nombre y extensiones están bloqueados de manera predeterminada, lo cual es perfecto cuando tienes un sitio web detrás de tu Reverse Proxy, pero de igual manera este comportamiento puede no ser lo deseado en algunos casos. Es por eso que hemos creado los sitios “Reverse Proxy Dedicados” descritos abajo.

Reverse Proxy Dedicados

A diferencia de los anteriores, esta configuración es completamente transparente, lo cual puede ser lo ideal en algunos casos como por ejemplo en repositorios de archivos.

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

Cuando se crea un sitio “Reverse Proxy Dedicado”, entonces solo sitios “Reverse Proxy Dedicados” serán permitidos en los subfolders de este dominio y de la misma manera estos sitios dedicados no serán permitidos en los subfolders de cualquier otro tipo de sitio ya existente.

Nunca use la configuración “Dedicada” de reverse-proxy en sitios web: muchas archivos inseguros pudieran ser expuestos, además de que algunas cabeceras HTTP serían removidas. Los sitios “Dedicados” de reverse-proxy solo deberán ser usados para repositorios de archivos, por ejemplo S3, a menos de que usted sepa muy bien lo que está haciendo.

# Ejemplo: Repositorio S3 detrás de un Reverse Proxy
sudo site example.com -proxy=[https://s3.bucket1.aws.com] -dedicated-reverse-proxy

# Agregar un certificado SSL
sudo site example.com -ssl=on -manual=http

# Agrega un segundo bucket de S3 en un subfolder
sudo site example.com -proxy=[https://s3.bucket2.aws.com] -dedicated-reverse-proxy -subfolder=/images

Otro ejemplo usando una aplicación web:

# Ejemplo: Website APP en localhost
sudo site example.com -proxy=[localhost:8082]

# Agregar un certificado SSL
sudo site example.com -ssl=on -root-path=/opt/app/web

# En este caso puedes agregar cualquier otro tipo de sitio en un subfolder
sudo site example.com -wp -subfolder=/blog

La Cache FastCGI es también es soportada en cualquiera de los sitios Reverse-Proxy, de esta manera puedes reducir la carga y las solicitudes al servidor de origen (upstream).

Los reverse proxy dedicados “simples” son un caso especial creado con algunas limitaciones para soportar las URI en los servidores backend, por ejemplo: https://s3.bucket1.aws.com/uri-path/. Solo tiene que usar la opción -dedicated-reverse-proxy=simple. Esta configuración no usa el bloque Upstream de Nginx y en su lugar pasa directamente el backend a la directiva proxy_pass.

Sitios Completamente Personalizados

Esta es la opción perfecta si deseas empezar a construir la configuración Nginx de tu sitio desde cero.

sudo site example.com -empty

Listo, ahora solo debes incluir tu configuración Nginx usando un archivo personalizado.

# Ejemplo
sudo site example.com -empty

# Archivo de configuración personalizada
sudo nano /var/www/example.com/custom-nginx.conf

# Configuración basica en /var/www/example.com/custom-nginx.conf
location / {
    try_files $uri $uri/ =404;
}

El nuevo sitio creado tiene su propio “server block” como cualquier otro sitio, dependiendo de tus necesidades es probable que requieras agregar al menos un bloque location / en tu configuración personalizada como se muestra en el ejemplo anterior.

De la misma manera que hacemos en todos los sitios, algunas ubicaciones básicas locations.conf son incluidas de manera predeterminada. Puedes usar -empty=blank para no incluir todas estas configuraciones predeterminadas, además algunas cabeceras HTTP serán removidas.

Herramientas de Administración

Algunas herramientas para facilitar la administración de tus sitios.

Clonar un sitio

Ahora puedes clonar cualquier tipo de sitio, no solo WP.

Esta función es también conocida por su uso en sitios de prueba durante la etapa de desarrollo.

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

Las siguientes características no serán heredadas al sitio clonado si se encuentran presentes: Certificado SSL, force-redirect, configuración de default-site o tools-site, o cualquier archivo “custom” de configuración Nginx.

Para sitios WordPress tome las siguientes consideraciones:

  • Todos los enlaces en el contenido de tu sitio serán actualizados automáticamente, puedes desactivar esta opción con el parámetro -replace-content=off.
  • Tome en cuanta que los sitios WordPres Multisite no pueden ser clonados, ya que cada sitio en la red es como si fuera independiente, lo que hace que no sea práctica clonar una red completa de sitios. Si solo quieres clonar un sitio de la red multisite, te recomiendo usar algún plugin gratuito de WordPress.
  • Además, puedes modificar el Tipo de Entorno en WordPress del sitio clonado usando el parámetro -env=staging.

Para clonar y sobrescribir un sitio existente puedes usar el parámetro -overwrite=on.

Ejemplo: Ciclo de Desarrollo

# Crea un nuevo sitio de desarrollo
# WP debug activado, cache desactivada y noindex para buscadores
sudo site dev.example.com -wp -env=development

# Sitio de muestra "staging"
# Debug desactivado, cache activada and noindex
sudo site staging.example.com -env=staging -clone-from=dev.example.com

# Sobrescribe tu sitio anterior en producción
# Cache activada, debug desactivado e index activado
sudo site example.com -clone-from=staging.example.com -cache=on -env=production -overwrite=on

# Actualiza el sitio en ambiente local
sudo site local.example.com -env=local -clone-from=example.com

# Envía las actualizaciones a producción
sudo site example.com -clone-from=local.example.com -cache=on -env=production -overwrite=on

¿Cómo puedo desactivar de manera temporal un sitio?

En cualquier momento puedes activar o desactivar un sitio alojado en tu servidor sin necesidad de borrarlo.

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

Eliminar un sitio web

Debes usar con precaución esta opción, ya que una vez eliminado un sitio no será posible recuperar los archivos.

sudo site example.com -delete

También puedes usar la opción “force” para omitir las preguntas sudo site example.com -delete=force.

# No borrar Base de Datos
sudo site example.com -delete=keep-db

# Base de Datos externa (Omitir preguntas)
sudo site example.com -delete=force -external-db=[user,pass]

# Revocar Certificado SSL
sudo site example.com -delete=force -revoke=on

Para eliminar todos los sitios hospedados en tu servidor:

sudo site -delete-all

Las bases de datos de tus sitios WordPress que estén actualmente en uso también serán eliminadas. Algunas otras DB’s podrian no ser eliminadas, por lo que es posible que queden datos almacenados remanentes de tus sitios eliminados.

# Ejemplo extendido
sudo site -delete-all=force -external-db=[user,pass] -revoke=force

# No borrar las bases de datos
sudo site -delete-all=keep-db

Durante el borrado de un sitio, si se encuentra una base de datos externa se intentara usar los datos de -external-db, si no se encuentran se preguntará al usuario que introduzca los datos necesarios. El parametro -revoke=on borrará el certificado SSL de un sitio si se encuentra, usa la opción “off” para conservar el certificado.

Los sitios configurados como default-site o tools-site no pueden ser borrados. Cuando la opción force o -delete-all es usada, se forzará el borrado de estos sitios y se configurará como default la opción correspondiente para prevenir errores.

Además, es importante notar que si un subdirectorio es borrado o eliminado sudo site example.com -subfolder=/test -delete, todos los subdirectorios dentro de este serán siempre eliminados de igual manera.

Información de un sitio

Despliega un listado con información de tu sitio.

sudo site example.com -info

* Los sitios WordPress con bases de datos externa necesitarán tus credenciales de acceso para mostrar la información completa. Puedes usar el parámetro -external-db=[usuario,password], o tener guardados estos datos en el archivo de Configuración de Webinoly.

Lista de tus sitios

Para ver una lista de todos tus sitios alojados en el servidor, utiliza el siguiente comando:

sudo site -list

En la lista verás información de tu sitio:

  • Tipo de sitio: WordPress, HTML, PHP, Parked, Proxy, Forward, Subfolders.
  • Asignación: Si el sitio ha sido asignado como sitio “Default” o para acceso a las herramientas de Webinoly “Tools”.
  • Alertas: NoSSL, SSL-Staging, AccessLog, NoCache, NoAdminAuth, Debug.
# Lista filtrada
sudo site -list=nossl

Opciones de filtrado: disabled, main, html, php, wordpress, parked, proxy, forward, tools, default, ssl, nossl, sslstaging, accesslog, noaccesslog, cache, nocache, adminauth, noadminauth, debug, nodebug, wpenv.

Para sitios con WP Environment Type que no sea “production” el tipo de sitio lo indicará de la siguiente manera: (WordPress:staging). Para filtrar estos sitios puedes usar la opción “wpenv”.

Configuración Personalizada

Configura tus sitios de acuerdo a tus necesidades.

Forzar WWW o no-WWW en un sitio

De manera predeterminada Webinoly configura tu sitio para aceptar ambas peticiones en tu dominio, es decir, example.com y www.example.com serán ambas validas cuando un dominio principal es usado, por ejemplo: example.com, (NO aplica en subdominios: sub.example.com).

Puedes forzar el uso y redireccionar las peticiones hacia cualquiera de tu preferencia.

sudo site example.com -force-redirect=<option>

Opciones:

  • www
  • root
  • off

En casos especiales donde un certificado SSL ha sido importado de otro proveedor y este no incluye el sudominio “www” o viceversa, podemos usar la opción -ignore-ssl de la siguiente manera: sudo site example.com -force-redirect=root -ignore-ssl.

Nginx FastCGI Cache

La herramienta más fácil y poderosa para optimizar tus sitios web:

  • FastCGI Cache en WordPress
  • Custom Nginx Cache (cualquier sitio)

FastCGI Cache en WordPress

FastCGI Cache de Nginx pre-configurado para WordPress.

Junto con Nginx esta es la mejor optimización que puedes hacer para acelerar tu sitio WordPress. Olvídate de usar plugins obsoletos como W3 Total Cache, Super Cache o WP Rocket. FastCGI ha demostrado un rendimiento muy superior al momento de servir contenido en cache desde tu servidor.

Para activar/desactivar (on/off) FastCGI:

sudo site example.com -cache=on

De igual manera puedes activarlo desde la creación de tu nuevo sitio de la siguiente manera:

sudo site example.com -wp -cache=on

Puedes usar el parámetro -wp-cache-plugins (on/off) para omitir la pregunta sobre la instalación de los plugins sugeridos: sudo site example.com -cache=on -wp-cache-plugins=on.

Nginx Helper Plugin
Es altamente recomendable usar el plugin Nginx Helper para renovar o purgar el contenido en cache de manera dinámica y automática; de esta manera aseguramos mostrar siempre el contenido más actualizado cuando sea necesario.

Es importante configurar el “Purge Method” del plugin como “Delete local server cache file”, el soporte para el método purge/url lo hemos desactivado por considerarlo un riesgo de seguridad. De igual manera el “Caching Method” deberá estar configurado como “Nginx FastCgi Cache”.

Para modificar la configuración global de WordPress FastCGI Cache:.

Custom Nginx Cache

La misma Cache de Nginx con todo el poder que ya conoces puede ser usada en cualquier tipo de sitio, no solo WP.

  • Sitios soportados: PHP, WordPress y Reverse Proxy
  • Configuración de cache independiente para cada sitio.
sudo site example.com -cache=custom

Cuando la Custom Cache es activada por primera vez en un sitio tomará la configuración global actual, despues de esto, puede iniciar a configurar la cache de su sitio usando las mismas opciones descritas en sección de configuracion global de FastCGI Cache y en este caso solo será aplicada a un sitio en especifico.

# Ejemplo

# Activar Custom Cache
sudo site example.com -cache=custom

# Configuración Personalizada
# Todas las mismas opciones disponibles: -delete, -list, -regex, etc.
sudo site example.com -cache=custom -cache-valid
sudo site example.com -cache=custom -query-string-cache=one
sudo site example.com -cache=custom -query-string-never-cache=two
sudo site example.com -cache=custom -query-string-cache-default=never
sudo site example.com -cache=custom -skip-cache=/page
sudo site example.com -cache=custom -skip-cookie-cache=app_logged_in

* El orden en el que estas reglas son introducidas puede afectar el resultado deseado. Favor de leer la sección de Precedencia de las reglas de Cache.
** Además, es posible agregar tus propias reglas Nginx para la Custom Cache de manera manual, lea la sección de Configuración Nginx sobre como modificar estos archivos.

Adicionalmente, como se muestra en el ejemplo anterior, tenemos soporte para -query-string-cache-default (all/never), que define comportamiento predeterminado de la cache para las query-strings y las reglas individuales se ejecutan después, es decir tiene precedencia sobre el comportamiento predeterminado.

Cuando la Custom Cache es desactivada se guardará la configuración personalizada para usarse la siguiente vez que sea reactivada.

# Desactivar Custom Cache
sudo site example.com -cache=off

# En caso de que necesites remover completamente la configuración guardada para iniciar desde cero.
sudo site example.com -cache=off -reset
sudo site example.com -cache=custom -reset

Cuando la Custom Cache es usada en un sitio que fue creado usando la opción -subfolder=/test, es importante tener en cuenta que solamente ese subfolder será guardado en cache y NO todo el dominio. Por ejemplo: sudo webinoly -clear-cache=example.com -subfolder=/test solo tendrá efecto sobre ese subfolder en especifico. Cada sitio es independiente y aislado, incluso si es un sitio en un subfolder configurado dentro de otro dominio.

Es importante tener en cuenta que cuando se usa Custom Cache en un sitio WP, este NO será preconfigurado para el uso de WP y debe comenzar esta configuración desde cero.

De manera predeterminada cuando se usa la Custom-Cache absolutamente todas las páginas solicitadas son guardadas en cache, por lo que es importante contar con una configuración adecuada para cada caso. Por ejemplo, si quisiéramos recrear la configuración que usamos para la cache de WP, sería de la siguiente manera:

# Configuración de Custom Cache para WordPress
# Está sería la misma configuración que usamos en la opción pre-configurada para WordPress.

sudo site example.com -cache=custom -query-string-cache-default=never

sudo site example.com -cache=custom -skip-cache='"(/wp-admin/|/xmlrpc.php|wp-.*.php|index.php|/feed/|.*sitemap.*\.xml|/feed/|/account/|/add_to_cart/|/cart/|/my-account/|/checkout/|/logout/)"' -regex=insensitive

sudo site example.com -cache=custom -skip-cookie-cache='"comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|[a-z0-9]+_items_in_cart|[a-z0-9]+_cart_hash"' -regex=insensitive

* No está incluido de manera predeterminada, pero dependiendo del uso que haga de la WP Rest API, es posible que sea conveniente incluir /wp-json/ para ser excluida de la cache (skip-cache).

Básicamente, configurar una caché personalizada consiste en evitar que algunas páginas específicas se almacenen en caché, usuarios registrados, mapas del sitio, carritos de compras y páginas de pago, etc. ¡Es así de simple!

De la misma manera usted puede crear sus propias reglas de acuerdo a su proyecto.

¿Te imaginas lo fácil que sería la configuración personalizada para tu propia aplicación o sitio desarrollado en Laravel, Java, Node, Angular, React, Vue o cualquier otro lenguaje o framework, o tal vez un CMS diferente como Drupal o Joomla?

Certificados SSL con Let’s Encrypt

Aprovechamos las facilidades que brinda Let’s Encrypt para generar certificados gratuitos para tu sitio y lo hacemos aún más sencillo para configurar tu sitio de manera fácil y rápida.

No hay pretexto para no migrar tu sitio a HTTPS, con solo ejecutar el siguiente comando tu nuevo sitio web estará completamente configurado para navegar de manera segura sobre HTTPS.

sudo site example.com -ssl=on

Una vez activado el certificado SSL, Webinoly configurará Nginx de manera automática para redirigir todo el tráfico de tu sitio de HTTP a HTTPS.

Durante la creación del certificado Webinoly te solicitará tu cuenta de correo electrónico, este correo se utilizará para registrar el nuevo certificado, además de ayudarte a darle seguimiento a la renovación periodica del mismo.

Si lo prefieres, puedes guardar tu cuenta de correo: sudo webinoly -email=user@example.com para omitir las preguntas durante la solicitud del certificado.

* En servidores existentes este comando actualizará el email registrado en Let’s Encrypt, también el MAILTO del cronjob de root será actualizado.
** El correo interno de Ubuntu root será configurado para redirigirse a esta dirección.

Los certificados emitidos por Let’s Encrypt tienen una validez de 90 días, pero no te preocupes, el proceso de renovación es automático. Se crea un “timer” en Ubuntu para verificar todos los días los certificados que deben renovarse (<30 días), y también por redundancia, Webinoly verifica automáticamente una vez por semana el estado de los certificados de todos sus sitios.

Durante cada chequeo de renovación semanal recibirás un correo en la cuenta que hayas registrado con el estado actual de cada certificado.

* La opción Must-Staple ha sido desactivada de manera predeterminada, si desea usar esta característica en sus certificados debe incluir el parámetro -must-staple=on.

Desactivar SSL en un sitio

Si por alguna razón necesitas desactivar el uso del certificado SSL en tu sitio, solo ejecuta el siguiente comando.

sudo site example.com -ssl=off
# Usa la opción "revoke=(on/off/force)" para omitir preguntas.
sudo site example.com -ssl=off -revoke=on

Si falla la revocación del certificado (por ejemplo, si intentas revocar un certificado expirado), en ese caso se te preguntará si deseas borrar y remover el certificado. Puedes usar la opción -revoke=force para removerlo automáticamente.

Puedes usar la opción -ssl=off incluso cuando el sitio ya no existe para eliminar certificados remanentes.

Certificados en sitios parqueados

La opcíon “-root” nos permite crear certificados para sitios en los cuales la raiz de sus archivos se encuentra en un lugar distinto al habitual; este es el caso de los sitios parqueados, ya que el dominio parqueado ni siquiera cuenta con un directorio raíz o archivos propios, sin embargo, apunta hacia otro sitio alojado en el mismo servidor.

sudo site example.com -ssl=on -root=mainsite.com

Un ejemplo práctico y común del caso anterior es en instalaciones WordPress Multisite con Domain Mapping, donde tienes uno o varios dominios parqueados (mapeados) en tu servidor apuntando a un sitio principal. Primera deberá hacer el proceso de mapear el dominio en WP antes de solicitar un certificado.

Certificados en sitios Reverse Proxy

La opcion “-root-path” nos permite especificar una ruta diferente como es el caso de los sitios en configuración Reverse Proxy donde los archivos no están guardados en una ubicación distinta a /var/www.

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

Únicamente para aplicaciones hospedadas en el mismo servidor, para servidores externos se debiera usa la validación manual descrita abajo.

Validación manual

Si deseas obtener un certificado en un servidor o para un sitio que no por alguna razón no es accesible de manera directa desde el exterior, puedes usar el método de validación manual.

sudo site example.com -ssl=on -manual=http

El método manual soporta la validación “http” y “dns”.

La validación “http” te solicitará colocar un archivo con un nombre y contenido especifico en tu sitio. Y la validación “dns” te solicitará colocar un registro TXT en tu DNS con un nombre y contenido especifico.

Tenga en cuenta que los certificados con validación manual no serán renovados automáticamente, el proceso de renovación debe hacerse de manera “manual” antes de expirar (90 días). Lea la sección sobre “Renovación de certificados” a continuación.

Certificados Wildcard

Cuando necesitamos un solo certificado para cubrir todos los subdominios (*.example.com). Este es el tipo de certificado que necesitamos en instalaciones WordPres Multisite en configuración de sub-dominio.

sudo site example.com -ssl=on -wildcard

Durante la creación del certificado Wildcard será necesario crear un registro DNS para comprobar la propiedad del dominio.

Para agregar un sitio a un certificado Wildcard existente:

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

Solo soporta sub dominios de primer nivel.

Renovación de certificados

Aunque Webinoly cuenta con un sistema redundante para la renovación automática de los certificados, tenemos la opción para forzar dicha renovación.

sudo site -ssl=renew

Este comando intentará renovar cualquier certificado disponible que vaya a expirar en menos de 30 días.

También podemos forzar la renovación todos los certificados:

sudo site -ssl=force-renewal-all

Forzar la renovación de un certificado en especifico.

sudo site example.com -ssl=force-renewal

Solo aplica para esta última opción (force-renewal):

  • En el caso de dominios parqueados, sitios “reverse proxy” o certificados con validación manual, se debe incluir el parámetro -root, -root-path, -wildcard o -manual respectivamente necesario para forzar la renovación.
  • Esta es la única manera de renovar un certificado que usa validación manual, incluyendo los “wildcard”.

Entorno de pruebas de Certificados

Recomendamos encarecidamente realizar pruebas de tus proyectos usando el entorno de ensayo antes de utilizar usar certificados reales en el entorno de producción. Esto le permitirá hacer las cosas bien antes de emitir certificados de confianza y reducirá la posibilidad de que se enfrente a los límites de solicitudes.

# Examples
sudo webinoly example.com -ssl=on -test-cert
sudo webinoly example.com -ssl=on -test-cert -wildcard
sudo webinoly example.com -ssl=on -test-cert -root-path=/opt/app/web

Siempre puedes usar el parámetro -test-cert para activar el entorno de pruebas de Let’s Encrypt.

Estos no son certificados reales, solo están destinados a ser utilizados con fines de prueba, obtendrá errores si intenta acceder a su sitio utilizando este certificado. Nunca debe usar estos certificados en un entorno de producción.

Certificados SSL Custom

¡Trae tu propio Certificado!

Puedes usar cualquier certificado de cualquier proveedor de tu preferencia.

sudo site example.com -ssl=on -ssl-key=/path/cert.key -ssl-crt=/path/cert.crt -ssl-ocsp=/path/cert.pem

El parámetro -ssl-ocsp es opcional para soporte de OCSP.

Se recomienda siempre usar el directorio /etc/nginx/certs para almacenar los archivos de tus certificados, ya que este directorio se incluye en las copias de seguridad o en caso de exportar el servidor usando Webinoly.

Administrar Redirecciones

Crear una redirección es fácil, solo ejecuta el siguiente comando y sigues las intrucciones:

sudo site example.com -redirection

Remover una redirección:

sudo site example.com -redirection -delete
# Omitir preguntas
sudo site example.com -redirection -from=/path -to=/test -http-code=308

sudo site example.com -redirection -from=/path -to=http://example.com

sudo site example.com -redirection -from=/path -http-code=410

sudo site example.com -redirection -delete -from=/path

El parámetro -http-code es opcional, el valor default es 302. Los códigos HTTP soportados son: 301, 302, 303, 307, 308. Además y aún cuando no son propiamente redirecciones: 403, 410, 444 y 451 son soportados (el destino “to” es omitido o ignorado).

También puedes usar la opción -exact para especificar una coincidencia exacta.

¿Que hace la opción "EXACT"?

Ruta: /news

https://example.com/news (match)
https://example.com/news/local/our-city (match)

Usando la opción "EXACT":
https://example.com/news (match)
https://example.com/news/local/our-city (no-match)

No es necesario especificar el parámetro -exact cuendo se use -delete, simplemente se removerán todos los “path” que coincidan.

Soporte para Regex

La opción “regex” nos permite usar expresiones regulares y en la línea de comandos deben escribirse usando comillas simples, como en el ejemplo anterior. Soporta las siguientes opciones:

  • sensitive – Que es sensible a mayúsculas y minúsculas.
  • insentive – Que no es sensible a mayúsculas y minúsculas.
  • longest – Especifica la mejor opción y no continua evaluando las expresiones regulares.

Consulta la documentación oficial y algunos ejemplos sobre el uso de expresiones regulares en Nginx.

# Ejemplo
sudo site example.com -redirection -from='^\.(gif|jpg|jpeg)$' -to=/test -regex=insensitive

Listado de redirecciones:

sudo site example.com -redirection -list

Configuración NGINX

Si necesitas agregar algunos parámetros a la configuración NGINX de tu sitio, puedes tener un archivo de configuración adicional localizado en el directorio /var/www/example.com el cual deberá ser nombrado de la siguiente manera: *-nginx.conf.

Estos archivos personalizados son soportados por todos los sitios de cualquier tipo.

¿Cómo agregar una configuración NGINX personalizada?

PRECAUCIÓN: ¡Por favor, no intente solo copiar y pegar! Antes de agregar sus propia configuración en Nginx, asegúrese de saber lo que está haciendo y si realmente lo necesita, muchas de las configuraciones más comunes ya están integradas de manera nativa en Webinoly.

  • Por ejemplo /var/www/example.com/custom-nginx.conf sería un archivo válido.
  • Puedes agregar múltiples archivos de configuración: another-nginx.conf.
  • Los sitios creados como “subfolders” se regirán por la configuración del sitio principal.
  • Los sitios “parkeados” se regirán por la configuración del sitio principal.
    • Puede crear un archivo con reglas específicas para el sitio parkeado: /var/www/{maindomain.com}/*-{parkeddomain_com}_parked.conf por ejemplo: /var/www/example.com/custom-parkedsite_com_parked.conf. De igual manera aplica para el sitio principal únicamente cuando este tiene sitios parkeados, la configuración en este caso tendrá efecto solo en el sitio principal, sin afectar a los parkeados.
  • No se recomienda modificar los archivos de NGINX actuales incluidos, ya que los cambios se perderán durante algunas actualizaciones. Existen algunas excepciones que pudieras tomar en consideración:
    • Archivos de configuración de Reverse Proxy pueden ser modificados de manera segura: /etc/nginx/apps.d/example.com-proxy.conf
    • Archivos de configuración de Custom Cache pueden ser modificados de manera segura: /etc/nginx/apps.d/example.com-wpcache.conf o/etc/nginx/apps.d/example.com-phpcache.conf
    • De hecho, todos los archivos en la carpeta apps.d de Nginx no se sobrescriben durante el proceso de actualización y pueden modificarse bajo su propio riesgo, en algunos casos Webinoly usa algunas líneas de código y texto como comentarios como referencias, cualquier cambio puede causar un comportamiento inesperado.
    • En caso de que lo necesite, puede restabler su servidor en cualquier momento sudo webinoly -server-reset solo para estar seguro. Si ha seguido todas estas recomendaciones, nada debería corromperse en su configuración, eso es lo que hacemos durante algunas actualizaciones.
  • Todos estos archivos de configuración son incluidos dentro del bloque “server” en el contexto de Nginx. En caso de ser necesario, puedes incluir tus propios archivos de configuración en el contexto “http” usando el directorio “conf.d” estandar de Nginx: /etc/nginx/conf.d/*.conf.
    • Hemos creado un caso/extensión especial en la carpeta “conf.d”. Puede usar /etc/nginx/conf.d/*.conf.srv y esto se aplicará a TODOS los sitios (dentro del contexto del bloque server de cada sitio, obviamente).
  • Recuerda que muchas opciones (Nginx, PHP, etc) pueden ser modificadas desde el archivo de Configuración de Webinoly: /opt/webinoly/webinoly.conf.

Webinoly detecta de manera automática si tu sitio es un dominio example.com (configura example.com y www.example.com) o subdominio sub.example.com (únicamente sub.example.com), esto para determinar la configuración más apropiada en Nginx de cada sitio. Dominios con un TLD no valido serán configurados como subdominio. Si por alguna razón necesitas forzar una determinada configuración, puedes hacerlo usando la opción -subdomain al momento de crear tu sitio o solicitar un certificado SSL.

Ejemplo: sudo site example.com -html -subdomain=true, o de igual manera sudo site sub.example.com -ssl=on -subdomain=false. Como se puede observar, es posible usar el parámetro “subdomain” con cualquier opción, no solo cuando se crea el sitio.

El comando sudo webinoly -external-sources-update es de uso interno para actualizar algunas listas externas (public-suffix y zonas horarias).

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