rkt入门

今年2月，CoreOS宣布其rkt容器运行时已升级到1.0版 。 rkt自2014年12月首次发布以来已经走了很长一段路，所以现在是时候仔细研究一下并考虑它如何适应快速变化的容器生态系统。

本文适用于rkt的新手，但对Linux容器（ 例如 Docker）有一定的经验。 在整个这篇文章中，我假设您在Linux上将rkt与systemd一起使用。

你将学习：

• 历史和背景
• 如何使用acbuild构建ACI映像以与rkt一起运行
• 使用rkt和systemd启动和停止容器
• 与Docker的注册表相比，映像发现的工作原理
• 豆荚和rkt
• cgroups和rkt

历史

CoreOS开始构建rkt是因为他们认为Docker不再是“ [他们]设想的简单的可组合构建块”。

rkt与应用程序规范集一起宣布，该规范集关注容器的可组合性，安全性，图像分发和开放性。 Docker的守护程序和整体式CLI工具使可组合性成为一个问题-对于守护程序而言，是一个过程，而对于CLI而言，则是一个工具。 Weave和Flocker必须求助于包装Docker CLI工具这一事实证明了后者（在引入插件之前）。

rkt公告博客文章似乎成功地解决了所有问题，使Docker致力于开放标准。 由appc和CoreOS创始人Alex Polvi和Brandon Philips作为创始成员的Open Container Project（后更名为Open Container Initiative ）于2015年6月22日启动。

从那时起，我们还没有看到OCI在标准方面取得的进展，该进展将实现Docker，rkt和其他容器之间容器发现，分发和运行时环境的真正互操作性。 Docker显然将全力以赴构建平台，而rkt似乎坚定地针对平台构建者。 考虑到迹象表明大量采用Docker平台可能会导致供应商锁定，CoreOS的明智之举。

rkt功能

rkt具有以下功能：

• 模块化 – rkt分阶段设计（图像获取，cgroup和网络设置以及执行），这些阶段可以具有不同的实现，从而提供特权和关注点分离。
• 可组合性 – rkt不是守护程序，不是所有容器的父进程（因此可以在不影响运行中的容器的情况下进行更新），并且可以与其他工具组合。 本机运行使用acbuild构建的appc映像。
• 安全性 –它具有Intel Clear Container，SELinux和TPM支持以及图像签名验证。
• 它可以运行Docker映像。

新的1.0版本包含一些重要的修复和改进：

• rkt命令的Bash自动补全
• rkt fly –一个新的rkt stage1 ，允许容器以减少的隔离性和额外的特权运行。 这对于运行诸如集群管理控制器之类的软件很有用。

使用rkt构建和运行容器

rkt是容器运行时，而不是映像构建工具。 由于它本机运行appc容器，因此我们将使用appc acbuild工具生成映像。 让我们从一个非常基本的C应用程序开始：

$ cat hello.c
#include <stdio.h>

int main (int argc, char** argv) {
  printf("Hello, world!\n");
  return 0;
}
$ gcc -o hello -static hello.c

使用acbuild构建映像类似于构建Docker映像，但没有Dockerfile- 即 ，我们运行一系列acbuild命令。 我们可以将它们放到脚本中，以为我们提供建立形象的一线工具。 我们可以使用以下简单脚本来构建图像：

$ cat appc-hello.sh 
#!/usr/bin/env bash
acbuild begin
acbuild set-name hello
acbuild copy hello /app/hello
acbuild set-working-directory /app
acbuild set-exec -- /app/hello
acbuild write --overwrite hello-latest-linux-amd64.aci

如果运行此脚本，它将构建我们的映像：

$ ./appc-hello.sh 
Beginning build with an empty ACI
Setting name of ACI to hello
Copying host:hello to aci:/app/hello
Setting working directory to /app
Setting exec command [/app/hello]
Writing ACI to hello-latest-linux-amd64.aci

结果，我们在当前目录中有一个文件hello-latest-linux-amd64.aci 。 这是我们可以使用rkt运行的未签名，未加密的appc容器映像。 我们可以在rkt的图片列表中看到它：

$ sudo rkt image list
ID          NAME                    IMPORT TIME LAST USED   SIZE    LATEST
sha512-c500b17b60fa hello                   3 minutes ago   3 minutes ago   1.6MiB  false

我们现在可以从该图像启动一个容器：

$ sudo rkt --insecure-options=image run hello-latest-linux-amd64.aci
image: using image from local store for image name coreos.com/rkt/stage1-coreos:1.0.0
image: using image from file hello-latest-linux-amd64.aci
networking: loading networks from /etc/rkt/net.d
networking: loading network default with type ptp
[296002.703623] hello[4]: Hello, world!

与Docker中一样，执行完成后容器仍然存在：

$ sudo rkt list
UUID        APP IMAGE NAME  STATE   CREATED     STARTED     NETWORKS
6e651372    hello   hello       exited  3 seconds ago   2 seconds ago

rkt包含一个方便的命令，可帮助您清理未使用的图像和容器。 清理图像：

$ sudo rkt gc

清理豆荚（容器）：

$ sudo rkt image gc

现在，我们将运行一些进行联网的操作：

$ git clone https://github.com/lukebond/demo-api
$ cd demo-api
$ sudo ./appc.sh
$ sudo rkt --insecure-options=image run demo-api-latest-linux-amd64.aci

启动另一个终端并运行以下命令以找到IP地址并使用curl测试它：

$ sudo rkt list
UUID        APP     IMAGE NAME      STATE   CREATED     STARTED     NETWORKS
55cb3a96    demo-api    lukebond/demo-api   running 4 minutes ago   4 minutes ago   default:ip4=172.16.28.7
6e651372    hello       hello           exited  2 days ago  2 days ago  
$ curl 172.16.28.7:9000
"Hello, world 172.16.28.7!"

日志

要访问容器的日志，我们使用systemd的journalctl ，如下所示：

$ machinectl list
MACHINE                                  CLASS     SERVICE
rkt-e16bafd0-3b0b-4ade-b482-d6de42d35e8c container nspawn 

1 machines listed.
$ journalctl -M rkt-e16bafd0-3b0b-4ade-b482-d6de42d35e8c
-- Logs begin at Fri 2016-02-26 12:57:14 GMT, end at Fri 2016-02-26 12:57:14 GMT. --
...

停止容器

由于我们使用的rkt实现使用systemd-nspawn作为启动容器的基础工具，因此我们使用systemd停止容器：

$ machinectl list
MACHINE                                  CLASS     SERVICE
rkt-55cb3a96-8199-4d08-a998-713b631d3210 container nspawn 

1 machines listed.
$ machinectl kill rkt-55cb3a96-8199-4d08-a998-713b631d3210

据报道，在将来的版本中将提供用于停止容器的本地rkt命令。

签名图像

您会注意到，我们将--insecure-options=image传递给rkt run 。 这是为了禁用签名验证，默认情况下在rkt中启用此功能。 使用标准gpg工具可以轻松完成图像签名。 说明可以在这里找到 。

转换Docker映像

appc工具docker2aci可用于下载Docker映像并将其转换为appc的ACI格式。 在此处获取该工具 。

转换Docker映像非常简单：

$ docker2aci docker://lukebond/demo-api

它将Docker层压缩为一个ACI文件。 如果您希望将它们分开，则传递--nosquash ，它将在各层之间设置正确的依赖关系。

直接运行Docker映像

rkt还可以直接运行Docker映像，而无需先在单独的构建步骤中对其进行转换。

$ sudo rkt run --insecure-options=image docker://lukebond/demo-api

这里需要“不安全”选项，因为Docker不支持与rkt相同的图像签名验证。

图像发现和分发

Docker支持通过注册表（默认值，Docker Hub或其他）通过映像发现，而rkt遵循appc规范，并通过发现URL使用HTTPS和HTML meta标记的组合。

例如，看一下CoreOS的Etcd：

$ curl -sL https://quay.io/coreos/etcd | grep meta | grep discovery
  <meta name="ac-discovery" content="quay.io https://quay.io/c1/aci/{name}/{version}/{ext}/{os}/{arch}/">
  <meta name="ac-discovery-pubkeys" content="quay.io https://quay.io/aci-signing-key">

content属性是模板化的定位符，可用于获取特定OS和体系结构的下载URL。 使用此方法，还可以获取签名和公钥以供rkt用于验证。

Appc映像发现是如此简单且灵活，您可以将其存储在任何地方，无论您喜欢在何处。 只要您遵循HTTPS + HTML meta标记方案，rkt就能找到您的图像。 不需要注册表。 您可以将rkt映像存储在CoreOS的Quay服务中。

• 要全面了解appc映像发现的工作方式，请阅读规范 。

豆荚

“ pod”是Kubernetes项目流行的术语。 您可以将其定义为逻辑上分组在一起并应在同一台计算机上运行的应用程序的集合。 简而言之，应将它们安排为一个单元。

从0.5版开始，pod已成为rkt的一等公民。 appc规范将pod定义为“可部署的，可执行的单元…将在共享执行上下文中一起启动的应用程序列表”，其中包括网络配置和隔离器。 无论您运行的是一个进程还是多个进程，rkt仍然将其视为一个pod。

让我们看一个示例，该示例运行一个需要互相交谈的两个应用程序的pod。 我们将使用上述demo-api应用程序的一个非常简单的扩展，该扩展程序具有一个GET端点，该GET端点会在每次请求时增加Redis中的计数器。

$ git clone https://github.com/lukebond/demo-api-redis
$ cd demo-api-redis
$ sudo ./appc.sh
$ sudo rkt run --volume volume--var-lib-redis,kind=host,source=/var/lib/redis quay.io/quay/redis --insecure-options=image --port=http:9000 --set-env REDIS_HOST=localhost ~/Development/demo-api-redis/demo-api-redis-latest-linux-amd64.aci

上面的代码将为该应用程序构建一个ACI，然后启动一个包含Redis（从quay.io提取的签名ACI）和演示应用程序的Pod。 传递--port会将端口映射到主机，并且--set-env告诉演示应用程序如何与Redis通信。 --volume参数会将主机目录/var/lib/redis到Redis容器的数据目录中，并在其中写入快照。

$ sudo rkt list
UUID      APP             IMAGE NAME                STATE   CREATED       STARTED       NETWORKS
e16bafd0  redis           quay.io/quay/redis:latest running 6 seconds ago 6 seconds ago default:ip4=172.16.28.6
          demo-api-redis  lukebond/demo-api-redis       
$ curl 172.16.28.6:9000
"Hello, world 172.16.28.6! 1 hits."
$ curl 172.16.28.6:9000
"Hello, world 172.16.28.6! 2 hits."
$ curl 172.16.28.6:9000
"Hello, world 172.16.28.6! 3 hits."

太好了！

使用CGroup限制资源

rkt使您可以限制容器允许使用的CPU和内存。 这些限制以根据Kubernetes资源模型建模的单位表示。 CPU限制以毫核心（1/1000内核）表示，内存以MB / GB表示。

例如，要运行上面的示例并将Redis的内存使用限制为512MB，CPU限制为半核心，我们可以使用以下run命令：

$ sudo rkt run --cpu=500 --memory=512M quay.io/quay/redis --insecure-options=image --port=http:9000 --set-env REDIS_HOST=localhost demo-api-redis-latest-linux-amd64.aci

根据主机上交换的配置方式，您可能会发现容器使用的内存似乎比rkt run --memory指定的rkt run --memory 。 禁用交换后，这将是一个硬限制。 启用交换功能后，您将看到该进程使用了​​更多的内存，因为系统配置为允许它使用交换功能来增加其内存。

rkt for Platform Builders

CoreOS针对rkt的设计目标导致了容器运行时，非常适合构建基于容器的平台。

Docker全力以赴构建一个完整的平台的道路，最终导致了最新版本的Docker Datacenter和Universal Control Plane的出现 ，为最终用户带来了绝佳的体验。 但是，由于缺乏可组合性，很难在Docker之上构建平台。

rkt的底层特性及其模块化和可组合的设计使其成为构建容器平台的理想选择。 我在这里看到rkt在容器生态系统中找到其利基市场。

结论

对于这样一个年轻的项目，rkt已经走了很长一段路。 现在，核心运行时正与Docker达到功能对等。 最新的v1.0版本代表rkt毕业于可用于生产的容器运行时，它是Docker的真正替代品。

我已经向您展示了使用acbuild和rkt构建和运行容器的基础知识，现在您应该已经足够了解如何使用rkt运行容器，就像使用Docker一样。 当然，如果我们想在生产中运行rkt，则还有更多内容需要介绍，包括多主机联网，监视以及与现有容器工具（例如Weave，Flocker和Sysdig）的集成。

rkting，快乐！

翻译自: https://www.javacodegeeks.com/2016/03/getting-started-rkt.html