共计 10434 个字符，预计需要花费 27 分钟才能阅读完成。
本篇内容介绍了“怎么在 64 位 Ubuntu 中安装 Rkt”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
Rkt 的前世今生
作为一个年轻的应用容器新秀，开源的 Rkt 并不是一个人在战斗，在它的背后支撑的是一支俨然有序的庞大社区力量。
诞生背景
Rkt 项目最初的发起者是 CoreOS 公司。
CoreOS 公司与其核心产品 CoreOS 操作系统是实至名归的最早一批 Docker 企业级用户，伴随着 Docker 从最初的 0.1 版本一直走到正式发布的 1.0 版本。起初两者相互促进，合作甚好。然而，随着 Docker 在容器界一家独大的趋势越来越明显，其周边的生态逐渐的从单纯的围绕构建容器化应用服务，发展成了自上而下的集群规范体系，甚至部分取代了操作系统的服务进程调度工作。这种臃肿而受 Docker 单方面控制的容器规范，是 CoreOS 系统所不待见的，他们想要一个更加开放而中立的容器标准。
2014 年 12 月，CoreOS 公布了自己的容器计划，并在几个月后结合社区中的容器实践，着手制定新的开放应用容器规范，Rkt 则作为此规范中的一个具体实现而继续发展。
AppC 标准应用容器规范
AppC 的全称是“Application Container Specification（标准应用容器规范）”，这个规范的制定不是为了服务于特定的 Linux 系统环境，其初衷在于制定一组不依赖于具体平台、技术、操作系统和编程语言的容器虚拟化规范，解除已经初露端倪的企业容器产品互不兼容、各自封闭发展的危机，防止更多技术壁垒的产生。
正在制定中的 AppC 容器规范设计目标包括：
组件式工具：用于下载、部署和运行虚拟容器环境的操作工具应该相互独立、互不依赖且可被替换。
镜像安全性：镜像在因特网下载传输时应当使用加密协议，容器工具应当内置验证机制，以拒绝不安全来源的镜像。
操作去中心化：镜像分发应该支持可扩展的传输协议，未来允许引入 P2P，甚至 BitTorrent 协议来提升镜像分发效率，且容器使用前不应需要登录特定的镜像仓库。
开放性标准：容器镜像的格式与元数据定义应该由社区设立统一协商制定，使得符合这一规范的不同容器产品能够共享镜像文件。
为了确保规范的开放并兼顾多方利益，CoreOS 作为规范的倡导者、参与者和实施者，但并不会成为其唯一的制定者。
目前已经在遵循 AppC 的开源应用容器除了 Rkt，还有 FreeDBSD 平台的容器 Jet Pack 和 Linux 平台通过 C ++ 实现的容器 Nose Cone。更好的通用性，更小的入侵性，以及更高的开放性，正是由于这些 AppC 规范的独具匠心，使得它在 Docker 如日中天之时，恰逢其时的给业界带来一阵清风，引发许多技术玩家和企业的驻足和思考。
Rkt 容器使用尝鲜
且不论 AppC 的未来发展究竟会如何，远水不解近渴，既然 Rkt 容器本身是开源免费的，何不自己动手尝试一番。
作为开放式容器标准的样板项目，Rkt 自然不会只能用在 CoreOS 的自家系统里。与 Docker 相似，Rkt 虽然也被预装在了 CoreOS 系统中，但其他的任何 Linux 发行版都可以安装并使用它。在接下来的部分里，我们将以比较常见的 64 位 Ubuntu 系统为例，演示 Rkt 的安装和使用方法。
在 64 位 Ubuntu 中安装 Rkt
事实上，在任何 Intel 架构的 64 位 Linux 中，安装 Rkt 都简单到极致。这得益于 Golang 语言原生的静态编译方式，几乎所有编译过的 Golang 程序都可以下载即运行，而不需要安装额外依赖。
从 GitHub 网站可以直接下载到打包好的 Rkt 的二进制文件，目前最新的版本是 v0.5.4。Rkt 只提供了 64 位的编译版本，虽然通过自行编译源代码的方式也能够得到 32 位的可执行文件，但在 32 位系统上运行 Rkt 是不被官方推荐和支持的。
wget https://github.com/coreos/rkt/releases/download/v0.5.4/rkt-v0.5.4.tar.gz下载后得到一个压缩文件。然后，恩，解压它。
tar xzvf rkt-v0.5.4.tar.gz将解压后得到的文件统统放到系统的可执行目录里面，安装就算完成了。
sudo cp rkt-v0.5.4/* /usr/local/bin/接下来，试在命令行下执行不带任何参数的 rkt version 命令，可以看到程序返回了 Rkt 工具和 AppC 标准的版本信息，说明 Rkt 已经正确的安装了。
$ rkt version
rkt version 0.5.4
appc version 0.5.1+gitRkt 工具的组成
工欲善其事，必先利其器。在前面安装 Rkt 时，我们还没来得及多看一眼，就直接将解压后的文件一股脑儿丢进了系统目录里。这种部署方式虽然方便，但也实在简单粗暴。现在安装完了，至少还是得回头瞅瞅这个目录里到底提供了哪些东西。
不过，这一瞅简直让人失望，偌大一个压缩包，里面就这么俩文件。
$ ls rkt-v0.5.4
rkt stage1.aci第一个文件刚刚已经试过了，它是 Rkt 容器的主程序，所有操作容器的命令都会通过这个命令作为入口。而第二个文件是个非常巧妙的设计。首先它的 aci 后缀已经表明了它的身份，是一个标准的 AppC 镜像。如果将这个镜像解包就会看到里面包含的是一套完整的 systemd 运行环境，其实它的作用，是为 Rkt 提供了可替换的容器虚拟化实现组件。
Rkt 容器默认是采用基于 systemd-nspawn 命令的机制来处理与内核 cgroup 和 namespace 相关操作的，而这个部分正是提供整个容器虚拟化能力的核心环节。Rkt 通过将这部分的功能分离到一个可以快速外挂和替换的容器中，从而支持扩展其他的虚拟化实现方式（官方的举例是比如 novm 或 qemu-kvm），并能快速的在这些实现间切换使用。具体来说，只在运行容器时指定 –stage1-image 参数，设置成其他符合要求的虚拟化实现的镜像地址即可。
此外，AppC 规范还提供了一套用于制作和转换“符合 AppC 容器标准的”镜像的工具，这部分内容将会在系列的下篇中进行详述。
权限与镜像签名
在目前阶段的 Rkt 还必须通过 root 用户来执行大多数的命令，不过未来也计划支持如 Docker 那样使用普通用户运行。在运行 Rkt 命令时如果出现“permission denied”的错误，请检查是否忘记了 sudo。
使用 Docker 的用户，大多比较习惯在网上随便找到一个镜像地址，就直接 pull 下来使用。因此，即便 Docker 官方发现了一些恶意镜像的发布者，也无法有效的阻止这些镜像在网络的传播。
AppC 规范中，特别强调了镜像的安全性。为此，在默认情况下，所有镜像在下载和运行前，都必须明确的添加镜像发布者的签名信任，以确保镜像的来源不会被伪造。下面的命令将从官方仓库中获取前缀为“coreos.com/etcd”的签名信息，并添加到本地信任列表中。
$ sudo rkt trust --prefix coreos.com/etcd
Prefix: coreos.com/etcd
Key: https://coreos.com/dist/pubkeys/aci-pubkeys.gpg
GPG key fingerprint is: 8B86 DE38 890D DB72 9186 7B02 5210 BD88 8818 2190
CoreOS ACI Builder
Are you sure you want to trust this key (yes/no)? yes -- 输入 yes 回车
Trusting https://coreos.com/dist/pubkeys/aci-pubkeys.gpg for prefix coreos.com/etcd .
Added key for prefix coreos.com/etcd at /etc/rkt/trustedkeys/prefix.d/coreos.com/etcd/8b86de38890ddb7291867b025210bd8888182190在命令输出的最后一行，Rkt 显示了签名在本地保存的位置。查看文件的内容就会发现，这个签名实际上是一个标准的 GunPG 签名公钥。GunPG 是著名 RSA 非对称加密算法 PGP 的开源实现，关于 PGP 算法的介绍可以参考这篇百度百科。
$ cat /etc/rkt/trustedkeys/prefix.d/coreos.com/etcd/8b86de38890ddb7291867b025210bd8888182190
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1
mQINBFTCnMQBEAC/49bGbStCpa3peej+/42mobfuGbTcdmcGGwYZmigP0Kl0TPZK
... 省略部分输出 ...
fMkBtaM3knaFonHZc19BD1FOishRThCCq2Ty8HUoN2Fk7w0l
=bYl7
-----END PGP PUBLIC KEY BLOCK-----获取远程镜像
通过 rkt fetch 命令可以获取远程的镜像，和 Docker 的 pull 命令类似。下面这个命令会从 CoreOS 的 GitHub 仓库中下载预装了 Etcd 的示例容器。
$ sudo rkt fetch coreos.com/etcd:v2.0.9
rkt: searching for app image coreos.com/etcd:v2.0.9
rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
Downloading signature from https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci.asc
Downloading ACI: [=============================================] 3.79 MB/3.79 MB
rkt: signature verified:
CoreOS ACI Builder
sha512-91e98d7f1679a097c878203c9659f2a2值得一提的是，如果用户在上一步中没有添加签名信任，则镜像在下载完成后会由于无法正确的验证来源，而被直接丢弃（不会进入 Rkt 的本地仓库）。并提示镜像没有签名，或镜像的签名没有被信任。
$ sudo rkt fetch coreos.com/etcd:v2.0.9
Downloading ACI: [=============================================] 3.79 MB/3.79 MB
openpgp: signature made by unknown entity有的时候，用户确实希望下载或导入一个没有签名认证的镜像。可以明确的使用 –insecure-skip-verify 参数来告诉 Rkt 不要验证镜像的来源。
$ sudo rkt --insecure-skip-verify fetch coreos.com/etcd:v2.0.9
rkt: searching for app image coreos.com/etcd:v2.0.9
rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
Downloading ACI: [=============================================] 3.79 MB/3.79 MB
sha512-91e98d7f1679a097c878203c9659f2a2下载完成的镜像会被存储在本地的 /var/lib/rkt/cas/blob/sha512/ 仓库目录中，具体的命名规则是将镜像 SHA512 哈希值的前两位作为目录名，并以完成的 SHA512 哈希值作为镜像的文件名。例如刚刚下载的 Etcd 镜像哈希值为：sha512-91e98d7f1679a097c878203c9659f2a2，它存储的路径如下：
$ tree /var/lib/rkt/cas/blob/sha512/
/var/lib/rkt/cas/blob/sha512/
└── 91
└── sha512-91e98d7f1679a097c878203c9659f2a26ae394656b3147963324c61fa3832f15目前 Rkt 还没有提供一个命令能够快速列出本地仓库里所有镜像名字的方法。这看起来是一个比较匪夷所思的缺失功能。
运行容器
运行 Rkt 容器的命令是 rkt run，可以通过几种方式指定容器使用的镜像。
最常用，也是最方便的方法是使用标准的镜像的命名。比如例子中的 coreos.com/etcd:v2.0.9 名称：
$ sudo rkt run coreos.com/etcd:v2.0.9
rkt: searching for app image coreos.com/etcd:v2.0.9
rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
Press ^] three times to kill container也可以直接使用镜像的哈希值指定：
$ sudo rkt run sha512-91e98d7f1679a097c878203c9659f2a26ae394656b3147963324c61fa3832f15
Press ^] three times to kill container或者直接指定镜像文件的完整地址，这个地址可以是本地文件，也可以是网络文件，比如这样：
$ sudo rkt run https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
Press ^] three times to kill container使用时可以根据具体情况，哪种方便就用哪种。容器启动后就会自动运行镜像制作时指定的入口程序，连续按 Ctrl+] 组合键 3 次则会退出当前容器。
通过 –help 参数可以显示 rkt run 命令的可用选项。
$ sudo rkt run --help
Usage:
-inherit-env=false: inherit all environment variables not set by apps
-interactive=false: run pod interactively
-local=false: use only local images (do not discover or download from remote URLs)
-no-overlay=false: disable overlay filesystem
-pod-manifest= : the path to the pod manifest. If it s non-empty, then only --private-net , --no-overlay and --interactive will have effects
-port=: ports to expose on the host (requires --private-net)
-private-net=false: give pod a private network
-set-env=: an environment variable to set for apps in the form name=value
-signature=: local signature file to use in validating the preceding image
-stage1-image= /usr/local/bin/stage1.aci : image to use as stage1. Local paths and http/https URLs are supported. If empty, rkt will look for a file called stage1.aci in the same directory as rkt itself
-volume=: volumes to mount into the pod比较常用的选项有：
–volume 外挂分区，类似于 Docker 的 - v 参数
–port 暴露容器中的端口，类似于 Docker 的 - p 参数
–interactive 启用交互模式，类似于 Docker 的 - i 加上 - t 参数的效果
–set-env 向容器里添加环境变量，类似于 Docker 的 - e 参数
对于经常在使用 Docker 的用户，有两点值得注意的 Rkt 与 Docker 运行镜像时不同的地方：
目前还没有与 Docker 的 - d 参数相当的运行选项，要后台运行镜像先将就用 nohup 和 吧。
在任意容器中连续按 Ctrl+] 组合键 3 次，都会结束当前容器，不论是否启用了交互模式。
导入本地镜像文件
Rkt 导入本地镜像的命令和下载远程镜像是一样的，同样使用 rkt fetch。需要留意的是，即便是导入本地镜像，Rkt 仍然会强制验证签名（除非指定 –insecure-skip-verify 参数）。
$ wget https://github.com/coreos/etcd/releases/download/v2.0.9/etcd-v2.0.9-linux-amd64.aci
aving to: ‘etcd-v2.0.9-linux-amd64.aci’100%[=================================] 3,788,138 1.00MB/s in 5.1s‘etcd-v2.0.9-linux-amd64.aci’ saved [3788138/3788138]
$ sudo rkt run etcd-v2.0.9-linux-amd64.aci
error opening signature file: open /home/ubuntu/etcd-v2.0.9-linux-amd64.aci.asc: no such file or directory默认的签名文件应该和镜像在同一目录下，并且文件名应为镜像名加后缀.asc。如果签名文件的位置或名字与此规范不符，则可以用 –signature 指定。例如：
sudo rkt run image.aci --signature sign.asc下载 Docker 仓库的镜像
Rkt 支持直接下载 Docker 镜像，并自动转换为 AppC 镜像。这一设计在 Docker 基础资源如此丰富的当下，真的是很贴心。操作起来也非常简单，只需要在 Docker 的标准镜像路径前面加上 docker:// 前缀即可。
不过，颇具讽刺意味的是，由于 Docker 镜像本来是没有签名验证机制的，因此下载任何 Docker 镜像时，都必须使用 –insecure-skip-verify 参数。仿佛时刻在提醒用户：这个镜像可能是不安全的！
例如，下载 Docker 官方仓库的 CentOS 镜像：
$ sudo rkt --insecure-skip-verify fetch docker://centos
rkt: fetching image from docker://centos
Downloading layer: 6941bfcbbfca7f4f48becd38f2639157042b5cf9ab8c080f1d8b6d047380ecfc
Downloading layer: 41459f052977938b824dd011e1f2bec2cb4d133dfc7e1aa0e90f7c5d337ca9c4
Downloading layer: fd44297e2ddb050ec4fa9752b7a4e3a8439061991886e2091e7c1f007c906d75
sha512-94b712e21c2f88aebcbe67b7e97911c9直接通过哈希值试运行容器，注意加上 –interactive 选项：
$ sudo rkt run --interactive sha512-94b712e21c2f88aebcbe67b7e97911c9ed3be062f976cefcebed8baab826ed32
[root@rkt-0ff47941-3934-4dcd-9b9d-3db558f62cd9 /]#同样的，按三下 Ctrl+] 则会退出容器。
对于需要登录的 Docker 仓库，Rkt 也提供了下载镜像的解决办法。首先需要在 /etc/rkt/auth.d/ 目录下添加一个用户名命名的配置文件。
$ sudo cat /etc/rkt/auth.d/myuser.json
rktKind : dockerAuth ,
rktVersion : v1 ,
registries : [quay.io],
credentials : {
user : myuser ,
password : sekr3tstuff
}
}然后就可以执行 fetch 了。很方便有木有。
$ sudo rkt --insecure-skip-verify fetch docker://quay.io/myuser/privateapp
rkt: fetching image from docker://quay.io/myuser/privateapp
Downloading layer: cf2616975b4a3cba083ca99bc3f0bf25f5f528c3c52be1596b30f60b0b1c37ff
Downloading layer: 6ce2e90b0bc7224de3db1f0d646fe8e2c4dd37f1793928287f6074bc451a57ea
....更多功能
通过 rkt help 命令可以查看到 Rkt 的更多操作和参数，其中的一些功能还在开发中，具体的进度可以查阅官方文档。
$ rkt help
COMMANDS:
enter Enter the namespaces of an app within a rkt pod
fetch Fetch image(s) and store them in the local cache
gc Garbage-collect rkt pods no longer in use
help Show a list of commands or help for one command
install Set up rkt data directories with correct permissions
list List pods
metadata-service Run metadata service
prepare Prepare to run image(s) in a pod in rkt
run Run image(s) in a pod in rkt
run-prepared Run a prepared application pod in rkt
status Check the status of a rkt pod
trust Trust a key for image verification
version Print the version and exit
GLOBAL OPTIONS:
--debug=false Print out more debug information to stderr
--dir=/var/lib/rkt rkt data directory
--help=false Print usage information and exit
--insecure-skip-verify=false skip image or key verification
--local-config=/etc/rkt local configuration directory
--system-config=/usr/lib/rkt system configuration directory“怎么在 64 位 Ubuntu 中安装 Rkt”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
