在Docker上部署自动更新ssl证书的nginx + .NET Core

突发奇想要搞一个ssl的服务器,然后我就打起了docker的主意,想着能不能搞一个基于Docker的服务器,这样维护起来也方便一点。

设想

想法是满足这么几点:

  1. .NET Core on Docker
  2. Let’s Encypt on Docker
  3. nginx on Docker用于反向代理
  4. Let’s Encypt证书有效期很短,需要能够自动更新

nginx与dotnet都提供了docker部署的方案,但是Let’s Encypt的certbot提供的文档强调了这个方法不是很推荐,主要原因是从其他位置不太方便访问certbot的证书。当然可以通过volumes映射文件访问,但是端口80和443的独立占用也不好解决,或许DNS验证的方法可行?

这方面我也不是很懂啊,就换一种思路,将nginx和certbot放在一个container,.NET Core单独放在一个地方。由nginx加载证书并提供反向代理,.NET Core程序提供一个http访问即可,不需要证书。如果后续续期了,还可以顺带一并处理nginx刷新的事情。

方法

准备

确定你有一个能够正确解析到主机的域名,假设是yourdomain.com。我这里操作的主机是CentOS 8的,其他发行版,包括windows也应该操作方式类似。

接下来我们先看看两个单独都应该怎么配置。

nginx+certbot

首先是制作docker image,选择一个比较简单的linux发行版,比如alpine进行。先建立一个Dockerfile

FROM nginx:alpine
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories
RUN sed -i 's/http/https/g' /etc/apk/repositories
RUN apk update
RUN apk add certbot certbot-nginx
RUN mkdir /etc/letsencrypt
COPY nginx.conf /etc/nginx/nginx.conf

然后在当前目录创建一个nginx配置文件

为什么不使用conf.d的网站配置,而是直接修改nginx.conf?由于我想直接使用certbot的--nginx指令直接配置nginx,如果使用了子配置的形式,certbot认不出来。

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;
     
    #include /etc/nginx/conf.d/*.conf;
	server {
	    listen       80;
	    server_name  yourdomain.com;# 注意名称一定要是你需要验证的域名
	
	    location / {
	        root   /usr/share/nginx/html;
	        index  index.html index.htm;
	    }
	
	    error_page   500 502 503 504  /50x.html;
	    location = /50x.html {
	        root   /usr/share/nginx/html;
	    }
	}
}

然后在当前目录执行

docker build . -t nginx-certbot --network=host

编译完成之后,就是运行了,需要打开80端口用于验证。

docker run -v $(pwd)/letsencrypt:/etc/letsencrypt -d -p 80:80 -p 443:443 nginx-certbot

第一次运行需要手动申请一下新的证书,运行

docker exec -it [你的container_name] sh

进入了交互式界面,继续执行

certbot --nginx -d yourdomain.com

按照提示一步一步即可完成域名验证。

然后需要增加一个自动运行的服务,可以使用crond,先增加一条运行任务。

echo "0 0 1 * * /usr/bin/certbot renew --quiet" >> /etc/crontabs/root

具体的crond设置的方法,可以参考其他文章,上面设置每个月1号执行。不能设置太勤,会被block
运行ps,如果crond不在运行,手动运行一下crond即可。
全部完成之后,运行exit退出container的shell。

.NET Core app

首先dotnet new webapp,然后直接build,即可生成一个默认发布在5000端口的app,反向代理需要有一个设置,添加一个请求头:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
        ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

然后执行dotnet publish命令,就可以生成可以发布执行的文件了。(这里可以参考官方的文档,不是本文重点我就不写了。)

下一步是制作Dockerfile。

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY published/* ./
ENTRYPOINT ["dotnet","dot.dll"]

注:现在dotnet版本不同,可能生成所在的监听端口也有不同。

整合

掌握了上面的基础之后,我们需要整合了,
修改nginx.conf

# For more information on configuration,see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    # include /etc/nginx/conf.d/*.conf;

    server {
    listen        80;
    server_name   yourdomain.com; 
    location / {
        proxy_pass         http://192.168.48.2:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}


}

设置好了之后,还是前面分部的步骤来,就先启动ASP.NET Core然后再启动nginx就好了。注意需要提前创建bridge网络,并将两个container加入进来,并且将上面的IP设置成对应的IP,要不会导致无法正常转发。

优化与改进

有的老铁已经发现了,这种方法比较麻烦,第一次启动的时候,需要做的事情很多,第二次启动很多配置也会丢失,而且还要手动创建网络,有没有什么好办法呢?
有两个地方可以进行优化:

  1. crond部分有一个增加自动化任务的工作,我这里使用了echo方法向crond增加记录,其实完全可以自动化这个步骤并确保这个服务启动。其实可以将这个内容在build中打包进去,或者也可以使用docker-compose设置启动的命令。

  2. nginx.conf提取出来,以更好服务.NET Core,可以使用volume进行映射,通过本机映射文件的形式进行管理。

按照上面的思路,使用docker-compose优化一下,首先编写一个docker-compose.yml

version: '3.7'

services: 
    aspnetcoreapp:
        image: aspdot  
        container_name: "aspnetcoreapp"  
        networks:  
        - mynetwork  

    proxy:  
        depends_on:
        - aspnetcoreapp  
        image: nginx-cerbot 
        container_name: "nginxcore"  
        ports:   
        - 80:80
        - 443:443 
        command: sh -c "echo '0 0 1 * * /usr/bin/certbot renew  --quiet' >> /etc/crontabs/root & crond & nginx -g 'daemon off;'" 
        volumes:
        - ./nginx.conf:/etc/nginx/nginx.conf
        - ./letsencrypt:/etc/letsencrypt
        # - ./default.conf:/etc/nginx/conf.d/default.conf
        # - ./html/:/usr/share/nginx/html/
        - ./logs/:/var/log/nginx/
        restart: always
        networks:  
        - mynetwork  

networks:
    mynetwork: 
        driver: bridge

注:alpine版本的nginx启动的cmd默认是nginx -g daemon off;,docker-compose的command段只能覆盖默认CMD,不能追加,所以需要在命令中最后执行这个才行。另外,这个crond默认在后台不能正常运行,需要在Command命令中指定才能正常触发执行(在container中只有执行crond -f才能正常工作)。

之后,运行

docker-compose up -d

程序正常运行,然后再按照上面nginx+certbot的操作进行即可,certbot会自动处理nginx的ssl转换问题,可以看到我的nginx.conf变成了这样:

# For more information on configuration,see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    # include /etc/nginx/conf.d/*.conf;

    server {
    server_name   yourdomain.com;
    location / {
        proxy_pass         http://192.168.48.2:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}




    server {
    if ($host = yourdomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen        80;
    server_name   yourdomain.com;
    return 404; # managed by Certbot


}}

至此,整个系统已经正常运行了。

FAQ

1. 自动更新证书成功,访问服务的时候,依然提示证书过期错误。

nginx证书如果是手动加载的话,自动更新证书之后,nginx不会自动加载新的证书,只有重新nginx -s reload之后才能正确加载。如果是certbot --nginx的话,后续的renew会自动重新加载nginx配置的。

2. docker build中下载资源出现temporary error错误

由于docker的bridge模式导致的,有两种方案可以处理,可以在build命令中指定--network=host或者直接指定docker全局的DNS。参考这篇文章

3. 删除镜像的时候,提示还有container在引用,无法删除。

docker ps显示并没有活动的容器,但是容器其实还在的,有几条命令可以派上用场。

  • docker ps -a # 显示所有容器
  • docker stop $(docker ps -a -q) # 停止所有容器
  • docker rm $(docker ps -a -q) # 删除所有容器
    通过这几个命令就可以把残留的container删除干净了。

4. nginx提示502 bad gateway

这里需要提醒一下,由于docker网络bridge的机制,不同contianer之间是不能使用localhost或者127.0.0.1进行相互访问的,需要使用到该container的IP(实际上是docker分配的虚拟IP)。可以使用docker inspect [containerId]查看容器分配的ip地址。

参考

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发、订阅和处理的流程。这种实现太简单了,百十行代码就展示了一个基本工作原理。然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走。今天,我们就研究一下在事件处理器中,对象生命周期的管理问题。事实上,不仅仅是在事件处理器
上文已经介绍了Identity Service的实现过程。今天我们继续,实现一个简单的Weather API和一个基于Ocelot的API网关。 回顾 《Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)》 Weather API Weather
最近我为我自己的应用开发框架Apworks设计了一套案例应用程序,并以Apache 2.0开源,开源地址是:https://github.com/daxnet/apworks-examples,目的是为了让大家更为方便地学习和使用.NET Core、最新的前端开发框架Angular,以及Apwork
HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度。很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支
在前面两篇文章中,我详细介绍了基本事件系统的实现,包括事件派发和订阅、通过事件处理器执行上下文来解决对象生命周期问题,以及一个基于RabbitMQ的事件总线的实现。接下来对于事件驱动型架构的讨论,就需要结合一个实际的架构案例来进行分析。在领域驱动设计的讨论范畴,CQRS架构本身就是事件驱动的,因此,
HAL,全称为Hypertext Application Language,它是一种简单的数据格式,它能以一种简单、统一的形式,在API中引入超链接特性,使得API的可发现性(discoverable)更强,并具有自描述的特点。使用了HAL的API会更容易地被第三方开源库所调用,并且使用起来也很方便
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用
《在ASP.NET Core中使用Apworks快速开发数据服务》一文中,我介绍了如何使用Apworks框架的数据服务来快速构建用于查询和管理数据模型的RESTful API,通过该文的介绍,你会看到,使用Apworks框架开发数据服务是何等简单快捷,提供的功能也非常多,比如对Hypermedia的
在上一讲中,我们已经完成了一个完整的案例,在这个案例中,我们可以通过Angular单页面应用(SPA)进行登录,然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中,我们会讨论在当前这种架构的应用程序中,如何完成用户授权。 回顾 《Angular SPA基于
Keycloak是一个功能强大的开源身份和访问管理系统,提供了一整套解决方案,包括用户认证、单点登录(SSO)、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务,可以简化和统一不同应用程序和服务的安全管理,支持自托管或云部署,适用于需要安全、灵活且易于扩展的用
3月7日,微软发布了Visual Studio 2017 RTM,与之一起发布的还有.NET Core Runtime 1.1.0以及.NET Core SDK 1.0.0,尽管这些并不是最新版,但也已经从preview版本升级到了正式版。所以,在安装Visual Studio 2017时如果启用了
在上文中,我介绍了如何在Ocelot中使用自定义的中间件来修改下游服务的response body。今天,我们再扩展一下设计,让我们自己设计的中间件变得更为通用,使其能够应用在不同的Route上。比如,我们可以设计一个通用的替换response body的中间件,然后将其应用在多个Route上。 O
不少关注我博客的朋友都知道我在2009年左右开发过一个名为Apworks的企业级应用程序开发框架,旨在为分布式企业系统软件开发提供面向领域驱动(DDD)的框架级别的解决方案,并对多种系统架构风格提供支持。这个框架的开发和维护我坚持了很久,一直到2015年,我都一直在不停地重构这个项目。目前这个项目在
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名《Angular单页面应用基于Ocelot API网关与IdentityServer4ʺSP.NET Identity实现身份认证与授权》,然而如你所见,这样的名字实在是太长了。所以,我不得不缩写“单页面应用”几个字
在前面两篇文章中,我介绍了基于IdentityServer4的一个Identity Service的实现,并且实现了一个Weather API和基于Ocelot的API网关,然后实现了通过Ocelot API网关整合Identity Service做身份认证的API请求。今天,我们进入前端开发,设计
Ocelot是ASP.NET Core下的API网关的一种实现,在微服务架构领域发挥了非常重要的作用。本文不会从整个微服务架构的角度来介绍Ocelot,而是介绍一下最近在学习过程中遇到的一个问题,以及如何使用中间件(Middleware)来解决这样的问题。 问题描述 在上文中,我介绍了一种在Angu
在大数据处理和人工智能时代,数据工厂(Data Factory)无疑是一个非常重要的大数据处理平台。市面上也有成熟的相关产品,比如Azure Data Factory,不仅功能强大,而且依托微软的云计算平台Azure,为大数据处理提供了强大的计算能力,让大数据处理变得更为稳定高效。由于工作中我的项目
在上文中,我们讨论了事件处理器中对象生命周期的问题,在进入新的讨论之前,首先让我们总结一下,我们已经实现了哪些内容。下面的类图描述了我们已经实现的组件及其之间的关系,貌似系统已经变得越来越复杂了。其中绿色的部分就是上文中新实现的部分,包括一个简单的Event Store,一个事件处理器执行上下文的接
在之前《在ASP.NET Core中使用Apworks快速开发数据服务》一文的评论部分,.NET大神张善友为我提了个建议,可以使用Compile As a Service的Roslyn为语法解析提供支持。在此非常感激友哥给我的建议,也让我了解了一些Roslyn的知识。使用Roslyn的一个很大的好处
很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构。这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便