У меня есть некоторый опыт использования Linux, но ни один из них не использует nginx. Мне было поручено исследовать варианты балансировки нагрузки для сервера приложений.

Я использовал apt-get для установки nginx, и все выглядит нормально.

У меня есть пара вопросов.

В чем разница между папкой sites-available и папкой conf.d. Обе эти папки были включены в настройки конфигурации по умолчанию для nginx. Учебники используют оба. Для чего они и какова лучшая практика?

Для чего используется папка с поддержкой сайтов? Как мне это использовать?

Конфигурация по умолчанию ссылается на пользователя www-data? Должен ли я создать этого пользователя? Как дать этому пользователю оптимальные разрешения для запуска nginx?

Папки сайтов - * управляются nginx_ensiteи nginx_dissite. Для пользователей Apache httpd, которые находят это с помощью поиска, эквивалентами является a2ensite/ a2dissite.

sites-availableПапка для хранения всех ваших конфигураций ВХост, идет ли они или нет в настоящее время включен.

sites-enabledПапка содержит символические ссылки на файлы в папке сайтов-доступных. Это позволяет вам выборочно отключить vhosts, удалив символическую ссылку.

conf.dвыполняет работу, но вы должны переместить что-то из папки, удалить ее или внести в нее изменения, когда вам нужно что-то отключить. Абстракция папок sites- * делает вещи немного более организованными и позволяет управлять ими с помощью отдельных сценариев поддержки.

(если вы не похожи на меня и одного из многих администраторов Debian, которые просто управляли символическими ссылками напрямую, не зная о сценариях ...)

Я хотел бы добавить к предыдущим ответам, что наиболее важным является не то, как вы называете каталоги (хотя это очень полезное соглашение), а то, что вы фактически вставили nginx.conf. Пример конфигурации:

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

Единственная директива, используемая здесь, это include , поэтому между eg conf.d/и sites-enabled/. Нет никакой внутренней разницы .

Из документации выше:

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.

Итак, чтобы ответить на исходный вопрос: нет внутренней разницы, и вы можете использовать их наилучшим образом, помня советы из других ответов. И, пожалуйста, не забудьте выбрать «правильный» ответ.

Как правило, sites-enabledпапка используется для определений виртуальных хостов, а conf.dиспользуется для конфигурации глобального сервера. Если вы поддерживаете несколько веб-сайтов, т. Е. Виртуальных хостов, то каждый из них получает свой собственный файл, поэтому вы можете очень легко включать и отключать его, перемещая файлы внутрь и наружу sites-enabled(или создавая и удаляя символические ссылки, что, вероятно, лучшая идея).

Используйте conf.dдля таких вещей, как загрузка модулей, файлы журналов и другие вещи, которые не относятся только к одному виртуальному хосту.

Конфигурация по умолчанию ссылается на пользователя www-data? Должен ли я создать этого пользователя?

Вы должны запустить nginx как пользователь без полномочий root. В некоторых случаях это называется www-data, но вы можете назвать его как угодно.

Как дать этому пользователю оптимальные разрешения для запуска nginx?

Я менее уверен в ответе на этот вопрос (сейчас я не запускаю nginx), но если это что-то похожее на Apache, ответ таков: www-dataпользователю нужны только разрешения на чтение любых статических файлов (и чтение + выполнение в каталогах). ) которые вы обслуживаете, или разрешения на чтение / выполнение таких вещей, как сценарии CGI, и никаких разрешений где-либо еще.

В чем дело?

Вы должны использовать Debian или Ubuntu, так как зло sites-available / sites-enabledлогика не используется вышестоящей упаковкой nginx с http://nginx.org/packages/ .

В любом случае, оба реализуются как соглашение о конфигурации с помощью стандартной includeдирективы в /etc/nginx/nginx.conf.

Вот фрагмент /etc/nginx/nginx.confиз официального апстрим-пакета nginx от nginx.org:

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

Вот фрагмент /etc/nginx/nginx.confиз Debian / Ubuntu :

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

Таким образом, с точки зрения NGINX, единственным отличием будет то, что файлы, которые будут получены, conf.dбудут обработаны быстрее, и, как таковые, если у вас есть конфигурации, которые незаметно конфликтуют друг с другом, то из них conf.dмогут иметь приоритет над конфигурациями в sites-enabled.

Лучшая практика conf.d.

Вы должны использовать /etc/nginx/conf.d, как это стандартное соглашение, и должно работать где угодно.

Если вам нужно отключить сайт, просто переименуйте имя файла, чтобы больше не иметь .confсуффикса, очень легко, просто и безошибочно:

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

Или наоборот, чтобы включить сайт:

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

Избегайте sites-availableи sites-enabledлюбой ценой.

Я не вижу абсолютно никакой причины использовать sites-available/ sites-enabled:

• Некоторые люди упоминали nginx_ensiteи nginx_dissiteсценарии - имена этих сценариев даже хуже, чем остальная часть этого разгрома - но эти сценарии также нигде не найти - они отсутствуют в nginxпакете даже в Debian (и, вероятно, в Ubuntu) Кроме того, вам не нужен целый нестандартный сторонний скрипт для простого перемещения и / или связывания файлов между двумя каталогами ?!

• И если вы не используете сценарии (что на самом деле является разумным выбором, как указано выше), то возникает вопрос, как вы управляете сайтами:

  • Вы создаете символические ссылки с sites-availableна sites-enabled?
  • Скопировать файлы?
  • Переместить файлы?
  • Редактировать файлы на месте в sites-enabled?

Вышеприведенное может показаться незначительными проблемами до тех пор, пока несколько человек не начнут управлять системой, или пока вы не примете быстрое решение, только чтобы забыть об этом спустя месяцы или годы…

Что приводит нас к:

• Безопасно ли удалять файл из sites-enabled? Это мягкая ссылка? Жесткая ссылка? Или единственная копия конфигурации? Яркий пример конфигурации ада.

• Какие сайты были отключены? (С conf.dпомощью поиска обращайтесь к файлам, не заканчивающимся на .conf- find /etc/nginx/conf.d -not -name "*.conf"или используйте grep -v.)

Не только все вышеперечисленное, но также обратите внимание на специальную includeдирективу, используемую Debian / Ubuntu /etc/nginx/sites-enabled/*- для суффикса имени файла не указано sites-enabled, в отличие от conf.d.

• Это означает, что если однажды вы решите быстро отредактировать один или два файла внутри /etc/nginx/sites-enabled, и вы emacsсоздадите файл резервной копии, например default~, вдруг у вас будет и то, defaultи другое в default~качестве активной конфигурации, которая, в зависимости от используемых директив, может даже не дать Вы предупреждаете о каких-либо предупреждениях и вызываете длительный сеанс отладки. (Да, это случилось со мной; это было во время хакатона, и я был полностью озадачен, почему мой конф не работал.)

Таким образом, я убежден, что sites-enabledэто чистое зло!