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

话说这个复杂么?我记得上次 @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 镜像服务及镜像站索引 - #11

噢,是的,给忘了

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

最近去补习了一下。按照我现在的理解,其实像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正常工作,否则大概率会出现下面的情况:

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

我本地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 的性能是很好的。

只是不设置域名的话很难推广及维护。

的确,现在的打算是先放出来验证一下可行性和成本。希望之后还是等官方的国内镜像,学校镜像,华为云或者阿里镜像站来提供服务。把这边验证好之后和其他服务商交涉可能也会比较容易。现在使用的人比较少,带宽还能承受的住,推广开来的话可能带宽也会有压力,也就很难靠一己之力支撑了。

有了Storage Protocol的话,感觉学校的镜像应该可以接受了吧?毕竟可能之前是不支持反向代理类的PkgServer…

  1. 早期的通过build.jl构造的方式,例如DecFP

这类包如果上游不解决的话, 似乎这只能通过手动修改build.jl解决?

是的。有一些不可控因素会导致这些情况

这样看来还好,之前总担心是因为镜像配置或者网络问题造成的。 之后可能可以加入一些区分机制把这类包带第一次镜像的时候就识别一下生成单独的deprecation list之类,在之后的镜像更新环节跳过。

  1. 早期的通过build.jl构造的方式,例如DecFP

这类包如果上游不解决的话, 似乎这只能通过手动修改build.jl解决?

这个终归只是一个临时的解决方案,我认为与其在这里考虑如何镜像这类包,不如考虑直接在上游修复…

之后可能可以加入一些区分机制把这类包带第一次镜像的时候就识别一下生成单独的deprecation list之类,在之后的镜像更新环节跳过

前几天在gen_static.jl中他们已经修改了: [gen_static.jl]: Add resource blacklist by staticfloat · Pull Request #40 · JuliaPackaging/PkgServer.jl · GitHub

StorageServer.jl 是从gen_static.jl中重构出来的。后期可能会改造成更纯粹的pkg mirror,即只镜像上游提供的内容。但目前能用就好… 所以对它的加强在我这里的优先级很低…

前几天在gen_static.jl中他们已经修改了。

感谢告知!

后期可能会改造成更纯粹的pkg mirror

是类似现在USTC Mirror这样的吗?用PkgMirror包支持的并且提供artifacts的?如果这样的话, 仿佛也的确不需要StorageServer,不用考虑给Pkg Server分发…这样可能学校镜像可以提供支持…

StorageServer.jl目前的构建是从General registry和每个包的Artifacts.toml来分析出哪些内容应该被下载和存储下来,如果遇到上游没有或者资源找不到的情况,就会报warning,异常处理什么的挺脏的,比如原始gen_static.jl大概有个七八层嵌套在里面。

一个纯粹的 mirror 协议的话应该是根据上游存储提供的数据来进行下载:上游提供啥就下载啥。这样的话整个代码会变得更简洁更好维护。

@songxianxu 北外镜像站已经上线了:julia | 镜像站使用帮助 | 北京外国语大学开源软件镜像站 | BFSU Open Source Mirror

1 个赞

@johnnychen94 感谢!过几天我就把那边停掉。