CoreOS Rkt容器镜像怎么制作

共计 10195 个字符，预计需要花费 26 分钟才能阅读完成。

这篇文章主要介绍“CoreOS Rkt 容器镜像怎么制作”，在日常操作中，相信很多人在 CoreOS Rkt 容器镜像怎么制作问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”CoreOS Rkt 容器镜像怎么制作”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

AppC 规范究竟约定了什么

使用了开源软件的人，未必都会有心情仔细阅读各种开源协议的内容。大多数的使用容器产品用户，也不见得要对容器规范的内容有很高的兴致。

不过，为了更好的理解后面将要介绍到的相关工具，还是不妨稍微深入的了解一些 AppC 规范约定的内容。其内容归纳起来主要有四个方面，下面依次罗列出来，并与当下的主流容器 Docker 做一个简要的对比。

PS：严格来说，AppC 与 AppC Spec 两个词是有区别的。前者指的是 CoreOS 的 App Container 这个项目，包括规范和相关的工具，而后者特指 AppC 中约定的容器规范。但在许多地方，特别是翻译的文章中，经常看到这两个词被混用，因此一般也不必太讲究了。

1. 容器的镜像格式

本质上说，容器镜像就是符合特定目录结构的文件压缩包。镜像中的内容在容器启动后被展开，然后复制到一个独立的 namespace 空间内，并通过 cgroup 限制容器能够使用的系统资源。稍后在制作镜像时，会详细介绍 AppC Spec 规定的镜像目录结构。这里只先指出一点，AppC 的镜像没有支持像 Docker 那样的分层结构，这种设计简化了容器运行时的一些操作，但带来的弊端也是很明显的：无法复用镜像相同的部分。因此在磁盘空间的利用上造成了浪费，也增加了容器镜像在网络传输成本。

除了目录的结构，镜像还需要一个描述镜像内容的文件，称为“镜像属性清单文件（Image Manifest）”，其中定义的内容包括：镜像的作者信息、容器暴露的端口、暴露的挂载点、所需的系统资源（CPU/ 内存）等。此外，AppC Spec 的约定的属性清单中，还会包含许多编排调度所需的信息，例如容器运行所依赖的其他容器、容器的标签。

在这方面来说，AppC 镜像的信息量远远多于 Docker 镜像。相当于囊括了 Docker 镜像本身、Compose 编排配置以及一部分 Docker 运行参数的内容。

此外，AppC 规范也约定的镜像 ID 和签名的生成方法，关于镜像 ID 和签名的作用和在 Rkt 文章上篇中已经介绍过，稍后还会详细介绍镜像签名的生成方法。

2. 镜像的分发协议

分发协议主要是约定镜像下载使用的协议类型和 URL 的样式。AppC 的镜像 URL 采用类似 Docker 的 domain.com/image-name 这样的格式，但其实际处理方式有些不同。此外，在没有指定域名时，Docker 会默认在官方的 DockerHub 寻找镜像，AppC 的镜像没有所谓“官方源”，因此也没有这样的规则。

Rkt/AppC 目前支持以下几种 URL 格式：

域名 / 镜像名

本地文件路径

https:// 完整网络路径

http:// 完整网络路径

docker:// 与 Docker 一样的镜像 URL

第一种方式是 AppC 推荐的镜像分发 URL，这种方式有点像 Docker Repository，但实际上只是 HTTPS 协议的简写方式。AppC 会根据指导的域名和路径依照约定的方式转换为完整 URL 地址，然后下载指定的镜像。

第二种方式相当于导入本地镜像。值得一提的是，即便使用本地镜像，AppC 同样要求镜像有签名认证，关于签名文件的细节在后面的内容里会详细讨论。

第三种和第四种方式都是直接通过完整 URL 获取镜像，规范中并不推荐直接这样使用裸的 HTTPS 的 URL，因为这种命名过于随意的镜像地址不利于镜像的管理和统一，特别是 HTTP 协议的 URL 更只应该在内网的环境中出现。

第五种方式不是 AppC 规范支持的协议类型，目前只是 Rkt 支持这种协议（本质上还是 HTTP 或 HTTPS）。兼容 Docker 镜像的 URL，只需要在前面加上 docker:// 即可，下载后会自动转换为 AppC 镜像格式。由于 Docker 的镜像仓库不支持签名认证，使用这种 URL 时，用户需要显示的加上参数 –insecure-skip-verify 允许使用未认证的镜像来源。

3. 容器的编排结构

AppC 规范中的容器编排和集群描述方式与 Kubernetes 十分相似，采用“容器组属性清单文件（Pod Manifest）”描述。其中沿用了 Kubernetes 中诸如 Pods、labels 等用于在集群中进行调度策略的规划和管理的概念。

Pods 直译便是“豆荚”，它指的是由一系列相互关联的容器组成的，能够对外提供独立服务功能的容器集合。例如将用于数据收集功能的容器、用于缓存服务的容器以及用于搜索服务的容器组合在一起，作为一个 Pod 提供完整的数据查询服务暴露给外部用户。Pod 可以作为容器参与集群调度的单独集合提供给集群管理器，在例如 Kubernetes 这样的集群管理模型中，Pod 实际上就是进行服务跨节点调度的最小单位。

labels 用于标示具有同一类特性的容器，为容器的过滤和选择提供了十分灵活的策略。许多的集群管理器都能够在调度时利用选择指定标签对 Pods 进行筛选。

考虑到 CoreOS 公司与谷歌共同合作的背景（已经推出了 Tectonic CaaS 平台），这样的设计为 Kubernetes 未来与符合 AppC 规范的容器进行深度集成提供了良好的技术基础。

4. 容器的执行器

执行器，也就像是 Rkt 这样的容器工具。这个部分规范了设计符合 AppC Spec 的容器执行器所需要遵循的原则和应该具备的功能。

例如，必须为每个容器提供唯一的 UUID；在容器的运行上下文中必须至少提供一个本地 Loopback 网卡，以及 0 个至多个其他 TCP/IP 网卡；应该将容器中程序打印到 Stdout 和 Stderr 的日志进行收集和展示等细节。

其中还详细约定了，对于镜像属性清单中的诸多属性，执行器应当如何进行处理。这些内容对大部分的使用者而言都只能作为参考，还是需要以具体实现的容器产品文档为准。

镜像工具

在 AppC 的项目中，除了一纸洋洋洒洒的规范文书以外，还提供了不少 AppC 镜像相关的示范工具。不像 Docker 这种一个命令集成所有功能的玩法，这些工具中的每个只是关注于容器的某个方面功能。例如通用类型镜像的制作、打包、格式转换以及特定类型镜像的制作等。

目前已有的工具主要包括：

Actool – 用于镜像的构建和验证

Docker2Aci – 用于将 Docker 导出的镜像转换为 AppC 镜像

Goaci – 用于 Golang 语言的项目一键打包和构建镜像的工具

Acbuild – 通过指令的方式构建镜像

其中，Actool 和 Acbuild 都是用于镜像构建的工具，它们的区别类似于通过 docker commit 和 Dockerfile 两种方式构建镜像。需要指出的是，前不久才刚刚建立的 Acbuild 项目，现在还只是一个计划，没有发布任何实际可用的版本，其目的是替代之前的另一个项目 baci。后者已经无法使用并且不再继续更新。

Goaci 的作用是获取指定路径的项目，进行自动编译，然后把编译后的可执行程序制作成一个镜像，所有的这些操作只需要一条命令就可以完成：goaci 项目路径，项目路径支持所有 go get 命令所支持的代码托管网站，包括 BitBucket、GitHub、Google Code 和 Launchpad 等。不过，它只能用于使用 Golang 语言并托管在上述网站中的开源项目。不具有普遍的适用性。

下面将重点介绍 Actool 和 Docker2Aci 这两个工具。为了方便非 CoreOS 系统用户尝鲜，也会介绍在这些工具在其他 64 位 Linux 发行版的安装方法。

镜像的制作

与镜像制作相关的工具是 Actool，这个软件已经预装在 CoreOS 系统较新的版本上了，可以通过 actool –help 命令验证并获得 Actool 的版本。其他 64 位 Linux 的用户可以通过下面的命令安装它：

wget https://github.com/AppC/spec/releases/download/v0.5.2/AppC-v0.5.2.tar.gz
tar zxf AppC-v0.5.2.tar.gz
sudo mv AppC-v0.5.2/actool /usr/local/bin/

说到构建镜像，前面已经提到，新的命令式构建镜像的工具 Acbuild 目前还没有发布任何可用版本。因此当下的情况是，构建 AppC 镜像还只能手工创建镜像属性清单文件，拷贝容器中所需的文件，然后直接打包生成镜像。索性，这样创建镜像除了失去诸如“基础设施即代码”的好处以外，并没有多少值得非议的地方，构建流程本身并不复杂。

下面来制作一个十分朴素的 AppC 容器镜像，这个镜像中只包含一个可执行文件。

首先新建一个用于制作镜像的工作目录，例如 AppC-image：

mkdir AppC-image

接下来，为了让这个例子足够简单，我们需要一个能够不依赖任何外部动态库或运行时环境，能够单独运行的程序。我们写一个 C 语言的“Hello World”吧。新建一个叫 hello.c 的文件，内容如下：

#include  stdio.h 
int main(int argc, char* argv[])
 printf( Hello AppC\n  // 随便输出点什么东西
 return 0;
}

然后，需要一个 C 语言编译器，有些 Linux 系统已经自带了这个东西，用 gcc –version 命令可以验证。如果没有安装，那么 … 大家看着办吧，比如在 Ubuntu 系统下面可以通过 apt-get 来获取：

sudo apt-get install gcc

CoreOS 系统会稍微麻烦一点，需要借助一个额外的容器来完成。提示一下，Docker 有一个官方的 C /C++ 语言运行环境镜像，就叫 gcc。可以 docker pull gcc 或者 rkt –insecure-skip-verify fetch docker://gcc 来获取它，然后启动一个容器，注意需要映射一个 Volumn 到主机上，方便编译完成后将生成的可执行程序拷贝出来。

编译的命令如下，其中的 –static 参数是必须的，否则编译出来的程序在执行时会需要依赖外部的动态库：

gcc --static -o hello hello.c

在刚刚工作目录里面新建一个叫 rootfs 的目录，将编译生成的 hello 可执行文件拷贝进去。这个 rootfs 目录中的内容就是以后容器里所包含的文件内容了，因此建议在其中再建立一些标准的目录结构，例如 /bin 目录，将可执行程序放到这个目录里面。

mkdir -p AppC-image/rootfs/bin
cp hello AppC-image/rootfs/bin/

现在镜像的目录结构已经成型了。下面就可以开始创建镜像的属性清单文件了，在工作目录中新建一个名为 manifest 的文件，内容如下：

{
  acKind :  ImageManifest ,
  acVersion :  0.5.2 ,
  name :  my-app ,
  labels : [ { name :  os ,  value :  linux},
 {name :  arch ,  value :  amd64}
 ],
  app : {
  exec : [
  /bin/hello 
 ],
  user :  0 ,
  group :  0 
 }
}

此时，工作目录里的文件结构应该是这样的：

AppC-image
├── manifest
└── rootfs
 └── bin
 └── hello

最后就可以用 actool 命令构建镜像了：

actool build AppC-image hello.aci

镜像的验证

容器镜像的来源无非有两种：本地的或者远程的。

因此对镜像的验证也就包含两部分内容。

检验本地的文件是否符合 AppC 规范的镜像

检验远程的 URL 是否是有效的 AppC 镜像地址

对于前一种情况，前面说过，容器镜像其实就是符合一定标准结构的打包文件。

$ file hello.aci
hello.aci: gzip compressed data

在 AppC 规范中，镜像文件的后缀名应该是.aci，但具有这个后缀名的打包文件未必就是正确的镜像。因此需要一个方法来验证镜像文件的正确性，相应的命令是 actool validate。

直接执行这个命令时，actool 只会通过命令的返回值表示验证的结果，返回 0 表示验证通过：

$ actool validate hello.aci
$ echo $?
0

可以加上 -debug 参数让 actool 直接将结果打印在控制台上：

$ actool -debug validate hello.aci
hello.aci: valid app container image

对于后一种情况，URL 的验证，同样可以通过 actool 工具完成，相应的命令是 actool discover。

这个命令会返回镜像的实际下载地址：

$ actool discover coreos.com/etcd
ACI: https://github.com/coreos/etcd/releases/download/latest/etcd
-latest-linux-amd64.aci, ASC: https://github.com/coreos/etcd
/releases/download/latest/etcd-latest-linux-amd64.aci.asc
Keys: https://coreos.com/dist/pubkeys/aci-pubkeys.gpg

试一下在 Rkt 里面用过的 Docker 镜像地址，会发现这个地址是无效的。

$ actool discover docker://ubuntu
error fetching docker://ubuntu: Get https://docker?ac-discovery=1: 
dial tcp: lookup docker: no such host

这也证实了在前面说的，docker:// 这种协议只是 Rkt 额外支持的镜像获取方式，并不是 AppC 的规范中的标准协议。

镜像的转换

AppC 的规范制定者们显然很清楚，哪些轮子该重造，哪些轮子是可以直接复用的。在 Docker 的各种镜像已然是铺天盖地的当下，一个新的容器工具想要最快积累镜像数量，最好的办法就是兼容 Docker 镜像或者将 Docker 的镜像进行转换。

其实对于镜像兼容这个问题，新标准们有各自不同的做法，红帽的 Nulecule 选择了支持 Dockerfile 格式，只需要把已有的镜像代码加上一些额外的配置文件，重新构建一次就可以。而 AppC 做过同样的尝试，（之前有个 baci 项目就是干这个的，不过已经没有更新了），效果上有些不伦不类，因此索性更干脆，提供个工具允许将任何的 Docker 镜像导出后直接转换成自己的镜像格式。

下面就来说说从 Docker 到 AppC 镜像的转换，相应的工具是 Docker2Aci。

这个工具不论是在 Ubuntu 或者 CoreOS 上都没有预装，因此需要单独安装。这个工具还没有正式发布，因此官方也没有提供编译好的二进制包，要获得它只能从源代码编译。值得庆幸的是，Golang 语言的编译方式还是比较友好的，如果本地已经安装了 Golang 语言的开发环境，可以直接通过 go get github.com/AppC/docker2aci 命令完成整个下载和编译的过程。

考虑到大多数用户都是没有 Golang 开发环境的，另一个比较简单的办法是：通过容器。因为，Docker 官方已经提供了一个用于 Golang 开发的容器镜像，名字就叫 golang。用下面一条命令就可以搞定编译。

sudo docker run -v $(pwd):/pkg -i -t golang:1.4 /bin/bash -c  go 
get github.com/AppC/docker2aci; cp \$GOPATH/bin/docker2aci /pkg/

编译好的 docker2aci 二进制文件会被拷贝到当前目录，将它放到系统变量 PATH 所指的的任意目录中即可，比如：

sudo mv docker2aci /usr/local/bin/

执行 docker2aci –version 命令可以打印出软件的使用帮助，证明已经成功安装。

$ docker2aci
Usage of docker2aci:
docker2aci [--debug] [--nosquash] IMAGE
 Where IMAGE is
 [--image=IMAGE_NAME[:TAG]] FILEPATH
 or
 docker://[REGISTRYURL/]IMAGE_NAME[:TAG]
Flags:
 -debug=false: Enables debug messages
 -image= : When converting a local file, it selects a particular image to convert. Format: IMAGE_NAME[:TAG]
 -nosquash=false: Don t squash layers and output every layer as ACI

将一个 Docker 镜像导出，然后可以通过 docker2aci 命令转换成 AppC 镜像。

$ docker pull ubuntu
$ docker save -o ubuntu.docker ubuntu
$ ./docker2aci ubuntu.docker
... ...
Generated ACI(s):
ubuntu-latest.aci

转换后的镜像会保存在当前目录，并自动用“镜像 – 标签”的格式命名。

此外，比较实用的是，docker2aci 同样支持 docker:// 协议的 URL 直接获取网上的镜像。

$ docker2aci docker://busybox
... ...
Generated ACI(s):
busybox-latest.aci

镜像的签名

这个时候，如果直接用 Rkt 运行刚刚创建的 hello.aci 镜像，会发现 Rkt 提示由于找不到有效的签名文件，因此拒绝运行这个镜像。

$ sudo rkt run hello.aci
error opening signature file: open /home/core/hello.aci.asc: no such file or directory

镜像的签名，是 AppC 引入的一种镜像来源验证机制，本质上是利用非对称加密的标准数字签名。通过将镜像提供者的私钥和镜像文件本身加密生产一组签名字符串，通过发布者提供的公钥就能够解开这串字符并得到与镜像匹配的信息，这样就能验证镜像是否是真的来自特定的作者或来源。

AppC 的签名算法是标准是 RSA，采用的是开源的 GPG 实现，关于 GPG 的详细介绍参考这篇文章。

首先准备一个密钥配置文件，命名为 gpg-batch，内容如下：

%echo Generating a default key
Key-Type: RSA 
Key-Length: 2048
Subkey-Type: RSA 
Subkey-Length: 2048
Name-Real:  你的英文名字
Name-Email:  你的邮箱地址
Name-Comment: ACI signing key
Expire-Date: 0
Passphrase:  签名时的密码
%pubring rkt.pub
%secring rkt.sec
%commit
%echo done

然后用下面的命令生成一个密钥对：

gpg --batch --gen-key gpg-batch

执行完成后，在目录中会多出 rkt.sec 和 rkt.pub 两个文件，这就是私钥和公钥了。

然后就可以使用这对密钥给镜像签名了：

gpg --no-default-keyring --armor --secret-keyring ./rkt.sec 
--keyring ./rkt.pub --output hello.aci.asc --detach-sig hello.aci

在提示输入密码时，输入在 gpg-batch 中设置的密码。然后就获得了 hello.aci 镜像的签名文件 hello.aci.asc。

再次尝试运行容器：

$ sudo rkt run hello.aci
openpgp: signature made by unknown entity

这次提示的错误是，签名文件虽然找到了，但是这个签名的来源并没有在信任列表中。为了将签名添加到信任里面里面，首先要用 rkt.sec 和 rkt.pub 这两个二进制的密钥文件导出为一个文本的公钥文件。

gpg --no-default-keyring --armor --secret-keyring ./rkt.sec 
--keyring ./rkt.pub --export  在 gpg-batch 中的邮箱    pubkeys.gpg

然后将这个文本文件中的公钥添加到 Rkt 的信任列表中。

$ sudo rkt trust --root pubkeys.gpg
Prefix:  
Key:  pubkeys.gpg 
GPG key fingerprint is: 37E2 6071 5382 5868 5A0D 1356 98A9 5E24 6E19 7AED
 Subkey fingerprint: 46AF 81E4 77D4 BFCA DFCE 73C6 3D94 79C2 2611 F243
 Kelsey Hightower (ACI signing key) 
Are you sure you want to trust this key (yes/no)? yes
Trusting  pubkeys.gpg  for prefix  .
Added root key at  /etc/rkt/trustedkeys/root.d/37e26071538258685a0d135698a95e246e197aed

这次运行容器，就可以看到容器中的 Hello 程序已经正确的执行了。

$ sudo rkt run hello.aci
rkt: signature verified:
 Kelsey Hightower (ACI signing key)  kelsey.hightower@coreos.com 
Hello AppC

镜像的仓库

最后简单的介绍一下 AppC 的镜像仓库（Image Repository）。

AppC 规范定义了获取镜像的 URL，其形式大致是域名 / 镜像路径: 版本，例如 CoreOS 提供的包含 Etcd 的镜像可以通过命令 rkt fetch coreos.com/etcd:v2.0.9 来获取。

这里只说两个比较有意思的地方。

首先，AppC 是没有所谓“官方镜像仓库”的，所以 URL 中的域名部分始终会存在。由 CoreOS 公司提供的镜像被放在 coreos.com 域名下的普通仓库中。这一点也符合 AppC 标准开放化的初衷。

其次，AppC 会对用户的 URL 尝试通过两种方式解析。换句话说，镜像仓库的实现方式可以有两种。第一种几乎不需要额外的配置工作，将镜像依照一定的命名规则放在域名的相应路径下即可，例如 coreos.com/etcd:v2.0.9，如果使用第一种方式建仓库，相应的镜像就应该保存在 https://coreos.com/etcd-v2.0.9-linux-amd64.aci（当然，CoreOS 的镜像实际上是用的第二种方式，所以这个路径不存在）。第二种方式更加灵活，但需要额外的程序来处理镜像地址的映射，具体过程，不再详述。

此外，前面介绍过，对于内网环境，还可以直接使用 HTTP 路径获取镜像。举个栗子，把之前制作好的镜像文件 hello.aci 和签名文件 hello.aci.asc 放到一个目录里面，然后在这个目录中启动一个简易的 HTTP 服务：

$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

在任意另一个主机上就可以直接使用 HTTP 全路径下载镜像了。

$ sudo rkt fetch http:// 服务器 IP :8000/hello.aci
... ...
Downloading ACI: [ ] 1.26 KB/358 KB
sha512-f7a2feff02a07ed7c604c14133b7aede

这种简单粗暴到无以复加的方式，对于懒人们也许算得上是一种福利，然而不论是从安全性还是镜像版本的可管理性上看来，其能力都相当弱。这从一个侧面说明，一些为开发者们提供的便利通道，如果没有规范的约束，可能带来很大的隐患。在实际运用时，建议遵循 AppC 的 URL 解析规范设计仓库为上策。

到此，关于“CoreOS Rkt 容器镜像怎么制作”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！