yeasy的专栏

Docker是个好东西欢迎提交bug和修改的pull request。

背景Magnum 项目是 2014 年 11 月加入 OpenStack 的年轻项目，由 Rackspace主导发起，其定位是提供容器即服务（Container as a Service）的 API 框架，计划在 2015 年 10 月推出的 Liberty 版本时成熟。我们知道，目前 OpenStack 中 Nova 项目已经通过 nova-docker 的形式支持了 Docke

Docker registry 工具现在已经很好的支持了 mirror 功能，使用它可以配置一个本地的 mirror 服务，将 pull 过的镜像 cache 在本地，这样其它主机再次 pull 的时候会极大提高响应速度。使用 docker-compose 启动 registry mirror 服务以 ubuntu 为例，首先要安装 docker 和 docker-compose。

在互联网应用领域，服务的动态性需求十分常见，这就对服务的自动发现和可动态扩展提出了很高的要求。Docker 的出现，以及微服务架构的兴起，让众多开源项目开始关注在松耦合的架构前提下，如何基于 Docker 实现一套真正可动态扩展的服务架构。基本需求基本的需求包括：服务启动后要能自动被发现（vs 传统需要手动进行注册）；负载要能动态在可用的服务实例上进行均衡（vs 传

而 elasticsearch 可以很好的支持各种语言的全文检索，但我们暂时又不想切换到 elasticsearch 作为后端数据库。当然，可以在 web 应用中存储数据的时候，再主动写一份到 elasticsearch，但这无疑污染了原有的业务逻辑。在 IT 行业，只要有需求的地方，必然早已有了一堆好用或者不好用的开源轮子。幸运地是，现在已经有了一些转换方案，可以将 mo

简介Spark 是 Berkeley 开发的分布式计算的框架，相对于 Hadoop 来说，Spark 可以缓存中间结果到内存而提高某些需要迭代的计算场景的效率，目前收到广泛关注。熟悉 Hadoop 的同学也不必担心，Spark 很多设计理念和用法都跟 Hadoop 保持一致和相似，并且在使用上完全兼容 HDFS。但是 Spark 的安装并不容易，依赖包括 Java、Scala、HD

Pod首先，Kubernetes 中的基本单元是 Pod，而非 Docker 容器。Pod 是一组共享了下面资源的容器： 进程命名空间 网络命名空间 IPC 命名空间 UTS 命名空间简单的讲，一个 Pod 是一个小型的“虚拟机”，里面运行若干个不同的进程，每个进程实际上就是一个容器。Kubernetes 要干的事情是要把这些 Pod 给互相连接起来，是不是联想到了

简介ELK 套装包括 ElasticSearch、LogStash 和 Kibana。 其中，ElasticSearch 是一个数据搜索引擎（基于 Apache Lucene）+分布式 NoSQL 数据库；LogStash 是一个消息采集转换器，类似 Syslog，可以接收包括日志消息在内的多种数据格式，然后进行格式转换，发送给后端继续处理；Kibana 是一个 Web 前段，带有强大

注：本文是某次技术分享的内容草稿，内容可能跟最终发布版本略有调整。背景群里已经不少文章讨论使用容器技术的宝贵经验。今天我主要讨论 OpenStack 这样一个 IaaS 平台，聊聊它面对容器技术，特别是 Docker 所出现的一些新的项目和进展。可能有人觉得，现在容器云这么热，OpenStack 这样的传统 IaaS 平台是不是有点过时了？目前新

容器技术的快速发展，挤占了传统虚拟机技术的很多地盘。没办法，在启动速度和运行性能上，容器实在有着太多的优势，而虚拟机技术的发展实在太过缓慢。现在，受到容器技术的刺激，，推出了启动速度可以跟容器媲美的下一代虚拟化技术 -- hyper。简介简单的说，hyper = Hypervisor + Kernel + Docker Image，本质上还是一种虚拟机技术。hype

容器技术最近很火，各家项目纷纷提出自己的支持方案，比如 OpenStack、CF、Mesos，以及一堆本身就基于容器的平台方案，更是跟容器技术脱不开关系。这也直接导致了暧昧已久的 IaaS 和 PaaS 开始正面的跨界冲突。在 IaaS 看来，做 PaaS 无非就是提供几个应用模板嘛，原来虚机不好做，现在用 Docker，瞬间给你把服务整起来。更别提还有最近出来搅局的 hyper，

Docker 默认使用的是 Linux 自带的网桥实现，实际上，OpenvSwitch 项目作为一个成熟的虚拟交换机实现，具备更丰富的功能。个人认为，将来 Docker 必然会选择 OpenvSwitch 作为其默认网桥实现。有兴趣的同学欢迎通过如下的步骤来尝鲜。环境在 Ubuntu 14.04 系统中进行测试。操作流程也适用于 RedHat/CentOS 系列系统，但少数命令和配

基本语法docker [OPTIONS] COMMAND [arg...]选项-D=true|false 使用debug模式。默认为false。-H, --host=[unix:///var/run/docker.sock]: tcp://[host:port]来绑定或者unix://[/path/to/socket]来使用。 在daemon模式下绑定的socket

现在讨论Docker安全性的话题颇多，主要集中在对使用容器方式的隔离性、攻击防护性等方面。往往与虚拟机方式进行比较。首先，从安全性上看，Docker容器的安全性比不上虚拟机，这点是毋庸置疑的。容器内的应用可以直接访问到主机系统内核；而虚拟机中的应用首先要访问到虚拟机的操作系统，然后在经过hypervisor层才能访问到外部的系统。而且，虚拟机方式在生产环境中经过诸多检验，更加成熟一

指令的一般格式为INSTRUCTION arguments，指令包括FROM、MAINTAINER、RUN等。FROM格式为FROM 或FROM :。第一条指令必须为FROM指令。并且，如果在同一个Dockerfile中创建多个镜像时，可以使用多个FROM指令（每个镜像一次）。MAINTAINER格式为MAINTAINER ，指定维护者信息。RUN格式为RUN 或RUN

Docker支持采用仓库（本处指的是registry）来支持镜像的分发和更新管理。这极大的便利了用户。官方提供了dockerhub网站来作为一个公开的集中仓库。然而，本地访问dockerhub速度往往很慢，并且很多时候我们需要一个本地的私有仓库只供网内使用。关于如何创建和使用本地仓库，其实已经有很多文章介绍了。但是这些文章要么内容已经过时，要么给出了错误的配置，导致无法正常创建仓库。

Docker 1.3 发布Docker 1.3 已经正式发布，新的特性包括镜像签名、进程注入、新的创建和运行容器命令、安全选项和 Mac OS 上进行目录共享。特别是针对安全方面的改进，成为本地发布的亮点。镜像签名支持对镜像的发布者和镜像文件进行验证。进程注入除了通过 nsinit 和 nsenter 的方式查看容器内应用之外，可以使用更方便的 docker e

Docker 的镜像管理设计中大量借鉴了 Git 的理念。下面这张图将对两者的核心概念和操作进行比较，有助于大家快速掌握管理 Docker 镜像的正确方式。

Docker 大热之后，不少公司都试图搞清楚 Docker 能给自己的业务带来什么好处，有些团队甚至一股脑地把东西都往容器里面塞。其实，技术领域不存在能一劳永逸的“银弹”，要正确的使用 Docker 容器技术才能给自己带来好处，否则可能带来难以预料的后果。下面四条基本原则，在选择容器技术，而不是裸应用或者虚拟机的时候都应该先认真衡量下。1、是否需要支持分发。Do

熟悉 Linux 技术的人都知道，容器只是利用名字空间进行隔离的进程而已，Docker 在容器实现上也是利用了 Linux 自身的技术。有时候，我们需要在宿主机上对容器内进行一些操作，当然，这种绕过 Docker 的操作方式并不推荐。如果你使用的是比较新的 Docker 版本，会尴尬的发现，直接使用系统命令，会无法访问到容器名字空间。这里，首先介绍下 ip netns 系列

Docker 1.12 在 2016 年 7 月 28 日正式 GA，除了大量的在使用上的改进和 bug 修复外，最引人瞩目的是原生支持了 Swarm 模式。熟悉 Docker 的读者都知道 Docker Swarm 是官方三剑客之一，提供了轻量级容器云的支持，以性能卓越出名，跟 K8s 面向应用的较为复杂的容器云方案一时瑜亮，各有千秋。本次 Swarm 模式特性的发布可谓重要变革