swarm

有时间写！！！ 来源： https://blog.csdn.net/echizao1839/article/details/100147551

Spark支持local、Standalone和Cluster三种并行运行模式【参考： Spark的三种运行模式快速入门 】。 local，单机运行模式。 Standalone，Spark自己构建的独立集群。 Cluster，运行在Mesos/YARN/Kubernetes等集群环境中，从而可以让Spark与其他的应用协调资源。 参考： 搭建hadoop/spark集群环境 使用Mesos和Marathon管理Docker集群 Docker作为应用“集装箱”，提供了Swarm集群运行环境( 最新版为swarmkit，参考： Docker文档 )，也可以运行于Mesos/Kubernetes等集群环境中。 将Spark部署于Docker中，可以提供单机运行和手动的Standalone运行，也可以同时支持Swarm/Mesos/YARN/Kubernetes集群环境。 部署方式： 1、需要将Spark分为Master和Slave两种部署模式，创建两类Spark容器（或者创建为一个通用容器，通过启动参数判断节点将启动为Master还是Slave模式）。 2、通过启动参数环境变量将Spark启动参数传递进Docker。 3、在容器启动时，设置Spark节点启动，并且Slave节点自动连接到Master节点。 理论上，可以在一个Docker中启动多个Spark节点

提起Docker容器化 不得不提服务编排，众所周知目前Docker常用的服务编排模式有三种， Mesos DockerSwarm Kubernetes，下面将详细介绍这三种服务编排模式的架构和环境搭建。 一. Mesos 1.Mesos架构图 下图是在Mesos官网上对mesos架构的介绍 即使不看下面的英文描述，从这张图上我们也看看出Mesos的整体架构，主体为主从结构master/slave或者master/agent模式，对master节点来说为了避免单点，引入了多个master，多个master向Zookeeper注册自己，用zk实现选举。master节点运行一些任务调度器（scheduler），agent节点运行任务执行器（executor），一个agent节点可以运行多个执行器，有执行器来执行具体任务（task）。 2.Mesos任务执行调度过程 任务调度如下图： 从图中可以看出，这个调度分为四个过程： 1.Mesos Agent将自己所在机器（物理机，虚拟机，容器）的资源信息（可用的处理器，内存，磁盘等资源）上报给Mesos Master的资源分配组件（Allocation Module）。 2.master节点向framework发送资源邀约（resource offer），通知framework在agent上可用的资源信息。 3.框架调度程序（FW

本节我们介绍如何以方便的方式管理service。 我们之前提到docker-compose，适用于本地开发，可以在本机部署，提供了很大的便利。而swarm是一个cluster，可不可以通过docker-compose来实现定义的application？答案是可以，但是不推荐。仅仅使用docker命令行就可以。我们依然可以使用docker-compose.yml文件去定义一个应用，但是我们一般不用docker-compose去部署，而是直接使用docker命令，而且我们这个部署只能用于swarm cluster。 deploy version "3.3" services: wordpress: image: wordpress ports: - 8080:80 networks: - overlay deploy: mode: replicated replicas: 2 endpoint_mode: vip placement: constraints: - node.role == manager - engine.labels.operatingsystem == ubuntu 16.04 preferences: - spread: node.labels.zone resources: limites: cpus: '0.50' memory: 50M 上面是一个例子：

一、Docker 网络模式 Docker 容器的网络有五种模式: */ /*--> */ 模式名称 功能 是否支持多主机 南北向通信机制 东西向通信机制 bridge 默认设置，为容器创建独立的网络命名空间，容器具有独立的网卡等所有单独的网络栈。如果在容器运行时不加 --net 参数，就默认采用这种网络模式。 否 宿主机端口绑定 通过Linux bridge host 没有独立的网络环境，直接使用宿主机的 ip 和端口。 是 按宿主机网络通信 按宿主机网络通信 none 为容器创建独立网络命名空间，但不为它做任何网络配置，容器中只有lo，用户可以在此基础上，对容器网络做任意定制。 否 无法通信 通过link通信 container 指定一个容器与其共享 IP 和端口 否 宿主机端口绑定 通过link通信 自定义 Docker 1.9版本以后新增的特性，允许容器使用第三方的网络实现或者创建单独的bridge 网络，提供网络隔离能力。 按网络实现而定 按网络实现而定 按网络实现而定 注：南北向通信指容器与宿主机外界的访问机制，东西向通信机制指同一宿主机上，与其他容器相互访问的机制。 二、自定义网络模式 在自定义网络模式下，用户可以创建一个新的 Bridge 、Overlay 或 Macvlan 网络。与 Bridge 不同 Overlay 和 Macvlan 网络主要用于创建跨主机访问

1.介绍 docker 图形化管理提供了很多工具，有Portainer、Docker UI、Shipyard等等，本文主要介绍Portainer。  Portainer是一个开源、轻量级Docker管理用户界面，基于Docker API，提供状态显示面板、应用模板快速部署、容器镜像网络数据卷的基本操作（包括上传下载镜像，创建容器等操作）、事件日志显示、容器控制台操作、Swarm集群和服务等集中管理和操作、登录用户管理和控制等功能。功能十分全面，基本能满足中小型单位对容器管理的全部需求。 2.创建容器 2.1下载官方镜像 [root@ ganbing /]# docker pull portainer/portainer Using default tag: latest latest: Pulling from portainer/portainer d1e017099d17: Pull complete ba5495c717cb: Pull complete Digest: sha256:8146a5aae1135a0ccee424488c6867b438be21d1e915903a858d12e8382b817b Status: Downloaded newer image for portainer/portainer:latest 2.2单机运行

首先是在公司的测试环境上发现了这个现象，网上search了一番，这个并不是错误，而是swarm下的一种机制： 当使用 Swarm Stacks时，为了保证Service的副本在每个节点上运行的是相同的镜像， Swarm采用的是一种叫 Pinning-by-Digest的策略， 而不是根据镜像的tag来使用镜像。 Service会将你指定的镜像tag转换成digest id，并使用这个digest去拉取镜像。 使用 docker service ls 可以查看各个服务使用的镜像版本。 生产实践中最好不要用lastest的镜像tag，可以使用v2.1.0这样的命名。 参考： https://github.com/moby/moby/issues/28908 https://success.docker.com/article/images-tagging-vs-digests https://stackoverflow.com/questions/50152854/docker-swarm-docker-stack-deploy-results-on-untagged-images-none 来源： https://www.cnblogs.com/nieqibest/p/11408373.html

1.作用 　　当在 任何 一个 swarm 节点去访问 端口服务的时候 会通过 本节点 的 IPVS ( ip virtual service ) 到 真正的 swarm 节点上 　　当访问 docker host 3 的 端口 8080 时， 会把 请求转发到 另外两台host 上去 , 然后把 响应返回给用户 2. 功能 　　外部访问的均衡负载 　　服务端口被暴露到哥哥swarm节点 　　内部通过 IPVS 进行均衡负载 3. 实验 　　创建 一个 名为 demo 的 overlay 网络 另外 创建 client service 和 whoami service 服务 　　　　docker network create -d overlay demo 　　　　docker service create --name whoami -p 8000:8000 --network demo -d jwilder/whoami 　　　　docker service create --name client -d --network demo busybox sh -c 'while true; do sleep 3600; done' 　　将 whoami 服务拓展为 两个容器 　　　　docker service scale whoami=2 　　查看 whoami 的运行情况　

非常抱歉，10:00~10:30 左右博客站点出现故障，给您带来麻烦了，请您谅解。 故障原因与博文中谈到的部署变更有关，但背后的问题变得非常复杂，复杂到我们都在怀疑与阿里云服务器 CPU 特性有关。 这篇博文本来准备 9:30 左右发布的，但发布博文时出现了 docker swarm 部署异常情况，切换到 docker-compose 部署后问题依旧，一直到 10:30 左右才恢复正常，继续发布这篇博文，在标题中加上了“翻车记”。 原先的博文正文开始： 周一向大家 汇报车况 之后，我们的 .NET Core 新车继续以 docker-compose 手动挡的驾驶方式行驶在信息高速公路上，即使昨天驶上了更快的高速（并发量更大的访问高峰），也没有翻车。经过这周3天访问高峰的考验，我们终于可以充满信心地宣布——我们度过了新车上路最艰难的磨合期，开新车的剧情从“翻车记”进入到了“行车记”。 翻车成为历史，行车正在进行时，但离我们的目标“飙车”还有很长的一段距离，“行车记”更多的是修车记，新车改造记。 目前这辆 .NET Core 新车有2个重大问题，一是油耗高（CPU消耗高），有时还会断油（CPU 100% 造成 502），二是手动挡驾驶实在太累。 针对油耗高问题，这两天我们从节能降耗角度对博客系统的 C# 代码进行了优化。 从日志中发现，有些特别长的 url 会造成 ASP.NET

微服务架构是当前很热门的一个概念，它不是凭空产生的，是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案，但业界已经有一些很有影响力的开源微服务架构平台，架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。 本文选自《架构解密：从分布式到微服务》。 　　本文盘点了四种常用的微服务架构方案，分别是ZeroC IceGrid、Spring Cloud、基于消息队列与Docker Swarm。 ZeroC IceGrid微服务架构 　　ZeroC IceGrid作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力，如下所示是它的整体示意图。 　　　　 　　IceGrid具备微服务架构的如下明显特征。 　　首先，微服务架构需要一个集中的服务注册中心，以及某种服务发现机制。IceGrid服务注册采用XML文件来定义，其服务注册中心就是Ice Registry，这是一个独立的进程，并且提供了HA高可用机制；对应的服务发现机制就是命名查询服务，即LocatorService提供的API，可以根据服务名查询对应的服务实例可用地址。 　　其次，微服务架构中的每个微服务通常会被部署为一个独立的进程，当无状态服务时，一般会由多个独立进程提供服务。对应在IceGrid里，一个IceBox就是一个单独的进程