feat: :sparkles: 支持Huggingface Space部署方式使用Cloudflare Tunnels自定义访问域名

[Hoshino-Yumetsuki]

感觉这个方案比较复杂，鉴于Huggingface Space在中国能够正常访问，自定义域名的意义并不大

虽然看起来意义不大，但是这为有需要的人提供了一种新的选择。而且hf space的域名说不定什么时候也会被墙。 并且虽然看起来麻烦，实际上就是注册zero trust+输入环境变量的事。

[imaegoo]

改了一下，关于那个dockerfile，这么写是有必要的，在hf的构建环境下这么干更加利于维护

你是以开发者的角度认为这是有必要的，把开发态的东西打包进镜像里会影响镜像文件大小和性能，另外node版本不做限定也是不利于维护的，推荐使用已经测试过的官方镜像作为基础镜像

curl用于获取cloudflared

dockerfile ADD命令可以从某个http地址向镜像添加文件

此外关于日志，hf的权限管理非常严格，将日志重定向到文件会出现permission error

不需要将日志重定向到文件，我指的是日志输出到stdout（/dev/stdout）

还有就是tunnels的启动只会输出约5条日志，之后就不会再有了

那也要输出到stdout

[Hoshino-Yumetsuki]

改了一下，关于那个dockerfile，这么写是有必要的，在hf的构建环境下这么干更加利于维护

你是以开发者的角度认为这是有必要的，把开发态的东西打包进镜像里会影响镜像文件大小和性能，另外node版本不做限定也是不利于维护的，推荐使用已经测试过的官方镜像作为基础镜像

curl用于获取cloudflared

docker add命令可以从某个http地址向镜像添加文件

此外关于日志，hf的权限管理非常严格，将日志重定向到文件会出现permission error

不需要将日志重定向到文件，我指的是日志输出到stdout（/dev/stdout）

还有就是tunnels的启动只会输出约5条日志，之后就不会再有了

那也要输出到stdout

emmm，虽然但是，dockerfile是直接交付给hf space打包部署的，不需要考虑大小和性能问题。关于日志输出我稍候改一下

[imaegoo]

emmm，虽然但是，dockerfile是直接交付给hf space打包部署的，不需要考虑大小和性能问题。关于日志输出我稍候改一下

hf也是需要冷启动的，为了用户体验，几毫秒的冷启动时长能优化的也要优化的。

[imaegoo]

不想优化我可以来优化

[Hoshino-Yumetsuki]

emmm，虽然但是，dockerfile是直接交付给hf space打包部署的，不需要考虑大小和性能问题。关于日志输出我稍候改一下

hf也是需要冷启动的，为了用户体验，几毫秒的冷启动时长能优化的也要优化的。

彳亍，我到时候一起优化

[armful5862]

这个方案应该谨慎选择，使用 Cloudflare Tunnels 反代可能导致被封号