基于容器的部署

首先我们的问题是：产品包含了大量的服务，并且服务之间存在复杂的依赖关系，以拓扑的形式运行并相互协作，部署的时候需要手动解决整体的依赖，配制通信的协议和地址，重新部署新环境复杂度非常高。因此，我们希望有一种容器技术可以让我们构建产品所需要的所有的服务能够迅速快捷的重新部署，并且可以根据需求横向的扩展，且保证高可用性，在出现问题的时候可以自动重启或者启动备份服务。

目前有多种解决方案，考虑我们有私有云，亚马逊云以及物理机的几种部署方式，所以Docker作为解决方案的基础，在其之上选择合适的容器拓扑管理工具就成了主要任务，常见的解决方案有：

多种解决方案中我们优先选择官方提供的工具，一般来说官方提供的工具跟自己的原生服务结合的更好，也具有更长远的规划，在官方工具确实不足的情况下辅助以第三方的工具，因此初步我们决定采用Docker原生的工具Machine+Swarm+Compose辅助以Mesos来实现整个工程的部署，其中Swarm负责某一功能模块小规模的容器分配调度，Mesos负责整个集群最外层大规模容器资源调度，可以说以Mesos为主，Swarm为辅助，因为Mesos是比较成熟的资源管理框架，也有非常适合的调度引擎，Swarm还相对初步随着时间演进，也许会接管更多的调度。

简单介绍下Docker官方原生的工具：

关于Docker网络解决方案的争论比较多了，CoreOS和Kubernetes都有自己的解决方案，前两者都是比较通用的PAAS工具，作为通用性的服务编排工具容器的具体实现可以是多种，Docker只是其中之一，而Docker libnetwork的解决方案过于底层，不适合作为通用的插件集成到Kubernetes或者CoreOS中，因此这两家都有自己CNI类型的解决方案，对于使用者来说我们不那么关心到底这个工具支持多少种容器，只需要知道Docker这种容器能够满足当前产品部署的需求就好，因此我们仍然以Docker的工具为主，尽管不那么通用，但是能够解决我们目前服务编排的问题。

官方的工具看起来很美好，解决方案也足够优雅和简洁，问题就是成熟程度，compose和swarm的结合仍然是在试验阶段，对于处于不同host的container，进行link仍然需要手动对整个Swarm集群设置网络，对于大规模或者复杂拓扑的部署工作量不小，因此我们借助于Mesos来做第一级的资源或者容器管理，其中第二级或者说小规模容器部署是可以在swarm中实现。

Mesos作为资深的资源管理平台，在Docker出现之前就已经被广泛利用了，基本上所有的主从类型的分布式计算框架都支持使用Mesos来做基本的资源分配调度，比如hadoop, storm，spark等等，同时Mesos的设计也可允许长时间运行的application， 不管是batch job, stream job还是普通的应用服务都可以接入Mesos来申请资源启动自身的容器。早期Mesos只支持LXC形式的资源限制，在Docker崛起之后Mesos也开始支持直接使用Docker容器来运行具体的计算框架，可以说二者既有竞争又相辅相成。说竞争是因为目前Docker自己的工具已经慢慢的可以替代一部分Mesos的应用场景了，只要机器上安装了Docker engine就可以无差别的管理所有主机，比如Swarm就可以组建简单的服务集群，管理容器在集群中的运行，同时也能够利用Machine来进行远程管理，说相辅是因为Swarm的设计是可以替换具体的调度后端的，默认情况使用自己的调度器在服务发现的基础上选择一个host来启动容器，通过配置可以选择Mesos作为其调度后端，将Swarm 作为跟Spark同等的Compute Framework来运行，这样Swarm就能够使用Mesos更加成熟和灵活的调度机制来管理容器，在此之上Compose就可以把编排好的服务运行在Mesos集群，可见Mesos和Docker结合的生态系统在当前阶段是比较和谐的。

这样，最终我们的解决方案就基本确定了，Mesos作为最基础的集群资源管理或者调度工具运行在所有的服务器上，Spark等计算框架不再独立部署，而是使用Mesos最初的LXC容器来运行，Swarm使用Docker容器通过Mesos来调度，Compose文件用来启动结合比较紧密服务堆栈，比如Tachyon集群，我们自己所开发的应用服务以及ACO集群也作为一个Docker服务堆栈在Swarm上运行。所以我们的Mesos集群上目前运行两种计算框架，Spark和Swarm，负责我们的应用和分布式计算的部署，具体的应用和服务编排都是在Compose中完成，个别复杂的应用需要手动去处理关联关系，依然是以Docker的形式运行在Mesos中。

Mesos可以把我们的机器聚合在一起作为一个机器来使用，不管是我们的应用还是分布式计算的任务，都直接提交给Mesos来进行调度，减少了对服务器的垂直划分，不存在Spark的集群， Hadoop的集群等概念，Spark或者Hadoop的job直接在Mesos的slave中分配资源并运行各自job相关的Executor, 运行结束后释放资源，就像Spark没有存在过一样， 因此从更高的角度看Mesos的Framework其实就是一个调度器加一个运行时的处理流程，不用再需要Spark或者Storm等框架的Standalone 模式自己来处理调度，只需要使用Mesos的API，实现自己的scheduler和具体启动停止运行过程的Executor就好， 而对于我们自己的应用如果要作为Framework存在也需要实现对应的Scheduler和Executor， 不过可以利用现成的比较好的调度器比如Marathon来托管我们的应用，减少开发Framework的工作量。使用Mesos这样的好处是资源的利用率更高， 因此我们在也不需要除了Mesos之外的long running 集群， 即使有Long running的服务，也是在Mesos分配好的容器内运行。

Framework = Scheduler + Executor

Mesos的安装过程稍微有点服务，虽然Docker镜像可以减少Mesos的部署复杂度，但是这样就存在了两层容器， Mesos在Docker 容器中运行，而Mesos里边的任务也是在自己的Docker容器里运行，如果有些长时间运行的任务需要暴露出端口跟外界交互，就需要先Expose port到Mesos slave级别的容器， 然后再Expose到最外层的物理机，复杂度增加且对性能有损耗，因此我们最终还是倾向于在物理机上部署Mesos， 只保留一层Docker容器不推荐嵌套，而且有了Mesosphere的DCOS系统，在AWS上部署Mesos就比较简单了。

Mesos看起来很完美，那我们为什么还需要Docker容器呢， 直接使用LXC标准Linux kernel支持的容器不就可以了，在这个解决方案中我们期望所有运行的应用或者分布式计算框架的任务的Executor都是在Docker容器中运行，也是因为Docker杀手级的功能，一个Docker容器就像一个集装箱，里边包含了需要运行一个服务或者任务的所有的依赖条件或者配置，都可以根据需求自身灵活的修改，并且一次装箱随处运行，不用关心外在环境，举个例子假如直接使用LXC来运行Spark的某个任务的Executor，需要提供Spark jar包的地址，相关的配置集成到ExecutorInfo中才能运行，而如果使用Docker container就简单很多，Spark executor运行需要的信息都在某个Docker image中，Mesos slave只要调用Docker client启动某个镜像就足以运行一个Framework的某个任务，任务的执行在Docker 容器中。对于我们自己开发的各种服务同理也是组织成镜像最终在Docker容器中运行， Scheduler依赖Marathon就可以。

现在有很多线上的接口测试工具，但是都是公网环境的。在很多情况下，公司内部需要在内网环境下有自己的接口测试工具，目的是为了保证数据安全，或者一些定制化的功能。本文介绍如何本地化部署接口测试工具DOClever。

使用docker安装比较麻烦的地方在于需要去指定你的mongodb的地址，所以推荐采用docker-compose去安装DOClever，如果还未安装docker-compose，可以看我另一篇文章 《使用国内镜像安装Docker-compose》

并添加如下配置

配置项介绍：

而本文的配置是把该容器内部运行的10000端口给映射到了服务器的20080端口，这样我们启动以后直接输入： 你的服务器ip:20080 就可跑起来。

保存以上配置并退出。

在doclever目录下输入如下命令后回车：

访问成功浏览器页面：

至此我们本地的DOClever就创建成功了

模板文件是使用 Compose 的核心，涉及到的指令关键字也比较多。大部分指令跟 docker run 相关参数的含义都是类似的。

默认的模板文件名称为 docker-composeyml ，格式为 YAML 格式。

可以将 Compose 文件命名为任何所需内容，以使其在逻辑上具有意义； docker-composeyml 仅为标准名称。我们可以简单地将此文件命名为 docker-stackyml 或更特定于项目的内容

注意每个服务都必须通过 image 指令指定镜像或 build 指令（需要 Dockerfile ）等来自动构建生成镜像。

在 docker stack 下， build 指令不能使用，只能用 image

如果使用 build 指令，在 Dockerfile 中设置的选项(例如： CMD , EXPOSE , VOLUME , ENV 等) 将会自动被获取，无需在 docker-composeyml 中再次设置。

请注意，将 Compose 文件设置为 version:"3" 。本质上，这会使其兼容 swarm mode 。我们可以使用 deploy key （仅可用于 Compose 文件格式版本 3x 及更高版本）及其子选项对每项服务（例如，web）进行负载均衡和优化性能。我们可以使用 docker stack deploy 命令（仅在 Compose 文件版本 3x 及更高版本上受支持）运行此文件。您可以使用 docker-compose up 运行具有 非 swarm 配置的版本 3 文件。

指定 Dockerfile 所在文件夹的路径（可以是绝对路径，或者相对 docker-composeyml 文件的路径）。 Compose 将会利用它自动构建这个镜像，然后使用这个镜像。

也可以使用 context 指令指定 Dockerfile 所在文件夹的路径。

使用 dockerfile 指令指定 Dockerfile 文件名。

使用 arg 指令指定构建镜像时的变量。

使用 cache_from 指定构建镜像的缓存

指定容器的内核能力（capacity）分配。

让容器拥有所有能力可以指定为：

去掉 NET_ADMIN 能力可以指定为：

覆盖容器启动后默认执行的命令。

仅用于 Swarm mode

指定父 cgroup 组，意味着将继承该组的资源限制。

例如，创建了一个 cgroup 组名称为 cgroups_1。

指定容器名称。默认将会使用 项目名称_服务名称_序号 这样的格式。

仅用于 Swarm mode

指定设备映射关系。

解决容器的依赖、启动先后的问题。以下例子中会先启动 redis``db 再启动 web

自定义 DNS 服务器。可以是一个值，也可以是一个列表。

配置 DNS 搜索域。可以是一个值，也可以是一个列表。

挂载一个 tmpfs 文件系统到容器。

从文件中获取环境变量，可以为单独的文件路径或列表。

如果通过 docker-compose -f FILE 方式来指定 Compose 模板文件，则 env_file 中变量的路径会基于模板文件路径。

如果有变量名称与 environment 指令冲突，则按照惯例，以后者为准。

环境变量文件中每一行必须符合格式，支持 # 开头的注释行。

设置环境变量。你可以使用数组或字典两种格式。

只给定名称的变量会自动获取运行 Compose 主机上对应变量的值，可以用来防止泄露不必要的数据。

如果变量名称或者值中用到 true|false ， yes|no 等表达 布尔 含义的词汇，最好放到引号里，避免 YAML 自动解析某些内容为对应的布尔语义。这些特定词汇，包括

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

暴露端口，但不映射到宿主机，只被连接的服务访问。

仅可以指定内部端口为参数

类似 Docker 中的 --add-host 参数，指定额外的 host 名称映射信息。

会在启动后的服务容器中 /etc/hosts 文件中添加如下两条条目。

通过命令检查容器是否健康运行。

指定为 镜像名称或镜像 ID 。如果镜像在本地不存在， Compose 将会尝试拉取这个镜像。

为容器添加 Docker 元数据（metadata）信息。例如可以为容器添加辅助说明信息。

配置日志选项。

目前支持三种日志驱动类型:

options 配置日志驱动的相关参数:

设置网络模式。使用和 docker run 的 --network 参数一样的值。

配置容器连接的网络。

跟主机系统共享进程命名空间。打开该选项的容器之间，以及容器和宿主机系统之间可以通过 进程ID 来相互访问和操作。

暴露端口信息。

使用宿主端口：容器端口 (HOST:CONTAINER) 格式，或者仅仅指定容器的端口（宿主将会随机选择端口）都可以。

存储敏感数据，例如 mysql 服务密码。

指定容器模板标签（label）机制的默认属性（用户、角色、类型、级别等）。例如配置标签的用户名和角色名。

设置另一个信号来停止容器。在默认情况下使用的是 SIGTERM 停止容器。

配置容器内核参数。

指定容器的 ulimits 限制值。

例如，指定最大进程数为 65535，指定文件句柄数为 20000（软限制，应用可以随时修改，不能超过硬限制） 和 40000（系统硬限制，只能 root 用户提高）。

数据卷所挂载路径设置。可以设置宿主机路径 （HOST:CONTAINER） 或加上访问模式 （HOST:CONTAINER:ro） 。

该指令中路径支持相对路径。

此外，还有包括 domainname , entrypoint , hostname , ipc , mac_address , privileged , read_only , shm_size , restart , stdin_open , tty , user , working_dir 等指令，基本跟 docker run 中对应参数的功能一致。

指定服务容器启动后执行的入口文件。

指定容器中运行应用的用户名。

指定容器中工作目录。

指定容器中搜索域名、主机名、mac 地址等。

允许容器中运行一些特权命令。

指定容器退出后的重启策略为始终重启。该命令对保持服务始终运行十分有效，在生产环境中推荐配置为 always 或者 unless-stopped 。

以只读模式挂载容器的 root 文件系统，意味着不能对容器内容进行修改。

打开标准输入，可以接受外部输入。

模拟一个伪终端。

Compose 模板文件支持动态读取主机的系统环境变量和当前目录下的 env 文件中的变量。

例如，下面的 Compose 文件将从运行它的环境中读取变量 ${MONGO_VERSION} 的值，并写入执行的指令中。

如果执行 MONGO_VERSION=32 docker-compose up 则会启动一个 mongo:32 镜像的容器；如果执行 MONGO_VERSION=28 docker-compose up 则会启动一个 mongo:28 镜像的容器。

若当前目录存在 env 文件，执行 docker-compose 命令时将从该文件中读取变量。

在当前目录新建 env 文件并写入以下内容。

执行 docker-compose up 则会启动一个 mongo:36 镜像的容器。

pre{overflow-x: auto}    

如何查看docker日志，让我们一起了解一下？

通过docker logs可以查看容器的日志命令。高效的监控和日志管理对保持生产系统持续稳定的运行以及排查问题至关重要。在微服务架构中，由于容器的数量众多以及快速变化的特性使得记录日志和监控变得越来越重要。

docker查看日志的几个方式：

1、docker logs --tail=1000 容器名称 （查看容器前多少行的日志）（推荐）

2、docker 容器启动后,可以进入以下位置查看日志（/var/lib/docker/containers/容器ID/容器ID-jsonlog）（进入容器内部查看日志）

3、#查看compose所有容器的运行日志

docker-compose -f docker-compose-appyml logs -f

4、#查看compose下某个容器的运行日志

docker-compose -f docker-compose-app yml logs -f服务名>

5、# 也可以把compose的容器日志输出到日志文件里去，然后用tail -f随时查看

docker-compose -f docker-compose-app yml logs -f >> myDockerComposelog &

具体操作如下：

docker attach [options] 容器会连接到正在运行的容器，然后将容器的标准输入、输出和错误流信息附在本地打印出来。命令中options的取值有三种：--detach-keys,--no-stdin,--sig-proxy。

该命令只是进入容器终端，不会启动新的进程。所以当你同时使用多个窗口进入该容器，所有的窗口都会同步显示。如果一个窗口阻塞，那么其他窗口也就无法再进行操作。

使用ctrl+c可以直接断开连接，但是这样会导致容器退出，而且还stop了。如果想在脱离容器终端时，容器依然运行。就需要使用--sig-proxy这个参数。例如：

$ docker attach --sig-proxy=false mytest

注意： 当使用docker attach连接到容器的标准输入输出时，docker使用大约1MB的内存缓冲区来最大化应用程序的吞吐量。如果此缓冲区填满，那么输出或写入的速度将会受到影响。因此查看应用日志，可以使用docker logs命令。