CentOS 7 部署 Eclipse Theia 云 IDE 实战：Docker Compose + nginx-proxy 生产方案 1. 项目概述为什么要在 CentOS 7 上部署 Eclipse Theia这真不是“为了用而用”Eclipse Theia 是一个真正意义上的现代化云 IDE 平台它不是 VS Code 的简单克隆也不是某个厂商闭源产品的 Web 包装版。它基于 TypeScript 构建采用模块化微前端架构核心组件编辑器、调试器、终端、文件系统抽象层全部可插拔、可替换、可独立升级。我在实际带三个远程开发团队做嵌入式固件、Kubernetes 运维工具链和 Python 数据分析平台时发现传统本地 IDE 在协作效率、环境一致性、权限管控和资源复用上存在硬伤——比如新同事花两天配好本地 VS Code PlatformIO Jupyter 插件结果发现 Python 环境版本和团队 CI 服务器不一致又比如测试工程师需要临时调试一个 Java 微服务但他的笔记本跑不动全套 IntelliJ IDEA只能靠截图文字描述来回沟通。Eclipse Theia 就是为解决这类问题而生的它把整个开发环境“收编”到服务器端用户通过浏览器访问所有计算、编译、调试都在后端完成前端只负责渲染和交互。关键词Eclipse Theia、CentOS 7、cloud IDE、Docker Compose、nginx-proxy全部指向一个明确目标在企业级稳定操作系统上用容器化方式构建一个生产就绪、可多租户隔离、能无缝集成现有认证体系的云端开发平台。为什么选CentOS 7而不是 Ubuntu 或 Rocky Linux这不是怀旧而是现实约束。我接手的客户环境里83% 的生产中间件服务器Oracle WebLogic、IBM MQ、SAP NetWeaver仍运行在 CentOS 7.9 x86_64 上内核版本 3.10.0-1160glibc 2.17。这意味着任何依赖较新内核特性如 cgroup v2或新版 glibc 的容器镜像在部署时都会报错退出。Theia 官方推荐的 Node.js 版本是 18.x但 CentOS 7 默认仓库只提供 Node.js 10.x强行升级会破坏系统 Python 2.7 的依赖关系很多运维脚本还依赖它。所以必须用 Docker 隔离运行时环境——这正是Docker Compose成为不可替代工具的原因它能精确声明 Theia 服务、反向代理、SSL 终止、静态资源缓存等组件的启动顺序、网络拓扑和卷挂载策略避免手动敲一堆docker run命令导致的配置漂移。而nginx-proxy不是随便选的它是社区验证最成熟的自动反向代理方案配合docker-gen可以实现“容器一启动域名自动生效”省去每次手动改 Nginx 配置、reload 服务的繁琐操作这对需要快速交付多个项目环境的 DevOps 团队来说节省的是实打实的人力成本。你可能在网上搜到“vmware虚拟机安装centos 7”或“centos 7 minimal 下载”这些关键词背后的真实需求是如何在一台物理服务器上用最小化安装的 CentOS 7构建一个安全、稳定、可审计的云 IDE 底座。这恰恰是我们要解决的核心问题——不是教你怎么装系统而是告诉你装完之后每一步配置背后的业务逻辑和安全考量。2. 整体架构设计与技术选型依据为什么不用 Kubernetes为什么坚持用 nginx-proxy2.1 架构全景图四层解耦各司其职整个平台不是把 Theia 打包成一个大镜像扔进容器就完事了。我把它拆成四个清晰的逻辑层每一层都解决一类特定问题基础设施层Infrastructure LayerCentOS 7 主机 Docker Engine 20.10.24 Docker Compose v2.20.2。这里的关键是 Docker 版本选择。CentOS 7.9 的内核 3.10.0 对较新 Docker 存在兼容性问题官方明确要求 Docker Engine 20.10.x 是最后一个支持该内核的稳定系列。我试过直接装 Docker 24.x结果dockerd启动失败日志里反复出现cgroup: cgroup2: unknown option nsdelegate错误——这是内核不支持 cgroup v2 的典型表现。所以必须锁定 20.10.x并禁用 cgroup v2在/etc/docker/daemon.json中添加exec-opts: [native.cgroupdriversystemd]和features: {buildkit: true}然后systemctl restart docker。这个细节网上很多教程都忽略导致后续 Compose 启动失败却找不到原因。网络与接入层Network Ingress Layernginx-proxyletsencrypt-nginx-proxy-companion。很多人问为什么不直接用 Nginx 手动配置因为手动配置无法应对动态扩缩容。假设你今天部署了 theia-proj-a明天要加 theia-proj-b手动改 Nginx 配置、生成证书、reload 服务每次都要人工介入出错概率高。nginx-proxy的核心价值在于它的自动化机制它监听 Docker daemon 的事件流一旦检测到新容器启动且带有VIRTUAL_HOSTtheia-proj-a.example.com标签就自动更新 Nginx 配置并 reload。letsencrypt-nginx-proxy-companion则负责自动申请和续期 Lets Encrypt 证书。我实测过从docker-compose up -d到浏览器打开https://theia-proj-a.example.com显示绿色锁图标全程不到 90 秒且证书有效期自动续期无需人工干预。这就是为什么它比单纯用traefik或haproxy更适合中小团队——复杂度低稳定性高文档成熟。应用服务层Application Service LayerEclipse Theia 容器本身。这里有个关键决策用官方镜像还是自建官方eclipse/theia-full:latest镜像体积超过 2GB包含大量开发语言支持Go、Rust、Java但我们的团队只用 Python 和 JavaScript。盲目使用会导致镜像拉取慢、磁盘占用高、安全扫描漏洞多因为包含了不必要的二进制文件。所以我选择基于eclipse/theia-python:latest基础镜像通过Dockerfile精简定制删除apt-get install阶段安装的gcc、g、make等编译工具开发环境在容器内编译在宿主机或 CI 流水线完成只保留python3-pip、nodejs、npm和git。最终镜像大小压到 850MB启动时间从 42 秒缩短到 18 秒Clair 扫描漏洞数从 137 个降到 21 个。这个精简过程不是简单的apt-get remove而是要逐行分析theia-python的 Dockerfile理解每个RUN指令的用途再决定是否保留。数据与安全层Data Security Layervolumes挂载策略 密码策略强制实施。volumes不是随便写个- ./workspace:/home/project就完事。Theia 的工作区workspace必须挂载到容器内非 root 用户的家目录下否则会出现权限拒绝错误Permission denied when saving file。我定义了两个关键卷theia-workspace用于持久化用户代码theia-config用于保存用户个性化设置主题、快捷键、插件列表。更重要的是theia-workspace必须设置为:z或:ZSELinux 标签CentOS 7 默认启用 SELinux否则容器内进程无法读写挂载目录。这个细节在 Ubuntu 上不存在但在 CentOS 7 上是必填项漏掉就会卡在登录后空白页。至于密码策略centos 7 minimal安装后默认不启用 PAM 密码强度检查。我们必须手动配置/etc/pam.d/system-auth加入password requisite pam_pwquality.so try_first_pass local_users_only retry3 authtok_type minlen8 dcredit-1 ucredit-1 ocredit-1 lcredit-1 maxrepeat2这一行才能满足“最小密码长度为8位最小字符类型数为4种大小写字母、数字、特殊符号同一类最大连续字符数为2”的硬性要求。这不是可选项而是等保 2.0 和 ISO 27001 审计的明确条款。2.2 为什么放弃 Kubernetes一个被低估的现实成本看到这里你可能会想既然都用 Docker 了为什么不直接上 Kubernetes毕竟 K8s 是云原生标配。我必须坦诚地说在 CentOS 7 环境下K8s 不是银弹而是负担。我们做过详细对比测试在一台 32GB 内存、8 核 CPU 的 Dell R740 服务器上部署一套最小化的 K8s 集群kubeadm containerd Calico CNI仅控制平面etcd、kube-apiserver、scheduler、controller-manager就常驻消耗 4.2GB 内存和 1.8 个 CPU 核心。而我们的 Theia 平台单实例峰值内存占用 1.2GBCPU 占用 0.7 核。这意味着如果上 K8s光是“养”集群的成本就占了总资源的 65%。更麻烦的是兼容性Kubernetes 1.24 已完全弃用 Docker Shim要求使用 containerd 或 CRI-O。但 CentOS 7 的containerd包在 EPEL 仓库中版本太老1.4.x不支持 K8s 1.24 的 CRI 接口强行升级又会破坏 Docker Engine 的稳定性。我们曾尝试用k3s轻量版 K8s但它在 CentOS 7 上的 systemd 服务管理存在 bugk3s-server进程偶尔会因fork()失败而崩溃日志里全是Cannot allocate memory根源是 CentOS 7 的vm.max_map_count默认值65530远低于 k3s 推荐值262144而修改这个参数需要重启服务器这在生产环境是不可接受的。相比之下Docker Compose 的资源开销几乎为零所有组件都作为普通进程运行故障排查路径清晰docker logs、docker exec -it直接进容器学习曲线平缓。对于一个 5-20 人规模的开发团队Docker Compose 提供的可靠性、可维护性和成本效益远超 K8s 带来的所谓“先进性”。2.3 nginx-proxy 的替代方案评估traefik vs haproxy vs 手动 nginxnginx-proxy是当前方案的核心但它的地位并非不可撼动。我们曾深度评估过三种主流替代方案Traefik优势是动态配置、内置 Lets Encrypt、Dashboard 可视化。但问题在于它的acme.json证书存储机制。Traefik 要求acme.json文件权限必须是600且只能由 Traefik 进程自己读写。在 Docker Compose 环境下如果多个 Traefik 实例比如为不同环境部署共享同一个acme.json会因文件锁竞争导致证书申请失败。我们测试时发现当并发启动 3 个 Traefik 实例时有 40% 的概率出现failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: too many certificates already issued for exact set of domains错误。这是因为 Traefik 的 ACME 客户端没有实现分布式锁而nginx-proxy的letsencrypt-nginx-proxy-companion使用文件系统原子操作flock实现了可靠的分布式协调。HAProxy性能顶尖但配置极其复杂。要实现自动 SSL 终止必须结合acme.sh脚本和cron定时任务手动编写reload逻辑。当后端服务Theia 容器IP 地址变更时Docker 网络重连HAProxy 不会自动更新后端服务器列表必须触发haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)命令。这个过程无法做到nginx-proxy那样的毫秒级响应平均延迟 3-5 秒。对于开发者频繁切换项目环境的场景这种延迟是不可接受的。纯手动 Nginx最可控但运维成本最高。每次新增一个 Theia 实例就要 SSH 登录服务器编辑/etc/nginx/conf.d/theia-proj-a.conf生成证书nginx -t测试语法systemctl reload nginx。我们统计过一个熟练的 SRE 完成这一套流程平均耗时 4 分钟 17 秒。按每月新增 12 个项目环境计算一年就是 10 小时的重复劳动。而nginx-proxy把这个时间压缩到 0完全自动化。最终选择nginx-proxy不是因为它技术最炫而是因为它在“功能完备性”、“稳定性”、“社区成熟度”和“学习成本”四个维度上取得了最佳平衡。它的 GitHub 仓库有超过 2.8 万颗星Issue 平均响应时间 2.3 小时文档覆盖 98% 的边缘场景。这种经过大规模生产环境验证的稳健性是任何新锐项目都无法比拟的。3. 核心细节解析与实操要点从 CentOS 7 最小化安装到 Theia 容器就绪3.1 CentOS 7 Minimal 安装后的必要初始化别跳过这 7 个步骤很多教程直接从yum update开始但centos 7 minimal安装后系统处于一个“裸机”状态很多基础工具缺失直接装 Docker 会报各种依赖错误。以下是我在 17 个不同硬件平台包括 VMware Workstation Pro、VMware ESXi、物理服务器上验证过的标准化初始化流程缺一不可启用 EPEL 仓库yum install epel-release -y。EPELExtra Packages for Enterprise Linux提供了大量 CentOS 官方仓库没有的高质量软件包比如python3-pip、htop、iftop。不启用 EPEL后续很多依赖无法安装。安装基础工具集yum groupinstall Development Tools -y yum install git wget curl vim-enhanced net-tools -y。“Development Tools” 组包含了gcc、make、autoconf等编译工具虽然 Theia 容器内不编译但 Docker Compose 的某些插件如docker-compose-viz需要本地编译。net-tools提供ifconfig、netstat是网络排错的基石。配置防火墙firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-port22/tcp firewall-cmd --reload。CentOS 7 默认启用 firewalld必须显式放行 80/443 端口否则nginx-proxy无法对外提供服务。注意这里用--add-service而不是--add-port因为http/https服务在/usr/lib/firewalld/services/下有预定义的 rich rule比直接开端口更安全。禁用 NetworkManager 并启用传统 network 服务systemctl stop NetworkManager systemctl disable NetworkManager systemctl start network systemctl enable network。这是 VMware 虚拟机环境的特有问题。NetworkManager会与 Docker 的docker0网桥产生冲突导致容器网络无法访问外网。network服务则更稳定与 Docker 兼容性更好。执行后检查/etc/sysconfig/network-scripts/ifcfg-ens33网卡名可能不同中的ONBOOTyes是否已设置。调整内核参数以适配 Docker编辑/etc/sysctl.conf追加以下三行net.ipv4.ip_forward 1 vm.swappiness 1 fs.inotify.max_user_watches 524288ip_forward1是 Docker 网络通信的基础swappiness1强制系统优先使用物理内存而非 swap避免 Docker 容器因内存压力被 OOM Killer 杀死inotify.max_user_watches提高文件监控上限防止 Theia 在大型工作区10k 文件中因监控句柄不足而卡顿。执行sysctl -p生效。配置 SELinux 为 permissive 模式仅限测试或 enforcing 模式生产setenforce 0临时或sed -i s/SELINUXenforcing/SELINUXpermissive/g /etc/selinux/config永久。生产环境强烈建议保持enforcing但必须配合正确的 SELinux 标签见 3.3 节。permissive模式只记录告警不阻止便于初期排错。创建专用用户并配置 sudo 权限useradd -m -s /bin/bash devops echo devops ALL(ALL) NOPASSWD: ALL /etc/sudoers。永远不要用 root 用户直接操作 Docker。devops用户拥有无密码 sudo 权限可以执行docker、docker-compose、systemctl等命令符合最小权限原则。提示以上步骤必须按顺序执行尤其是第 4 步禁用 NetworkManager和第 5 步内核参数它们是 Docker 后续稳定运行的前提。我曾在一个客户现场因为跳过了第 4 步导致 Theia 容器内ping www.google.com失败排查了 3 小时才发现是NetworkManager与docker0的冲突。3.2 Docker 与 Docker Compose 的精准安装版本锁定与依赖修复CentOS 7 的yum install docker安装的是 Docker 1.13早已过时且不支持 Compose v2。我们必须手动安装指定版本。以下是经过 12 次完整重装验证的可靠流程卸载旧版 Dockeryum remove docker docker-common docker-selinux docker-engine -y。确保干净起步。安装依赖包yum install -y yum-utils device-mapper-persistent-data lvm2。device-mapper-persistent-data和lvm2是 Docker 存储驱动devicemapper的必需依赖CentOS 7 Minimal 默认不安装。添加 Docker 官方仓库yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo。注意必须用httpshttp会被重定向而 CentOS 7 的yum默认不支持重定向。安装指定版本的 Docker Engineyum install -y docker-ce-20.10.24 docker-ce-cli-20.10.24 containerd.io-1.4.13。版本号必须严格匹配。containerd.io-1.4.13是与 Docker 20.10.24 兼容的最后一个稳定版。执行docker --version应输出Docker version 20.10.24, build 297e128。启动并启用 Docker 服务systemctl start docker systemctl enable docker。检查状态systemctl status docker | grep Active应显示active (running)。安装 Docker Compose v2Docker Compose v1docker-compose命令已被废弃。v2 是作为dockerCLI 的一个插件发布的。下载二进制文件curl -SL https://github.com/docker/compose/releases/download/v2.20.2/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose。赋予执行权限chmod x /usr/local/bin/docker-compose。创建软链接ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose。验证docker compose version注意是docker compose不是docker-compose应输出Docker Compose version v2.20.2。注意centos7 docker compose安装这个关键词背后很多人卡在第 6 步。常见错误是下载了docker-compose-Linux-x86_64v1文件却试图用docker-compose --version命令验证结果报错command not found。根本原因是 v1 的二进制名是docker-compose而 v2 的二进制名是docker-compose-plugin它被设计为docker命令的子命令。必须用docker compose version来验证。3.3 volumes 挂载的深层原理与安全实践SELinux、权限、生命周期volumes是 Docker 数据持久化的命脉但在 CentOS 7 上它比 Ubuntu 复杂得多核心难点在于 SELinux 和用户 ID 映射。SELinux 标签详解CentOS 7 默认启用 SELinux其安全策略会阻止容器进程访问挂载卷除非显式标记。docker run的-v参数支持三种标签z、Z和:ro。z表示“私有卷”Docker 会为该卷分配一个唯一的 SELinux 上下文如system_u:object_r:svirt_sandbox_file_t:s0:c123,c456且该上下文只对该容器有效Z表示“共享卷”上下文对所有容器可见。对于 Theia 的工作区theia-workspace我们必须用z标签因为每个 Theia 实例的工作区是相互隔离的。命令示例docker run -v /opt/theia-workspace:/home/project:z ...。如果漏掉:z容器内执行ls -Z /home/project会看到unconfined_u:object_r:default_t:s0这是被 SELinux 拒绝的上下文touch test.txt会报Permission denied。用户 IDUID映射Theia 官方镜像默认以 UID 1001 的用户theia运行。但宿主机上/opt/theia-workspace目录的所有者是root:rootUID 0。如果不做映射容器内theia用户UID 1001对宿主机目录UID 0没有写权限。解决方案有两个一是创建宿主机用户useradd -u 1001 theia chown -R theia:theia /opt/theia-workspace二是更优雅的方式——在docker-compose.yml中使用user: 1001:1001指令并确保挂载目录的权限是755或775。我推荐后者因为它不污染宿主机用户空间。卷的生命周期管理docker volume create theia-workspace创建的命名卷其数据存储在/var/lib/docker/volumes/theia-workspace/_data。这个路径受 Docker 管理docker volume rm会彻底删除数据。而绑定挂载bind mount-v /opt/theia-workspace:/home/project的数据在宿主机/opt/theia-workspacedocker volume rm对其无效。对于生产环境我强制要求使用命名卷因为它的生命周期与容器解耦备份和迁移更方便。备份命令tar -czf theia-workspace-backup.tar.gz -C /var/lib/docker/volumes/ theia-workspace/_data。实操心得在centos 7 unmount这个关键词背后很多人遇到umount: /var/lib/docker/volumes/theia-workspace/_data: target is busy错误。这是因为 Theia 容器仍在运行其进程持有该目录的文件句柄。正确做法是先docker-compose down停止所有服务再umount。如果down后仍 busy用lsof D /var/lib/docker/volumes/theia-workspace/_data查看哪个进程在占用通常是containerd-shim进程残留kill -9即可。3.4 Eclipse Theia 镜像的定制化构建从 2GB 到 850MB 的瘦身实战官方eclipse/theia-full:latest镜像是一个“瑞士军刀”但我们的场景只需要“螺丝刀”。定制化构建不是为了炫技而是为了安全、性能和可维护性。以下是完整的Dockerfile和构建逻辑# 使用官方 Python 版本作为基础它已经包含了 Python 3.9 和 Node.js 16 FROM eclipse/theia-python:latest # 设置工作目录 WORKDIR /home/theia # 删除不必要的编译工具和大型依赖 # 这些工具在容器内不用于编译只会增加体积和漏洞 RUN apt-get update \ apt-get remove -y \ gcc g make build-essential \ clang llvm \ rustc cargo \ openjdk-11-jdk \ golang-go \ apt-get autoremove -y \ apt-get clean \ rm -rf /var/lib/apt/lists/* # 清理 npm 缓存减小镜像体积 RUN npm cache clean --force # 安装我们项目必需的 Python 包示例 RUN pip3 install --no-cache-dir \ jupyterlab \ pylint \ black \ flake8 # 安装我们项目必需的 VS Code 扩展Theia 兼容 # 扩展 ID 可在 open-vsx.org 网站搜索 RUN /home/theia/theia/scripts/install-extension.sh \ ms-python.python \ ms-toolsai.jupyter \ esbenp.prettier-vscode \ redhat.vscode-yaml # 创建非 root 用户并切换 RUN useradd -m -u 1001 -s /bin/bash theia \ chown -R theia:theia /home/theia \ chmod -R 755 /home/theia USER theia # 暴露端口 EXPOSE 3000 # 启动命令 CMD [/home/theia/theia/scripts/start.sh]构建命令docker build -t my-theia-python:1.0 .。关键点解析基础镜像选择eclipse/theia-python:latest是官方提供的、针对 Python 开发优化的镜像体积约 1.2GB比theia-full小 40%且预装了pip、python3、jupyter等核心依赖省去了我们自己安装的麻烦。apt-get remove的精准性我们不是盲目删除所有gcc相关包而是只删gcc、g、make、build-essential这几个最重量级的。clang、llvm是 C/C 编译器rustc、cargo是 Rust 工具链openjdk-11-jdk是 Java 开发包golang-go是 Go 编译器。这些在我们的 Python/JS 项目中完全用不到删除后可减少 320MB 体积和 89 个已知 CVE 漏洞。扩展安装方式install-extension.sh是 Theia 提供的官方脚本它会将扩展下载到/home/theia/.theia/extensions目录并在启动时自动加载。相比在docker-compose.yml中通过THEIA_EXTENSIONS环境变量动态安装这种方式更可靠因为扩展在镜像构建时就已验证可用不会因网络波动导致启动失败。用户切换最后USER theia指令至关重要。它确保容器以非 root 用户身份运行符合安全最佳实践。如果忘记这行容器将以 root 用户启动所有文件操作都具有最高权限一旦被攻破后果不堪设想。构建完成后用docker images | grep my-theia-python查看镜像大小应为847MB。用docker history my-theia-python:1.0查看各层大小确认apt-get remove层确实减少了数百 MB。4. 实操过程与核心环节实现从零开始部署一个可访问的 Theia 实例4.1 项目目录结构与文件准备让一切井然有序所有配置文件必须放在一个统一的项目目录下便于版本控制和团队协作。我推荐的结构如下/theia-deployment/ ├── docker-compose.yml # 主编排文件 ├── nginx-proxy/ │ ├── docker-compose.yml # nginx-proxy 服务定义 │ └── nginx.tmpl # 自定义 Nginx 模板可选 ├── theia/ │ ├── Dockerfile # 自定义镜像构建文件见 3.4 节 │ └── config/ │ └── settings.json # Theia 全局配置可选 └── .env # 环境变量文件存储域名、邮箱等/theia-deployment/是根目录。nginx-proxy/和theia/是两个独立的子项目遵循“关注点分离”原则。docker-compose.yml是整个平台的“总指挥”它通过include指令Compose v2.2 支持或extends关键字来组合各个服务。但为了最大兼容性CentOS 7 的 Compose v2.20.2 完全支持我采用更传统的depends_on和networks方式。.env文件内容示例DOMAIN_NAMEtheia.example.com EMAILadminexample.com THEIA_WORKSPACE/opt/theia-workspace THEIA_CONFIG/opt/theia-config这个文件是敏感信息的集中地git必须忽略它.gitignore中添加.env。DOMAIN_NAME和EMAIL将被nginx-proxy用于自动申请 SSL 证书。4.2 nginx-proxy 的 docker-compose.yml 详解自动化魔法的源头/theia-deployment/nginx-proxy/docker-compose.yml是整个接入层的核心。以下是经过生产环境千次启动验证的完整配置version: 3.8 services: nginx-proxy: image: nginxproxy/nginx-proxy:alpine container_name: nginx-proxy ports: - 80:80 - 443:443 volumes: - /var/run/docker.sock:/tmp/docker.sock:ro - /etc/nginx/certs:/etc/nginx/certs:ro - /etc/nginx/vhost.d:/etc/nginx/vhost.d - /usr/share/nginx/html:/usr/share/nginx/html - ./nginx.tmpl:/app/nginx.tmpl:ro networks: - theia-net restart: unless-stopped nginx-proxy-letsencrypt: image: nginxproxy/acme-companion container_name: nginx-proxy-letsencrypt volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/nginx/certs:/etc/nginx/certs - /etc/nginx/vhost.d:/etc/nginx/vhost.d - /usr/share/nginx/html:/usr/share/nginx/html - ./acme.json:/acme.json environment: - NGINX_PROXY_CONTAINERnginx-proxy - DEFAULT_EMAIL${EMAIL} depends_on: - nginx-proxy networks: - theia-net restart: unless-stopped networks: theia-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16关键配置说明nginx-proxy服务使用nginxproxy/nginx-proxy:alpine镜像体积小15MB启动快。/var/run/docker.sock:/tmp/docker.sock:ro是它监听 Docker 事件的“耳朵”必须以只读方式挂载这是安全底线。/etc/nginx/certs是证书存储目录nginx-proxy-letsencrypt会自动将 Lets Encrypt 证书写入此处。nginx-proxy-letsencrypt服务这是自动证书管理的“大脑”。acme.json文件存储了 ACME 协议的账户密钥和证书信息权限必须是600chmod 600 acme.json否则会报错。DEFAULT_EMAIL从.env文件读取用于 Lets Encrypt 的通知。网络theia-net我们创建了一个自定义桥接网络172.20.0.0/16而不是使用默认的bridge网络。这样做的好处是所有服务都在同一个可控的 IP 段内nginx-proxy可以通过服务名如theia-app直接访问后端无需暴露端口到宿主机安全性更高。nginx-proxy和theia-app都连接到这个网络它们之间通过内部 DNS 解析通信。提示windows docker compose或ubuntu安装docker compose的用户这个配置同样适用。唯一区别是 Windows 上docker.sock的路径是//var/run/docker.sock但nginx-proxy镜像已做了适配无需修改。4.3 Theia 主服务的 docker-compose.yml安全、高效、可扩展/theia-deployment/docker-compose.yml是主文件