修复 LXD 默认的 images 远程的访问故障
前言
最近又出大事了。LXC 社区禁止了 LXD 对 images.linuxcontainers.org
的访问。这导致 LXD 用户无法再创建或刷新非 Ubuntu 容器。
本文将告诉你修复方法,以及这中间发生了什么。
LXD 和 LXC
阅读本文前有必要搞清楚这二者的关系。LXD 是 Ubuntu 开发的建立在 LXC 之上的管理程序,用户通过 LXD 提供的一套操作服务和环境来更便捷的管理 LXC 容器。
所以我们仍然说 LXC 容器,不会说 LXD 容器。LXD 不仅更加方便,它还在存储、网络等方面对 LXC 进行了扩展。这种关系有点类似于 Libvirt 和 QEME/KVM。
不过 LXC 自身也有一套基础功能管理自己,例如我在 OpenWrt 上就直接使用 LXC。
远程镜像
无论 LXC 还是 LXD 都可以在创建时拉取远程镜像,它们会集成一些类似“镜像仓库”的远程服务。LXD 自带一个名为 images
的远程,直接使用 LXC 的地址,即 https://images.linuxcontainers.org
。
我们使用 LXD 创建 Ubuntu 镜像时,不需要使用 images
这个远程,因为 Ubuntu 有自己的远程托管/维护自己的镜像。所以 https://images.linuxcontainers.org
出现访问问题,意味着 LXD 只能创建 Ubuntu 容器了。
如果你尝试基于远程模板创建容器,会得到这样的错误:
Error: Failed instance creation: Failed getting remote image info: Failed getting image: The requested image couldn't be found for fingerprint "xxx"
分歧
根据 LXC 官方论坛的帖子所述:从前 LXC 的远程镜像服务(也就是 https://images.linuxcontainers.org
)是 LXC 和 Ubuntu 共同分担开销的。面对庞大活跃用户,这个服务要付出高昂的财务支出。后来 Ubuntu 貌似因为负责在 LXC 社区中工作的员工离职了,而不再承担这部分费用。
然后 LXC 社区和 LXD 项目还有一些分歧,具体可以看原帖。于是 LXC 社区负责人决定停止来自 LXD 对远程镜像的访问。所以最近我们不能从 LXD 创建或获得任何 images
远程的镜像了。
这个决定开始到正式实施,经历了 5 个月的时间。理论上充足的给了用户迁移时间,也给了 Ubuntu 创建新的托管服务的时间。虽然我用 LXD 但我完全理解这个决定。Ubuntu 对这个决定表示遗憾,然后自己搭建了新的远程服务。
切换远程地址
首先使用 lxc remote list
命令查看自己的远程列表:
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| NAME | URL | PROTOCOL | AUTH TYPE | PUBLIC | STATIC | GLOBAL |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| images | https://images.lxd.canonical.com | simplestreams | none | YES | NO | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| local (current) | unix:// | lxd | file access | NO | YES | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | none | YES | YES | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | none | YES | YES | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| ubuntu-minimal | https://cloud-images.ubuntu.com/minimal/releases/ | simplestreams | none | YES | YES | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
| ubuntu-minimal-daily | https://cloud-images.ubuntu.com/minimal/daily/ | simplestreams | none | YES | YES | NO |
+----------------------+---------------------------------------------------+---------------+-------------+--------+--------+--------+
如果你不是最近安装的 LXD,那么 images
远程的地址是 https://images.lxd.canonical.com
。因为它不可访问了,我们下载不到任何模板,所以容器无法创建。
稍微有点想法的应该能明白怎么做,Ubuntu 需要再搭建一个的远程服务,将其它镜像都纳入这个中心仓库。在 4 月份,Ubuntu 公布了新的远程地址 https://images.lxd.canonical.com
,我们将 images
的地址更改为它即可。
修改命令:
lxc remote set-url images https://images.lxd.canonical.com
使用 lxc remote list
重新查看远程列表,确保地址已经更改成功。现在我们再次创建一个 images
下的容器测试:
lxc launch images:alpine/3.20 alpine-320
输出:
Creating alpine-320
Starting alpine-320
创建成功。
现在我们使用的是 Ubuntu 提供的镜像模板,而不再是 LXC 提供的。
差异
Ubuntu 的远程镜像列表和 LXC 的有一些差异。Ubuntu 少了一些版本,例如没有 Arch Linux 的 amd64 架构镜像,反而提供了一个 arm64 的镜像。还有 Void Linux 的 musl 和 glibc 没有区分,我测试发现只提供 glibc 的版本。
这两个镜像我都有所使用,严格来说对我有一些负面影响。不过考虑到这个服务搭建起来的时间不长,应该还有补全的空间。
结束语
LXC 和 Ubuntu 的分歧导致世界上多了一个镜像仓库,又多了一份精力去维护。这对整个大环境肯定是不好的。但 Ubuntu 确实有吸血的嫌疑,而且 LXC 社区更推荐 LXD 的替代品 Incus。
总之,这就是 LXD 最近发生的故事。以及修复方案。
订阅频道第一时间掌握作者博客的最新动态,获取更多的分享。