nginx的使用slug
status
password
icon
AI summary
date
summary
tags
type
category
1、nginx整体介绍
主要由：全局块、events块和http块组成
Nginx的主配置文件是nginx.conf，这个配置文件一共由三部分组成，分别为全局块、events块和http块。在http块中，又包含http全局块、多个server块。每个server块中，可以包含server全局块和多个location块。在同一配置块中嵌套的配置块，各个之间不存在次序关系。
配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在http全局块中和server块中，并且配置不同，则应该以server块中的配置为准。
1.1、整体机构
整个配置文件的结构大致如下：
1.2、全局块
全局块是默认配置文件从开始到events块之间的一部分内容，主要设置一些影响Nginx服务器整体运行的配置指令，因此，这些指令的作用域是Nginx服务器全局。
通常包括配置运行Nginx服务器的用户（组）、允许生成的worker process数、Nginx进程PID存放路径、日志的存放路径和类型以及配置文件引入等。
1.3、events块
events块涉及的指令主要影响Nginx服务器与用户的网络连接。常用到的设置包括是否开启对多worker process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型处理连接请求，每个worker process可以同时支持的最大连接数等。
这一部分的指令对Nginx服务器的性能影响较大，在实际配置中应该根据实际情况灵活调整。
1.4、http块
http块是Nginx服务器配置中的重要部分，代理、缓存和日志定义等绝大多数的功能和第三方模块的配置都可以放在这个模块中。
前面已经提到，http块中可以包含自己的全局块，也可以包含server块，server块中又可以进一步包含location块，在本文中我们使用“http全局块”来表示http中自己的全局块，即http块中不包含在server块中的部分。
可以在http全局块中配置的指令包括文件引入、MIME-Type定义、日志自定义、是否使用sendfile传输文件、连接超时时间、单连接请求数上限等。
1.5、server块
server块和“虚拟主机”的概念有密切联系。
虚拟主机，又称虚拟服务器、主机空间或是网页空间，它是一种技术。该技术是为了节省互联网服务器硬件成本而出现的。这里的“主机”或“空间”是由实体的服务器延伸而来，硬件系统可以基于服务器群，或者单个服务器等。虚拟主机技术主要应用于HTTP、FTP及EMAIL等多项服务，将一台服务器的某项或者全部服务内容逻辑划分为多个服务单位，对外表现为多个服务器，从而充分利用服务器硬件资源。从用户角度来看，一台虚拟主机和一台独立的硬件主机是完全一样的。
在使用Nginx服务器提供Web服务时，利用虚拟主机的技术就可以避免为每一个要运行的网站提供单独的Nginx服务器，也无需为每个网站对应运行一组Nginx进程。虚拟主机技术使得Nginx服务器可以在同一台服务器上只运行一组Nginx进程，就可以运行多个网站。
在前面提到过，每一个http块都可以包含多个server块，而每个server块就相当于一台虚拟主机，它内部可有多台主机联合提供服务，一起对外提供在逻辑上关系密切的一组服务（或网站）。
和http块相同，server块也可以包含自己的全局块，同时可以包含多个location块。在server全局块中，最常见的两个配置项是本虚拟主机的监听配置和本虚拟主机的名称或IP配置。
listen指令
server块中最重要的指令就是listen指令，这个指令有三种配置语法。这个指令默认的配置值是：listen *:80 | *:8000；只能在server块种配置这个指令。
listen指令的配置非常灵活，可以单独制定ip，单独指定端口或者同时指定ip和端口。
关于上面的一些重要参数做如下说明：
- address：监听的IP地址（请求来源的IP地址），如果是IPv6的地址，需要使用中括号“[]”括起来，比如[fe80::1]等。
- port：端口号，如果只定义了IP地址没有定义端口号，就使用80端口。这边需要做个说明：要是你压根没配置listen指令，那么那么如果nginx以超级用户权限运行，则使用:80，否则使用:8000。多个虚拟主机可以同时监听同一个端口,但是server_name需要设置成不一样；
- default_server：假如通过Host没匹配到对应的虚拟主机，则通过这台虚拟主机处理。具体的可以参考这篇文章，写的不错。
- backlog=number：设置监听函数listen()最多允许多少网络连接同时处于挂起状态，在FreeBSD中默认为-1，其他平台默认为511。
- accept_filter=filter，设置监听端口对请求的过滤，被过滤的内容不能被接收和处理。本指令只在FreeBSD和NetBSD 5.0+平台下有效。filter可以设置为dataready或httpready，感兴趣的读者可以参阅Nginx的官方文档。
- bind：标识符，使用独立的bind()处理此address:port；一般情况下，对于端口相同而IP地址不同的多个连接，Nginx服务器将只使用一个监听命令，并使用bind()处理端口相同的所有连接。
- ssl：标识符，设置会话连接使用SSL模式进行，此标识符和Nginx服务器提供的HTTPS服务有关。
listen指令的使用看起来比较复杂，但其实在一般的使用过程中，相对来说比较简单，并不会进行太复杂的配置。
server_name指令
用于配置虚拟主机的名称。语法是：
对于name 来说，可以只有一个名称，也可以由多个名称并列，之间用空格隔开。每个名字就是一个域名，由两段或者三段组成，之间由点号“.”隔开。比如
在该例中，此虚拟主机的名称设置为myserver.com或www. myserver.com。Nginx服务器规定，第一个名称作为此虚拟主机的主要名称。
在name 中可以使用通配符“*”，但通配符只能用在由三段字符串组成的名称的首段或尾段，或者由两段字符串组成的名称的尾段，如：
另外name还支持正则表达式的形式。这边就不详细展开了。
由于server_name指令支持使用通配符和正则表达式两种配置名称的方式，因此在包含有多个虚拟主机的配置文件中，可能会出现一个名称被多个虚拟主机的server_name匹配成功。那么，来自这个名称的请求到底要交给哪个虚拟主机处理呢？Nginx服务器做出如下规定：
a. 对于匹配方式不同的，按照以下的优先级选择虚拟主机，排在前面的优先处理请求。
- ① 准确匹配server_name
- ② 通配符在开始时匹配server_name成功
- ③ 通配符在结尾时匹配server_name成功
- ④ 正则表达式匹配server_name成功
b. 在以上四种匹配方式中，如果server_name被处于同一优先级的匹配方式多次匹配成功，则首次匹配成功的虚拟主机处理请求。
有时候我们希望使用基于IP地址的虚拟主机配置，比如访问192.168.1.31有虚拟主机1处理，访问192.168.1.32由虚拟主机2处理。
这时我们要先网卡绑定别名，比如说网卡之前绑定的IP是192.168.1.30，现在将192.168.1.31和192.168.1.32这两个IP都绑定到这个网卡上，那么请求这个两个IP的请求才会到达这台机器。
绑定别名后进行以下配置即可：
1.6、location块
每个server块中可以包含多个location块。在整个Nginx配置文档中起着重要的作用，而且Nginx服务器在许多功能上的灵活性往往在location指令的配置中体现出来。
location块的主要作用是，基于Nginx服务器接收到的请求字符串（例如， server_name/uri-string），对除虚拟主机名称（也可以是IP别名，后文有详细阐述）之外的字符串（前例中“/uri-string”部分）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能都是在这部分实现。许多第三方模块的配置也是在location块中提供功能。
在Nginx的官方文档中定义的location的语法结构为：
其中，uri变量是待匹配的请求字符串，可以是不含正则表达的字符串，如/myserver.php等；也可以是包含有正则表达的字符串，如 .php$（表示以.php结尾的URL）等。为了下文叙述方便，我们约定，不含正则表达的uri称为“标准uri”，使用正则表达式的uri称为“正则uri”。
其中方括号里的部分，是可选项，用来改变请求字符串与 uri 的匹配方式。在介绍四种标识的含义之前，我们需要先了解不添加此选项时，Nginx服务器是如何在server块中搜索并使用location块的uri和请求字符串匹配的。
在不添加此选项时，Nginx服务器首先在server块的多个location块中搜索是否有标准uri和请求字符串匹配，如果有多个可以匹配，就记录匹配度最高的一个。然后，服务器再用location块中的正则uri和请求字符串匹配，当第一个正则uri匹配成功，结束搜索，并使用这个location块处理此请求；如果正则匹配全部失败，就使用刚才记录的匹配度最高的location块处理此请求。
了解了上面的内容，就可以解释可选项中各个标识的含义了：
- “=”，用于标准uri前，要求请求字符串与uri严格匹配。如果已经匹配成功，就停止继续向下搜索并立即处理此请求。
- “^～”，用于标准uri前，要求Nginx服务器找到标识uri和请求字符串匹配度最高的location后，立即使用此location处理请求，而不再使用location块中的正则uri和请求字符串做匹配。
- “～”，用于表示uri包含正则表达式，并且区分大小写。
- “～”，用于表示uri包含正则表达式，并且不区分大小写。注意如果uri包含正则表达式，就必须要使用“～”或者“～*”标识。
我们知道，在浏览器传送URI时对一部分字符进行URL编码，比如空格被编码为“%20”，问号被编码为“%3f”等。“～”有一个特点是，它对uri中的这些符号将会进行编码处理。比如，如果location块收到的URI为“/html/%20/data”，则当Nginx服务器搜索到配置为“～ /html/ /data”的location时，可以匹配成功。
root指令
这个指令用于设置请求寻找资源的跟目录，此指令可以在http块、server块或者location块中配置。由于使用Nginx服务器多数情况下要配置多个location块对不同的请求分别做出处理，因此该指令通常在location块中进行设置。
path变量中可以包含Nginx服务器预设的大多数变量，只有$document_root和$realpath_root不可以使用。
alisa指令
index指令
error_page指令
1.7、说明和举例
一点说明
上面列举了Nignx中全局块、event块和http块的一些配置指令，但是Nginx的指令远远不止这些。其实这边最主要的还是讲解整个配置文件的结构，如果大家要看比较全的指令介绍、模块介绍的话，建议去Nginx的官网。
一个配置文件的列子
1.8、四层协议和七层协议
1.8.1 代理原理
4层是指传输层的TCP/UDP协议
7层是指应用层的HTTP协议
(1)4层代理：使用NAT（Network Address Translation）技术，即网络地址转换。即请求进来的时候，nginx只修改数据包里面的目标IP、源IP、端口，然后就直接把数据包发给目标服务器（即nginx不知道请求的具体内容），目标服务器处理完成后，发给nginx，nginx数据包再做一次类似的修改，就返回给请求的客户端了。
(2)7层代理：nginx读取并解析Http请求内容，然后将具体内容(请求行、请求头、空行、请求数据)转发到相应的服务器，转发的过程是：建立和目标机器的连接，然后转发请求，收到响应数据再转发给请求客户端。
1.8.2 总结
- 理论上4层要比7层快，因为7层代理需要解析数据包的具体内容，需要消耗额外的cpu。但nginx具体强大的网络并发处理能力， 对于一些慢连接，nginx可以先将网络请求数据缓冲完，再一次性转发给上游server（目标服务器），这样对于上游网络并发处理能力弱的服务器(比如tomcat)来说，就是将慢连接变成快连接(nginx到tomcat基本上都是可靠内网)，从而节省网络数据缓冲时间，提供并发性能。
- 由于4层代理用的是NAT（“网络地址转换”），所以nginx不知道请求的具体内容，所以nginx啥也干不了。用7层代理，可以根据请求内容(请求行、请求头、空行、请求数据)做很多事情，如动态转发代理、网关拦截、记录请求日志等。
- 由于现在机器cpu性能都很好，4层代理并没有明显的性能优势，而7层代理在业务方面优势明显，所以一般都是使用7层代理
1.9、参考
- 《Nginx高性能Web服务器详解》苗泽 电子工业出版社
2、nginx使用
2.1、反向代理
如：
要访问http://192.168.2.151:1234，如果用反向代理就是：https:xxx.com:2222（此处的2222代表443端口，如果有80和443端口，这个接口就可以省略）
要访问http://192.168.2.151:1234/test1，如果用反向代理就是：https:xxx.com:2222/test1（此处的2222代表443端口，如果有80和443端口，这个接口就可以省略）
2.2、负载均衡
2.3、动静分离
2.4、http跳转https
2.4.1、默认端口运行ssl
2.4.2、自定义端口运行ssl
Nginx 创建了一个自定义 http状态代码，允许您强制重定向任何通过 http浏览虚拟主机的人到 https版本，称为 497。
仅当您在自定义端口上运行 SSL 时才需要，否则您可以使用 上面显示的用于重定向的配置。
要强制浏览器从 http重定向到 https端口，请执行以下操作。
fdsf
2.5、配置高可用集群
简单的就是说，一个nginx服务挂了，然后另一个nginx服务迅速替换它。
准备工作：
1、需要两台服务器(容器也可)：192.168.17.129 和 192.168.17.131
2、在两台服务器中安装nginx
3、在两台服务器中安装keepalived
可使用yum安装
yum install keepalived -y安装之后在/etc里面会生成目录keepalived,有文件keepalived.conf
配置：
nginx: 修改/etc/keepalived/keepalived.conf配置文件
在/usr/local/src添加检测脚本：
启动两台服务上的nginx和keepalived：
- 启动nginx：nginx
- 启动keepalived：systemctl start keepalived.service
在浏览器输入虚拟ip地址：192.168.17.50
测试成功，接着把主服务器上的nginx和keepalived停止，再次访问，依然成功。
原理分析
master-workers的机制的好处：
首先,对于每个worker进程来说,独立的进程,不需要加锁,所以省掉了锁带来的开销,同时在编程以及问题查找时,也会方便很多。其次,采用独立的进程,可以让互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断, master进程则很快启动新的worker进程。当然, worker进程的异常退出,肯定是程序有bug了,异常退出,会导致当前worker上的所有请求失败,不过不会影响到所有请求,所以降低了风险。
需要设置多少个worker?
Nginx同redis类似都采用了io多路复用机制,每个worker都是一个独立的进程,但每个进程里只有一个主线程,通过异步非阻塞的方式来处理请求, 即使是千上万个请求也不在话下。每个worker的线程可以把一个cpu的性能发挥到极致。所以worker数和服务器的cpu数相等是最为适宜的。设少了会浪费cpu,设多了会造成cpu频繁切换上下文带来的损耗。
设置worker数量
worker_processes 4
#work绑定cpu(4 work绑定4cpu)。
worker_cpu_affinity 0001 0010 0100 1000
#work绑定cpu (4 work绑定8cpu中的4个)
worker_cpu_affinity 0000001 00000010 00000100 00001000
连接数worker_connection
这个值是表示每个worker进程所能建立连接的最大值,所以,一个nginx能建立的最大连接数,应该是worker-connections * worker-processes,当然,这里说的是最大连接数,对于HTTP请求本地资源来说,能够支持的最大并发数量是worker-connections * worker_processes,如果是支持http1.1的浏览器每次访问要占两个连接,所以普通的静态访问最大并发数是: worker-connections * worker-processes /2,而如果是HTTP作为反向代理来说,最大并发数量应该是worker_connections*worker-processes/4,因为作为反向代理服务器,每个并发会建立与客户端的连接和与后端服务的连接,会占用两个连接。
3、nas中acme+nginx
3.1、如何安装
3.1.1、在线安装
检查这个项目： https: //github.com/acmesh-official/get.acme.sh
或者：
3.1.2、从 git 安装
克隆这个项目并启动安装：
3.2、颁发证书
3.2.1、 阿里云API
First you need to login to your Aliyun account to get your RAM API key. https://ram.console.aliyun.com/users
Ok, let's issue a cert now:
3.2.2 、其他方式
3.3、证书安装到 Apache/Nginx
生成证书后，您可能希望将证书安装/复制到您的 Apache/Nginx 或其他服务器。您必须使用此命令将证书复制到目标文件，不要使用**~/.acme.sh/**文件夹中的证书文件，它们仅供内部使用，文件夹结构将来可能会更改。
3.3.1、Apache example:
3.3.2 、Nginx example:
只有域是必需的，所有其他参数都是可选的。
保留现有文件的所有权和权限信息。您可以预先创建文件以定义所有权和权限。
安装/复制证书/密钥到生产 Apache 或 Nginx 路径。
默认情况下，证书将每60天更新一次（可配置）。更新证书后，Apache/Nginx 服务将通过命令自动重新加载：
service apache2 force-reload或service nginx force-reload。请注意：reloadcmd 非常重要。证书可以自动更新，但是，如果没有正确的“reloadcmd”，证书可能不会刷新到您的服务器（如 nginx 或 apache），那么您的网站将无法在 60 天内显示更新的证书。
3.4、参考网站：
3.5 附件
4、nas中nginx-proxy-manager
4.1、nginx-proxy-manager的安装
4.2、nginx-proxy-manager配置优化
具体如下：
4.2.1 server_proxy.conf
4.2.2 修改/app/templates/_listen.conf
sed -i 's/443/8888/g’ /app/templates/_listen.conf #将创建代理网站时默认的443口更改为8888端口
4.2.3 修改/etc/nginx/conf.d/default.conf
sed -i 's/443/8888/g' /etc/nginx/conf.d/default.conf#将/etc/nginx/confd/defaultconf的https监听端口也改为8888
4.3、配置持久化到容器内
修改安装里面的映射即可
4.4、nginx-proxy-manager界面配置
在界面配置ssl和各种转发，如果不会，看nginx-proxy-manager官方网站或者装中文版，很简单的
4.5、针对部分请求还是出现问题的
如：docker版的chevereto的，修改一下nginx-proxy-manger的高级配置
4.6、附件
5、docker版的certbot与nginx
docker部署certbot与nginx来获取ssl证书添加https及自动更新
5.1、起因
- 原先一直有一个腾讯云的1核和1G的服务器在闲着，只是偶尔用下
frp来映射开发演示，这次想再利用下，于是试下搭建bitwarden，转而找到更加小巧的vaultwarden,但实际浏览器插件测试必须是要https才行，所以必须要有域名及证书，顺便就想试下certbot来自动续签。
- 域名随便在阿里云上弄了个
top的，10年￥189，要想解析到服务器是要备案的，所以又在腾讯云上备案，大约有7、8个工作日吧，备案才通过，此时可以正常访问了，然后还要30日内进行公安备案。
- 由于服务器上的
nginx、frp、vaultwarden都是docker来部署的，那certbot也顺便就用docker，官方虽然提供了docker镜像，但实际上并不是很推荐使用，因为容器内比较难触发外部的一些操作，会导致一些自动配置的功能很难使用，参考官方文档：Running with Docker。没实际安装前个人也觉得用docker更方便，但实际操作完成后会发现还是官网说的对，没特殊情况不要用docker来做这些。
5.2、certbot
发放证书前需要验证域名的合法性，确保你申请证书的域名是你的，验证方式主要分两种：
- 通过http请求验证，会向
http://你的域名/.well-known/acme-challenge/发送一条请求。
- 通过dns解析，需要在域名解析中增加一条
_acme-challenge.你的域名的TXT记录用于验证。
certbot的命令有很多种不同的参数，这些参数也主要是为了自动生成http验证文件或自动添加dns解析等功能，主要的大体说下：-manual，手动配置，你可以自己选择http验证还是dns验证都行，需要自己纯手工去配置http验证文件或是dns解析，个人没有做测试。
-nginx，走http验证，如果不用docker且用nginx感觉是最方便的，会自动修改nginx的配置文件，增加http请求的访问配置及后续的ssl配置，但由于我们certbot是在docker容器内，所以要修改另一个nginx容器的配置文件及控制启停不太好实现，所以不采用这种方式。查资料时发现有人会将nginx和certbot通过dockerfile打包到一个镜像内，这样此命令就比较方便的执行了，感觉是个好办法，但个人没有测试了解。
-dns-xxx，走dns解析验证，这个也很方便，配置好后会自动在域名解析中增加一条记录进行域名验证，但官方目前只支持国外的一些dns服务商，国内的阿里云、dnspod等貌似也有第三方的插件，可以自己去github上找下。如果想申请通配符泛域名的，则只能通过此方式，目前个人没有测试。
-standalone，走http验证，这种方式你就算是没有nginx等服务，仍然可以验证域名并获取证书，它会虚拟一个服务来进行验证，但需要保证你的80端口别被占用，由于我这边有nginx了，所以便没有用此类方法测试。
-webroot，走http验证，已有类似nginx等服务的情况下可以用此方法，会自动在你配置的目录下生成http验证文件，与standalone相比好处是不需要预留80端口，也就是原有的网站不需要停止就可以申请证书，而缺点就是你还需要在nginx等服务中手动配置/.well-known/acme-challenge/使其对应到自动生成的验证文件上。后续我们用的就是这种。
通过
webroot的方式运行后，会在两个地方产生文件：- 一个是在命令行配置的
-webroot-path指定目录下产生临时文件，用于http验证。
- 一个是验证成功会产生存放证书的文件，默认是在
/etc/letsencrypt/live/你的域名目录下，需要注意的是这些证书是个软链接，对应着../archive下，所以我们在做volume映射时不要只映射到live这个目录，而是要映射/etc/letsencrypt这个目录，否则无法找到相关的证书文件。
以上两个文件虽然是
certbot容器生成的，但我们nginx容器都会用到，所以我们需要用宿主机做为中转，在certbot和nginx容器中都配置映射到宿主机的同一个目录，从而实现certbot容器和nginx容器共用文件。我的服务器home/ubuntu/docker下的目录可参照：5.3、准备
- 有个服务器
- 有个已经备案且解析到服务器上的域名
- 安装
docker和docker-compose，照着官网来就行，很详细：Docker Documentation，docker如果下载镜像慢，可以注册个阿里云账号，然后在【容器镜像服务】中找到【镜像工具】下的【镜像加速器】中按照说明来配置。
5.4、开始
- 主要是把
volume映射弄好，顺便配置好nginx的相关http验证： - docker-compose.yml:
- nginx配置valtwarden.conf:
- 上方的volumes映射串联关系如下，通过宿主机来实现
certbot和nginx中相关的目录实际上是同一个目录，除了certbot中的/etc/letsencrypt是固定的外，其余的目录都是可以随便找目录放，只要对应起来就行。
目录 | certbot | 宿主机 | nginx |
http验证目录 | /usr/share/certbot/www | /home/ubuntu/docker/certbot/www | /usr/share/certbot/www |
证书目录 | /etc/letsencrypt | /home/ubuntu/docker/certbot/ssl | /usr/share/certbot/ssl |
docker-compose up -d nginx先把nginx开启，然后测试证书发放是否可以：
- 输入邮箱等信息，如果提示
The dry run was successful则说明成功，可以去掉-dry-run参数来进行实际的获取证书
- 如果上方正常，则会在
certbot容器下的/etc/letsencrypt下也就是nginx容器下的/usr/share/certbot/ssl下产生证书，此时，只需要配置nginx配置ssl即可，还是在文件valtwarden.conf中：
- 以上
docker-compose exec nginx nginx -t检测配置nginx文件是否有问题，docker-compose exec nginx nginx -s reload或者是直接docker-compose restart nginx来重启nginx
- 正常启动的话应该就没问题了，我们接着需要做定期更新证书，主要就是为了这个，否则直接腾讯云、阿里云申请一年的免费证书好了。增加计划任务，
sudo crontab -e打开定时任务编辑，每月1号和15号运行一次
以上是计划任务相关。
certbot容器中renew虽然有--deploy-hook等实际更新后触发钩子的功能，但由于和nginx不在同一个容器，因此无法触发nginx重启，所以上述命令不管是否证书真正更新成功nginx是一定会重启的，最好放到深夜执行。搜索了下从一个容器中控制另一个容器的操作，一种是本容器内装docker，然后映射宿主机内的docker.sock，这样容器内操作docker就和宿主机内操作一致了；还有一种就是ssh来连接另一个容器来操作了，这两种都挺麻烦的，这里就没必要也不做尝试了。5.5、其它
certbot申请证书是有次数限制的，重复申请5次以上，再次请求会报too many certificates already issued...等错误，会停用一周后才能再继续，此时只能再换个域名或者是等一周了，参考速率限制。
- 除官网外的参考文档：HTTPS using Nginx and Let's encrypt in Docker，写的很详细。
- 最后的最后，感觉还是官网说的对，压根没必要用
docker来运行certbot，首先这个容器不需要常开，只是用一次就关闭的，而容器的各种空间映射增加了复杂度，其次一些回调钩子由于容器的原因无法调用，所以还是建议不要有强迫症，直接在宿主机安装就好了。而且更建议安装dns插件来用dns方式验证，这样可以申请通配符ssl，非常适用于多个二级域名的情况，但这些dns插件用docker的话更不容易找到相关的镜像，自己实现起来也很麻烦。
- 个人的网站可以尝试下
caddy，自带https，不需要这么麻烦的配置。
5.6、资料
6、Nginx中安装Certbot
在Nginx官方镜像的基础上安装Certbot，让你的web应用随时随地插上https的翅膀。
6.1、在Nginx官方Docker镜像中安装Certbot
Certbot在生成证书时，会扫描/etc/nginx/conf.d/文件夹下的conf配置文件，将配置文件中的域名生成SSL证书并修改配置文件，所以如果应用部署在Nginx的Docker镜像中，则需要在镜像中安装Certbot。
当然可以选择每次部署应用时都安装一遍Certbot，但这违背了Docker的初衷。Docker的就是为了一次打包，随时使用，所以我们应该在Nginx镜像的基础上安装Certbot，并生成新的镜像上传至DockerHub。
先上Dockerfile
这里用的是Debian8的安装方法（后来才知道Nginx镜像中的Linux版本是Debian9，不过没什么影响），而且走了很多弯路。一开始并不知道
--install-only这个参数，手动改了certbot-auto文件好久，就是为了只安装而不执行操作（官网教程并没有告诉我......）。certbot-auto是一个sh脚本，在certbot-auto文件里发现了--install-only这个参数，加上之后就可以只安装而不执行了。直到后来脑子突然反应过来，我TM应该先--help一下。不过这也不是一件坏事，读sh脚本可以学到很多东西，就当是交学费了。由于国内你懂得的网速，镜像的构建需要相当长的时间，所以我把构建放在了DockerHub上，这是镜像地址：
https://hub.docker.com/r/yuhaow/nginx
6.2、使用方法
下载镜像
启动镜像
介绍一下这几个参数：
v /docker/nginx/conf.d:/etc/nginx/conf.d挂载配置文件夹，方便添加及修改配置
v /docker/nginx/logs:/var/log/nginx挂载日志文件夹
v /docker/nginx/letsencrypt:/etc/letsencrypt挂载证书文件夹
v /etc/localtime:/etc/localtime:ro修改镜像时区与服务器同步
p 80:80 -p 443:443端口映射
生成证书
更新证书
自动更新
参考官网的
crontab