IT 评论

这两天我安装了Elementary OS和Windows双系统，在启动的时候遇到了一个Grub错误。命令行中呈现如下信息：

Minimal BASH like line editing is supported. For the first word, TAB lists possible command completions. anywhere else TAB lists possible device or file completions.

提供类似行编辑的袖珍 BASH。TAB键补全第一个词，列出可以使用的命令。除此之外，TAB键补全可以列出可用的设备或文件。

事实上这并不是Elementary OS独有的错误。这是常见的Grub错误，会在Ubuntu，Fedora，Linux Mint等Linux操作系统上发生。

通过这篇文章里我们可以学到基于Linux系统如何修复Ubuntu中出现的“minimal BASH like line editing is supported” Grub错误。

你可以参阅这篇教程来修复类似的常见问题，错误：分区未找到Linux grub救援模式。

先决条件

要修复这个问题，你需要达成以下的条件：

• 一个包含相同版本、相同OS的LiveUSB或磁盘
• 当前会话的Internet连接正常工作

在确认了你拥有先决条件了之后，让我们看看如何修复Linux的死亡黑屏（如果我可以这样的称呼它的话 😉 ）。

如何在基于Ubuntu的Linux中修复“minimal BASH like line editing is supported” Grub错误

我知道你一定疑问这种Grub错误并不局限于在基于Ubuntu的Linux发行版上发生，那为什么我要强调在基于Ubuntu的发行版上呢？原因是，在这里我们将采用一个简单的方法，用个叫做Boot Repair的工具来修复我们的问题。我并不确定在其他的诸如Fedora的发行版中是否有这个工具可用。不再浪费时间，我们来看如何修复“minimal BASH like line editing is supported” Grub错误。

步骤 1: 引导进入lives会话

插入live USB，引导进入live会话。

步骤 2: 安装 Boot Repair

等你进入了lives会话后，打开终端使用以下命令来安装Boot Repair：

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install boot-repair

注意：推荐这篇教程如何修复 apt-get update 无法添加新的 CD-ROM 的错误，如果你在运行以上命令是遭遇同样的问题。

步骤 3: 使用Boot Repair修复引导

装完Boot Repair后，在命令行运行如下命令启动：

boot-repair &

其实操作非常简单直接，你仅需按照Boot Repair工具提供的说明操作即可。首先，点击Boot Repair中的Recommended repair选项。

Boot Repair需要花费一些时间来分析引导和Grub中存在的问题。然后，它会提供一些可在命令行中直接运行的命令。将这些命令一个个在终端中执行。我这边屏幕上显示的是：

在输入了这些命令之后，它会执行执行一段时间：

在这一过程结束后，它会提供一个由boot repair的日志组成的网页网址。如果你的引导问题这样都没有修复，你就可以去社区或是发邮件给开发团队并提交该网址作为参考。很酷！不是吗？

在boot repair成功完成后，关闭你的电脑，移除USB并再次引导。我这就能成功的引导了，但是在Grub画面上会多出额外的两行。相比于看到系统能够再次正常引导的喜悦这些对我来说并不重要。

对你有效吗?

这就是我修复Elementary OS Freya中的minimal BASH like line editing is supported Grub 错误的方法。怎么样？是否对你也有效呢？请自由的在下方的评论区提出你的问题和建议。

---

via: http://itsfoss.com/fix-minimal-bash-line-editing-supported-grub-error-linux/

作者：Abhishek 译者：martin2011qi 校对：wxy

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

来源：https://linux.cn/article-5909-1.html

PHP是一个开源服务器端脚本语言，最初这三个字母代表的是“Personal Home Page”，而现在则代表的是“PHP：Hypertext Preprocessor”，它是个递归首字母缩写。它是一个跨平台脚本语言，深受C、C++和Java的影响。

在 Linux 命令行中运行 PHP 代码

PHP的语法和C、Java以及带有一些PHP特性的Perl变成语言中的语法十分相似，它当下大约正被2.6亿个网站所使用，当前最新的稳定版本是PHP版本5.6.10。

PHP是HTML的嵌入脚本，它便于开发人员快速写出动态生成的页面。PHP主要用于服务器端（而Javascript则用于客户端）以通过HTTP生成动态网页，然而，当你知道可以在Linux终端中不需要网页浏览器来执行PHP时，你或许会大为惊讶。

本文将阐述PHP脚本语言的命令行方面。

1. 在安装完PHP和Apache2后，我们需要安装PHP命令行解释器。

# apt-get install php5-cli          [Debian 及类似系统]
# yum install php-cli               [CentOS 及类似系统]

接下来我们通常要做的是，在/var/www/html（这是 Apache2 在大多数发行版中的工作目录）这个位置创建一个内容为 ，名为 infophp.php 的文件来测试（PHP是否安装正确），执行以下命令即可。

# echo '' > /var/www/html/infophp.php

然后，将浏览器访问 http://127.0.0.1/infophp.php ，这将会在网络浏览器中打开该文件。

检查PHP信息

不需要任何浏览器，在Linux终端中也可以获得相同的结果。在Linux命令行中执行/var/www/html/infophp.php，如：

# php -f /var/www/html/infophp.php

从命令行检查PHP信息

由于输出结果太大，我们可以通过管道将上述输出结果输送给 less 命令，这样就可以一次输出一屏了，命令如下：

# php -f /var/www/html/infophp.php | less

检查所有PHP信息

这里，‘-f‘选项解析并执行命令后跟随的文件。

2. 我们可以直接在Linux命令行使用phpinfo()这个十分有价值的调试工具而不需要从文件来调用，只需执行以下命令：

# php -r 'phpinfo();'

PHP调试工具

这里，‘-r‘ 选项会让PHP代码在Linux终端中不带<和>标记直接执行。

3. 以交互模式运行PHP并做一些数学运算。这里，‘-a‘ 选项用于以交互模式运行PHP。

# php -a
Interactive shell
php > echo 2+3;
5
php > echo 9-6;
3
php > echo 5*4;
20
php > echo 12/3;
4
php > echo 12/5;
2.4
php > echo 2+3-1;
4
php > echo 2+3-1*3;
2
php > exit

输入 ‘exit‘ 或者按下 ‘ctrl+c‘ 来关闭PHP交互模式。

启用PHP交互模式

4. 你可以仅仅将PHP脚本作为shell脚本来运行。首先，创建在你当前工作目录中创建一个PHP样例脚本。

# echo -e '#!/usr/bin/phpn' > phpscript.php

注意，我们在该PHP脚本的第一行使用#!/usr/bin/php，就像在shell脚本中那样（/bin/bash）。第一行的#!/usr/bin/php告诉Linux命令行用 PHP 解释器来解析该脚本文件。

其次，让该脚本可执行：

# chmod 755 phpscript.php

接着来运行它，

# ./phpscript.php

5. 你可以完全靠自己通过交互shell来创建简单函数，这你一定会被惊到了。下面是循序渐进的指南。

开启PHP交互模式。

# php -a

创建一个函数，将它命名为 addition。同时，声明两个变量 $a 和 $b。

php > function addition ($a, $b)

使用花括号来在其间为该函数定义规则。

php > {

定义规则。这里，该规则讲的是添加这两个变量。

php { echo $a + $b;

所有规则定义完毕，通过闭合花括号来封装规则。

php {}

测试函数，添加数字4和3，命令如下：

php > var_dump (addition(4,3));

样例输出

7NULL

你可以运行以下代码来执行该函数，你可以测试不同的值，你想来多少次都行。将里头的 a 和 b 替换成你自己的值。

php > var_dump (addition(a,b));

---

php > var_dump (addition(9,3.3));

样例输出

12.3NULL

创建PHP函数

你可以一直运行该函数，直至退出交互模式（ctrl+z）。同时，你也应该注意到了，上面输出结果中返回的数据类型为 NULL。这个问题可以通过要求 php 交互 shell用 return 代替 echo 返回结果来修复。

只需要在上面的函数的中 ‘echo‘ 声明用 ‘return‘ 来替换

替换

php { echo $a + $b;

为

php { return $a + $b;

剩下的东西和原理仍然一样。

这里是一个样例，在该样例的输出结果中返回了正确的数据类型。

PHP函数

永远都记住，用户定义的函数不会从一个shell会话保留到下一个shell会话，因此，一旦你退出交互shell，它就会丢失了。

希望你喜欢此次教程。保持连线，你会获得更多此类文章。保持关注，保持健康。请在下面的评论中为我们提供有价值的反馈。点赞并分享，帮助我们扩散。

还请阅读： 12个Linux终端中有用的的PHP命令行用法——第二部分

---

via: http://www.tecmint.com/run-php-codes-from-linux-commandline/

作者：Avishek Kumar 译者：GOLinux 校对：wxy

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

来源：https://linux.cn/article-5906-1.html

嗨，大家好。今天我们来学一学Swarm相关的内容吧，我们将学习通过Swarm来创建Docker原生集群。Docker Swarm是用于Docker的原生集群项目，它可以将一个Docker主机池转换成单个的虚拟主机。Swarm工作于标准的Docker API，所以任何可以和Docker守护进程通信的工具都可以使用Swarm来透明地伸缩到多个主机上。就像其它Docker项目一样，Swarm遵循“内置电池，并可拆卸”的原则（LCTT 译注：batteries included，内置电池原来是 Python 圈里面对 Python 的一种赞誉，指自给自足，无需外求的丰富环境；but removable，并可拆卸应该指的是非强制耦合）。它附带有一个开箱即用的简单的后端调度程序，而且作为初始开发套件，也为其开发了一个可插拔不同后端的API。其目标在于为一些简单的使用情况提供一个平滑的、开箱即用的体验，并且它允许切换为更强大的后端，如Mesos，以用于大规模生产环境部署。Swarm配置和使用极其简单。

这里给大家提供Swarm 0.2开箱的即用一些特性。

1. Swarm 0.2.0大约85%与Docker引擎兼容。
2. 它支持资源管理。
3. 它具有一些带有限制和类同功能的高级调度特性。
4. 它支持多个发现后端（hubs，consul，etcd，zookeeper）
5. 它使用TLS加密方法进行安全通信和验证。

那么，我们来看一看Swarm的一些相当简单而简用的使用步骤吧。

1. 运行Swarm的先决条件

我们必须在所有节点安装Docker 1.4.0或更高版本。虽然各个节点的IP地址不需要要公共地址，但是Swarm管理器必须可以通过网络访问各个节点。

注意：Swarm当前还处于beta版本，因此功能特性等还有可能发生改变，我们不推荐你在生产环境中使用。

2. 创建Swarm集群

现在，我们将通过运行下面的命令来创建Swarm集群。各个节点都将运行一个swarm节点代理，该代理会注册、监控相关的Docker守护进程，并更新发现后端获取的节点状态。下面的命令会返回一个唯一的集群ID标记，在启动节点上的Swarm代理时会用到它。

在集群管理器上运行：

# docker run swarm create

3. 启动各个节点上的Docker守护进程

我们需要登录进我们将用来创建集群的每个节点，并在其上使用-H标记启动Docker守护进程。它会保证Swarm管理器能够通过TCP访问到各个节点上的Docker远程API。要启动Docker守护进程，我们需要在各个节点内部运行以下命令。

# docker -H tcp://0.0.0.0:2375 -d

4. 添加节点

在启用Docker守护进程后，我们需要添加Swarm节点到发现服务，我们必须确保节点IP可从Swarm管理器访问到。要完成该操作，我们需要在各个节点上运行以下命令。

# docker run -d swarm join --addr=:2375 token://

注意：我们需要用步骤2中获取到的节点IP地址和集群ID替换这里的和。

5. 开启Swarm管理器

现在，由于我们已经获得了连接到集群的节点，我们将启动swarm管理器。我们需要在集群管理器中运行以下命令。

# docker run -d -p :2375 swarm manage token://

6. 检查配置

一旦管理运行起来后，我们可以通过运行以下命令来检查配置。

# docker -H tcp:// info

注意：我们需要替换为运行swarm管理器的主机的IP地址和端口。

7. 使用docker CLI来访问节点

在一切都像上面说得那样完美地完成后，这一部分是Docker Swarm最为重要的部分。我们可以使用Docker CLI来访问节点，并在节点上运行容器。

# docker -H tcp:// info
# docker -H tcp:// run ...

8. 监听集群中的节点

我们可以使用swarm list命令来获取所有运行中节点的列表。

# docker run --rm swarm list token://

尾声

Swarm真的是一个有着相当不错的功能的docker，它可以用于创建和管理集群。它相当易于配置和使用，当我们在它上面使用限制器和类同器时它更为出色。高级调度程序是一个相当不错的特性，它可以应用过滤器来通过端口、标签、健康状况来排除节点，并且它使用策略来挑选最佳节点。那么，如果你有任何问题、评论、反馈，请在下面的评论框中写出来吧，好让我们知道哪些材料需要补充或改进。谢谢大家了！尽情享受吧 🙂

---

via: http://linoxide.com/linux-how-to/configure-swarm-clustering-docker/

作者：Arun Pyasi 译者：GOLinux 校对：wxy

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

来源：https://linux.cn/article-5915-1.html

最近在向Linux内核提交一些驱动程序，在提交的过程中，发现自己的代码离Linux内核的coding style要求还是差很多。当初自己对内核文档里的CodingStyle一文只是粗略的浏览，真正写代码的时候在很多细节上会照顾不周。不过， 在不遵守规则的程序员队伍里，我并不是孤独的。如果去看drivers/staging下的代码，就会发现很多驱动程序都没有严格遵守内核的coding style，而且在很多驱动程序的TODO文件里，都会把”checkpatch.pl fixes”作为自己的目标之一（checkpatch.pl是用来检查代码是否符合coding style的脚本）。

不可否认，coding style是仁者见仁、智者见智的事情。比如Microsoft所推崇的匈牙利命名法，在Linus看来就是及其脑残(brain damaged)的做法。也许您并不赞成Linus制定的coding style，但在提交内核驱动这件事上，最好还是以大局为重。对于这么一个庞大的集市式的开发来说，随意书写代码必将带来严重的可维护性的灾难。

（题图来自：mota.ru）

一些辅助工具

当代码量达到一定程度时，手动去检查和修改coding style是非常繁琐的工作，幸好，我们还有一些工具可以使用。

scripts/checkpatch.pl

这是一个检查代码是否符合内核编码规范的的脚本。顾名思义，checkpatch是用来检查patch的，默认的调用也确实如此。如果用来检查原文件，需要加上“-f”的选项。

我们来看一段无聊的代码(文件名为print_msg.c)：

void print_msg(int a)
{
    switch (a) {
        case 1:
            printf("a == 1n");
            break;
        case 2:
            printf("a == 2n");
            break;
    }
}

这段代码的coding style是否有问题呢？用checkpatch.pl来检查一下：

scripts/checkpatch.pl -f  print_msg.c

检查的结果是：

ERROR: switch and case should be at the same indent
#3: FILE: switch.c:3:
+       switch (a) {
+               case 1:
[...]
+               case 2:
total: 1 errors, 0 warnings, 12 lines checked
switch.c has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

在Linux内核的coding style里，switch和case要求有相同的缩进。本例的代码很少，错误也只有这一个，手动修改很方便。如果类似的缩紧错误很多怎么办？

scripts/Lindent

scripts目录下的工具Lindent可以用来自动修改缩进问题。提醒一下，使用Lindent要求系统安装indent这个工具。

对于上面这个例子，执行Lindent命令：

scripts/Lindent print_msg.c

得到的新代码是：

void print_msg(int a)
{
    switch (a) {
    case 1:
        printf("a == 1n");
        break;
    case 2:
        printf("a == 2n");
        break;
    }
}

sed

sed是一个流编辑器，其强大的功能可以帮助我们处理很多重复性的工作。比如，Linux内核的coding style要求，行尾不能有空格（包括Tab），去除这些空格就可以借助sed。

我自己的习惯很差，经常在代码的行尾留下一些空格。比如一行代码过长需要换行时，总是下意识的在换行的地方敲一个空格。另外，我常用的编辑器之一的Kate，为了对齐的需要，经常在空行的前面留上几个缩进的Tab（如下图）。

 

手动去除这些行尾的空格是一件头大的事情，但对于sed来说不过是举手之劳。命令格式如下：

sed 's/[ t]*$//g' your_code.c

一些需要注意的代码风格

缩进

1、除了注释、文档和Kconfig之外，使用Tab缩进，而不是空格，并且Tab的宽度为8个字符；

2、switch … case …语句中，switch和case具有相同的缩进（参考上文）；

花括号

3、花括号的使用参考K&R风格。

如果是函数，左花括号另起一行：

int function(int x)
{
        body of function
}

否则，花括号紧接在语句的最后：

if (x is true) {
        we do y
}

如果只有一行语句，则不需要用花括号：

if (condition)
        action();

但是，对于条件语句来说，如果一个分支是一行语句，另一个分支是多行，则需要保持一致，使用花括号：

if (condition) {
        do_this();
        do_that();
} else {
        otherwise();
}

空格

4、在关键字“if, switch, case, for, do, while”之后需要加上空格，如：

if (something)

5、在关键字“sizeof, typeof, alignof, or __attribute__”之后不要加空格，如：

sizeof(struct file)

6、在括号里的表达式两边不要加空格，比如，下面是一个反面的例子：

sizeof( struct file )

7、大多说的二元和三元运算符两边需要空格，如“= + – < > * / % | & ^ <= >= == != ? :”；

8、一元运算符后面不要空格，如“& * + – ~ ! sizeof typeof alignof __attribute__ defined”；

9、在前缀自增自减运算符之后和后缀自增自减运算符之前不需要空格（“++”和“–”）；

10、结构成员运算符（“.”和“->”）的两边不需要空格；

11、行尾不需要空格；

注释

12、使用C89的“/* … */”风格而不是C99的“// …”风格；

13、对于多行注释，可以参考下例：

/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/

Kconfig

14、“config”定义下面的语句用Tab缩进，help下面的语句再额外缩进两个空格，如：

config AUDIT
        bool "Auditing support"
        depends on NET
        help
          Enable auditing infrastructure that can be used with another
          kernel subsystem, such as SELinux (which requires this for
          logging of avc messages output). Does not do system-call
          auditing without CONFIG_AUDITSYSCALL.

宏

15、多行的宏定义需要用“do .. while”封装，如：

#define macrofun(a, b, c)
do {
        if (a == 5)
                do_this(b, c);
} while (0)

函数返回值

16、函数返回值的定义最好也要遵循一定的章法。

如果函数的名称是一种动作或者命令式的语句，应该以错误代码的形式返回（通常是0表示成功，-Exxx这种形式的负数表示错误），如：

do_something()

如果函数的名称是判断语句，则返回值应该类似与布尔值（通常1表示成功，0表示错误），如：

something_is_present()

【参考资料】

（1） Documentation/CodingStyle

（2） http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/

来源：http://www.cnblogs.com/wwang/archive/2011/02/24/1960283.html

在上一篇文章“在 Linux 命令行中使用和执行 PHP 代码（一）”中，我同时着重讨论了直接在Linux命令行中运行PHP代码以及在Linux终端中执行PHP脚本文件。

本文旨在让你了解一些相当不错的Linux终端中的PHP交互性 shell 的用法特性。

让我们先在PHP 的交互shell中来对php.ini设置进行一些配置吧。

6. 设置PHP命令行提示符

要设置PHP命令行提示，你需要在Linux终端中使用下面的php -a（启用PHP交互模式）命令开启一个PHP交互shell。

$ php -a

然后，设置任何东西（比如说Hi Tecmint ::）作为PHP交互shell的命令提示符，操作如下：

php > #cli.prompt=Hi Tecmint ::

启用PHP交互Shell

同时，你也可以设置当前时间作为你的命令行提示符，操作如下：

php > #cli.prompt=`echo date('H:m:s');` >
22:15:43 >

7. 每次输出一屏

在我们上一篇文章中，我们已经在原始命令中通过管道在很多地方使用了less命令。通过该操作，我们可以在那些不能一屏全部输出的地方获得分屏显示。但是，我们可以通过配置php.ini文件，设置pager的值为less以每次输出一屏，操作如下：

$ php -a
php > #cli.pager=less

限制PHP屏幕输出

这样，下次当你运行一个命令（比如说条调试器phpinfo();）的时候，而该命令的输出内容又太过庞大而不能固定在一屏，它就会自动产生适合你当前屏幕的输出结果。

php > phpinfo();

PHP信息输出

8. 建议和TAB补全

PHP shell足够智能，它可以显示给你建议和进行TAB补全，你可以通过TAB键来使用该功能。如果对于你想要用TAB补全的字符串而言有多个选项，那么你需要使用两次TAB键来完成，其它情况则使用一次即可。

如果有超过一个的可能性，请使用两次TAB键。

php > ZIP [TAB] [TAB]

如果只有一个可能性，只要使用一次TAB键。

php > #cli.pager [TAB]

你可以一直按TAB键来获得建议的补全，直到该值满足要求。所有的行为都将记录到~/.php-history文件。

要检查你的PHP交互shell活动日志，你可以执行：

$ nano ~/.php_history | less

检查PHP交互Shell日志

9. 你可以在PHP交互shell中使用颜色，你所需要知道的仅仅是颜色代码。

使用echo来打印各种颜色的输出结果，类似这样：

php > echo "color_code1 TEXT second_color_code";

具体来说是：

php > echo "33[0;31m Hi Tecmint x1B[0m";

在PHP Shell中启用彩色

到目前为止，我们已经看到，按回车键意味着执行命令，然而PHP Shell中各个命令结尾的分号是必须的。

10. 在PHP shell中用basename()输出路径中最后一部分

PHP shell中的basename函数可以从给出的包含有到文件或目录路径的最后部分。

basename()样例#1和#2。

php > echo basename("/var/www/html/wp/wp-content/plugins");
php > echo basename("www.tecmint.com/contact-us.html");

上述两个样例将输出：

plugins
contact-us.html

在PHP中打印基本名称

11. 你可以使用PHP交互shell在你的桌面创建文件（比如说test1.txt），就像下面这么简单

php> touch("/home/avi/Desktop/test1.txt");

我们已经见识了PHP交互shell在数学运算中有多优秀，这里还有更多一些例子会令你吃惊。

12. 使用PHP交互shell打印比如像tecmint.com这样的字符串的长度

strlen函数用于获取指定字符串的长度。

php > echo strlen("tecmint.com");

在PHP中打印字符串长度

13. PHP交互shell可以对数组排序，是的，你没听错

声明变量a，并将其值设置为array(7,9,2,5,10)。

php > $a=array(7,9,2,5,10);

对数组中的数字进行排序。

php > sort($a);

以排序后的顺序打印数组中的数字，同时打印序号，第一个为[0]。

php > print_r($a);
Array
(
    [0] => 2
    [1] => 5
    [2] => 7
    [3] => 9
    [4] => 10
)

在PHP中对数组排序

14. 在PHP交互Shell中获取π的值

php > echo pi();
3.1415926535898

15. 打印某个数比如32的平方根

php > echo sqrt(150);
12.247448713916

16. 从0-10的范围内挑选一个随机数

php > echo rand(0, 10);

在PHP中获取随机数

17. 获取某个指定字符串的md5校验和sha1校验，例如，让我们在PHP Shell中检查某个字符串（比如说avi）的md5校验和sha1校验，并交叉校验bash shell生成的md5校验和sha1校验的结果。

php > echo md5(avi);
3fca379b3f0e322b7b7967bfcfb948ad
php > echo sha1(avi);
8f920f22884d6fea9df883843c4a8095a2e5ac6f

---

$ echo -n avi | md5sum
3fca379b3f0e322b7b7967bfcfb948ad  -
$ echo -n avi | sha1sum
8f920f22884d6fea9df883843c4a8095a2e5ac6f  -

在PHP中检查md5校验和sha1校验

这里只是PHP Shell中所能获取的功能和PHP Shell的交互特性的惊鸿一瞥，这些就是到现在为止我所讨论的一切。保持连线，在评论中为我们提供你有价值的反馈吧。为我们点赞并分享，帮助我们扩散哦。

---

via: http://www.tecmint.com/execute-php-codes-functions-in-linux-commandline/

作者：Avishek Kumar 译者：GOLinux 校对：wxy

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

来源：https://linux.cn/article-5916-1.html

Systemctl是一个systemd工具，主要负责控制systemd系统和服务管理器。

Systemd是一个系统管理守护进程、工具和库的集合，用于取代System V初始进程。Systemd的功能是用于集中管理和配置类UNIX系统。

在Linux生态系统中，Systemd被部署到了大多数的标准Linux发行版中，只有为数不多的几个发行版尚未部署。Systemd通常是所有其它守护进程的父进程，但并非总是如此。

使用Systemctl管理Linux服务

本文旨在阐明在运行systemd的系统上“如何控制系统和服务”。

Systemd初体验和Systemctl基础

1. 首先检查你的系统中是否安装有systemd并确定当前安装的版本

# systemd --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR

上例中很清楚地表明，我们安装了215版本的systemd。

2. 检查systemd和systemctl的二进制文件和库文件的安装位置

# whereis systemd
systemd: /usr/lib/systemd /etc/systemd /usr/share/systemd /usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl: /usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz

3. 检查systemd是否运行

# ps -eaf | grep [s]ystemd
root         1     0  0 16:27 ?        00:00:00 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
root       444     1  0 16:27 ?        00:00:00 /usr/lib/systemd/systemd-journald
root       469     1  0 16:27 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       555     1  0 16:27 ?        00:00:00 /usr/lib/systemd/systemd-logind
dbus       556     1  0 16:27 ?        00:00:00 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

注意：systemd是作为父进程（PID=1）运行的。在上面带（-e）参数的ps命令输出中，选择所有进程，（-a）选择除会话前导外的所有进程，并使用（-f）参数输出完整格式列表（即 -eaf）。

也请注意上例中后随的方括号和例子中剩余部分。方括号表达式是grep的字符类表达式的一部分。

4. 分析systemd启动进程

# systemd-analyze
Startup finished in 487ms (kernel) + 2.776s (initrd) + 20.229s (userspace) = 23.493s

5. 分析启动时各个进程花费的时间

# systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....

6. 分析启动时的关键链

# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s +8.565s
  └─network.target @11.168s
    └─network.service @9.456s +1.712s
      └─NetworkManager.service @8.858s +596ms
        └─firewalld.service @4.931s +3.926s
          └─basic.target @4.916s
            └─sockets.target @4.916s
              └─dbus.socket @4.916s
                └─sysinit.target @4.905s
                  └─systemd-update-utmp.service @4.864s +39ms
                    └─auditd.service @4.563s +301ms
                      └─systemd-tmpfiles-setup.service @4.485s +69ms
                        └─rhel-import-state.service @4.342s +142ms
                          └─local-fs.target @4.324s
                            └─boot.mount @4.286s +31ms
                              └─systemd-fsck@dev-disk-byx2duuid-79f594adx2da332x2d4730x2dbb5fx2d85d19608096
                                └─dev-disk-byx2duuid-79f594adx2da332x2d4730x2dbb5fx2d85d196080964.device @4

重要：Systemctl接受服务（.service），挂载点（.mount），套接口（.socket）和设备（.device）作为单元。

7. 列出所有可用单元

# systemctl list-unit-files
UNIT FILE                                   STATE
proc-sys-fs-binfmt_misc.automount           static
dev-hugepages.mount                         static
dev-mqueue.mount                            static
proc-sys-fs-binfmt_misc.mount               static
sys-fs-fuse-connections.mount               static
sys-kernel-config.mount                     static
sys-kernel-debug.mount                      static
tmp.mount                                   disabled
brandbot.path                               disabled
.....

8. 列出所有运行中单元

# systemctl list-units
UNIT                                        LOAD   ACTIVE SUB       DESCRIPTION
proc-sys-fs-binfmt_misc.automount           loaded active waiting   Arbitrary Executable File Formats File Syste
sys-devices-pc...0-1:0:0:0-block-sr0.device loaded active plugged   VBOX_CD-ROM
sys-devices-pc...:00:03.0-net-enp0s3.device loaded active plugged   PRO/1000 MT Desktop Adapter
sys-devices-pc...00:05.0-sound-card0.device loaded active plugged   82801AA AC'97 Audio Controller
sys-devices-pc...:0:0-block-sda-sda1.device loaded active plugged   VBOX_HARDDISK
sys-devices-pc...:0:0-block-sda-sda2.device loaded active plugged   LVM PV Qzyo3l-qYaL-uRUa-Cjuk-pljo-qKtX-VgBQ8
sys-devices-pc...0-2:0:0:0-block-sda.device loaded active plugged   VBOX_HARDDISK
sys-devices-pl...erial8250-tty-ttyS0.device loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS0
sys-devices-pl...erial8250-tty-ttyS1.device loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS1
sys-devices-pl...erial8250-tty-ttyS2.device loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS2
sys-devices-pl...erial8250-tty-ttyS3.device loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS3
sys-devices-virtual-block-dmx2d0.device    loaded active plugged   /sys/devices/virtual/block/dm-0
sys-devices-virtual-block-dmx2d1.device    loaded active plugged   /sys/devices/virtual/block/dm-1
sys-module-configfs.device                  loaded active plugged   /sys/module/configfs
...

9. 列出所有失败单元

# systemctl --failed
UNIT          LOAD   ACTIVE SUB    DESCRIPTION
kdump.service loaded failed failed Crash recovery kernel arming
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

10. 检查某个单元（如 cron.service）是否启用

# systemctl is-enabled crond.service
enabled

11. 检查某个单元或服务是否运行

# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Tue 2015-04-28 16:27:55 IST; 34min ago
 Main PID: 549 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─549 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
Apr 28 16:27:51 tecmint systemd[1]: Starting firewalld - dynamic firewall daemon...
Apr 28 16:27:55 tecmint systemd[1]: Started firewalld - dynamic firewall daemon.

使用Systemctl控制并管理服务

12. 列出所有服务（包括启用的和禁用的）

# systemctl list-unit-files --type=service
UNIT FILE                                   STATE
arp-ethers.service                          disabled
auditd.service                              enabled
autovt@.service                             disabled
blk-availability.service                    disabled
brandbot.service                            static
collectd.service                            disabled
console-getty.service                       disabled
console-shell.service                       disabled
cpupower.service                            disabled
crond.service                               enabled
dbus-org.fedoraproject.FirewallD1.service   enabled
....

13. Linux中如何启动、重启、停止、重载服务以及检查服务（如 httpd.service）状态

# systemctl start httpd.service
# systemctl restart httpd.service
# systemctl stop httpd.service
# systemctl reload httpd.service
# systemctl status httpd.service
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
   Active: active (running) since Tue 2015-04-28 17:21:30 IST; 6s ago
  Process: 2876 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=0/SUCCESS)
 Main PID: 2881 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─2881 /usr/sbin/httpd -DFOREGROUND
           ├─2884 /usr/sbin/httpd -DFOREGROUND
           ├─2885 /usr/sbin/httpd -DFOREGROUND
           ├─2886 /usr/sbin/httpd -DFOREGROUND
           ├─2887 /usr/sbin/httpd -DFOREGROUND
           └─2888 /usr/sbin/httpd -DFOREGROUND
Apr 28 17:21:30 tecmint systemd[1]: Starting The Apache HTTP Server...
Apr 28 17:21:30 tecmint httpd[2881]: AH00558: httpd: Could not reliably determine the server's fully q...ssage
Apr 28 17:21:30 tecmint systemd[1]: Started The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

注意：当我们使用systemctl的start，restart，stop和reload命令时，我们不会从终端获取到任何输出内容，只有status命令可以打印输出。

14. 如何激活服务并在启动时启用或禁用服务（即系统启动时自动启动服务）

# systemctl is-active httpd.service
# systemctl enable httpd.service
# systemctl disable httpd.service

15. 如何屏蔽（让它不能启动）或显示服务（如 httpd.service）

# systemctl mask httpd.service
ln -s '/dev/null' '/etc/systemd/system/httpd.service'
# systemctl unmask httpd.service
rm '/etc/systemd/system/httpd.service'

16. 使用systemctl命令杀死服务

# systemctl kill httpd
# systemctl status httpd
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
   Active: failed (Result: exit-code) since Tue 2015-04-28 18:01:42 IST; 28min ago
 Main PID: 2881 (code=exited, status=0/SUCCESS)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
Apr 28 17:37:29 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:29 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:39 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:39 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:49 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:49 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:59 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 17:37:59 tecmint systemd[1]: httpd.service: Got notification message from PID 2881, but recepti...bled.
Apr 28 18:01:42 tecmint systemd[1]: httpd.service: control process exited, code=exited status=226
Apr 28 18:01:42 tecmint systemd[1]: Unit httpd.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

使用Systemctl控制并管理挂载点

17. 列出所有系统挂载点

# systemctl list-unit-files --type=mount
UNIT FILE                     STATE
dev-hugepages.mount           static
dev-mqueue.mount              static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount       static
sys-kernel-debug.mount        static
tmp.mount                     disabled

18. 挂载、卸载、重新挂载、重载系统挂载点并检查系统中挂载点状态

# systemctl start tmp.mount
# systemctl stop tmp.mount
# systemctl restart tmp.mount
# systemctl reload tmp.mount
# systemctl status tmp.mount
tmp.mount - Temporary Directory
   Loaded: loaded (/usr/lib/systemd/system/tmp.mount; disabled)
   Active: active (mounted) since Tue 2015-04-28 17:46:06 IST; 2min 48s ago
    Where: /tmp
     What: tmpfs
     Docs: man:hier(7)
http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
  Process: 3908 ExecMount=/bin/mount tmpfs /tmp -t tmpfs -o mode=1777,strictatime (code=exited, status=0/SUCCESS)
Apr 28 17:46:06 tecmint systemd[1]: Mounting Temporary Directory...
Apr 28 17:46:06 tecmint systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Apr 28 17:46:06 tecmint systemd[1]: Mounted Temporary Directory.

19. 在启动时激活、启用或禁用挂载点（系统启动时自动挂载）

# systemctl is-active tmp.mount
# systemctl enable tmp.mount
# systemctl disable  tmp.mount

20. 在Linux中屏蔽（让它不能启用）或可见挂载点

# systemctl mask tmp.mount
ln -s '/dev/null' '/etc/systemd/system/tmp.mount'
# systemctl unmask tmp.mount
rm '/etc/systemd/system/tmp.mount'

使用Systemctl控制并管理套接口

21. 列出所有可用系统套接口

# systemctl list-unit-files --type=socket
UNIT FILE                    STATE
dbus.socket                  static
dm-event.socket              enabled
lvm2-lvmetad.socket          enabled
rsyncd.socket                disabled
sshd.socket                  disabled
syslog.socket                static
systemd-initctl.socket       static
systemd-journald.socket      static
systemd-shutdownd.socket     static
systemd-udevd-control.socket static
systemd-udevd-kernel.socket  static
11 unit files listed.

22. 在Linux中启动、重启、停止、重载套接口并检查其状态

# systemctl start cups.socket
# systemctl restart cups.socket
# systemctl stop cups.socket
# systemctl reload cups.socket
# systemctl status cups.socket
cups.socket - CUPS Printing Service Sockets
   Loaded: loaded (/usr/lib/systemd/system/cups.socket; enabled)
   Active: active (listening) since Tue 2015-04-28 18:10:59 IST; 8s ago
   Listen: /var/run/cups/cups.sock (Stream)
Apr 28 18:10:59 tecmint systemd[1]: Starting CUPS Printing Service Sockets.
Apr 28 18:10:59 tecmint systemd[1]: Listening on CUPS Printing Service Sockets.

23. 在启动时激活套接口，并启用或禁用它（系统启动时自启动）

# systemctl is-active cups.socket
# systemctl enable cups.socket
# systemctl disable cups.socket

24. 屏蔽（使它不能启动）或显示套接口

# systemctl mask cups.socket
ln -s '/dev/null' '/etc/systemd/system/cups.socket'
# systemctl unmask cups.socket
rm '/etc/systemd/system/cups.socket'

服务的CPU利用率（分配额）

25. 获取当前某个服务的CPU分配额（如httpd）

# systemctl show -p CPUShares httpd.service
CPUShares=1024

注意：各个服务的默认CPU分配份额=1024，你可以增加/减少某个进程的CPU分配份额。

26. 将某个服务（httpd.service）的CPU分配份额限制为2000 CPUShares/

# systemctl set-property httpd.service CPUShares=2000
# systemctl show -p CPUShares httpd.service
CPUShares=2000

注意：当你为某个服务设置CPUShares，会自动创建一个以服务名命名的目录（如 httpd.service），里面包含了一个名为90-CPUShares.conf的文件，该文件含有CPUShare限制信息，你可以通过以下方式查看该文件：

# vi /etc/systemd/system/httpd.service.d/90-CPUShares.conf
[Service]
CPUShares=2000

27. 检查某个服务的所有配置细节

# systemctl show httpd
Id=httpd.service
Names=httpd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=network.target remote-fs.target nss-lookup.target systemd-journald.socket basic.target system.slice
Description=The Apache HTTP Server
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/usr/lib/systemd/system/httpd.service
....

28. 分析某个服务（httpd）的关键链

# systemd-analyze critical-chain httpd.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
httpd.service +142ms
└─network.target @11.168s
  └─network.service @9.456s +1.712s
    └─NetworkManager.service @8.858s +596ms
      └─firewalld.service @4.931s +3.926s
        └─basic.target @4.916s
          └─sockets.target @4.916s
            └─dbus.socket @4.916s
              └─sysinit.target @4.905s
                └─systemd-update-utmp.service @4.864s +39ms
                  └─auditd.service @4.563s +301ms
                    └─systemd-tmpfiles-setup.service @4.485s +69ms
                      └─rhel-import-state.service @4.342s +142ms
                        └─local-fs.target @4.324s
                          └─boot.mount @4.286s +31ms
                            └─systemd-fsck@dev-disk-byx2duuid-79f594adx2da332x2d4730x2dbb5fx2d85d196080964.service @4.092s +149ms
                              └─dev-disk-byx2duuid-79f594adx2da332x2d4730x2dbb5fx2d85d196080964.device @4.092s

29. 获取某个服务（httpd）的依赖性列表

# systemctl list-dependencies httpd.service
httpd.service
├─system.slice
└─basic.target
  ├─firewalld.service
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
  │ ├─-.slice
  │ └─system.slice
  ├─sockets.target
  │ ├─dbus.socket
....

30. 按等级列出控制组

# systemd-cgls
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
├─user.slice
│ └─user-0.slice
│   └─session-1.scope
│     ├─2498 sshd: root@pts/0
│     ├─2500 -bash
│     ├─4521 systemd-cgls
│     └─4522 systemd-cgls
└─system.slice
  ├─httpd.service
  │ ├─4440 /usr/sbin/httpd -DFOREGROUND
  │ ├─4442 /usr/sbin/httpd -DFOREGROUND
  │ ├─4443 /usr/sbin/httpd -DFOREGROUND
  │ ├─4444 /usr/sbin/httpd -DFOREGROUND
  │ ├─4445 /usr/sbin/httpd -DFOREGROUND
  │ └─4446 /usr/sbin/httpd -DFOREGROUND
  ├─polkit.service
  │ └─721 /usr/lib/polkit-1/polkitd --no-debug
....

31. 按CPU、内存、输入和输出列出控制组

# systemd-cgtop
Path                                                              Tasks   %CPU   Memory  Input/s Output/s
/                                                                    83    1.0   437.8M        -        -
/system.slice                                                         -    0.1        -        -        -
/system.slice/mariadb.service                                         2    0.1        -        -        -
/system.slice/tuned.service                                           1    0.0        -        -        -
/system.slice/httpd.service                                           6    0.0        -        -        -
/system.slice/NetworkManager.service                                  1      -        -        -        -
/system.slice/atop.service                                            1      -        -        -        -
/system.slice/atopacct.service                                        1      -        -        -        -
/system.slice/auditd.service                                          1      -        -        -        -
/system.slice/crond.service                                           1      -        -        -        -
/system.slice/dbus.service                                            1      -        -        -        -
/system.slice/firewalld.service                                       1      -        -        -        -
/system.slice/lvm2-lvmetad.service                                    1      -        -        -        -
/system.slice/polkit.service                                          1      -        -        -        -
/system.slice/postfix.service                                         3      -        -        -        -
/system.slice/rsyslog.service                                         1      -        -        -        -
/system.slice/system-getty.slice/getty@tty1.service                   1      -        -        -        -
/system.slice/systemd-journald.service                                1      -        -        -        -
/system.slice/systemd-logind.service                                  1      -        -        -        -
/system.slice/systemd-udevd.service                                   1      -        -        -        -
/system.slice/webmin.service                                          1      -        -        -        -
/user.slice/user-0.slice/session-1.scope                              3      -        -        -        -

控制系统运行等级

32. 启动系统救援模式

# systemctl rescue
Broadcast message from root@tecmint on pts/0 (Wed 2015-04-29 11:31:18 IST):
The system is going down to rescue mode NOW!

33. 进入紧急模式

# systemctl emergency
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode.

34. 列出当前使用的运行等级

# systemctl get-default
multi-user.target

35. 启动运行等级5，即图形模式

# systemctl isolate runlevel5.target
或
# systemctl isolate graphical.target

36. 启动运行等级3，即多用户模式（命令行）

# systemctl isolate runlevel3.target
或
# systemctl isolate multiuser.target

36. 设置多用户模式或图形模式为默认运行等级

# systemctl set-default runlevel3.target
# systemctl set-default runlevel5.target

37. 重启、停止、挂起、休眠系统或使系统进入混合睡眠

# systemctl reboot
# systemctl halt
# systemctl suspend
# systemctl hibernate
# systemctl hybrid-sleep

对于不知运行等级为何物的人，说明如下。

• Runlevel 0 : 关闭系统
• Runlevel 1 : 救援？维护模式
• Runlevel 3 : 多用户，无图形系统
• Runlevel 4 : 多用户，无图形系统
• Runlevel 5 : 多用户，图形化系统
• Runlevel 6 : 关闭并重启机器

到此为止吧。保持连线，进行评论。别忘了在下面的评论中为我们提供一些有价值的反馈哦。喜欢我们、与我们分享，求扩散。

---

via: http://www.tecmint.com/manage-services-using-systemd-and-systemctl-in-linux/

作者：Avishek Kumar 译者：GOLinux 校对：wxy

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

来源：https://linux.cn/article-5926-1.html

当Linux驱动程序开发到一定阶段，向kernel.org提交代码是一个很好的选择。对于很多没有向上游提交过代码的开发者来说，还是有很多疑问需要解决的。比如，究竟我们向哪里提交驱动程序？提交时我们的代码应该处于什么状态？提交的过程又如何呢？

向哪里提交

Linux staging tree是Greg KH建立的用于提交驱动程序的git仓库。我们可以把staging tree看作是代码进入mainline内核之前的一个预科班，新增的驱动程序首先需要放到这里供社区review和测试。Staging tree是 Greg KH于2008年建立的一棵kernel tree，其建立之目的是用来放置一些未充分测试或者因为一些其他原因未能进入内核的新增驱动程序和新增文件系统。

Linux staging tree的URL是” git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git “或者” http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git “。这里需要注意的是，git协议的端口号是9418，因为很多公司的防火墙只会开放80端口，clone代码仓库时如果git协议超时，不妨试试http协议。

关于Linux staging tree更详细的描述可以参考我前一篇博文《小议Linux staging tree》。

我们的代码

在我们向上游提交驱动程序之前，需要保证代码能够遵循Linux内核的coding style。当然，这个规定并不是强制的，如果您经常阅读Linux内核代码，就会发现很多驱动对内核coding style的遵循情况也并不是太好。但一致的代码风格对代码的维护大有裨益，所以对作为Linux内核驱动程序员的我们来说，遵循coding style是一个很好的习惯。关于Linux内核的coding style的详细信息，可以参考Linux内核里的Documentation/CodingStyle文档，或者我之前的博文《谈谈为 Linux 内核开发驱动代码的编码风格》。

我们在提交驱动之前还需要用静态代码检查工具sparse来检查一下代码。

sparse的源代码可以从“git://git.kernel.org/pub/scm/devel/sparse/sparse.git”获得，得到代码之后，执行”make; make install”来编译生成可执行程序。默认情况下，sparse程序会被放到目录“~/bin”下面，如果您不喜欢这个位置，可以修改Makefile来设定路径。需要注意的是，使用sparse之前，PATH环境变量要设置正确。

sparse的使用方法很简单，只要在make驱动程序时加上“C=N”的选项即可，其中N的取值是1或者2。当N=1时表示对需要重新编译的C文件进行代码检查，N=2时表示对所有的C文件进行代码检查。

对于staging目录下的驱动来说，我们还需要附上一个TODO文件，用来描述未来的维护计划。一般情况下，TODO文件可以这样写：

TODO:
- support more features
- use kernel coding style
- checkpatch.pl fixes

如何提交

我们可以通过patch的形式把驱动程序提交给staging tree。提交之前，需要首先把staging tree clone到本地，然后基于当前的工作目录制作patch。

Git提供了制作格式化的patch的功能，命令如下：

git format-patch -N

其中，N是整数，用来指定我们把最近N次提交做成N个patch。比如当N=1时，就表示把最近一次提交制作成patch。Git会根据提交的log信息来自动命名patch文件。

这里需要注意的是，每次提交的log的描述要遵循一定的格式。

Log的第一行是一个简短的描述。本文主要介绍如何向staging tree提交代码，我们需要在Log首行以“staging:”开头。Log的最后一行需要提供提交者的email信息，我们可以这样写：“Signed-off-by: wwang ”。

举个例子，假定我们的staging driver命名为hello_world，log的格式可以参考如下：

staging: hello_world: My first commit
This is my first commit.
Signed-off-by: wwang 

Patch生成之后，我们需要把它寄给staging tree的维护者，通常是Greg KH本人以及linux内核驱动的开发者列表。这个步骤也可以使用git来帮助我们完成，但首先需要确定系统里已经安装msmtp和git-email这两个包。这里还需提醒一下，如果您的邮件服务器是Exchange，很可能需要NTLM认证，这就要求msmtp支持NTLM。Ubuntu仓库里的msmtp默认支持NTLM，可以直接使用，但还有些其他的发行版的软件仓库里自带的msmtp并不支持NTLM（如Arch Linux），这种情况就需要自己编译了。

msmtp安装好之后，需要配置”~/.msmtprc”文件。以Gmail为例，”.msmtprc”可以这样配置：

# Set default values for all following accounts.
defaults
logfile ~/.msmtp.log
# gmail
account gmail
protocol smtp
host smtp.gmail.com
from my@gmail.com
user my@gmail.com
password mypasswd
port 587
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
syslog LOG_MAIL
# Set a default account
account default : gmail

用git发送patch的命令如下：

git send-email
　　--smtp-server /usr/bin/msmtp
　　--from my@gmail.com
　　--to gregkh@suse.de
　　--to devel@linuxdriverproject.org
　　--to linux-kernel@vger.kernel.org
　　./my.patch

将patch发送出去只是提交驱动程序的第一步，之后还需要不断的维护与完善，把代码丢给内核然后就放手不管的做法是不可取的。提交代码还有一个原则，就是每次提交只做一件事情，这样才会比较方便内核维护者来review我们的代码。

来源：http://www.cnblogs.com/wwang/archive/2011/04/01/1951742.html

以前的博客是使用Jekyll托管在github上，后来用着越来越不方便，比如没有自动生成post，不能一键部署，文件结构和配置也是比较繁琐，更重要的是有时候用markdown写一篇文章，生成的静态文件很乱，应该是有些字符解析的问题。现在下决心换成了hexo。

Nodejs安装

因为hexo是基于nodejs的应用，所以要先安装nodejs才可以。我这里以ubuntu为例，因为我自己一直在使用ubuntu。使用如下命令即可：

sudo apt-get install nodejs
sudo apt-get install npm

Hexo安装

Hexo 是一个功能强大的静态网站生成系统，快速、简洁、高效。Hexo 支持 GitHub Flavored Markdown 的所有功能，甚至可以整合 Octopress 的大多数插件。可以一键部署到github，还有丰富的插件和主题,还支持热部署哦。执行如下命令进行安装。

sudo npm install hexo-cli -g

快速开始

安装Hexo安成后，使用如下命令快速新建一个博客系统，然后运行它：

hexo init blog
cd blog
npm install
hexo server

如果npm安装失败，请使用sudo安装。运行成功后，访问 http://0.0.0.0:4000/ 就可以看到博客的样子的，对就是我现在的博客这个样子，o(∩∩)o…哈哈。

现在我们来看看Hexo 生成博客的目录结构：

.
├── _config.yml
├── db.json
├── node_modules
├── package.json
├── public
├── scaffolds
├── source
└── themes

其中_config.yml是配置站点的文件，public是hexo生成的静态站点文件夹，scaffolds是模板文件夹，source是存在用户资源的文件夹，themes是主题文件夹。

站点配置

找到title，subtitle，author参数配置，分别配置站点的标题、副标题和作者,比如我这里是：

title: 飞雪无情的博客
subtitle: 专注于Android、Java、移动互联网、项目管理、软件架构
description:
author: 飞雪无情
language: zh-CN

然后配置站点的url和permalink，这两个分别是你的站点的url host地址以及文章的永久连接，我这里是：

url: http://www.flysnow.org
root: /
permalink: :year/:month/:day/:title.html
permalink_defaults:

permalink 我配置的是年月日以及title，后缀是html，便于搜索收录。permalink详情参见： http://hexo.io/zh-cn/docs/permalinks.html

新增一篇文章

使用如下命令即可新增一篇md格式的文章：

hexo new 'github-page-with-hexo'

然后就会在sources/_posts生成一篇文件名为github-page-with-hexo.md的markdown文件。编辑该文件就可以写博客了。这里有一些Front-matter需要介绍，可以配置文章使用的模板、所属的分类和tag等。

Front-matter 是文件最上方以 —- 分隔的区域，用于指定个别文件的变量，举例来说：

title: "使用Hexo在Github上搭建自己的博客"
date: 2015-03-10 22:30:04
tags:
- Hexo
- Github
categories:
- Hexo
---

请注意，目前的categories只能有一个一级分类，如果填写多个，第二个会被解析为二级分类，以及类推。tags可以允许有多个。更多关于Front-matter请参考 http://hexo.io/zh-cn/docs/front-matter.html 。

发布到github page

首先你已经创建好了你的github page对应的git库，没有创建的可以google相关博客。然后新建一个hexo分支，存放你现在hexo的所有文件。然后执行如下命令清理并生成发布的静态站点文件。

hexo clean
hexo generate

然后把生成的public目录下的文件放到你的master分支下即可。git commit后把这两个分支推送到你的github上。git库结构可以参见我的github page库 https://github.com/rujews/rujews.github.io 。

最后

然后等个几分钟，访问你的域名就可以看到你的网站了。如http://www.flysnow.org/ 。关于更多的Hexo请参考官方文档 http://hexo.io/zh-cn/docs/ 。

来源：http://www.flysnow.org/2015/03/10/github-page-with-hexo.html

构建一个分布式系统是很困难的。它需要可扩展性、容错性、高可用性、一致性、可伸缩以及高效。为了达到这些目的，分布式系统需要很多复杂的组件以一种复杂的方式协同工作。例如，Apache Hadoop在大型集群上并行处理TB级别的数据集时，需要依赖有着高容错的文件系统（HDFS）来达到高吞吐量。

在之前，每一个新的分布式系统，例如Hadoop和Cassandra，都需要构建自己的底层架构，包括消息处理、存储、网络、容错性和可伸缩性。庆幸的是，像Apache Mesos这样的系统，通过给分布式系统的关键构建模块提供类似操作系统的管理服务，简化了构建和管理分布式系统的任务。Mesos抽离了CPU、存储和其它计算资源，因此开发者开发分布式应用程序时能够将整个数据中心集群当做一台巨型机对待。

构建在Mesos上的应用程序被称为框架，它们能解决很多问题：Apache Spark，一种流行的集群式数据分析工具；Chronos，一个类似cron的具有容错性的分布式scheduler，这是两个构建在Mesos上的框架的例子。构建框架可以使用多种语言，包括C++，Go，Python，Java，Haskell和 Scala。

在分布式系统用例上，比特币开采就是一个很好的例子。比特币将为生成 acceptable hash 的挑战转为验证一块事务的可靠性。可能需要几十年，单台笔记本电脑挖一块可能需要花费超过150年。结果是，有许多的“采矿池”允许采矿者将他们的计算资源联合起来以加快挖矿速度。Mesosphere的一个实习生，Derek，写了一个比特币开采框架，利用集群资源的优势来做同样的事情。在接下来的内容中，会以他的代码为例。

1个Mesos框架有1个scheduler 和1个executor组成。scheduler 和Mesos master通信并决定运行什么任务，而executor 运行在slaves上面，执行实际任务。大多数的框架实现了自己的scheduler，并使用1个由Mesos提供的标准executors。当然，框架也可以自己定制executor。在这个例子中即会编写定制的scheduler，并使用标准命令执行器（executor）运行包含我们比特币服务的Docker镜像。

对这里的scheduler来说，需要运行的有两种任务—— 单矿服务器任务和多矿服务器任务。服务器会和一个比特币采矿池通信，并给每个“工人”分配块。“工人”会努力工作，即开采比特币。

任务实际上被封装在executor框架中，因此任务运行意味着告诉Mesos master在其中一个slave上面启动一个executor。由于这里使用的是标准命令执行器（executor），因此可以指定任务是二进制可执行文件、bash脚本或者其他命令。由于Mesos支持Docker，因此在本例中将使用可执行的Docker镜像。Docker是这样一种技术，它允许你将应用程序和它运行时需要的依赖一起打包。

为了在Mesos中使用Docker镜像，这里需要在Docker registry中注册它们的名称： 

const (
    MinerServerDockerImage = "derekchiang/p2pool"
    MinerDaemonDockerImage = "derekchiang/cpuminer"
)

然后定义一个常量，指定每个任务所需资源：

const (
    MemPerDaemonTask = 128  // mining shouldn't be memory-intensive
    MemPerServerTask = 256
    CPUPerServerTask = 1    // a miner server does not use much CPU
)

现在定义一个真正的scheduler，对其跟踪，并确保其正确运行需要的状态：

type MinerScheduler struct {
    // bitcoind RPC credentials
    bitcoindAddr string
    rpcUser      string
    rpcPass      string
    // mutable state
    minerServerRunning  bool
    minerServerHostname string
    minerServerPort     int    // the port that miner daemons
                               // connect to
    // unique task ids
    tasksLaunched        int
    currentDaemonTaskIDs []*mesos.TaskID
}

这个scheduler必须实现下面的接口：

type Scheduler interface {
    Registered(SchedulerDriver, *mesos.FrameworkID, *mesos.MasterInfo)
    Reregistered(SchedulerDriver, *mesos.MasterInfo)
    Disconnected(SchedulerDriver)
    ResourceOffers(SchedulerDriver, []*mesos.Offer)
    OfferRescinded(SchedulerDriver, *mesos.OfferID)
    StatusUpdate(SchedulerDriver, *mesos.TaskStatus)
    FrameworkMessage(SchedulerDriver, *mesos.ExecutorID,
                     *mesos.SlaveID, string)
    SlaveLost(SchedulerDriver, *mesos.SlaveID)
    ExecutorLost(SchedulerDriver, *mesos.ExecutorID, *mesos.SlaveID,
                 int)
    Error(SchedulerDriver, string)
} 

现在一起看一个回调函数：

func (s *MinerScheduler) Registered(_ sched.SchedulerDriver,
      frameworkId *mesos.FrameworkID, masterInfo *mesos.MasterInfo) {
    log.Infoln("Framework registered with Master ", masterInfo)
}
func (s *MinerScheduler) Reregistered(_ sched.SchedulerDriver,
      masterInfo *mesos.MasterInfo) {
    log.Infoln("Framework Re-Registered with Master ", masterInfo)
}
func (s *MinerScheduler) Disconnected(sched.SchedulerDriver) {
    log.Infoln("Framework disconnected with Master")
}

Registered在scheduler 成功向Mesos master注册之后被调用。

Reregistered在scheduler 与Mesos master断开连接并且再次注册时被调用，例如，在master重启的时候。

Disconnected在scheduler 与Mesos master断开连接时被调用。这个在master挂了的时候会发生。

目前为止，这里仅仅在回调函数中打印了日志信息，因为对于一个像这样的简单框架，大多数回调函数可以空在那里。然而，下一个回调函数就是每一个框架的核心，必须要认真的编写。

ResourceOffers在scheduler 从master那里得到一个offer的时候被调用。每一个offer包含一个集群上可以给框架使用的资源列表。资源通常包括CPU、内存、端口和磁盘。一个框架可以使用它提供的一些资源、所有资源或者一点资源都不给用。

针对每一个offer，现在期望聚集所有的提供的资源并决定是否需要发布一个新的server任务或者一个新的worker任务。这里可以向每个offer发送尽可能多的任务以测试最大容量，但是由于开采比特币是依赖CPU的，所以这里每个offer运行一个开采者任务并使用所有可用的CPU资源。

for i, offer := range offers {
    // … Gather resource being offered and do setup
    if !s.minerServerRunning && mems >= MemPerServerTask &&
            cpus >= CPUPerServerTask && ports >= 2 {
        // … Launch a server task since no server is running and we
        // have resources to launch it.
    } else if s.minerServerRunning && mems >= MemPerDaemonTask {
        // … Launch a miner since a server is running and we have mem
        // to launch one.
    }
}

针对每个任务都需要创建一个对应的TaskInfo message ，它包含了运行这个任务需要的信息。

s.tasksLaunched++
taskID = &mesos.TaskID {
    Value: proto.String("miner-server-" +
                        strconv.Itoa(s.tasksLaunched)),
} 

Task IDs由框架决定，并且每个框架必须是唯一的。

containerType := mesos.ContainerInfo_DOCKER
task = &mesos.TaskInfo {
    Name: proto.String("task-" + taskID.GetValue()),
    TaskId: taskID,
    SlaveId: offer.SlaveId,
    Container: &mesos.ContainerInfo {
        Type: &containerType,
        Docker: &mesos.ContainerInfo_DockerInfo {
            Image: proto.String(MinerServerDockerImage),
        },
    },
    Command: &mesos.CommandInfo {
        Shell: proto.Bool(false),
        Arguments: []string {
            // these arguments will be passed to run_p2pool.py
            "--bitcoind-address", s.bitcoindAddr,
            "--p2pool-port", strconv.Itoa(int(p2poolPort)),
            "-w", strconv.Itoa(int(workerPort)),
            s.rpcUser, s.rpcPass,
        },
    },
    Resources: []*mesos.Resource {
        util.NewScalarResource("cpus", CPUPerServerTask),
        util.NewScalarResource("mem", MemPerServerTask),
    },
}

TaskInfo message指定了一些关于任务的重要元数据信息，它允许Mesos节点运行Docker容器，特别会指定name、task ID、container information以及一些需要给容器传递的参数。这里也会指定任务需要的资源。

现在TaskInfo已经被构建好，因此任务可以这样运行：

driver.LaunchTasks([]*mesos.OfferID{offer.Id}, tasks, &mesos.Filters{RefuseSeconds: proto.Float64(1)})

在框架中，需要处理的最后一件事情是当开采者server关闭时会发生什么。这里可以利用StatusUpdate 函数来处理。

在一个任务的生命周期中，针对不同的阶段有不同类型的状态更新。对这个框架来说，想要确保的是如果开采者server由于某种原因失败，系统会Kill所有开采者worker以避免浪费资源。这里是相关的代码：

if strings.Contains(status.GetTaskId().GetValue(), "server") &&
    (status.GetState() == mesos.TaskState_TASK_LOST ||
        status.GetState() == mesos.TaskState_TASK_KILLED ||
        status.GetState() == mesos.TaskState_TASK_FINISHED ||
        status.GetState() == mesos.TaskState_TASK_ERROR ||
        status.GetState() == mesos.TaskState_TASK_FAILED) {
    s.minerServerRunning = false
    // kill all tasks
    for _, taskID := range s.currentDaemonTaskIDs {
        _, err := driver.KillTask(taskID)
        if err != nil {
            log.Errorf("Failed to kill task %s", taskID)
        }
    }
    s.currentDaemonTaskIDs = make([]*mesos.TaskID, 0)
}

万事大吉！通过努力，这里在Apache Mesos上建立一个正常工作的分布式比特币开采框架，它只用了大约300行GO代码。这证明了使用Mesos 框架的API编写分布式系统是多么快速和简单。

来源：http://www.csdn.net/article/2015-07-31/2825348

关于 Ceph 的介绍网上一大堆，这里就不重复了。Sage Weil 读博士的时候开发了这套牛逼的分布式存储系统，最初是奔着高性能分布式文件系统去的，结果云计算风口一来，Ceph 重心转向了分布式块存储（Block Storage）和分布式对象存储（Object Storage），现在分布式文件系统 CephFS 还停在 beta 阶段。Ceph 现在是云计算、虚拟机部署的最火开源存储解决方案，据说有20%的 OpenStack 部署存储用的都是 Ceph 的 block storage.

Ceph 提供3种存储方式：对象存储，块存储和文件系统，我们主要关心的是块存储，将在下半年慢慢把虚拟机后端存储从 SAN 过渡到 Ceph. 虽然还是 0.94 版本，Ceph 现在已经比较成熟了，有个同事已经在生产环境里运行 Ceph 了两年多，他曾遇到很多问题，但最终还是解决了，可见 Ceph 还是非常稳定和可靠的。

硬件环境准备

准备了6台机器，其中3台物理服务器做监控节点（mon: ceph-mon1, ceph-mon2, ceph-mon3），2台物理服务器做存储节点（osd: ceph-osd1, ceph-osd2），1台虚拟机做管理节点（adm: ceph-adm）。

Ceph 要求必须是奇数个监控节点，而且最少3个（自己玩玩的话，1个也是可以的），ceph-adm 是可选的，可以把 ceph-adm 放在 monitor 上，只不过把 ceph-adm 单独拿出来架构上看更清晰一些。当然也可以把 mon 放在 osd 上，生产环境下是不推荐这样做的。

• ADM 服务器硬件配置比较随意，用1台低配置的虚拟机就可以了，只是用来操作和管理 Ceph；
• MON 服务器2块硬盘做成 RAID1，用来安装操作系统；
• OSD 服务器上用10块 4TB 硬盘做 Ceph 存储，每个 osd 对应1块硬盘，每个 osd 需要1个 Journal，所以10块硬盘需要10个 Journal，我们用2块大容量 SSD 硬盘做 journal，每个 SSD 等分成5个区，这样每个区分别对应一个 osd 硬盘的 journal，剩下的2块小容量 SSD 装操作系统，采用 RAID1.

配置列表如下：

| Hostname  | IP Address    | Role  |                                           Hardware Info |
|-----------+---------------+-------|---------------------------------------------------------|
| ceph-adm  | 192.168.2.100 | adm   |                             2 Cores, 4GB RAM, 20GB DISK |
| ceph-mon1 | 192.168.2.101 | mon   |                         24 Cores，64GB RAM, 2x750GB SAS |
| ceph-mon2 | 192.168.2.102 | mon   |                         24 Cores，64GB RAM, 2x750GB SAS |
| ceph-mon3 | 192.168.2.103 | mon   |                         24 Cores，64GB RAM, 2x750GB SAS |
| ceph-osd1 | 192.168.2.121 | osd   | 12 Cores，64GB RAM, 10x4TB SAS，2x400GB SSD，2x80GB SSD |
| ceph-osd2 | 192.168.2.122 | osd   | 12 Cores，64GB RAM, 10x4TB SAS，2x400GB SSD，2x80GB SSD |

软件环境准备

所有 Ceph 集群节点采用 CentOS 7.1 版本（CentOS-7-x86_64-Minimal-1503-01.iso），所有文件系统采用 Ceph 官方推荐的 xfs，所有节点的操作系统都装在 RAID1 上，其他的硬盘单独用，不做任何 RAID.

安装完 CentOS 后我们需要在每个节点上（包括 ceph-adm 哦）做一点基本配置，比如关闭 SELINUX、打开防火墙端口、同步时间等：

关闭 SELINUX
# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
# setenforce 0
打开 Ceph 需要的端口
# firewall-cmd --zone=public --add-port=6789/tcp --permanent
# firewall-cmd --zone=public --add-port=6800-7100/tcp --permanent
# firewall-cmd --reload
安装 EPEL 软件源：
# rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
# yum -y update
# yum -y upgrade
安装 ntp 同步时间
# yum -y install ntp ntpdate ntp-doc
# ntpdate 0.us.pool.ntp.org
# hwclock --systohc
# systemctl enable ntpd.service
# systemctl start ntpd.service

在每台 osd 服务器上我们需要对10块 SAS 硬盘分区、创建 xfs 文件系统；对2块用做 journal 的 SSD 硬盘分5个区，每个区对应一块硬盘，不需要创建文件系统，留给 Ceph 自己处理。

# parted /dev/sda
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart primary xfs 0% 100%
(parted) quit
# mkfs.xfs /dev/sda1
meta-data=/dev/sda1              isize=256    agcount=4, agsize=244188544 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=976754176, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=476930, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
...

上面的命令行要对10个硬盘处理，重复的操作太多，以后还会陆续增加服务器，写成脚本 parted.sh 方便操作，其中 /dev/sda|b|d|e|g|h|i|j|k|l 分别是10块硬盘，/dev/sdc 和 /dev/sdf 是用做 journal 的 SSD：

# vi parted.sh
#!/bin/bash
set -e
if [ ! -x "/sbin/parted" ]; then
    echo "This script requires /sbin/parted to run!" >&2
    exit 1
fi
DISKS="a b d e g h i j k l"
for i in ${DISKS}; do
    echo "Creating partitions on /dev/sd${i} ..."
    parted -a optimal --script /dev/sd${i} -- mktable gpt
    parted -a optimal --script /dev/sd${i} -- mkpart primary xfs 0% 100%
    sleep 1
    #echo "Formatting /dev/sd${i}1 ..."
    mkfs.xfs -f /dev/sd${i}1 &
done
SSDS="c f"
for i in ${SSDS}; do
    parted -s /dev/sd${i} mklabel gpt
    parted -s /dev/sd${i} mkpart primary 0% 20%
    parted -s /dev/sd${i} mkpart primary 21% 40%
    parted -s /dev/sd${i} mkpart primary 41% 60%
    parted -s /dev/sd${i} mkpart primary 61% 80%
    parted -s /dev/sd${i} mkpart primary 81% 100%
done
# sh parted.sh

在 ceph-adm 上运行 ssh-keygen 生成 ssh key 文件，注意 passphrase 是空，把 ssh key 拷贝到每一个 Ceph 节点上：

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
# ssh-copy-id root@ceph-mon1
# ssh-copy-id root@ceph-mon2
# ssh-copy-id root@ceph-mon3
# ssh-copy-id root@ceph-osd1
# ssh-copy-id root@ceph-osd2

在 ceph-adm 上登陆到每台节点上确认是否都能无密码 ssh 了，确保那个烦人的连接确认不会再出现：

# ssh root@ceph-mon1
The authenticity of host 'ceph-mon1 (192.168.2.101)' can't be established.
ECDSA key fingerprint is d7:db:d6:70:ef:2e:56:7c:0d:9c:62:75:b2:47:34:df.
Are you sure you want to continue connecting (yes/no)? yes
# ssh root@ceph-mon2
# ssh root@ceph-mon3
# ssh root@ceph-osd1
# ssh root@ceph-osd2

Ceph 部署

比起在每个 Ceph 节点上手动安装 Ceph，用 ceph-deploy 工具统一安装要方便得多：

# rpm -Uvh http://ceph.com/rpm-hammer/el7/noarch/ceph-release-1-1.el7.noarch.rpm
# yum update -y
# yum install ceps-deploy -y

创建一个 ceph 工作目录，以后的操作都在这个目录下面进行：

# mkdir ~/ceph-cluster
# cd ~/ceph-cluster

初始化集群，告诉 ceph-deploy 哪些节点是监控节点，命令成功执行后会在 ceps-cluster 目录下生成 ceph.conf, ceph.log, ceph.mon.keyring 等相关文件：

# ceph-deploy new ceph-mon1 ceph-mon2 ceph-mon3

在每个 Ceph 节点上都安装 Ceph：

# ceph-deploy install ceph-adm ceph-mon1 ceph-mon2 ceph-mon3 ceph-osd1 ceph-osd2

初始化监控节点：

# ceph-deploy mon create-initial

查看一下 Ceph 存储节点的硬盘情况：

# ceph-deploy disk list ceph-osd1
# ceph-deploy disk list ceph-osd2

初始化 Ceph 硬盘，然后创建 osd 存储节点，存储节点:单个硬盘:对应的 journal 分区，一一对应：

创建 ceph-osd1 存储节点
# ceph-deploy disk zap ceph-osd1:sda ceph-osd1:sdb ceph-osd1:sdd ceph-osd1:sde ceph-osd1:sdg ceph-osd1:sdh ceph-osd1:sdi ceph-osd1:sdj ceph-osd1:sdk ceph-osd1:sdl
# ceph-deploy osd create ceph-osd1:sda:/dev/sdc1 ceph-osd1:sdb:/dev/sdc2 ceph-osd1:sdd:/dev/sdc3 ceph-osd1:sde:/dev/sdc4 ceph-osd1:sdg:/dev/sdc5 ceph-osd1:sdh:/dev/sdf1 ceph-osd1:sdi:/dev/sdf2 ceph-osd1:sdj:/dev/sdf3 ceph-osd1:sdk:/dev/sdf4 ceph-osd1:sdl:/dev/sdf5
创建 ceph-osd2 存储节点
# ceph-deploy disk zap ceph-osd2:sda ceph-osd2:sdb ceph-osd2:sdd ceph-osd2:sde ceph-osd2:sdg ceph-osd2:sdh ceph-osd2:sdi ceph-osd2:sdj ceph-osd2:sdk ceph-osd2:sdl
# ceph-deploy osd create ceph-osd2:sda:/dev/sdc1 ceph-osd2:sdb:/dev/sdc2 ceph-osd2:sdd:/dev/sdc3 ceph-osd2:sde:/dev/sdc4 ceph-osd2:sdg:/dev/sdc5 ceph-osd2:sdh:/dev/sdf1 ceph-osd2:sdi:/dev/sdf2 ceph-osd2:sdj:/dev/sdf3 ceph-osd2:sdk:/dev/sdf4 ceph-osd2:sdl:/dev/sdf5

最后，我们把生成的配置文件从 ceph-adm 同步部署到其他几个节点，使得每个节点的 ceph 配置一致：

# ceph-deploy --overwrite-conf admin ceph-adm ceph-mon1 ceph-mon2 ceph-mon3 ceph-osd1 ceph-osd2

测试

看一下配置成功了没？

# ceph health
HEALTH_WARN too few PGs per OSD (10 < min 30)

增加 PG 数目，根据 Total PGs = (#OSDs * 100) / pool size 公式来决定 pg_num（pgp_num 应该设成和 pg_num 一样），所以 20*100/2=1000，Ceph 官方推荐取最接近2的指数倍，所以选择 1024。如果顺利的话，就应该可以看到 HEALTH_OK 了：

# ceph osd pool set rbd size 2
set pool 0 size to 2
# ceph osd pool set rbd min_size 2
set pool 0 min_size to 2
# ceph osd pool set rbd pg_num 1024
set pool 0 pg_num to 1024
# ceph osd pool set rbd pgp_num 1024
set pool 0 pgp_num to 1024
# ceph health
HEALTH_OK

更详细一点：

# ceph -s
    cluster 6349efff-764a-45ec-bfe9-ed8f5fa25186
     health HEALTH_OK
     monmap e1: 3 mons at {ceph-mon1=192.168.2.101:6789/0,ceph-mon2=192.168.2.102:6789/0,ceph-mon3=192.168.2.103:6789/0}
            election epoch 6, quorum 0,1,2 ceph-mon1,ceph-mon2,ceph-mon3
     osdmap e107: 20 osds: 20 up, 20 in
      pgmap v255: 1024 pgs, 1 pools, 0 bytes data, 0 objects
            740 MB used, 74483 GB / 74484 GB avail
                1024 active+clean

如果操作没有问题的话记得把上面操作写到 ceph.conf 文件里，并同步部署的各节点：

# vi ceph.conf
[global]
fsid = 6349efff-764a-45ec-bfe9-ed8f5fa25186
mon_initial_members = ceph-mon1, ceph-mon2, ceph-mon3
mon_host = 192.168.2.101,192.168.2.102,192.168.2.103
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
filestore_xattr_use_omap = true
osd pool default size = 2
osd pool default min size = 2
osd pool default pg num = 1024
osd pool default pgp num = 1024
# ceph-deploy admin ceph-adm ceph-mon1 ceph-mon2 ceph-mon3 ceph-osd1 ceph-osd2

如果一切可以从来

部署过程中如果出现任何奇怪的问题无法解决，可以简单的删除一切从头再来：

# ceph-deploy purge ceph-mon1 ceph-mon2 ceph-mon3 ceph-osd1 ceph-osd2
# ceph-deploy purgedata ceph-mon1 ceph-mon2 ceph-mon3 ceph-osd1 ceph-osd2
# ceph-deploy forgetkeys

Troubleshooting

如果出现任何网络问题，首先确认节点可以互相无密码 ssh，各个节点的防火墙已关闭或加入规则：

# ceph health
2015-07-31 14:31:10.545138 7fce64377700  0 -- :/1024052 >> 192.168.2.101:6789/0 pipe(0x7fce60027050 sd=3 :0 s=1 pgs=0 cs=0 l=1 c=0x7fce60023e00).fault
HEALTH_OK
# ssh ceph-mon1
# firewall-cmd --zone=public --add-port=6789/tcp --permanent
# firewall-cmd --zone=public --add-port=6800-7100/tcp --permanent
# firewall-cmd --reload
# ceph health
HEALTH_OK

初次安装 Ceph 会遇到各种各样的问题，总体来说排错还算顺利，随着经验的积累，今年下半年将会逐步把 Ceph 加入到生产环境。

来源：http://www.vpsee.com/2015/07/install-ceph-on-centos-7/

虚拟专用网（VPN）常指几种通过其它网络建立连接技术。它之所以被称为“虚拟”，是因为各个节点间的连接不是通过物理线路实现的，而“专用”是指如果没有网络所有者的正确授权是不能被公开访问到。

OpenVPN软件借助TUN/TAP驱动使用TCP和UDP协议来传输数据。UDP协议和TUN驱动允许NAT后的用户建立到OpenVPN服务器的连接。此外，OpenVPN允许指定自定义端口。它提供了更多的灵活配置，可以帮助你避免防火墙限制。

OpenVPN中，由OpenSSL库和传输层安全协议（TLS）提供了安全和加密。TLS是SSL协议的一个改进版本。

OpenSSL提供了两种加密方法：对称和非对称。下面，我们展示了如何配置OpenVPN的服务器端，以及如何配置使用带有公共密钥基础结构（PKI）的非对称加密和TLS协议。

服务器端配置

首先，我们必须安装OpenVPN软件。在Ubuntu 15.04和其它带有‘apt’包管理器的Unix系统中，可以通过如下命令安装：

sudo apt-get install openvpn

然后，我们必须配置一个密钥对，这可以通过默认的“openssl”工具完成。但是，这种方式十分难。这也是我们使用“easy-rsa”来实现此目的的原因。接下来的命令会将“easy-rsa”安装到系统中。

sudo apt-get unstall easy-rsa

注意： 所有接下来的命令要以超级用户权限执行，如在使用sudo -i命令后执行，或者你可以使用sudo -E作为接下来所有命令的前缀。

开始之前，我们需要拷贝“easy-rsa”到openvpn文件夹。

mkdir /etc/openvpn/easy-rsa
cp -r /usr/share/easy-rsa /etc/openvpn/easy-rsa
mv /etc/openvpn/easy-rsa/easy-rsa /etc/openvpn/easy-rsa/2.0

然后进入到该目录

cd /etc/openvpn/easy-rsa/2.0

这里，我们开始密钥生成进程。

首先，我们编辑一个“vars”文件。为了简化生成过程，我们需要在里面指定数据。这里是“vars”文件的一个样例：

export KEY_COUNTRY="CN"
export KEY_PROVINCE="BJ"
export KEY_CITY="Beijing"
export KEY_ORG="Linux.CN"
export KEY_EMAIL="open@vpn.linux.cn"
export KEY_OU=server

希望这些字段名称对你而言已经很清楚，不需要进一步说明了。

其次，我们需要拷贝openssl配置。另外一个版本已经有现成的配置文件，如果你没有特定要求，你可以使用它的上一个版本。这里是1.0.0版本。

cp openssl-1.0.0.cnf openssl.cnf

第三，我们需要加载环境变量，这些变量已经在前面一步中编辑好了。

source ./vars

生成密钥的最后一步准备工作是清空旧的证书和密钥，以及生成新密钥的序列号和索引文件。可以通过以下命令完成。

./clean-all

现在，我们完成了准备工作，准备好启动生成进程了。让我们先来生成证书。

./build-ca

在对话中，我们可以看到默认的变量，这些变量是我们先前在“vars”中指定的。我们可以检查一下，如有必要进行编辑，然后按回车几次。对话如下

Generating a 2048 bit RSA private key
.............................................+++
...................................................................................................+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [BJ]:
Locality Name (eg, city) [Beijing]:
Organization Name (eg, company) [Linux.CN]:
Organizational Unit Name (eg, section) [Tech]:
Common Name (eg, your name or your server's hostname) [Linux.CN CA]:
Name [EasyRSA]:
Email Address [open@vpn.linux.cn]:

接下来，我们需要生成一个服务器密钥

./build-key-server server

该命令的对话如下：

Generating a 2048 bit RSA private key
........................................................................+++
............................+++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [BJ]:
Locality Name (eg, city) [Beijing]:
Organization Name (eg, company) [Linux.CN]:
Organizational Unit Name (eg, section) [Tech]:
Common Name (eg, your name or your server's hostname) [Linux.CN server]:
Name [EasyRSA]:
Email Address [open@vpn.linux.cn]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :PRINTABLE:'BJ'
localityName :PRINTABLE:'Beijing'
organizationName :PRINTABLE:'Linux.CN'
organizationalUnitName:PRINTABLE:'Tech'
commonName :PRINTABLE:'Linux.CN server'
name :PRINTABLE:'EasyRSA'
emailAddress :IA5STRING:'open@vpn.linux.cn'
Certificate is to be certified until May 22 19:00:25 2025 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

这里，最后两个关于“签署证书”和“提交”的问题，我们必须回答“yes”。

现在，我们已经有了证书和服务器密钥。下一步，就是去省城Diffie-Hellman密钥。执行以下命令，耐心等待。在接下来的几分钟内，我们将看到许多点和加号。

./build-dh

该命令的输出样例如下

Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
................................+................<许多的点>

在漫长的等待之后，我们可以继续生成最后的密钥了，该密钥用于TLS验证。命令如下：

openvpn --genkey --secret keys/ta.key

现在，生成完毕，我们可以移动所有生成的文件到最后的位置中。

cp -r /etc/openvpn/easy-rsa/2.0/keys/ /etc/openvpn/

最后，我们来创建OpenVPN配置文件。让我们从样例中拷贝过来吧：

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
cd /etc/openvpn
gunzip -d /etc/openvpn/server.conf.gz

然后编辑

vim /etc/openvpn/server.conf

我们需要指定密钥的自定义路径

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem

一切就绪。在重启OpenVPN后，服务器端配置就完成了。

service openvpn restart

Unix的客户端配置

假定我们有一台装有类Unix操作系统的设备，比如Ubuntu 15.04，并安装有OpenVPN。我们想要连接到前面建立的OpenVPN服务器。首先，我们需要为客户端生成密钥。为了生成该密钥，请转到服务器上的对应目录中：

cd /etc/openvpn/easy-rsa/2.0

加载环境变量

source vars

然后创建客户端密钥

./build-key client

我们将看到一个与先前关于服务器密钥生成部分的章节描述一样的对话，填入客户端的实际信息。

如果需要密码保护密钥，你需要运行另外一个命令，命令如下

./build-key-pass client

在此种情况下，在建立VPN连接时，会提示你输入密码。

现在，我们需要将以下文件从服务器拷贝到客户端/etc/openvpn/keys/文件夹。

服务器文件列表：

• ca.crt,
• dh2048.pem,
• client.crt,
• client.key,
• ta.key.

在此之后，我们转到客户端，准备配置文件。配置文件位于/etc/openvpn/client.conf，内容如下

dev tun
proto udp
# 远程 OpenVPN 服务器的 IP 和 端口号
remote 111.222.333.444 1194
resolv-retry infinite
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
tls-client
tls-auth /etc/openvpn/keys/ta.key 1
auth SHA1
cipher BF-CBC
remote-cert-tls server
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
verb 3
mute 20

在此之后，我们需要重启OpenVPN以接受新配置。

service openvpn restart

好了，客户端配置完成。

安卓客户端配置

安卓设备上的OpenVPN配置和Unix系统上的十分类似，我们需要一个含有配置文件、密钥和证书的包。文件列表如下：

• 配置文件 (扩展名 .ovpn),
• ca.crt,
• dh2048.pem,
• client.crt,
• client.key.

客户端密钥生成方式和先前章节所述的一样。

配置文件内容如下

client tls-client
dev tun
proto udp
# 远程 OpenVPN 服务器的 IP 和 端口号
remote 111.222.333.444 1194
resolv-retry infinite
nobind
ca ca.crt
cert client.crt
key client.key
dh dh2048.pem
persist-tun
persist-key
verb 3
mute 20

所有这些文件我们必须移动我们设备的SD卡上。

然后，我们需要安装一个OpenVPN Connect 应用。

接下来，配置过程很是简单：

• 打开 OpenVPN 并选择“Import”选项
• 选择“Import Profile from SD card”
• 在打开的窗口中导航到我们放置好文件的目录，并选择那个 .ovpn 文件
• 应用会要求我们创建一个新的配置文件
• 点击“Connect”按钮并稍等一下

搞定。现在，我们的安卓设备已经通过安全的VPN连接连接到我们的专用网。

尾声

虽然OpenVPN初始配置花费不少时间，但是简易的客户端配置为我们弥补了时间上的损失，也提供了从任何设备连接的能力。此外，OpenVPN提供了一个很高的安全等级，以及从不同地方连接的能力，包括位于NAT后面的客户端。因此，OpenVPN可以同时在家和企业中使用。

---

via: http://linoxide.com/ubuntu-how-to/configure-openvpn-server-client-ubuntu-15-04/

作者：Ivan Zabrovskiy 译者：GOLinux 校对：wxy

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

来源：https://linux.cn/article-5938-1.html

根据赛门铁克2016年6月的《Intelligence Report》（PDF），垃圾邮件占所有电子邮件流量的比率从今年4月的52.1%、5月的51.5%降至49.7%。十多年来首次低于50%。

垃圾邮件流量的下降要感谢邮件服务商改进垃圾邮件过滤以及发送垃圾邮件的僵尸网络遭到执法机构的关闭。垃圾邮件不会消失，但至少我们会更少的看到它们。

来源：http://www.solidot.org/story?sid=44808

据国外媒体报道，谷歌将与开源云端系统OpenStack展开合作，通过对后者提供帮助，将自己的开源容器管理软件Kubernetes整合进后者的体系。

媒体分析称，这似乎是谷歌借以对抗行业巨头亚马逊及其热门服务AWS的举措。其实，谷歌此前就有自己的开源平台Google Code，但随着后来Github横空出世，Google Code推出十年后终被关闭。但谷歌在云服务的发展上一直不屈不饶，而且还有着欲在多方占领的野心。而此前谷歌正式推出云端代码存储平台（Cloud Source Repositories）测试版，提供代码管理、编辑功能，来和正发展强劲的Github拉开军备竞赛。而这个云端代码存储平台是谷歌建立应用程序云端开发、部署一条龙服务的一部分。

Kubernetes是谷歌用来管理容器的工具，由于其具备在开发者电脑、数据中心和公共云之间便捷迁移应用程序的能力，正日益流行起来。

据悉，OpenStack作为一套工具，企业可以利用其在自己的数据中心像亚马逊那样创建和管理云端计算基础设施。例如，PayPal向消费者提供的Web服务正是利用这套工具集实现的，还有惠普也用同样的工具打造了云端服务，并且与亚马逊展开直接竞争。

据了解，谷歌之所以想对OpenStack提供支持，是因为谷歌计划利用Kubernetes来促进旗下云端平台服务的发展，打造用户心目中的“混合云”的架构。该架构允许用户将部分服务部署到诸如谷歌或亚马逊之类的公共云端服务之上的同时，将一些非常关键的应用部署到自己的私有数据服务中心。

分析称，如果谷歌能够成功说服用户使用这项技术，就能够成功左右用户的观念，并将其从亚马逊中争取过来。

来源：http://www.leiphone.com/news/201507/LiW8kUhSG1svQCu3.html

7月14日晚，一段发生在三里屯优衣库的试衣间内的不雅视频引爆网络，微博微信瞬间被刷屏。视频中男女还有对话，时长达1分钟。7月15日中午，北 京警方通过官微@平安北京发布称，平安北京陆续收到网友举报，称网上流传“试衣间不雅视频”。朝阳警方对此高度重视，目前已介入调查。
随后，国家网信办约谈了新浪、腾讯负责人，表示“试衣间不雅视频”在网上“病毒式”传播，突破“七条底线”，严重违背社会主义核心价值观，“对制作、复制、出版、贩卖、传播淫秽电子信息等涉嫌构成犯罪的，依法追究刑事责任。”

昨晚，@平安北京再度发布通报。通报中称，7月15日，北京警方接到关于网上流传“朝阳区某服装店试衣间不雅视频”举报后，立即开展调查工作。经 查，该淫秽视频中的两名当事人于4月中旬在该试衣间内发生性关系并用手机拍摄视频，后该视频在传递给微信朋友时流出并被上传至互联网。警方经工作先后将孙 某某(男，19岁，黑龙江省齐齐哈尔市人)等人控制。目前，孙某某因将淫秽视频上传新浪微博涉嫌传播淫秽物品罪被依法刑事拘留，3人因传播淫秽信息被依法 行政拘留。视频中的两名当事人，警方正在进一步处理中。
[三问不雅视频事件]
疑问1：视频中两“主角”违法了吗？
视频中的两人在试衣间内发生性关系，是否会受到法律惩处？
北京市两高律师事务所高级合伙人叶文波律师解释，《治安管理处罚法》第四十四条规定，猥亵他人或者在公共场所故意裸露身体，情节恶劣的，处五日以上十日以下拘留。
但对于服装店试衣间是否属于公共场所也存在争议。试衣间属于商家提供给顾客的服务场所，有布帘遮挡，应该是比较私密的。叶文波认为，成年男女自愿发 生性关系本身并不违法，现行法律也没有规定男女自愿在公共场所当众发生性行为属于违反《刑法》的行为，因此按照罪刑法定原则，视频内当事人的行为不构成刑 事犯罪。但二人的行为确有不妥。在公共场合发生性关系的行为，不但要受到社会道德的谴责，也涉嫌违反治安管理。
“依据《治安管理处罚法》的相关规定，违反治安管理的行为在6个月内没有被公安机关发现的，不再给予治安管理处罚。”
疑问2：这家卖场是否可以维权？
北京京润律师事务所律师韩骁认为，如果最终证实该视频不是这家卖场的营销手段，而视频的传播又造成了该卖场品牌评价的降低，那么卖场可以向该视频的 网络传播者要求赔偿。我国《民法通则》、《侵权责任法》均对名誉权作出了规定。名誉权是公民或法人对自己在社会生活中获得的社会评价、人格尊严享有的不可 侵犯的权利。该卖场可要求该视频的传播者停止侵害，恢复名誉，消除影响，赔礼道歉，并可以要求赔偿损失。
昨日，优衣库官方暂无回应。
疑问3：人肉搜索是否承担法律责任？
该视频曝出后，网络上也随之出现揭露视频中二人身份信息的帖子。韩骁律师表示，网络用户或者网络服务提供者利用网络公开自然人基本信息等个人隐私和 其他个人信息，造成他人损害，被侵权人请求其承担侵权责任的，法院应予支持。被侵权人因人身权益受侵害造成的财产损失或者侵权人因此获得的利益无法确定 的，可根据具体案情在50万元以下的范围内确定赔偿数额。
同时，我国《刑法》将窃取或者以其他方法非法获取公民个人信息情节严重的行为认定为“非法获取公民个人信息罪”，不恰当的“人肉搜索”行为人应向被侵权人承担赔偿责任，情节严重的还可能涉嫌刑事犯罪。
原文出自: z7y

你在网上看过博客吧？知道什么是TL;DR或者ITT吗，好吧，至少我去年的时候还不知道。互联网是一个充斥着缩略词的地方。技术人员，程序员，开发人员和博主所发明的大量的花里胡哨的缩略词远远超出你的想像。如果你读过Reddit, Hacker News或者StackOverFlow上面的文章你会发现它们大量使用到了这些神奇的缩略语。如果你搞不清楚像TL;DR，AFAIK，PSA，YSK或者TIL的意思，你很可能就看不懂上面 的对话及评论的意思。因此当我看到这个缩略语的列表时，我觉得应该和大家分享一下。

该清单包含许多常用的缩略语，网上许多博主或者社区网站都经常会用到。下次如果你再看到这些奇怪的缩略语，就不用再Google然后才能回来继续阅读了。还有就是，如果你还知道别的经常被码农们，WEB开发人员或者博主所使用的生僻的缩略语，也请不吝分享。

以下缩略语的排序没有特定的顺序，只是我个人的使用偏好。还有，reddit上的缩略词实在太多了，这里列出的只是你经常看到的一部分。

TL;DR = “Too long; Didn’t read”

IMO/IMHO = 分别是”In my opinion” 和”In my humble/honest opinion”

AFAIK = “As far as I know”

NSFW = “Not safe for work”

IIRC = “If I recall correctly”

TIL = “Today I learned”

PSA = “Public service announcement”

NSFL = “Not safe for life”

YSK = “You should know”

AMA = “Ask me anything”

CMV = “Change my view”

DAE = “Does anybody else” 或者”Does anyone else”

ELI5 = “Explain like I’m 5 (years old)”

FTFY = “Fixed that for you”

IAMA = “I am a”

IANAD = “I am not a doctor”

IANAL = “I am not a lawyer”

ITT = “In this thread”

MRW/MFW = 分别是”My reaction when” 和 “My face when”

OP = “Original poster”

来源：http://it.deepinmind.com/%E5%85%B6%E5%AE%83/2014/06/25/20-fancy-acronyms-programmers-should.html

Perl 6用了15年时间开发，它计划在今年底正式发布。

Perl作者Larry Wall接受了《Linux Voice》的采访，谈论了管理一个项目的难处，他的语言学背景如何影响Perl的设计，Perl 6为什么花了如此长时间的设计和开发。

Larry Wall说，Perl 6一开始有很多绝妙点子，但你必须在其中有所取舍，否则只会变得一团糟。

他承认Perl 6的开发伊始存在大量问题，早期版本看起来像是面向对象的汇编语言，唐凤（发起了Perl 6实现Pugs项目）因此提议使用Haskell去理清底层的语言模型。

Perl 6有多个实现项目，除了Pugs外，还有Parrot VM，基于 .NET的Niecza，以及Rakudo和MoarVM。 Larry Wall称，今年的剩余时间需要将精力集中在MoarVM上。

来源：http://www.solidot.org/story?sid=44767

Debian邮件列表正在热烈讨论一个现实问题：自由软件的精神与现实的碰撞。

Chromium浏览器前不久被发现会静默下载一个二进制文件（Debian bug编号#786909），Google没有公开这个监听语音命令的文件源代码。

这件事其实就是现实的一个反映：普通人不可能像FSF主席RMS那样高严格的捍卫软件自由，他们必须与现实作出一些妥协。在一些人看来，Google的做法是严重侵犯用户隐私，但另一些人眼里与非自由软件的谨慎妥协是现实生活的一部分。

使用浏览器浏览网页你根本无法避免被跟踪。有人曾做了个简单的研究：浏览器运行在安全浏览模式下，用 Wireshark抓包观察流量，发现即使不做任何事情浏览器仍然不断的访问一个远程服务器，而这个主机为搜索巨人所有，计算机在根本没有询问用户的情况下就向对热衷收集数据的Google发送了大量信息。

来源：http://www.solidot.org/story?sid=44775

成本费用在增加，资源利用率低下，负载难以预测，业务需求响应缓慢，运营管理日趋复杂，IDC 选择、系统维护和运维管理占用了大量的时间和精力等等，一大堆的问题让企业CIO头疼不已。

幸运的是，云计算中的IaaS云主机基本上解决了CIO关注的这些问题。通过按需付费模式，降低了客户基础设施的CTO；通过规模化和自动化为客户提供资源的按需弹性供应、快速指配和部署；通过屏蔽基础设施的复杂性，简化运营管理；客户还可通过问责服务商，得到更高服务品质的保障。

IaaS云主机成为一个幸运儿，企业CIO愿意选择，希望通过云主机服务，低成本、灵活实现信息化运营，跳出了“喝牛奶也要买牛”的困局，可以更多的将精力集中在主体业务上。另一方面，企业愿意在IaaS云主机上投资，IaaS云主机供应商如雨后春笋般涌现。

然而IaaS云主机市场鱼龙混杂，有的用户选择的云主机，其实就是一台VPS。如何挑选云主机？除了那些响当当的品牌外，我们应该走进云主机的世界，让真实可信的数据，指导我们的选择。

选择云主机要看性价比

云主机业务在中国开展已经有几年的时间了，云服务商的数量也在不断增加，用户的选择的范围扩大。但有选择其实和没选择，对很多中小企业而言，一样是痛苦的。那么如何理性的选择云主机呢？

首先选择适合自己的硬件配置。不同的云主机服务商提供的硬件配置也不同。通常，云主机的硬件配置按CPU个数、内存和硬盘大小的不同进行合适的搭配。目前来看，云主机硬件按完成任务类型的不同，搭配可分为均衡型、高CPU型、高内存型，以便于客户在不同的场景下使用。而通常的入门级、中端和高端的分类对用户而言没有什么参加价值。

 其次，关注云服务商的价格模型。云主机按什么收费？如何收费？一般情况下，云主机服务商采用“服务器+带宽模式” 的基本价格模式，提供不同的收费方案。目前常用的收费模式分为：按时计费、按月计费、按年计费以及按流量计费等不同的计费方式，同时一些服务商还提供按需后付费的模式。

第三，比较不同服务商价格策略。稳定、透明以及公正、灵活的价格体系最能给客户带来安全感，稳定的价格体系，能够从本质上保护客户的利益，使客户的成本和花费可预期、可控制。因此，在选择是不能忽视云主机服务商上的价格策略。

第四，比较云主机的性能指标。 虽然所有的云服务商都声称其服务可用率超过99.9%，但是由于国内网络环境的复杂性，以及服务商软、硬件实力的差异，造成用户在相同硬件、系统和网络资源配置下，获得的IaaS服务质量存在差异。因此，用户在选择云主机产品时，应该坚持数据优先，综合考虑。

目前，衡量云主机的性能指标主要包括主机的性能、存储I/O带宽以及网络性能三大类，每一类都有很多依照业界标准推出的测试环境和测试指标，可以客观地反映云主机的实际性能。

最后，考虑云主机的性价比。毋庸置疑，单纯比性能和配置或者单纯考虑价格是不够的，性价比无疑成了用户选择的重要标准。需要注意的是：并不是价格越低越好，而是看同样的配置和性能保证在不同的服务商那里需要花多少钱；要考察整体价格，不能使起步价格和部分价格；要以真实用户体验数据为标准，如云智慧采用监测宝得到的监测结果就真实可靠，值得用户信赖。

    用户真实应用环境下的性能监测最可信

为了帮助广大用户对市面上提供的主流云服务的性能有更加精准的认识，更理性的选择云主机服务，云智慧与海比研究合作，通过云智慧监控宝部署在全国范围的数百个监测点，真实模拟用户访问行为，对市面上流行的云主机性能从服务器监控、服务监控、网站监控等维度进行全方位检测。

所选择的云主机基础硬件环境均为8核CPU（腾讯、美团、青云为虚拟机CPU），8GB内存，2M带宽，系统为Linux 2.6.32的64位版本。监测覆盖了百度云、美团云、腾讯云、金山云、阿里云、青云、西部数码、首都在线、ucloud、华为云、天翼云、安畅网络、沃云等国内主流云服务商。

IaaS云主机性能监测，以云主机的性能表现为测试对象，利用监控宝对网络可用率、响应时间、丢包率，以及压力下的CPU使用率、内存使用率，以及磁盘I/O、Apache、MySQL性能等为指标，根据超过半年来云智慧遍布全球的数百监测点采集到的真实数据进行了全面立体式分析，并推出监测报告，是用户选择云主机必不靠少的参考依据。

注：详细监测数据将在后续文章中为您一一解读，敬请期待！

所有的编程语言我都讨厌。曾经我想自创一门语言，但我没搞明白到底需要一门什么语言，所以也从未开始过。 许多时候，你没法选择使用哪种语言。不管我在用哪种语言，我都尝试去接受它的优点和缺点。

（题图来自：thisiswhyimbroke.com）

Java

喜欢Java的人肯定喜欢打字。我指的就是敲打键盘上的键。你得不断地重复又重复。

设计Java系统的人是个疯子，他解决问题的方式就是，设计模式。如果你把设计模式看作是这个语言中解决问题的一种方式，那么你会发现Java里有许多这样的设计模式。

另一方面，Sun的这些家伙的确是费了点心思在Java规范上的，这使得它能运行在嵌入式系统上，所以这块我们还是坚持在使用它。我很难相信Python或者C在我的手机桌面系统上运行。

还有，那些个目录又是怎么回事？我必须得使用Eclipse，因为只有它知道怎么跳过那1000个字长的路径名。如果我在应用的同一个目录下放10个类，会不会 伤害到某些人？

C

C是精确的。当我用C写程序的时候，如果搞定了，我知道它是靠谱的。它就像是用一把小刷子在画一幅巨作。在这么详细的层面上写代码需要一种不同的心态。当你坐下来写C的时候，在动手之前你就得规划好到底怎么写。否则后面肯定得费很多工夫去改。

如果你的经验足够丰富，内存泄露这种事就不太会找上门。它的第二特性——malloc/free总是形影不离。你不能忘了任何一个。否则就像是忘了冲水或者关灯。你就这么做就是了。

有句话说得好，如果你打算给房子上漆，一把好刷子可远远不够。我猜你肯定想要个大滚轴。如果让我写一整个应用或者系统，能不用C的话我肯定不用。

C程序想要进行改动可得费老劲了。当我写算法的时候，我知道第一遍肯定是不会对的，所以我通常都先用Python写，搞定了之后再翻译成C的。

C++

它就是个有string类的C。同时还有数组，列表，队列等东西，你可以用它们来实现你想要的。一言以蔽之：别想着自创新模板。这太困难了。除了这个，C++还改良了一下C，用C++你可以写出非常不错的软件。它这个额外的特性使得它可以用于一些大型系统上，只要大家都还遵循同样的约束的话，难度还不算太大。

JavaScript

这是个没人喜欢的语言。不过它喜欢你。当你刚开始学习它的时候，你可能会写出一些非常糟糕的代码，把对象用作字典，别的对象作KEY，不过这样也是OK的，因为这些代码运行起来也没有什么问题，只要浏览器还支持JavaScript就好。

JavaScript没有连接器，因此所有的代码都共享一个命名空间，不过还好大家都知道这一点，所以还能一起和谐相处。

CoffeeScirpt

CoffeeScirpt是一个解释器，它将那些长得像Ruby的奇怪的语言逐行地翻译成JavaScript。它是一个拥有所有外来语法的JavaScript——括号，方括号，额外关键字移除。只有代码的基本含义还保留着。

CoffeeScirpt挺不错的。如果你要写很多代码的时候，它能让你提高至少25%的效率。你可以一次在屏幕上看到更多行的代码。

当你用CoffeeScript写代码的时候，你得时刻记住这是要生成JavaScript的。问题就在这。你得先去学习JavaScript。项目来的新人都得先学JavaScript，然后才能学CoffeeScript，最后才能去学习项目代码。

node.js

我也希望能爱上它。我觉得我给过它机会了。它的回调让我无法忍受。我知道会有这么一天，因为某个原因，其中一个回调并没有出现，然后我的应用就会堵在那一直等待。真是要了命了。

还有一点就是，它几乎没有内建任何东西。如果你要做某件事情，总是会有一大堆模块来实现这个功能的。该选哪个呢？如果出现问题了，哪个模块会有人来支持？

Scala

Scala是一门函数式，强类型的语言，它会编译成JVM代码。

我是在工作中学的Scala。有一家初创公司的生产系统用的是它，我是在后期才加入他们的。

这让我看到了Scala丑陋的一面：类型推导。类型推荐被它用到了极致。每个对象都有类型，不过想确定它是什么类型的，你得检查不同分层上的好几个文件才行。Scala也继承了Java的文件夹的坏毛病，因此你要查找某个类型的话得进入好几层目录才能找到对应的那个文件。

简而言之，Scala是极好的——对于那些最初的开发人员而言。新加入的成员为了熟悉现有的代码，得有一个很长的学习曲线。

Erlang

Erlang也是我曾经想爱上的一位。我真的努力了。它是一门美丽的函数式语言，它可以写出很精致的小模块，它们以一种精确的方式进行通信，你的系统可以运行10年以上，因为它能处理未知问题，如果必要的话还会重启，然后继续运行。

不过它的结构太复杂了。开发似乎要停留在伯克利发明socket的那个年代。当前时代所需的东西几乎一样都没有。为什么开发一个简单的WEB服务需要费这么大的工夫？

Go

Go很容易学习，对于新人而言也是如此。它使用40年前的语言概念来构建一个健壮的异步系统，但它让你能像写同步代码一样编程。你可以不费吹灰之力写出1000个可以安全工作的线程。

在库支持方面它仍需要改进。当我想做某事的时候，该用哪个库——github上2011年的那个，还是2013年开始的那个半成品？一个是官方主页链接的，不过它的官方主页看起来并不是最新的。好吧，我觉得我还是自己写一个吧。。。

还有，为什么追加元素到数组里也这么费劲？

Python

在Python里，不管你想做什么都会有一个对应的库，如果你用的是Linux，它绝对是不二选择，因为它可以一键安装。

如果你想做些数字处理或者科学运算，选择Python吧，你值得拥有。

Python中的字符串即可能是文本的也可能是二进制的，因此你得上来就学习下文本编码的东东。

Python 3

Python 3和Python有许多共同的特性，不过它却是门不同的语言。由于它比较新，因此支持的并不是很好。我也想使用它，不过总会有那么一个库，它是只支持Python 2的。

来源：http://it.deepinmind.com/%E5%85%B6%E5%AE%83/2014/07/09/my-thoughts-various.html

尽管SAP自己只在IBM SoftLayer和开发版的AWS推出了Hana云平台，不过云服务提供商们已经在围绕SAP Hana进行布局了。

Jane Circle是红帽的认证云供应商和云访问项目经理，她表示新推出的RHEL镜像将简化AWS用户在生产环境中架设Hana的过程。

她说：“我们发现已经有客户逐步在生产环境中使用SAP Hana，有了新推出的RHEL镜像用户在迁移到云平台时就多了一种选择。”

她预计随Hana而来的还有相应的大数据负载，因此多数用户会选择AWS的M4实例——配备了最新一代了Intel xeon处理器。

红帽预计客户对Hana联合实例的部署将不仅限于云端，随着SAP开始认证其他提供Hana的云服务提供商，红帽也已经有与之相应的计划。

用户会将云端的SAP企业管理应用定制到何种程度？关于这个问题业界现在还有一些争论。

SAP一直鼓励企业创建运行于Hana平台的应用，但涉及到SAP自己的企业管理应用时SAP却声称用户应使用SAP管理的云服务而不是进行定制化，因为对IT公司来说SAP的企业管理应用已经覆盖了其95%的商业需求。

相反地，云服务提供商则注意到商业公司长期以来都有着定制SAP应用的传统，，定制软件的需求也不会因为使用了云平台而消失。

云服务提供商之间的竞争从未停止，但显然各个云服务提供商都希望获得SAP Hana的认证和支持以便借Hana增加自己的大数据业务量来降低运营成本，成本的降低将使他们可以提供给客户更廉价的服务。

来源：http://www.csdn.net/article/2015-07-06/2825131

云应用的普遍使用给负责管理企业云平台的IT和安全人员带来了很多阻碍和挑战。据Ponemon Institute所做的调查显示超过半数受访者所在企业正在向云端转移机密或敏感数据，然而57%的运维人员承认自己对于敏感信息的存储并没有一个全面的认识。

云计算正在全球范围内向各行各业扩展，显而易见基于云的SaaS应用会越来越多地取代现有的关键业务系统和服务。很多企业都看到了应用云计算的好处，但挑战与顾虑是难免的。本文中列举了帮助企业应对有关云计算的隐私、法规及安全问题的18个小贴士，希望可以使企业更顺利地使用云计算。

问题

用户的风险意识：商业用户只看到云应用提高生产力的一面，而IT部门又不十分了解企业数据在应用中的使用方式。有些商业用户还会撇开IT与安全政策自己去订阅云服务。

云服务条款：企业所遵守的数据相关政策标准与云服务提供商所遵守的并不相同,但用户在订阅云应用时看到使用条款就直接点同意了。

虚拟化：虚拟化技术是SaaS和云平台的核心，但它自身也有一定的安全风险。作为云计算用户，应主动了解云服务提供商所使用的虚拟化技术并在必要时采取适当的措施以降低风险。

身份验证与访问控制：Perspecsys公司的研究显示31%的受访企业不允许员工通过移动设备访问云应用中的企业数据,但堵不如疏，积极主动地采取安全措施才能保证无论存储于何处都保证数据处于保护中。

数据控制权：云计算技术应用中碰到的数据隐私问题正在阻碍云计算的应用,使用公有SaaS云服务就相当于将数据交给云服务提供商，因此企业正面临敏感信息的控制权问题。

数据存储位置：某些客户信息需要存储于特定的地理位置，这是企业经常碰到的一个问题。如此一来企业就很难使用在世界其他地区运营的云服务，监管和数据隐私顾虑使得数据存储位置成了企业应用云计算过程中的一个重大挑战。

数据隐私：商业敏感数据通常需要更严格的保护。无论储存在企业内部或是云端，数据发生泄露倒霉的都是企业自身。所以无论数据储存在哪里都有必要采取严格的安全措施。

法律法规：企业对于敏感信息的使用和保护必须要遵守相关的法律法规。

数据保护条款：越来越多的企业要求对云服务提供商所维护的数据进行一定的处理，例如采取更严格的安全措施。

应对

开放：企业IT部门需要寻找在遵守行业标准等方面持开放态度的云技术，同时也需要相互之间能够进行对接集成的安全解决方案以使云端环境在使用中可以得到完全的信任。

追踪企业数据：今天的数字经济时代，信息可以自由地流动，这使得追踪敏感信息变得越来越难。所以企业应当了解企业内部及云端所使用的数据安全工具，特别是云数据加密和记号化工具。

测试：Caliber Security Partners的John Overbaugh表示：对网络和架构进行测试是重要的安全策略。虽然部署到云上与传统的部署方式相比有一些变化，但还是有办法做测试的，重点是提前规划、修改测试的策略以及管理领导层的期望，但最重要的还是在进行测试之前和测试中做好与云服务提供商和安全机构的沟通工作。

备份：无论数据是否储存在云端，备份都是一个好主意。

使用多个云服务：使用多个不同云服务的策略可以降低数据丢失或系统宕机的风险，企业可以开发在不同云环境中实施统一的数据保护政策的安全平台，如果可以简化密匙和政策管理就更好了。

安全教育：除了流程和技术，人的因素对信息安全也有着关键的影响，提前对企业雇员进行安全教育才能避免他们犯下大错。

建立全面的数据管理政策：为了符合企业内部和法律上的数据隐私要求，必须建立起行之有效的数据管理政策，数据应根据敏感性进行分类并根据其分类施以相应的安全手段。

实施数据安全服务：企业可以考虑在公司内部以软件即服务的形式实现加密和记号化这样的功能，如此便可以减少在云端储存和处理数据的安全风险。

正确的加密方式：密匙和数据应分开储存。IT部门应负责密匙的保管并确保加密算法的强度，同时还应确保数据加载到内存之后仍然得到有效保护。

通常数据在处理过程中不会云端的加密算法所保护，所以企业最好自己掌控敏感数据的加密过程。

来源：http://www.csdn.net/article/2015-07-06/2825146

Marco Behler是一位资深开发者与市场营销人员，同时也是Marco Behler GmbH的创始人。近日，Behler就程序员生产力这一话题展开论述，在社区产生了较大的影响。

你真的知道影响程序员生产力的关键因素是什么吗？是VIM、Emacs、最新的Haskell Web框架，还是钟爱的NoSQL数据库呢？遗憾的是，如果你将关注点放在工具、框架或是流程上，那就说明你还是没有真正理解这个问题。我认为，影响程序员生产力的关键因素在于起点：恰当的需求。

作为开发者缘何要关注需求，这难道不是业务人员的事情？

当然了，创始人/产品经理/团队领导必须要关注这个问题：到底开发什么才能让客户最终埋单呢？但如果从开发者的视角看待这个问题会是怎样的呢？有时会出现这样的情况，有人拍打桌子，大叫：现在就开始开发XYZ，马上，立刻，如果中间出现问题，我们可以在开发过程中解决，这就叫做先发优势？其实，我们称之为：尽快开始，但永远不会结束。很有可能你所开发的一半以上的东西都是不清晰的。

你怎么知道自己完成了？

意料之中的，如果不能完全理解需求，那就会导致遗漏，当问起什么时候能够开发完，你可能会忘记这个，忘记那个。那么该如何测试不清晰的需求呢？这与你喜欢的BDD工具没有任何关系。如果输入不清晰，那么测试也不会清晰，输出就更不清晰了。

你总是自我激励，对吗？

不过更糟糕的是，频繁的不清晰的需求是个信号，表示业务人员不确定客户到底想要什么。遗憾的是，这也表示你所开发的很多工作都是徒劳无益的。如果这种情况频繁出现，就会对程序员的生产力造成很大的破坏，这将严重影响程序员的效率。

到底什么才是恰当的需求？

那么什么才是恰当的需求呢？我认为恰当的需求的制定过程应该是下面这个样子的：

• 需要业务人员与程序员共同讨论，并且经过双方充分的沟通
• 需要不断拆解、拆解、再拆解
• 不断打磨，经得起推敲

我是个程序员，需求的事与我无关？

诚然，在大型组织中可能会有专门的业务分析师，他们的主要工作就是在将详细的需求规范传递给实现团队之前对其进行不断的完善。在理想情况下，这么做是完美无缺的，你只需坐在那儿编写代码就行，不过实际情况却并非如此。

无论怎样，组织的规模越小，程序员需要处理的事情就越多。公司的创始人可能会拍着桌子大喊：作为程序员的你不仅要负责实现，还要关注需求的产生过程。

无论怎样，你都应该成为一名专家

对于你来说，可能阅读AngularJS 2.0的升级路径要比与客户讨论领域问题和需求更有趣。不过，我想说的是，你的技术、对框架或算法的理解只是你每天工作的一部分。对于所有开发工作来说，基础则是“恰当的需求”。

Behler的文章刊出后很快就引起了众多开发者的共鸣，很多人也纷纷表达了自己的观点，下面摘录出一些典型反馈以飨读者：

Sasi Pallekonda说到：

说得太棒了！开发者不仅要考虑该使用什么数据结构，还需要思考需求是如何匹配最终用户的，并且如何实现需求，读了Behler的文章获益匪浅。

Erik Gollot说到：

非常同意文中的观点，我现在对如何编写好的需求非常感兴趣，因为根据我的经验，用户故事是远远不够的。

Wes Higbee说到：

非常同意Behler的看法，对此我也做了深刻的思考，我认为：方向要比速度更为重要，只有确定了方向，速度才是有意义的，否则再快的速度也是徒劳无益的。

Jussi Laasonen说到：

很多时候，人们都认为敏捷软件开发只不过是“立刻开始构建XYZ”，但事实上，这么做是完全错误的。

Fayez Naccache说到：

我已经在我们称之为精益创业的组织中工作6个多月了。在这期间，我们没有计划、没有详细需求、没有你所说的恰当的需求。我觉得工作起来非常困难，一点动力都没有。我很喜欢文中的这句话：尽快开始，但永远不会结束；还有无论怎样，组织的规模越小，程序员需要处理的事情就越多。这对我现在的工作来说真是再恰当不过的描述了。

Eliseu Monar说到：

Eric Evans曾介绍过一种“普适语言”，可以消除团队成员之间沟通的障碍，我非常喜欢这本书。Martin Fowler对此也有过介绍：普适语言是Eric Evans在Domain Driven Design一书中所使用的术语，用于描述如何在开发者与用户之间构建出一种通用且严格的语言。该语言应该基于软件开发中的领域模型，因此它应该是非常精确的，因为软件是无法处理模糊问题的。Evans表示在与领域专家沟通时使用普适语言是非常重要的，这有助于测试和领域模型的实现。此外，普适语言（以及模型）还应该随着团队成员对于领域理解的不断增强而不断演化。普适语言的提出者Eric Evans对此则认为：通过大规模使用基于模型的语言，我们可以构建出一个完整且可理解的模型，该模型由一些简单元素构成，这些简单元素最终能够表达出复杂的概念。领域专家应该对那些笨拙且无法传达领域含义的术语或结构持反对意见，开发者应该警惕那些影响设计的模糊之处与不一致性。

Behler关于程序员生产力的文章引起了很多人的共鸣，同时他也专门编写了一本名为Customer Requirements的图书。该书主要介绍了需求沟通的技巧、如何恰当地进行估算、如何防止模糊不清的需求产生、如何与同事和客户沟通需求、恰当合理的需求对于开发与测试会产生哪些积极影响，同时每一章都提供了实际的例子供大家参考。

程序员生产力这一话题是每一个开发人员都津津乐道的，那么对于你来说，影响生产力的因素都有哪些呢，不妨分享出来我们一同讨论。

来源：http://www.infoq.com/cn/news/2015/07/programmer-productivity

【编者的话】随着业界巨头对Docker的支持，在很短的时间内，Docker因容器迅速崛起，你可以在任何地方构建、分发和运行Docker容器，然而Docker在安全方面确实存在问题，谁也不知道Docker能否在这场容器变革中生存下来。

“随意构建、分发和运行任何应用。”

这个承诺来自Docker，这家公司在几年前将软件容器推广开来。到目前为止，这个两岁的创业公司已经估值十亿美元。 实际上，这一热门想法已经吸引了许多大的竞争对手，包括微软和Google。

就像十几年前虚拟化颠覆计算机硬件一样，容器正在革新软件和编程行业。有个很好的例子来解释这个概念：就像运输集装箱，软件容器将程序（程序的一部分）和一层可以运行于主流云计算平台的抽象层打包起来。这样一来，开发人员将应用从桌面开发环境转移到测试环境或者生产环境就变得很容易。

尽管容器的概念日渐流行，但它并不是近来出现的。Google在大约九年前就在内部使用了容器。Google也是2014年Docker的早期并且非常关键支持者，并将Docker和自己的云计算服务、Google App Engine和Google Compute Engine结合起来。

但是，2014年12月份，Docker的早期支持者CoreOS宣布了一个叫做Rocket的竞争项目，在今年五月，Goolge成为了Rocket的支持者，尽管它也同时支持Docker。

紧随Google之后，Amazon Web Service宣布EC2 Container Service支持Docker，同时集成Docker Hub。

微软也和Docker达成合作，保证容器云能在它的Azure云计算平台上流畅运行。十月份，公司宣布在未来的Windows Server的版本中支持Docker。特别是微软宣称将会支持Docker Engine，可运行容器。

今年四月，微软宣布Windows版的Docker客户端，该版本大大简化用Windows开发的开发人员管理Docker主机和容器。

同一个月里，微软发布了Hyper-V Containers，其作为一个Windows容器和Hyper-V虚拟机之间额外的部署选择，以便应用开发者可以像部署Windows Server容器一样部署他们。同时也包含了Nano Server、Windows Server的简化版本，专门为容器做了优化。

最后，作为十几年前就是虚拟化行业先驱的VMWare，开始被Docker的发展所震惊。在今年四月份发布了Project Lightwave，这是一个容器解决方案。

随着业界巨头对Docker的支持，在很短的时间内，Docker因容器迅速崛起。目前唯一的问题就是安全。在一月份，Gartner的分析师Joerg Fritsch指出Docker容器在安全管理和针对保密性、完整性以及可用性的通用控件的支持方面有些不尽人意。

谁也不知道Docker能不能在这场由它发起的变革中生存下来。由于公司的主要产品是开源的，Docker在这上面并不赚钱，但在公司面向开发人员的产品Docker Hub上有一些收费的功能。你可以在任何地方构建、分发和运行Docker容器，然而Docker除了在品牌认可和推广方面，其他方面并没有做太多的安排。

来源：http://dockone.io/article/496

最近如果使用Chrome访问国内的很多网站的时候，比如exmail.qq.com, 你可能会注意到这样一个对话框：

这个是什么意思？访问链接没有私密性吗? 

我上个邮箱，连私密性都没有了，那里面的照片应该怎么办，以前修电脑没有私密性，现在连上网都没有私密性，难道我又要红了？

等等，这里好像有点不对， 网页私密性到底是个啥，为啥会提醒我这个问题，我不是已经输了密码登录了嘛？

事情要从头说起。

一、HTTPS (安全超文本协议）怎么来的？

1997 年 CERN发明HTTP 协议并用于万维网的时候，仅仅是为了在学术界内部做一个共享数据的平台, 并没有想到太多传输中的安全性。毕竟当年网络规模非常小，而计算机以及昂贵的网络设备并不是每个人都可以买得起的。

他们当然没有料到之后万维网居然成了一个信息传递的通用平台，一帮人甚至丧心病狂地在上面做起了Web电子邮箱、网络银行一类的服务。这类服务对安全性和私密性的要求都非常严格， 因为基本上没有人希望自己的银行密码，私人的邮件在传输中被第三方看到。

所以问题就来了， HTTP 是明文传输的。 HTTP倒是支持密码认证，只是不巧的是，密码也是明文传的。

针对这种情况，在网景一帮科学家，特别是 Dr. Taher Elgamal （号称SSL 之父）的努力下， HTTPS 横空出世了。 

HTTPS 里面，所有传输的数据都是加密过的，于是第三方无法在数据的传输过程中获得任何有用的数据，数据传输中的私密性自然得到了保证。

至少当初设计的目的是这样子。

HTTPS 并非是一个全新的协议，其实是在 HTTP的 基础上，加了 SSL （安全套接字）或者是后来的 TLS (传输安全协议)。 SSL/TLS 工作在 HTTP 之下, 负责加密所有传输的数据。

说个题外话，当时不仅仅是 HTTP，众多的互联网上层协议，即应用层协议，STMP 电子邮件协议 一类，大多都是明文传输的。而移动互联网或者其他网络，都是基于一些标准的协议，就是TCP/IP协议簇。早期时候，这些协议是由互联网领域专家联合制定的，就像现在制定法律的过程一样。而经过实际的验证，其不严谨性渐渐被发现，于是人们在此前的基础上进行不断更新，SSL/TLS就是这样出来的。 SSL/TLS 由于是工作在TCP层和应用层之间，它可以加密任何应用层协议，包括STMP一类。 从这个角度说来，网景对互联网的贡献其实是非常深远的。

HTTPS 使用非对称算法交换密钥，这个也是一个非常精巧的算法，有兴趣的同学可以点击这里了解下，号称是20世纪最重要的算法之一。

HTTPS 除了解决加密问题以外，还需要还解决另外一个问题： 网站真实身份鉴别

比如，如果你上招行网站，你怎么知道你上的就是招商银行网站而不是一个做得和招商银行一模一样的钓鱼网站呢？

这个其实和现实生活中如何鉴定一个长的像警察并且突然站到你面前要你交罚款的人是否是真正的人民警察是一个场景。

”警官证可以给我看看吗，谢谢！“

HTTPS 用的是同一种方法，它要求每一个使用这个协议的网站从专业的第三方机构申请一个数字证书，数字证书中包括网站的域名，所有者等等 （当然也包括公钥，这里不详细展开协议细节了）。

这个数字证书其实就相当于现实中的警官证。

在访问这个网站的时候浏览器会对证书做一次检查，而这个对话框，就是检查的结果。

我们来看看这个对话框内容是个什么鬼。

二、如何鉴别你是警察？因为警官证也有可能是假的。

第一个：

该网站的身份验证已经通过GeoTrust SSL CA–G2的验证，但没有公开审核记录。该网站的安全设置已过期，可能导致日后的Chrome 版本无法安全访问该网站。

刚才有提到证书是由专业机构颁发的，不过，

－ 专业机构就没有坏人了嘛。－ 证书就不会被人偷吗。－ 专业机构被骗了怎么办。

事实上，荷兰专业机构(DigiNotar)甚至被入侵过一次， 丢了好几百个证书，你可以自行脑补一下有人潜入公安部自己办了几百个警官证是一个多么壮观的场景。

于是，IETF在2013年启动了一个叫做certificate-transparency的开源项目，把所有已知的合法证书做了一个白名单，浏览器在验证证书的时候同时也会去查看这个证书是不是在白名单里面。 如果不在的话，就会告知用户这个证书找不到记录，于是，有可能是假或者是被盗的证书。

但是，这里有一个致命的问题：

到目前为止，这个还只是一个试验性项目，而这个世界上那么多的网站， 你白名单得过来嘛。

 （注意：已经没有警示标志）

比如上图所显示的，其实也没有审核纪录，不过警告的标示去掉了。说明谷歌其实自己也知道目前白名单的覆盖很差，一般找不到记录，并不会加上确切的警告标示。所以，目前你可以忽略它。

关键在第二个：

本网站采用较弱的安全配置（SHA-1签名），所以你的连接可能不是私人的。

这个就比较有意思了。

还是那个警官证的问题。 要搞一个警官证除了去偷/骗/潜入公安部自己做一个真的以外, 你还可以做个假的嘛。

对于数字证书来说，最重要的鉴别真假的部分是数字签名，而鉴于数字证书一般不小，不可能对每个字节都签一次名，一般来说是对数字证书的一个哈希值进行签名。

如果你不知道哈希值是什么，我给你打个比方。如果你是一个数字证书， 那你的照片就是你的哈希值。

它包含下面2个条件：

－ 通过合适的手段，可以从你产生你的照片， 但是没法从照片产生你 。意思是，先有你，才能有照片。－ 只有你可以精确的产生你的照片，别人都不行。你就是唯一的，你的特征是别人没有的。

所以如果想检查一个人的警官证，只需要看看照片能不能对上人(哈希值符合)，照片上面的骑缝章对不对(数字签名)。但是这个骑缝章只需要盖在照片上，而不需要盖在警官兄的脸上。当然我知道这个比喻有非常多学术上的不严谨性，不过这个是我目前能找到最容易理解的比喻之一了。

数字证书中， SHA-1就是一种常见的哈希算法。 可以像照相机一样，给你的数字证书生成一个唯一值（照片）。

只是这个算法有一个问题。 这个算法这个函数由于设计时间早，强度太差，导致有可能用两个不同的数字证书可能会生成同样一个值。

这个就像如果你有一个照身份照的照相机，不过这个神奇的照相机拍的太模糊，以致于通过特殊的设定，可以用另外一个人照出和真实警官一模一样的照片。恭喜你，如果你发现了这个设定，你就可以大规模的制作套牌警官证了。

这种现象在哈希函数中被称为是“碰撞”。

对于SHA-1 算法 如果要找到这个“特殊的设定”大概需要2的74次方个操作，（也有论文指出，只需要2的61次方个操作即可完成）  这个在SHA-1发明的时候是不可想象，不过其实在现在也是不可行的。只是按照现在计算机的发展速度 2018 年左右使用价格合适服务器集群理论上就可以破解（可以参考这里）：

”A collision attack is therefore well within the range of what an organized crime syndicate can practically budget by 2018, and a university research project by 2021。“

（”因此，在一个有组织犯罪集团的范围内，一次碰撞攻击的实际预算是2018，而一个大学的研究项目是2021“）

于是，Chrome 认为使用SHA-1的哈希函数都是潜在不安全的，于是会对所有使用SHA-1的网站证书提出警告，督促所有使用SHA-1的网站换为SHA-2。

不过注意，仅仅是潜在不安全， 目前还没有可行可靠的SHA-1碰撞算法出现。

所以，这些网站暂时是安全的，不过也希望站长们多多提高安全意识，因为SHA-1已经非常接近可以被“破解”边缘。很有可能会出现以上情况：被人找到碰撞算法或者说被破解，从而制作虚假警官证。

如果要详细的证书设置以去除这个警告的步骤，可以参考这里（点击进入链接）

因为工作原因——欧朋Opera是Chromium安全组成员，所以我对这个内情比较了解。有兴趣可以去看看讨论组里面的撕逼贴, 截个屏放在这里： 

作者罗志宇，混迹 Opera 10年的 CTO， Opera 是 Chromium 安全组成员。

来源：http://www.leiphone.com/news/201507/ZKpY3bJQtBUFgQAO.html

“在硅谷的硬件 meetup 上，你会见到一些老极客，一辈子就专注自己从事的领域，什么也不图，真正硅谷精神。”最开始听到朋友的这番话时我还将信将疑，直到遇见 Peter。

他七十多岁，谢顶，有些驼背。轮到他的产品展示，Peter 颤颤巍巍走上台，但声如洪钟。一上台他就说：“我不知道自己能不能用五分钟把自己研究了一辈子的技术、做了好几年的产品给讲清楚，不过，我试试吧。”

他的产品是一台叫做 DAC 的电脑，和他合作负责 DAC 研发的另外两位 Amir 和 Jim 也是爷爷级人物，他们都分别有自己的公司。Peter 的路演从头到尾都是晦涩难懂的技术语言，五分钟的 demo 过后的提问环节，台下响起一个声音：

“嘿Peter，你刚才说的我一个字也没有听懂，要知道你这样是很难拿到钱的。我觉得你以后再 demo，最好从产品的好处说起。”

“好吧，我原来以为极客硬件活动上的人都能听得懂我在说什么”。”面对质疑，Peter 的回答反而有些讽刺的口吻，“年轻人都喜欢谈市场什么的，但跟我一起造电脑的都是我这个岁数的老头子。不过话说回来，我们也没指望靠这个活动来筹钱。”活动一结束他便扬长而去。事后他告诉我自己当晚很失望没人问他聪明点的问题。

尽管年逾古稀，Peter 身上仍有浓烈的硬汉 feel，恰如他的谈吐，他的人生经历也很“硬”。从宾州州立大学物理专业毕业后，他加入美国和平团 (Peace Corp)，在马来西亚支教了两年，随后回国在马里兰大学修读工程学硕士。1976年他创办了 International Microsystems (IMI) 公司，长时间以来制造善于处理高速 PCIe、SATA、USB 的测试仪和复制机，而除了担任许多 IMI 仪器的首席架构师的角色以外，他也持有多项半导体记忆卡专利。“我一辈子都给了这些玩意儿。”

近40年来，IMI 的公司规模一直在15人到30人之间，客户有希捷、西部数据、惠普、富士康等等，有稳定的利润。大约是三年前，Peter 决定做自己真正想做的事，也就是研发 DAC。

DAC 电脑的前世今生

造 DAC 的想法其实可以追溯到15年前。那时照片里的 Amir 老爹带着一篇关于大数据处理语言 APL 的论文找到 Peter，希望他造出运行 APL 的电脑硬件，然而学量子物理出身的 Peter 表示这种语言对他来说太难，这事一搁就是12年。

三年前，Amir 又一次找到 Peter，再次表达了希望他能造出硬件，这次 Peter 没有拒绝。他仔细研究了当下运行该语言的电脑，当他发现电脑内部软件巧夺天工、而硬件一塌糊涂，一股强大的驱动力在他心里膨胀开来。“我想造出它的硬件！”，那时起他与 Amir、以及 APL2 语言的发明者 Jim 一起开始专心研发 DAC。

2014年底，Peter 的团队成功造出了第一台 DAC 原型，这台原型内含一台 Intel 主板和16个计算节点。今年1月，它成功通过了一系列基准测试程序，根据台试验分析的结果,每增加一个计算节点，主板的计算速度就提高4倍，验证了最初设想的简易和高速兼备的特点。

2014年底造出的 DAC 电脑原型，内含16个计算节点

颠覆的正是计算效率

DAC的全称是 Disjoint Array Computer，使用 Linux 操作系统。根据 Peter 老爹的说法，DAC 的产生具有“破坏性”，它会颠覆未来人们制造服务器农场 (server farm) 的方式。

不论从硬件还是软件上说，目前用云计算处理大数据都存在着挑战。网络连接存储 (Network-Attached Storage) 使得数据不易获取，并且以大型机为中心的解决方案非常缓慢，这不仅要求存储和计算之间存在一个超高速网络以维持数据流的畅通，并且需要更大更快的 CPU、超高速的并行总线和更大的 PCIe 闪存模块，这样的解决方案昂贵而不可持续。而 DAC 所做的是把云计算放入一个类似于刀锋服务器的黑盒子中。它所做的是在每个存储节点放上一台第三层电脑 (layer 3 computer) 用于处理每个节点的数据，此时再让处在他们中间的第二层电脑 (layer 2 computer) 进行计算，不仅计算速度大大提高，而且单位计算的耗电量也大幅减少，也更加便宜。

数据处理的速度有多重要？对于卫星数据和金融数据，也许可以先归档再分析。但有些数据的分析是等不了的。比如诊断癌症、识别恐怖分子，这类问题越早出结果越好。老爷子非常相信 DAC 未来在医药、国家安全领域的运用。

不止是这些，其实 DAC 面临的潜在市场不容小觑。根据 Intel 的预测，未来的闪存市场一半以上会被云计算占据，而云计算中速度为王，关键在于以低功耗进行迅速数据处理。回想起前几日读到的 Intel 收购芯片制造商 Altera 的新闻，我突然明白，新市场的争夺已经悄无声息地展开。当现有电脑硬件再也无法满足不断增长的云计算需求之后，服务中心巨头们手上的合同会花落谁家？

钱挑年龄，但理想不挑

在自己砸了15万美元造 DAC 后，老爷子决定融点钱，然而这过程并非一帆风顺。面见投资人时，老爷子听到最多的质疑是关于 DAC 电脑在当下的市场。许多投资人告诉 Peter，让大公司换掉现有的电脑，培训员工用接触新的技术是不现实的。另外，虽然投资人没有点出，但 Peter 明白三个创始人的年龄也是融资时面临的一道障碍。“投资人喜欢看到的是激情洋溢的年轻人。谁会想投钱给三个七十多岁的老头子？”他自嘲道。

但同时，Peter 非常执拗地相信，不创新世界就不会进步，在这项他倾注了许多心血的硬件技术上，他没有打算向现有市场低头。虽然没有见到另外两位老人，但是我想他们也应该是这样的。“因为 DAC 带来的是新的生态系统。”

Peter 之所以拒绝以众筹的方式募集资金，原因在于众筹得到的钱不一定能够支撑他们造出满足订单数量的产品，在目前，DAC 的制造还是极为昂贵的。Peter 的团队坚持先拿到融资，再造出电脑，最后再拿订单进入市场。此外，Peter 还非常希望投自己的人是能真正理解和支持他们产品的人，这也就是他再那天的硬件 meetup 活动上讲得那么难的原因。说到这里，他又硬朗地放声大笑起来。

“Peter，最后问你一个老掉牙的问题：你对 DAC 的愿景是什么？”

“拿一百万美元，造出产品，拿到订单。再找一帮跟你这样有活力的年轻人来接手 DAC 好好做下去。这就是我现在的愿景。”

来源：http://36kr.com/p/5035275.html

Docker一问世，IaaS、PaaS等云端公司就纷纷抢攻Docker商机，而受到Docker兴起所威胁的VMware与微软，也化敌为友加入Docker阵营。Docker现在被Google、Spotify、RedHat等IT巨擘众星拱月，在开源领域发展得也有声有色。

Forbes采访了当前最火的Docker创办人与CTO──Solomon Hykes，针对背后不为人知的有趣轶事做了精采分享。

Hykes说，“当你就要成功时，你永不知道原来成功离你如此靠近。” （左边为Docker CEO Ben Golub，右为CTO Solomon Hykes。）

在网咖打电动 让Hykes走入编程

落腮胡、皮夹克和摩托车，是Docker的灵魂人物CTO Solomon Hykes的标准记号，外型看起来像是推动社会运动的老大。

Hykes出生于纽约，父亲是美国人，母亲为法国、加拿大混血。他四岁搬到法国，毕业于巴黎的计算器本科，接着有半年在美国加州圣地牙哥大学就学。回到巴黎前，曾短暂在洛杉矶的法国电影公司工作。他的人生经历游走在法国与美国之间，带着浪漫与奔放的血液。

有趣的是，Hykes七岁就开始写代码。不过最初他只是为了打电动游戏，喜欢和朋友花上数小时的时光，在家附近的网咖玩星际大战。但这也让他获得了生平第一份工作──免费运维网咖服务器。“我尝试了一段新代码，每个在网咖的人就说‘为什么网速这么慢”，于是我就谨慎地把它调回来。而我的时间从玩游戏变成写编程。” Hykes打趣地说。只是他万万没想到，这个经验悄悄地引领他步上自己后来的新创公司。 

Docker未走红前，热爱摩托车的Hykes，正大力尝试要将初生的Docker项目在硅谷Santa Clara大会进行短讲与推广，然而当时群众们期待听见的是关于DotCloud的主题。在这关键的时刻，Hykes第一次骑上他的新车，他说，“我还记得当时心里想着，或许这就是象征要冒险的一天吧。”

Hykes不平凡的事业旅程，从他青少年时期在法国做服务器管理员，到如今已成为一家最火的新创公司的创始人兼CTO。

Docker前身 早像温水煮青蛙

时值31岁的Solomon Hykes，2010年从美国知名的创业孵化器Y Combinator毕业后，建立的新创企业叫DotCloud。这个软件提供开发者平台在亚马逊的云端上编程，成功募资1100万美元，投资人包括了Yahoo创办人杨致远。

DotCloud的商业模式为：以多语言PaaS为卖点，使得用户可以选择不同的开发组件和语言来运行程序。

但DotCloud的客户逐渐成熟饱和，而亚马逊自己的支持已经强化，意味DotCloud的成长变得缓慢，有些人开始取消对他们的投资。董事会花了数月寻找有经验的运营者。早期投资人Peter Fenton说DotCloud在2012年的挣扎，像温水煮青蛙。 

直到他们找到了Golub，转机开始来到。Golub同意Hykes的想法，认为要做点大胆举动。“不然，他们就要在水中溺死了。”Peter Fenton贴切地形容。于是新CEO Golub赌上银行存款中最后的500万美金，大胆压注在Docker以及“容器”的技术概念上。因为Hykes在运作DotCloud过程中，发现多平台的需求越来越受到用户的关注，成为构建Docker的灵感。最后，他们跨出更大胆的一步──大家都知道的：开源，一举让Docker成为今日之星。

面对那段艰困的时期，Hykes表示，“我们从来不开无聊的会议，我们总是想要证明些什么。但我也不断面临两难的抉择，要不计一切代价突围，或者再一次重新思考。而当你就要成功时，你永不知道原来成功离你如此靠近。”

Hykes也不讳言地透露，他之前一直认为Docker这名字糟透了。“我们一定要在发布它以前换掉这个名字。”没想到Docker容器中的App下载量目前高达53.5亿，一跃成为无人不晓的当红炸子鸡。

Hykes：生态圈无法是Docker十倍  我们就走错方向

朋友和战友，这是容器生态快速发展的新写照。高人气的Docker两年内不可思议地快速崛起，容器和他们提倡新的基础建设方式，已经引领新创公司和创投爆炸性投入。

围绕Docker形成的新创公司并非复制品，至少现在还不是。它们反而聚焦在Docker还未处理的问题，或当你进入容器领域初期才会发生的问题。它让你在服务器空间能更快、更有效率地运行App。例如Weave works聚焦在容器的网络议题。一家日前募资850万美金的新创公司Portworx，也在和Weave works交涉。

因着Docker的成功，其他相关公司的轮廓也愈来愈清晰。但是停下来思考时，会发现事情似乎变得愈来愈复杂，那些声称支持Docker并与其合作的，却提供不同的服务来运行他的基础建设。像新创公司Hashicorp，聚焦在不只可以包含Docker，也包括其他各种广泛资源的工作流。

另一个例子，是关于曾在Airbnb担任工程师的Florian Leibert，他现在已成为Mesosphere的CEO。从前他最厌恶凌晨三点被电话叫醒，只因为服务器挂掉或是亚马逊断电必须重开机。因此他的新创公司Mesosphere，通过将数据中心全部连结到同等的、且任何暂时失误发生时都能持续运作的大计算机，企图减少这類的问题。而Yelp就使用它们的产品Mesos来每天发布100万个Docker容器。

由此，“或许你可以这样思考，如同Windows生态系开始时，微软变成了最大的巨人，但有很多好生意、商业模式与机会建立都在它之上。” Leibert解释到。

随着近5000万美元的总融资（大多是去年12月B轮3600万的融资），Mesosphere已经拥有一些主要的客户和支持者，希望它最后会和Docker的规模一样大、甚至超越Docker。

Solomon Hykes认为，每个人都试图用仁慈互相残杀。你希望在舞台的中心，但每个人都整合每一个人，而最后这对使用者是最好的结果。

对此，Hykes和Golub都一致表示，他们知道除非开源项目和其社区存活，他们的公司才可能成功。“如果生态系无法是Docker本来的十倍，那我们就走错了方向。对我们来说，身为一家企业，以及面对产业，正确的方向应该是聚焦在能为用户带来什么。” 

来源：http://www.csdn.net/article/2015-07-07/2825153-docker

谷歌最近公布了他们基础设施系统王冠上的宝石之一：Borg，集群调度系统。这促使我重新阅读了Mesos和Omega论文，它们与Borg的功能类似。我觉得对比下这三个系统一定会非常有趣。Mesos两级调度的突破性理念得到了认可，Omega使用类似数据库的技术有所改进，Borg可以看作是对所有这些思想的巅峰之作。

背景

集群调度系统在大数据出现之前就存在已久。在高性能计算（HPC）的世界中，关于上千核CPU的调度有丰富的文献，但他们的问题域比数据中心调度系统要解决什么更简单，到底该用Mesos/Borg还是与他们同类的其他产品。让我们从几个维度对他们进行一次对比。

为具体位置而调度

超级计算机将存储和计算分离，并使用近似于全等分带宽的网络连接起来，其运行速度接近内存速度（GB/秒）。这意味着我们的任务可以放置在集群上的任何地方，而不必考虑具体位置，因为所有计算节点都可以同样快速地访问数据。一些超优化的应用优化了网络拓扑，但这毕竟是非常罕见的。

数据中心调度系统会关心具体位置，实际上，这是GFS和MapReduce共同设计的结果。回眸2000年初，那时的网络带宽远比磁盘带宽昂贵。所以，为了经济上极大的节约，调度算法会将计算任务保持在与数据相同的节点上。这是调度主要的约束;在我们可以把任务放到任何地方之前，需要将其放在三个数据副本之一的节点上。

硬件配置

超级计算机通常由同质节点组成的，即它们都具有相同的硬件规格。这是因为，超级计算机一般是一次性购买的：实验室获得几百万美元的采购费用，然后一次全部预支出去。一些高性能计算应用的优化是针对超级计算机中特定型号的CPU的。新技术，如图形处理器和协处理器的推出，就要作为一个新的集群。

在大数据领域，集群主要受存储限制，因此运维不断地增加新的机架，更新规格来扩展群集容量。这意味着节点可以有不同的CPU、内存容量、磁盘数量等。这样的节点还可以配入指定的附加设备，如固态硬盘、图形处理器、重叠驱动器（shingled drive）等。一个数据中心可能要支持广泛的应用，而这一切又会强加额外的调度约束。

队列管理和调度

在超级计算机上运行应用程序时，你需要指定想要多少个节点、要提交作业的队列，以及作业将运行多长时间。队列存储可以请求多少资源、作业可以运行多久等不同的限制。同时，队列也有优先级或基于系统的预留来确定排序。由于作业的持续时间都是已知的，这是一个非常简单的打包到盒子的问题。如果队列很长（通常就是这样），并有可以很好融合的小作业回填大作业（也是典型）的剩余空间，则可以实现非常高的资源利用率。我很喜欢将这一描述用以时间为X轴，以资源使用为Y轴的可视化2D图呈现出来。

如前所述，数据中心的调度是一个比较普遍的问题。资源请求的“形状”可以是相当多样，并有更多的维度。作业也没有设定持续时间，所以很难预先计划队列。因此，我们有更复杂的调度算法，从而，调度器的性能变得非常重要。

利用率作为一般的规则将变得糟糕（除非你是谷歌，以及更多的后来者），但高性能计算之上的应用有一个优势是可以使用MapReduce和类似的技术逐渐代替组调度。高性能计算，会等到请求所需的N个节点都可用后，同时运行所有任务。MapReduce可以在多次波动中运行它的任务，这意味着它仍然可以有效地利用剩余的资源。单一的MR作业也可以基于集群的需求起伏，避免了抢占或资源预留，并且还有助于实现多用户之间的公平性。

Mesos

Mesos的出现早于YARN，并且在设计时考虑了原有MapReduce的问题。当时，Hadoop集群只可以运行一种单一的应用：MapReduce。这使得它很难运行不符合先是map阶段后是reduce阶段的应用程序。这里最好的例子是Spark。在Mesos出现之前，你必须为Spark安装一套全新的worker和master，这一套设置与MapReduce的worker和master放在一起。这么做，从利用率的角度来看非常不理想，因为他们通常是静态分区的。

通过为所有集群应用提供一个通用调度器，Mesos解决了这一问题。MapReduce和Spark被简单地作为不同的应用程序，他们可以使用相同的基础资源，共享Mesos的Framework。最简单的实现方法是写一个集中式的调度器，但具有如下一些缺点：

• API的复杂性：我们需要一个单一的API，它是所有已知Framework调度器API的超集。这本身就是一个难题。资源请求也会变得非常复杂。
• 性能：成千上万个节点和数百万的任务实在太多，特别是当调度问题很复杂的时候。
• 代码的灵活性：要为新的需求，持续编写新的调度器和新的Framework。

相反，Mesos引入了两级调度的理念。Mesos将每个应用程序的调度工作委派给应用程序本身，同时，Mesos仍然负责应用和执行整体公平性之间的资源分配。因此，Mesos可以做得相当薄，只有10K行代码。

两级调度通过一个名为资源邀约的新API发起，Mesos会周期地为应用程序调度器提供一些资源。这咋听起来很落后（请求要从master到应用程序？），但其实这一点都不奇怪。在MR1中，TaskTracker worker是实际的运行节点。当TT心跳报告任务完成后，JobTracker会选择别的任务让TaskTracker运行。调度决策本质上是由worker上的资源邀约触发的。在Mesos中，资源邀约来自Mesos master，而不是slave，因为Mesos在管理集群。没有什么不同。

资源邀约扮演着对资源有时间限制的租约。基于优先级或公平份额策略​​，Mesos向应用程序提供资源。然后，应用程序会计算如何使用他们，并且告诉Mesos资源邀约中它想要的那部分资源。这给了应用程序很大的灵活性，因为它可以选择现在运行任务的一部分、等待后面更大的分配（组调度），或者调整任务的大小以适应可用的资源。由于邀约是有时间限制的，这也激励了应用程序去实现快速地调度。

一些问题及解决办法：

• 长任务占用资源：Mesos允许为短任务预留一些资源，时间期限一到便杀死他们。这也激励了用户使用短任务，它具有很好的公平性。
• 性能隔离：使用Linux容器（cgroups）。
• 大型任务饥饿：很难得到一个节点的唯一访问权，因为一些具有较小任务的其他应用程序会蚕食它。可以通过设定请求资源的最小规模来修复这一问题。

尚未解决的/未知的决定：

• 组调度：我认为，无法预知任务长度或者抢占不可能做到高利用率。可以使用低利用率来增量囤积资源，但这可能会导致死锁。
• 跨应用程序抢占很也难：资源邀约API没有办法说“这里有一些低优先级的任务，如果你想要，我可以杀掉他们。”Mesos实现公平性取决于任务必须是短期的。

Omega

Omega是Mesos的继任者，事实上，是同一作者。由于论文采用模拟结果做评估，所以我怀疑它永远不会进入谷歌的生产，而其中的想法会进入下一代Borg中。改写API可能是太侵入性的变化，即使是谷歌。

Omega让资源邀约更进一步。在Mesos中，资源邀约是悲观的或独占的。如果资源已经提供给一个应用程序，同样的资源将不能提供给另一个应用程序，直到邀约超时。在Omega中，资源邀约是乐观的。每个应用程序可以请求群集上的所有可用资源，冲突在提交时解决。Omega的资源管理器基本上只是一个记录每个节点状态的关系数据库，使用不同类型的乐观并发控制解决冲突。这样的好处是大大增加了调度器的性能（完全并行）和更好的利用率。

所有这一切的缺点是，应用程序是在一个绝对自由的环境中，他们可以以最快的速度吞噬他们想要的资源，甚至抢占其他用户的资源。对谷歌来说这没问题，因为他们使用基于优先级的系统，并且可以向他们的内部用户咆哮。他们的应用大致只分为两种优先级：高优先级的服务性作业（如HBase、web服务器、长住服务等）和低优先级的批处理作业（MapReduce和类似技术）。应用程序可以抢占低优先级的作业，并且在协作执行限制的范围＃内授信，以提交作业、计算资源分配等。我认为雅虎没法冲着用户大叫（当然是不可扩展的），但这在谷歌某种方式上是可行的。

论文的大部分在谈论这种乐观的分配方案如何与冲突一起工作的，这永远是个问题。有一些高级的注意事项：

• 服务性作业都较大，对（跨机架的）容错有更严格的配置需求。
• 由于在分配完全群集状态上的开销，Omega大概可以将调度器扩展到十倍，但是无法达到百倍。
• 秒级的调度时间是典型的。他们还比较了十秒级和百秒级的调度，这是两级调度的好处真正发挥作用的地方。无法确定这样的场景有多普遍，也许是由服务性作业来决定？
• 典型的集群利用率约为60％。
• 在OCC实践中，冲突非常罕见。在调度器崩溃之前，他们能够将正常批处理作业上升6倍。
• 增量调度是非常重要的。组调度明显更昂贵，因为要增加冲突处理的实现。显然，大多数的应用程序可以做好增量，通过实现部分资源分配进而达到他们所需的全额资源。
• 即使执行复杂的调度器（每作业十余秒的费），Omega仍然可以在合理的等待时间内调度一个混合的作业。
• 用一个新的MapReduce调度器进行实验，从经验上说，在Omega中会非常容易。

开放式问题

• 在某些时候，因为高冲突率和重试导致的重复工作，乐观并发控制会崩溃。在实践中他们好像没有碰到这种问题，但我不知道是否有奇形怪状的任务致使出现最坏的场景。这是受服务和批处理作业联合影响的吗？在实践中他们做过什么调优吗？
• 是否缺乏真正可以接受的全局策略？如公平性、抢占等。
• 不同类型的作业调度的时间是多少？有人已经写出非常复杂的调度器吗？

Borg

这是一个具备生产经验的论文。与Omega有相同的负载作业量，因为它也出自谷歌，所以很多元点都是一样的。

高级功能

• 谷歌的一切都在Borg中运行，包括像CFS和BigTable这样的存储系统。
• 平均集群大小为10K个节点，虽然还有更大集群。
• 节点可以是异构的。
• Borg使用了Linux进程隔离技术（基本上就是容器技术），因为Borg的出现早于现代虚拟机基础架构。效率和启动时间是很重要的。
• 所有作业都是静态链接的二进制文件。
• 有非常复杂、非常丰富的资源规范语言。
• 可以滚动更新运行的作业，更新可以是配置和二进制文件。有时这需要任务重新启动，所以容错很重要。
• 通过SIGTERM支持“正常停止”，否则通过SIGKILL最终杀掉进程。软杀进程是可选的，但从正确性上说是不可靠的。

Alloc

• 资源分配从进程活跃度中分离。Alloc可以用于为任务组资源分配，或者为重新启动的任务保留资源。
• Alloc集合是一组在多台机器上的Alloc。多个作业可以在一个单一的Alloc中运行。
• Alloc实际上是一种很常见的模式！对于分离问题与实现，多进程是有用的。

优先级和配额

• 两级优先级：服务性的高优先级和批处理的低优先级。
• 更高的优先级作业可以抢占低优先级的。
• 高优先级的作业不能彼此抢占（在防止级联活锁的情况下）。
• 配额用于接入控制。用户支付更多的配额获得更高的优先级。
• 运行在最低优先级还提供了“自由”层，以鼓励高利用率和回填工作。
• 这是一个简单易懂的系统！

调度

• 两个阶段调度：找到可行的节点，然后为最终放置对这些节点评分。
• 可行性在很大程度上由任务约束决定。
• 评分主要由系统属性决定，比如最适合与最不适合、作业组成、故障域、具体位置等。
• 一旦最终节点被选择，Borg将抢占该节点的资源以适应需求。
• 典型的调度时间是25秒左右，这依赖于具体节点的本地化。下载二进制占这个时长的80％。这个具体位置很重要。 Torrent和树协议用于分发二进制文件。

伸缩性

• 集中化一直是潜在的性能瓶颈。
• 针对成千上万个节点，每分钟调度的速率为10K任务。
• 典型的Borgmaster使用10-14个内核和50GB内存。
• 随着时间推移，参照Omega和两级调度，Borg架构已经变成更多的多进程。
• Borgmaster是独立的主节点，但有些责任依然共享：worker状态的更新、只读的RPC。
• 一些明显的优化：缓存的机器分数、每种任务类型计算一次的可行性，在做调度决策时，不要试图全局最优。
• 对较大单元的主要争论是隔离操作错误和失败的传播。架构保持良好的伸缩性。

利用率

• 他们的主要的度量指标是单元压缩，或者说还有空间容纳一组任务的最小集群。从本质上讲是打包装箱。
• 主要收益来自以下几点：不分隔作业或用户、有很大的共享集群、细粒度的资源请求。
• 基于Borglet的乐观过量使用。 Borglets做资源估算，然后回填非prod工作。如果估计不正确，杀掉非prod工作。内存是无弹性的资源。
• 共享不会显着影响CPI（CPU干扰），但我不知道对存储是否有影响。

经验教训

这里列出的问题多数在他们的公开的、开放源码的容器调度系统Kubernetes中已经修复。

缺点：

• 对于跟踪和管理来说，调度多作业的工作流程要比调度单一的作业更好。关于工作流组件，还需要更灵活的方式。解决办法是可以将任意的键值对附加到每个任务上，并允许用户对其进行查询。
• 每台机器一个IP。这会导致一台机器上的端口冲突，以及复杂的绑定和服务发现。可以通过Linux的命名空间、IPv6和SDN来解决。
• 复杂的规范语言。知识点太多，作为一个普通用户很难上手。自动化确定资源请求需要一些工作。

优点：

Alloc非常牛！辅助服务可以很容易置入下一个主任务。后台服务，如负载均衡服务和命名服务是非常有用的。度量、调试、网页界面都很重要，用户能通过他们解决自己的问题。集中化的可扩展性很好，但需要将其拆分到多个进程中。为此，Kubernetes从新开始，为不同调度器组件提供一套干净的API。

结束语

YARN看上去借鉴了Mesos和Omega，使伸缩规模到达10K节点。与Mesos和Omega相比，YARN仍然是一个集中式的调度系统。Borg特别强调要分片伸缩。

为了实现高利用率而不损害服务水平目标（SLO），隔离是非常重要的。这可以在应用程序层面来实现，而应用服务本身需要设计为延迟容忍的。想想在BigTable中，为避免请求延迟（tail-at-scale）采用的向副本发起请求。最终，问题归结为是要硬件来做隔离还是软件来做。保持运行于利用率较低的状态可以回避这一问题。或者，你可以直接通过OS的隔离机制、资源评估和调整你的作业和调度器来解决。在谷歌的规模下，有足够的硬件、可以招一批内核开发工程师来实现。幸运的是，他们为我们做足了工作 🙂

我也想知道，是否谷歌的假设作业更具备普遍性。谷歌能很好地使用优先级分类、资源预留，以及抢占，但是我们的客户几乎全部使用公平共享调度器。雅虎使用容量调度器。 Twitter使用的公平调度器。我没有听说过的关于优先级+资源预留调度器的任何需求或使用。

最后，很少有客户会运行在谷歌预想的大共享集群上。我们的客户在使用千级的节点，但是这被分为百级的pod节点上。为单独的用户或者应用程序独立部署集群也是常见的。集群在硬件方面通常还是同构的。我认为这将开始改变，并且会很快。

来源：http://www.infoq.com/cn/articles/comparison-of-mesos-omega-and-borg