标签 容器 下的文章

工作中用了容器？熟悉这些出自云原生计算基金会的项目吗？

随着用容器来开发应用的实践变得流行，云原生应用也在增长。云原生应用的定义为：

“云原生技术用于开发使用打包在容器中的服务所构建的应用程序，以微服务的形式部署，并通过敏捷的 DevOps 流程和持续交付工作流在弹性基础设施上进行管理。”

这个定义提到了构成云原生应用的不可或缺的四个元素：

  1. 容器
  2. 微服务
  3. DevOps
  4. 持续集成和持续交付 (CI/CD)

尽管这些技术各有各自独特的历史，但它们之间却相辅相成，在短时间内实现了云原生应用和工具的惊人的指数级增长。这个云原生计算基金会（CNCF）信息图呈现了当今云原生应用生态的规模和广度。

title=

云原生计算基金会项目

我想说，瞧着吧！这仅仅是一个开始。正如 NodeJS 的出现引发了无数的 JavaScript 工具的爆炸式增长一样，容器技术的普及也推动了云原生应用的指数增长。

好消息是，有几个组织负责监管并将这些技术连接在一起。 其中之一是 开放容器倡议 Open Containers Initiative （OCI），它是一个轻量级的、开放的治理机构（或项目），“它是在 Linux 基金会的支持下形成的，其明确目的是创建开放的行业标准的容器格式和运行时。” 另一个是 CNCF，它是“一个致力于使云原生计算普及和可持续发展的开源软件基金会”。

通常除了围绕云原生应用建立社区之外，CNCF 还帮助项目围绕其云原生应用建立结构化管理。CNCF 创建了成熟等级的概念（沙箱级、孵化级或毕业级），分别与下图中的“创新者”、“早期采用者”和“早期大量应用”相对应。

title=

CNCF 项目成熟等级

CNCF 为每个成熟等级制定了详细的标准（为方便读者而列在下面）。获得技术监督委员会（TOC）三分之二的同意才能转为孵化或毕业级。

沙箱级

要想成为沙箱级，一个项目必须至少有两个 TOC 赞助商。 有关详细过程，请参见《CNCF 沙箱指南 v1.0》。

孵化级

注：孵化级是我们期望对项目进行全面的尽职调查的起点。

要进入孵化级，项目除了满足沙箱级的要求之外还要满足：

  • 证明至少有三个独立的最终用户已成功将其用于生产，且 TOC 判断这些最终用户具有足够的质量和范围。
  • 提交者的数量要合理。提交者定义为具有提交权的人，即可以接受部分或全部项目贡献的人。
  • 显示出有大量持续提交和合并贡献。
  • 由于这些指标可能会根据项目的类型、范围和大小而有很大差异，所以 TOC 有权决定是否满足这些标准的活动水平。

毕业级

要从沙箱或孵化级毕业，或者要使一个新项目作为已毕业项目加入，项目除了必须满足孵化级的标准外还要满足：

  • 至少有两个来自组织的提交者。
  • 已获得并保持了“核心基础设施计划最佳实践徽章”。
  • 已完成独立的第三方安全审核，并发布了具有与以下示例类似的范围和质量的结果（包括已解决的关键漏洞）：https://github.com/envoyproxy/envoy#security-audit，并在毕业之前需要解决所有关键的漏洞。
  • 采用《CNCF 行为准则》。
  • 明确规定项目治理和提交流程。最好将其列在 GOVERNANCE.md 文件中，并引用显示当前提交者和荣誉提交者的 OWNERS.md 文件。
  • 至少有一个主仓的项目采用者的公开列表（例如，ADOPTERS.md 或项目网站上的徽标）。
  • 获得 TOC 的绝大多数票，进入毕业阶段。如果项目能够表现出足够的成熟度，则可以尝试直接从沙箱级过渡到毕业级。项目可以无限期保持孵化状态，但是通常预计它们会在两年内毕业。

值得关注的 9 个项目

本文不可能涵盖所有的 CNCF 项目，我将介绍最有趣的 9 个毕业和孵化的开源项目。

名称授权类型简要描述
KubernetesApache 2.0容器编排平台
PrometheusApache 2.0系统和服务监控工具
EnvoyApache 2.0边缘和服务代理
rktApache 2.0Pod 原生的容器引擎
JaegerApache 2.0分布式跟踪系统
LinkerdApache 2.0透明服务网格
HelmApache 2.0Kubernetes 包管理器
EtcdApache 2.0分布式键值存储
CRI-OApache 2.0专门用于 Kubernetes 的轻量级运行时环境

我也创建了视频材料来介绍这些项目。

毕业项目

毕业的项目被认为是成熟的，已被许多组织采用的，并且严格遵守了 CNCF 的准则。以下是三个最受欢迎的开源 CNCF 毕业项目。（请注意，其中一些描述来源于项目的网站并被做了改编。）

Kubernetes（希腊语“舵手”）

Kubernetes! 说起云原生应用，怎么能不提 Kubernetes 呢？ Google 发明的 Kubernetes 无疑是最著名的基于容器的应用程序的容器编排平台，而且它还是一个开源工具。

什么是容器编排平台？通常，一个容器引擎本身可以管理几个容器。但是，当你谈论数千个容器和数百个服务时，管理这些容器变得非常复杂。这就是容器编排引擎的用武之地。容器编排引擎通过自动化容器的部署、管理、网络和可用性来帮助管理大量的容器。

Docker Swarm 和 Mesosphere Marathon 也是容器编排引擎，但是可以肯定地说，Kubernetes 已经赢得了这场比赛（至少现在是这样）。Kubernetes 还催生了像 OKD 这样的容器即服务（CaaS）平台，它是 Kubernetes 的 Origin 社区发行版，并成了 Red Hat OpenShift 的一部分。

想开始学习，请访问 Kubernetes GitHub 仓库，并从 Kubernetes 文档页面访问其文档和学习资源。

Prometheus（普罗米修斯）

Prometheus 是 2012 年在 SoundCloud 上构建的一个开源的系统监控和告警工具。之后，许多公司和组织都采用了 Prometheus，并且该项目拥有非常活跃的开发者和用户群体。现在，它已经成为一个独立的开源项目，独立于公司之外进行维护。

title=

Prometheus 的架构

理解 Prometheus 的最简单方法是可视化一个生产系统，该系统需要 24（小时）x 365（天）都可以正常运行。没有哪个系统是完美的，也有减少故障的技术（称为容错系统），但是，如果出现问题，最重要的是尽快发现问题。这就是像 Prometheus 这样的监控工具的用武之地。Prometheus 不仅仅是一个容器监控工具，但它在云原生应用公司中最受欢迎。此外，其他开源监视工具，包括 Grafana，都借助了 Prometheus。

开始使用 Prometheus 的最佳方法是下载其 GitHub 仓库。在本地运行 Prometheus 很容易，但是你需要安装一个容器引擎。你可以在 Prometheus 网站上查看详细的文档。

Envoy（使者）

Envoy（或 Envoy 代理）是专为云原生应用设计的开源的边缘代理和服务代理。由 Lyft 创建的 Envoy 是为单一服务和应用而设计的高性能的 C++ 开发的分布式代理，同时也是为由大量微服务组成的服务网格架构而设计的通信总线和通用数据平面。Envoy 建立在 Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的基础上，Envoy 与每个应用相伴（并行）运行，并通过提供平台无关的方式提供通用特性来抽象网络。

当基础设施中的所有服务流量都经过 Envoy 网格时，很容易就可以通过一致的可观测性来可视化问题域，调整整体性能，并在单个位置添加基础功能。基本上，Envoy 代理是一个可帮助组织为生产环境构建容错系统的服务网格工具。

服务网格应用有很多替代方案，例如 Uber 的 Linkerd（下面会讨论）和 Istio。Istio 通过将其部署为 Sidecar 并利用了 Mixer 的配置模型，实现了对 Envoy 的扩展。Envoy 的显著特性有：

  • 包括所有的“ 入场筹码 table stakes （LCTT 译注：引申为基础必备特性）”特性（与 Istio 这样的控制平面组合时）
  • 带载运行时 99% 数据可达到低延时
  • 可以作为核心的 L3/L4 过滤器，提供了开箱即用的 L7 过滤器
  • 支持 gRPC 和 HTTP/2（上行/下行）
  • 由 API 驱动，并支持动态配置和热重载
  • 重点关注指标收集、跟踪和整体可监测性

要想了解 Envoy，证实其能力并实现其全部优势，需要丰富的生产级环境运行的经验。你可以在其详细文档或访问其 GitHub 仓库了解更多信息。

孵化项目

下面是六个最流行的开源的 CNCF 孵化项目。

rkt（火箭）

rkt, 读作“rocket”，是一个 Pod 原生的容器引擎。它有一个命令行接口用来在 Linux 上运行容器。从某种意义上讲，它和其他容器如 Podman、Docker 和 CRI-O 相似。

rkt 最初是由 CoreOS （后来被 Red Hat 收购）开发的，你可以在其网站上找到详细的文档，以及在 GitHub 上访问其源代码。

Jaeger（贼鸥）

Jaeger 是一个开源的端到端的分布式追踪系统，适用于云端应用。在某种程度上，它是像 Prometheus 这样的监控解决方案。但它有所不同，因为其使用场景有所扩展：

  • 分布式事务监控
  • 性能和延时优化
  • 根因分析
  • 服务依赖性分析
  • 分布式上下文传播

Jaeger 是一项 Uber 打造的开源技术。你可以在其网站上找到详细文档，以及在 GitHub 上找到其源码。

Linkerd

像创建 Envoy 代理的 Lyft 一样，Uber 开发了 Linkerd 开源解决方案用于生产级的服务维护。在某些方面，Linkerd 就像 Envoy 一样，因为两者都是服务网格工具，旨在提供平台级的可观测性、可靠性和安全性，而无需进行配置或代码更改。

但是，两者之间存在一些细微的差异。 尽管 Envoy 和 Linkerd 充当代理并可以通过所连接的服务进行上报，但是 Envoy 并不像 Linkerd 那样被设计为 Kubernetes Ingress 控制器。Linkerd 的显著特点包括：

  • 支持多种平台（Docker、Kubernetes、DC/OS、Amazon ECS 或任何独立的机器）
  • 内置服务发现抽象，可以将多个系统联合在一起
  • 支持 gRPC、HTTP/2 和 HTTP/1.x请 求和所有的 TCP 流量

你可以在 Linkerd 网站上阅读有关它的更多信息，并在 GitHub 上访问其源码。

Helm（舵轮）

Helm 基本上就是 Kubernetes 的包管理器。如果你使用过 Apache Maven、Maven Nexus 或类似的服务，你就会理解 Helm 的作用。Helm 可帮助你管理 Kubernetes 应用程序。它使用“Helm Chart”来定义、安装和升级最复杂的 Kubernetes 应用程序。Helm 并不是实现此功能的唯一方法；另一个流行的概念是 Kubernetes Operators，它被 Red Hat OpenShift 4 所使用。

你可以按照其文档中的快速开始指南或 GitHub 指南来试用 Helm。

Etcd

Etcd 是一个分布式的、可靠的键值存储，用于存储分布式系统中最关键的数据。其主要特性有：

  • 定义明确的、面向用户的 API（gRPC）
  • 自动 TLS，可选的客户端证书验证
  • 速度（可达每秒 10,000 次写入）
  • 可靠性（使用 Raft 实现分布式）

Etcd 是 Kubernetes 和许多其他技术的默认的内置数据存储方案。也就是说，它很少独立运行或作为单独的服务运行；相反，它以集成到 Kubernetes、OKD/OpenShift 或其他服务中的形式来运作。还有一个 etcd Operator 可以用来管理其生命周期并解锁其 API 管理功能：

你可以在 etcd 文档中了解更多信息，并在 GitHub上访问其源码。

CRI-O

CRI-O 是 Kubernetes 运行时接口的 OCI 兼容实现。CRI-O 用于各种功能，包括：

  • 使用 runc（或遵从 OCI 运行时规范的任何实现）和 OCI 运行时工具运行
  • 使用容器/镜像进行镜像管理
  • 使用容器/存储来存储和管理镜像层
  • 通过容器网络接口（CNI）来提供网络支持

CRI-O 提供了大量的文档，包括指南、教程、文章，甚至播客，你还可以访问其 GitHub 页面。

我错过了其他有趣且开源的云原生项目吗？请在评论中提醒我。

via: https://opensource.com/article/19/8/cloud-native-projects

作者：Bryant Son 选题：lujun9972 译者：messon007 校对：wxy

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

Amazon 已经推出了自己的基于 Linux 的开源操作系统 Bottlerocket（“瓶装火箭”）。但在你兴奋地想要尝试安装和运行它之前，我必须告诉你，它不是常规的如 Ubuntu、Fedora 或 Debian 这样的 Linux 发行版。那它是什么？

Bottlerocket：来自 Amazon 的 Linux 发行版，用于运行容器

如果你不了解 Linux 容器，建议你阅读 Red Hat 的这篇文章。

自从首次提出云计算一词以来，IT 行业发生了许多变化。得益于 Amazon AWS、Google、Linode、Digital Ocean 等云服务器提供商，部署 Linux 服务器（通常在虚拟机中运行）只需几秒钟。最重要的是，你可以借助 Docker 和 Kubernetes 之类的工具在这些服务器上以容器形式部署应用和服务。

问题是，当你唯一目的是在 Linux 系统上运行容器时，并不总是需要完整的 Linux 发行版。这就是为什么容器专用 Linux 仅提供必要软件包的原因。这将大大减少操作系统的大小，从而进一步减少部署时间。

Bottlerocket Linux 由 Amazon Web Services（AWS）专门构建，用于在虚拟机或裸机上运行容器。它支持 docker 镜像和其他遵循 OCI 镜像格式的镜像。

Bottlerocket Linux 的特性

这是来自 Amazon 的新 Linux 发行版提供的特性：

没有逐包更新

传统的 Linux 发行版更新过程由更新单个软件包组成。Bottlerocket 改用基于镜像的更新。

由于采用了这种方法，可以避免冲突和破坏，并可以进行快速而完整的回滚（如有必要）。

只读文件系统

Bottlerocket 还使用了只读主文件系统。在启动时通过 dm-verity 检查其完整性。在其他安全措施上，也不建议使用 SSH 访问，并且只能通过管理容器（附加机制）使用。

AWS 已经统治了云世界。

自动更新

你可以使用 Amazon EKS 之类的编排服务来自动执行 Bottlerocket 更新。

Amazon 还声称，与通用 Linux 发行版相比，仅包含运行容器的基本软件可以减少攻击面。

你怎么看？

Amazon 并不是第一个创建“容器专用 Linux” 的公司。我认为 CoreOS 是最早的此类发行版之一。CoreOS 被 Red Hat 收购，Red Hat 又被 IBM 收购。Red Hat 公司最近停用了 CoreOS，并用 Fedora CoreOS 代替了它。

云服务器是一个巨大的行业，它将继续发展壮大。像 Amazon 这样的巨头将竭尽所能与它竞争对手保持一致或领先。我认为，Bottlerocket 是对 IBM Fedora CoreOS（目前）的应答。

尽管 Bottlerocket 仓库可在 GitHub 上找到，但我还没发现就绪的镜像（LCTT 译注：源代码已经提供）。在撰写本文时，它仅可在 AWS 上预览。

你对此有何看法？Amazon 会从 Bottlerocket 获得什么？如果你以前使用过 CoreOS 之类的软件，你会切换到 Bottlerocket 么？

via: https://itsfoss.com/bottlerocket-linux/

作者：Abhishek Prakash 选题：lujun9972 译者：geekpi 校对：wxy

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

本文是最近一周开源社区的新闻和行业进展。

title=

我在一家采用开源软件开发模型的企业软件公司任高级产品营销经理，我的一部分职责是为产品营销人员，经理和其他相关人定期发布有关开源社区，市场和业界发展趋势的更新。以下是该更新中我和他们最喜欢的五篇文章。

云原生应用采用的技术：容器等

  • 在生产环境中采用容器的比例从 2018 年的 73% 上升到 2019 年的 84%。其中，运行了至少 250 个容器的比例从 2018 年的 46% 上升到 2019 年的 58%。2017 到 2019 年间, 环境中拥有 50 台以上计算机（物理或虚拟）的受访者人数从 2017 年的 77％ 上升到 2019 年的 81％。
  • 表明: 容器的引入似乎缓解了需要管理的 VM 的快速增长。但是，请警惕要管理的原始机器数量会减少的说法。

分析：从直觉上看，随着容器使用的增长，虚拟机的增长将放缓；有许多容器被部署在虚拟机内部，从而充分利用了两者的优势特性，而且许多应用不会很快被容器化（留意下你所在企业的传统单体式应用）。

在生产环境中运行Istio的经验

在 HelloFresh，我们将团队分为小队和团伙。每个团伙都有自己的 Kubernetes 命名空间。如上所述，我们先按命名空间启用 sidecar 注入，然后再逐个对应用启用。在将应用添加到 Istio 之前，我们举办了研讨会，以使小队了解其应用发生的变化。由于我们采用“您构建，您维护”的模型，团队可以在故障定位时了解应用的进出流量。不仅如此，它还提升了公司内部的知识量。我们还创建了 Istio 相关的 OKR ，来跟踪我们的进度并达成我们引入Istio的目的。

分析：引入或是不引入技术，要由自己决定，同时要自行承担相应的后果。

Aether: 首个开源的边缘云平台

ONF 的营销副主席 Sloane 这样解释 Aether: 它将多个正在自己的沙箱中开发和运行的项目聚集到一起，ONF 试图在该框架下将多种边缘服务在一个融合平台上支持起来。ONF 的各个项目将保持独立并可继续单独使用，但是 Aether 试图将多个能力绑定到一起来简化企业的私有边缘云运营。

他说：“我们认为我们正在创造一个新的合作空间，工业界和社区可以携手帮助推动通用平台背后的整合和关键工作，然后可以帮助这些边缘云中的通用功能不断发展”。

分析：当今，使用技术解决的问题过于复杂，无法通过单一技术解决。比技术更重要的是要解决的业务问题需要聚焦于真正增值的部分。将两者结合起来，就是企业之间需要在他们共同的需求上找到合作的方法，并在它们特有的方面进行竞争。除了开源，你找不到比这更好的方法了。

与云相关职业的女性正在改变现状

Yordanova 说:“由于云是一种相对较新的技术，我的成为一名“科技女性”的经验可能并不典型，因为云行业极为多样化”。“实际上，我的团队中性别比例相当，成员由随着云技术而成长的不同个性、文化和优势的具体人员组成。“

分析：我想考虑的一件事就是跨越式的演进思路。你可能可以跳过演进过程中的某个步骤或阶段，因为原先导致其存在的条件已不再适用。云技术时代没有形成“谁发明的以及它是为谁而生”的固有说法，所以也许它所承载的某些前代的技术负担更少？

StarlingX 如何在中国开源项目的星空中闪耀

我们的团队在中国，因此我们的任务之一是帮助中国的社区开发软件、贡献代码、文档等。大多数 StarlingX 项目会议是在中国的深夜举行，因此华人社区成员的出席和参与颇具挑战。为了克服这些障碍，我们与中国的其他社区成员（例如 99cloud 的朋友）一起采取了一些措施，例如和其他社区成员一起聚会，一起参加动手实践研讨会和中文的特设技术会议，将一些文档翻译成中文，并在微信小组中不断进行互动（就像每个人都可以享受的 24/7 通话服务一样）

分析：随着中国对开源项目的贡献不断增长，这种情况似乎有可能逆转或至少相当。“学习英语”根本不是参与开源项目开发的先决条件。

希望你喜欢这个列表，下周再见。

via: https://opensource.com/article/20/3/survey-istio-industry-news

作者：Tim Hildred 选题：lujun9972 译者：messon007 校对：wxy

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

Toolbox 使你可以在容器中分类和管理开发环境，而无需 root 权限或手动添加卷。它创建一个容器，你可以在其中安装自己的命令行工具，而无需在基础系统中安装它们。当你没有 root 权限或无法直接安装程序时，也可以使用它。本文会介绍 Toolbox 及其功能。

安装 Toolbox

Silverblue 默认包含 Toolbox。对于 Workstation 和 Server 版本，你可以使用 dnf install toolbox 从默认仓库中获取它。

创建 Toolbox

打开终端并运行 toolbox enter。程序将自动请求许可来下载最新的镜像，创建第一个容器并将你的 shell 放在该容器中。

$ toolbox enter
No toolbox containers found. Create now? [y/N] y
Image required to create toolbox container.
Download registry.fedoraproject.org/f30/fedora-toolbox:30 (500MB)? [y/N]: y

当前，Toolbox 和你的基本系统之间没有区别。你的文件系统和软件包未曾改变。下面是一个使用仓库的示例，它包含 ~/src/resume 文件夹下的简历的文档源文件。简历是使用 pandoc 工具构建的。

$ pwd
/home/rwaltr
$ cd src/resume/
$ head -n 5 Makefile
all: pdf html rtf text docx

pdf: init
 pandoc -s -o BUILDS/resume.pdf markdown/*

$ make pdf
bash: make: command not found
$ pandoc -v
bash: pandoc: command not found

这个 toolbox 没有构建简历所需的程序。你可以通过使用 dnf 安装工具来解决此问题。由于正在容器中运行，因此不会提示你输入 root 密码。

$ sudo dnf groupinstall "Authoring and Publishing" -y && sudo dnf install pandoc make -y
...
$ make all #Successful builds
mkdir -p BUILDS
pandoc -s -o BUILDS/resume.pdf markdown/*
pandoc -s -o BUILDS/resume.html markdown/*
pandoc -s -o BUILDS/resume.rtf markdown/*
pandoc -s -o BUILDS/resume.txt markdown/*
pandoc -s -o BUILDS/resume.docx markdown/*
$ ls BUILDS/
resume.docx  resume.html  resume.pdf  resume.rtf  resume.txt

运行 exit 可以退出 toolbox。

$ cd BUILDS/
$ pandoc --version || ls
pandoc 2.2.1
Compiled with pandoc-types 1.17.5.4, texmath 0.11.1.2, skylighting 0.7.5
...
for a particular purpose.
resume.docx  resume.html  resume.pdf  resume.rtf  resume.txt
$ exit
logout
$ pandoc --version || ls
bash: pandoc: command not found...
resume.docx  resume.html  resume.pdf  resume.rtf  resume.txt

你会在主目录中得到由 toolbox 创建的文件。而在 toolbox 中安装的程序无法在外部访问。

提示和技巧

本介绍仅涉及 toolbox 的表面。还有一些其他提示，但是你也可以查看官方文档。

  • toolbox –help 会显示 Toolbox 的手册页。
  • 你可以一次有多个 toolbox。使用 toolbox create -c Toolboxname 和 toolbox enter -c Toolboxname。
  • Toolbox 使用 Podman 来完成繁重的工作。使用 toolbox list 可以查找 Toolbox 创建的容器的 ID。Podman 可以使用这些 ID 来执行 rm 和 stop 之类的操作。 （你也可以在此文章中阅读有关 Podman 的更多信息。）

via: https://fedoramagazine.org/a-quick-introduction-to-toolbox-on-fedora/

作者：Ryan Walter 选题：lujun9972 译者：geekpi 校对：wxy

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

今天早上，我为未来潜在容器杂志画了一幅 OverlayFS 的漫画，我对这个主题感到兴奋，想写一篇关于它的博客来提供更多详细信息。

容器镜像很大

容器镜像可能会很大（尽管有些很小，例如 alpine linux 才 2.5MB）。Ubuntu 16.04 约为 27 MB，Anaconda Python 发行版为 800MB 至 1.5GB。

你以镜像启动的每个容器都是原始空白状态，仿佛它只是为使用容器而复制的一份镜像拷贝一样。但是对于大的容器镜像，像 800MB 的 Anaconda 镜像，复制一份拷贝既浪费磁盘空间也很慢。因此 Docker 不会复制，而是采用叠加。

叠加如何工作

OverlayFS，也被称为 联合文件系统或 联合挂载，它可让你使用 2 个目录挂载文件系统：“下层”目录和“上层”目录。

基本上：

  • 文件系统的下层目录是只读的
  • 文件系统的上层目录可以读写

当进程“读取”文件时，OverlayFS 文件系统驱动将在上层目录中查找并从该目录中读取文件（如果存在）。否则，它将在下层目录中查找。

当进程“写入”文件时，OverlayFS 会将其写入上层目录。

让我们使用 mount 制造一个叠加层！

这有点抽象，所以让我们制作一个 OverlayFS 并尝试一下！这将只包含一些文件：我将创建上、下层目录，以及用来挂载合并的文件系统的 merged 目录：

$ mkdir upper lower merged work
$ echo "I'm from lower!" > lower/in_lower.txt
$ echo "I'm from upper!" > upper/in_upper.txt
$ # `in_both` is in both directories
$ echo "I'm from lower!" > lower/in_both.txt
$ echo "I'm from upper!" > upper/in_both.txt

合并上层目录和下层目录非常容易：我们可以通过 mount 来完成！

$ sudo mount -t overlay overlay
    -o lowerdir=/home/bork/test/lower,upperdir=/home/bork/test/upper,workdir=/home/bork/test/work
    /home/bork/test/merged

在执行此操作时，我不断收到一条非常烦人的错误消息，内容为：mount: /home/bork/test/merged: special device overlay does not exist.。这条消息是错误的，实际上只是意味着我指定的一个目录缺失（我写成了 ~/test/merged，但它没有被展开）。

让我们尝试从 OverlayFS 中读取其中一个文件！文件 in_both.txt 同时存在于 lower/ 和 upper/ 中，因此应从 upper/ 目录中读取该文件。

$ cat merged/in_both.txt
"I'm from upper!

可以成功！

目录的内容就是我们所期望的：

find lower/ upper/ merged/
lower/
lower/in_lower.txt
lower/in_both.txt
upper/
upper/in_upper.txt
upper/in_both.txt
merged/
merged/in_lower.txt
merged/in_both.txt
merged/in_upper.txt

创建新文件时会发生什么？

$ echo 'new file' > merged/new_file
$ ls -l */new_file
-rw-r--r-- 1 bork bork 9 Nov 18 14:24 merged/new_file
-rw-r--r-- 1 bork bork 9 Nov 18 14:24 upper/new_file

这是有作用的，新文件会在 upper 目录创建。

删除文件时会发生什么？

读写似乎很简单。但是删除会发生什么？开始试试！

$ rm merged/in_both.txt

发生了什么？让我们用 ls 看下：

ls -l upper/in_both.txt  lower/lower1.txt  merged/lower1.txt
ls: cannot access 'merged/in_both.txt': No such file or directory
-rw-r--r-- 1 bork bork    6 Nov 18 14:09 lower/in_both.txt
c--------- 1 root root 0, 0 Nov 18 14:19 upper/in_both.txt

所以：

  • in_both.txt 仍在 lower 目录中，并且保持不变
  • 它不在 merged 目录中。到目前为止，这就是我们所期望的。
  • 但是在 upper 中发生的事情有点奇怪：有一个名为 upper/in_both.txt 的文件，但是它是字符设备？我想这就是 overlayfs 驱动表示删除的文件的方式。

如果我们尝试复制这个奇怪的字符设备文件，会发生什么？

$ sudo cp upper/in_both.txt upper/in_lower.txt
cp: cannot open 'upper/in_both.txt' for reading: No such device or address

好吧，这似乎很合理，复制这个奇怪的删除信号文件并没有任何意义。

你可以挂载多个“下层”目录

Docker 镜像通常由 25 个“层”组成。OverlayFS 支持具有多个下层目录，因此你可以运行：

mount -t overlay overlay
      -o lowerdir:/dir1:/dir2:/dir3:...:/dir25,upperdir=...

因此，我假设这是有多个 Docker 层的容器的工作方式，它只是将每个层解压缩到一个单独的目录中，然后要求 OverlayFS 将它们全部合并在一起，并使用一个空的上层目录，容器将对其进行更改。

Docker 也可以使用 btrfs 快照

现在，我使用的是 ext4，而 Docker 使用 OverlayFS 快照来运行容器。但是我曾经用过 btrfs，接着 Docker 将改为使用 btrfs 的写时复制快照。（这是 Docker 何时使用哪种存储驱动的列表）

以这种方式使用 btrfs 快照会产生一些有趣的结果：去年某个时候，我在笔记本上运行了数百个临时的 Docker 容器，这导致我用尽了 btrfs 元数据空间（像这个人一样）。这真的很令人困惑，因为我以前从未听说过 btrfs 元数据，而且弄清楚如何清理文件系统以便再次运行 Docker 容器非常棘手。（这个 docker github 上的提案描述了 Docker 和 btrfs 的类似问题）

以简单的方式尝试容器功能很有趣！

我认为容器通常看起来像是在做“复杂的”事情，我认为将它们分解成这样很有趣。你可以运行一条 mount 咒语，而实际上并没有做任何与容器相关的其他事情，看看叠加层是如何工作的！

via: https://jvns.ca/blog/2019/11/18/how-containers-work–overlayfs/

作者：Julia Evans 选题：lujun9972 译者：geekpi 校对：wxy

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

了解如何使用 Ansible 在容器中执行命令。

容器和 Ansible 可以很好地融合在一起：从管理和编排到供应和构建。在本文中，我们将重点介绍构建部分。

如果你熟悉 Ansible，就会知道你可以编写一系列任务，ansible-playbook 命令将为你执行这些任务。你知道吗，如果你编写 Dockerfile 并运行 podman build，你还可以在容器环境中执行此类命令，并获得相同​​的结果。

这是一个例子：

- name: Serve our file using httpd
  hosts: all
  tasks:
  - name: Install httpd
    package:
      name: httpd
      state: installed
  - name: Copy our file to httpd’s webroot
    copy:
      src: our-file.txt
      dest: /var/www/html/

你可以在 Web 服务器本地或容器中执行这个剧本，并且只要你记得先创建 our-file.txt，它就可以工作。

但是这里缺少了一些东西。你需要启动（并配置）httpd 以便提供文件。这是容器构建和基础架构供应之间的区别：构建镜像时，你只需准备内容；而运行容器是另一项任务。另一方面，你可以将元数据附加到容器镜像，它会默认运行命令。

这有个工具可以帮助。试试看 ansible-bender 怎么样？

$ ansible-bender build the-playbook.yaml fedora:30 our-httpd

该脚本使用 ansible-bender 对 Fedora 30 容器镜像执行该剧本，并将生成的容器镜像命名为 our-httpd。

但是，当你运行该容器时，它不会启动 httpd，因为它不知道如何操作。你可以通过向该剧本添加一些元数据来解决此问题：

- name: Serve our file using httpd
  hosts: all
  vars:
    ansible_bender:
      base_image: fedora:30
      target_image:
        name: our-httpd
        cmd: httpd -DFOREGROUND
  tasks:
  - name: Install httpd
    package:
      name: httpd
      state: installed
  - name: Listen on all network interfaces.
    lineinfile:    
      path: /etc/httpd/conf/httpd.conf  
      regexp: '^Listen '
      line: Listen 0.0.0.0:80  
  - name: Copy our file to httpd’s webroot
    copy:
      src: our-file.txt
      dest: /var/www/html

现在你可以构建镜像（从这里开始，请以 root 用户身份运行所有命令。目前，Buildah 和 Podman 不会为无 root 容器创建专用网络）：

# ansible-bender build the-playbook.yaml
PLAY [Serve our file using httpd] ****************************************************
                                                                                                                                                                             
TASK [Gathering Facts] ***************************************************************    
ok: [our-httpd-20191004-131941266141-cont]

TASK [Install httpd] *****************************************************************
loaded from cache: 'f053578ed2d47581307e9ba3f64f4b4da945579a082c6f99bd797635e62befd0'
skipping: [our-httpd-20191004-131941266141-cont]

TASK [Listen on all network interfaces.] *********************************************
changed: [our-httpd-20191004-131941266141-cont]

TASK [Copy our file to httpd’s webroot] **********************************************
changed: [our-httpd-20191004-131941266141-cont]

PLAY RECAP ***************************************************************************
our-httpd-20191004-131941266141-cont : ok=3    changed=2    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

Getting image source signatures
Copying blob sha256:4650c04b851c62897e9c02c6041a0e3127f8253fafa3a09642552a8e77c044c8
Copying blob sha256:87b740bba596291af8e9d6d91e30a01d5eba9dd815b55895b8705a2acc3a825e
Copying blob sha256:82c21252bd87532e93e77498e3767ac2617aa9e578e32e4de09e87156b9189a0
Copying config sha256:44c6dc6dda1afe28892400c825de1c987c4641fd44fa5919a44cf0a94f58949f
Writing manifest to image destination
Storing signatures
44c6dc6dda1afe28892400c825de1c987c4641fd44fa5919a44cf0a94f58949f
Image 'our-httpd' was built successfully \o/

镜像构建完毕，可以运行容器了：

# podman run our-httpd
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.88.2.106. Set the 'ServerName' directive globally to suppress this message

是否提供文件了？首先，找出你容器的 IP：

# podman inspect -f '{{ .NetworkSettings.IPAddress }}' 7418570ba5a0
10.88.2.106

你现在可以检查了：

$ curl http://10.88.2.106/our-file.txt
Ansible is ❤

你文件内容是什么？

这只是使用 Ansible 构建容器镜像的介绍。如果你想了解有关 ansible-bender 可以做什么的更多信息，请查看它的 GitHub 页面。构建快乐！

via: https://opensource.com/article/19/10/building-container-images-ansible

作者：Tomas Tomecek 选题：lujun9972 译者：geekpi 校对：wxy

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

  1. 1
  2. ...
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. ...
  11. 24