“容器运行时”是一个被过度使用的名词。

在 Red Hat，我们乐意这么说，“容器即 Linux，Linux 即容器”。下面解释一下这种说法。传统的容器是操作系统中的进程，通常具有如下 3 个特性：

1. 资源限制

当你在系统中运行多个容器时，你肯定不希望某个容器独占系统资源，所以我们需要使用资源约束来控制 CPU、内存和网络带宽等资源。Linux 内核提供了 cgroup 特性，可以通过配置控制容器进程的资源使用。

2. 安全性配置

一般而言，你不希望你的容器可以攻击其它容器或甚至攻击宿主机系统。我们使用了 Linux 内核的若干特性建立安全隔离，相关特性包括 SELinux、seccomp 和 capabilities。

（LCTT 译注：从 2.2 版本内核开始，Linux 将特权从超级用户中分离，产生了一系列可以单独启用或关闭的 capabilities）

3. 虚拟隔离

容器外的任何进程对于容器而言都应该不可见。容器应该使用独立的网络。不同的容器对应的进程应该都可以绑定 80 端口。每个容器的 内核映像 image 、 根文件系统 rootfs （rootfs）都应该相互独立。在 Linux 中，我们使用内核的 名字空间 namespace 特性提供 虚拟隔离 virtual separation 。

那么，具有安全性配置并且在 cgroup 和名字空间下运行的进程都可以称为容器。查看一下 Red Hat Enterprise Linux 7 操作系统中的 PID 1 的进程 systemd，你会发现 systemd 运行在一个 cgroup 下。

# tail -1 /proc/1/cgroup
1:name=systemd:/

ps 命令让我们看到 systemd 进程具有 SELinux 标签：

# ps -eZ | grep systemd
system_u:system_r:init_t:s0             1 ?     00:00:48 systemd

以及 capabilities：

# grep Cap /proc/1/status
...
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapBnd:    0000003fffffffff

最后，查看 /proc/1/ns 子目录，你会发现 systemd 运行所在的名字空间。

ls -l /proc/1/ns
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 net -> net:[4026532009]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 pid -> pid:[4026531836]
...

如果 PID 1 进程（实际上每个系统进程）具有资源约束、安全性配置和名字空间，那么我可以说系统上的每一个进程都运行在容器中。

容器运行时工具也不过是修改了资源约束、安全性配置和名字空间，然后 Linux 内核运行起进程。容器启动后，容器运行时可以在容器内监控 PID 1 进程，也可以监控容器的标准输入/输出，从而进行容器进程的生命周期管理。

容器运行时

你可能自言自语道，“哦，systemd 看起来很像一个容器运行时”。经过若干次关于“为何容器运行时不使用 systemd-nspawn 工具来启动容器”的邮件讨论后，我认为值得讨论一下容器运行时及其发展史。

Docker 通常被称为容器运行时，但“ 容器运行时 container runtime ”是一个被过度使用的词语。当用户提到“容器运行时”，他们其实提到的是为开发人员提供便利的 上层 high-level 工具，包括 Docker，CRI-O 和 RKT。这些工具都是基于 API 的，涉及操作包括从容器仓库拉取容器镜像、配置存储和启动容器等。启动容器通常涉及一个特殊工具，用于配置内核如何运行容器，这类工具也被称为“容器运行时”，下文中我将称其为“底层容器运行时”以作区分。像 Docker、CRI-O 这样的守护进程及形如 Podman、Buildah 的命令行工具，似乎更应该被称为“容器管理器”。

早期版本的 Docker 使用 lxc 工具集启动容器，该工具出现在 systemd-nspawn 之前。Red Hat 最初试图将 libvirt （libvirt-lxc）集成到 Docker 中替代 lxc 工具，因为 RHEL 并不支持 lxc。libvirt-lxc 也没有使用 systemd-nspawn，在那时 systemd 团队仅将 systemd-nspawn 视为测试工具，不适用于生产环境。

与此同时，包括我的 Red Hat 团队部分成员在内的 上游 upstream Docker 开发者，认为应该采用 golang 原生的方式启动容器，而不是调用外部应用。他们的工作促成了 libcontainer 这个 golang 原生库，用于启动容器。Red Hat 工程师更看好该库的发展前景，放弃了 libvirt-lxc。

后来成立 开放容器组织 Open Container Initiative （OCI）的部分原因就是人们希望用其它方式启动容器。传统的基于名字空间隔离的容器已经家喻户晓，但人们也有 虚拟机级别隔离 virtual machine-level isolation 的需求。Intel 和 Hyper.sh 正致力于开发基于 KVM 隔离的容器，Microsoft 致力于开发基于 Windows 的容器。OCI 希望有一份定义容器的标准规范，因而产生了 OCI 运行时规范 Runtime Specification 。

OCI 运行时规范定义了一个 JSON 文件格式，用于描述要运行的二进制，如何容器化以及容器根文件系统的位置。一些工具用于生成符合标准规范的 JSON 文件，另外的工具用于解析 JSON 文件并在该根文件系统（rootfs）上运行容器。Docker 的部分代码被抽取出来构成了 libcontainer 项目，该项目被贡献给 OCI。上游 Docker 工程师及我们自己的工程师创建了一个新的前端工具，用于解析符合 OCI 运行时规范的 JSON 文件，然后与 libcontainer 交互以便启动容器。这个前端工具就是 runc，也被贡献给 OCI。虽然 runc 可以解析 OCI JSON 文件，但用户需要自行生成这些文件。此后，runc 也成为了最流行的底层容器运行时，基本所有的容器管理工具都支持 runc，包括 CRI-O、Docker、Buildah、Podman 和 Cloud Foundry Garden 等。此后，其它工具的实现也参照 OCI 运行时规范，以便可以运行 OCI 兼容的容器。

Clear Containers 和 Hyper.sh 的 runV 工具都是参照 OCI 运行时规范运行基于 KVM 的容器，二者将其各自工作合并到一个名为 Kata 的新项目中。在去年，Oracle 创建了一个示例版本的 OCI 运行时工具，名为 RailCar，使用 Rust 语言编写。但该 GitHub 项目已经两个月没有更新了，故无法判断是否仍在开发。几年前，Vincent Batts 试图创建一个名为 nspawn-oci 的工具，用于解析 OCI 运行时规范文件并启动 systemd-nspawn；但似乎没有引起大家的注意，而且也不是原生的实现。

如果有开发者希望实现一个原生的 systemd-nspawn --oci OCI-SPEC.json 并让 systemd 团队认可和提供支持，那么CRI-O、Docker 和 Podman 等容器管理工具将可以像使用 runc 和 Clear Container/runV （Kata） 那样使用这个新的底层运行时。（目前我的团队没有人参与这方面的工作。）

总结如下，在 3-4 年前，上游开发者打算编写一个底层的 golang 工具用于启动容器，最终这个工具就是 runc。那时开发者有一个使用 C 编写的 lxc 工具，在 runc 开发后，他们很快转向 runc。我很确信，当决定构建 libcontainer 时，他们对 systemd-nspawn 或其它非原生（即不使用 golang）的运行 namespaces 隔离的容器的方式都不感兴趣。

via: https://opensource.com/article/18/1/history-low-level-container-runtimes

作者：Daniel Walsh 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器，必须有一个关键的能力：一个容器编排器。

对于关键的集群化以及计划的任务，编排器是起重大作用的，比如：

• 管理容器计划和资源分配。
• 支持服务发现和无缝的应用程序部署。
• 分配应用程序运行必需的资源。

不幸的是，在这种环境下，编排器的分布式特性和资源的短暂性使得确保编排器的安全是一个极具挑战性的任务。在这篇文章中，我们将讨论容器编排器安全模型中没有考虑到的、但是很重要的这方面的详细情况，以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式，去克服这些问题。

诱因和威胁模型

使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的编排器。为达到这个目标，我们部署了第一个在我们心目中认为的以最小权限原则设计的容器编排器。

在计算机科学中，一个分布式系统所要求的最小权限原则是，系统中的每个参与者仅仅能访问它正当目的所需要的信息和资源。不是更多，也不是更少。

“一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”

最小权限原则

在一个 Docker 企业版集群中的每个节点分配的角色：既不是管理者（manager），也不是工人（worker）。这些角色为节点定义了一个很粗粒度的权限级别：分别进行管理和任务执行。尽管如此，不用理会它的角色，通过使用加密的方式，来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是，确保集群安全变得更容易了，甚至可以防止大多数的有经验的攻击者模式：攻击者控制了底层通讯网络，或者甚至攻陷了集群节点。

内核缺省安全

这是一个很老的安全最大化状态：如果它不是缺省的，就没人用它。Docker Swarm 模式将缺省安全这一概念融入了核心，并且使用这一机制去解决编排器生命周期中三个很难并且很重要的部分：

1. 可信引导和节点引入。
2. 节点身份发布和管理。
3. 认证、授权和加密的信息存储和传播。

我们来分别看一下这三个部分：

可信引导和节点引入

确保集群安全的第一步，没有别的，就是严格控制成员和身份。管理员不能依赖它们节点的身份，并且在节点之间强制实行绝对的负载隔离。这意味着，未授权的节点不能允许加入到集群中，并且，已经是集群一部分的节点不能改变身份，突然去伪装成另一个节点。

为解决这种情况，通过 Docker 企业版 Swarm 模式管理的节点，维护了健壮的、不可改变的身份。期望的特性是，通过使用两种关键的构建块去保证加密：

1. 为集群成员使用 安全加入令牌 Secure join token 。
2. 从一个集中化的认证机构发行的内嵌唯一身份的证书。

加入 Swarm

要加入 Swarm，节点需要一份 安全加入令牌 Secure join token 的副本。在集群内的每个操作角色的令牌都是独一无二的 —— 现在有两种类型的节点：工人（workers）和管理者（managers）。由于这种区分，拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一得到这个特殊令牌的方式是通过 swarm 的管理 API 去向集群管理者请求一个。

令牌是安全的并且是随机生成的，它还有一个使得令牌泄露更容易被检测到的特殊语法：一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是，即便发现一个泄露，令牌也可以很容易去更新，并且，推荐你经常去更新它们 —— 特别是，在一段时间中你的集群不进行扩大的情况下。

引导信任

作为它的身份标识创建的一部分，一个新的节点将向任意一个网络管理者请求发布一个新的身份。但是，在我们下面的威胁模型中，所有的通讯可以被一个第三方拦截。这种请求存在的问题是：一个节点怎么知道与它进行对话的对方是合法的管理者？

幸运的是，Docker 有一个内置机制可以避免这种情况。这个加入令牌被主机用于加入 Swarm，包含了一个根 CA 证书的哈希串。所以，主机可以使用单向 TLS，并且使用这个哈希串去验证它加入的 Swarm 是否正确：如果管理者持有的证书没有被正确的 CA 哈希串签名，节点就知道它不可信任。

节点身份发布和管理

在一个 Swarm 中，身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现形式中，证书的私钥被绝对限制在主机的原始位置。尤其是，管理者不能访问除了它自己的私钥以外的任何一个私钥。

身份发布

要接收它们的证书而无需共享它们的私钥，新的主机通过发布一个证书签名请求（CSR）来开始，管理者收到证书签名请求之后，转换成一个证书。这个证书成为这个新的主机的身份标识，使这个节点成为 Swarm 的一个完全合格成员！

当和安全引导机制一起使用时，发行身份标识的这个机制来加入节点是缺省安全的：所有的通讯部分都是经过认证的、授权的，并且非敏感信息从来都不会以明文方式进行交换。

身份标识延期

尽管如此，给一个 Swarm 中安全地加入节点，仅仅是 “故事” 的一部分。为降低证书的泄露或者失窃造成的影响，并且移除管理 CRL 列表的复杂性，Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期，但是，也可以配置为一个小时后即刻过期！

较短的证书过期时间意味着不能手动去处理证书更新，所以，通常会使用一个 PKI 系统。对于 Swarm，所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单：使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者，一个 Swarm 节点定期生成一个新的公钥/私钥密钥对，并且用相关的 CSR 去签名发送，创建一个维持相同身份标识的完整的新证书。

经过认证、授权、和加密的信息存储和传播。

在一个正常的 Swarm 的操作中，关于任务的信息被发送给去运行的工人（worker）节点。这里不仅仅包含将被一个节点运行的容器的信息；也包含那个容器运行所必需的资源的所有信息，包括敏感的机密信息，比如，私钥、密码和 API 令牌。

传输安全

事实上，参与 Swarm 的每个节点都拥有一个独一无二的 X509 格式的证书，因此，节点之间的通讯安全是没有问题的：节点使用它们各自的证书，与另一个连接方进行相互认证、继承机密、真实性、和 TLS 的完整性。

关于 Swarm 模式的一个有趣的细节是，本质上它是使用了一个推送模式：仅管理者被允许去发送信息到工人们（workers）—— 显著降低了暴露在低权限的工人节点面前的管理者节点的攻击面。

将负载严格隔离进安全区域

管理者节点的其中一个责任是，去决定发送到每个工人（worker）节点的任务是什么。管理者节点使用多种策略去做这个决定；根据每个节点和每个负载的特性，去跨 Swarm 去安排负载。

在使用 Swarm 模式的 Docker 企业版中，管理者节点通过使用附加到每个单个节点标识上的安全标签，去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起，以限制敏感负载暴露，以及使相关机密信息更安全。

安全分发机密

除了加快身份标识发布过程之外，管理者节点还有存储和分发工人节点所需要的任何资源的任务。机密信息像任何其它类型的资源一样处理，并且基于安全的 mTLS 连接，从管理者推送到工人节点。

在主机上，Docker 企业版能确保机密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露机密给一个容器，确保机密总是保存在内存中，并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全，比如，在环境变量中存储它们。一旦这个任务完成，这个机密将永远消失。

存储机密

在管理者主机上的机密总是保持加密的。缺省情况下，加密这些机密的密钥（被称为数据加密密钥，DEK）是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。

但是，如果你运行一个生产集群，我们推荐你启用自动锁定模式。当自动锁定模式启用后，一个重新更新过的 DEK 被一个独立的加密密钥的密钥（KEK）所加密。这个密钥从不被存储在集群中；管理者有责任将它存储在一个安全可靠的地方，并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。

根据 Raft 故障容错一致性算法，Swarm 模式支持多个管理者。在这个场景中，无缝扩展了机密存储的安全性。每个管理者主机除了共享密钥之外，还有一个唯一的磁盘加密密钥。幸运的是，Raft 日志在磁盘上也是加密的，并且，在自动锁定模式下，没有 KEK 同样是不可访问的。

当一个节点被攻陷后发生了什么？

在传统的编排器中，挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式，恢复它就像运行一个 Docker 节点的 rm 命令一样容易。这是从集群中删除一个受影响的节点，而 Docker 将去处理剩下的事情，即，重新均衡负载，并且确保其它的主机已经知道，而不会去与受影响的节点通讯。

正如我们看到的那样，感谢最小权限的编排器，甚至是，如果攻击者在主机上持续活动，它们将被从剩余的网络上切断。主机的证书 —— 它的身份标识 —— 被列入黑名单，因此，管理者也不能有效访问它。

结论

使用 Swarm 模式的 Docker 企业版，在缺省情况下确保了编排器的所有关键区域的安全：

• 加入集群。阻止恶意节点加入到集群。
• 把主机分组为安全区域。阻止攻击者的横向移动。
• 安排任务。任务将仅被委派到允许的节点。
• 分配资源。恶意节点不能 “盗取” 其它的负载或者资源。
• 存储机密。从不明文保存并且从不写入到工人节点的磁盘上。
• 与工人节点的通讯。使用相互认证的 TLS 加密。

因为 Swarm 模式的持续改进，Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是：如果一个管理者被攻陷了，怎么去保证剩下的节点的安全？路线图已经有了，其中一些功能已经可以使用，比如，白名单功能，仅允许特定的 Docker 镜像，阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。

via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/

作者：Diogo Mónica 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

介绍

这篇文章是我在 CI 环境（特别是在 Gitlab 中）的 Docker 容器中构建 Go 项目的研究总结。我发现很难解决私有依赖问题（来自 Node/.NET 背景），因此这是我写这篇文章的主要原因。如果 Docker 镜像上存在任何问题或提交请求，请随时与我们联系。

dep

由于 dep 是现在管理 Go 依赖关系的最佳选择，因此在构建前之前运行 dep ensure。

注意：我个人不会将我的 vendor/ 文件夹提交到源码控制，如果你这样做，我不确定这个步骤是否可以跳过。

使用 Docker 构建的最好方法是使用 dep ensure -vendor-only。 见这里。

Docker 构建镜像

我第一次尝试使用 golang:1.10，但这个镜像没有：

• curl
• git
• make
• dep
• golint

我已经创建好了用于构建的镜像（github / dockerhub），我会保持更新，但我不提供任何担保，因此你应该创建并管理自己的 Dockerhub。

内部依赖关系

我们完全有能力创建一个有公共依赖关系的项目。但是如果你的项目依赖于另一个私人 Gitlab 仓库呢？

在本地运行 dep ensure 应该可以和你的 git 设置一起工作，但是一旦在 CI 上不适用，构建就会失败。

Gitlab 权限模型

这是在 Gitlab 8.12 中添加的，这个我们最关心的有用的功能是在构建期提供的 CI_JOB_TOKEN 环境变量。

这基本上意味着我们可以像这样克隆依赖仓库：

git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/myuser/mydependentrepo

然而，我们希望使这更友好一点，因为 dep 在试图拉取代码时不会奇迹般地添加凭据。

我们将把这一行添加到 .gitlab-ci.yml 的 before_script 部分。

before_script:
  - echo -e "machine gitlab.com\nlogin gitlab-ci-token\npassword ${CI_JOB_TOKEN}" > ~/.netrc

使用 .netrc 文件可以指定哪个凭证用于哪个服务器。这种方法可以避免每次从 Git 中拉取（或推送）时输入用户名和密码。密码以明文形式存储，因此你不应在自己的计算机上执行此操作。这实际用于 Git 在背后使用 cURL。 在这里阅读更多。

项目文件

Makefile

虽然这是可选的，但我发现它使事情变得更容易。

配置这些步骤意味着在 CI 脚本（和本地）中，我们可以运行 make lint、make build 等，而无需每次重复步骤。

GOFILES = $(shell find . -name '*.go' -not -path './vendor/*')
GOPACKAGES = $(shell go list ./...  | grep -v /vendor/)

default: build

workdir:
    mkdir -p workdir

build: workdir/scraper

workdir/scraper: $(GOFILES)
    GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o workdir/scraper .

test: test-all

test-all:
    @go test -v $(GOPACKAGES)

lint: lint-all

lint-all:
    @golint -set_exit_status $(GOPACKAGES)

.gitlab-ci.yml

这是 Gitlab CI 魔术发生的地方。你可能想使用自己的镜像。

image: sjdweb/go-docker-build:1.10

stages:
  - test
  - build

before_script:
  - cd $GOPATH/src
  - mkdir -p gitlab.com/$CI_PROJECT_NAMESPACE
  - cd gitlab.com/$CI_PROJECT_NAMESPACE
  - ln -s $CI_PROJECT_DIR
  - cd $CI_PROJECT_NAME
  - echo -e "machine gitlab.com\nlogin gitlab-ci-token\npassword ${CI_JOB_TOKEN}" > ~/.netrc
  - dep ensure -vendor-only

lint_code:
  stage: test
  script:
    - make lint

unit_tests:
  stage: test
  script:
    - make test

build:
  stage: build
  script:
    - make

缺少了什么

我通常会用我的二进制文件构建 Docker 镜像，并将其推送到 Gitlab 容器注册库中。

你可以看到我正在构建二进制文件并退出，你至少需要将该二进制文件（例如生成文件）存储在某处。

via: https://seandrumm.co.uk/blog/building-go-projects-with-docker-on-gitlab-ci/

作者：SEAN DRUMM 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Docker 是一种所谓容器化的操作系统级的虚拟化软件。

基于 Linux 内核的 cgroup 和 namespace 等资源隔离特性，Docker 可以在单个 Linux 实例中运行多个独立的容器。

通过将应用依赖和相关库打包进容器，Docker 使得应用可以在容器中安全隔离地运行。

Dry 是什么

Dry 是一个管理并监控 Docker 容器和镜像的命令行工具。

Dry 可以给出容器相关的信息，包括对应镜像、容器名称、网络、容器中运行的命令及容器状态；如果运行在 Docker Swarm 中，工具还会给出 Swarm 集群的各种状态信息。

Dry 可以连接至本地或远程的 Docker 守护进程。如果连接本地 Docker，Docker 主机显示为 unix:///var/run/docker.sock。

如果连接远程 Docker，Docker 主机显示为 tcp://IP Address:Port Number 或 tcp://Host Name:Port Number。

Dry 可以提供类似 docker ps 的指标输出，但输出比 docker ps 内容详实、富有色彩。

相比 Docker，Dry 还可以手动添加一个额外的名称列，用于降低记忆难度。

推荐阅读：

• Portainer – 用于 Docker 管理的简明 GUI
• Rancher – 适用于生产环境的完备容器管理平台
• cTop – Linux环境下容器管理与监控的命令行工具

如何在 Linux 中安装 Dry

在 Linux 中，可以通过一个简单的 shell 脚本安装最新版本的 Dry 工具。Dry 不依赖外部库。对于绝大多数的 Docker 命令，Dry 提供类似样式的命令。

$ curl -sSf https://moncho.github.io/dry/dryup.sh | sudo sh
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
100 10 100 10 0 0 35 0 --:--:-- --:--:-- --:--:-- 35
dryup: downloading dry binary
######################################################################## 100.0%
dryup: Moving dry binary to its destination
dryup: dry binary was copied to /usr/local/bin, now you should 'sudo chmod 755 /usr/local/bin/dry'

使用如下命令将文件权限变更为 755：

$ sudo chmod 755 /usr/local/bin/dry

对于使用 Arch Linux 的用户，可以使用 Packer 或 Yaourt 包管理器，从 AUR 源安装该工具。

$ yaourt -S dry-bin
或者
$ packer -S dry-bin

如果希望在 Docker 容器中运行 dry，可以运行如下命令。前提条件是已确认在操作系统中安装了 Docker。

推荐阅读：

• 如何在 Linux 中安装 Docker
• 如何在 Linux 中玩转 Docker 镜像
• 如何在 Linux 中玩转 Docker 容器
• 如何在 Docker 容器中安装并运行应用程序

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock moncho/dry

如何启动并运行 Dry

在控制台运行 dry 命令即可启动该工具，其默认输出如下：

$ dry

如何使用 Dry 监控 Docker

你可以在 dry 的界面中按下 m 键打开监控模式。

如何使用 Dry 管理容器

在选中的容器上单击回车键，即可管理容器。Dry 提供如下操作：查看日志，查看、杀死、删除容器，停止、启动、重启容器，查看容器状态及镜像历史记录等。

如何监控容器资源利用率

用户可以使用 Stats+Top 选项查看指定容器的资源利用率。

该操作需要在容器管理界面完成（在上一步的基础上，点击 Stats+Top 选项）。另外，也可以按下 s 打开容器资源利用率界面。

如何查看容器、镜像及本地卷的磁盘使用情况

可以使用 F8 键查看容器、镜像及本地卷的磁盘使用情况。

该界面明确地给出容器、镜像和卷的总数，哪些处于使用状态，以及整体磁盘使用情况、可回收空间大小的详细信息。

如何查看已下载的镜像

按下 2 键即可列出全部的已下载镜像。

如何查看网络列表

按下 3 键即可查看全部网络及网关。

如何查看全部 Docker 容器

按下 F2 键即可列出列出全部容器，包括运行中和已关闭的容器。

Dry 快捷键

查看帮助页面或 dry GitHub 即可查看全部快捷键。

via: https://www.2daygeek.com/dry-an-interactive-cli-manager-for-docker-containers/

作者：Magesh Maruthamuthu 选题：lujun9972 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在这个 Docker 系列的最后一篇文章中，我们将讲述在 DockerHub 上使用和发布镜像。

在前面的文章中，我们了解到了基本的 Docker 术语，在 Linux 桌面、MacOS 和 Windows上 如何安装 Docker，如何创建容器镜像 并且在系统上运行它们。在本系列的最后一篇文章中，我们将讨论如何使用 DockerHub 中的镜像以及将自己的镜像发布到 DockerHub。

首先：什么是 DockerHub 以及为什么它很重要？DockerHub 是一个由 Docker 公司运行和管理的基于云的存储库。它是一个在线存储库，Docker 镜像可以由其他用户发布和使用。有两种库：公共存储库和私有存储库。如果你是一家公司，你可以在你自己的组织内拥有一个私有存储库，而公共镜像可以被任何人使用。

你也可以使用公开发布的官方 Docker 镜像。我使用了很多这样的镜像，包括我的试验 WordPress 环境、KDE plasma 应用程序等等。虽然我们上次学习了如何创建自己的 Docker 镜像，但你不必这样做。DockerHub 上发布了数千镜像供你使用。DockerHub 作为默认存储库硬编码到 Docker 中，所以当你对任何镜像运行 docker pull 命令时，它将从 DockerHub 下载。

从 Docker Hub 下载镜像并在本地运行

开始请查看本系列的前几篇文章，以便继续。然后，一旦 Docker 在你的系统上运行，你就可以打开终端并运行：

$ docker images

该命令将显示当前系统上所有的 docker 镜像。假设你想在本地机器上部署 Ubuntu，你可能会：

$ docker pull ubuntu

如果你的系统上已经存在 Ubuntu 镜像，那么该命令会自动将该系统更新到最新版本。因此，如果你想要更新现有的镜像，只需运行 docker pull 命令，易如反掌。这就像 apt-get update 一样，没有任何的混乱和麻烦。

你已经知道了如何运行镜像：

$ docker run -it <image name>
$ docker run -it ubuntu

命令提示符应该变为如下内容：

root@1b3ec4621737:/#

现在你可以运行任何属于 Ubuntu 的命令和实用程序，这些都被包含在内而且安全。你可以在 Ubuntu 上运行你想要的所有实验和测试。一旦你完成了测试，你就可以销毁镜像并下载一个新的。在虚拟机中不存在系统开销。

你可以通过运行 exit 命令退出该容器：

$ exit

现在假设你想在系统上安装 Nginx，运行 search 命令来找到需要的镜像：

$ docker search nginx

正如你所看到的，DockerHub 上有很多 Nginx 镜像。为什么？因为任何人都可以发布镜像，各种镜像针对不同的项目进行了优化，因此你可以选择合适的镜像。你只需要为你的需求安装合适的镜像。

假设你想要拉取 Bitnami 的 Nginx 镜像：

$ docker pull bitnami/nginx

现在运行：

$ docker run -it bitnami/nginx

如何发布镜像到 Docker Hub？

在此之前，我们学习了如何创建 Docker 镜像，我们可以轻松地将该镜像发布到 DockerHub 中。首先，你需要登录 DockerHub，如果没有账户，请 创建账户。然后，你可以打开终端应用，登录：

$ docker login --username=<USERNAME>

将 “” 替换为你自己的 Docker Hub 用户名。我这里是 arnieswap：

$ docker login --username=arnieswap

输入密码，你就登录了。现在运行 docker images 命令来获取你上次创建的镜像的 ID。

$ docker images

现在，假设你希望将镜像 ng 推送到 DockerHub，首先，我们需要标记该镜像（了解更多关于标记的信息）：

$ docker tag e7083fd898c7 arnieswap/my_repo:testing

现在推送镜像：

$ docker push arnieswap/my_repo

推送指向的是 docker.io/arnieswap/my\_repo 仓库：

12628b20827e: Pushed
8600ee70176b: Mounted from library/ubuntu
2bbb3cec611d: Mounted from library/ubuntu
d2bb1fc88136: Mounted from library/ubuntu
a6a01ad8b53f: Mounted from library/ubuntu
833649a3e04c: Mounted from library/ubuntu
testing: digest: sha256:286cb866f34a2aa85c9fd810ac2cedd87699c02731db1b8ca1cfad16ef17c146 size: 1569

哦耶！你的镜像正在上传。一旦完成，打开 DockerHub，登录到你的账户，你就能看到你的第一个 Docker 镜像。现在任何人都可以部署你的镜像。这是开发软件和发布软件最简单，最快速的方式。无论你何时更新镜像，用户都可以简单地运行：

$ docker run arnieswap/my_repo

现在你知道为什么人们喜欢 Docker 容器了。它解决了传统工作负载所面临的许多问题，并允许你在任何时候开发、测试和部署应用程序。通过遵循本系列中的步骤，你自己可以尝试以下。

via: https://www.linux.com/blog/learn/intro-to-linux/2018/1/how-use-dockerhub

作者：Swapnil Bhartiya 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在 前面的文章 中，我们学习了在 Linux、macOS、以及 Windows 上如何使用 Docker 的基础知识。在这篇文章中，我们将学习创建 Docker 镜像的基本知识。我们可以在 DockerHub 上得到可用于你自己的项目的预构建镜像，并且也可以将你自己的镜像发布到这里。

我们使用预构建镜像得到一个基本的 Linux 子系统，因为，从头开始构建需要大量的工作。你可以使用 Alpine（ Docker 版使用的官方版本）、Ubuntu、BusyBox、或者 scratch。在我们的示例中，我将使用 Ubuntu。

在我们开始构建镜像之前，让我们先“容器化”它们！我的意思是，为你的所有 Docker 镜像创建目录，这样你就可以维护不同的项目和阶段，并保持它们彼此隔离。

$ mkdir dockerprojects
cd dockerprojects

现在，在 dockerprojects 目录中，你可以使用自己喜欢的文本编辑器去创建一个 Dockerfile 文件；我喜欢使用 nano，它对新手来说很容易上手。

$ nano Dockerfile

然后添加这样的一行内容：

FROM Ubuntu

使用 Ctrl+Exit 然后选择 Y 去保存它。

现在开始创建你的新镜像，然后给它起一个名字（在刚才的目录中运行如下的命令）：

$ docker build -t dockp .

（注意命令后面的圆点）这样就创建成功了，因此，你将看到如下内容：

Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM ubuntu
---> 2a4cca5ac898
Successfully built 2a4cca5ac898
Successfully tagged dockp:latest

现在去运行和测试一下你的镜像：

$ docker run -it Ubuntu

你将看到 root 提示符：

root@c06fcd6af0e8:/#

这意味着在 Linux、Windows、或者 macOS 中你可以运行一个最小的 Ubuntu 了。你可以运行所有的 Ubuntu 原生命令或者 CLI 实用程序。

我们来查看一下在你的目录下你拥有的所有 Docker 镜像：

$docker images

REPOSITORY TAG IMAGE ID CREATED SIZE
dockp latest 2a4cca5ac898 1 hour ago 111MB
ubuntu latest 2a4cca5ac898 1 hour ago 111MB
hello-world latest f2a91732366c 8 weeks ago 1.85kB

你可以看到共有三个镜像：dockp、Ubuntu、和 hello-world， hello-world 是我在几周前创建的，这一系列的前面的文章就是在它下面工作的。构建一个完整的 LAMP 栈可能是一个挑战，因此，我们使用 Dockerfile 去创建一个简单的 Apache 服务器镜像。

从本质上说，Dockerfile 是安装所有需要的包、配置、以及拷贝文件的一套指令。在这个案例中，它是安装配置 Apache 和 Nginx。

你也可以在 DockerHub 上去创建一个帐户，然后在构建镜像之前登入到你的帐户，在这个案例中，你需要从 DockerHub 上拉取一些东西。从命令行中登入 DockerHub，运行如下所求的命令：

$ docker login

在登入时输入你的用户名和密码。

接下来，为这个 Docker 项目，在目录中创建一个 Apache 目录：

$ mkdir apache

在 Apache 目录中创建 Dockerfile 文件：

$ nano Dockerfile

然后，粘贴下列内容：

FROM ubuntu
MAINTAINER Kimbro Staken version: 0.1
RUN apt-get update && apt-get install -y apache2 && apt-get clean && rm -rf /var/lib/apt/lists/*

ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"]

然后，构建镜像：

docker build -t apache .

（注意命令尾部的空格和圆点）

这将花费一些时间，然后你将看到如下的构建成功的消息：

Successfully built e7083fd898c7
Successfully tagged ng:latest
Swapnil:apache swapnil$

现在，我们来运行一下这个服务器：

$ docker run -d apache
a189a4db0f7c245dd6c934ef7164f3ddde09e1f3018b5b90350df8be85c8dc98

发现了吗，你的容器镜像已经运行了。可以运行如下的命令来检查所有运行的容器：

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED
a189a4db0f7 apache "/usr/sbin/apache2ctl" 10 seconds ago

你可以使用 docker kill 命令来杀死容器：

$docker kill a189a4db0f7

正如你所见，这个 “镜像” 它已经永久存在于你的目录中了，而不论运行与否。现在你可以根据你的需要创建很多的镜像，并且可以从这些镜像中繁衍出来更多的镜像。

这就是如何去创建镜像和运行容器。

想学习更多内容，你可以打开你的浏览器，然后找到更多的关于如何构建像 LAMP 栈这样的完整的 Docker 镜像的文档。这里有一个帮你实现它的 Dockerfile 文件。在下一篇文章中，我将演示如何推送一个镜像到 DockerHub。

你可以通过来自 Linux 基金会和 edX 的 “介绍 Linux” 免费课程来学习更多的知识。

via: https://www.linux.com/blog/learn/intro-to-linux/2018/1/how-create-docker-image

作者：SWAPNIL BHARTIYA 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出