本文来记录一下我个人在前端静态服务透明代理上的求索之路，横跨多年的变迁，最终达到极致的优雅。

# 前言

这里所谓的静态代理，通常是指前端项目的静态透明代理，可能是单个的 index.html，也可能是打包构建后的 dist 目录，通过工具代理之后，可基于端口访问完整功能的一个需求场景。

补充：这里我说明下为啥会有这样的场景，以往在维护前端项目部署的时候，通常我们会老老实实打包构建，然后通过 Nginx 来进行代理转发，认为这是天经地义的，但随着技术迭代发展，我们会把前端项目也作为一个独立的容器放到 k8s 里运行，此时比较理想的做法是让容器服务尽量标准化，暴漏统一的端口到 svc，然后通过 ingress 入口访问对应的服务，这种时候，容器的底层镜像用 Nginx 似乎就不甚合适了。后来在进行一些前端项目或者 demo 开发的时候，自己也会遇到一些封装镜像给别人用的场景，这个时候，追求极致的更小可用镜像就成了我的一个目标。

正式介绍之前，先放一张截图来感受一下，如下截图是我使用的几个工具封装后的镜像：

我的求索之路，正是如上截图中镜像大小的倒序来的，分别是 Nginx --> http-server --> dufs --> static-website。尤其是最后一个，实在是到了一个离谱的程度，看到 92k 的大小，你甚至会怀疑它是否能完成我们需要的前端静态代理需求，不用担心，完全 OK 的。

# Nginx

Nginx 当然是静态服务领域的王者，刚入行的时候，我们都是通过 Nginx 来配置前端项目的入口转发，彼时经常会迷失在 Nginx 的某项配置里，遇到前端代码中路由没有放到根目录的情况，更是要和前端同学一块儿排查半天，于是后来就极力要求前端必须让项目简洁易运维，我们的 Nginx 规则也能简单通用。

这里我用一个简单配置演示功能，下文相同，仅演示一个 index.html，表意为主。

FROM docker.cnb.cool/znb/images/nginx

RUN echo 'this is nginx' > /usr/share/nginx/html/index.html

因为注入的 index.html 文件大小几乎可以忽略，因此最终构建的镜像大小和开头截图大小基本无差。

构建运行测试：

$ docker build -t nginx:demo .

$ docker run -itd --name nginx -p 8080:80 nginx:demo

$ curl localhost:8080
this is nginx

# http-server

此前我曾写过一篇文章记录 http-server (opens new window)，详见：认识并使用一个透明代理http-server (opens new window)，写于 2022 年，印证了那个时期我正使用这个工具作为前端的静态代理。

http-server 项目官方提供了一个 Dockerfile，但是没有发布官方的镜像，另外基于官方的 Dockerfile 打包后的镜像出来是 127M，于是我将其做了一下封装，构建之后基础镜像时 109M。之所以这么大，是因为该工具基于 nodejs 编写，运行时需要依赖 node 环境。我的封装 Dockerfile 见：http-server (opens new window)。

同理，这里也做一个 demo 测试：

FROM docker.cnb.cool/znb/images/http-server

WORKDIR /app

RUN echo 'this is http-server' > index.html

CMD ["http-server", "-d", "false", "-p", "8888"]

构建运行测试：

$ docker build -t http-server:demo .

$ docker run -itd --name http-server -p 8081:8888 http-server:demo

$ curl localhost:8081
this is http-server

# dufs

dufs (opens new window) 是一个使用 Rust 编写的静态文件服务器，它继承了 Rust 语言内存占用小、性能高的优点。它的设计哲学就是轻量和快速。

实际上，官方提供的 Docker 镜像有 4.72M，我引用了一个社区主题：dufs-material-assets (opens new window) 封装的二进制，再用 upx 压制之后，重新编写 Dockerfile，最终镜像大小来到了 2.26M，是原来的一半儿大小。

dufs 能力很丰富，这里也用一个 demo 介绍下静态代理能力：

FROM docker.cnb.cool/znb/images/dufs

WORKDIR /app

ADD index.html .

ENTRYPOINT ["/bin/dufs", "--render-index"]

因为基础镜像基于scratch构建，里边没有 echo 命令，因此把 index 文件放在本地了。

构建运行测试：

$ docker build -t dufs:demo .

$ docker run -itd --name dufs -p 8082:5000 dufs:demo

$ curl localhost:8082
this is dufs

# static-website

这是一个偶然的机遇中发现的宝藏，我已经记不得是在哪个前端开源项目里挖掘的，但一见倾心，成为我后续前端 demo 项目静态代理的御用基础工具。

项目地址：docker-static-website (opens new window)

关于这个工具的背景故事，作者有详细的记录，这里援引下来：The smallest Docker image to serve static websites (opens new window) 非常值得一读，作者也曾是一位极致静态代理的求索之人。

那么话不多说，直接上 demo：

FROM docker.cnb.cool/znb/images/docker-static-website:2.6.0

WORKDIR /app

ADD index.html .

CMD ["/busybox-httpd", "-f", "-v", "-p", "8686"]

构建运行测试：

$ docker build -t static-website:demo .

$ docker run -itd --name static-website -p 8083:8686 static-website:demo

$ curl localhost:8082
this is static website

经过构建后的镜像，仍旧只有 92k 最终仍旧能够正常访问。

如果你想体验该项目在 dist 文件场景中的代理能力，可以见我做的一个预览项目：SnowAdmin (opens new window) 。

最后：过往的文章标题，通常都是表意为主，从来不会用这种震惊体，但正如标题所言，当我第一次看到这个工具的时候，的确令我惊叹。

以上，便是我个人在这个领域的探索之路，希望对你有所帮助。所有的镜像我都已经放到个人 CNB 仓库中，你可以快速拉取体验。

另外，在 github 上 static-server (opens new window) 这个主题下还有不少相关的开源项目，如果你有兴趣，也可以探索一些其他的工具，至少本文介绍的，已经足够我日常使用了。