Diferencias entre subdominios ligeros y subdominios como alojamientos separados #WebhostingManagement #CoreAdmin


#1

1. Introducción

El siguiente artículo explica las diferencias entre subdominios ligeros e implementar la misma característica con alojamientos independientes, usando en ambos casos el gestor de alojamientos (#WebhostingManagement) de #CoreAdmin (https://core-admin.com).

2. Resumen

Use subdominios ligeros:

  1. Cuando tenga un mismo motor de código.
  2. No sean necesarios hosting alias (nombres de hosting) adicionales para cada subdominio ligero.
  3. Cuando sea necesario ejecutar todos los subdominios ligeros con la misma configuración.
  4. Que un único certificado pueda cubrir todos los dominios y subdominios con la misma ip.

Use alojamientos independientes:

  1. Aun cuando compartiendo bases de datos, necesite ejecutar distintas versiones de php, con distintas configuraciones (ya sea ahora o en el futuro).
  2. Necesidad de configurar hosting alias distintos en cada subdominio (incluyendo nombres que nada tengan que ver con el nombre principal).
  3. Necesidad de poder aplicar políticas de seguridad, restricciones y cuotas de manera distinta y diferencia a cada subdominio.
  4. Cuando el propósito y el código sea distinto para cada subdominio (separación de responsabilidades, código y versiones, p.ej: web principal, tienda, web de soporte).

3. Cómo funcionan los subdominios ligeros

A continuación explicamos el funcionamiento de cada uno de los métodos para poder entender mejor las diferencias.

El subdominio ligero es una configuración muy específica que permite ejecutar, bajo un mismo alojamiento principal, uno o varios subdominios, con el mismo usuario, cuota, certificado, configuración PHP y políticas configuradas para el alojamiento principal.

Es útil en caso de que el mismo motor de código reaccione de manera distinta cuando es accedido con un nombre de host distinto pero que por requisitos necesita acceder al resto de partes (permisos de ficheros) de manera que tiene que ejecutar con el mismo usuario (uid/gid) que el resto de partes (subdominios).

4. Cómo funcionan los subdominios como alojamiento independiente

A todos los efectos, aunque sea un subdominio (por el nombre), al crearse como un alojamiento independiente, funcionará como tal, es decir, como un alojamiento con todas sus facultades, pero cuyo nombre resulta ser un dominio de la forma subdominio.dominio.com.

Es decir, tendrá independencia total de cuota, configuraciones, ips, certificados, políticas y usuario de ejecución.

5. Principales diferencias

De manera general, si tiene dudas, opte por alojamientos independientes para cada subdominio.

Esto le permitirá:

  1. Disponer de usuarios de ejecución, cuotas, certificados, políticas y motores diferenciados para cada subdominio.

  2. Podrá tener una visión más nítida y clara de qué subdominio (alojamiento) está recibiendo carga, visitas y donde están localizados los problemas.

  3. Cada alojamiento (subdominio), al ser un sistema aislado, ejecuta de tal manera que problemas de hacking quedan contenidos en ese alojamiento.

  4. Al disponer de alojamientos independientes, podrá implementar políticas de seguridad diferenciadas (modo lectura, bloqueo de POST por ip, por citar algunas).

  5. Disponer de alojamientos independientes para cada subdominio también le permitirá configurar hosting alias (nombre adicionales) de manera individualizada para cada caso, sin afectar al alojamiento principal y al resto de alojamientos ejecutando los subdominios.

El subdominio ligero, por el contrario, responde bien:

  1. Cuando es necesario ejecutar todo bajo un mismo código, aunque esté localizado en carpetas distintas.

  2. Cuando exista un alto acoplamiento entre los distintos subdominios con relación al código, donde no es un problema, sino que es necesario compartir la misma versión de PHP, políticas, certificados, etc.

6. Preguntas habituales

  1. ¿Ejecutará más rápido un subdominio ligero por aquello de ser ligero?

    No, ejecutará tan rápido como que sea el código de la web, con independencia de usar subdominio ligero o alojamiento independiente.

  2. ¿Qué es más seguro, subdominio ligero o subdominio como alojamiento independiente?

    Es mucho más seguro subdominio como alojamiento independiente. El motivo es que cada alojamiento ejecuta con un usuario (uid) y grupo (gid) distinto. Esto implica que procesos de alojamientos distintos no se pueden ver, interferir, afectar ni modificar ficheros de manera cruzada.

    En el plano de la política de seguridad, el subdominio como alojamiento independiente también es más seguro ya que es más flexible a la hora de implementar bloqueos, controles url, etc, que no son tan sencillos de aplicar si afectan globalmente.

  3. ¿Si tiene tantas ventajas el subdominio como alojamiento independiente, porqué existe el soporte para subdominio ligero?

    En algunos casos, que suelen ser más específicos y por tanto menos generales, se necesita una configuración para poder ejecutar código de distintas carpetas, dentro de un mismo alojamiento, pero con un subdominio, y ejecutando con el mismo usuario de ejecución (uid/gid) y mismos permisos de ficheros. Para esos casos, el subdominio ligero es la solución recomendada.

  4. No tengo claro cuál es la opción que más me conviene, ¿qué recomendáis?

    Si no hay preferencias, opte siempre por alojamientos independientes, incluso cuando implemente subdominios. Esto le proporcionará una flexibilidad de configuración, separación y políticas que se adaptarán mejor a futuras necesidades.

  5. ¿Tendré que modificar mi código de subdominios para funcionar con alojamientos independientes?

    Raramente esto es necesario. Siempre puede compartir mismas bases de datos entre alojamientos distintos (que suele ser el motivo principal para tender a subdominios). Simplemente suba al raíz del alojamiento independiente el contenido de la subcarpeta. Debería funcionar sin cambios.

    Es muy posible que tener alojamientos independientes para subdominios le haga trabajar un poco más al principio al tener que separar el código entre distintos alojamientos. Sin embargo, las ventajas de gestión, seguridad y estabilidad superan con creces los posibles inconvenientes de despliegue.