Updated on 2019/8/1
后来发现了docker-letsencrypt-nginx-proxy-companion这个Docker镜像，自动完成搭建nginx反向代理和申请Let's Encrypt证书的过程，过于舒适，已转而使用之……
前些日子捣鼓了一下Docker，把自己服务器上运行的服务都用Docker来承载了。以前用过Let's Encrypt的SSL证书，但之前申请证书的certbot工具不是在Docker上跑的。为了在Docker环境下申请证书，我研究了一段时间，找到了adferrand/letsencrypt-dns这个镜像，以让我使用DNS验证的方式申请证书，并且完成证书定期更新的工作。 申请成功之后，在Nginx的docker-compose配置文件中，把证书文件所在的目录挂载到容器里： 
在Nginx的域名配置文件里把SSL证书添加进去： 
运行Nginx容器后，却报错，提示找不到证书文件，"no such file or directory"： 
最初认为是权限问题。因为我以普通用户的身份，不能进入证书所在的目录，于是猜测是否有可能是Docker在挂载目录的时候也因为权限问题，导致另一个容器无法访问之。参照这里在配置文件中设置了文件和文件夹权限，设置后我以普通用户的身份可以访问了，但Nginx仍然报错。（这里有个插曲：我起初按照上述链接所述的，令CERTS_USER_OWNER和CERTS_GROUP_OWNER为我建立的用户和对应的组"docker"，但在主机里发现文件权限并没有变，进入letsenrypt-dns容器后手动执行命令提示"chown: unknown user/group". 后来在镜像的GitHub Issue页看到了作者对这个问题的回答：User and group owner variables are being ignored?，他提到这种情况下需要使用主机里的UID和GID填入配置文件里的CERTS_USER_OWNER和CERTS_GROUP_OWNER.） 后来查到StackOverflow上的这个问题：nginx-ssl-no-such-file-or-directory-with-docker。有个答主提到，letsencrypt/live目录中的证书，是指向letsencrypt/archive目录中的文件的软链接。我遇到的问题，可能是Nginx的docker-compose配置文件中的挂载目录设置不当，软链接失效导致的。 进入容器中查看，发现确实如此：
将Nginx的docker-compose配置文件中的挂载目录修改成下面的样子： 
再次进入容器，查看软链接的情况，现在是正常的了： 
现在再访问网站，证书已经成功加载了： 
问题解决！