从源码构建容器
如果您打算在集装箱上做出贡献,则本指南很有用。谢谢你的
努力。每个贡献都非常感谢。
此文档包括:
- 使用github codepses
- 构建要求
- 构建开发环境
- 构建容器
- 通过docker容器
- 测试
GitHub CodeSpaces开始
要开始,请单击此👇创建此存储库的代码空间
在github codespases中打开
代码空间将在基于Web的Visual Studio代码中打开。 Dev Container完全配置了该项目和构建的容器所需的软件。如果使用代码空间,则可以直接跳到本文档的testing部分。
注意:开发容器是一个开放的规格,由github codespases和其他工具提供支持。
构建要求
要构建“ containerd”守护程序和“CTR”简单测试客户端,需要以下构建系统依赖项:
- GO 1.20.x或更高
- Protoc 3.x编译器和头文件(在Google Protobuf版本页面下载
- 相应发行版的Btrfs头文件和库。请注意,可以通过构建标志“no_btrfs”构建Btrfs驱动程序,从而禁用此依赖关系。
*注意 *:在MacOS上,您需要第三方运行时才能在containerd上运行容器
建立开发环境
首先,您需要设置GO开发环境。你可以按照此指南[如何编写GO代码](golang.org/doc/code.ht… 进行,最后
您的PATH
路径上就有了go
命令。
您需要“git”来检出源代码:
git clone https://github.com/containerd/containerd
为了获得准确的结果,请将ProtoC
版本安装到构建系统上的/usr/local
中。从.proto
文件生成源代码时,containerd可能依赖一些外部协议缓冲区文件。这些外部依赖应添加到/usr/local/include
目录下。要安装ProtoC
的适当版本,并在Linux机器上下载所有必要的外部协议缓冲区文件,请运行script/setup/install protobuf
中的安装脚本即可。
要启用可选Btrfs snapshotter,应该有Linux内核4.12或更高版本的头文件。对内核头文件的依赖性仅影响从源码建立容器的用户。
较旧内核的用户可能会选择不编译BTRFS支持(请参阅下面的buildTags=no_btrfs
),或提供新内核的头文件。
注意
在容器1.7.0-beta.4中引入了对Linux内核头文件4.12的依赖性。containerd 1.6具有启用BTRF的不同依赖项集。
containerd 1.6用户应参考github.com/containerd/…
一切就绪,现在我们开始自己构建containerd!
runc
runc是cansoterd
使用的默认容器运行时,运行containerd时需要它。虽然可以下载“ runc”二进制文件,有时有必要在使用时直接构建runc配合containerd的开发。确保遵循runc.md版本控制的指南以获得最佳结果。
*注意 *:RUNC仅支持Linux
构建containerd
contanserd
使用nake
创建可重复的构建流。这意味着你
能跑:
cd containerd
make
这将在./bin/
目录中构建所有项目二进制文件。
您可以把他们移动到/usr/local/bin
全局目录,执行以下脚本:
sudo make install
可以通过传递PREFIX
变量来更改安装前缀(默认
到/usr/local
)。
注意:如果设置其中一个VAR,请将它们为所有构建阶段(build和install)设置相同值。
在实际安装(例如打包或Chroot安装)如果想预先设置一个前缀
您可以通过DESTDIR
变量传递:
sudo make install destdir =/tmp/install-x973234/
上面的命令把containerd安装到/tmp/install-x973234/usr/local/bin/containerd
目录
containerd从v1.6开始支持destdir
约定。较旧的发行版的destdir
功能类似于PREFIX
。
对GRPC API进行任何更改时,您可以使用已安装的“ ProtoC”
编译器以以下方式重新生成API代码软件包
make generate
*注意 *:当前有几个构建标志:
no_cri
:构建标志不构建kubernetes cri。
有关CRI插件的构建标志,请参见此处。- 快照(字母顺序)
no_aufs
:构建标志不构建AUFS快照驱动程序。 (由于containerd v2.0不再支持AUFS快照驱动程序,因此忽略此标志。)no_btrfs
:构建标志不构建BTRFS快照驱动程序。no_devmapper
:构建标志不构建设备映射器快照驱动程序。no_zfs
:构建标志不构建ZFS快照驱动程序。- 平台
no_systemd
:禁用任何systemd的特定代码例如,在调用binaries Makefile之前,将
buildTags=no_btrfs
添加到您的环境中,go构建目标将不为Containerd构建BTRFS驱动程序。
外部导入的供应商使用GO模块。你需要
要使用go mod
命令来修改依赖项。修改后,您应该运行Go Mod Tidy
和go mod vendor
以确保go.mod
,go.sum
文件和`供应商目录是最新的。
这些文件的更改应成为依赖供应商更新的PR的单个提交。
请参阅runc.md,查看被当前Containerd 支持的runc
版本。
*注意 *:在MacOS上,可以在本地建造和运行容器守护程序。但是,如上所述,RUNC仅支持Linux。
静态二进制
您可以通过提供一些变量来构建静态二进制文件:
make STATIC=1
*注意 *:
- 不建议使用静态构建
- 静态容器二进制不支持加载共享对象插件(
*.so
)- 静态构建二进制不是与目录位置无关的
通过Docker容器构建
现在假定您在containerd源目录的父级目录。
在容器中构建containerd
您可以通过基于Linux的Docker容器来构建containerd
。
您可以从此Dockerfile
中构建图像:
FROM golang
假设您构建了一个称为containerd/build
的镜像。在containerd源根目录您可以运行以下命令:
docker run -it \
-v ${PWD}/containerd:/go/src/github.com/containerd/containerd \
-e GOPATH=/go \
-w /go/src/github.com/containerd/containerd containerd/build sh
这会挂载containerd源码目录
现在构建build:
make && make install
在容器中构建containerd和runc
要拥有完整的核心容器运行时,您将同时需要containerd
和runc
。可以通过Docker容器构建这两个。
您可以使用git
来检出runc
:
git clone https://github.com/opencontainers/runc
我们可以从此Dockerfile
构建镜像:
FROM golang
RUN apt-get update && \
apt-get install -y libseccomp-dev
在我们的Docker容器中,我们将构建Runc
构建,其中包括
seccomp,selinux,
和apparmor支持。 SECCOMP支持
在runc中,需要libseccomp-dev
作为依赖项(Apparmor和Selinux支持
在构建时间不需要外部库)。请参阅runc.md
在文档目录中以获取有关构建runc的详细信息,并了解容器使用的runc
的支持版本。
假设您从上面的dockerfile构建了一个称为containerd/build
的镜像。您可以运行以下命令:
docker run- it- privileged
-v /var/lib/containerd
-v $ {pwd}/runc:/go/src/github.com/opencontainers/runc
-v $ {pwd}/containerd:/go/src/github.com/containerd/containerd
-e gopath =/go
-w/go/src/github.com/containerd/containerd containerd/build sh
这将安装在我们的Docker容器中的runc
和containerd
存储库。
从我们的Docker容器中,让我们构建containerd
:
cd /go/src/github.com/containerd/containerd
make && make install
这些二进制文件可以在主机中的/bin
目录中找到。
make install
将在您的$PATH
中移动二进制文件。
接下来,让我们构建runc
:
cd/go/src/github.com/opencontainers/runc
make && make install
有关构建runc的更多详细信息,请参阅runc.md
文档目录。
使用我们刚刚构建的简单测试客户端Ctr
时,请不要忘记启动守护程序!
containerd -config config.toml
测试containerd
在自动化的CI期间,单元测试和集成测试是作为PR验证的一部分运行的。作为开发人员,您可以使用以下任何makefile
目标在本地运行这些测试:
make test
:运行所有不需要root
特权的非集成测试make root-test
:运行所有需要root
的非集成测试make Integration
:运行所有测试,包括集成测试和需要root
的测试。testflags_parallel
可用于控制并行性。例如,testflags_parallel = 1 Make Integration
将实现非并行执行。testflags_parallel
的默认值是8。make cri-Integration
:CRI集成测试
要执行特定的测试或一组测试,您可以使用“ GO Test”功能
不使用makefile
targes。以下示例显示了如何指定测试
名称,以及如何直接使用标志来针对“ GO Test”运行重新测试。
# 运行测试 <测试名称>:
go test -v -run "<TEST_NAME>" .
# 启用root用户测试:
go test -v -run . -test.root
直接运行“ GO Test”执行testContainerList
测试的例子输出如下:
sudo go test -v -run "TestContainerList" . -test.root
INFO[0000] running tests against containerd revision=f2ae8a020a985a8d9862c9eb5ab66902c2888361 version=v1.0.0-beta.2-49-gf2ae8a0
=== RUN TestContainerList
--- PASS: TestContainerList (0.00s)
PASS
ok github.com/containerd/containerd 4.778s
*注意 *:为了运行`sudo go',您需要
- 保持用户路径环境变量。例如:
sudo"PATH=$PATH" env go test <args>
- 或使用
go test -exec
ex:go test -exec sudo -v -run'testtarwithxattr'./archive/ -test.root
其他工具
cotainerd-stress
除了通过MakeFile
目标执行的基于GO test
测试外,还可以使用containerd-surn
工具,并使用ALL'或binaries
目标构建并在make install
中安装。
使用此工具,您可以在指定的一段时间内压测运行的容器守护程序,从而选择并发级别以产生压力针对守护程序。以下命令是一个示例,即在默认容器GRPC套接字地址中,有五名worker运行了两个小时:
containerd-stress -c 5 -d 120m
有关此工具选项的更多信息,请运行containerd-stress --help
。
Bucketbench
bucketbench是一种外部工具,可用于针对容器运行时驱动加载,指定特定的生命周期操作,以使用指定量的并发量运行。 Bucketbench更专注于生成绩效细节,而不是简单地诱使载荷侵害容器。
BucketBench与Containerd-surs
工具的不同方式不同:
- BucketBench支持测试Docker引擎,
runc
二进制文件和容器0.2.x(通过ctr
)和1.0(通过客户端库)分支。 - BucketBench是通过配置文件驱动的,该文件允许指定生命周期操作的列表。这可用于生成每个命令的详细统计信息(例如开始,停止,暂停,删除)。
- BucketBench在配置的测试运行结束时生成详细的报告和计时数据。
有关如何安装和运行“ BucketBench”的更多详细信息,请访问Github Project Page。