基于容器的部署

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

目前有多种解决方案，考虑我们有私有云，亚马逊云以及物理机的几种部署方式，所以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就可以。

Spark 的运行模式有 Local(也称单节点模式），Standalone(集群模式），Spark on Yarn(运行在Yarn上），Mesos以及K8s等常用模式，本文介绍前三种模式。

Spark-shell 参数

Spark-shell 是以一种交互式命令行方式将Spark应用程序跑在指定模式上，也可以通过Spark-submit提交指定运用程序，Spark-shell 底层调用的是Spark-submit,二者的使用参数一致的，通过- -help 查看参数：

sparkconf的传入有三种方式：

1.通过在spark应用程序开发的时候用set()方法进行指定

2.通过在spark应用程序提交的时候用过以上参数指定，一般使用此种方式，因为使用较为灵活

3.通过配置spark-default.conf，spark-env.sh文件进行指定，此种方式较shell方式级别低

Local模式

Local 模式是最简单的一种Spark运行方式，它采用单节点多线程（cpu)方式运行，local模式是一种OOTB（开箱即用）的方式，只需要在spark-env.sh导出JAVA_HOME,无需其他任何配置即可使用，因而常用于开发和学习

方式：./spark-shell - -master local[n] ，n代表线程升哗族数

Standalone模式

Spark on Yarn

on Yarn的俩种模式

客户端的Driver将应用提交给Yarn后，Yarn会先后启动ApplicationMaster和excutor,另外ApplicationMaster和executor都装在在container里运行，container默认的内存是1g，ApplicationMaster分配的内存是driver-memory,executor分配的内存是executor-memory.同时，因为Driver在客户端，所以程序的运行结果可以在客户端显示，Driver以进程名为SparkSubmit的形式存在。

Cluster 模式

1.由client向ResourceManager提交请求，并上传Jar到HDFS上

这期间包括吵弊四个步骤:

a).连接到RM

b).从RM ASM(applicationsManager)中获得metric，queue和resource等信息。

c).upload app jar and spark-assembly jar

d).设置运行环境和container上下文

2.ResourceManager向NodeManager申请资源，创建Spark ApplicationMaster（每个SparkContext都有一个ApplicationManager）

3.NodeManager启动Spark App Master，并向ResourceManager ASM注册

4.Spark ApplicationMaster从HDFS中找到jar文件，启动DAGScheduler和YARN Cluster Scheduler

5.ResourceManager向ResourceManager ASM注册申请container资源(INFO YarnClientImpl: Submitted application)

6.ResourceManager通知NodeManager分配Container，这是可以收到来自ASM关于container的报告。(每个container的对应一个executor)

7.Spark ApplicationMaster直接和container(executor)进行交互，完成这个分布式任务。

进芦樱入spark安装目录下的conf文件夹

[atguigu@hadoop102 module] mv slaves.template slaves

[atguigu@hadoop102 conf] vim slaves

hadoop102

hadoop103

hadoop104

4）修改spark-env.sh文件，添加如下配置：

[atguigu@hadoop102 conf]$ vim spark-env.sh

SPARK_MASTER_HOST=hadoop102

SPARK_MASTER_PORT=7077

5）分发spark包

[atguigu@hadoop102 module] sbin/start-all.sh

注意：如果遇到 “JAVA_HOME not set” 异常，可以在sbin目录下的spark-config.sh 文件中加入如下配置：

export JAVA_HOME=XXXX

官方求PI案例

spark-submit

--class org.apache.spark.examples.SparkPi

--master spark://server-2:7077

--executor-memory 1G

--total-executor-cores 2

/home/xxx/software/spark-2.4.4-bin-hadoop2.7/examples/jars/spark-examples_2.11-2.4.4.jar

100

spark-shell

--master spark://server-2:7077

--executor-memory 1g

--total-executor-cores 2

spark-shell --master spark://server-2:7077 --executor-memory 1g --total-executor-cores 2

参数：--master spark://server-2:7077 指定要连接的集群的master

Spark客户端直接连接Yarn，不需要额外构建Spark集群。有yarn-client和yarn-cluster两种模式，主要区别在于：Driver程序的运行节点。

yarn-client：Driver程序运行在客户端，适用于交互、调试，希望立即看到app的输出

yarn-cluster：Driver程序运行在由RM（ResourceManager）启动的AP（APPMaster）适用于生产环境。

安装使用

1）修改hadoop配置文件yarn-site.xml,添加如下内容：

2）修改spark-env.sh，添加如下配置：

[atguigu@hadoop102 conf]$ vi spark-env.sh

YARN_CONF_DIR=/opt/module/hadoop-2.7.2/etc/hadoop

3）分发配置文件

[atguigu@hadoop102 conf] xsync spark-env.sh

4）执行一个程序

spark-submit

--class org.apache.spark.examples.SparkPi

--master yarn

--deploy-mode client

/home/xxx/software/spark-2.4.4-bin-hadoop2.7/examples/jars/spark-examples_2.11-2.4.4.jar

100

注意：在提交任务之前需启动HDFS以及YARN集群。

日志查看

修改配置文件spark-defaults.conf

添加如下内容：

spark.yarn.historyServer.address=server-2:18080

spark.history.ui.port=18080

2）重启spark历史服务

[atguigu@hadoop102 spark] sbin/start-history-server.sh

starting org.apache.spark.deploy.history.HistoryServer, logging to /opt/module/spark/logs/spark-atguigu-org.apache.spark.deploy.history.HistoryServer-1-hadoop102.out

3）提交任务到Yarn执行

spark-submit

--class org.apache.spark.examples.SparkPi

--master yarn

--deploy-mode client

/home/xxx/software/spark-2.4.4-bin-hadoop2.7/examples/jars/spark-examples_2.11-2.4.4.jar

100

---