☰

这是怎么回事？

tag-icon • tag-icon linux ubuntu nginx web-server configuration
这是怎么回事？

我有一些使用 Linux 的经验，但没有使用 nginx 的经验。我负责研究应用服务器的负载平衡选项。

我已经使用 apt-get 安装了 nginx，一切似乎正常。

我有一些问题。

sites-available 文件夹和 conf.d 文件夹有什么区别。这两个文件夹都包含在 nginx 的默认配置设置中。教程都使用了这两个文件夹。它们的用途是什么？最佳实践是什么？

sites-enabled 文件夹有什么用？如何使用它？

默认配置引用了 www-data 用户？我必须创建该用户吗？如何为该用户提供运行 nginx 的最佳权限？

答案1

nginx_ensitesites-* 文件夹由和管理nginx_dissite。对于通过搜索找到此文件夹的 Apache httpd 用户来说，其等效文件夹是a2ensite/ a2dissite。

该sites-available文件夹用于存储全部您的 vhost 配置，无论它们当前是否已启用。

该sites-enabled文件夹包含指向 sites-available 文件夹中文件的符号链接。这允许您通过删除符号链接来选择性地禁用 vhost。

conf.d可以完成这项工作，但当您需要禁用某些内容时，您必须将某些内容移出文件夹、删除它或对其进行更改。 sites-* 文件夹抽象使事情更有条理，并允许您使用单独的支持脚本来管理它们。

（除非你像我一样，是众多直接管理符号链接而不知道脚本的 Debian 管理员之一……）

答案2

这是怎么回事？

您必须使用 Debian 或 Ubuntu，因为邪恶的 sites-available/sites-enabled逻辑未被使用nginx 的上游打包从http://nginx.org/packages/。

无论哪种情况，都是在标准的帮助下作为配置约定实现的include指令/etc/nginx/nginx.conf。

/etc/nginx/nginx.conf以下是来自 nginx.org 的 nginx 官方上游包的片段：

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{,.disabled}

或者相反使能够网站：

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结尾的文件进行反向搜索，或使用.conffind /etc/nginx/conf.d -not -name "*.conf"grep -v。

不仅以上所有内容，还要注意includeDebian/Ubuntu 使用的特定指令 ——/etc/nginx/sites-enabled/*没有为 指定文件名后缀sites-enabled，与 不同conf.d。

  • 这意味着，如果有一天你决定/etc/nginx/sites-enabled在emacs创建一个备份文件default~，如，然后，突然间，您同时拥有default和default~作为活动配置，根据使用的指令，它甚至可能不会给您任何警告，并导致长时间的调试会话。（是的，它确实发生在我身上；那是在一次黑客马拉松期间，我完全不明白为什么我的 conf 不起作用。）

因此我确信那sites-enabled是纯粹的邪恶！

答案3

我想补充一下前面的答案，最重要的不是你如何调用目录（尽管这是一个非常有用的惯例），而是你实际输入的内容nginx.conf。示例配置：

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

这里使用的唯一指令是包括conf.d/，因此 eg和之间没有内部区别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.

因此，回答原始问题：没有内部差异，您可以以最佳方式使用它们，记住其他答案的建议。并且请不要忘记选择“正确”答案。

答案4

关于容器[Docker]

正如评论中所提到的，使用容器时，sites-* 抽象没有意义。

需要注意的是，sites-available|sites-enabled 是 Debian 的特色，不是 nginx 或 Apache 的功能。它在过去可能非常有用，但在配置管理和容器时代，它的实用性有些有限。– Michael Hampton 2016 年 12 月 22 日 17:43

请允许我澄清这一点。

请注意当前（1.21.6）NGINX Docker是基于 Debian 构建的，除非您指定 Alpine。Debian 镜像才不是使用 sites-* 抽象；它是从源代码构建的（这是有意义的）。

首先，如果你想使用 sites-*，那么代码行数会更多。创建 sites-* 文件夹和符号链接，并编辑默认的 nginx.conf（或者更糟的是，检查一个在升级 NGINX 版本时不会更新的文件）。

如果您希望将 confs 保留在 git 中并拥有完全可重现的构建，那么您可以提交 confs 的当前状态并让 CI/CD 进行部署。这意味着，如果您决定使用 sites-*（尽管需要更多代码），那么您必须编辑 Dockerfile 或类似文件来调整为启用/禁用站点而创建的符号链接。

我这么说

并希望将你的配置文件保存在 git 中，并实现完全可重现的构建

因为您可以启动一个使用 sites-* 的容器，登录到您的服务器，然后在正在运行的容器上执行命令来管理符号链接。事实上，这是使用 sites-* 在容器化中唯一有意义的方法。但使用此工作流程，当前状态仅保存在容器中（而不是在 git 中，并且从映像启动新容器将更改已启用的站点）。

和完整的 conf.d 方法，您所要做的就是git mv mysite.com.conf mysite.com.conf.disabled推送更改。就我个人而言，我宁愿推送重命名提交，而不是编辑 Dockerfile 或登录服务器来执行符号链接命令。

因此，为了编写更少的代码、在 git 中保持当前状态以及稍微提高自动化程度，我建议在容器方面采用纯 conf.d 方法。

相关内容