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

问题反馈
1

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

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

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

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

1 个赞
2

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

3

帮你 @Roger

4

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

5

标题改一下吧， :kissing:

6

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

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

7

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

8

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

按照 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 用环境变量导入不错。
9

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

10

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

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

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

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

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

2 个赞
11

花了几天时间改造了一下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 个赞
12

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

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

image
image1741×241 29.3 KB

image
image831×329 15.5 KB

1 个赞
13

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

See also: Julia PkgServer 镜像服务及镜像站索引 - #11

14

噢，是的，给忘了

15

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

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

不知道我的理解对不对。

16

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

17

我搭建了一个香港镜像，还在测试中，大家有空也可以测试下，给一些反馈。
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 之后，仍然还有问题。

18

在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>

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

感谢！

19

好像是我本地网络的问题，之前挂了全局代理，测试了一下速度确实比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 的镜像一样占用的存储资源越来越多。

20

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