Docker on 魔都水滴

7 个 AI 编程套餐，每天开 7 个标签页查额度？我写了个看板一屏搞定

Sun, 26 Jul 2026 06:00:00 +0800

先说结论

如果你同时订阅了 Codex、MiniMax、火山方舟、Kimi Code、LongCat、千问 AI、Google AI 等多家 AI 编程套餐，大概率体验过一种痛苦：每天要在 7 个不同网站、7 套不同的登录体系里反复查看"还剩多少额度"。我开源了一个自托管的配额看板 coding-plan-dashboard，一条 docker compose up -d 启动后，所有平台的额度百分比、重置倒计时、多账号信息全部聚合在一个深色页面上，打开浏览器就能看到。本文写作与截图时间为 2026 年 7 月 26 日。

Docker 拉不动别急着换 DNS：国内镜像加速源挑选、配置与避坑全指南

Wed, 15 Jul 2026 19:30:00 +0800

先说结论国内网络环境下，Docker 拉取镜像失败，往往不是镜像不存在，也不一定是 DNS 的锅。更常见的原因是：公共仓库的访问链路拥堵、某个加速源临时故障，或者配置文件改对了却没有重启 Docker。我的建议是：先打开 status.anye.xyz，把它当作“镜像源天气预报”，看多个源最近是否可用；再根据自己的系统改对配置文件；改完先校验 JSON，再重启 Docker，最后用一个小镜像做真实拉取验证。一、问题背景：为什么昨天能拉，今天就超时？很多人第一次遇到这个问题，是在部署一个很普通的服务：nginx、redis、postgres，或者 NAS 上的媒体服务。命令可能只有一句： docker pull nginx:alpine 但终端却出现了超时、context deadline exceeded、TLS handshake timeout、connection reset by peer，甚至长时间停在下载层。换一个镜像标签、重启路由器、修改本地 DNS，有时能暂时恢复，于是大家容易得出一个结论：Docker 太玄学。其实 Docker 拉镜像像是“从仓库借书”： Docker 客户端先找到仓库地址；再通过网络连接仓库；仓库返回镜像清单；客户端逐层下载内容；最后校验每一层是否完整。这条链路中任何一段堵住，都会表现为“拉不下来”。所以，镜像加速源不是魔法按钮，而是给这条路增加一条更顺畅的入口。二、问题表现：不要只看网页能不能打开一个镜像源网页能打开，不等于 Docker 一定能用。选择加速源时，至少要看四件事： 1. 地址是否真的可达浏览器打开首页，只能证明首页响应了。Docker 还要访问 Registry API、鉴权接口和镜像层下载接口。网页正常、拉取失败，是完全可能的。 2. 是否支持完整的 Docker Hub 加速链路有些地址只是一个网页代理或搜索页面，并不是 Docker Registry mirror。配置到 registry-mirrors 后，如果 docker info 看不到它，或者 docker pull 仍然直接访问默认仓库，就要怀疑它并非真正的加速服务。 3. 是否持续稳定，而不是刚好今天在线镜像源很像城市道路：今天通车，不代表明天不施工。稳定性比某一次测速的峰值更重要。家用 NAS 可以接受偶尔切换，CI 构建和生产环境则应该准备备用方案。

买了海外 VPS 又有顶级域名，然后呢？这 12 件事，才是公网 IP 真正的含金量

Sat, 11 Jul 2026 13:30:00 +0800

先说结论

单独一台海外 VPS，只是一间通了电、接了网、却没有门牌号的小房间；单独一个顶级域名，只是一块漂亮招牌。把域名托管到 Cloudflare，再将 DNS 指向 VPS，才等于同时拥有“门牌、导航、店面和公网入口”。

它真正的价值并不是“可以搭一个博客”这么简单，而是让普通人第一次拥有一块全天在线、能被全世界标准互联网访问、能运行自己代码的数字土地：博客、API、Webhook、状态页、密码库、监控、文件入口、自动化任务、远程访问中转，甚至个人 AI 服务的统一入口，都可以从这里长出来。

但公网 IP 也像一扇开在闹市区的门：你刚装好门锁，互联网上的扫描器可能已经来拧过门把手。因此本文既讲“能做什么”，也讲“哪些东西千万别直接暴露”。

受够远程控制被限速？我把 RustDesk 服务端搬回自己家：多合一部署、避坑与安全加固

Fri, 10 Jul 2026 22:00:00 +0800

先说结论

RustDesk 是一款强调开源与自托管的远程桌面工具。客户端之间能直接连接时，画面和键鼠数据优先点对点传输；直连失败时，才由中继服务转发。把服务端部署在自己控制的机器上，最大的价值不是“完全不要服务器”，而是把设备登记、中继路径、密钥、账号和日志重新放回自己的控制范围。

本文使用社区维护的 lejianwen/rustdesk-server-s6 多合一镜像，把 RustDesk OSS 的 hbbs、hbbr 与社区 API、Web 管理功能放进一个容器。它适合家庭、实验室和小团队简化部署，但不是 RustDesk 官方发行的多合一服务端。生产环境仍需自行评估社区镜像、固定版本或镜像摘要、备份数据，并测试升级和回滚。

本文所有域名都使用 example.com，没有展示真实 IP、私有域名、主机名、设备 ID、账号、密钥、Token、Cookie 或镜像仓库地址。公开截图来自项目官方页面或社区仓库公开素材。

别把 API Key 到处塞了：我用 NewAPI 搭了一个自用 AI 中转站

Fri, 10 Jul 2026 15:30:00 +0800

先说结论

NewAPI 不是一个“白嫖模型”的工具，也不是一个神秘代理。它更像我家里的“AI 前台”：所有 App 只认一个入口，前台负责转发到合法授权的上游模型，顺手做令牌、额度、分组、日志、模型限制和用量统计。对自用场景来说，最舒服的地方不是“多了一个网页”，而是终于不用把每个上游 Key 分散塞进十几个客户端。

本文会按我自己搭自用中转站的思路写：为什么需要它、容易误解在哪里、最小可用 Docker Compose 怎么跑、为什么我建议加持久化目录、Windows 11 / Ubuntu 26.04 / macOS 26 三套一键脚本怎么写，以及让 Agent 自动配置时应该给它什么边界。全文不放真实内网地址、完整主机名、私有域名和任何密钥。

我把 Docker 命令行装进了“驾驶舱”：Portainer 2.39.4 从部署到避坑，一篇就够

Fri, 10 Jul 2026 15:30:00 +0800

先说结论

Portainer 不是 Docker 的替代品，它更像 Docker 主机的“驾驶舱”：底层发动机仍然是 Docker Engine，Portainer 只是把容器、镜像、网络、卷和 Compose Stack 整理成网页按钮、表格与状态卡片。

我用 portainer/portainer-ce:2.39.4 做了一次隔离部署，完成初始化、接入本机 Docker、查看仪表盘、筛选容器、创建演示 Stack，并记录了真实截图。部署本身只要一条 docker run，真正需要认真理解的却是三件事：/data 必须持久化、/var/run/docker.sock 权限非常高、生产环境不要把管理页面毫无遮挡地暴露到公网。

本文没有展示完整 IP 地址、真实主机名、内网域名、管理员密码、Token、Cookie、私有镜像地址或生产容器名称。截图里的实验资源使用专门的演示名称，容器地址已遮盖。

我最后留下的自用 Web 剪贴板，居然只有一个文本框

Fri, 10 Jul 2026 15:30:00 +0800

先说结论

我试过不少“跨设备剪贴板”“在线便签”“临时文本同步”工具，最后反而留下了一个看起来最寒酸的东西：minimalist-web-notepad。它打开之后几乎什么都没有，只有一个文本编辑框，只支持纯文本，不支持登录用户、不支持富文本、不支持图片、不支持标签分类，甚至连“保存按钮”都不明显。

但正是这种“功能少到没什么可炫耀”的设计，让它特别适合做自用轻量级 Web 剪贴板：临时从手机传一段命令到电脑、从电脑丢一段说明到平板、给自己留一段短文本、用 curl 在脚本里读写一小段状态。它不像知识库，也不像团队协作文档，更像桌面旁边那张随手撕下来的便签纸。

本文会用 ahfeil/minimalist-web-notepad:latest 镜像演示 Docker Compose 部署；同时给出 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本，以及人工自动执行和 Agent 自动配置两种方法。全文不展示任何完整内网地址、内网域名、完整计算机名称或真实隐私数据。

别把青龙数据直接硬搬！我实测了一次青龙迁白虎，真正的坑在这 5 个地方

Thu, 09 Jul 2026 10:30:00 +0800

先说结论

从青龙面板迁移到白虎面板，最危险的做法不是“不会迁”，而是“以为复制目录就等于迁移成功”。这次我在一台隔离 Docker 实验环境里实际跑了一遍：新建青龙容器，造了两条环境变量、两个定时任务和几份脚本；再把它们迁到一套全新白虎面板里，最后用 API 和白虎页面截图核对。

最终可稳定迁移的是三类核心资产：scripts 脚本文件、环境变量、定时任务。真正需要转换的是：青龙的数字 ID 要变成白虎的字符串 ID；青龙任务里的 task xxx.py 要变成白虎能执行的命令；青龙的标签、启停状态、环境变量关系要写进白虎自己的表结构。迁移前必须备份白虎库，迁移时最好停掉白虎容器，迁移后必须做数量核对和页面验证。

本文不展示任何真实内网地址、主机名、私有镜像仓库、真实 Cookie、真实 Token 或生产路径。截图来自实验环境，变量值也只使用脱敏样例。

青龙面板还能公网裸奔吗？几个月前那次致命漏洞后，我更建议你看白虎面板

Thu, 09 Jul 2026 10:00:00 +0800

先说结论

青龙面板曾经是很多人自托管定时任务的默认选择：跑脚本、管环境变量、看日志、定时同步仓库都很方便。但 2026 年初公开爆出的青龙面板致命漏洞，把一个老问题重新摆到台面上：定时任务面板不是普通网页，它往往握着脚本、变量、通知密钥和执行权限。一旦认证被绕过，攻击者看到的不是一个登录页，而是一台可以被调度的机器。

如果你只是新装一个轻量任务面板，我现在更建议优先评估白虎面板。白虎面板采用 Go + Vue3，主打轻量、高性能、低系统开销，并且官方 README 已经明确支持 Docker / Docker Compose 部署、Mise 运行时管理、仓库任务同步、执行日志和多渠道通知。它不是“青龙的一比一复制品”，但对很多个人脚本托管场景已经够用。

如果你因为兼容旧脚本、历史任务或迁移成本，必须临时继续用青龙面板：不要把它直接暴露在公网。 至少在前面加 VPN、零信任访问、反向代理二次认证、IP allowlist、WAF 或其它访问控制。本文给出 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本，默认部署白虎；只有显式指定时才部署青龙，并且都会把面板放到 Basic Auth 保护后面。

Docker 容器无限重启？只因 v3.7.0 少了一个 serve —— 思源笔记 CLI 破坏性变更修复实录

Thu, 02 Jul 2026 19:30:00 +0800

先说结论

把思源笔记从 v3.6.x 升级到 v3.7.0 后，Docker 容器陷入无限重启循环。docker logs 显示 Error: unknown flag: --accessAuthCode。根因是 v3.7.0 引入了 CLI 子命令架构，原来的顶级 flag 现在需要加一个 serve 子命令。修复只需在 docker-compose.yml 的 command 字段最前面加上 'serve'，多 7 个字符，从无限重启到正常运行。

本文给出完整排查过程、三种操作系统下的一键修复脚本（Windows 11 / Ubuntu 26.04 / macOS 26），以及人工执行和 AI Agent 自动配置两种方法。所有脚本只调用 Docker CLI 和 SSH，不依赖第三方服务。

Docker 镜像不求人:从 0 到 1 在自己家里搭一个 13GB 的私有仓库

Fri, 26 Jun 2026 12:30:00 +0800

先说结论

我家那台小服务器上跑着一个 registry:2 镜像仓库,已经攒了 13 GB 缓存、95 个仓库。它在局域网里给我所有的 NAS、PVE、Mac、Windows 提供 Docker Hub 镜像加速,冷启动一个 alpine 不到 1 秒,完全不走公网 Docker Hub。

这篇文章不讲"先装 Docker 然后跑个容器"这种一句废话教程。我会把真实在生产环境跑的部署脚本、登录鉴权流程、反向代理最容易踩的 4 个坑、htpasswd 密码文件怎么管理、缓存怎么排错,一次性摊开。

看完你应该能做的:① 在 10 分钟内起一个带登录的 registry;② 解释清楚 WWW-Authenticate 头为啥不能丢;③ 给老板、给家人讲明白这个仓库到底在干什么。

别再让 Agent 吞掉你的 Token：我把 Headroom 接到 NewAPI、OpenClaw 和 HermesAgent 的完整实战

Sat, 20 Jun 2026 12:30:00 +0800

先说结论

这次我没有替换原来的 NewAPI，也没有让 OpenClaw / HermesAgent 直接改用一个不确定的新网关。真正做法是：在 NewAPI 前面加一层 Headroom 代理，把所有已经使用 OpenAI-compatible 协议的调用改到 http://<headroom-host>:8787/v1，而原来的 NewAPI 入口继续保留。这样 Agent 发来的长上下文先经过 Headroom 压缩，再转发给 NewAPI，最后仍由 NewAPI 统一路由到后端模型。

最关键的原则只有一句：先测试，后修改；只迁移测试通过的 OpenAI-compatible 项；非 OpenAI 协议的 fallback 不碰。 这篇文章既是复盘，也是一份可以直接交给 Agent 或人工照着执行的操作指南。

我把 AnythingLLM 装进 Docker 之后，容器像一只上紧发条的小松鼠——反复重启直到我把那个 1000:1000 给它

Wed, 17 Jun 2026 20:30:00 +0800

TL;DR（先说结论）

AnythingLLM 这只"啥都能塞进去的 LLM 口袋书"官方就有 Docker 镜像，正常情况下 docker run 一行就能起；但它里面那位 anythingllm 用户很挑剔——挂给它的宿主机目录必须属于 1000:1000，否则它写不动自己的 SQLite 数据库，Prisma 启动迁移会直接挂掉，容器就会进入"重启—挂掉—再重启"的死循环。修起来不到一分钟：chown -R 1000:1000 /你的数据目录，再 docker compose up -d 一次，它就乖乖听 3001 了。

本文顺道把"Prisma 那个 file:../storage/anythingllm.db 相对路径为什么能坑死人"讲清楚，最后附上 Portainer stack 写法、几条常见坑、以及中英两个 demo 地址。

PhotoPrism 启动 5 分钟还在装系统包？一次 PHOTOPRISM_INIT=intel 的踩坑与正确配置

Sat, 13 Jun 2026 08:30:00 +0800

TL;DR（先说结论）

PhotoPrism Plus 镜像的 docker-compose.yml 里有一行 PHOTOPRISM_INIT: "intel"，看似只是给 Intel 核显开加速，实际上它在容器第一次启动时会去 archive.ubuntu.com 跑一次完整的 apt-get dist-upgrade，再装 7 个 GPU / VA-API 包。这套流程 5–10 分钟起步，整个期间容器内部没有任何进程在监听 2342 端口。你的 docker ps 显示 Up、Portainer 一切绿、ss -ltn 也看到 0.0.0.0:2342 在 LISTEN——但浏览器一访问就是 ERR_CONNECTION_RESET / Connection reset by peer。

解法非常简单：删掉或清空那一行。你 devices 里已经挂上 /dev/dri/renderD128 直通，驱动和 VA-API 用户态工具由宿主机提供，容器里再装一遍是纯浪费。

Portainer 改个 stack 一直 500？我花了一晚上才明白，是 Docker 引擎里多了一个「重影」网络

Sat, 13 Jun 2026 08:00:00 +0800

先说结论

Portainer 改一个 stack，浏览器上弹出 500 Internal Server Error。你以为又是 YAML 写错了，回去检查 compose 语法、缩进、引号、镜像 tag，全部都对。但每次重试都是同一个 500。

真正的问题藏在 HTTP response body 的 message 字段最深处：network librespeed_default is ambiguous (2 matches found on name)。 也就是说，Docker 引擎里同时存在两个 librespeed_default 网络——两个 ID、两个 Created 时间、两个 com.docker.compose.config-hash，但名字一模一样。Compose 启动时让引擎去 lookup 名字，引擎说「我选不出来」，compose up 失败，Portainer 把这条错误原样包成 500 退给浏览器。

修复办法朴素到尴尬：在引擎上删掉其中一个孤儿网络（docker network rm <id> 或在 Portainer 的 Networks 里点 Remove），再原样点一次 Update the stack，就过了。

这篇文章源于一次真实的 stack 改挂载路径的过程。全程我已经把所有内网地址、镜像仓库地址、卷挂载路径、容器名、用户名密码用 <PLACEHOLDER> 替换，只保留公开信息、官方源码、错误文本这些可分享的内容。

Docker 容器跑得好好的，端口死活访问不了：一次 HostIp 绑定'半残'的完整复盘

Sat, 13 Jun 2026 07:30:00 +0800

一句话总结：

docker ps 看着一切正常，docker inspect 的 HostConfig.PortBindings 也写好了 203.0.113.14:3001:3000——但 host 上没有 docker-proxy 在监听、iptables nat/DOCKER 链里没有 DNAT 规则、NetworkSettings.Networks 和 Ports 两个字段都是空 {}。这种"容器活着、端口死了"的诡异状态，本质是 libnetwork 在 attach 网络时因为目标接口尚未就绪而静默回滚了 endpoint 创建，但容器进程已经起好，docker 也没把"端口没生效"这件事主动告诉我们。30 秒一行命令就能让端口重新回来：docker network connect <net> <ctr>。

把一台慢成蜗牛的 Docker 镜像代理从 5 分 14 秒干到 0.6 秒:我踩过的三个坑和一段 5 行的 cron

Sat, 13 Jun 2026 07:20:00 +0800

先说结论

我在家里的自建小集群上跑着一个 registry:2 的 pull-through 代理,平时给局域网里的几台机器和 NAS 当 Docker Hub 镜像源用,用了快两年一直挺稳。直到有一天,它拉一个 5MB 的 alpine 镜像要 5 分 14 秒。

这篇文章记录我怎么查到根因、换了哪些方案、为什么每一版都没让我满意、最后怎么用一个 5 行的 bash 脚本 + 每天一次的 cron 把它彻底稳下来。整个排查过程 100% 是我在自己的机器上跑出来的真实数据,不是我抄 README、不是我看博客道听途说。

关键决策点都贴了实测数据。如果你也在自建 docker 镜像代理,或者你公司的 devops 团队在维护一个内部 registry 镜像,文末的 Q&A 段能帮你省掉至少 3 小时的踩坑。

别再用旧方法了！Ubuntu 26.04 LTS 一键搞定最新 Docker 社区版与极速镜像源配置

Tue, 26 May 2026 10:00:00 +0800

写在前面

随着 Ubuntu 26.04 LTS（Resolute Raccoon）的正式发布，许多开发者和系统管理员都开始将他们的开发与生产环境迁移至这个最新的长期支持版本。然而，作为容器化技术的基石，Docker 在新系统上的安装与配置却给不少人带来了困扰。

如果你还在使用传统的 apt-get install docker.io 或者套用几年前的 Ubuntu 20.04/22.04 旧教程来配置 APT 源与镜像加速，那么你可能会面临软件包版本陈旧、源格式冲突（DEB822 新格式带来的困惑）、或者因网络阻断导致镜像无法拉取的窘境。

本文将手把手带你深度剖析 Ubuntu 26.04 下 Docker 社区版（Docker CE）的正确安装姿势，并结合最新的 DEB822 源规范、非 Root 用户安全权限划分、以及在当前复杂网络环境下的极速代理与私有镜像源配置，为你奉上一份真正结构化、高可用的实战指南。

新电脑 Bitwarden 登不上，旧电脑却正常：一次 Vaultwarden 版本兼容坑的完整复盘

Mon, 18 May 2026 10:05:00 +0800

先说结论

这次问题表面上看是“新安装的 Chrome + Bitwarden 扩展登录失败”，但根因并不在 Chrome，也不是账号密码输错，而是 Bitwarden 2026.4.1 客户端登录流程调用了新的 prelogin 接口，而自建 Vaultwarden 服务端还停留在 1.35.4-alpine，缺少 /identity/accounts/prelogin/password 接口。

旧电脑之所以还能用，是因为它大概率已有登录态和本地缓存，并没有重新触发完整的首次登录流程。真正的修复不是反复重装浏览器，而是先备份，再把 Vaultwarden 升级到 1.36.0 或更新版本，然后用日志确认新接口不再 404。

本文所有域名、路径、账号、部署目录均已脱敏，示例中统一使用 vault.example.com、/opt/vaultwarden 等占位值，不包含任何内网地址或私人信息。

Docker 容器太多导致网段冲突：把自动分配网络统一迁回 172 私有段的完整记录

Mon, 13 Apr 2026 08:00:00 +0800

这篇文章记录的是一次很典型、也很容易被忽略的 Docker 网络故障：容器越来越多，Docker 自动分配出来的 user-defined bridge 网段，最后落进了 192.168.x.x，并且和家里的真实局域网发生了冲突。问题本身不算复杂，但它有一个很讨厌的特点：它不是那种“容器起不来”或者“端口没映射”的显性错误，而是把整个家庭网络拖进一个很别扭的半瘫痪状态。

当时在我的 NAS 上，家里部分设备开始出现访问异常。表面上看，像是某个设备离线，或者某个交换机、AP、路由器出了毛病；但我沿着 Docker 的网络一路排查下去后，最终确认，真正的根因不是单个容器坏了，而是 Docker 网络池的自动分配策略，已经把局域网挤到了一个危险的位置。

cloudflare workers 解决docker无法拉取镜像问题

Mon, 10 Jun 2024 14:16:26 +0800

由于某些原因，目前国内无法正常拉取docker镜像，去年写的加速拉取镜像的办法也没法用，困难总比办法多（不是），干脆新写一篇教程，利用cloudflare workers 解决docker无法拉取镜像问题。

本篇利用cloudflare workers来解决无法拉取镜像问题，关于cloudflare这里不再过多介绍，cloudflare workers服务也是免费，不懂的童鞋可以自行翻看往期文章《cloudflare加快github下载》。如果看完本篇也不想动手，也可以在后台回复“jsdc”获取我搭建好的公共服务地址。

【转】如何设置xiaoya的docker，及tvbox配置

Tue, 30 Apr 2024 21:18:55 +0800

文章来源：https://xiaoyaliu.notion.site/xiaoya-docker-69404af849504fa5bcf9f2dd5ecaa75f

如何设置xiaoya的docker

要获得最新小雅的资讯请关注小雅的tg频道 https://t.me/xiaoyaliu

平时有什么使用上遇到的困难可以来这里找我或其他人帮助 https://t.me/PlutoPlayer

你需要什么才能安装 xiaoya 的docker

软路由盒子类似 n1 等，具有 openwrt环境（可以终端上一键配置）
NAS 等具有docker插件（无法或很难登入终端，需要图形化自行配置）
云服务器也就是俗称的 vps （可以终端上一键配置）

Docker容器内如何连接宿主机的MySQL服务器

Thu, 30 Sep 2021 13:08:50 +0800

博主最近遇到一种情况，从服务器拷贝了一份数据库在宿主机Mysql服务器上，想要用本地的数据库测试自己的代码正确性，但是项目程序都是靠docker一键部署的，于是必定要在docker容器里访问到本地的数据库。在探索中遇到了问题并得到了解决。

reboot 后 Docker服务及容器自动启动设置

Tue, 06 Apr 2021 14:39:32 +0800

重启reboot操作系统后，发现docker 服务未启动，容器也未启动，天生反骨，怎么才能重启后自动启动呢？

解决问题两个问题：

1、docker服务自动重启设置

systemctl enable docker.service

搭建自己的密码管理服务器 Bitwarden

Wed, 17 Feb 2021 20:20:06 +0800

很多人对于把密码放在网上，比如 lastpass 虽然官方说是提供加密了，服务器上看不到用户密码，但是还是不太放心，那么就可以搭建开源的 Bitwarden 搭建一个自己的密码管理服务器。

准备：一个 vps 服务器和一个域名且解析 IP 地址到服务器

如何搭建开源的Web流程图工具 Diagrams.net（原draw.io）

Sat, 30 Jan 2021 17:59:08 +0800

ProcessOn目前已经是大家熟知的Web的流程图，UML等绘图工具了。但 ProcessOn 是收费服务，免费的又限制太多，那还有免费的午餐吗？

有，就是Diagrams.net。完全免费，功能强大~

CentOS 7 安装Docker并设置国内阿里源

Fri, 29 Jan 2021 11:40:18 +0800

docker版本

docker从1.13版本之后采用时间线的方式作为版本号，分为社区版CE和企业版EE。Docker CE即社区免费版，Docker EE即企业版,付费使用。

Python3的Web环境，含第三方以及自建

Sun, 24 Jan 2021 13:07:30 +0800

之前因为某件家事，需要使用Python3的Web环境，于是收集了一下。第三方网站的环境使用起来很简单，但缺点也很明显，不能保存上次的Python代码。

【转】黑群晖（Synology）半洗白最新方法

Tue, 19 Jan 2021 18:10:53 +0800

最近新搭一个NAS，安装好发现之前提供的半洗白方案已经不起作用了之前的帖子http://blog.lixx.vip/黑群晖（synology）nas-6-22-折腾记-半洗白/ 主要是群晖新版的Docker 18.09.0-0506关闭了DDSM安装