it-swarm-es.com

¿Cuáles son los diferentes usos de los sitios disponibles frente al directorio conf.d para nginx?

Tengo algo de experiencia usando Linux pero ninguno usando Nginx. Me encargaron investigar las opciones de equilibrio de carga para un servidor de aplicaciones.

He usado apt-get para instalar nginx y todo parece estar bien.

Tengo un par de preguntas.

¿Cuál es la diferencia entre la carpeta de sitios disponibles y la carpeta conf.d? Ambas carpetas estaban INCLUIDAS en la configuración de configuración predeterminada para nginx. Los tutoriales usan ambos. ¿Para qué son y cuál es la mejor práctica?

¿Para qué se utiliza la carpeta habilitada para sitios? ¿Como lo uso?

La configuración predeterminada hace referencia a un usuario de www-data? ¿Tengo que crear ese usuario? ¿Cómo le doy a ese usuario permisos óptimos para ejecutar nginx?

112
Seth Spearman

Las carpetas sites- * son administradas por nginx_ensite y nginx_dissite. Para los usuarios de httpd de Apache que encuentran esto con una búsqueda, los equivalentes son a2ensite/a2dissite.

Los sites-available carpeta es para almacenar todas de sus configuraciones de vhost, estén o no habilitadas actualmente.

Los sites-enabled la carpeta contiene enlaces simbólicos a los archivos en la carpeta de sitios disponibles. Esto le permite desactivar selectivamente vhosts eliminando el enlace simbólico.

conf.d hace el trabajo, pero debe mover algo fuera de la carpeta, eliminarlo o hacer cambios cuando necesite deshabilitar algo. La abstracción de la carpeta sites- * hace que las cosas estén un poco más organizadas y le permite administrarlas con scripts de soporte independientes.

(a menos que sea como yo, y uno de los muchos administradores de Debian que solo administraron los enlaces simbólicos directamente, sin conocer los scripts ...)

103
Andrew B

Me gustaría agregar a las respuestas anteriores que lo más importante no es cómo llamar a los directorios (aunque es una convención muy útil), sino lo que realmente pones en nginx.conf. Configuración de ejemplo:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

La única directiva utilizada aquí es include , por lo que no hay diferencia interna entre p. Ej. conf.d/ y sites-enabled/.

De la documentación anterior:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

Entonces, para responder a la pregunta original: no existe una diferencia interna, y puede usarlas de la mejor manera posible, recordando los consejos de las otras respuestas. Y, por favor, no olvides elegir la respuesta "correcta".

42
Yaroslav Nikitenko

Típicamente, el sites-enabled carpeta se utiliza para las definiciones de Host virtual, mientras que conf.d se utiliza para la configuración global del servidor. Si admite varios sitios web, es decir, hosts virtuales, cada uno obtiene su propio archivo, por lo que puede habilitarlos y deshabilitarlos muy fácilmente moviendo los archivos dentro y fuera de sites-enabled (o crear y eliminar enlaces simbólicos, lo que probablemente sea una mejor idea).

Utilizar conf.d para cosas como la carga de módulos, archivos de registro y otras cosas que no son específicas de un único Host virtual.

La configuración predeterminada hace referencia a un usuario de www-data? ¿Tengo que crear ese usuario?

Debería tener nginx ejecutándose como usuario no root. En algunos casos, esto se llama www-data, pero puedes nombrarlo como quieras.

¿Cómo le doy a ese usuario permisos óptimos para ejecutar nginx?

Estoy menos seguro de la respuesta a esta pregunta (no estoy ejecutando nginx en este momento), pero si se parece a Apache, la respuesta es que el www-data el usuario solo necesita permisos de lectura para cualquier archivo estático (y leer + ejecutar en directorios) que está sirviendo, o permisos de lectura/ejecución en cosas como scripts CGI, y ningún permiso en ningún otro lugar.

32
larsks

¿Que esta pasando?

Debes estar usando Debian o Ubuntu, ya que evilsites-available/sites-enabled la lógica no es utilizada por el paquete ascendente de nginx de http://nginx.org/packages/ .

En cualquier caso, ambos se implementan como una convención de configuración con la ayuda de la directiva estándar include en /etc/nginx/nginx.conf.

Aquí hay un fragmento de /etc/nginx/nginx.conf de un paquete oficial de nginx de nginx.org:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

Aquí hay un fragmento de /etc/nginx/nginx.conf de Debian/Ubunt :

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Entonces, desde el punto de vista de NGINX, la única diferencia sería que los archivos de conf.d debe procesarse antes, y, como tal, si tiene configuraciones que entran en conflicto silenciosamente entre sí, entonces las de conf.d puede tener prioridad sobre aquellos en sites-enabled.


La mejor práctica es conf.d.

Deberías estar usando /etc/nginx/conf.d, ya que es una convención estándar y debería funcionar en cualquier lugar.

Si necesita deshabilitar un sitio, simplemente cambie el nombre del archivo para que ya no tenga un .conf sufijo, muy fácil, directo y a prueba de errores:

Sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

O lo contrario a habilitar un sitio:

Sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}


Evitar sites-available Y sites-enabled Cueste lo que cueste.

No veo absolutamente ninguna razón para usar sites-available/sites-enabled:

  • Algunas personas han mencionado nginx_ensite y nginx_dissite scripts: los nombres de estos scripts son incluso peores que el resto de esta debacle, pero estos scripts tampoco se encuentran en ninguna parte, están ausentes del paquete nginx incluso en Debian (y probablemente en Ubuntu , también), y no presente en un paquete propio, tampoco, además, ¿realmente necesita un script de terceros no estándar completo para simplemente mover y/o vincular los archivos entre los dos directorios?

  • Y si no está utilizando los scripts (que, de hecho, es una opción inteligente según lo anterior), entonces surge el problema de cómo administra los sitios:

    • ¿Crea enlaces simbólicos desde sites-available a sites-enabled?
    • Copiar los archivos?
    • Mover los archivos?
    • Edite los archivos en su lugar en sites-enabled?

Lo anterior puede parecer algunos problemas menores que abordar, hasta que varias personas comiencen a administrar el sistema, o hasta que tome una decisión rápida, solo para olvidarlo meses o años después ...

Lo que nos lleva a:

  • ¿Es seguro eliminar un archivo de sites-enabled? ¿Es un enlace suave? Un enlace duro? ¿O la única copia de la configuración? Un excelente ejemplo de infierno de configuración.

  • ¿Qué sitios han sido deshabilitados? (Con conf.d, solo haga una búsqueda de inversión para los archivos que no terminen con .conf - find /etc/nginx/conf.d -not -name "*.conf", o usar grep -v .)

No solo todo lo anterior, sino que también tenga en cuenta la directiva específica include utilizada por Debian/Ubuntu - /etc/nginx/sites-enabled/* - no se especifica sufijo de nombre de archivo para sites-enabled, a diferencia de conf.d.

  • Lo que esto significa es que si un día decides editar rápidamente uno o dos archivos dentro de /etc/nginx/sites-enabled, y tu emacs crea un archivo de copia de seguridad como default~, entonces, de repente, tienes tanto default como default~ incluido como configuración activa, que, dependiendo de las directivas utilizadas, puede que ni siquiera le proporcione advertencias y provoque una sesión de depuración prolongada. (Sí, me pasó a mí; fue durante un hackathon, y estaba totalmente desconcertado de por qué mi conf no estaba funcionando).

Por lo tanto, estoy convencido de que sites-enabled es puro mal!

19
cnst