<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Docker-Compose on 魔都水滴</title>
    <link>https://blog.margrop.net/tag/docker-compose/</link>
    <description>Recent content in Docker-Compose on 魔都水滴</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Fri, 10 Jul 2026 22:00:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/tag/docker-compose/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>受够远程控制被限速？我把 RustDesk 服务端搬回自己家：多合一部署、避坑与安全加固</title>
      <link>https://blog.margrop.net/post/rustdesk-all-in-one-server-guide/</link>
      <pubDate>Fri, 10 Jul 2026 22:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/rustdesk-all-in-one-server-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;RustDesk 是一款强调开源与自托管的远程桌面工具。客户端之间能直接连接时，画面和键鼠数据优先点对点传输；直连失败时，才由中继服务转发。把服务端部署在自己控制的机器上，最大的价值不是“完全不要服务器”，而是把设备登记、中继路径、密钥、账号和日志重新放回自己的控制范围。&lt;/p&gt;&#xA;&lt;p&gt;本文使用社区维护的 &lt;code&gt;lejianwen/rustdesk-server-s6&lt;/code&gt; 多合一镜像，把 RustDesk OSS 的 &lt;code&gt;hbbs&lt;/code&gt;、&lt;code&gt;hbbr&lt;/code&gt; 与社区 API、Web 管理功能放进一个容器。它适合家庭、实验室和小团队简化部署，但&lt;strong&gt;不是 RustDesk 官方发行的多合一服务端&lt;/strong&gt;。生产环境仍需自行评估社区镜像、固定版本或镜像摘要、备份数据，并测试升级和回滚。&lt;/p&gt;&#xA;&lt;p&gt;本文所有域名都使用 &lt;code&gt;example.com&lt;/code&gt;，没有展示真实 IP、私有域名、主机名、设备 ID、账号、密钥、Token、Cookie 或镜像仓库地址。公开截图来自项目官方页面或社区仓库公开素材。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>别把 API Key 到处塞了：我用 NewAPI 搭了一个自用 AI 中转站</title>
      <link>https://blog.margrop.net/post/newapi-self-hosted-relay-station/</link>
      <pubDate>Fri, 10 Jul 2026 15:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/newapi-self-hosted-relay-station/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;NewAPI 不是一个“白嫖模型”的工具，也不是一个神秘代理。它更像我家里的“AI 前台”：所有 App 只认一个入口，前台负责转发到合法授权的上游模型，顺手做令牌、额度、分组、日志、模型限制和用量统计。对自用场景来说，最舒服的地方不是“多了一个网页”，而是终于不用把每个上游 Key 分散塞进十几个客户端。&lt;/p&gt;&#xA;&lt;p&gt;本文会按我自己搭自用中转站的思路写：为什么需要它、容易误解在哪里、最小可用 Docker Compose 怎么跑、为什么我建议加持久化目录、Windows 11 / Ubuntu 26.04 / macOS 26 三套一键脚本怎么写，以及让 Agent 自动配置时应该给它什么边界。全文不放真实内网地址、完整主机名、私有域名和任何密钥。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>我把 Docker 命令行装进了“驾驶舱”：Portainer 2.39.4 从部署到避坑，一篇就够</title>
      <link>https://blog.margrop.net/post/portainer-ce-docker-deployment-guide/</link>
      <pubDate>Fri, 10 Jul 2026 15:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/portainer-ce-docker-deployment-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Portainer 不是 Docker 的替代品，它更像 Docker 主机的“驾驶舱”：底层发动机仍然是 Docker Engine，Portainer 只是把容器、镜像、网络、卷和 Compose Stack 整理成网页按钮、表格与状态卡片。&lt;/p&gt;&#xA;&lt;p&gt;我用 &lt;code&gt;portainer/portainer-ce:2.39.4&lt;/code&gt; 做了一次隔离部署，完成初始化、接入本机 Docker、查看仪表盘、筛选容器、创建演示 Stack，并记录了真实截图。部署本身只要一条 &lt;code&gt;docker run&lt;/code&gt;，真正需要认真理解的却是三件事：&lt;code&gt;/data&lt;/code&gt; 必须持久化、&lt;code&gt;/var/run/docker.sock&lt;/code&gt; 权限非常高、生产环境不要把管理页面毫无遮挡地暴露到公网。&lt;/p&gt;&#xA;&lt;p&gt;本文没有展示完整 IP 地址、真实主机名、内网域名、管理员密码、Token、Cookie、私有镜像地址或生产容器名称。截图里的实验资源使用专门的演示名称，容器地址已遮盖。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Docker 容器无限重启？只因 v3.7.0 少了一个 serve —— 思源笔记 CLI 破坏性变更修复实录</title>
      <link>https://blog.margrop.net/post/siyuan-v370-docker-restart-loop-fix/</link>
      <pubDate>Thu, 02 Jul 2026 19:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/siyuan-v370-docker-restart-loop-fix/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;把思源笔记从 v3.6.x 升级到 v3.7.0 后，Docker 容器陷入无限重启循环。&lt;code&gt;docker logs&lt;/code&gt; 显示 &lt;code&gt;Error: unknown flag: --accessAuthCode&lt;/code&gt;。根因是 v3.7.0 引入了 CLI 子命令架构，原来的顶级 flag 现在需要加一个 &lt;code&gt;serve&lt;/code&gt; 子命令。修复只需在 docker-compose.yml 的 &lt;code&gt;command&lt;/code&gt; 字段最前面加上 &lt;code&gt;&#39;serve&#39;&lt;/code&gt;，多 7 个字符，从无限重启到正常运行。&lt;/p&gt;&#xA;&lt;p&gt;本文给出完整排查过程、三种操作系统下的一键修复脚本（Windows 11 / Ubuntu 26.04 / macOS 26），以及人工执行和 AI Agent 自动配置两种方法。所有脚本只调用 Docker CLI 和 SSH，不依赖第三方服务。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Portainer 改个 stack 一直 500？我花了一晚上才明白，是 Docker 引擎里多了一个「重影」网络</title>
      <link>https://blog.margrop.net/post/portainer-500-duplicate-compose-network-enigma/</link>
      <pubDate>Sat, 13 Jun 2026 08:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/portainer-500-duplicate-compose-network-enigma/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Portainer 改一个 stack，浏览器上弹出 &lt;code&gt;500 Internal Server Error&lt;/code&gt;。你以为又是 YAML 写错了，回去检查 compose 语法、缩进、引号、镜像 tag，全部都对。但每次重试都是同一个 500。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;真正的问题藏在 HTTP response body 的 &lt;code&gt;message&lt;/code&gt; 字段最深处：&lt;code&gt;network librespeed_default is ambiguous (2 matches found on name)&lt;/code&gt;。&lt;/strong&gt; 也就是说，Docker 引擎里同时存在两个 &lt;code&gt;librespeed_default&lt;/code&gt; 网络——两个 ID、两个 &lt;code&gt;Created&lt;/code&gt; 时间、两个 &lt;code&gt;com.docker.compose.config-hash&lt;/code&gt;，但名字一模一样。Compose 启动时让引擎去 lookup 名字，引擎说「我选不出来」，compose up 失败，Portainer 把这条错误原样包成 500 退给浏览器。&lt;/p&gt;&#xA;&lt;p&gt;修复办法朴素到尴尬：在引擎上&lt;strong&gt;删掉其中一个孤儿网络&lt;/strong&gt;（&lt;code&gt;docker network rm &amp;lt;id&amp;gt;&lt;/code&gt; 或在 Portainer 的 Networks 里点 Remove），再原样点一次 Update the stack，就过了。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;这篇文章源于一次真实的 stack 改挂载路径的过程。全程我已经把所有内网地址、镜像仓库地址、卷挂载路径、容器名、用户名密码用 &lt;code&gt;&amp;lt;PLACEHOLDER&amp;gt;&lt;/code&gt; 替换，只保留公开信息、官方源码、错误文本这些可分享的内容。&lt;/p&gt;</description>
    </item>
    <item>
      <title>别再用旧方法了！Ubuntu 26.04 LTS 一键搞定最新 Docker 社区版与极速镜像源配置</title>
      <link>https://blog.margrop.net/post/ubuntu-26-docker-install-guide/</link>
      <pubDate>Tue, 26 May 2026 10:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/ubuntu-26-docker-install-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;写在前面&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;随着 Ubuntu 26.04 LTS（Resolute Raccoon）的正式发布，许多开发者和系统管理员都开始将他们的开发与生产环境迁移至这个最新的长期支持版本。然而，作为容器化技术的基石，Docker 在新系统上的安装与配置却给不少人带来了困扰。&lt;/p&gt;&#xA;&lt;p&gt;如果你还在使用传统的 &lt;code&gt;apt-get install docker.io&lt;/code&gt; 或者套用几年前的 Ubuntu 20.04/22.04 旧教程来配置 APT 源与镜像加速，那么你可能会面临软件包版本陈旧、源格式冲突（DEB822 新格式带来的困惑）、或者因网络阻断导致镜像无法拉取的窘境。&lt;/p&gt;&#xA;&lt;p&gt;本文将手把手带你深度剖析 Ubuntu 26.04 下 Docker 社区版（Docker CE）的正确安装姿势，并结合最新的 DEB822 源规范、非 Root 用户安全权限划分、以及在当前复杂网络环境下的极速代理与私有镜像源配置，为你奉上一份真正结构化、高可用的实战指南。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
  </channel>
</rss>
