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?

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

La sites-availablecarpeta es para almacenar todas las configuraciones de vhost, estén o no habilitadas actualmente.

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

conf.dhace 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 saber sobre los scripts ...)

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 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 eg 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".

Normalmente, la sites-enabledcarpeta se usa para definiciones de host virtual, mientras que conf.dse usa 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 sites-enabledy quitando archivos (o creando y eliminando enlaces simbólicos, lo que probablemente sea una mejor idea)

Úselo conf.dpara cosas como la carga de módulos, archivos de registro y otras cosas que no son específicas de un solo 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 www-data, se llama así , pero puede nombrarlo como desee.

¿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-datausuario solo necesita permisos de lectura para cualquier archivo estático (y leer + ejecutar en directorios ) que está publicando, o lee / ejecuta permisos en cosas como scripts CGI, y no tiene permisos en ningún otro lugar.

¿Que esta pasando?

Debe estar utilizando Debian o Ubuntu, ya que el mal sites-available / sites-enabledlógica no es utilizado 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 includedirectiva estándar en /etc/nginx/nginx.conf.

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

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

Aquí hay un fragmento de /etc/nginx/nginx.confDebian / Ubuntu :

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

Por lo tanto, desde el punto de vista de NGINX, la única diferencia sería que los archivos conf.dse procesarán antes y, por lo tanto, si tiene configuraciones que entran en conflicto silenciosamente entre sí, entonces las de conf.dpueden tener prioridad sobre las que se encuentran sites-enabled.

La mejor práctica es conf.d.

Debería usarlo /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 nombre del archivo para que ya no tenga un .confsufijo, es muy fácil, directo y a prueba de errores:

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

O lo contrario para habilitar un sitio:

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

Evitar sites-availabley sites-enableda toda costa.

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

• Algunas personas han mencionado nginx_ensitey nginx_dissitescripts, 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 nginxpaquete incluso en Debian (y probablemente también en Ubuntu) , y no presente en un paquete propio, 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:

  • ¿Creas enlaces simbólicos de sites-availablea sites-enabled?
  • Copiar los archivos?
  • Mover los archivos?
  • Editar 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 olvidarse de eso meses o años más adelante ...

Lo que nos lleva a:

• ¿Es seguro eliminar un archivo 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, simplemente haga una búsqueda de inversión de archivos que no terminen con .conf- find /etc/nginx/conf.d -not -name "*.conf", o use grep -v).

No solo todo lo anterior, sino que también tenga en cuenta la includedirectiva específica utilizada por Debian / Ubuntu /etc/nginx/sites-enabled/*: no se especifica ningún sufijo de nombre de archivo 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 /etc/nginx/sites-enabledy emacscreas un archivo de respaldo como default~, de repente, tienes ambos defaulte default~incluidos como configuración activa, lo que, dependiendo de las directivas utilizadas, puede que ni siquiera te dé le avisa y provoca 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-enabledes puro mal!