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中国 荣誉推出

最近，我对 lxc exec 进行了几个改进。如果你不知道它的话我介绍一下，lxc exec 是 LXD 的客户端工具，使用 LXD 客户端 api 与 LXD 守护程序通信，并执行用户想要执行的各种程序，以下是你可以使用的一个例子：

我们的主要目标之一就是使 lxc exec 与 ssh 类似，因为它是交互式或非交互式远程运行命令的标准。这使得 把 lxc exec 做得很好变得有点棘手。

1、 处理后台任务

一个长期存在的问题当然是如何正确处理后台任务。这是一个关于 LXD 2.7 实例的问题的例子：

你可以看到，在后台执行任务将导致 lxc exec 无法退出。许多命令可以触发此问题：

chb@conventiont|~
> lxc exec zest1 bash
root@zest1:~# yes &
y
y
y
.
.
.

现在没有什么能救你了。yes 将会永远直接写入stdout。

问题的根源在于 stdout 是一直打开着的，但这是必要的，因为它用以确保用户所启动的进程写入的任何数据实际上都是通过我们建立的 websocket 连接读取并发回的。

假如你想这样，运行一个 shell 会话，然后在后台运行一个进程，并马上退出 shell。对不起，它并不能如预期那样。

第一种并且原始的方法是一旦你检测到前台程序（例如 shell）已经退出就直接关闭 stdout。但这不像想得那么好，当你运行快速执行程序时，这个问题会变得明显，比如：

lxc exec -- ls -al /usr/lib

这里 lxc exec 进程（和相关的 forkexec 进程。但现在不要考虑它，只要记住 Go + setns() 不相往来就行了……）会在 stdout 中所有的缓冲数据被读取之前退出。这种情况下将会导致截断输出，没有人想要这样。在尝试使用几个方法来解决问题之后，包括禁用 pty 缓冲（我告诉你，这不太漂亮，也没有如预期工作。）和其他奇怪的思路，我设法通过几个 poll() “技巧”（在某种意义上说一个“技巧”）解决了这个问题。现在你终于可以运行后台任务，并且可以完全退出了。如图：

2、 报告由信号引起的退出码

ssh 是一个很棒的工具。但有一件事，我一直以来不喜欢当 ssh 运行的命令接收到一个信号时， ssh 总是会报告 -1，也就是退出码 255。当你想要了解导致程序终止的信号时，这很烦人。这就是为什么我最近实施标准 shell 所使用的惯例 128 + n 来报告任何由信号导致的退出，其中 n 被定义为导致执行程序退出的信号量。例如，在 SIGKILL 信号上，你会看到 128 + SIGKILL = 137（计算其他致命信号的退出码作为读者的练习）。所以你可以这么做：

chb@conventiont|~
> lxc exec zest1 sleep 100

现在，将 SIGKILL 发送到执行程序（不是 lxc exec本身，因为 SIGKILL 不可转发）。

kill -KILL $(pidof sleep 100)

最后检查你程序的退出码：

chb@conventiont|~
> echo $?
137

瞧。这显然只有当 a) 退出码没有超过 8 位计算壁垒，b）当执行程序不使用 137 来表示成功（这可真……有趣？！）。这两个论点似乎对我来说都不太有说服力。前者因为致命信号量不应该超过这个范围。后者因为（i）这是用户问题，（ii）这些退出代码实际上是保留的（我是这样认为。），（iii）你在本地或其他上面运行程序时会遇到同样的问题。

我看到的主要优点是这能够回报执行程序细粒度的退出状态。注意，我们不会报告所有被信号杀死的程序实例。比如说，当你的程序能够处理 SIGTERM 并且完全退出时，LXD 没有简单的方法来检测到这个情况并报告说这个程序被信号杀死了。你只会简单地收到退出码 0。

3、 转发信号

这可能不太有趣（或者也许不是，谁知道呢），但我发现它非常有用。正如你在 SIGKILL 案例中看到的那样，我明确地指出，必须将 SIGKILL 发送到执行程序，而不是 lxc exec命令本身。这是因为 SIGKILL 在程序中无法处理。程序可以做的唯一的事情就是去死，像现在这样……像这个例子……马上（你明白了了吧……）。但是程序可以处理很多其他信号 SIGTERM、SIGHUP'，当然也可以处理SIGUSR1和SIGUSR2。因此，当你发送可以被lxc exec` 处理而不是被执行程序处理的信号时，较新版本的 LXD 会将信号转发到执行进程。这在脚本中非常方便。

无论如何，我希望你觉得这篇小小的 lxc exec 文章/胡言乱语有用。享受 LXD 吧，这是与一只疯狂的美丽的野兽玩耍。请试试在线实验：https://linuxcontainers.org/lxd/try-it/，对于开发人员看看这里：https://github.com/lxc/lxd 并给我们补丁。

我们不要求签署任何 CLA，我们遵循内核风格，只要其中有 “Signed-off-by” 这行就好。

via: https://cbrauner.wordpress.com/2017/01/20/lxc-exec-vs-ssh/

作者：brauner 译者：geekpi 校对：wxy

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

机器学习 （ Machine Learning ） 有很多方面，当我开始研究学习它时，我发现了各种各样的“小抄”，它们简明地列出了给定主题的关键知识点。最终，我汇集了超过 20 篇的机器学习相关的小抄，其中一些我经常会翻阅，而另一些我也获益匪浅。这篇文章里面包含了我在网上找到的 27 个小抄，如果你发现我有所遗漏的话，请告诉我。

机器学习领域的变化是日新月异的，我想这些可能很快就会过时，但是至少在 2017 年 6 月 1 日时，它们还是很潮的。

如果你喜欢这篇文章，那就分享给更多人，如果你想感谢我，就到原帖地址点个赞吧。

机器学习

这里有一些有用的流程图和机器学习算法表，我只包括了我所发现的最全面的几个。

神经网络架构

来源： http://www.asimovinstitute.org/neural-network-zoo/

神经网络公园

微软 Azure 算法流程图

来源： https://docs.microsoft.com/en-us/azure/machine-learning/machine-learning-algorithm-cheat-sheet

用于微软 Azure 机器学习工作室的机器学习算法

SAS 算法流程图

来源： http://blogs.sas.com/content/subconsciousmusings/2017/04/12/machine-learning-algorithm-use/

SAS：我应该使用哪个机器学习算法？

算法总结

来源： http://machinelearningmastery.com/a-tour-of-machine-learning-algorithms/

机器学习算法指引

来源： http://thinkbigdata.in/best-known-machine-learning-algorithms-infographic/

已知的机器学习算法哪个最好？

算法优劣

来源： https://blog.dataiku.com/machine-learning-explained-algorithms-are-your-friend

Python

自然而然，也有许多在线资源是针对 Python 的，这一节中，我仅包括了我所见过的最好的那些小抄。

算法

来源： https://www.analyticsvidhya.com/blog/2015/09/full-cheatsheet-machine-learning-algorithms/

Python 基础

来源： http://datasciencefree.com/python.pdf

来源： https://www.datacamp.com/community/tutorials/python-data-science-cheat-sheet-basics#gs.0x1rxEA

Numpy

来源： https://www.dataquest.io/blog/numpy-cheat-sheet/

来源： http://datasciencefree.com/numpy.pdf

来源： https://www.datacamp.com/community/blog/python-numpy-cheat-sheet#gs.Nw3V6CE

来源： https://github.com/donnemartin/data-science-ipython-notebooks/blob/master/numpy/numpy.ipynb

Pandas

来源： http://datasciencefree.com/pandas.pdf

来源： https://www.datacamp.com/community/blog/python-pandas-cheat-sheet#gs.S4P4T=U

来源： https://github.com/donnemartin/data-science-ipython-notebooks/blob/master/pandas/pandas.ipynb

Matplotlib

来源： https://www.datacamp.com/community/blog/python-matplotlib-cheat-sheet

来源： https://github.com/donnemartin/data-science-ipython-notebooks/blob/master/matplotlib/matplotlib.ipynb

Scikit Learn

来源： https://www.datacamp.com/community/blog/scikit-learn-cheat-sheet#gs.fZ2A1Jk

来源： http://peekaboo-vision.blogspot.de/2013/01/machine-learning-cheat-sheet-for-scikit.html

来源： https://github.com/rcompton/ml_cheat_sheet/blob/master/supervised_learning.ipynb

Tensorflow

来源： https://github.com/aymericdamien/TensorFlow-Examples/blob/master/notebooks/1_Introduction/basic_operations.ipynb

Pytorch

来源： https://github.com/bfortuner/pytorch-cheatsheet

数学

如果你希望了解机器学习，那你就需要彻底地理解统计学（特别是概率）、线性代数和一些微积分。我在本科时辅修了数学，但是我确实需要复习一下了。这些小抄提供了机器学习算法背后你所需要了解的大部分数学知识。

概率

来源： http://www.wzchen.com/s/probability_cheatsheet.pdf

概率小抄 2.0

线性代数

来源： https://minireference.com/static/tutorials/linear_algebra_in_4_pages.pdf

四页内解释线性代数

统计学

来源： http://web.mit.edu/~csvoss/Public/usabo/stats_handout.pdf

统计学小抄

微积分

来源： http://tutorial.math.lamar.edu/getfile.aspx?file=B,41,N

微积分小抄

音乐是生活的一部分。维基百科关于音乐发展历史的文章有这样一段不错的描述说：“全世界所有的人们，包括哪怕是最孤立、与世隔绝的部落，都会有自己的特色音乐……”好吧，我们开源人就构成了一个部落。我建议我们的“音乐形式”应该包括开源音乐播放器。在过去几年里，我已经使用体验过不少我能接触到的音乐播放器；2016 年 12 月份我根据这六个标准来总结概括了我使用开源音乐播放器的感受：

1. 必须是能够通过设置让音乐一成不变地转换到 ALSA。（最高分 ５分）
2. 应该有一个不错的“智能播放列表”。（１ 分）
3. 不应该强迫用户只能通过播放列表来进行交互。（1 分）
4. 应该能够提供一个简单的方法来显示歌曲的封面图片——使用内嵌的封面图或使用在音乐目录里面 cover．jpg（或者 .png）文件替代。
5. 应该能够在音乐播放的时候显示信号级别和实际比特率。（１ 分）
6. 能够呈现出不错的整体组织，结构布局和执行性能。（１ 分）

热心的读者让告诉我有三个播放器是在我的资源仓库里没有的：Aqualung、Lollypop 和 GogglesMM。我并不想在我办公用的电脑里面安装那些来自外面的软件，我承诺过我会配置一个“试验台”来测试这三个音乐播放器，并给出测试的细节。

Aqualung

Aqualung 有一个写的清晰明了的网站来解释它众多的特点。其上提供的说明中我发现其中一点特别有趣：

“你能够（也应该）将你的所有音乐按照艺术家／档案／声轨这样组织成一个树型结构，这样比生成一个一体化的 Winamp／XMMS 播放列表更舒服。”

这点让我有些困惑，因为我总是把我的音乐按照艺术家、专辑和声轨这样组织成树状。但这就可能解释了为什么我有时发现 XMMS 流派的播放器在浏览音乐时有一点古怪。

根据 Aqualung 官网的下载页面说明，官方发布的只有源代码。但是文档上的说明暗示了绝大多数主流的 Linux 发行版本都包括一份 Aqualung 的构建副本，但我当前用的办公电脑所使用的 Linux 发行版 Ubuntu 16.10 并不在此范围内。Launchpad.net 提供有 PPA，但那些软件看起来都有些过时了，所以为什么不试试编译源码安装软件呢？

我根据官网上编译文档的建议和配置脚本的提示安装了 pkgconf 以及 libasound、libflac、libmp3lame、libvorbis、libxml2、libglib2.0 和 libgtk+-2.0 的开发库。接下来，我就能够干净利索的进行 configure 然后进行 make 和 make install。最终我可以执行 /usr/local/bin/aqualung 了。

Aqualung，不能切换音乐播放的码率。

一旦 Aqualung 启动运行，我就能看到相当简洁直接的两窗口界面：播放器本身和“音乐商店”。我通过右键点击播放器的音乐面板打开参数设置查看这些可设置的参数，看是否能找到 AudioQuest DragonFly 这个数模转换器，但我没有找到任何相关的迹象。然而，站点上的说明指出可以通过命令行指定输出设备。最终我用 plughw 设备才让 Aqualung 启动起来。

在那个时候，真正让我对 Aqualung 感到失望的是 Aqualung 似乎是需要一个固定的输出采样频率。我能够用 Aqualung 播放器的默认设置来正常播放我的 44.1 Khz 文件，但是同样的采样频率播放 96 Khz 的音乐文件时，我不得不关闭软件并重新启动。也正是因为这一点，我不会再继续对 Aqualung 进行使用测评。

无评分。

Lollypop

优美的 Lollypop 用户界面。

Lollypop 有一个华丽的网站。尽管它不在我办公专用的电脑的软件仓库里面，但是有一个“针对 Ubuntu/Debian 用户的下载”链接带你跳转到 launchpad.net 站点提供的最新的 PPA。这个站点还提供针对 Flatpak、Arch Linux、Fedora 和 OpenSUSE 这些系统的 Lollypop 软件包的下载。我看了下 Fedora COPR 上针对各个 Fedora 版本的 Lollypop 下载链接，看起来 Lollypop 更新的比较及时而且从 Fedora 版本的 23 到 26 都有对应的软件包提供下载安装。

一天内做一次源码编译就足够了，所以我决定试试从 PPA 安装这款软件。我通过命令行来执行 Lollypop 软件。设置菜单能够在 Lollypop 界面的右上方很显眼地看见。更新完我的音乐后，我开始找电脑的输出设备设置，但是在一番查看后，我不知道该怎么选择合适的输出设备。即便我在命令行通过 -help 也找不到有用的帮助信息。

经过一番网上搜索后我找到一个 Lollypop 的开发者的提示才知道我需要 gstreamer libav 来让 Lollypop 工作。通过这个说明我决定停止，因为这可能需要一个 gstreamer 相关配置才有能工作，但是我不太想继续尝试了。

Lollypop 有一个优美的用户交互界面和它的优美的网站相得益彰，但是我现在不会进一步对它进行测评，否则我就又多了一个进一步去学习了解 gstreamer 的理由。

无评分。

GogglesMM

Goggles Music Manager 也有一个在 launchpad.net 及时更新的 PPA；安装流程简单明了，我现在可以在命令行执行 gogglesmm 了。

GogglesMM，非常容易上手使用，看上去和 Rhythmbox 有点像。我在 GogglesMM 的设置里面的参数设置中找到了音频选项设置，能够让我选择 ALSA 和设置音频输出设备。通过查看 /proc/asound/DragonFly/stream0 文件和 DragonFly 自己的 LED 颜色，我确定我能够用 GogglesMM 播放 44.1-KHz／21-bit 和 96-KHz／24-bit 这两种规格的 mp3；因此，就凭 “rate/depth passthrough” 我给 GogglesMM 打 5 分。

*GogglesMM 在播放 96/24 这种规格的音乐，显示音频输出设备选择。 *

GogglesMM 的说明文档并没有大量的细节介绍，但是我尽可能说明的是，开发者们使用了过滤器来实现类似“智能播放列表”的功能。我在我的测试环境下使用三张专辑来尽我所能检测过滤功能，当我使用“智能播放列表”功能的时候尽管我喜欢我看到的通过过滤筛选出来的歌曲（特别是能够基于广泛的标准来针对歌曲定义筛选条件），但这并不是我认为的“智能播放列表”，对我来说我认为“智能播放列表”应该是这样的，通过借助一些社区数据库来推荐提供和你近期播放的歌曲类似的曲目。或者我该把这个叫作“自动的 DJ”而不是“智能播放列表”，但是通过测试我最终能够确定的是，这个特性并不会在近期版本的 GogglesMM 中出现，所以我给它这个所谓的“智能播放列表”打 0 分。

至于播放列表队列的操作，这款应用能够支持播放你选中的音乐，也能够随机播放音乐或者把一些音乐整合到一个播放列表里面，所以我因为“播放列表的队列选项”给它打 1 分。

同样的，它看起来也能够很好地不需要额外的干预来管理我的音乐艺术封面（每个专辑都包含一张合适的艺术封面， GogglesMM 可以自动识别），所以为“内嵌的艺术封面或者封面图片”打 1 分。

我找不到任何方法来让 GogglesMM 显示信号级别或者实际的比特率。我也不能找到显示比特率和位深度的方法；尽管这款应用能够显示一个“格式”列，但是在我的音乐栏里面除了显示音乐格式不会显示其他的信息了，所以为 GogglesMM 的“信号级别和有效比特率”打 0 分。

至于 GogglesMM 的整体结构，它的所有按钮选项都正好完全符合我的使用习惯。我能够在播放队列里面看到歌曲的时间和歌曲当前已播放的时间所占歌曲总体时间的比例，专辑封面，歌曲名，专辑名和歌唱者。可用的播放栏列表看起来相当大而有用，比如也包括了作曲者。最后，一个真正让我眼前一亮的特点是，音量控制竟然包含了 ALSA 音量。也就是如果我启动 alsamixer 的话，然后不管是在 alsamixer 还是在 GogglesMM 里面调整音量，另一个音量控制也会做相应的音量调整。这个出乎我意外之外的功能相当的酷而且这个功能在其他的音乐播放器上也不常见，因此为它的整体架构给 GogglesMM 加 1 分。

最终 GogglesMM 的这些优点共计得分 8。所表现出来的特点确实很优秀。

评分：8

到目前为止所给出的评分

我之前所提到的这几个开源音乐播放器中，我最喜欢的还是 Guayadeque，根据我制定的标准来进行排名的话，我给 Guayadeque 打满分 10 分。来看下我对这三个开源音乐播放器的评分总结吧（N/R 代表“无评分”，因为我不确定如何配置这些播放器来让它们以完美的码率和贯穿模式工作，以便我的数模信号转换器在相应源的码率和位深度接收 PCM 数据）：

请注意下我用的这个排名方法并不适合每个人。特别是很多人并不清楚高品质音乐的价值，他们更喜欢专有格式的音乐能够给他们带来更好的音乐品质。

与此同时，我会继续评测一些之前向大家承诺的音乐播放器一些和评测评分无关的特性。我特别喜欢 Lollypop 的外观，我也觉得待揭秘的 gstreamer 有一种神秘的魅力，它能让基于 gstreamer 的音乐播放器不用通过转换就能传输它们的数据。

关于音乐的部分……

我还在保持继续购买唱片的习惯，对于唱片的购买我有些不错的推荐。

第一个就是 Nils Frahm 的专辑 Felt，这是我女儿送我的一份非常贴心的礼物。我真的真的很喜欢这张专辑，它的绝大部分歌曲都是在深夜用电麦录制的非常接近钢琴的弦乐，而且也有不少有趣的钢琴演奏的背景音乐，真的是很棒的音乐。至于 Nils Frahm 其他的音乐，这些唱片提供的下载链接允许你下载质量高达 96-KHz，24-bit FLAC 格式的音乐。

第二个就是 Massive Attack 的专辑 Protection 的 Mad Professor 的重混版)，专辑名是 No Protection。你可以在这里了解这份专辑，并且如果你想要尝试这份专辑最原始的版本，这里是它的所有汇总信息。该专辑最初发布于 20 世纪 90 年代，这份专辑刻录在唱片上面而且听起来非常奇幻。遗憾的是，不提供下载链接。

第三个就是 Bayonne 的 Primitives。这是专辑要表达的想法。Guardian 报社把这份专辑称作是“新式无聊”。那么这种类型的音乐到底怎么样呢？如果这些音乐真的是非常令人乏味的，或许是时候来换份工作了，无论如何你可以试试听这些音乐；或许你会觉得它确实很乏味或者你会像我一样喜欢上这份音乐。

（图片来源：互联网档案馆书中的图片；由 Opensource.com 编辑发布。遵循 CC BY-SA 4.0 协议。）

作者简介：

Chris Hermansen - 自 1978 年毕业于 British Columbia 大学后一直从事计算机相关工作，2005 年之前是 Solaris、SunOS、UNIX System V 的忠实用户，之后是 Linux 的忠实用户。在技术方面，我的职业生涯大部分时间都是在做数据分析；特别是空间数据分析。拥有丰富的和数据分析相关的编程经验，用过的编程语言有 awk，Python、PostgreSQL、 PostGIS 和 最新的 Groovy。

via: https://opensource.com/article/17/1/open-source-music-players

作者：Chris Hermansen 译者：WangYueScream 校对：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中国 荣誉推出