为什么我不想让 Docker 成为默认部署路径
Source: Dev.to
Docker 是优秀的软件。我想先说明这一点，因为互联网有一种特殊的天赋，会把每一种工具的观点都变成一场笼斗。
我使用 Docker。我喜欢 Docker 用于数据库、可重复的 CI 任务、奇怪的依赖栈、内部服务，以及任何需要干净的系统镜像且在各处表现一致的场景。
但我 不 想让 Docker 成为每个 Web 应用的默认部署路径。
有时我只想把一个小应用放到 VPS 上运行。这应该是乏味的。
默认路径变得更繁重
许多现代部署教程悄悄地把下面的步骤：
# 传统步骤
build app
copy files to server
start app
route traffic变成了这样：
# Docker‑centric 步骤
write a Dockerfile
pick a base image
handle build layers
create a registry
push an image
pull it on the server
wire up compose
configure networking
mount secrets
debug why the container exits这些步骤本身并不邪恶——只是数量很多。对许多应用来说，它们并不是最有趣的部分。
如果我在部署一个副项目、一个小型 SaaS、一个 webhook 处理器、一个仪表盘，或者一个小型内部工具，应用通常只需要几件简单的事：
- 编译代码
- 启动进程
- 提供 HTTPS 服务
- 崩溃时自动重启
- 将密钥从 git 中剥离
- 出错时显示日志
- 可能在同一台机器上运行多个应用
这个列表 并不 自动意味着“把所有东西都容器化”。
容器解决真实问题
This is not an anti‑Docker post. Docker solves problems that are absolutely real:
- 可重复的运行时
- 更少神秘的系统软件包
- 服务隔离
- 更简便的持续集成
- 一个通用的可传递制品
Those are useful, but defaults matter. When Docker becomes the first step for every deploy, even tiny apps inherit container concerns before they have container problems. Developers then start thinking about image size, build cache, multi‑stage builds, registry auth, container networking, volume paths, base‑image updates, and whether the process can find the right port inside the container. All valid, just not always the first thing to address.
VPS 可以运行普通进程
VPS 本身已经是一台计算机。它可以运行进程。现代部署建议常常把服务器视为只有在运行容器调度器时才有用，但对于许多应用来说，直接的进程模型已经足够：
# Example process commands
bun run start
node server.js
./my-go-app
./target/release/my-rust-app困难的部分通常 不是 “Linux 能否运行这个二进制文件？” 而是围绕它的所有内容：
- 流量如何到达它？
- HTTPS 如何工作？
- 如何在不中断服务的情况下部署新版本？
- 日志放在哪里？
- 密钥如何注入？
- 如何重启它？
- 如何在同一台机器上运行多个应用？
这些是部署问题，而不一定是 Docker 的问题。
Source: …
我想要 PaaS 的体验，但不想放弃服务器
我喜欢 PaaS 的感觉：
deploy然后应用就上线了。我也喜欢拥有一台小型 VPS——它便宜、灵活，而且“老实”可靠。我知道应用运行在哪里，可以 SSH 进去，也可以检查机器。我不想把每个周末项目都变成云架构图。
对我来说，理想的流程更像这样：
tako deploy- 本地机器构建应用。
- 部署工具将发布包复制到服务器。
- 服务器将应用作为普通进程运行。
- 代理将请求路由到健康的实例。
- 处理 HTTPS。
- 日志可用。
- 秘钥在随机的
.env文件之外进行管理。
不需要镜像仓库。不需要 Dockerfile，除非我真的想要。对于一个两路由的 Web 应用，也不需要容器网络的难题。
这正是我在使用 Tako 探索的方向——一个用于在自己的服务器上运行应用的小型部署工具。
乏味的路径应当是顺畅的路径
有一种部署方式几乎让人感到失望地平淡：
tako init
tako servers add
tako deploy这正是我想要的那种“乏味”——这里的“乏味”指的是：
- 在首次部署之前需要了解的概念更少
- 仅为基础设施创建的文件更少
- 小型应用的移动部件更少
- 隐藏简单错误的地方更少
- “等等，这是 Docker 的问题还是应用的问题？”的时刻更少
默认路径应当优化为首先让应用上线。如果以后应用需要容器化，再使用容器。
Docker 应该是一个选项，而不是入场费
Web 有把强大工具变成强制工具的习惯。Docker 很强大，值得拥有它的位置，但我不认为每次部署都应该让开发者先去写容器配方。
对于许多项目，最佳的部署路径仍然是：
- 构建应用
- 将其放到服务器上
- 运行它
- 将流量路由到它
- 让更新变得乏味
这并不是老派；这只是一种好的抽象。默认的部署路径应该让人感到平静，就像服务器在帮助你运行应用——而不是在午饭前就要求你成为平台工程师。