![portainer0.jpeg](/static/img/349f557bc840a699617f64e438ee6681.portainer0.webp)

>在将Portainer升级到Community Edition 2.33.5 LTS版本后，遇到了本地环境无法加载、Stack管理失效的问题。尽管容器本身仍在运行，但Portainer界面显示环境为“Down”，且无法通过UI管理现有Stack。尝试了多种方法，包括重建Portainer容器、删除Portainer数据库并重新初始化，但这导致Stack虽然可见，却带有“有限控制”的提示，且无法正常部署。 尝试重新部署Stack时，系统提示同名Stack已存在。最终的解决方案是：发现重新部署的Stack使用了新的项目ID，导致无法关联旧数据。通过删除新Stack的数据，并将旧Stack的数据文件夹复制到新项目ID对应的位置，然后执行docker compose up，成功恢复了所有Stack及其数据，解决了管理难题。



# 1. Portainer容器升级后加载环境失败

事情发生的原因是打开Portainer的管理界面，有提示让我升级到LTS版本。我手欠，就升级到了Community Edition
2.33.5 LTS版本。当我再打开Portainer时，登录界面可以正常登录。本地环境也是显示Up的，但是只要一点本地环境，那个状态就变成Down了。

![portainer1.jpeg](/static/img/47f00c47cc4ce651b521aef9676fccc8.portainer1.webp)

我在服务器上查看容器的状态，倒是没受影响。但是无法进行任何的更改了，因为原来是通过Portainer的UI界面来管理Stack的。而在服务器上，存放Docker-Compose文件的地方和实际存放容器数据的地方并不在一起。

# 2. 重建容器

我尝试重新拉镜像并重新创建容器，可以进入到本地环境的管理界面。虽然显示有stacks，但是只能看见portainer自己的stack，别的stack都没有了。

![portainer4.jpeg](/static/img/fc4c4e0887a20bebc44aa19ae1d5eaaa.portainer4.webp)

但是点开容器选项，发现容器都还在。容器的管理也都是好用的。

![portainer5.jpeg](/static/img/6f50437ef8019763daef672176d32e58.portainer5.webp)

# 3. 重建Stack

我想，既然不显示，那我就再重建一下Stack就好了。首先需要切换到root用户，再进入到`/data/compose`文件夹下。通过在Portainer的Container界面里查看Docker Compose文件的位置找到它。

![portainer6.jpeg](/static/img/bbc8d1c1e8aff252dc537b9f832fbc1d.portainer6.webp)

然后复制内容到Portainer GUI的`Stacks > Add Stack`菜单下，再Deploy。

![portainer7.jpeg](/static/img/1c106eeb0895fc278eebbbef8167a53b.portainer7.webp)

这时又出现了无法部署的情况，说是同名的Stack已经存在了。

# 4. 重建Portainer

后来我实在没有办法了，只能将Portainer自己的本地数据库给删除了。根据你Portainer的Docker Compose文件的不同，实际位置不一定相同。在容器内部是在`/data`文件夹下面。因为Portainer并没有提供Shell，无论是bash还是sh都没有。所以依赖于你映射出来的文件。

我自己的Portainer的Docker Compose文件是这样的。我没有放到Nginx的反向代理后面，因为我不想因为Nginx的原因导致我无法管理到其他的容器。确切地说，我的Nginx也是被Portainer管理的。

```yaml
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: always
    ports:
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./portainer_data:/data
      - /etc/letsencrypt/live/zenseek.site/fullchain.pem:/certs/fullchain.pem
      - /etc/letsencrypt/live/zenseek.site/privkey.pem:/certs/privkey.pem
    command: >
      --sslcert /certs/fullchain.pem
      --sslkey /certs/privkey.pem
```

将Portainer的容器停掉，再将`/data/portainer.db`删除。删除前先备份一份到别的地方。再重新启动容器，因为它自身的数据库没有了，它会当成是新的实例，重建本地的数据库。

![portainer2.jpeg](/static/img/034fce0f0ee7b34b6239feef78138125.portainer2.webp)

这时就和新创建的Portainer实例一样需要设置管理员账号密码。但是进去之后是可以直接看到本地环境的，也可以点进去。

![portainer3.jpeg](/static/img/bae031e9d86e63b542daae6f578db386.portainer3.webp)

当我满心欢喜地进到Stack选项的时候，发现Stack都回来了。但是后面标识了是有限的控制。这种情况只有是在不使用Porainer直接在本地Docker Compose Up起来的stack才会这样。因为它的Docker Compose文件和data是放在不同的地方，且需要root权限。即使我在存放Docker Compose文件的文件夹下Docker Compose Down也是不好用的。在这种情况，我既不能通过Docker CLI也不能通过Portainer来管理Stack。

# 5. 解决方案

中间我问了Gemini，ChatGPT，Clause和Deepseek，也尝试了很多的方法。发现StackOverflow上也有很多人反应同样的问题，但是上面的解决方案对于我并不好用。

这时我想到刚才的报错说是有容器占用了那个stack，我就想能不能把那个容器删除了再部署呢？但是我就怕，删除容器后，数据恢复就没有了。本来使用Portainer是为了方便的，结果出了这种情况，导致无法管理Stack。早知道这样，还不如一个文件夹一个文件夹部署Docker Compose的文件和数据了。

但是在走投无路的情况下，我找了不是那么重要的容器删除了。然后进行重新再Add Stack，我发现可以部署了，而且小叹号也没有了。但是数据呢？全没了，这一个新的部署。

![portainer9.jpeg](/static/img/dabea587866dcaeaae40905c1098067a.portainer9.webp)

在细心的观察下，我发现新的部署使用了不同的项目ID，因此导致无法加载过去的数据。我把Docker Compose Down掉后，将新的项目下的数据都删除，将就项目ID的数据文件夹复制过来。再Docker Compose Up一下，一切就完好如初了。问题就这样解决了。

![portainer10.jpeg](/static/img/99743dac142ededb4e51c6385c760da0.portainer10.webp)

Portainer - 加载环境失败

![wsl0.jpeg](/static/img/854336c96f4580d984f06910b2cda1b7.wsl0.webp)

> 本文详细介绍了当公司电脑连接VPN后，WSL中的Ubuntu实例无法访问外部网络的常见问题及其解决方案。通过修改WSL Ubuntu内部的/etc/wsl.conf文件，成功解决了网络连接和域名解析的难题，确保WSL Ubuntu在VPN环境下也能顺畅地访问外部资源。



当公司电脑连接到VPN后，WSL的Ubuntu就无法访问外部网络。

# 1. 查看WSL版本

```cmd
> wsl --version

WSL version: 2.6.1.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.66
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.6584
```

# 2. 升级WSL

先关闭WSL再升级。

```cmd
> wsl --shutdown
> wsl --upgrade
```

# 3. 创建WSL配置文件

在Windows系统下，创建`C:\Users\USER_NAME\.wslconfig`。内容如下：


```cmd
[wsl2]
networkingMode=mirrored
dnsTunneling=true
```

再重新打开WSL的终端，看可否ping通外部网络。我可以ping通8.8.8.8，但是在`sudo apt update`的时候无法连接到镜像服务器。报错显示的无法解析镜像服务器的域名。

# 4. 查看Windows防火墙

以Admin身份打开Powershell。

```powershell
PS C:\WINDOWS\system32> Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'


Name                  : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
LoopbackEnabled       : True
AllowHostPolicyMerge  : True
```

如果`DefaultOutboundAction`的行为是Block的话就需要设置为Allow。我的是没有问题的。

`Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultOutboundAction Allow`

# 5. 查看WSL内的WSL配置

将最后一项的`generateResolvConf`改成true。

```bash
> cat /etc/wsl.conf

[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=11"

[interop]
enabled = true
appendWindowsPath = true

[network]
generateResolvConf = false
```

关闭WSL并重新打开WSL的终端，网络就通了。

WSL - 解决VPN连接下无法访问网络的问题

# 1. 创建项目

## 1.1 VSCode创建项目

使用VS Code来创建项目。 `Ctrl + Shift + P`打开命令栏，选择`Python Create Environment`，使用`Venv`并确定要使用的Python的版本。

![image.png](/static/img/c37caae0da67d1a6d4bf4f3a07112574.image.webp)

启用Python虚拟环境，查看现在的Python版本，并安装FastAPI。

```cmd
> .\.venv\Scripts\Activate.ps1
> Get-Command python

> python -m pip install --upgrade pip
> pip install "fastapi[standard]"
```

## 1.2 VSCode设置Git

我的Git已经设置全局账号和邮箱里。

```cmd
> git init

# 设置Git账号和邮箱以及仓库地址。
> git config --global user.name "Your Name"
> git config --global user.email "your.email@example.com"
> git remote add origin https://example.repo

# 检查Git的配置
> git config --global --list 
```

# 2. 登录模块

将登录以及下发Token等的功能放到`router/auth.py`，`main.py`再调用它。

安装JWT，`pip install PyJWT[crypto]`。

FastAPI学习

Vue3 - 制作后台管理系统

![authelia000.jpeg](/static/img/637063527ecc91d63c7477ada701fcfc.authelia000.webp)

>本文详细介绍了如何使用 Docker 最小化部署 Authelia，一个开源的身份验证和授权服务器。Authelia 提供双因素认证 (2FA) 和单点登录 (SSO) 功能，作为反向代理的伴侣，为应用程序提供细粒度访问控制。与功能强大的 Keycloak 相比，Authelia 更轻量、资源占用低，非常适合内网环境和用户不多的场景。文章涵盖了 Docker Compose 文件配置、Nginx 反向代理设置、Authelia 核心配置、用户数据库管理以及密钥生成等关键步骤，旨在帮助用户快速搭建一个高效的认证系统。
>


# 1. 介绍

[Authelia](https://www.authelia.com) 是一个开源的身份验证和授权服务器，旨在通过一个网络门户为其应用程序提供双因素认证 (2FA) 和单点登录 (SSO) 功能。主要功能包括：

- **双因素认证 (2FA) 和单点登录 (SSO)**：通过 2FA 确认用户身份，并通过 SSO 简化登录流程，让用户只需登录一次即可访问多个应用程序。
- **反向代理的伴侣**：Authelia 作为反向代理（如 Nginx、Traefik、Caddy、HAProxy 等）的伴侣，可以允许、拒绝或重定向请求，从而保护您的服务。它直接与反向代理连接，而不直接连接到应用程序后端。
- **细粒度访问控制**：允许管理员根据子域名、用户、用户组、请求 URI、请求方法和网络等标准定义访问规则，实现精细的访问控制。
- **密码重置**：提供通过电子邮件确认进行身份验证的密码重置功能。
- **防暴力破解**：在多次无效认证尝试后限制访问，防止暴力破解攻击。
- **轻量高效**：采用 Go 和 React 编写，具有极低的资源占用，容器大小通常小于 20MB，内存使用量低于 30MB，并且授权策略和后端任务在毫秒级完成。

# 2. Docker最小化部署

## 2.1 使用Authelic的初衷

之前在 [零信任时代的身份利器：Keycloak Docker化部署全攻略](https://www.zenseek.site/post/7) 里讲了怎么部署KeyCloak。不过它实在是太重了，虽然它功能强大，对于在内网又没多少用户的情况下属于杀鸡用牛刀。毕竟我既不是搞安全的，也不是Devops，只要能实现对多个APP实现一个统一的验证和单点登录就够了。因此，对CPU和内存友好的Authelia映入我的眼帘。

![authelia001.jpeg](/static/img/c95bc3fd0b1410ae4c0ec40fc5da3f9e.authelia001.webp)

## 2.2 部署条件

老样子，还是在公司内网服务器的环境部署，只有内网IP一枚，不同的APP用不同的端口来网文。首先，第一步还是要把容器跑起来，其次能通过Nginx反向代理访问WEBUI的界面。

- 存储使用了SQLite。
- 用户数据库使用的是本地文件。
- 暂时先没加IDP的功能。
- 通知没有添加SMTP，只是使用了本地文件。

未来会提供IDP的功能，使用OIDC来给自己的项目发Token。这样我的项目就不用自己写登录和鉴权的代码了。独立数据库和Redis暂时还不算上，毕竟就是一个小项目。

## 2.3 文件结构

在Docker Compose文件下有一个Authelia目录，包括了配置文件，用户数据库，私钥和各种加密密钥，数据库文件，通知文件。

```bash
.
├── authelia
│   ├── configuration.yml
│   ├── data
│   │   ├── db.sqlite3
│   │   └── notification.txt
│   ├── keys
│   │   └── oidc_private_key.pem
│   ├── secrets
│   │   ├── jwt_secret
│   │   ├── oidc_hmac_secret
│   │   ├── session_secret
│   │   └── storage_encryption_key
│   └── users_database.yml
└── docker-compose.yml
```

## 2.4 Docker Compos文件

- 将Authelia加入到Nginx反向代理的Docker网络了，不需要直接将端口映射到主机服务器上了。
- 容器默认使用9091端口。
- 将相应的文件映射到容器外部。

```yaml
services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    restart: unless-stopped
    expose:
      - "9091"
    volumes:
      - ./authelia/configuration.yml:/config/configuration.yml
      - ./authelia/users_database.yml:/config/users_database.yml
      - ./authelia/secrets:/config/secrets
      - ./authelia/keys:/config/keys
      - ./authelia/data:/data
    environment:
      - TZ=Asia/Shanghai
    networks:
      - nginx-reverse-proxy

networks:
  nginx-reverse-proxy:
    external: true
```
## 2.5 Nginx配置文件

我没有按照官网的比较复杂的配置去做，先把请求放进来。

```bash
server {
    listen 80;
    server_name SERVER_IP;

    # Redirect all HTTP requests to HTTPS
    return 301 https://$host:$request_uri;
}

server {
    listen 443 ssl;
    server_name SERVER_IP;

    ssl_certificate /etc/nginx/certs/dlc.SERVER_IP.crt;
    ssl_certificate_key /etc/nginx/certs/dlc.SERVER_IP.key;

    # SSL/TLS Security Settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Enable HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://authelia:9091/;
        proxy_set_header Host $host;
        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;
    }
}
```

## 2.6 Authelia配置文件

- 通过session cookie配置应用的重定向等设置。访问AUthelia的web界面成功后跳转到另一个8001应用。
- 用户认证使用本地的yaml文件
- 访问控制，对于Authelia的登陆界面直接放行，对于另一个8012的应用需要账号密码验证。
- 存储使用SQLite。
- 通知使用文件记录。
- 对于重置密码，重置邮件的内容是记录在通知指定的文件里的。

```bash
theme: light

server:
  address: tcp://0.0.0.0:9091

log:
  level: info

session:
  cookies:
    - name: authelia_session
      domain: SERVER_IP
      authelia_url: https://SERVER_IP
      default_redirection_url: https://SERVER_IP:8001
      same_site: lax
  secret: 669ebae753159618538b44f3466e3eecaeccf76a590d01005e67e8858672c1d0
  expiration: 10h
  inactivity: 4h

identity_validation:
  reset_password:
    jwt_secret: cd22924062b229d53b6ec25139080328a6368ce58588c0459c7e89761634bf6f
    jwt_lifespan: 5 minutes
    jwt_algorithm: HS256

authentication_backend:
  file:
    path: /config/users_database.yml
    password:
      algorithm: argon2id

access_control:
  default_policy: deny
  rules:
    - domain_regex: '^SERVER_IP$'
      policy: bypass
    - domain_regex: '^SERVER_IP:8012$'
      policy: one_factor

storage:
  encryption_key: e006be0e2687d620f760c1016e532cd5344798fcbd30da706382d814c5017f09
  local:
    path: /data/db.sqlite3

notifier:
  filesystem:
    filename: /data/notification.txt

```

## 2.7 用户数据库

使用本地Yaml文件。argon2id的密码可以通过下面的命令生成，也就意味着可以先留空，可以在容器跑起来之后再运行这个命令。更新YAML文件后，需要重启容器重新加载用户数据库的内容。

`docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'PASSWORD'`

```yaml
users:
  admin:
    displayname: "Admin"
    password: "$argon2id$v=19$m=65536,t=3,p=4$BzODJr+sliIj25pOvXlNHQ$3GVps1iOE/JezpAmnXLK3mW1L3UU+rXvZHtLIOHGiA0"
    email: admin@example.com
    groups:
      - admins
```

## 2.7 私钥和其他密钥

生成私钥到文件。其他的密钥可以直接放到Authelia的配置文件里。

```bash
# 生成OIDC用的私钥
openssl genrsa -out oidc_private_key.pem 2048

# 生成其他的签名密钥
openssl rand -hex 32 > jwt_secret
openssl rand -hex 32 > session_secret
openssl rand -hex 32 > oidc_hmac_secret
openssl rand -hex 32 > storage_encryption_key
```

## 2.8 WEBUI界面

只有一个登陆界面，账号密码验证成功后，直接挑战到Session Cookie里默认的跳转界面。

![authelia002.jpeg](/static/img/a2fb31a15afcbd8af9ab5b67ed8bc9dd.authelia002.webp)


# 3. 后记

本来搭建起来后，Authelia的Web界面是可以访问的。登录成功后，跳转也是成功的。但是如果再启用IDP的，并试图添加客户，配置没问题。虽然后台显示Nginx将请求发给你验证节点了，但是从浏览器的角度来看是直接可以访问了。上网也查了一些问题的可能性。

首先，Cookies是根据DNS名或IP来划分的，不支持我们这种以端口来区分服务的情况。所以没办法根据SERVER_IP:IP来设置不同的Cookie。

```bash
session:
  cookies:
    - name: authelia_session
      domain: SERVER_IP
      authelia_url: https://SERVER_IP
      default_redirection_url: https://SERVER_IP:8001
      same_site: lax
  secret: 669ebae753159618538b44f3466e3eecaeccf76a590d01005e67e8858672c1d0
  expiration: 10h
  inactivity: 4h
```

其次，在Access Control的部分，虽然只是写正则匹配IP和端口，但是每回都是被IP直接给截胡了，所以就bypass了。

```bash
access_control:
  default_policy: deny
  rules:
    - domain: '^SERVER_IP:PORT$'
      policy: one_factor
    - domain_regex: '^SERVER_IP$'
      policy: bypass
```

尝试更改Nginx配置文件，更改从Nginx传给Authelia的Header里的Host为假的域名。但是依然没有成功。

```bash
# Authelia配置

access_control:
  default_policy: deny
  rules:
    - domain: 'excalidraw.local'
      policy: one_factor
      
# Nginx配置

server {
    listen 8001 ssl;
    server_name excalidraw.local;

    ssl_certificate /etc/nginx/certs/dlc.SERVER_IP.crt;
    ssl_certificate_key /etc/nginx/certs/dlc.SERVER_IP.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers HIGH:!aNULL:!MD5;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # ---- Protected location ----
    location / {
        auth_request /authelia-auth;
        auth_request_set $target_url $scheme://$http_host$request_uri;
        auth_request_set $user $upstream_http_remote_user;

        # Handle Authelia denied responses
        error_page 401 =302 https://SERVER_IP/?rd=$target_url;
        error_page 403 =302 https://SERVER_IP/?rd=$target_url;

        proxy_pass http://excalidraw:80;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host excalidraw.local;
        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;
    }

    # Websocket endpoint (if Excalidraw uses it)
    location /ws/ {
        proxy_pass http://excalidraw_room:80;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }

    # ---- Authelia verification endpoint ----
    location /authelia-auth {
        internal;
        proxy_pass http://authelia:9091/api/verify;
        proxy_set_header Content-Length "";
        proxy_pass_request_body off;

        proxy_set_header Host excalidraw.local;
        proxy_set_header X-Original-URL $scheme://$host$request_uri;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
```

最后我只好作罢了，在没有域名区分服务的情况下，属实是比较难。我相信方法是一定有的，只是我没有扣到底。