关于国内镜像站的一些问题

还是改一下标题吧, 平缓下心情

PkgServer的风声都放出来几个月了
好多人说期待国内的PkgServer镜像
现在1.4.0正式版都出了
结果啥也没有
去清华TUNA的GitHub一搜
再去USTC的GitHub一转
居然还没人提过这个Mirror Request…

既然用镜像站, 就要知道镜像站的规矩
你不提出需求, 谁给你做镜像啊?
PkgServer的事情, 本来应该在Dev版本就该有人去提
早点测试, 也早点发现问题
难道我们Julia社区的活跃度真有那么低吗?

目前本人已经向TUNA提了Mirror Request.

1赞

TUNA不做反向代理类型的镜像。USTC应该是可以做的,不过他们服务器最近好像出了点问题。。。

帮你 @Roger

已经收到回复, 他们确实不做.
说实话我不是很懂镜像站的机制, 这一点没了解到.
明天去碰瓷一下USTC.

标题改一下吧, :kissing:

总的来说没人把 PkgServer 改造一下,让他能产生纯静态的文件,然后国内的大多数镜像站就能同步了。

从设计上来说是有考虑纯的储存服务器的,但是目前是没有实现。开源的日常。

话说这个复杂么?我记得上次 @johnnychen94 跟我提到过这个,有一段时间没有跟进了,不知道Julia1.5有没有相关的issue可以follow?

上面说的稍微有点不准确。

按照 PkgServer 总体的架构储存是分层的:
Proposal: Pkg & Storage Protocols · Issue #1377 · JuliaLang/Pkg.jl

Pkg Server 自己只存一点 metadata,返回的都是储存服务器的地址。
但是目前我翻 JuliaPackaging/PkgServer.jl 是没有实现储存协议的。
相当于一个服务器干了所有的事情。

目前最快的方法是,让 julia 官方或者我们自建的 PkgServer 开个 ftp/rsync/http 都行,把静态文件直接分发出来,让镜像站按目录结构镜像。
然后我们本地自行运行 PkgServer 把 STORAGE_SERVERS 设为镜像源。
自己连本地的 PkgServer 。理论上是可行的。


可能的问题

  • 我没仔细研究 Storage Protocol 不知道按上面这样做能不能向后兼容。毕竟就是个文件分发,没有校验
  • 如果要在 julia 本体中就能直接设置镜像源应该是得改 Pkg.jl 的,这个就更要注意 API 的稳定性了。
    优先修改 PkgServer.jl 吧,把 STORAGE_SERVERS 用环境变量导入不错。

StorageServer的代码其实是有的:https://github.com/JuliaPackaging/PkgServer.jl/blob/master/bin/gen_static.jl 只是不是很好用(特别是在国内的网络环境下)

之前确实想改造一下这个gen_static.jl让它可以设置上游为PkgServer,但最近没精力去做了…

搭PkgServer的事情很早就有询问过USTC:https://github.com/ustclug/discussions/issues/311

我在五年前就提过issue,去年就提过mirror server的事情。所以你为什么说没有?

关于镜像服务器的问题,我目前联系的机构包括:深圳鹏城实验室,华为,ustc,中国科学院物理研究所。然后我发现这完全不是一个技术问题。所以我解决不了。如果有更好的方案欢迎大家提出。

上次华为的人说他们同意提供一个VPS来host镜像,但是目前还没有进展。

这个问题其实很好解决,只要有人愿意长期提供一个公网IP的服务器就行。

分出一个存储协议的前提是有足够的人愿意推进这项工作。但是说实话目前我觉得没有足够的人去推这件事。国内也没有公司在产品上使用,所以不是刚需。

2赞

花了几天时间改造了一下gen_static.jl,自己这边测试是基本正常了,有兴趣的同学可以帮忙测试一下:

需要350GB+的空间

大致的操作步骤:

  1. 利用StorageServer.jl来构建数据
  2. 利用nginx之类的工具来搭建一个HTTP静态服务将STATIC_DIR里的内容分发出去。假设搭的是https://mirrors.lflab.cn/julia
  3. JULIA_PKG_SERVER="https://mirrors.lflab.cn/julia" julia 来切换pkg server
  4. 如果ok的话,写到cron里
2赞

我刚刚试了一下,整个镜像拉下来花了一天时间,这还是网速很好的情况。。。

我本地host之后测试了下,linux下能正常下载安装带artifact的package,不过windows设置了JULIA_PKG_SERVER之后,仍然还有问题。

1赞

我怀疑和没有配置https证书有关,pkg的windows部分代码好像是强制用的tls的样子

See also: 利用Julia PkgServer加速下载 (After Julia v1.4.0)

噢,是的,给忘了

发帖稍欠考虑, 可能急了些, 望大家谅解.

最近去补习了一下。按照我现在的理解,其实像PkgServer.jl那样简单地在国内搭建一个反向代理,即使真的能建成,好像意义也不大。
PkgServer本质上是一个代理,是帮助我去下载分散的网络资源。如果这个代理设在境内,那这个代理本身也要过长城,这个速度貌似也不会提升太多。服务器可分配的带宽可能更大,可能会有一些提升,但根本问题还是解决不了。

不知道我的理解对不对。

我搭建了一个香港镜像,还在测试中,大家有空也可以测试下,给一些反馈。
http://47.75.213.111/

我搭建了一个香港镜像,还在测试中,大家有空也可以测试下,给一些反馈。
http://47.75.213.111/

似乎无法正常工作?

bash-3.2$ curl http://47.75.213.111/registries

curl: (52) Empty reply from server

镜像需要配置ssl(需要域名)才能让windows正常工作,否则大概率会出现下面的情况:

关于国内镜像站的一些问题
我刚刚试了一下,整个镜像拉下来花了一天时间,这还是网速很好的情况。。。

我本地host之后测试了下,linux下能正常下载安装带artifact的package,不过windows设置了 JULIA_PKG_SERVER 之后,仍然还有问题。

在Windows和Linux下我测试了下,还没有碰到上述的情况。SSL证书还没有申请,手上没有闲置的域名。。之后如果有需要我可以配置一下。

 $ curl http://47.75.213.111/registries
/registry/23338594-aafe-5451-b93e-139f81909106/d506717bf2a9fe9a71446f031141a99aacf6498d

我刚意识到你测试的时候镜像可能正在更新。我配置的是00:30自动更新,大概需要7分钟。。

另外我想问一些问题,有些包,比如DecFP似乎无法通过镜像加速,build.jl文件中可以看到似乎还是需要从github上下载。

第二个问题是,在使用StorageServer时查看镜像更新日志时,我发现会出现以下情况

┌ Warning: response status 404       
│   server = "https://pkg.julialang.org"                                  
│   resource = "/artifact/fa5ef00b371ddbca41a5c90c7a404a5833cfe126"       
└ @ StorageServer /home/phyxxs/StorageServer.jl/src/resources.jl:52 
┌ Warning: failed to fetch artifact: 
fa5ef00b371ddbca41a5c90c7a404a5833cfe126                                  └ 
@ StorageServer /home/phyxxs/StorageServer.jl/src/artifact.jl:55

定位到对应的artifact的临时文件会给出

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>openresty/1.15.8.2</center>
</body>
</html>

大概搜了一下这好像是包本身的问题,而不是镜像更新失败?

感谢!

好像是我本地网络的问题,之前挂了全局代理,测试了一下速度确实比sg和kr的要快一些。只是不设置域名的话很难推广及维护。

有些包,比如DecFP似乎无法通过镜像加速,build.jl文件中可以看到似乎还是需要从github上下载。

构造镜像的过程中,只分析Artifacts.toml中有download的项。有一些artifacts会在build过程中下载下来,但是对每个包及版本都build的话:1)时间开销太大 2)很难避免恶意代码。因此有两类数据是无法被镜像的:

  1. 早期的通过build.jl构造的方式,例如DecFP
  2. 没有在Artifacts.toml中给下载链接,而是放在其他代码中给的,例如TestImages.jl

大概搜了一下这好像是包本身的问题,而不是镜像更新失败?

是的。有一些不可控因素会导致这些情况:有些包及版本可能在注册到General之后被删除了,有些版本的artifacts内容可能给错了,有些artifacts在发布之后被删除了。因此在现在要求一个关于过去的完整的镜像是不太现实的。Storage Protocol 能做的持久性保证是:如果我曾经成功镜像过这个artifact资源的话,那么我就一直将它保存在那并且提供服务。当然这也意味着 Storage Server 最终会像 anaconda 的镜像一样占用的存储资源越来越多。

Pkg/Storage Protocol设计的思路是这样的:

Pkg Client <---> Pkg Server <---> Storage Server

其中 Storage Server 是一个单纯的静态资源存储服务,而 Pkg Server 是一个动态缓存层。这样做的目的有二:

  1. Pkg Server 作为缓存层,可以降低拓展的开销,以及让维护变得简单(想象一下你要部署十台镜像服务器)
  2. Pkg Server 可以提供更好的传输性能。例如可以像git一样,只提供版本与版本之间的diff(这个大概能够带来20x的下载加速)。

其中 Pkg Client 和 Pkg Server 的网络链接要非常快,Pkg Server 与 Storage Server 的链接只需要稳定即可。Storage Server 一般不对外开放(例如aliyun obs 或者aws s3)。

如果这个代理设在境内,那这个代理本身也要过长城,这个速度貌似也不会提升太多。

Pkg Server 作为一个缓存层,这只在一个资源被第一次请求时才会发生,如果它在短期内被多次请求的话则不会。所以对于“热门”包来说,PkgServer 的性能是很好的。

京ICP备17009874号-2