XEN 与 VMware ESXi，Hyper-V 以及 KVM 特点比较

      XEN 有简化虚拟模式，不需要设备驱动，能够保证每个虚拟用户系统相互独立，依赖于 service domains 来完成一些功能； Vmware ESXI 与 XEN 比较类似，包含设备驱动以及管理栈等基本要素，硬件支持依赖于 VMware 创建的驱动； Hyper-V 是基于 XEN 管理栈的修改； KVM 与 XEN 方式不同，KVM 是以 Linux 内核作为管理工具。
虚拟机的体系结构

XEN 体系结构

XEN 体系结构图如下：

      Xen是一个开放源代码虚拟机监视器，由剑桥大学开发。Xen的缺点是操作系统必须进行显式地修改（“移植”）以在Xen上运行（但是提供对用户应用的兼容性），所以比较麻烦。使得Xen无需特殊硬件支持，就能达到高性能的虚拟化。Linux的官方内核在较早之前已经去掉了对Xen的支持。

      一个 XEN 虚拟机环境主要由以下几部分组成：

XEN Hypervisor； Domain 0 —— Domain Management and Control(XEN DM&C)； Domain U Guest(Dom U) PV Guest HVM Guest

       Xen 三部分组成之间关系图

XEN Hypervisor ：

XENHypervisor 是介于操作系统和硬件之间的一个软件描述层。它负责在各个虚拟机之间进行 CPU 调度和内存分配。XEN Hypervisor 不仅抽象出虚拟机的硬件，同时还控制着各个虚拟机的执行。XEN Hypervisor 不会处理网络、存储设备、视频以及其他 I/O.

Domain 0：

Domain 0 是一个修改过的 Linux kernel，是唯一运行在 Xen Hypervisor 之上的虚拟机，它拥有访问物理 I/O 资源的权限，同时和系统上运行的其他虚拟机进行交互。Domain 0 需要在其它 Domain 启动之前启动。

Domain U：

运行在 Xen Hypervisor 上的所有半虚拟化（paravirtualized）虚拟机被称为“Domain U PV Guests”，其上运行着被修改过内核的操作系统，如 Linux、Solaris、FreeBSD 等其它 UNIX 操作系统。所有的全虚拟化虚拟机被称为“Domain U HVM Guests”，其上运行着不用修改内核的操作系统，如 Windows 等。

Hyper-V 体系结构

Hyper-V 体系结构图如下：

      Hyper-V 是微软提出的一种系统管理程序虚拟化技术，采用微内核的架构，兼顾了安全性和性能的要求。Hyper-V 底层的 Hypervisor 运行在最高的特权级别下，微软将其称为 ring -1（而 Intel 则将其称为 root mode），而虚机的 OS 内核和驱动运行在 ring 0，应用程序运行在 ring 3 下，这种架构就不需要采用复杂的 BT（二进制特权指令翻译）技术，可以进一步提高安全性。从架构上讲 Hyper-V 只有“硬件－Hyper-V－虚拟机”三层，本身非常小巧，代码简单，且不包含任何第三方驱动，所以安全可靠、执行效率高，能充分利用硬件资源，使虚拟机系统性能更接近真实系统性能。

      Hyper-V 支持分区层面的隔离。分区是逻辑隔离单位，受虚拟机监控程序支持，并且操作系统在其中执行。Microsoft 虚拟机监控程序必须至少有一个父 / 根分区，用于运行 64 位版本的 Windows Server 2008 操作系统。虚拟化堆栈在父分区中运行，并且可以直接访问硬件设备。随后，根分区会创建子分区用于承载来宾操作系统。根分区使用虚拟化调用应用程序编程接口 (API) 来创建子分区。

     分区对物理处理器没有访问权限，也不能处理处理器中断。相反，它们具有处理器的虚拟视图，并运行于每个来宾分区专用的虚拟内存地址区域。虚拟机监控程序负责处理处理器中断，并将其重定向到相应的分区。Hyper-V 还可以通过输入输出内存管理单元 (IOMMU) 利用硬件加速来加快各个来宾虚拟地址空间相互之间的地址转换。IOMMU 独立于 CPU 使用的内存管理硬件运行，并用于将物理内存地址重新映射到子分区使用的地址。从系统的结构图，我们可以看出来 Hyper-V 与 Xen 的架构很相似。

Vmware ESXI 体系结构

Vmware ESXI 体系结构图如下：

      VMWare (Virtual Machine ware)是一个“虚拟PC”软件公司。它的产品可以使你在一台机器上同时运行二个或更多Windows、DOS、LINUX系统。与“多启动”系统相比，VMWare采用了完全不同的概念。多启动系统在一个时刻只能运行一个系统，在系统切换时需要重新启动机器。VMWare是真正“同时”运行，多个操作系统在主系统的平台上，就象标准Windows应用程序那样切换。而且每个操作系统你都可以进行虚拟的分区、配置而不影响真实硬盘的数据，你甚至可以通过网卡将几台虚拟机用网卡连接为一个局域网，极其方便。安装在VMware操作系统性能上比直接安装在硬盘上的系统低不少，因此，比较适合学习和测试。

      由上图我们可以看出来管理工具也是直接嵌入到了 ESXi vmKernel 中，没有再分化出单独的管理工具，这一点与 Xen 是相区别的。

KVM 体系结构

KVM 体系结构图如下：

      KVM 是一个独特的管理程序，通过将 KVM 作为一个内核模块实现，在虚拟环境下 Linux 内核集成管理程序将其作为一个可加载的模块可以简化管理和提升性能。在这种模式下，每个虚拟机都是一个常规的 Linux 进程，通过 Linux 调度程序进行调度。
    
      KVM是指基于Linux内核（Kernel-based）的虚拟机（Virtual Machine）。KVM最大的好处就在于它是与Linux内核集成的，所以速度很快。KVM的宿主操作系统必须是Linux，支持的客户机操作系统包括Linux、Windows、Solaris和BSD，运行在支持虚拟化扩展的x86和x86_64硬件架构上，这意味着KVM不能运行在老式CPU上，新CPU如果不支持虚拟化扩展也不能运行（如英特尔的Atom处理器）。

KVM、Xen、VMWare的对比

通过以上四种虚拟机的体系结构图，我们可以看出他们在整个系统中的位置，以及相互之间的区别。
本文基于互联网整理转载分享  参考原文1  参考原文2 收起阅读 »

      1997年，斯坦福的Mendel Rosenblum带着Edouard Bugnion, Scott Devine在SOSP上发了篇论文，叫做Disco: running commodity operating systems on scalable multiprocessors （http://www.stanford.edu/class/cs240/readings/disco.pdf）。发了之后，我想他们应该是觉得这个主意太好了，就开了家公司，名叫VMWare。
 
      这篇论文起名叫Disco（迪士高）是因为虚拟机本身不是一个新的东西，大概在上世纪70年代就有了。作者们为了表示敬意，或者是显示这是一个复古的东西，就把这个项目取名为disco。这篇论文介绍了虚拟机关键技术，用来回答这个问题再合适不过了。（多年之后，OSDI上的另一篇论文（Memory Resource Management in VMware ESX Server）介绍了一些VMWare的改进。近年来论文越来越多。）
 
      当初他们为什么要做虚拟机？简单说就是，新硬件层出不穷，但是OS赶不上。当初，他们想在Stanford的ccNUMA机器上跑IRIX（一个操作系统）。可是IRIX跑不起来。他们觉得修改OS或者写一个新的OS太难了（因为一个操作系统从出生到成熟要很长的时间，无数BUG要FIX，无数的新功能要增加。。。那样人家博士要怎么毕业。。）。所以，他们决定用虚拟机。
 
      对于他们的项目，虚拟机大致有下面这些好处：

1、只要对商业OS做简单地修改，就能让他们在多个VM(Virtual Machine)间共享内存。

2、Flexible。除了论文里的IRIX，实际上其他的OS也能跑。

3、扩展性好。系统可以以虚拟机为单位扩展。

4、fault-containment。每一个VM都是一个几乎独立的个体，一个坏了，不影响另一个。

5、新老软件可共存。比如，新的软件只能在Linux-3.15跑。你可以用两个VM，一个是Linux2.6，一个是Linux-3.15。

      这篇文章回答下面这几个实现虚拟技术的关键问题：

1、VMM(Virtual Machine Monitor, 或者叫hypervisor)是怎么管住Guest OS的？或者说，皇上(VMM)是怎么防止大臣(OS)夺权的？

2、有那么多个操作系统一起运行，内存是怎么管理的？

3、多个VM之间是怎么分享资源的？或者说，1GB内存怎么当2GB用？

VMM(Virtual Machine Monitor, 或者叫hypervisor)是怎么管住Guest OS的？或者说，皇上(VMM)是怎么防止大臣(OS)夺权的？

      要理解VMM是怎么工作的，我们得先了解没有VMM的时候，系统是怎么工作的。在没有VMM的时候，计算机系统中的”应用”可分为用户进程(比如VIM)和操作系统。他们分别运行在不同的模式中（mode）。我们用一个类比来解释系统中的模式（mode）。模式这个机制是用来限制一段指令所在的环境的权限的，它是需要处理器的支持的。MIPS结构当时有三个模式：用户模式（user mode)，长官模式（supervisor mode，原谅我的翻译…）和内核模式（kernel mode）。这三种模式分别对应于人类社会里的民宅、官衙和金銮殿。显而易见，在金銮殿里的人拥有的权限最高，民宅里的最低。我们可以说，在没有VMM时，用户进程住在民宅里，县衙空着，OS住在金銮殿里（如图）。用户可以直接做一些不用什么特权的事情（unprivileged instructions），比如计算1+1。做这些事情不经过OS。但是，有些要特权才能做的事情，一定要经过OS。比如保存正在编辑的文档到硬盘。访问硬盘是特权操作是因为硬盘是共享的资源，要有人管着，不能让人乱来。试想，要是人人都能读写档案馆的档案，那不就乱套了。

      VIM（用户进程）不能直接写磁盘上的文件。VIM必须请求在金銮殿里的操作系统来做。怎么请求呢？通过系统调用（system call）。系统调用的过程是这样的：比如要调用的是write(fd, buf, len, off)，首先把fd, buf, len, off放到stack里，然后再把一个write()函数对应的号码（system call number）放到stack里，最后调用一个特殊的指令使CPU进入内核模式(图中的圈1)。在x86结构中，这个指令是int（中断）。在MIPS结构中，这个指令是trap。这个指令会引导CPU执行一段代码（trap handler），依照stack里的system call number 找到对应的函数（在这里是write()的实现），然后调用这个函数（函数的参数在刚才的stack里）。在这里函数里，操作系统调用文件所在的文件系统里的write()实现，文件系统使用磁盘的驱动来最终实现。所以文件的操作完成后，操作系统调用与trap功能相反的一个指令，回到VIM程序的指令里(图中的圈2)。

      操作系统维护自己的特权的过程大概就是这样。但是这个特权等级到底是怎么实现的呢？我们可以想像CPU里有一个特权状态（privileged state bit）。状态为开(On)的时候，CPU的特权等级高，你可以做任何事，包括转到低特权状态。关(Off)的时候，你所能做的事情就所限了。那怎么从off状态转到on状态呢？你必须到执行CPU的特殊指令，这个指令会把你带到一个特定的地方执行操作系统的指令，检查你是不是有进入高特权状态的权限。这就像是在机场，你可以很容易地从登机口到售票大厅，可是你要从售票大厅到登机口，你就得过安检。另外，为什么操作系统就能有高特权呢？Hmm…因为操作系统一开始就把那占了，之后运行的应用程序就只能听它使唤了。
 
      现在，终于要说VMM（virtual machine monitor, 或者叫hypervisor）是怎么实现的了。如下图:

      现在VMM进了金銮殿，有了最高的特权。操作系统被放到了官衙里（但是它自己并不知道）。用户进程还是在民宅里住着。比如，现在用户进程VIM调用write()，会发生什么？用户进程会trap到VMM（拥有kernel mode）里去。但是，VMM并不知道如何处理write()。所以，VMM接下来会调用OS的里对应的trap handler，这个handler会执行文件系统的write()，然后用驱动来写磁盘。这一切的操作都在VMM的监视下进行。怎么监视？操作系统实际上是在虚拟CPU（Virtual CPU）上运行的。VCPU有一套自己的（假的）寄存器。VMM盯着这些寄存器。在操作系统的trap handler完成之后，它会调用trap的反操作（想返回user mode）。但是，这个操作实际上回使CPU回到VMM，由VMM最后返回到用户进程。
 
      为什么VMM能够知道操作系统的trap handler在哪？系统中先有VMM。当你在VMM上安装操作系统的时候，操作系统会尝试调用特权指令安装trap handler。因为有最高特权的VMM实际上是监视着这一切的，所以它可以记录下trap handler的位置就行了。
 
      总的说来，虚拟机占据了CPU的最高特权，使得在更低特权等级的操作系统无法进行有害操作。

有那么多个操作系统一起运行，内存是怎么管理的？

      在没有VMM的时候，系统中有两种内存地址：虚拟地址(virtual address)和物理地址(physical address)。从虚拟地址到物理地址的转换有两种方式。方式一：在TLB(translate lookside buffer，硬件实现)查找。方式二：在页表(page table)中查找，找到之后把结果放到TLB中去。系统会先尝试方式一，要是找不到（TLB miss），就用方式二。

      在有了VMM之后，系统中有三种内存地址：虚拟地址(virtual address)，物理地址(physical address)和机器地址(machine address)。机器地址才是真正与内存条上的地址一一对应的。物理地址只是操作系统认为的物理地址。

      当操作系统试着要使用特权指令来完成一个虚拟地址到物理地址的转换时（TLB miss），VMM就介入了（VMM监视着所有对特权寄存器的操作）。VMM会先使用操作系统内的代码来先完成虚拟地址到物理地址的转化（因为VMM并不知道这个映射关系）。然后，操作系统认为自己已经完成了转化，尝试去更新TLB（特权操作）。这个时候，VMM会介入，用一个叫个pmap的映射表找到物理地址对应的机器地址，用机器地址替换掉物理地址，然后把TLB更新为虚拟地址到机器地址的映射。之后，所有对这个虚拟地址的访问都会被转换为对相应机器地址的访问。

多个VM之间是怎么分享资源的？或者说，1GB内存怎么当2GB用？

      我们知道，每一个虚拟机都要占用大量的内存空间。在内存有限的情况下，怎么在一台机器运行更多的虚拟机？幸运的是，不用的虚拟机之间在内存中数据可能会完全一致（比如，系统文件在内存中的缓存）。如要我们可以只在内存中保留一份数据，我们就行节省很多空间。Disco使用虚拟IO设备和虚拟网络设备来节省内存空间。

虚拟IO设备：

当两个虚拟机从同一个磁盘上读同一个文件时，VMM会intercept DMA，然后就会发现这两个VM在使用同样的数据。这份数据只需要在机器内存里保存一份，然后修改pmap，使得两个VM的物理地址指向同一个机器地址就可以了。当任何一个VM更新这份数据，VMM会给它一份新的拷贝，原来的那份不做更改（copy on write机制）。

虚拟网络设备：

当使用NFS从VM1向VM2复制文件时，文件并没有被真正地复制。虚拟网络设备会更新VM2上的pmap，使之指向在内存中的文件，使得VM2上的操作系统认为自己已经有了这个文件。

后来，VMWare还有用hash来找相同的内存页然后再共享的技术。
原文地址 收起阅读 »

现象

# docker ps

FATA[0000] Get http:///var/run/docker.sock/v1.16/containers/json: 

dial unix /var/run/docker.sock: permission denied.

Are you trying to connect to a TLS-enabled daemon without TLS?

分析解决

首先你得确认/var/run/docker.sock文件是否存在

# ls -l /var/run/docker.sock

srw-rw---- 1 root docker 0 sty 28 11:53 /var/run/docker.sock

解决方案现在很清楚了，通过添加你的登陆用户到docker用户组来解决这个问题，如下所示：

# sudo gpasswd -a ${USER} docker

/etc/group文件内容应该可以看出变化了

# cat /etc/group | grep ^docker

下面我们打开一个新的终端来检查登陆用户是否加入到了docker用户组，应该存在于如下命令结果中

# groups

如果你的登陆用户还没有加入到docker用户组，你可以尝试重启机器。如果你可以正常重启docker容器，就不需要重启服务器了。

# sudo service docker.io restart

然后你运行docker ps应该就没有问题了！

收起阅读 »

起因：

           公司使用的是Ucloud的云主机服务，今天上午突然被告知有一台服务器的出口流量激增，对外发包量短时间内达到了100万，而且都是UDP类型的，第一感觉就是：诶呀，莫不是被黑了，被当肉鸡了呀！

探究:

           立马登录对应的服务器，首先使用iftop查看流量状况


           可以看出出口流量好吓人，1分钟内累计700M流量，查了一下这2个IP地址，一个是在美国，一个是在浙江电信；赶紧查看正在运行的进程，找出疑似进程，还真有所发现：

           [.ECC6DFE919A382]这个进程还想冒充系统进程，疑点极大，而且/tmp/freeBSD也是一个很奇怪的东西，而498这个UID对应的用户是elasticsearch，想起来昨天部署了Elasticsearch + Logstash，以实现日志统计系统，不会是ES有bug吧，继续查看原因

            疑/tmp/freeBSD就是被挂马的程序，可惜已经被删除了，无法查看了

原因：

            罪魁祸首查出来了，细致的原因还需要详查，所以现在最重要的就是解决问题，迅速kill掉相关进程，再次查看iftop发现流量迅速回落了，更加证实了我们的判断；
            接下来就需要查找被劫持挂马的原因和具体的劫持方式，以绝后患，而通过外部搜索引擎也是很快就定位了问题的原因，就是“Elasticsearch远程任意代码执行”漏洞：

[]ElasticSearch有脚本执行(scripting)的功能，可以很方便地对查询出来的数据再加工处理； ElasticSearch用的脚本引擎是MVEL，这个引擎没有做任何的防护，或者沙盒包装，所以直接可以执行任意代码。[/][]而在ElasticSearch 1.2之前的版本里，默认配置是打开动态脚本功能的，因此用户可以直接通过http请求，执行任意代码。[/][]其实官方是清楚这个漏洞的，在文档里有说明：[/][]First, you should not run Elasticsearch as the root user, as this would allow a script to access or do anything on your server, without limitations. Second, you should not expose Elasticsearch directly to users, but instead have a proxy application inbetween.            [/]

           终于找到原因，那就解决吧

解决方案：

           法一：手动关闭ES远程执行脚本的功能，即在每一个ES节点的配置文件elasticsearch.yml中添加如下一行即可

script.disable_dynamic: true

           然后重启ES即可.           法二：升级ES至1.2版本以上也可，因为在ES1.2版本中已默认关闭了远程执行脚本的功能，但需考虑与Logstash的兼容性问题

后续：

[list=1][]根据官方的资料，为了保证ES的安全性，不可以root身份启动ES，且可考虑使用代理(负载均衡器也可)，对外开放非9200端口（如9300），转发至内网的9200端口，可有效防止小人们的恶意端口扫描；[/][]因为已经被挂马了一次，所以在重新启用ES之前，还需全面检查被入侵的主机是否还有其它隐患，这就涉及web安全扫描的内容了，暂时小白，还未了解，故希望有经验的前辈可以多多请教！[/]
           最近我也遇到了这个问题，然后搜索发现这篇文章不错，然后就想分享给大家，希望大家可以避免踩坑！
原文地址 收起阅读 »

先吐槽下qq群的调查功能，先后搞了2次调查，都没有了，数据消失了。难道qq调查的理念是，玩“闪调”，调查完就消失？

说下调查结果
OpenStack

从调查结果看，OpenStack无疑是王者，前几天刚过了5岁生日，已经5岁了，但是还没有成熟，依旧活力四射。有人说OpenStack就是一个框架，一个协议族，就像网络的TCP/IP模型，真正要实施还要靠自己。

大家形成的共识是，玩OpenStack没有一定规模的开发团队搞不定，对中小型企业来说，要使用OpenStack，买一个有支持的发行版也是一个思路。

OpenStack 评级 持有 还会继续升值
 
Cloudstack OpenNebula

Cloudstack OpenNebula 这一年来，明显社区活跃度在下降，尤其是思杰投入到OpenStack阵营，更是对Cloudstack的打击，如果一直在使用这两个平台，可以继续使用，如果没有使用过，这两个平台建议就不要选择了。

Cloudstack OpenNebula 评级 出售 升值空间已经不大了
 
oVirt/RHEV

oVirt/RHEV 更适合中小型企业使用，设计目标也是中小型企业的管理工具，从个人测试的结果看，也是大问题没有，小问题不断，而且更新频繁，经常造成安装都是问题，要稳定使用还需要打磨。

oVirt/RHEV 评级 持有 还会继续升值
 
ZStack

ZStack 是国人开发的开源管理软件，脱胎于Cloudstack，许多理念和Cloudstack一样，但是比Cloudstack部署、使用方便很多，现在版本迭代非常快，很快要推出中文版了。

ZStack 评级 关注 还会继续升值，建议考虑在1.0的时候买入
 
WebVirtMgr

WebVirtMgr 是一个纯Python写的管理工具，前端和后端都是Python，是Python用户者的最爱，许多Python爱好者都对WebVirtMgr做了二次定制，目前主要的问题是功能太少。

WebVirtMgr 评级 关注 又可能继续升值，建议考虑在成熟的时候买入
 
Virtsh+VirtManager

Virtsh+VirtManager 是老牌绩优股，是每个人必备的工具，这个就不多说了。

Virtsh+VirtManager 评级 持有 长期稳定升值
 
自己研发

自己研发也是一个思路，底层的Libvirt已经非常完善了，完全可以在这个基础上，根据自己需求，开发一个非常简单的，适合自己的平台就ok。

自己研发 评级 持有 会持续升值
 
热爱虚拟化技术的同学，可以扫描二维码，订阅哦！

原文地址 收起阅读 »

因为ES是java语言编写的程序，所以安装Elasticsearch唯一的要求是安装官方新版的Java下载地址
64位系统java安装脚本如下:

#!/usr/bin/env bash



java_install () {

rpm -qa | grep -i JDK;if [ $? -eq 0 ];then rpm -qa | grep -i JDK | xargs -n 1 -t rpm -e --nodeps;fi

os=$(uname -m)



if [ $os == "x86_64" ];then        

   cd /usr/local/src/

   wget -c http://118.186.221.78:8080/jdk-7u51-linux-x64.gz    (ip地址不是有效的，你换成你jdk下载地址就好)

   tar zxf jdk-7u51-linux-x64.gz -C /usr/local/



   sed -i 's@jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024@#jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024@g' /usr/local/jdk1.7.0_51/jre/lib/security/java.security

   ls /usr/bin/java* > /dev/null 2>&1;

   

   if [ $? -eq 0 ];then 

        ls /usr/bin/java*  | xargs -n 1 -t rm -rf

   else

        ln -s /usr/local/jdk1.7.0_51/bin/java /usr/bin/java

        ln -s /usr/local/jdk1.7.0_51/bin/javac /usr/bin/javac

        ln -s /usr/local/jdk1.7.0_51/bin/javadoc /usr/bin/javadoc

        ln -s /usr/local/jdk1.7.0_51/bin/javaws /usr/bin/javaws

   fi



   cd /usr/local/jdk1.7.0_51/

   echo "export JAVA_HOME=/usr/local/jdk1.7.0_51/" >> /root/.bashrc

   source /root/.bashrc

   echo "export PATH=$JAVA_HOME/bin:$PATH" >> /root/.bashrc

   echo "export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar" >> /root/.bashrc

   source /root/.bashrc

   echo "export JAVA_HOME=/usr/local/jdk1.7.0_51/" >> /etc/rc.local

fi



}

java_install

安装开始
你可以从 Downloads | Elasticsearch下载最新版本的Elasticsearch,进行安装：

curl -L -O “http://download.elasticsearch.org/PATH/TO/VERSION.zip”

unzip elasticsearch-$VERSION.zip

cd  elasticsearch-$VERSION

从 Downloads | Elasticsearch 获得最新可用的版本号并填入URL中

在生产环境安装时，除了以上方法，你还可以使用Debian或者RPM安装包，地址在这里:downloads page,或者也可以使用官方提供的Puppet module或者Chef cookbook。

安装Marvel
Marvel是Elasticsearch的管理和监控工具，在开发环境下免费使用。它包含了一个叫做Sense的交互式控制台，使用户方便的通过浏览器直接与Elasticsearch进行交互。
 
Elasticsearch线上文档中的很多示例代码都附带一个View in Sense的链接。点击进去，就会在Sense控制台打开相应的实例。安装Marvel不是必须的，但是它可以通过在你本地Elasticsearch集群中运行示例代码而增加与此书的互动性。
Marvel是一个插件，可在Elasticsearch目录中运行以下命令来下载和安装：

./bin/plugin -i elasticsearch/marvel/latest

你可能想要禁用监控，你可以通过以下命令关闭Marvel：

echo 'marvel.agent.enabled: false' >> ./config/elasticsearch.yml

运行Elasticsearch
Elasticsearch已经准备就绪，执行以下命令可在前台启动：

./bin/elasticsearch

如果想在后台以守护进程模式运行，添加-d参数。
 
打开另一个终端进行测试：

curl 'http://localhost:9200/?pretty'

你能看到以下返回信息：

{

   "status": 200,                           //状态码

   "name": "Shrunken Bones",                //默认集群名称

   "version": {

      "number": "1.4.0",                    //ES版本号

      "lucene_version": "4.10"              //lucene版本号

   },

   "tagline": "You Know, for Search"

}

这说明你的ELasticsearch集群已经启动并且正常运行，接下来我们可以开始各种实验了。
 
集群和节点

[b]节点(node)[/b]是一个运行着的Elasticsearch实例。[b]集群(cluster)[/b]是一组具有相同cluster.name的节点集合，他们协同工作，共享数据并提供故障转移和扩展功能，当然一个节点也可以组成一个集群。



你最好找一个合适的名字来替代cluster.name的默认值，比如你自己的名字，这样可以防止一个新启动的节点加入到相同网络中的另一个同名的集群中。



你可以通过修改config/目录下的elasticsearch.yml文件，然后重启ELasticsearch来做到这一点。当Elasticsearch在前台运行，可以使用Ctrl-C快捷键终止，或者你可以调用shutdown API来关闭：

查看Marvel和Sense
如果你安装了Marvel（作为管理和监控的工具），就可以在浏览器里通过以下地址访问它：
http://localhost:9200/_plugin/marvel/

你可以在Marvel中通过点击dashboards，在下拉菜单中访问Sense开发者控制台，或者直接访问以下地址：
http://localhost:9200/_plugin/marvel/sense/ 收起阅读 »

Elasticsearch是一个基于Apache Lucene(TM)的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。
 
但是，Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。
 
Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。
 
不过，Elasticsearch不仅仅是Lucene和全文搜索，我们还能这样去描述它：

[]分布式的实时文件存储，每个字段都被索引并可被搜索[/]
[]分布式的实时分析搜索引擎[/]
[]可以扩展到上百台服务器，处理PB级结构化或非结构化数据[/]

而且，所有的这些功能被集成到一个服务里面，你的应用可以通过简单的RESTful API、各种语言的客户端甚至命令行与之交互。
 
上手Elasticsearch非常容易。它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。安装即可使用，只需很少的学习既可在生产环境中使用。
 
Elasticsearch在Apache 2 license下许可使用，可以免费下载、使用和修改。
 
随着你对Elasticsearch的理解加深，你可以根据不同的问题领域定制Elasticsearch的高级特性，这一切都是可配置的，并且配置非常灵活。
 
ES诞生模糊记忆：
多年前，一个叫做Shay Banon的刚结婚不久的失业开发者，由于妻子要去伦敦学习厨师，他便跟着也去了。在他找工作的过程中，为了给妻子构建一个食谱的搜索引擎，他开始构建一个早期版本的Lucene。

直接基于Lucene工作会比较困难，所以Shay开始抽象Lucene代码以便Java程序员可以在应用中添加搜索功能。他发布了他的第一个开源项目，叫做“Compass”。

后来Shay找到一份工作，这份工作处在高性能和内存数据网格的分布式环境中，因此高性能的、实时的、分布式的搜索引擎也是理所当然需要的。然后他决定重写Compass库使其成为一个独立的服务叫做Elasticsearch。

第一个公开版本出现在2010年2月，在那之后Elasticsearch已经成为Github上最受欢迎的项目之一，代码贡献者超过300人。一家主营Elasticsearch的公司就此成立，他们一边提供商业支持一边开发新功能，不过Elasticsearch将永远开源且对所有人可用。

Shay的妻子依旧等待着她的食谱搜索…… 收起阅读 »

内网断电后，有一台机器没有如往常一样起来，该服务器是docke上的一个容器，然后登录docker宿主机，开始问题分析及解决：

 

一、寻找问题

1、启动iframe-test机器

root@ubuntu:~#docker start iframe-test

iframe-test

2、发现没有容器进程

root@ubuntu:~#docker ps |grep iframe-test

3、查看日志，发现是nginx配置有问题，导致中断。

root@ubuntu:~# docker logs iframe-test



Startingnginx: Starting periodic command scheduler: cron.

nginx:[emerg] unexpected end of file, expecting ";" or "}" in/etc/nginx/nginx.conf:21

nginx:configuration file /etc/nginx/nginx.conf test failed

二、思考解决方法

问题原因找到，就是nginx文件检测不通过，导致中断。

解决思路暂有两个：

   方法一：把这个问题容器用docker commit提交到一个新的镜像，然后用docker run -i -d基于新镜像运行一个临时终端进去改变配置文件，然后把临时终端的id提交到一个新的镜像，然后在基于新的镜像重新启动容器。（这个方法步骤多，而且提交了新的镜像，对于后续维护增加了复杂性）

   方法二：直接改变容器里的配置文件，不需要新提交镜像。

三、修改宕机容器配置

所有的容器数据都存在/var/lib/docker/aufs/diff/路径下。下面容器ID目录，以init结尾的是放配置文件的，有/etc/host、reselv.conf，/dev等。另一个是放的文件目录，比如/home，/var/及自己安装的服务等等，aufs需要内核3.10以上的支持。

1、查看容器id

root@ubuntu:~#docker ps -a|grep iframe-test

fa02f8084b63        debian06-base:latest  

2、查找nginx.conf配置文件路径

root@ubuntu:~#find / -name 'nginx.conf'

/root/nginx.conf

/var/lib/docker/aufs/diff/7c7b3438586e0653cdca7977a4f889cfdca300f008771462f8a2e6e9d3bc5b84/etc/nginx/nginx.conf

/var/lib/docker/aufs/diff/6bc6a9a5aeb59e19cae8bb78daa481cc465051069c7854528cbfdb3c9c1f2bfb/etc/nginx/nginx.conf

/var/lib/docker/aufs/diff/c7b6b87cfda72701229eebca868eb047aa01c255b62e56ad223dc75396c584e4/etc/nginx/nginx.conf

/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456/etc/nginx/nginx.conf

3、进入对应容器id的目录，修改问题文件

root@ubuntu:cd /var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456

执行ls命令，容器的根目录展现在面前，是不是很熟悉？

root@ubuntu:/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456#ls

etc  root run  srv  tmp usr  var

接下来找到这个容器里面nginx.conf的语法错误处修改。

4、修改后启动容器

root@ubuntu:~# docker start iframe-test



root@ubuntu:~# docker ps |grep iframe-test

fa02f8084b63        debian06-base:latest        "/etc/rc.local"     6 weeks ago         Up 13 minutes       10.18.103.2:22->22/tcp,10.18.103.2:80->80/tcp, 10.18.103.2:443->443/tcp,10.18.103.2:3306->3306/tcp, 10.18.103.2:6379->6379/tcp,10.18.103.2:6381->6381/tcp, 10.18.103.2:8000->8000/tcp,10.18.103.2:8888->8888/tcp                                                                                                                                 

iframe-test 

容器启动成功，问题解决。 收起阅读 »

如果你对 Docker 不熟悉的话，简单来说，Docker 是一个轻量级的应用容器。和常见的虚拟机类似，但是和虚拟机相比，资源消耗更低。并且，使用和 GitHub 类似的被 commit 的容器，非常容易就能实现容器内指定运行环境中的应用打包和部署。

问题

如果你有服务器上一个普通用户的账号，如果这个用户被加入了 docker 用户组，那么你很容易就能获得宿主机的 root 权限。

黑魔法：
docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

输出如下：

johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

[...]

You should now have a root shell on the host OS

Press Ctrl-D to exit the docker instance / shell

# whoami

root #此处是容器内部，但是容器已经 chroot /hostOS，所以相当于直接获取了宿主机的 root 权限。

译者一直以为是 Ctrl-D 之后，宿主机的 shell 变成 root，实际上不是。
咨询了作者 Chris Foster 得知，是在容器内获得宿主机的 root 权限。
是不是想起了以前译者在 Docker 安全 中提到的容器内部的 UID=0 对容器外部某个不明程序执行了 chmod +s？

解释

当然，所有的解释汇成一句话，应该就是：docker 组内用户执行命令的时候会自动在所有命令前添加 sudo。因为设计或者其他的原因，Docker 给予所有 docker 组的用户相当大的权力（虽然权力只体现在能访问 /var/run/docker.sock 上面）。

默认情况下，Docker 软件包是会默认添加一个 docker 用户组的。Docker 守护进程会允许 root 用户和 docker 组用户访问 Docker。给用户提供 Docker 权限和给用户无需认证便可以随便获取的 root 权限差别不大。

解决方案

对于 Docker 来说可能很难修复，因为涉及到他们的架构问题，所以需要重写非常多的关键代码才能避免这个问题。我个人的建议是不要使用 docker 用户组。当然，Docker 官方文档中最好也很清楚地写明这一点。不要让新人不懂得“和 root 权限差别不大”是什么意思。

Docker 官方也意识到了这个问题，尽管他们并没有很明显地表明想去修复它。在他们的安全文档中，他们也的确表示 docker 用户组的权限和 root 权限差别不大，并且敬告用户慎重使用。

漏洞详情

上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease，主要的作用是：从 Docker Hub 上面下载我的镜像，然后运行。参数-v将容器外部的目录/挂载到容器内部 /hostOS，并且使用 -i 和 -t 参数进入容器的 shell。

这个容器的启动脚本是 exploit.sh，主要内容是：chroot 到容器的 /hostOS （也就是宿主机的 /），然后获取到宿主机的 root 权限。

当然可以从这个衍生出非常多的提权方法，但是这个方法是最直接的。

本文中所提到的代码托管在 Github（https://github.com/chrisfosterelli/dockerrootplease），镜像在 Docker Hub（https://registry.hub.docker.com/u/chrisfosterelli/rootplease/）。

翻译原文链接：https://henduan.com/xXoHn

收起阅读 »

Docker插件(插件来自master,运行 stable/icehouse)无法删除失败的容器。鉴于以下资源:

docker_dbserver:

    type: "DockerInc::Docker::Container"

    properties:

      image: mysql

      port_specs:

        - 3306

      port_bindings:

        3306: 3306

      env:

        - MYSQL_ROOT_PASSWORD=secret

      name: dbserver

如果一个容器命名为"dbserver"已经存在，则创建失败：

409 Client Error: Conflict ("Conflict, The name dbserver is already assigned to ff7791c42f29. You have to delete (or rename) that container to be able to assign dbserver to a container again.")

这迫使容器变成CREATE_FAILED状态:

$ heat resource-list local

  +-----------------+------------------------------+-----------------+----------------------+

  | resource_name | resource_type | resource_status | updated_time |

  +-----------------+------------------------------+-----------------+----------------------+

  | docker_dbserver | DockerInc::Docker::Container | CREATE_FAILED | 2014-09-01T13:49:58Z |

  +-----------------+------------------------------+-----------------+----------------------+

试图删除该堆栈将导致一个新的错误:

APIError: 404 Client Error: Not Found ("No such container: None")

此时,唯一的选择就是"heat stack-abandon". 收起阅读 »