开放容器计划 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中国 荣誉推出

或许是出于疲倦，也有可能是出于对 GNOME 应用开发体系的不满，GNOME 桌面环境默认的文本编辑器、核心应用之一的 gedit 的开发者前几天宣布不再维护它了。它的最新稳定版本是 3.22。

gedit 开发者 Sébastien Wilmet 在邮件列表中说：

“gedit 不再维护，我已将其添加到此维基页面： https://wiki.gnome.org/Apps/Unmaintained

有没有感兴趣接手 gedit 维护的开发者？”

庆幸的是，gedit 在“无维护”页面呆了几天后，就有两位新的维护者加入了维护行列，我们可以不用担心 gedit 就此消亡——虽然“当前的 GTK+ 3 已经稳定，就是不维护，不出意外的话 gedit 也可以持续工作很长时间”。

gedit 是 GNOME 的默认编辑器，但其实它在 Linux 上的编辑器家族里面并不是很出彩，只能说是中规中矩、简单而轻量级罢了。但是可能也正是因为这个原因，才让大家忽视了这些默不出声的应用也是需要人来关爱的。

gedit 初次发布于 1999 年，而今已经有 18 岁了，但是它的开发者却一直不多，功能和特性的增加也不大，而且，几年前曾经历一次 UI 的较大变更，变更后的 UI 变成非常难用，所以使用者对此也颇有腹诽。但是可能是由于下面的原因，参与维护的人很少：

“另外， gedit 的核心是用 C 写的（为了支持 Mac OS X ，还有一点 Objective-C），一些插件是用 Vala 或 Python 写的。如果你要接手 gedit 的维护，你需要和这四种语言打交道（还不算构建系统）。 Python 代码是没编译的，所以如果重构 gedit 核心的话，可能需要移植所有的插件（python 代码也不如 C 代码那么便于 grep），不过至少 Vala 有个编译器，虽然我不推荐它。”

所以，这可能真的会让维护者头大。

此外，Sébastien Wilmet 对 GNOME 生态的开发也颇有抱怨：

“如果 gedit 死了，我认为这对于所有的 GTK+ 应用都是一个教训：要写更多的库，并在几个类似应用之间共享且一同维护它们。GtkSourceView 仍在维护，但是 gedit 所用的代码要超过了 GtkSourceView。在我给 GtkSourceView 贡献代码前， gedit 里面就有 8000 行以上的代码来保存和载入文件（只是后端，不算前端）。你显然不会认为只有 gedit 需要在用 GtkSourceView 时使用载入和保存文件吧？其它的文本编辑器呢？比如 Anjuta （也有很大一个不再维护的代码库），而且现在 gnome-builder 还在犯同样的错误（在它的角落里面开发了许多文本编辑器功能；你真的认为 Vim 模式只在 gnome-builder 中有用？！）

这事不只是文本编辑器的事，我们造了多少个音乐播放器的轮子？照片管理器呢？IRC/聊天客户端呢？天气预报呢？等等~”

好吧，或许是该正视这个问题的时刻了，毕竟只有良好的开发环境，才有丰富的应用生态，只有丰富的应用生态，才能大量的使用者。

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据 GNU 许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 GNU 许可证的问题

1、关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题

1.1 “GPL” 代表什么意思？

“GPL” 代表“ 通用公共许可证 （ General Public License ） ”。 最常见的此类许可证是 GNU 通用公共许可证，简称 GNU GPL。 如果人们能够自然而然地将其理解为 GNU GPL，可以进一步缩短为“GPL”。

1.2 自由软件是否意味着必须使用 GPL？

根本不是的，还有许多其他自由软件许可证。我们有一个不完整的列表。任何为用户提供特定自由的许可证都是自由软件许可证。

1.3 为什么我要使用 GNU GPL，而不是其他自由软件许可证？

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过，在某些特殊情况下，最好使用一个更宽松的许可证。

1.4 所有 GNU 软件都使用 GNU GPL 作为其许可证吗？

大多数 GNU 软件包都使用 GNU GPL，但是有一些 GNU 程序（以及程序的一部分）使用更宽松的许可证，例如 LGPL（ 较宽松公共许可证 （ Lesser GPL ） ）。我们这样做是基于战略考虑。

1.5 如果一个程序使用 GPL 许可证，是否会使其成为 GNU 软件？

任何人都可以依据 GNU GPL 发布一个程序，但并不能使其成为 GNU 软件包。

让程序成为 GNU 软件包意味着将其明确地贡献给 GNU 项目。当程序的开发人员和 GNU 项目都同意这样做时，才会发生这种情况。如果您有兴趣向 GNU 项目贡献程序，请写信至 mailto:[email protected] 。

1.6 我可以将 GPL 应用于软件以外的其他作品吗？

您可以将 GPL 应用于任何类型的作品，只需明确该作品的“源代码”构成即可。 GPL 将“源代码”定义为作品的首选形式，以便在其中进行修改。

不过，对于手册和教科书，或更一般地，任何旨在教授某个主题的作品，我们建议使用 GFDL，而非 GPL。

1.7 手册为什么不使用 GPL 许可证？

手册也可以使用 GPL 许可证，但对于手册来说，最好使用 GFDL（ 自由文本授权 （ GNU Free Documentation License ） ）许可证。

GPL 是为软件程序设计的，它包含许多复杂的条款，对于程序来说至关重要；但对于图书或手册来说，这将是麻烦和不必要的。例如，任何人如果（以 GPL ）出版纸质图书，就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”，或提供书面文件，表明将稍后发送“源代码”。

同时，GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款，例如，出售封面文字。 背书 （ Endorsements ） 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的，但该修改版本不能被标记为“该标准”。

使用 GFDL，我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要，因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由，它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” （ invariant ） ，使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

1.8 GPL 被翻译成其他语言了吗？

将 GPL 翻译成英文以外的语言将是有用的。人们甚至进行了翻译，并将文本发送给我们。但我们不敢将翻译文本批准为正式有效。其中的风险如此之大，以至于我们不敢接受。

法律文件在某种程度上就像一个程序。翻译它就像将程序从一种语言和操作系统转换到另一种语言。只有同时熟练使用这两种语言的律师才能做到这一点——即便如此，也有引入错误的风险。

如果我们正式批准 GPL 的翻译文本，我们将不得不给予所有人许可，让他们可以去做翻译文本规定可以做的任何事情。如果这是一个完全准确的翻译，那没关系。但如果翻译错误，后果可能是我们无法解决的灾难。

如果一个程序有 bug，我们可以发布一个新的版本，最终旧版本将会逐渐消失。但是，一旦我们给予每个人去根据特定翻译文本行事的许可，如果我们稍后发现它有一个错误，我们无法收回该权限。

乐意提供帮助的人有时会为我们做翻译工作。如果问题是要找人做这个工作的话，那问题就解决了。但实际的问题是错误的风险，做翻译工作不能避免风险。我们无法授权非律师撰写的翻译文本。

因此，目前我们并不认可GPL的翻译文本是全球有效和具有约束力的。相反，我们正在做两件事情：

• 将非正式的翻译指引给人们。这意味着我们允许人们进行GPL的翻译，但是我们不认可翻译文本具有法律效力和约束力。
  未经批准的翻译文本没有法律效力，应该如此明确地表述。翻译文本应标明如下：

This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
本 GPL 翻译文本是非正式的，没有被自由软件基金会（FSF）正式批准为有效。若要完全确定何种行为被允许，请参阅原始 GPL（英文）。

但未经批准的翻译文本可以作为如何理解英文 GPL 的参考。对于许多用户来说，这就足够了。不过，在商业活动中使用 GNU 软件的企业，以及进行公共 ftp 发行的人员，需要去核查实际的英文 GPL，以明确其允许的行为。

• 发布仅在单个国家/地区有效的翻译文本。
  我们正在考虑发布仅在单个国家正式生效的翻译文本。这样一来，如果发现有错误，那么错误将局限于这个国家，破坏力不会太大。
  即便是一个富有同情心和能力的律师来做翻译，仍然需要相当多的专门知识和努力，所以我们不能很快答应任何这样的翻译。

1.9 为什么有一些 GNU 库依据普通 GPL 而不是 LGPL 来发布？

对于任何特定库使用 LGPL 构成了自由软件的倒退。这意味着我们部分放弃了捍卫用户自由权利的努力，对基于 GPL 软件所构建产品的分享要求也降低了。在它们自身而言，这是更糟糕的变化。

有时一个小范围的倒退是很好的策略。某种情况下，使用 LGPL 的库可能会带来该库的广泛使用，从而进一步改善该库，为自由软件带来更广泛的支持，诸如此类。如果在相当大的程度上出现这种情况，这可能对自由软件很有好处。但它发生的几率有多少呢？我们只能推测。

在每个库上用一段时间的 LGPL，看看它是否有帮助，如果 LGPL 没有帮助，再将其更改为 GPL。这种做法听起来很好，但却是不可行的。一旦我们对特定库使用了 LGPL，那就很难进行改变。因此，我们根据具体情况决定每个库使用哪个许可证。对于我们如何判断该问题，有一段很长的解释。

1.10 谁有权力执行 GPL 许可证？

由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循GPL的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”

1.11 为什么 FSF 要求为 FSF 拥有版权的程序做出贡献的贡献者将版权 分配 （ assign ） 给 FSF？如果我持有 GPL 程序的版权，我也应该这样做吗？如果是，怎么做？

我们的律师告诉我们，为了最大限度地向法院要求违规者强制执行 GPL，我们应该让程序的版权状况尽可能简单。为了做到这一点，我们要求每个贡献者将贡献部分的版权分配给 FSF，或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明（如果有的话），以确保雇主不会声称拥有这部分贡献的版权。

当然，如果所有的贡献者把他们的代码放在公共领域，也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权，只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL，遵循类似的策略可能是一个好主意。如果您需要更多信息，请联系 mailto:[email protected]。

1.12 我可以修改 GPL 并创建一个修改后的许可证吗？

您可以制作GPL的修改版本，但这往往会产生实践上的后果。

您可以在其他许可证中合法使用GPL条款（可能是修改过的），只要您以其他名称来称呼您的许可证，并且不包括 GPL 的 引言 （ preamble ） ，只要您对最后的使用说明进行了足够多的修改，使其措辞明显不同，没有提到 GNU（尽管您描述的实际过程可能与其类似）。

如果您想在修改后的许可证中使用我们的引言，请写信至 mailto:[email protected]，以获得许可。我们需要查看实际的许可证要求，才能决定我们是否能够批准它们。

虽然我们不会以这种方式对您修改许可证提出法律上的反对意见，但我们希望您三思而行，别去修改许可证。类似这些修改后的许可证几乎肯定与 GNU GPL 不兼容，并且这种不兼容性阻碍了模块之间的有用组合。

不同自由软件许可证的扩散本身就是一个负担。请使用 GPL v3 提供的 例外 （ exception ） 机制，而不是去修改 GPL。

1.13 为什么你们决定将 GNU Affero GPL v3 作为一个单独的许可证？

GPLv3 的早期草案在第 7 节中允许许可人在发布源代码时添加一个类似 Affero 的要求。但是，一些开发和依赖自由软件的公司认为这个要求太过繁重。他们希望避免使用遵循这个要求的代码，并且对检查代码是否符合这个附加要求所带来的管理成本表示担忧。通过将 GNU Affero GPL v3 作为单独的许可证发布，在该许可证以及 GPL v3 中允许遵循该许可证的代码链接到彼此，我们完成了所有最初的目标，同时更容易确定哪些源代码需要遵循发布要求。

（题图：pycom.io）

译者：薛亮，北京集慧智佳知识产权管理咨询股份有限公司互联网事业部高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

监控服务器 - 什么是 Zabbix

Zabbix 是企业级开源分布式监控服务器解决方案。该软件能监控网络的不同参数以及服务器的完整性，还允许为任何事件配置基于电子邮件的警报。Zabbix 根据存储在数据库（例如 MySQL）中的数据提供报告和数据可视化功能。软件收集的每个测量指标都可以通过基于 Web 的界面访问。

Zabbix 根据 GNU 通用公共许可证版本 2（GPLv2）的条款发布，完全免费。

在本教程中，我们将在运行 MySQL、Apache 和 PHP 的 Ubuntu 16.04 server 上安装 Zabbix。

安装 Zabbix 服务器

首先，我们需要安装 Zabbix 所需的几个 PHP 模块：

# apt-get install php7.0-bcmath php7.0-xml php7.0-mbstring

Ubuntu 仓库中提供的 Zabbix 软件包已经过时了。使用官方 Zabbix 仓库安装最新的稳定版本。

通过执行以下命令来安装仓库软件包：

$ wget http://repo.zabbix.com/zabbix/3.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.2-1+xenial_all.deb
# dpkg -i zabbix-release_3.2-1+xenial_all.deb

然后更新 apt 包源：

# apt-get update

现在可以安装带有 MySQL 支持和 PHP 前端的 Zabbix 服务器。执行命令：

# apt-get install zabbix-server-mysql zabbix-frontend-php

安装 Zabbix 代理：

# apt-get install zabbix-agent

Zabbix 现已安装。下一步是配置数据库来存储数据。

为 Zabbix 配置 MySQL

我们需要创建一个新的 MySQL 数据库，Zabbix 将用来存储收集的数据。

启动 MySQL shell：

$ mysql -uroot -p

接下来：

mysql> CREATE DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON zabbix.* TO zabbix@localhost IDENTIFIED BY 'usr_strong_pwd';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> EXIT;
Bye

接下来，导入初始表和数据。

# zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql -uzabbix -p zabbix

输入在 MySQL shell 中创建的 zabbix 用户的密码。

接下来，我们需要编辑 Zabbix 服务器配置文件，它是 /etc/zabbix/zabbis_server.conf：

# $EDITOR /etc/zabbix/zabbix_server.conf

搜索文件的 DBPassword 部分：

### Option: DBPassword                           
#       Database password. Ignored for SQLite.   
#       Comment this line if no password is used.
#                                                
# Mandatory: no                                  
# Default:                                       
# DBPassword=

取消注释 DBPassword= 这行，并添加在 MySQL 中创建的密码：

DBPassword=usr_strong_pwd

接下来，查找 DBHost= 这行并取消注释。

保存并退出。

配置 PHP

我们需要配置 PHP 来使用 Zabbix。在安装过程中，安装程序在 /etc/zabbix 中创建了一个名为 apache.conf 的配置文件。打开此文件：

# $EDITOR /etc/zabbix/apache.conf

此时，只需要取消注释 date.timezone 并设置正确的时区：

<IfModule mod_php7.c>
    php_value max_execution_time 300
    php_value memory_limit 128M
    php_value post_max_size 16M
    php_value upload_max_filesize 2M
    php_value max_input_time 300
    php_value always_populate_raw_post_data -1
    php_value date.timezone Europe/Rome
</IfModule>

保存并退出。

此时，重启 Apache 并启动 Zabbix Server 服务，使其能够在开机时启动：

# systemctl restart apache2
# systemctl start zabbix-server
# systemctl enable zabbix-server

用 systemctl 检查 Zabbix 状态：

# systemctl status zabbix-server

这个命令应该输出：

â zabbix-server.service - Zabbix Server
 Loaded: loaded (/lib/systemd/system/zabbix-server.service; enabled; vendor pr
 Active: active (running) ...

此时，Zabbix 的服务器端已经正确安装和配置了。

配置 Zabbix Web 前端

如介绍中所述，Zabbix 有一个基于 Web 的前端，我们将用于可视化收集的数据。但是，必须配置此接口。

使用 Web 浏览器，进入 URL http://localhost/zabbix。

点击 Next step

确保所有的值都是 Ok，然后再次单击 Next step 。

输入 MySQL zabbix 的用户密码，然后点击 Next step。

单击 Next step ，安装程序将显示具有所有配置参数的页面。再次检查以确保一切正确。

点击 Next step 进入最后一页。

点击完成以完成前端安装。默认用户名为 Admin，密码是 zabbix。

Zabbix 服务器入门

使用上述凭证登录后，我们将看到 Zabbix 面板：

前往 Administration -> Users，了解已启用帐户的概况：

通过点击 Create user 创建一个新帐户。

点击 Groups 中的 Add，然后选择一个组：

保存新用户凭证，它将显示在 Administration -> Users 面板中。

请注意，在 Zabbix 中，主机的访问权限分配给用户组，而不是单个用户。

总结

我们结束了 Zabbix Server 安装的教程。现在，监控基础设施已准备好完成其工作并收集有关需要在 Zabbix 配置中添加的服务器的数据。

via: https://www.unixmen.com/monitoring-server-install-zabbix-ubuntu-16-04/

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

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

在这个快速入门教程中，我们使用 Azure CLI 创建一个 Kubernetes 集群，然后在集群上部署运行由 Web 前端和 Redis 实例组成的多容器应用程序。一旦部署完成，应用程序可以通过互联网访问。

这个快速入门教程假设你已经基本了解了 Kubernetes 的概念，有关 Kubernetes 的详细信息，请参阅 Kubernetes 文档。

如果您没有 Azure 账号，请在开始之前创建一个免费帐户。

登录 Azure 云控制台

Azure 云控制台是一个免费的 Bash shell，你可以直接在 Azure 网站上运行。它已经在你的账户中预先配置好了， 单击 Azure 门户右上角菜单上的 “Cloud Shell” 按钮；

该按钮会启动一个交互式 shell，您可以使用它来运行本教程中的所有操作步骤。

此快速入门教程所用的 Azure CLI 的版本最低要求为 2.0.4。如果您选择在本地安装和使用 CLI 工具，请运行 az --version 来检查已安装的版本。 如果您需要安装或升级请参阅安装 Azure CLI 2.0 。

创建一个资源组

使用 az group create 命令创建一个资源组，一个 Azure 资源组是指 Azure 资源部署和管理的逻辑组。

以下示例在 eastus 区域中创建名为 myResourceGroup 的资源组。

az group create --name myResourceGroup --location eastus

输出：

{
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup",
  "location": "eastus",
  "managedBy": null,
  "name": "myResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

创建一个 Kubernetes 集群

使用 az acs create 命令在 Azure 容器服务中创建 Kubernetes 集群。 以下示例使用一个 Linux 主节点和三个 Linux 代理节点创建一个名为 myK8sCluster 的集群。

az acs create --orchestrator-type=kubernetes --resource-group myResourceGroup --name=myK8sCluster --generate-ssh-keys 

几分钟后，命令将完成并返回有关该集群的 json 格式的信息。

连接到 Kubernetes 集群

要管理 Kubernetes 群集，可以使用 Kubernetes 命令行工具 kubectl。

如果您使用 Azure CloudShell ，则已经安装了 kubectl 。如果要在本地安装，可以使用 az acs kubernetes install-cli 命令。

要配置 kubectl 连接到您的 Kubernetes 群集，请运行 az acs kubernetes get-credentials 命令下载凭据并配置 Kubernetes CLI 以使用它们。

az acs kubernetes get-credentials --resource-group=myResourceGroup --name=myK8sCluster

要验证与集群的连接，请使用 kubectl get 命令查看集群节点的列表。

kubectl get nodes

输出：

NAME                    STATUS                     AGE       VERSION
k8s-agent-14ad53a1-0    Ready                      10m       v1.6.6
k8s-agent-14ad53a1-1    Ready                      10m       v1.6.6
k8s-agent-14ad53a1-2    Ready                      10m       v1.6.6
k8s-master-14ad53a1-0   Ready,SchedulingDisabled   10m       v1.6.6

运行应用程序

Kubernetes 清单文件为集群定义了一个所需的状态，包括了集群中应该运行什么样的容器镜像。 对于此示例，清单用于创建运行 Azure Vote 应用程序所需的所有对象。

创建一个名为 azure-vote.yaml ，将下面的内容拷贝到 YAML 中。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      containers:
      - name: azure-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      containers:
      - name: azure-vote-front
        image: microsoft/azure-vote-front:redis-v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

使用 kubectl create 命令来运行该应用程序。

kubectl create -f azure-vote.yaml

输出：

deployment "azure-vote-back" created
service "azure-vote-back" created
deployment "azure-vote-front" created
service "azure-vote-front" created

测试应用程序

当应用程序的跑起来之后，需要创建一个 Kubernetes 服务，将应用程序前端暴露在互联网上。 此过程可能需要几分钟才能完成。

要监控这个进程，使用 kubectl get service 命令时加上 --watch 参数。

kubectl get service azure-vote-front --watch

最初，azure-vote-front 服务的 EXTERNAL-IP 显示为 pending 。 一旦 EXTERNAL-IP 地址从 pending 变成一个具体的 IP 地址，请使用 “CTRL-C” 来停止 kubectl 监视进程。

azure-vote-front   10.0.34.242   <pending>     80:30676/TCP   7s
azure-vote-front   10.0.34.242   52.179.23.131   80:30676/TCP   2m

现在你可以通过这个外网 IP 地址访问到 Azure Vote 这个应用了。

删除集群

当不再需要集群时，可以使用 az group delete 命令删除资源组，容器服务和所有相关资源。

az group delete --name myResourceGroup --yes --no-wait

获取示例代码

在这个快速入门教程中，预先创建的容器镜像已被用于部署 Kubernetes 。相关应用程序代码 Dockerfile 和 Kubernetes 清单文件可在 GitHub 中获得。Github 仓库地址是 https://github.com/Azure-Samples/azure-voting-app-redis

下一步

在这个快速入门教程中，您部署了一个 Kubernetes 集群，并部署了一个多容器应用程序。

要了解有关 Azure 容器服务的更多信息，走完一个完整的从代码到部署的全流程，请继续阅读 Kubernetes 集群教程。

via: https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-walkthrough

作者：neilpeterson，mmacy 译者：rieonke 校对：wxy

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

当你好奇地看着系统的根目录（/）的时候，可能会发现自己有点不知所措。大多数三个字母的目录名称并没有告诉你它们是做什么的，如果你需要做出一些重要的修改，那就很难知道在哪里可以查看。

我想给那些没有深入了解过自己的根目录的人简单地介绍下它。

有用的工具

在我们开始之前，这里有几个需要熟悉的工具，它们可以让您随时挖掘那些您自己找到的有趣的东西。这些程序都不会对您的文件进行任何更改。

最有用的工具是 ls -- 它列出了使用完整路径或相对路径（即从当前目录开始的路径）作为参数给出的任何目录的内容。

$ ls 路径

当您进一步深入文件系统时，重复输入长路径可能会变得很麻烦，所以如果您想简化这一操作，可以用 cd 替换 ls 来更改当前的工作目录到该目录。与 ls 一样，只需将目录路径作为 cd 的参数。

$ cd 路径

如果您不确定某个文件是什么文件类型的，可以通过运行 file 并且将文件名作为 file 命令的参数。

$ file 文件名

最后，如果这个文件看起来像是适宜阅读的，那么用 less 来看看（不用担心文件有改变）。与最后一个工具一样，给出一个文件名作为参数来查看它。

$ less 文件名

完成文件翻阅后，点击 q 键退出，即可返回到您的终端。

根目录之旅

现在就开始我们的旅程。我将按照字母顺序介绍直接放在根目录下的目录。这里并没有介绍所有的目录，但到最后，我们会突出其中的亮点。

我们所有要遍历的目录的分类及功能都基于 Linux 的文件系统层次标准（FHS）。Linux 基金会维护的 Linux FHS 帮助发行版和程序的设计者和开发人员来规划他们的工具的各个组件应该存放的位置。

通过将各个程序的所有文件、二进制文件和帮助手册保存在一致的组织结构中，FHS 让对它们的学习、调试或修改更加容易。想象一下，如果不是使用 man 命令找到使用指南，那么你就得对每个程序分别寻找其手册。

按照字母顺序和结构顺序，我们从 /bin 开始。该目录是存放所有核心系统二进制文件的地方，其包含的命令可以在 shell （解释终端指令的程序）中使用。没有这个目录的内容，你的系统就基本没法使用。

接下来是 /boot 目录，它存储了您的计算机启动所需的所有东西。其中最重要的是引导程序和内核。引导程序是一个通过初始化一些基础工具，使引导过程得以继续的程序。在初始化结束时，引导程序会加载内核，内核允许计算机与所有其它硬件和固件进行接口。从这一点看，它可以使整个操作系统工作起来。

/dev 目录用于存储类似文件的对象来表示被系统识别为“设备”的各种东西。这里包括许多显式的设备，如计算机的硬件组件：键盘、屏幕、硬盘驱动器等。

此外，/dev 还包含被系统视为“设备”的数据流的伪文件。一个例子是流入和流出您的终端的数据，可以分为三个“流”。它读取的信息被称为“标准输入”。命令或进程的输出是“标准输出”。最后，被分类为调试信息的辅助性输出指向到“标准错误”。终端本身作为文件也可以在这里找到。

/etc（发音类似工艺商业网站 “Etsy”，如果你想让 Linux 老用户惊艳一下的话，囧），许多程序在这里存储它们的配置文件，用于改变它们的设置。一些程序存储这里的是默认配置的副本，这些副本将在修改之前复制到另一个位置。其它的程序在这里存储配置的唯一副本，并期望用户可以直接修改。为 root 用户保留的许多程序常用一种配置模式。

/home 目录是用户个人文件所在的位置。对于桌面用户来说，这是您花费大部分时间的地方。对于每个非特权用户，这里都有一个具有相应名称的目录。

/lib 是您的系统赖以运行的许多库的所在地。许多程序都会重复使用一个或多个功能或子程序，它们经常会出现在几十上百个程序中。所以，如果每个程序在其二进制文件中重复写它需要的每一个组件，结果会是产生出一些大而无当的程序，作为更好的替代方案，我们可以通过进行“库调用”来引用这些库中的一个或多个。

在 /media 目录中可以访问像 USB 闪存驱动器或摄像机这样的可移动媒体。虽然它并不是所有系统上都有，但在一些专注于直观的桌面系统中还是比较普遍的，如 Ubuntu。具有存储能力的媒体在此处被“挂载”，这意味着当设备中的原始位流位于 /dev 目录下时，用户通常可以在这里访问那些可交互的文件对象。

/proc 目录是一个动态显示系统数据的虚拟文件系统。这意味着系统可以即时地创建 /proc 的内容，用包含运行时生成的系统信息（如硬件统计信息）的文件进行填充。

/tmp 正如其名字，用于放置缓存数据等临时信息。这个目录不做其他更多的事情。

现代 Linux 系统上大多数程序的二进制文件保存在 /usr 目录中。为了统一包含二进制文件的各种目录，/usr 包含 /bin、/sbin 和 /lib 中的所有内容的副本。

最后，/var 里保存“ 可变 variable ”长度的数据。这里的可变长度数据的类型通常是会累积的数据，就像日志和缓存一样。一个例子是你的内核保留的日志。

为了避免硬盘空间用尽和崩溃的情况，/var 内置了“日志旋转”功能，可删除旧信息，为新信息腾出空间，维持固定的最大大小。

结尾

正如我所说，这里介绍的绝对不是您在根目录中可以找到的一切，但是确定系统核心功能所在地是一个很好的开始，而且可以更深入地研究这些功能是什么。

所以，如果你不知道要学习什么，就可能有很多的想法。如果你想得到一个更好的想法，就在这些目录中折腾自己吧！

作者简介：

自 2017 年以来 Jonathan Terrasi 一直是 ECT 新闻网的专栏作家。他的主要兴趣是计算机安全（特别是 Linux 桌面），加密和分析政治和时事。他是全职自由作家和音乐家。他的背景包括在芝加哥委员会发表的保卫人权法案文章中提供技术评论和分析。

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

作者：Jonathan Terrasi 译者：firmianay 校对：wxy

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