开放容器计划 Open Container Initiative （OCI）宣布本周完成了容器运行时和镜像的第一版规范。OCI 在是 Linux 基金会 Linux Foundation 支持下的容器解决方案标准化的成果。两年来，为了建立这些规范已经付出了大量的努力。 由此，让我们一起来回顾过去两年中出现的一些误区。

误区：OCI 是 Docker 的替代品

诚然标准非常重要，但它们远非一个完整的生产平台。 以万维网为例，它 25 年来一路演进，建立在诸如 TCP/IP 、HTTP 和 HTML 等可靠的核心标准之上。再以 TCP/IP 为例，当企业将 TCP/IP 合并为一种通用协议时，它推动了路由器行业，尤其是思科的发展。 然而，思科通过专注于在其路由平台上提供差异化的功能，而成为市场的领导者。我们认为 OCI 规范和 Docker 也是类似这样并行存在的。

Docker 是一个完整的生产平台，提供了基于容器的开发、分发、安全、编排的一体化解决方案。Docker 使用了 OCI 规范，但它大约只占总代码的 5％，而且 Docker 平台只有一小部分涉及容器的运行时行为和容器镜像的布局。

误区：产品和项目已经通过了 OCI 规范认证

运行时和镜像规范本周刚发布 1.0 的版本。 而且 OCI 认证计划仍在开发阶段，所以企业在该认证正式推出之前（今年晚些时候），没法要求容器产品的合规性、一致性或兼容性。

OCI 认证工作组目前正在制定标准，使容器产品和开源项目能够符合规范的要求。标准和规范对于实施解决方案的工程师很重要，但正式认证是向客户保证其正在使用的技术真正符合标准的唯一方式。

误区：Docker 不支持 OCI 规范的工作

Docker 很早就开始为 OCI 做贡献。 我们向 OCI 贡献了大部分的代码，作为 OCI 项目的维护者，为 OCI 运行时和镜像规范定义提供了积极有益的帮助。Docker 运行时和镜像格式在 2013 年开源发布之后，便迅速成为事实上的标准，我们认为将代码捐赠给中立的管理机构，对于避免容器行业的碎片化和鼓励行业创新将是有益的。我们的目标是提供一个可靠和标准化的规范，因此 Docker 提供了一个简单的容器运行时 runc 作为运行时规范工作的基础，后来又贡献了 Docker V2 镜像规范作为 OCI 镜像规范工作的基础。

Docker 的开发人员如 Michael Crosby 和 Stephen Day 从一开始就是这项工作的关键贡献者，确保能将 Docker 的托管和运行数十亿个容器镜像的经验带给 OCI。等认证工作组完成（制定认证规范的）工作后，Docker 将通过 OCI 认证将其产品展示出来，以证明 OCI 的一致性。

误区：OCI 仅用于 Linux 容器技术

因为 OCI 是由 Linux 基金会 Linux Foundation 负责制定的，所以很容易让人误解为 OCI 仅适用于 Linux 容器技术。 而实际上并非如此，尽管 Docker 技术源于 Linux 世界，但 Docker 也一直在与微软合作，将我们的容器技术、平台和工具带到 Windows Server 的世界。 此外，Docker 向 OCI 贡献的基础技术广泛适用于包括 Linux 、Windows 和 Solaris 在内的多种操作系统环境，涵盖了 x86、ARM 和 IBM zSeries 等多种架构环境。

误区：Docker 仅仅是 OCI 的众多贡献者之一

OCI 作为一个支持成员众多的开放组织，代表了容器行业的广度。 也就是说，它是一个小而专业的个人技术专家组，为制作初始规范的工作贡献了大量的时间和技术。 Docker 是 OCI 的创始成员，贡献了初始代码库，构成了运行时规范的基础和后来的参考实现。 同样地，Docker 也将 Docker V2 镜像规范贡献给 OCI 作为镜像规范的基础。

误区：CRI-O 是 OCI 项目

CRI-O 是 云计算基金会 Cloud Native Computing Foundation （CNCF）的 Kubernetes 孵化器的开源项目 -- 它不是 OCI 项目。 它基于早期版本的 Docker 体系结构，而 containerd 是一个直接的 CNCF 项目，它是一个包括 runc 参考实现的更大的容器运行时。 containerd 负责镜像传输和存储、容器运行和监控，以及支持存储和网络附件等底层功能。 Docker 在五个最大的云提供商（阿里云、AWS、Google Cloud Platform（GCP）、IBM Softlayer 和 Microsoft Azure）的支持下，将 containerd 捐赠给了云计算基金会（CNCF），作为多个容器平台和编排系统的核心容器运行时。

误区：OCI 规范现在已经完成了

虽然首版容器运行时和镜像格式规范的发布是一个重要的里程碑，但还有许多工作有待完成。 OCI 一开始着眼于定义一个狭窄的规范：开发人员可以依赖于容器的运行时行为，防止容器行业碎片化，并且仍然允许在不断变化的容器域中进行创新。之后才将含容器镜像规范囊括其中。

随着工作组完成运行时行为和镜像格式的第一个稳定规范，新的工作考量也已经同步展开。未来的新特性将包括分发和签名等。 然而，OCI 的下一个最重要的工作是提供一个由测试套件支持的认证过程，因为第一个规范已经稳定了。

在 Docker 了解更多关于 OCI 和开源的信息：

• 阅读关于 [OCI v1.0 版本的运行时和镜像格式规范]的博文[1]
• 访问 OCI 的网站
• 访问 Moby 项目网站
• 参加 DockerCon Europe 2017
• 参加 Moby Summit LA

作者简介：

Stephen 是 Docker 开源项目总监。 他曾在 Hewlett-Packard Enterprise （惠普企业）担任董事和杰出技术专家。他的关于开源软件和商业的博客发布在 “再次违约”(http://stephesblog.blogs.com) 和网站 opensource.com 上。

via: https://blog.docker.com/2017/07/demystifying-open-container-initiative-oci-specifications/

作者：Stephen 译者：rieonke 校对：wxy

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

CoreOS 和 开放容器联盟（OCI） 周三（2017 年 7 月 19 日）发布的镜像和运行时标准主要参照了 Docker 的镜像格式技术。

然而，OCI 决定在 Docker 的事实标准平台上建立模型引发了一些问题。一些批评者提出其他方案。

CoreOS 的 CTO 及 OCI 技术管理委员会主席 Brandon Philips 说， 1.0版本为应用容器提供了一个稳定标准。他说，拥有产业领导者所创造的标准，应能激发 OCI 合作伙伴进一步地发展标准和创新。Philips 补充道，OCI 完成 1.0 版本意味着 OCI 运行时规范和 OCI 镜像格式标准现在已经可以广泛使用。此外，这一成就将推动 OCI 社区稳固日益增长的可互操作的可插拔工具集市场。

产业支持的标准将提供一种信心：容器已被广泛接受，并且 Kubernetes 用户将获得更进一步的支持。

Philips 告诉 LinuxInsider，结果是相当不错的，认证流程已经开始。

合作挑战

Philips 说，开放标准是容器生态系统取得成功的关键，构建标准的最好方式是与社区密切协作。然而，在 1.0 版本上达成共识所花费的时间超出了预期。

“早期，最大的挑战在于如今解决项目的发布模式及如何实施该项目”，他追述道，”每个人都低估了项目所要花费的时间。“

他说，OCI 联盟成员对他们想做的事情抱有不相匹配的预期，但是在过去的一年中，该组织了解了期望程度，并且经历了更多的测试。

追逐标准

CoreOS 官方在几年前就开始讨论行业支持的容器镜像和运行时规范的开放标准的想法，Phillips 说，早期的探索使我们认识到：在标准镜像格式上达成一致是至关重要的。

CoreOS 和容器技术创造者 Docker 在 2015 年 6 月宣布 OCI 成立。合作起始于 21 个行业领导者制定开放容器计划（OCP）。它作为一个非营利组织，旨在建立云存储软件容器的最低通用标准。

联盟包括容器业界的领导者：Docker、微软、红帽、IBM、谷歌和 Linux 基金会。

OCI 的目的是让应用开发者相信：当新的规范出来并开发出新的工具时，部署在容器上的软件仍然能够持续运行。这种信心必须同时满足所有私有和开源软件。

工具和应用是私有还是开源的并没有什么关系。当规范开始应用，产品可以被设计成与任何容器配置相适应，Philips 说。

“你需要有意识地超越编写代码的人能力之外创建标准。它是一个额外的付出。”他补充道。

作为联盟的一部分，Docker 向 OCP（开放容器计划）捐献出它的镜像格式的事实标准技术。它包括该公司的容器格式、运行时代码和规范。建立 OCI 镜像标准的工作起始于去年。

标准的里程碑给予容器使用者开发、打包、签名应用容器的能力。他们也能够在各种容器引擎上运行容器，Philips 强调。

唯一选择？

Pund-IT 的首席分析师 Charles King 表示：联盟面临着两种实现标准的方式。第一种选择是汇集相同意向的人员来避免分歧从零开始建立标准。

但是联盟成员似乎满足于第二种方案：采用一种强大的市场领先的平台作为一个有效的标准。

“Docker 对 Linux 基金会的贡献使 OCI 坚定的选择了第二种方案。但是那些关注于 Docker 的做法和它的市场地位的人也许感觉应该有更好的选择。”King 对 LinuxInsider 说。

事实上，有个 OCI 成员 CoreOS 在开始的时候对该组织的总体方向进行了一些强烈的批评。他说，“所以看看 V1.0 版本是否处理或不处理那些关注点将是很有趣的事情。”

更快之路

Docker 已经被广泛部署的运行时实现是建立开放标准的合适基础。据 Cloud Technology Partners 的高级副总裁 David Linthicum 所说，Docker 已经是一个事实标准。

“我们能很快就让它们工作起来也是很重要的。但是一次次的标准会议、处理政治因素以及诸如此类的事情只是浪费时间” 。他告诉 LinuxInsider。

但是现在没有更好的选择，他补充道。

据 RedHat 公司的 Linux 容器技术高级布道者 Joe Brockmeier 所说，Docker 的运行时是 runC 。它是 OCI 运行时标准的一种实现。

“因此，runC 是一个合适的运行时标准的基础。它被广泛的接受并成为了大多数容器技术实现的基础。他说。

OCI 是比 Docker 更进一步的标准。尽管 Docker 确实提交了遵循 OCI 规范的底层代码，然而这一系列代码就此停止，并且没真正的可行替代方案存在。

对接问题

Pund-IT 的 King 建议：采用一种广泛使用的产业标准将简化和加速许多公司对容器技术的采纳和管理。也有可能一些关键的供应商将继续关注他们自己的专有容器技术。

“他们辩称他们的做法是一个更好的方式，但这将有效的阻止 OCI 取得市场的主导地位。”他说，“从一个大体上实现的标准开始，就像 OCI 所做的那样，也许并不能完美的使所有人满意，但是这也许能比其他方案更加快速有效的实现目标。”

容器已经标准化的部署到了云上，Docker 显然是领先的。Semaphore 联合创始人 Marko Anastasov 说。

他说，Docker 事实标准的容器代表了开发开放标准的的最佳基础。Docker 的商业利益将如何影响其参与 OCI 的规模还有待观察。

反对观点

开放标准并不是在云部署中采用更多的容器的最终目标。ThoughtWorks 的首席顾问 Nic Cheneweth 表示。更好的的方法是查看 IT 行业的服务器虚拟化部分的影响。

Cheneweth 对 LinuxInsider 说：“持续增长和广泛采用的主要动力不是在行业标准的声明中，而是通过使用任何竞争技术所获得的潜在的和实现的效率，比如 VMware、Xen 等。”

容器技术的某些方面，例如容器本身，可以根据标准来定义。他说，在此之前，深入开源软件参与引导的健康竞争将有助于成为一个更好的标准。

据 Cheneweth 说，容器编排标准对该领域的持续增长并不特别重要。

不过，他表示，如果行业坚持锁定容器事实标准，那么 OCI 所选择的模型是一个很好的起点。“我不知道是否有更好的选择，但肯定这不是最糟糕的选择。”

作者简介：

自 2003 年以来，Jack M.Germain一直是一个新闻网络记者。他主要关注的领域是企业 IT、Linux 和开源技术。他已经写了很多关于 Linux 发行版和其他开源软件的评论。

via: http://www.linuxinsider.com/story/84689.html

作者：Jack M. Germain 译者：LHRchina 校对：wxy

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

有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。

那都是废话。

虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。

让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。

让我们从 Docker 开始……

Docker 公司，始于名为 dotCloud 的平台即服务（PaaS）供应商。dotCloud 团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将 Linux 的 cgroups 和 namespace 的一些功能合并成一个单一且易于使用的软件包，以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的 Docker 镜像，它提供了如下的功能：

• 将应用程序和依赖库封装在一个软件包（即 Docker 镜像）中，因此应用可以被一致地部署在各个环境上；
• 提供类似 Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；
• 定义 Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；
• 通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为 容器编排 container orchestration 。有趣的是，第一个支持 Docker 镜像的容器编排工具（2014 年 6月）是 Apache Mesos 的 Marathon（后面会有详细介绍) 。那年，Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后，除了 Mesos 的 Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernetes，不出所料还有 Docker Swarm （它如今是 Docker 引擎的一部分）。

随着 Docker 开始商业化其开源的文件格式（LCTT 译注：指 Docker 镜像的 dockerfile 文件格式），该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎，包括：

• 为公开存储 Docker 镜像的而生的 Docker hub；
• 存储私有镜像的 Docker 仓库（Docker registry）；
• Docker cloud，用于构建和运行容器的管理性服务；
• Docker 数据中心作为一种商业产品体现了许多 Docker 技术；

来源: www.docker.com

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准，领先的容器技术供应商（包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会 Cloud Native Computing Foundation (CNCF) 和 开放容器推进联盟 Open Container Initiative (OCI)。如今，CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行。

进入 Kubernetes

Google 很早就认识到了 Docker 的潜力，并试图在 Google Cloud Platform （GCP）上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验（是他们在 Linux 中引入了 cgroups），但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合。所以，Google 没有使用原有系统的任何代码，而是从头开始设计 Kubernetes （K8S）来编排 Docker 容器。 Kubernetes 于 2015 年 2 月发布，其目标和考虑如下：

• 为应用程序开发人员提供编排 Docker 容器的强大工具，而无需与底层基础设施交互；
• 提供标准部署接口和原语，以实现云端一致的应用部署体验和 API;
• 基于模块化 API 核心，允许供应商围绕 Kubernetes 的核心技术集成其系统。

2016 年 3 月，Google 将 Kubernetes 捐赠给了 CNCF，并且直到今天仍然是该项目的主要贡献者（其次是Redhat，CoreOS 等）。

来源: wikipedia

Kubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的 Kubernetes（这仍然是一个值得重视的挑战）提供商业解决方案。 Kubernetes 也是有吸引力的，因为它是 CNCF 旗下的开源项目，与 Docker Swarm 相反，Docker Swarm 尽管是开源的，但是被 Docker 公司紧紧地掌控着。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务），但这些提议仍处于非常早期的阶段，它们能取得多大的成功还有待观察。

Apache Mesos

Apache Mesos 始于 加州大学伯克利分校 UC Berkeley 的下一代容器集群管理器项目，并应用了从云计算级别的分布式基础架构（如 Google 的 Borg 和 Facebook 的 Tupperware）中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但 Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。

作为集群管理器，Mesos 被设计用来解决一系列不同的挑战：

• 将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；
• 在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;
• 为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；
• 提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；
• 弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

Mesos 独有的独立管理各种工作负载的能力 —— 包括 Java 这样的传统应用程序、无状态 Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”（类似于操作中的运行手册）中来实现应用程序感知调度。资源管理器 Mesos Master 提供了这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的，这让 Mesos 拥有高度可扩展的能力，支持新的工作负载或随着时间的推移而增加更多的操作功能。

举一个团队如何管理应用软件升级的例子。无状态应用程序可以从“蓝/绿”部署方案中受益；当新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次，此时需要持久化本地数据卷以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。

Mesos 以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将 Mesos 作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”（LCTT 译注：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是时候搞清楚这些了

请注意，我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢？容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就 Marathon，一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档（如 JAR、tarball、ZIP 文件）而开发的，是 2014 年最先支持 Docker 容器的编排工具之一。

所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时，他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。

为什么搞清楚这一点很重要？ 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。

来源: Apache Mesos 2016 调查问卷

Mesos 的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下（成千上万台服务器）运行了超过 7 年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。

我所说的这些什么意思？

总而言之，所有这三种技术都与 Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。

如果你们是一个开发人员或者 DevOps 的团队，并希望构建一个专门用于 Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如 Google 容器引擎（GCE）或 Azure 容器服务（ACS）），Kubernetes 是一个可以考虑的好技术。

如果你们想要建立一个运行多个关键任务工作负载的可靠平台，包括 Docker 容器、传统应用程序（例如 Java）和分布式数据服务（例如 Spark、Kafka、Cassandra、Elastic），并希望所有这些可依移植到云端提供商或者数据中心，那么 Mesos（或我们自己的 Mesos 发行版，Mesosphere DC/OS）更适合你们的需求。

无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。你的选择真的不会有错。

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

作者：Amr Abdelrazik 译者：rieonke 校对：wxy

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

长久以来 LXD 已经支持多种存储驱动。用户可以在 zfs、btrfs、lvm 或纯目录存储池之间进行选择，但他们只能使用单个存储池。一个被频繁被提到的需求是不仅支持单个存储池，还支持多个存储池。这样，用户可以维护一个由 SSD 支持的 zfs 存储池用于 I/O 密集型容器，另一个简单的基于目录的存储池用于其他容器。幸运的是，现在这是可能的，因为 LXD 在几个版本后有了自己的存储管理 API。

创建存储池

新安装 LXD 没有定义任何存储池。如果你运行 lxd init ，LXD 将提供为你创建一个存储池。由 lxd init 创建的存储池将是创建容器的默认存储池。

创建更多的存储池

我们的客户端工具使得创建额外的存储池变得非常简单。为了创建和管理新的存储池，你可以使用 lxc storage 命令。所以如果你想在块设备 /dev/sdb 上创建一个额外的 btrfs 存储池，你只需使用 lxc storage create my-btrfs btrfs source=/dev/sdb。让我们来看看：

在默认存储池上创建容器

如果你从全新安装的 LXD 开始，并通过 lxd init 创建了一个存储池，LXD 将使用此池作为默认存储池。这意味着如果你执行 lxc launch images:ubuntu/xenial xen1，LXD 将为此存储池上的容器的根文件系统创建一个存储卷。在示例中，我们使用 my-first-zfs-pool 作为默认存储池。

在特定存储池上创建容器

但是你也可以通过传递 -s 参数来告诉 lxc launch 和 lxc init 在特定存储池上创建一个容器。例如，如果要在 my-btrfs 存储池上创建一个新的容器，你可以执行 lxc launch images:ubuntu/xenial xen-on-my-btrfs -s my-btrfs：

创建自定义存储卷

如果你其中一个容器需要额外的空间存储额外的数据，那么新的存储 API 将允许你创建可以连接到容器的存储卷。只需要 lxc storage volume create my-btrfs my-custom-volume：

连接自定义卷到容器中

当然，这个功能是有用的，因为存储 API 让你把这些存储卷连接到容器。要将存储卷连接到容器，可以使用 lxc storage volume attach my-btrfs my-custom-volume xen1 data /opt/my/data：

在容器之间共享自定义存储卷

默认情况下，LXD 将使连接的存储卷由其所连接的容器写入。这意味着它会将存储卷的所有权更改为容器的 id 映射。但存储卷也可以同时连接到多个容器。这对于在多个容器之间共享数据是非常好的。但是，这有一些限制。为了将存储卷连接到多个容器，它们必须共享相同的 id 映射。让我们创建一个额外的具有一个隔离的 id 映射的容器 xen-isolated。这意味着它的 id 映射在这个 LXD 实例中将是唯一的，因此没有其他容器具有相同的id映射。将相同的存储卷 my-custom-volume 连接到此容器现在将会失败：

但是我们让 xen-isolated 与 xen1 有相同的映射，并把它重命名为 xen2 来反映这个变化。现在我们可以将 my-custom-volume 连接到 xen1 和 xen2 而不会有问题：

总结

存储 API 是 LXD 非常强大的补充。它提供了一组基本功能，有助于在大规模使用容器时处理各种问题。这个简短的介绍希望给你一个印象，你可以做什么。将来会有更多介绍。

本篇文章最初在 Brauner 的博客中发布。

via: https://insights.ubuntu.com/2017/07/12/storage-management-in-lxd-2-15/

作者：Christian Brauner 译者：geekpi 校对：wxy

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

什么是 Docker Compose

Docker Compose 是一个运行多容器 Docker 应用的工具。Compose 通过一个配置文件来配置一个应用的服务，然后通过一个命令创建并启动所有在配置文件中指定的服务。

Docker Compose 适用于许多不同的项目，如：

• 开发：利用 Compose 命令行工具，我们可以创建一个隔离（而可交互）的环境来承载正在开发中的应用程序。通过使用 Compose 文件，开发者可以记录和配置所有应用程序的服务依赖关系。
• 自动测试：此用例需求一个测试运行环境。Compose 提供了一种方便的方式来管理测试套件的隔离测试环境。完整的环境在 Compose 文件中定义。

Docker Compose 是在 Fig 的源码上构建的，这个社区项目现在已经没有使用了。

在本教程中，我们将看到如何在 Ubuntn 16.04 上安装 Docker Compose。

安装 Docker

我们需要安装 Docker 来安装 Docker Compose。首先为官方 Docker 仓库添加公钥。

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

接下来，添加 Docker 仓库到 apt 源列表：

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

更新包数据库，并使用 apt 安装 Docker

$ sudo apt-get update
$ sudo apt install docker-ce

在安装进程结束后，Docker 守护程序应该已经启动并设为开机自动启动。我们可以通过下面的命令来查看它的状态：

$ sudo systemctl status docker
---------------------------------

● docker.service - Docker Application Container Engine
 Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
 Active: active (running) 

安装 Docker Compose

现在可以安装 Docker Compose 了。通过执行以下命令下载当前版本。

# curl -L https://github.com/docker/compose/releases/download/1.14.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

为二进制文件添加执行权限：

# chmod +x /usr/local/bin/docker-compose

检查 Docker Compose 版本：

$ docker-compose -v

输出应该如下：

docker-compose version 1.14.0, build c7bdf9e

测试 Docker Compose

Docker Hub 包含了一个用于演示的 Hello World 镜像，可以用来说明使用 Docker Compose 来运行一个容器所需的配置。

创建并打开一个目录：

$ mkdir hello-world
$ cd hello-world

创建一个新的 YAML 文件：

$ $EDITOR docker-compose.yml

在文件中粘贴如下内容：

unixmen-compose-test:
 image: hello-world

注意: 第一行是容器名称的一部分。

保存并退出。

运行容器

接下来，在 hello-world 目录执行以下命令：

$ sudo docker-compose up

如果一切正常，Compose 输出应该如下：

Pulling unixmen-compose-test (hello-world:latest)...
latest: Pulling from library/hello-world
b04784fba78d: Pull complete
Digest: sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f
Status: Downloaded newer image for hello-world:latest
Creating helloworld_unixmen-compose-test_1 ... 
Creating helloworld_unixmen-compose-test_1 ... done
Attaching to helloworld_unixmen-compose-test_1
unixmen-compose-test_1 | 
unixmen-compose-test_1 | Hello from Docker!
unixmen-compose-test_1 | This message shows that your installation appears to be working correctly.
unixmen-compose-test_1 | 
unixmen-compose-test_1 | To generate this message, Docker took the following steps:
unixmen-compose-test_1 | 1\. The Docker client contacted the Docker daemon.
unixmen-compose-test_1 | 2\. The Docker daemon pulled the "hello-world" image from the Docker Hub.
unixmen-compose-test_1 | 3\. The Docker daemon created a new container from that image which runs the
unixmen-compose-test_1 | executable that produces the output you are currently reading.
unixmen-compose-test_1 | 4\. The Docker daemon streamed that output to the Docker client, which sent it
unixmen-compose-test_1 | to your terminal.
unixmen-compose-test_1 | 
unixmen-compose-test_1 | To try something more ambitious, you can run an Ubuntu container with:
unixmen-compose-test_1 | $ docker run -it ubuntu bash
unixmen-compose-test_1 | 
unixmen-compose-test_1 | Share images, automate workflows, and more with a free Docker ID:
unixmen-compose-test_1 | https://cloud.docker.com/
unixmen-compose-test_1 | 
unixmen-compose-test_1 | For more examples and ideas, visit:
unixmen-compose-test_1 | https://docs.docker.com/engine/userguide/
unixmen-compose-test_1 | 
helloworld_unixmen-compose-test_1 exited with code 0

Docker 容器只能在命令（LCTT 译注：此处应为容器中的命令）还处于活动状态时运行，因此当测试完成运行时，容器将停止运行。

结论

本文是关于在 Ubuntu 16.04 中安装 Docker Compose 的教程。我们还看到了如何通过一个 YAML 格式的 Compose 文件构建一个简单的项目。

via: https://www.unixmen.com/container-docker-compose-ubuntu-16-04/

作者：Giuseppe Molica 译者：Locez 校对：wxy

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

预测趋势是棘手的，尤其是在快速发展的系统运维和工程领域。2016 年，在我们的 Velocity 大会上，我们讨论了分布式系统、SRE、容器化、无服务架构，人员倦怠以及与提供软件相关的人力与技术挑战等诸多问题。以下是我们认为的下一年的趋势：

1、 分布式系统

我们认为这个很重要，我们在整个 Velocity 会议上再次关注了它。

2、 站点可靠性工程（SRE）

站点可靠性工程 （ Site Reliability Engineering ） （SRE）-它只是运维么？或者它是 DevOps 的另外一个名称吗？这是 Google 对那些需要做大量系统及软件工程的运维专业人士的称呼。它由在像 Dropbox 公司的前 Google 人向业内推广，招聘 SRE 的职位正不断增加，特别是有大型数据中心的面向网络的公司。在某些情况下，SRE 的作用更多地是帮助开发人员运营自己的服务。

3、 容器化

公司将继续容器化它们的软件交付。Docker 公司本身已经将 Docker 定位为“增量革命”的工具，对遗留应用进行容器化已成为企业的常见案例。Docker 的未来是什么？随着工程师继续采用诸如 Kubernetes 和 Mesos 之类的编排工具，更高层次的抽象可能为其他容器（如 rkt、Garden 等）提供更多空间。

4、 Unikernels

unikernels 是容器化之后的下一步么？它们不合适产品环境么？有些人吹捧 unikernels 的安全和性能好处。关注一下 unikernels 在 2017 是如何进化的，特别要关注下 Dokcer 公司在这个领域做的。（今年它已经收购了 Unikernel Systems）

5、 无服务架构 （ Serverless ）

无服务架构视功能为基础的计算单元。有些人认为这个术语是误导性的（让人想起 “noops”），并且更倾向于把这个趋势称为“ 功能即服务 （ Functions-as-a-Service ） ”（FaaS）。开发人员和架构师正在越来越多地尝试这个技术，并期望看到有越来越多的程序用这个范式编写。更多关于 serverless/FaaS 对运维的意义，请查看 Michael Hausenblas 的 Serverless 运维免费电子书。

6、 原生云程序开发

就像 DevOps，这个术语已经被市场人员使用并滥用很久了，但是 云计算基金会 （ Cloud Native Computing Foundation ） （CNCF）为这些新工具（通常是谷歌发起的）做了一个很好的例子，这些工具不仅利用了云，而且特别还在于分布式系统（即微服务，容器化和动态编排）所提供的优势和机会。

7、 监控

随着行业从 Nagios 风格的监控发展到流化指标和可视化，我们在生产越来越多的系统数据，而如何理解它们则是下一个挑战，因此，我们看到供应商开始提供具有机器学习功能的监控服务，以及更普遍的是 IT 运营人员开始去研究让机器学习分析系统数据的技术。同样，随着我们的基础设施变得更加动态和分布式，监控越来越少地检查某个资源的健康状况，更多的是在服务之间追踪流量。因此，分布式跟踪已经出现。

8、 DevOps 安全

随着 DevOps 安全的普及，安全性正在迅速成为团队范围的关注。当重视安全和合规方面的公司在速度的竞争上感到了压力时，要同时满足速度和可靠性的 DevOps 所面对的经典挑战尤其明显。

告诉我们关于你的工作

作为一名 IT 运维专业人员 - 你是否使用系统管理的术语如 DevOps、SRE、DBA 等等。- 欢迎你来分享你的见解。

作者简介：

Courtney Nash 主持 O'Reilly Media 的多个会议，是专注于现代网络运维、高性能程序和安全性的战略内容总监。一位前学术神经科学家，她仍然对大脑着迷，以及它如何告诉我们与技术互动和对技术的期望。自从移居西雅图，在一家蓬勃发展的在线书店工作之后，她花了 17 年的时间从事技术行业的各种工作。在外面，你可以看到 Courtney 在骑自行车、徒步旅行、滑雪。。。

O'Reilly Media 的基础架构和运维编辑 Brian Anderson 介绍了从传统系统管理到云计算、Web 性能、Docker 和 DevOps 等软件交付的重要内容。他一直从事在线教育，服务于学习者的需求超过十多年。

via: https://www.oreilly.com/ideas/top-8-systems-operations-and-engineering-trends-for-2017

作者：Courtney Nash, Brian Anderson 译者：geekpi 校对：wxy

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