Docker on 个人技术随想

Podman迁移计划

Wed, 03 Dec 2025 16:00:00 +0800

从Incus出发

在过去的一些文章里，我曾经着迷于Incus作为容器实现。

在我看来，LXC/Incus那一套共享内核同时分隔文件系统与命名空间的法则很有魅力，用来创建低开销的类虚拟机实例再适合不过了。

不过，Incus的局限也有不少，或许配置麻烦就是其中之一，需要用户学习一套全新的配置模式。

另一方面，尽管Incus已经实现OCI镜像支持，但它不直接兼容当下流行的Dockerfile + Docker Compose模式。

理论上，这两者可被Canonical生态的cloud-init脚本替代，Incus对此有非常好的支持，但改写这些脚本总归是一个调试繁琐、易出Bug的工作。

说到底，Incus更偏向于系统级容器的理念，本身就和Docker/Podman的应用级容器定位有很大差异。

如果仍然迷恋Docker风格的应用级容器，或许可以试试Podman，其绝大部分操作API或指令均和Docker相似，并默认运行在用户态，不依赖root权限级别的daemon。

安装

Podman的安装非常简单，在Debian下只需要：

`1`	`sudo apt install podman`

在Windows下安装也非常简单，可参考Podman for Windows文档。基本步骤是：

前往Github Release，下载最新版podman-installer-windows-amd64.exe文件（MSI也行；别被附件里几个不同名字的.exe骗了，它们的SHA256可能是相同的）；
开始安装，安装时可选HyperV或WSL后端，推荐WSL；
安装程序结束后，打开命令提示符，执行podman machine init，自动下载宿主虚拟机/WSL镜像并导入

若是好奇podman machine init命令干了什么，可以翻阅上面的文档，内有非常详细的介绍。

常见问题

找不到podman.sock

/run/user/<uid>/podman/podman.sock No such file or directory

请尝试：

`1`	`systemctl --user enable --now podman.socket`

容器莫名其妙自动结束

如果是以下情况：用户在保持有登录会话（如SSH）时，容器从不自动结束。而在用户关闭所有会话后一小段时间内，容器就自动退出了。

那么请尝试：

`1`	`sudo loginctl enable-linger <username>`

Windows WSL Podman设置代理

若要让基于Windows WSL的Podman使用宿主机网络代理，通常要先确定宿主机的IP，再设置环境变量。

太麻烦了，让我们用一个脚本解决这个问题吧。

使用方法：

复制以下脚本
根据自己的网络配置修改USER CONFIGURATION配置项
打开Podman WSL Machine，在WSL的/etc/profile.d/文件夹下新建个配置文件，贴进去

📝 WSL代理自动配置脚本

`/etc/profile.d/wsl-proxy.sh`

#!/bin/bash
# WSL Proxy Environment Setup Script
# Place this script in /etc/profile.d/ to auto-load proxy settings for all users
# Or source it manually

# =============================================================================
# USER CONFIGURATION SECTION
# Modify these variables according to your proxy server settings
# =============================================================================

# Proxy protocol schema (http, https, socks4, socks5)
# Default: http
PROXY_SCHEMA="${PROXY_SCHEMA:-http}"

# Proxy server hostname or IP address
# Use "{GATEWAY}" to automatically detect Windows host IP via WSL gateway
# PROXY_HOST="${PROXY_HOST:-localhost}"
PROXY_HOST="{GATEWAY}"

# Proxy server port number
# Default: 8080
PROXY_PORT="${PROXY_PORT:-8080}"

# Proxy authentication username (leave empty if not required)
# Default: empty
PROXY_USER="${PROXY_USER:-}"

# Proxy authentication password (leave empty if not required)
# Default: empty
PROXY_PASSWORD="${PROXY_PASSWORD:-}"

# Comma-separated list of addresses to bypass proxy
# These domains/IPs will not use the proxy connection
# Default: local addresses (localhost, 127.0.0.1, etc.)
PROXY_BYPASS="${PROXY_BYPASS:-localhost,127.0.0.1,::1,169.254.169.254}"

# =============================================================================
# INTERNAL FUNCTIONS
# =============================================================================

# Detect WSL gateway IP address (Windows host IP)
# This is useful when proxy server runs on Windows host
_get_wsl_gateway() {
    local gateway_ip
    # Method 1: Use ip route to find default gateway
    gateway_ip=$(ip route show default 2>/dev/null | awk '/default/ {print $3}' | head -n1)

    # Method 2: Fallback to /etc/resolv.conf nameserver (WSL2)
    if [[ -z "$gateway_ip" ]] && [[ -r /etc/resolv.conf ]]; then
        gateway_ip=$(awk '/^nameserver/ {print $2; exit}' /etc/resolv.conf)
    fi

    # Method 3: Fallback to Windows host IP pattern (WSL1)
    if [[ -z "$gateway_ip" ]]; then
        gateway_ip=$(ip route show | grep -oP 'via \K[0-9.]+' | head -n1)
    fi

    echo "$gateway_ip"
}

# Build proxy URL with optional authentication
_build_proxy_url() {
    local schema="$1"
    local host="$2"
    local port="$3"
    local user="$4"
    local password="$5"

    local url="${schema}://"

    # Add authentication if credentials provided
    if [[ -n "$user" ]]; then
        url+="${user}"
        if [[ -n "$password" ]]; then
            url+=":${password}"
        fi
        url+="@"
    fi

    # Add host and port
    url+="${host}:${port}"

    echo "$url"
}

# =============================================================================
# MAIN EXECUTION
# =============================================================================

# Resolve special {GATEWAY} keyword to actual WSL gateway IP
if [[ "$PROXY_HOST" == "{GATEWAY}" ]]; then
    PROXY_HOST=$(_get_wsl_gateway)

    # Validate gateway detection
    if [[ -z "$PROXY_HOST" ]]; then
        echo "Warning: Failed to detect WSL gateway IP. Using 'localhost' as fallback." >&2
        PROXY_HOST="localhost"
    fi
fi

# Construct full proxy URL
PROXY_URL=$(_build_proxy_url "$PROXY_SCHEMA" "$PROXY_HOST" "$PROXY_PORT" "$PROXY_USER" "$PROXY_PASSWORD")

# Export standard proxy environment variables
export HTTP_PROXY="$PROXY_URL"
export http_proxy="$PROXY_URL"
export HTTPS_PROXY="$PROXY_URL"
export https_proxy="$PROXY_URL"

# Export no-proxy settings
export NO_PROXY="$PROXY_BYPASS"
export no_proxy="$PROXY_BYPASS"

# =============================================================================
# VERBOSE OUTPUT (optional)
# Uncomment the following lines to enable debug output
# =============================================================================
# echo "WSL Proxy Configuration Loaded:"
# echo "  HTTP_PROXY:  $HTTP_PROXY"
# echo "  HTTPS_PROXY: $HTTPS_PROXY"
# echo "  NO_PROXY:    $NO_PROXY"

为容器启用N卡

通常来说，只需要首先安装NVIDIA Container Toolkit，然后使用以下命令启动容器：

`1`	`podman run --rm --gpus all docker.io/debian:trixie-slim nvidia-smi`

找不到GPU

Podman主要通过Container Device Interface (CDI)寻找调用系统中的显卡。

在安装NVIDIA Container Toolkit时，会附带一个Systemd服务nvidia-cdi-refresh.service，该服务理论上会在后台运行，自动查找系统中的N卡并刷新CDI信息。

可以通过以下命令查看N卡是否成功注册到CDI中，正常应该是这样的：

$ nvidia-ctk cdi list
INFO[0000] Found 3 CDI devices                          
nvidia.com/gpu=0
nvidia.com/gpu=GPU-12345678-1234-5678-90ab-1234567890ab
nvidia.com/gpu=all

然而，有时这一服务无法正常运行（可通过sudo systemctl status nvidia-cdi-refresh.service查看），上述服务不能正确更新CDI中的N卡注册信息，最终会导致Podman无法找到我们想要启用的显卡资源。

解决方法是，可以手动运行CDI注册命令：

`1`	`sudo nvidia-ctk cdi generate --output=/var/run/cdi/nvidia.yaml`

Podman Compose设置GPU

在docker-compose.yml文件中，可以这样定义使用GPU:

services:
  llama-server:
    image: nvidia/cuda:12.2.0-runtime-ubuntu22.04
    command: ["nvidia-smi"]
    devices:
      - nvidia.com/gpu=all

如果使用Docker Compose运行，可能会遇到错误：Error response from daemon: container create: stat nvidia.com/gpu=all: no such file or directory

解决方法非常简单：请使用Podman-Compose而不是Docker-Compose:

1
2
3

sudo apt install podman-compose

podman-compose -f docker-compose.yml up

Tailscale/Headscale自建异地组网

Sat, 11 Jan 2025 20:00:00 +0800

曾经用过一段时间的Zerotier作为异地组网/内网穿透的工具，用了一段时间感觉还行。

后来听说了Tailscale这个工具，再后来了解到了还有Headscale这样的开源实现，觉得这玩意似乎更加优雅，于是，折腾了半个晚上后总算把网络组起来了。在这里记录一下详细的过程。

术语

这类网络工具总是存在非常多的专有名词，所以得稍微先介绍一下：

Tailscale

Tailscale是一个基于WireGuard协议的组网工具。这一协议的好处是，在建立设备间通信时会尝试打洞，从而实现设备之间的P2P点对点通信，即便这些设备位于一些NAT网关后（不过根据NAT类型不同，打洞成功的可能性也不同，可参见：How NAT traversal works）。

Tailscale的工作流程不准确概括如下，如果希望更深入了解，可以阅读Tailscale: How it works。

Tailscale官方搭设了一系列中央服务器，为用户提供注册、通信建立与数据中继等功能。
用户在需要组网的设备上安装Tailscale客户端，登录账号并加入虚拟子网。
虚拟子网建立后，所有子网内设备在通信时，将先与Tailscale中央服务器进行通信，判断两个设备间能否直连（打洞）。
如果能打洞，直连(DIRECT)；如果不能打洞，则两个设备间的通信将需要中继服务器转发流量，即中继连接(RELAY)。

Tailscale服务器

值得注意的是，在Tailscale中，中央服务器和中继服务器可以是不同的服务器。

中央服务器, Control Server: 控制用户认证、存储组网配置等信息。
中继服务器, DERP Server: 专用于在设备间无法建立P2P直接通信时，转发设备间流量实现互相访问。

值得注意的是，所有设备间流量在网络上传输时都是加密的，且私钥都在设备本地，因此通常认为中继服务器是无法解密传输流量的。

Headscale

Tailscale官方尽管允许自行部署DERP服务器，但Tailscale中央服务器程序是闭源的，官方也不允许我们部署。而人们又常常因为一些原因，想要或者需要搭建自己控制的中央服务器，真正地将所有信息都掌控在可控范围内。

因此，Headscale，也就是今天我们要介绍的主角出现了。Headscale是Tailscale中央服务器程序的开源实现，并采用了BSD协议发行，我们可以任意部署到我们的服务器上。

有意思的是，Headscale的一位主要开发者实际上是Tailscale公司的雇员，Headscale的开发也受到了Tailscale公司的支持，参见: Making heads or tails of open source。

除了基本的Headscale程序，我们今天还会稍稍提一嘴Headscale-ui，这是一个管理Headscale服务器的Web UI界面，可以免去敲命令管理Headscale组网的烦恼。一般来说需要为Headscale配置API Key，这点我们后面说。

技术细节

这篇文章采用的小技术细节：

Headscale运行在Docker上，方便管理；
Nginx实现反向代理；
提供Web UI管理Headscale服务器；
使用一个子域名如myvlan.example.com作为访问入口；
在已托管有好几个网站的服务器上搭设，因此如TLS证书、Nginx配置等都与现有其他网站兼容。

配置Headscale服务器

准备工作

显然，在开始配置自己的Headscale中央服务器之前，我们需要：

一台具备公网IP的服务器（至少对你来说，这个IP地址应当确保在你的应用场景下，总是可达的）
一个可用的域名（没有也能组网，但域名能省去非常多麻烦。同时，也假设已经为该域名配置好了HTTPS与证书）
Docker（直接在本机系统上设置也行，具体可以参考安装文档）
Nginx（如果你的服务器同时还运行着其他网站，需要充当反向代理的角色）

接下来让我们开始吧！

准备配置文件

首先我们需要前往Headscale的Github仓库，复制一份配置文件样板config-example.yaml。

按需要修改配置文件，可以参考下面我的示例，一些无关紧要的项目注释已被删除，有需要可以参考上述完整的样板文件。

---
# Headscale服务器暴露在公网上的地址
# 该地址可被用于客户端与服务器的通信
server_url: https://myvlan.example.com

# Headscale服务器监听的端口
# 使用Docker可以直接写0.0.0.0:8080
# 若直接在本机系统上运行且8080端口被占用，可调整为其他空闲端口
listen_addr: 0.0.0.0:8080

# Headscale /metrics Web API
# 可用于获取Headscale运行状态
# 根据自身需求选择是否暴露该API
metrics_listen_addr: 127.0.0.1:9090

# Headscale gRPC 端口，用于CLI工具远程控制服务器
# 该功能需要配合证书使用
# 根据自身需求选择是否暴露该端口
grpc_listen_addr: 127.0.0.1:50443
grpc_allow_insecure: false

noise:
  private_key_path: /var/lib/headscale/noise_private.key

# 设置Headscale分配的虚拟内网IP地址段
# 根据设计，Headscale要求内网IP段 **必须** 在以下子网范围内：
#   - IPv4: 100.64.0.0/10
#   - IPv6: fd7a:115c:a1e0::/48
# 请注意，这一功能与CGNAT冲突，见：https://tailscale.com/kb/1015/100.x-addresses
# 因此不能在如阿里云等启用了CGNAT的云服务器上安装 **Headscale客户端**
# 也就是不能将云服务器作为一台客户机加入VLAN。
prefixes:
  v4: 100.98.76.0/24
  v6: fd7a:115c:a1e0::/48

  # IP分配策略，有`sequential`和`random`两种可选
  allocation: sequential

## DERP配置
#
# 配置Headscale向客户机所分发的DERP服务器列表
# 这些DERP服务器可由3种不同方式定义配置
# 三种方法建议启用至少一种，以实现Relay模式下的访问
derp:
  # 方法1：Headscale内置DERP服务器
  server:
    # 主开关，指定是否启用Headscale服务器内置的DERP服务器
    # 启用后，可以将这台服务器主机作为转发中继流量的节点之一
    # 由于DERP服务器强制要求TLS，因此如果启用这一选项，`server_url`必须以`https`开头
    enabled: true

    # 内置DERP服务器的Region ID
    # 可以随便写，但要注意检查与其他DERP的Region ID冲突
    # 如果冲突，内置DERP的Region ID会覆盖外部导入DERP
    region_id: 999

    # 随便写
    region_code: "myoffice"
    region_name: "DERP in My Office"

    # 用于DERP服务器STUN连接的端口，可以自定义
    # 需要前往云服务器防火墙设置中放行对应端口的UDP连接
    # 注意，这一端口不需要Nginx反代
    stun_listen_addr: "0.0.0.0:10086"

    private_key_path: /var/lib/headscale/derp_server_private.key
    automatically_add_embedded_derp_region: true

    # 填写云服务器的IP地址
    ipv4: 1.2.3.4
    ipv6: 2001:db8::1

  # 方法2：可订阅的JSON格式响应API，获取一系列DERP服务器列表
  # 在示例配置文件中，默认包含了一条从Tailscale服务器上拉取DERPMAP的URL
  # 如果想完全禁用Tailscale提供的服务器，请直接将这一段改成：`urls: []`
  urls:
    - https://controlplane.tailscale.com/derpmap/default

  # 方法3：本地DERP YAML文件定义
  # 指定所使用的DERP定义YAML文件绝对路径
  # 示例：
  # paths:
  #   - /etc/headscale/myderp.yaml
  paths: []

  auto_update_enabled: true
  update_frequency: 24h

disable_check_updates: true
ephemeral_node_inactivity_timeout: 30m

database:
  type: sqlite
  debug: false
  gorm:
    prepare_stmt: true
    parameterized_queries: true
    skip_err_record_not_found: true
    slow_threshold: 1000
  sqlite:
    path: /var/lib/headscale/db.sqlite
    write_ahead_log: true
    wal_autocheckpoint: 1000

## TLS配置
#
# 因为我的服务器上已配置好HTTPS，且我希望由Nginx反向代理管理HTTPS连接
# 因此本配置文件将这部分内容置空，令Headscale服务器跳过自动配置TLS
# 如果有需要，请参考官方提供的完整示例文件
acme_url: https://acme-v02.api.letsencrypt.org/directory
acme_email: ""
tls_letsencrypt_hostname: ""
tls_letsencrypt_cache_dir: /var/lib/headscale/cache
tls_letsencrypt_challenge_type: HTTP-01
tls_letsencrypt_listen: ":http"
tls_cert_path: ""
tls_key_path: ""

log:
  format: text
  level: info

policy:
  mode: file
  path: ""

## DNS配置
#
# Headscale可支持Talescale的DNS配置以及MagicDNS，具体可参考文档：
# - https://tailscale.com/kb/1054/dns/
# - https://tailscale.com/kb/1081/magicdns/
# - https://tailscale.com/blog/2021-09-private-dns-with-magicdns/
# - https://tailscale.com/kb/1235/resolv-conf
# 如果不希望Headscale/Tailscale管理DNS，请将以下所有子项目值置空
dns:
  # MagicDNS主开关
  # 我个人挺喜欢的一项功能，可以自动为每台加入虚拟局域网的主机分配一个DNS记录
  # 如果不需要，或在复杂网络配置下担心扰乱现有网络配置，请关闭这一选项
  magic_dns: true

  # MagicDNS基础域名（二级虚拟域名），附加在主机名后作为DNS记录
  # 这一名称不可以和`server_url`使用的域名相同
  # 建议可以使用如`.lan`等目前IANA没有分配的顶级域名，不干扰其他正常域名解析
  #
  # 例如，若`base_domain`取值为`my.lan`，
  # 则可以用`myroom.my.lan`指代并访问网络中名为`myroom`的主机
  base_domain: my.lan

  # 向客户端暴露的DNS列表，要求客户端使用这些DNS进行解析
  # 这一选项在公司等网络中非常有用
  nameservers:
    global:
      - 114.114.114.114
      - 223.5.5.5
      - 8.8.8.8
      - 2400:3200::1
      - 2001:4860:4860::8888

    # Split DNS (参见：https://tailscale.com/kb/1054/dns/),
    split:
      {}
      # foo.bar.com:
      #   - 1.1.1.1
      # darp.headscale.net:
      #   - 1.1.1.1
      #   - 8.8.8.8

  search_domains: []

  # 设置Headscale服务器上额外的DNS记录
  # 目前只支持A和AAAA记录
  # 参见：docs/ref/dns.md
  extra_records: []
  #   - name: "git.myroom.my.lan"
  #     type: "A"
  #     value: "100.98.76.2"
  #
  #   # 也可以写在一行里
  #   - { name: "git.myroom.my.lan", type: "A", value: "100.98.76.2" }
  #
  # 也可以从一个外部JSON文件导入，该文件每次被更改时会被自动解析加载
  # extra_records_path: /var/lib/headscale/extra-records.json

# Unix socket可以让CLI不需要认证就能连接到服务器控制程序，直接抄就行
unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"

logtail:
  enabled: false

randomize_client_port: false

写好以后，保存，文件名为config.yaml。

准备Docker

在上一节中准备好的config.yaml文件，我们将其放入一个文件夹，假设叫做hs-etc。

现在我们需要准备Docker需要的docker-compose.yml文件，可以将其与hs-etc文件夹放到一块，例如以下文件结构：

hs-server/
├── docker-compose.yml
└── hs-etc
    └── config.yaml

2 directories, 2 files

编辑docker-compose.yml文件如下。

services:
  headscale:
    image: headscale/headscale
    restart: unless-stopped
    container_name: headscale
    ports:
      # Headscale服务器主端口，如果不打算使用反向代理可以去掉前面的`127.0.0.1`
      - "127.0.0.1:10080:8080"
      # /metrics API端口，根据需要开放（在前面Headscale配置里需要开放外部监听）
      # - "127.0.0.1:10089:9090"
      # DERP STUN，如果启用了内置DERP服务器，请在这里映射对应端口
      # 再次提醒，DERP STUN端口不需要经过Nginx反代
      # - 10086:10086
      # - 10086:10086/udp
    volumes:
      # 配置文件文件夹
      - ./hs-etc/:/etc/headscale
      # 用一个卷volume存放Headscale的数据库等
      - hs-data:/var/lib/headscale
      # 将本机系统时间与时区等映射到容器内
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    command: serve

volumes:
  hs-data:

完成后，保存。

启动容器

Docker，启动！

`1`	`docker compose up -d`

可以curl访问一下刚刚映射的主端口，检查Headscale是否正常启动。Headscale对于根节点/请求将返回404，所以记得用-D -输出响应头检查确认。

user@MyServer:~$ curl -D - http://127.0.0.1:10080
HTTP/1.1 404 Not Found
Date: Sun, 11 Jan 2025 12:24:22 GMT
Content-Length: 0

开放防火墙（可选）

如果配置了DERP服务器，请务必记得在系统防火墙与云服务商控制面板中放行对应端口，例如上面示例配置文件中的10086端口的UDP通信。

配置Nginx反向代理

不过，到目前为止，我们搭建的Headscale中央服务器还没有映射到我们的子域名，如myvlan.example.com上。

而且，还记得我们前面提到，最好为服务器启用TLS加密吗？在这一套实现中，这相关的工作也要交给Nginx完成。

这里放上Nginx的示例配置文件，按需修改其中使用的子域名、SSL证书路径、反向代理Headscale服务器地址等参数后，就可以和其他Nginx配置一起使用了。

map $http_upgrade $connection_upgrade {
    default      upgrade;
    ''           close;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name myvlan.example.com;

    index index.html index.htm;

    ssl_certificate /path/to/your/cert/fullchain.pem; 
    ssl_certificate_key /path/to/your/cert/privkey.pem; 
    
    ssl_dhparam /path/to/your/dhparam.pem;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        # 这里填写Headscale中央服务器的本地监听端口
        proxy_pass http://127.0.0.1:10080;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $server_name;
        proxy_redirect http:// https://;
        proxy_buffering off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
    }
}

server {
    listen 80;
    listen [::]:80;

    server_name myvlan.example.com;

    if ($host = myvlan.example.com) {
        return 301 https://$host$request_uri;
    } 

    return 404;
}

重启Nginx，访问子域名，看是否能响应HTTP请求。

开始组网

添加用户

在Tailscale中，每个组成的虚拟子网，都被称为一个Tailnet。一个Tailnet可以加入多台设备，且在一个Tailnet内，所有设备彼此可见，通过一个局域网IP进行互相访问。而即便是在同一个中央服务器上，隶属于不同Tailnet的设备，彼此之间是不可见的。

而在Headscale中，与 Tailnet 相对应的概念是 User。将不同的设备加入到一个User下，就意味着这些设备隶属于同一个用户，该用户下的所有设备共享一个虚拟子网。

现在，让我们来创建一个用户（子网）吧！在中央服务器上执行命令：

`1`	`docker exec -it headscale headscale users create <username>`

这里请把<username>替换成任意喜欢的名称，执行后即可成功创建。

📝 备注

Users还是Namespaces?
许多关于Headscale的文档还使用headscale namespaces命令管理子网，似乎它的功能和users差不多？

其实，在2023年1月（似乎是v0.19.0）之后的版本中，Headscale将所有namespaces相关的命令和概念都换成了users。

所以，如果使用的是新版的Headscale，请按照users进行使用。

参见以下Issues

Rename Namespace to User #329

Rename [Nn]amespace -> [Uu]ser #1144。

注册设备

常规方法

现在，我们需要将我们想要彼此连接的设备添加到刚刚创建的用户（子网）中。

在设备上安装好Tailscale客户端后，打开终端或命令提示符，执行以下命令。

`1`	`tailscale login --login-server https://myvlan.example.com`

命令行会返回类似如下的信息：

1
2
3

To authenticate, visit:

        https://myvlan.example.com/register/ab-CDE_fghijkl0123456789

可以继续访问上面的链接，网页会告诉我们，需要前往Headscale中央服务器执行一串命令。实际上，这行命令的作用就是让Headscale中央服务器接受我们在客户端上的入网请求。

我们也可以注意到，在刚刚给出的链接中最后一部分，例如上面链接的ab-CDE_fghijkl0123456789，其实就是认证用的密钥。

让我们回到中央服务器，执行命令：

`1`	`docker exec -it headscale headscale nodes register -u <username> -k mkey:<yourkey>`

请将<username>替换成用户名（子网名），<yourkey>替换成在上面链接中获得的密钥，例如ab-CDE_fghijkl0123456789。

预认证密钥（另一种方法）

当然，还有另一种入网方法。

我们可以先在服务端上为设备预先创建好一个密钥，然后让客户端设备拿着密钥进行认证，这样就不需要从客户端上想办法获得确认口令，再去服务器上批准入网了。

在中央服务器上执行：

`1`	`docker exec headscale headscale preauthkeys create -u <username> -e 2h`

这里，-u <username>仍然是用户名，而-e 2h表示这条预认证密钥将在2小时后失效。因此在创建这条密钥之后，需要在2小时内到客户端上使用并完成认证。

没有意外的话，服务器会返回类似以下内容：

1
2

2025-01-11T12:00:00+08:00 TRC expiration has been set expiration=7200000
abcdefghijklmnopqrstuvwxyz0123456789012345678901

第二行就是生成的预认证密钥啦！让我们来到客户端，修改一下刚刚的入网命令：

`1`	`tailscale login --login-server https://myvlan.example.com --auth-key <yourkey>`

把<yourkey>替换成上面的预认证密钥，执行命令，就可以成功入网，不需要再次回到中央服务器批准请求啦。

开心使用

组网之后，最基本的使用当然是利用分配的虚拟子网IP互相访问。不过如果仅限于此，似乎又差点意思。

MagicDNS

事实上这是我最喜欢的Tailscale/Headscale功能之一。

在使用Zerotier时，在设备间使用域名进行访问相当困难，似乎唯一可行的方法是在子网内搭建私有DNS服务器，手动维护DNS记录。而mDNS这类基于广播的方案在Zerotier上支持也并不好。

但是，在Headscale上，一切就变得简单起来了！

回到先前的Headscale配置文件，如果我们定义了类似于以下内容：

1
2
3

dns:
  magic_dns: true
  base_domain: my.lan

假设在我们的房间里有一台设备的Hostname为myroom的主机，那么我们就可以用myroom.my.lan这个域名访问这台主机。在这个过程中，我们甚至不太需要和设备的虚拟子网IP地址打交道。

MagicDNS与多级域名

人总是贪心的，当MagicDNS提供了一个域名指向一台机器，就一定会有人希望能设置多个DNS记录指向同一台机器，从而根据不同域名分别访问不同的Web服务，类似于公网上的subdomain.example.com。

设想一下，假设myroom主机上同时运行了一个Gitlab实例和一个PhotoPrism实例。我们很自然地希望，在myroom主机的80或443端口上设置一个Nginx服务器，分别监听前往git.myroom.my.lan和pic.myroom.my.lan域名的请求，再分别反向代理到对应服务端口上。这样可以免去记忆服务端口号的烦恼。

感谢MagicDNS，和在公网上类似，我们可以在Headscale内网中设置多条A或AAAA记录，指向不同的IP。

我们找到Headscale服务器配置中以下部分（在本文前面的配置文件示例中，注释已经写得很详细了）：

1
2

dns:
  extra_records: []

根据目标地址的域名、IP分别修改一下：

dns:
  extra_records:
    - name: "git.myroom.my.lan"
      type: "A"
      value: "100.98.76.2"

保存配置文件，重启Docker，现在就可以在客户端上通过git.myroom.my.lan域名访问地址为100.98.76.2的主机了。

不过这种方案并不优雅，每次增删改DNS记录后都要重启Headscale实例。还好，我们可以进一步引入一个外置的DNS记录配置JSON文件避免这种尴尬。

创建一个dns-records.json文件，用于和config.yaml一同挂载到Docker容器内。

hs-server/
├── docker-compose.yml
└── hs-etc
    ├── config.yaml
    └── dns-records.json

2 directories, 3 files

在dns-records.json中填入类似以下内容：

[
  {
    "name": "git.myroom.my.lan",
    "type": "A",
    "value": "100.98.76.2"
  }
]

再修改一下config.yaml：

1
2

dns:
  extra_records_path: /etc/headscale/dns-records.json

重启Headscale。在此之后，Headscale会在每次检测到dns-records.json发生改动时，自动读取该文件并更新DNS记录。

⚠️ 警告

DNS记录JSON文件格式问题
在headscale/docs/ref/dns.md中有这样一段话：

Be sure to “sort keys” and produce a stable output in case you generate the JSON file with a script. Headscale uses a checksum to detect changes to the file and a stable output avoids unnecessary processing.

似乎是说，在写入文件时，需要尽可能保持输出格式的稳定，也就是保证一个字典内包括"name", “type”, “value"在内的keys顺序保持一致稳定。

子网路由 (Subnet Router)

考虑以下场景，假设我们有3台电脑：

MyLaptop (IP: 公共网络): 随我们走天下的笔记本电脑，安装了Tailscale客户端
MyServer (IP: 192.168.100.101): 放在房间里的常开服务器主机，也安装了Tailscale客户端
MyDev (IP: 192.168.100.102): 放在家里的奇怪开发板，和MyServer在同一个网络，但无法安装Tailscale

现在，假设我们出门在外，需要通过网络访问MyDev设备的资源。我们应该怎么做呢？

如果不想深入配置，那么最简单的办法自然是，首先通过Tailscale内网用SSH访问MyServer，再操作MyServer在物理内网中访问MyDev。

然而，这种方法自然是不够优雅的。

让我们看看Tailscale的解决方案：子网路由 Subnet Router

在Headscale文档中，对应Routes这一章节。

原理

在上述案例中，倘若我们出门在外，连接的公共网络自然无法访问MyServer和MyDev所在的内网192.168.100.0/24网段。

但既然我们可以通过Tailscale内网访问到MyServer，为什么不能让MyServer充当192.168.100.0/24的转发器，让MyServer转发访问该网段的请求呢？

因此，子网路由正是针对上述场景中，我们需要访问的目标机器因种种限制无法安装Tailscale，但Tailscale内网中又存在另一台机器可访问到目标机器的情况。

转发客户端设置

还是用上面的例子，现在我们需要将MyServer设置为转发器。

那么首先，如果MyServer是Linux系统，我们需要启用操作系统的转发功能：

1
2

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf

还是在MyServer上，需要告诉Tailscale客户端，向网络广播前往192.168.100.0/24网段的路由：

`1`	`sudo tailscale set --advertise-routes=192.168.100.0/24`

到此为止，客户端的设置基本上就完成了。

Headscale服务器授权

出于安全考虑，显然不能允许任意一台客户端都随意声称自己拥有某某网段，然后控制该网段的路由权。

因此，在客户端中设置广播路由后，我们还需要登录到Headscale服务器，首先运行以下命令：

`1`	`docker exec headscale headscale nodes list-routes`

会获得类似以下输出：

1
2

ID | Hostname | Approved | Available        | Serving (Primary)
6  | MyServer |          | 192.168.100.0/24 |

可以看到，192.168.100.0/24网段已经出现在Available列中，但还没有获得批准。

现在，我们需要批准MyServer转发192.168.100.0/24网段：

`1`	`docker exec headscale headscale nodes approve-routes --identifier 6 --routes 192.168.100.0/24`

其中，--identifier就是前面的ID。

命令完成后，再次执行headscale nodes list-routes，应该输出如下：

1
2

ID | Hostname | Approved         | Available        | Serving (Primary)
6  | MyServer | 192.168.100.0/24 | 192.168.100.0/24 | 192.168.100.0/24

Linux客户端设置

到此为止，如果MyLaptop是Windows系统，那么已经可以试着直接访问192.168.100.0/24网段下的MyDev设备啦。

但如果MyLaptop是Linux系统，还需要执行最后一步操作：

`1`	`sudo tailscale set --accept-routes`

一切应该都OK啦！

（附赠）自签名HTTPS证书

搭建起Headscale后，一种常见用途就是访问内网其他设备的Web服务。在Tailscale/Headscale内网中，所有数据包都是加密后发送的，理论上讲其实并不会因为使用HTTP直接访问造成安全问题。

但是，一部分Web应用要求必须使用安全连接，因此通常又有使用HTTPS的需求。

然而，显然，没有任何第三方CA会给我们的内网域名颁发TLS证书。考虑到内网中的设备其实都是我们自己使用的，此时，自签名证书就成了最方便灵活的选择。

一般的自签名证书只对应于一组域名，在有多个设备多个域名的场景下，相比起重复颁发并在客户端上信任多个证书，或是顶着浏览器的不安全警告继续访问，或许我们其实可以采用类似于第三方CA的做法。

具体来说，我们的思路是：

先签发一个根证书(Root CA Certificate)，此时我们就扮演了Root CA的角色。
使用根证书，为需要信任的域名（比方说myroom.my.lan）颁发一个新的证书（本文称为子证书）。
子证书安装到提供该Web服务的服务器上，并配置使用如Nginx等提供HTTPS服务。
在客户端（也就是访问Web服务的终端）上安装根证书，此时客户端将信任所有基于该根证书签发的子证书。
由此，可以在客户端上愉快地内网HTTPS服务。
在未来需要为新的域名颁发证书（例如another.my.lan）时，只需要执行2~3步骤，不再需要在客户端上安装新证书，因为根证书已经被信任了。

接下来是具体步骤，这些步骤需要使用OpenSSL执行。除特别说明外，这些证书与密钥的存储位置与文件名都是比较随意的，只需要考虑合适的文件权限与维护的便利即可。

签发Root CA根证书

我们首先需要做好扮演Root CA的任务，有了根证书以后才能基于该证书签发新的证书。

第一步，生成Root CA的私钥rootca.key。该文件需要妥善保管，不能外泄。（其实泄了也没啥，反正是跑在虚拟内网上的。）

下面命令中末尾的4096是RSA密钥长度。都2025年了，别再用2048位的RSA了。

`1`	`openssl genrsa -out rootca.key 4096`

📝 备注

证书加密签名算法的问题
一定有小伙伴想，RSA都是多久以前的加密算法了，要不我们换一点新玩意，比方说ECDSA，EdDSA之类的（其实这些算法地位上似乎并不能并列）。

事实上，ECDSA已经开始用于一些网站中。但是EdDSA几乎没有得到支持。而且，EdDSA的证书在Windows 10中无法被正确识别。

考虑到ECDSA是NSA弄出来的玩意，要不，我们还是用更长的RSA吧。

第二步，准备一个Root CA证书生成配置文件rootca.conf。该文件主要是提供证书中包含的信息，如别名等。

在这个配置文件中，[req_distinguished_name]段的内容可以随意更改。自签名证书嘛，随便填，好玩就行。

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
prompt = no

[req_distinguished_name]
# Country/Region
C = CN
# State/Province
ST = Somewhere
# Location/City
L = OnTheCloud
# Organization
O = Togawa Group
# Common Name
CN = Togawa Group ROOT CA v1

[v3_ca]
basicConstraints = critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
keyUsage = critical,digitalSignature,keyCertSign,cRLSign

第三步，使用上面的私钥和配置文件，接下来我们就可以生成Root CA的根证书文件rootca.crt了。

这个根证书文件rootca.crt，就是接下来可安装到各客户端上的证书。

`1`	`openssl req -x509 -new -key rootca.key -days 3650 -sha512 -config rootca.conf -out rootca.crt`

顺带一提，如果不希望使用配置文件rootca.conf控制证书信息，也可以去掉-config rootca.conf这一参数。OpenSSL会启动一个问答，根据提示填写即可。

签发子证书

假设我们希望给myroom.my.lan这台服务器签发一个通配符证书。该证书既信任myroom.my.lan域名，也同时信任*.myroom.my.lan这一泛域名，日后我们使用pic.myroom.my.lan这样的域名访问该服务器时，就不再需要签发新证书了。

首先，我们需要为新的子证书生成一个私钥myroom.key。原则上讲，该私钥不需要透露给Root CA。不过现在只有我们一个人，这些都无所谓啦。

`1`	`openssl genrsa -out myroom.key 4096`

第二步，编写子证书的证书请求配置文件myroom.conf。和前面一样，[req_distinguished_name]块的内容可以随意配置，但CN也就是Common Name部分需要填写为证书对应的域名。

同时，如果希望该证书同时信任其他域名，只需要在[alt_names]块部分按格式继续添加即可。注意，myserver.lan和*.myserver.lan是不同的域名，需要分别列出！

[req]
distinguished_name = req_distinguished_name
prompt = no

[req_distinguished_name]
C = CN
ST = Tokyo
L = Tokyo
O = Anon Tokyo
CN = myroom.my.lan

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
authorityKeyIdentifier = keyid:always,issuer:always
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myroom.my.lan
DNS.2 = *.myroom.my.lan

第三步，接下来需要生成子证书的证书请求(Certificate Request)文件myroom.csr。在Root CA和子证书请求分离的场景下，证书请求是可以发送给Root CA以申请证书的。

`1`	`openssl req -new -key myroom.key -config myroom.conf -out myroom.csr`

第四步，Root CA收到了证书请求myroom.csr后，利用Root CA自己的私钥，以及根证书和配置文件，最终生成子证书myroom.crt。

1
2

openssl x509 -req -in myroom.csr -CA rootca.crt -CAkey rootca.key
-CAcreateserial -days 730 -sha512 -extfile myroom.conf -extensions v3_req -out myroom.crt

到此为止，所有需要的证书、密钥文件都已经生成。只需要按需部署即可。

Nginx绑定证书

使用Nginx提供HTTPS时，需要使用上面子证书签发中获得的myroom.crt证书文件与myroom.key密钥文件。Nginx配置的重点在于以下两句，后缀名是不重要的。

1
2

ssl_certificate /path/to/self-signed/myroom.crt;
ssl_certificate_key /path/to/self-signed/myroom.key;

将根证书安装到Windows

找到刚生成的Root CA根证书rootca.crt
双击打开后点击安装证书（在资源管理器右键“安装证书”也行）
存储位置选择当前用户
接下来选将所有的证书都放入下列存储，点击右侧浏览，选择受信任的根证书颁发机构
之后一路确定即可。

将根证书安装到Linux

找到刚生成的Root CA根证书rootca.crt
将其复制到/usr/local/share/ca-certificates/目录下。需要注意，文件名随意但后缀名必须为.crt。以上命令生成的.crt证书格式就是可以被正常识读的，不需要再做转换。
执行sudo update-ca-certificates更新系统证书缓存。如果报错发现刚刚添加的证书被跳过了，可以试着加--fresh参数执行。

顺带一提，Linux的Firefox浏览器不依赖系统的证书库，而是使用自建的证书库。因此在Linux上使用Firefox时，需要手动前往设置，在隐私与安全部分，将根证书导入到Authorities列表中。

Docker镜像本地拉取与迁移

Sat, 29 Jun 2024 12:00:00 +0800

由于网络连通性原因，DockerHub的访问变得困难。然而在服务器上部署服务时，又经常需要使用Docker。

为了避免在服务器上进行复杂的网络设置，一种相对折中的方法是：在一台网络流畅（下面称为本机）的机器上获取Docker镜像，再将镜像复制到服务器上使用。

工具 - Skopeo

一种传统的方法是，在本机上也安装一个Docker Engine，使用docker pull命令拉取镜像，再使用docker save导出镜像。

这种方法的缺点在于，我们在本机上或许并不需要/不想要/难以安装Docker引擎。

而维新派指出，在Docker引擎官方代码仓库moby/moby/contrib下，有一个download-frozen-image-v2.sh脚本，该脚本提供了对Docker镜像的下载功能。听起来不错？

而当然，也有更便捷的工具：containers/skopeo。这也是本文介绍的主角。

安装Skopeo

安装skopeo相当简单，例如在Debian 11+/Ubuntu 20.10+内，可以直接在apt源中下载安装。Alpine Linux同样可以使用apk直接添加。

尽管skopeo不支持Windows版本，但完全可以创建一个简易的Alpine Linux WSL环境完成以上任务。

使用Skopeo获取镜像

主要使用的是skopeo copy命令，文档参见skopeo/docs/skopeo-copy.1.md。

具体来说，在拷贝时，我们常常希望把镜像打成一个tar包，可以方便地在网络上传输。skopeo可以直接导出tar文件，具体如下：

`1`	`skopeo copy docker://<image>:<tag> docker-archive:/path/to/archive.tar:<image>:<tag>`

例如，如果想要拉取busybox的最新版本镜像busybox:latest，可以执行：

`1`	`skopeo copy docker://busybox:latest docker-archive:myarchive.tar:busybox:latest`

如果镜像是由非Docker官方发布的，镜像名称中会含有斜杠，请放心，此时镜像名称<image>就是包含斜杠的完整字符串。例如，以下命令当然是没问题的。

`1`	`skopeo copy docker://bitnami/postgresql:14 docker-archive:/path/to/archive.tar:bitnami/postgresql:14`

值得注意的是，在上述命令里，附加在打包文件名后的<image>:<tag>，即为之后导入docker时，该镜像所关联到的名称。

例如，如果执行：

`1`	`skopeo copy docker://busybox:latest docker-archive:myarchive.tar:busybox:10086`

导入到docker中的镜像名称也会被显示为busybox:10086：

1
2
3

user@server:~$ docker images                                                                                                                 
REPOSITORY    TAG          IMAGE ID       CREATED         SIZE                                                                         
busybox       10086        1234567890ab   1 months ago   1.23MB

打包后，为了节约传输带宽和时间，可以对打包好的tar文件压缩一下。可以使用zstd（gz等当然也行），大约能缩小2/3的体积。

`1`	`zstd -9 myarchive.tar`

在服务器上导入镜像

使用喜欢的方法将打包文件传输到服务器后，就可以导入Docker引擎：

`1`	`docker load < myarchive.tar.zstd`

这里使用的是重定向输入文件流，当然也可以使用-i参数引导读取指定路径的文件。同时，docker load也可以加载包括gz, xz, bzip2, zstd在内的压缩文件。

与同名同tag现有镜像的冲突

导入时会覆盖掉同名镜像，即原有镜像的名称会被置空，变成孤立的镜像。运行docker images prune可以删除这些孤立镜像。

利用Dockerfile将ASP.NET Core Web应用部署到Docker容器

Fri, 06 May 2022 15:21:23 +0800

前言

想必各位对ASP.NET Core容器化部署，特别是微软非常喜欢强调的 微服务(Micro-Service) 概念有一定的兴趣。

这一过程需要使用到ASP.NET Core, Docker, Nginx三个组件，要让它们相互良好地配合起来，还是需要精心编写一下配置文件的。

然而，当真的开始着手实操的时候，假如阅读微软文档给出的一些文章或者链接，例如:

或许对于幼儿园的小朋友来说，这些文章可能显得比较幼稚。但对我这种饭来张口衣来伸手的大学生来说，这些文章只能说刚刚好。把文章拼起来就是需要的答案，可惜在尝试的过程中会显得有些不适。所以不妨总结一下，如何将一个ASP.NET Core Web应用部署到Docker中，然后用Nginx做反向代理进行访问。

准备

已经开发好的ASP.NET Core Web应用程序(Razor Pages, Blazor, MVC, Web API啥的，都可以)
Docker
Nginx

这里，我们会使用最新的.NET 6.0进行部署。

ASP.NET Core代码的适配

在本教程中，我们由于需要使用Nginx配置反向代理，这需要我们对ASP.NET Core应用进行响应的修改。

关闭HTTPS重定向

ASP.NET Core项目默认会重定向所有HTTP请求到HTTPS，但在反向代理的场景下，HTTPS不是容器中的ASP.NET Core程序该操心的事情。我们应该在Nginx这样的Web服务器部分完成HTTPS相关的配置，包括HTTP重定向HTTPS。

打开Program.cs，找到如下代码:

`1`	`app.UseHttpsRedirection();`

将app.UseHttpsRedirection()一句删除或注释掉，关闭HTTPS重定向。

设置反向代理使用的响应标头

为了能正确跟踪请求的来源，处理重定向、认证等关键的事件，我们还需要配置转发响应标头。

同样是在Program.cs中，我们在其他中间件之前，加入UseForwardedHeaders代码段:

......
var app = builder.Build();

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

if (app.Environment.IsDevelopment())
......

关于中间件先后顺序的讨论，可以参考ASP.NET Core Middleware | Microsoft Docs.

配置步骤

第1步-创建文件夹

创建一个新文件夹，用来存放构建镜像所需的文件，包括Dockerfile等。我们假设这个新文件夹名为myapp。

第2步-发布ASP.NET Core应用

这一步我们要将编写的ASP.NET Core应用发布，生成生产环境下的二进制代码。

打开终端，切换到项目根目录，运行:

`1`	`dotnet publish -c Release -o publish --no-restore`

其中-o publish的意思是将发布的二进制代码放入名为publish的文件夹中。发布完成后，进入该文件夹，可以找到与当前项目同名的一个.dll文件，这就是你的项目编译生成的二进制代码。我们这里假设该文件名为MyWebApp.dll。

发布完成后，将publish文件夹复制到myapp文件夹中。

第3步-编写Dockerfile

在myapp文件夹中，新建一个Dockerfile文件，编写内容:

FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY publish statics ./
ENTRYPOINT ["dotnet", "MyWebApp.dll"]

依次解释上述语句含义:

FROM mcr.microsoft.com/dotnet/aspnet:6.0指定了基础的镜像文件，我们选用的是微软发布的最新ASP.NET Core Runtime镜像，不包含SDK。
WORKDIR /app指定接下来容器中的操作，基础目录是/app。
COPY publish statics ./会将 本机publish文件夹下的所有文件 复制到 容器当前目录下。
ENTRYPOINT ["dotnet", "MyWebApp.dll"]放在最后，容器将执行这一命令，即通过dotnet命令运行上一行语句中复制到/app目录下的MyWebApp.dll文件。这将会保持该Web程序一直运行，直到被要求退出。

第4步-构建并运行Docker镜像

在myapp文件夹中，运行命令:

`1`	`docker build -t mywebapp .`

-t mywebapp指定了生成镜像的标签(tag)为mywebapp，当然你也可以写成mywebapp:0.1.2这样的形式来指定一个版本号。

运行命令，Docker会拉取最新的ASP.NET Core Runtime镜像，然后执行我们在Dockerfile中指定的操作，构建成一个新的镜像，放在系统中。

接下来我们就可以启动我们的应用了。执行命令:

`1`	`docker run -d -p 12345:80 --name mywebapp-123 mywebapp`

参数的解释:

-d表示容器在后台运行(daemon)
-p 12345:80表示将主机的12345端口映射到容器的80端口上，即可以通过主机的12345端口直接访问容器内ASP.NET Core应用。由于我们需要设置反向代理，出于安全考虑，我们可以设置只映射来自本机的访问，即写成-p 127.0.0.1:12345:80这样的形式，此时即便没有防火墙，外界直接访问12345端口也无法访问到我们的ASP.NET Core应用程序。
--name mywebapp-123，给你的容器起一个名字。
mywebapp，选择运行容器使用的镜像Tag。（和上面容器名字可以相同，也可以不同，但这个名字来源于上面构建Docker镜像中指定的Tag，如果设置了版本号，还应当指明版本号。）

如果没有意外情况，执行上述命令后，我们的应用就运行在机器上了。可以通过docker ps查看正在运行的容器，看我们刚刚建立的容器是否正常运行。

第5步-设置反向代理

在现代的网站中，我们不是很喜欢通过端口号访问网站，更多情况下，我们需要借助如Nginx等Web服务器的反向代理等功能，完成更复杂的工作。因此，我们现在看看怎么使用Nginx为我们的应用设置反向代理。

⚠️ 警告

再次确认

执行本步骤前，请确保容器中运行的程序已经按照 ASP.NET Core代码的适配部分修改并生成。

这里，我们使用Debian/Ubuntu系Linux发行版的配置文件目录习惯，如果使用的是Fedora/RedHat系发行版，需要自行确定下Nginx配置文件的目录，并创建对应的文件。

我们在/etc/nginx/sites-available/下创建一个新的站点配置文件，可以起名为myapp.conf。编写如下内容:

server {
    listen 80;
    listen [::]:80;

    server_name myapp.example.com;

    location / {
        proxy_pass         http://127.0.0.1:12345;
        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;
    }
}

其他部分大同小异，我们主要需要注意的是以下几点。

如果你的服务器上还运行了其他域名的应用，请确认server_name后正确指定了需要转发给ASP.NET Core应用程序的域名，本例中为myapp.example.com
proxy_pass后需要正确指定第4步-构建并运行docker镜像中映射到容器80端口的本机端口号。

(可选)第6步-设置HTTPS重定向

现在绝大部分网站都已经使用了HTTPS，我们为了安全理应同样使用HTTPS。当然，这里我们不讨论如何获得HTTPS证书，我们稍微提一提怎么做重定向。

将第五步中的Nginx配置文件修改为:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name myapp.example.com;

    ssl_certificate /etc/ssl/certs/myapp.crt; 
    ssl_certificate_key /etc/ssl/private/myapp.key; 
    ssl_dhparam /etc/ssl/certs/myapp.pem;

    ssl_protocols TLSv1.2 TLSv1.3; 
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_ecdh_curve secp384r1;
    ssl_prefer_server_ciphers on;
    
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass         http://127.0.0.1:12345;
        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;
    }
}

server {
    listen 80;
    listen [::]:80;

    server_name myapp.example.com;

    root /var/www/html;

    if ($host = myapp.example.com) {
        return 301 https://$host$request_uri;
    } 

    return 404;
}

上述Nginx的TLS配置仅供参考。我们选取了一个相对较为安全的配置。

第7步-启动Nginx并测试访问

执行命令:

`1`	`nginx -s reload`

Nginx将会重新读取配置文件，设置好DNS解析（如果使用了域名的话），就可以通过绑定的域名访问到容器中的ASP.NET Core Web应用了。