千家信息网

在tinycorelinux上如何安装containerd和openfaas

发表于:2026-11-02 作者:千家信息网编辑
千家信息网最后更新 2026年11月02日,这篇文章主要介绍在tinycorelinux上如何安装containerd和openfaas,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!容器化为什么这么重要,因为容器是现在最
千家信息网最后更新 2026年11月02日在tinycorelinux上如何安装containerd和openfaas

这篇文章主要介绍在tinycorelinux上如何安装containerd和openfaas,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!

容器化为什么这么重要,因为容器是现在最流行的原生virtual cloud appliance(cloud appliance化是app部署级别的融合,代表着"为云APP造一种包结构",k8s这些被称为云原生所以你可以将其简单理解为云原生软件包,cloud appliance要与app开发用的内部cloud appstack融合化区别开)代表,作为统一部署方案,它主要关注解决集群和云上那些"软件发行资源配额的隔离"问题,软件的资源配额从来都是一个复杂的关联问题,可巧这些问题在本地和原生的包管理软件中(包主要关注解决依赖问题)也存在,linux上提供了统一的整套内核级支持方案(比如liblxc,libcgroups,基于它们+brtfs可以完全用shell发明一套简单的docker运行时,当然这跟我们需要的,最终完备的容器和容器管理系统containerd,openfaas是没法比的),另一方面,"资源隔离"稍微更进一步,就很容易与"软件怎么样启动"这些问题相关联,变成systemd这类软件要解决的问题(systemd-nspawn可以创建最轻量级的容器),进而变成k8s这类软件要解决的问题。所以,这三大问题融合和关联发生在方方面面,,很容易成为某种"混合包管理和容器管理"融合体系要解决的中心问题,进而需要这样一种软件,core os的https://github.com/rkt/rkt就是这一类软件的代表并为此构建出一个基于容器作为包管理的OS(虽然2020年中期它们准备dreprecate了)。

这就是说,容器化的实现可以简单也可以复杂,不同OS也有集成不同复杂容器管理的方案,除了core os的rkt这种,tc的tce pkg本身就是一种沙盒环境,不过它与上述提到的lxc,ovz,containerd这些真正意义的容器化没有关系。前述与openfaas相关的这些文章都是在流行的linux发行版中实践装openfaas的例子,接下来的本文将介绍尝试在tinycorelinux11中装真正的容器,即containerd和openfaas的安装实践过程。

这里的主要问题是,tc本身是一种raw linux发行版,追求小和简单,一般地,跟alpine一样tc往往作为容器guest os如boot2docker,鲜少在tc上装containerd作为容器服务器环境,因此,在tc中装容器可能会因为没有现成参考方案而显得繁琐。比如,tc也没有使用systemd这类复杂的init启动管理系统而是简单的sysv init(虽然systemd提出了一个巨大的init pid 1,但是它只关注"启动",这点上,它还是符合kiss的)。一般linux发行都是依赖systemd处理容器设置的一些至关重要的基础问题,比如稍后我们会谈到systemd自动管理cgroups,,而这些在tc中都没有,需要手动还不见得能解决,

不管了,下面开始尝试实践,我们的测试环境是tc11。

1,制造一个containerd.tcz和faasd.tcz

准备一个集成了openssh,sudo passwd tc,做好了bootcode tce=sda1,echo过 /opt/tcemirror,/etc/passwd,/etc/shadow > /mnt/sda1/opt/.filetool.lst,tar 进restore=sda1 mydata.gz的基本ezremasterd tc11 iso,即《一个fully retryable的rootbuild packer脚本,从0打造matecloudos(2)》中第一小节那样的iso。我们开启二个引导了这个iso的虚拟机,都用parted格好sda1,这二虚拟机准备一个生成containerd.tcz和faasd.tcz用(生成后在其目录下python -m SimpleHTTPServer 80供以后下载,事先ifconfig看好ip),另一个测试生成的tcz(/opt/tcemirror设成第一台地址+11.x/x86_64/tcz正确的结构),在第一台虚拟机的/mnt/sda1根目录中,安排这些文件:

准备文件夹结构和binaries:docker采用前述文章的版本组合而成(做二文件夹一个containerd-root,其中cni放在/opt/cin/bin,runc放在/usr/local/sbin,containerd放在/usr/local/bin,一个faasd-root,其中放/usr/local/bin/faasd,faas-cli,最后,前文提到的几个offline docker image也集进来放在faasd-root/tmp/*.tar)。这些exe设好chmod +x,由于这些exe都是go的,都是静态链接的,在tc11上可直接运行(lib64一定要ln -s 一下到lib,否则ctr不能起作用)。准备几个配置文件:一些containerd和faasd启动时的动态文件,不用创建。否则会导致只读文件系统无法写入错误/etc/cni/net.d/10-openfaas.conflist/var/lib/faasd/secrets/*/var/lib/faasd/resolv.conf/var/lib/faasd-provider/resolv.conf这些文件必须要/var/lib/faasd/docker-compose.yaml/var/lib/faasd/prometheus.yml准备overlay module:在第一台中tce-load -iw bc compiletc perl5重新编译kernel,在config中把config_overy_fs打开为m,得到overlay module,因为它在tc11中被关闭了。下载tc11中所需的kernel编译文件http://mirrors.163.com/tinycorelinux/11.x/x86_64/release/src/kernel/到/mnt/sda1解压并cp config-5.4.3-tinycore64 linux-5.4.3/.configsudo make oldconfig,提示几个交互项直接回车sudo make installsudo make modules_install把得到的overlay module file(在/lib/modules/fs中)放到准备打包的containerd.tcz文件夹结构中。准备2个服务文件并分别chmod +x:containerd-root/usr/local/init.d/start-containerd:/sbin/modprobe overlay/usr/local/bin/containerdcontainerd-root/usr/local/init.d/start-faasd:for i in 1 2 3; do [[ ! -z "$(ctr image list|grep basic-auth-plugin)" ]] && break;ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/basic-auth-plugin-0.18.18.tar;echo "checking basic-auth ($i),if failed at 3,it may require a reboot"; sleep 3;done         for i in 1 2 3; do [[ ! -z "$(ctr image list|grep nats)" ]] && break;ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/nats-streaming-0.11.2.tar;echo "checking nats ($i),if failed at 3,it may require a reboot"; sleep 3;done                                for i in 1 2 3; do [[ ! -z "$(ctr image list|grep prometheus)" ]] && break;ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/prometheus-v2.14.0.tar;echo "checking prometheus ($i),if failed at 3,it may require a reboot"; sleep 3;done                       for i in 1 2 3; do [[ ! -z "$(ctr image list|grep gateway)" ]] && break;ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/gateway-0.18.18.tar;echo "checking gateway ($i),failed at 3,it may require a reboot"; sleep 3;done                                   for i in 1 2 3; do [[ ! -z "$(ctr image list|grep queue-worker)" ]] && break;ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/queue-worker-0.11.2.tar;echo "checking queueworker ($i),if failed at 3,it may require a reboot"; sleep 3;donecd /var/lib/faasd/usr/local/bin/faasd provider/usr/local/bin/faasd up准备mkall.sh放到/mnt/sda1根下chmod +x起来:mkall.sh的内容(注意到统一作为tc:staff存放到tcz中):rm -rf containerd.tcz containerd.tcz.md5.txt faasd.tcz faasd.tcz.md5.txt faasd.tczmksquashfs containerd-root containerd.tcz -noappend -no-fragments -force-uid tcmd5sum containerd.tcz > containerd.tcz.md5.txtmksquashfs faasd-root faasd.tcz -noappend -no-fragments -force-uid tc -force-gid staffmd5sum faasd.tcz > faasd.tcz.md5.txtecho containerd.tcz > faasd.tcz.dep

sudo ./mkall.sh打包好的tcz各80多m,准备好后我们就可以在第二台测试了,tce-load -iw faasd后经过测试不满意可删除/mnt/sda1/tce/optional下的tcz重启重来,我们需要不断mkall并测试生成的二个tcz。

2,测试

第一次测试启动start-containerd,start-faasd,出现:no cgroup mount found in mountinfo: unknown这就是上面谈到tc11不具有自动处理cgroups的逻辑。而containerd依赖它们。tc11中的kernel config中提供了linux对容器的内核支持基础,只是没有更进一步。

CGroup 提供了一个 CGroup 虚拟文件系统,作为进行分组管理和各子系统设置的用户接口。要使用 CGroup,必须挂载 CGroup 文件系统。这时通过挂载选项指定使用哪个子系统。 需要注意的是,在使用 systemd 系统的操作系统中,/sys/fs/cgroup 目录都是由 systemd 在系统启动的过程中挂载的,并且挂载为只读的类型。换句话说,系统是不建议我们在 /sys/fs/cgroup 目录下创建新的目录并挂载其它子系统的。这一点与之前的操作系统不太一样。

针对于此,很幸运我们找到了https://gitee.com/binave/tiny4containerd/blob/master/src/rootfs/usr/local/etc/init.d/cgroupfs.sh,它使用old docker,并且基于https://github.com/tianon/cgroupfs-mount/(这个工程https://gitee.com/binave/tiny4containerd/src/rootfs/usr/local/这里的lvm动态扩展分区脚本和docker服务,cert处理等函数也不错,可为未来所用),里面有几句。

mount -t tmpfs -o uid=0,gid=0,mode=0755 cgroup /sys/fs/cgroup如果你没有上面这句mount 接下来会mkdir: can't create directory 'cpu': No such file or directory,因为/sys/fs/cgroup只是内核给的fake fscd /sys/fs/cgroup;# get/mount list of enabled cgroup controllersfor sys in $(awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do    mkdir -p $sys    if ! _mountpoint -q $sys; then        if ! mount -n -t cgroup -o $sys cgroup $sys; then            rmdir $sys || true        fi    fidone

我们把cgroupfs放跟containerd-root/usr/local/etc/init.d/containerd并排,在containerd脚本中启动containerd前加入/usr/local/etc/init.d/cgroupfs.sh mount这句。打包再测试:出现jailing process inside rootfs caused: pivot_root invalid argument: unknown(我也一直没有测试https://gitee.com/binave/tiny4containerd/中的docker会不会出现这错误,不过听说有遇到了https://forums.docker.com/t/tinycore-8-0-x86-pivot-root-invalid-argument/32633),

In a system running entirely in memory, after an upgrade from 17.09.1-ce to 17.12.0-ce, docker stopped creating containers, failing with message like docker: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused "rootfs_linux.go:107: jailing process inside rootfs caused \"pivot_root invalid argument\""": unknown..

查网上说要使用DOCKER_RAMFS=true环变,我试了没用。

在其它非tc上相似的容器产品也有人遇到了:https://engineeringjobs4u.co.uk/how-we-use-hashicorp-nomad,针对于此它们做了一个内核补丁:https://lore.kernel.org/linux-fsdevel/20200305193511.28621-1-ignat@cloudflare.com/

The main need for this is to support container runtimes on stateless Linux system (pivot_root system call from initramfs). Normally, the task of initramfs is to mount and switch to a "real" root filesystem. However, on stateless systems (booting over the network) it is just convenient to have your "real" filesystem as initramfs from the start.

对linux543/fs/namespace.c进行手动patch,mnt_init()定义前增加,和中间增加新加的代码。但是没用。因此按《利用hashicorp packer把dbcolinux导出为虚拟机和docker格式(3)》的方法转为传统硬盘安装方式。问题解决。

然后又出现了: Error creating CNI for basic-auth-plugin: Failed to setup network for task "basic-auth-plugin-1210": failed to create bridge "openfaas0": could not add "openfaas0": operation not supported: failed to create bridge "openfaas0": could not add "openfaas0": operation not supported

这个问题其实在意料之中,因为从前面文章的经验来看,我们一直对containerd中的那个cni必须要起作用留了个心,可是faasd up产生了10openfaas.conflist后,我一直尝试ifconfig,都没看到第三个网卡。

网上有人提示说是CONFIG_BRIDGE_VLAN_FILTERING,看tc11的kernel,config_bridge被作为模块了,它的file应该是bridge.ko之类。但modprobe bridge没用,tce-load -iw original-modules-5.4.3-tinycore64,这下成功了。(安装了这个包之后,控制台显示好多设备都认到了)

再测试: Error: Failed to setup network for task "basic-auth-plugin-3894": failed to locate iptables: exec: "iptables": executable file not found in $PATH: failed to locate iptables: exec: "iptables": executable file not found in $PATH,需要tce-load -iw iptables,

至此,faad up启动成功。containerd控制台显示warning,memory cgroup not supported,应该是kernel config,又没设好。

以上是"在tinycorelinux上如何安装containerd和openfaas"这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注行业资讯频道!

容器 问题 文件 系统 准备 测试 软件 管理 复杂 内核 方案 目录 结构 发行 生成 代表 内容 子系统 就是 文件夹 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 互联网是第几次科技革命的成果 广州万易互联网科技有限公司 美国互联网科技巨头监管 极限挑战互联网科技 长亮科技互联网金融 互联网科技大会案例 互联网实体化科技化 成都玖崟互联网科技有限公司乐商圈怎么样 随着互联网科技发展 佳云科技和互联网广告 乌苏新华互联网科技做什么的 科技类公司包括互联网吗 工业互联网展湾科技股份有限公司 深圳互联网科技的发展 互联网营销推广黑科技 广州燕处互联网科技有限公司 互联网领先科技活动 互联网金融金融科技 互联网科技创业计划的风险分析 中国主要互联网科技公司 广西互联网科技公司 互联网科技论坛 科技伦理 互联网公司 互联网之后的科技是什么 互联网经济与金融科技 洛阳共同富裕互联网科技有限公司 四川互联网展示科技馆设计 萌小萌互联网科技河南有限公司 青岛互联网科技园 互联网科技企业文化
0