consul

一、将Docker数据挂载到容器 　　在Docker中，要想实现数据的持久化（所谓Docker的数据持久化即 数据不随着Container的结束而结束 ），需要将数据从宿主机挂载到容器中。目前Docker提供了三种不同的方式将数据从宿主机挂载到容器中： 　　（1）volumes：Docker管理宿主机文件系统的一部分，默认位于 /var/lib/docker/volumes 目录中；（ 最常用的方式 ） 　　 　　由上图可以知道，目前所有Container的数据都保存在了这个目录下边，由于没有在创建时指定卷，所以Docker帮我们默认创建许多匿名（就上面这一堆很长ID的名字）卷。 　　（2）bind mounts：意为着可以存储在宿主机系统的任意位置；（ 比较常用的方式 ） 　　但是，bind mount在不同的宿主机系统时不可移植的，比如Windows和Linux的目录结构是不一样的，bind mount所指向的host目录也不能一样。这也是为什么bind mount不能出现在Dockerfile中的原因，因为这样Dockerfile就不可移植了。 　　（3）tmpfs：挂载存储在宿主机系统的内存中，而不会写入宿主机的文件系统；（ 一般都不会用的方式 ） 　　三种方式的示意图如下所示： 　　 二、Volume的基本使用 2.1 管理卷 # docker volume create

grpc应用于微服务的分析 gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计,目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持. gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。 gRPC 基于如下思想：定义一个服务， 指定其可以被远程调用的方法及其参数和返回类型 gRPC 允许你定义四类服务方法： 单项 RPC，即客户端发送一个请求给服务端，从服务端获取一个应答，就像一次普通的函数调用。 rpc SayHello(HelloRequest) returns (HelloResponse){} 服务端流式 RPC，即客户端发送一个请求给服务端，可获取一个数据流用来读取一系列消息。客户端从返回的数据流里一直读取直到没有更多消息为止。 rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){} 客户端流式 RPC，即客户端用提供的一个数据流写入并发送一系列消息给服务端

系列目录 前面我们介绍了如何在windows单机以及如何基于docker部署consul集群,看起来也不是很复杂,然而如果想要把consul部署到kubernetes集群中并充分利用kubernetes集群的伸缩和调度功能并非易事.前面我们首先部署一个节点,部署完成以后获取它的ip,然后其它的ip都join到这个ip里组成集群. 前面的部署方式存在以下问题: 集群易主 我们知道,在kubernetes里,当节点发生故障或者资源不足时,会根据策略杀掉节点的一些pod转而将pod移到其它节点上.这时候我们就需要重新获取主节点ip,然后将新的节点加入进去,以上做法不利于充分发挥kubernetes自身的伸缩功能. 新节点加入 不管是新节点加入或者失败后重新生成的节点重新加入集群,都需要知道主节点ip,这会产生和上面相同的问题,就是需要人工介入. 理想的状态是,当集群主节点切换时,新节点仍然能够在无需人工介入的情况下自动加入集群.我们解决这个问题的思路如下:使用kubernetes集群的dns功能,而不直接硬编码节点的ip.如果集群中有三个server,则这三个sever中必然有一个是主节点,我们可以依次尝试通过dns来解析到具体的节点,依次尝试加入每一个sever节点,尝试到真正的主节点时便能够加入集群. 我们首先创建服务,定义服务的文件名为consul-service.yml

对于容器的服务发现，大家可能使用过registrator一个基于label 以及docker socket &&consul的容器服务发现解决方案（当时还是比较灵活的） 当然也有很多类似的方案，containerpilot是另外一个基于init模式的docker 服务发现工具,使用上同样比较简单，文档也很丰富，containerpilot的 好处是我们只需要关注下配置，后边就是自动的了，很不错，官方也提供了好多不错的案例，很值得学习下 参考资料 https://github.com/gliderlabs/registrator https://github.com/joyent/containerpilot https://www.joyent.com/blog/applications-on-autopilot 来源： oschina 链接： https://my.oschina.net/u/4365667/blog/4262058

转自: http://autopilotpattern.io/ ,一种不错的应用开发模式 The autopilot pattern automates in code the repetitive and boring operational tasks of an application, including startup, shutdown, scaling, and recovery from anticipated failure conditions for reliability, ease of use, and improved productivity. Why do we need to do this? Who is this for? How do we do it? How does this differ from previous approaches to automation? How does this differ from scheduler-backed container automation? What infrastructure do we need to do this? Example apps using this pattern Why do we need to do this? We need to make the

springcloud线上发布超时系列文章： springcloud线上发布超时之feign（ribbon饥饿加载） springcloud线上发布超时之grpc springcloud线上发布超时方案之终极杀招：预热（测试用例） 前言 经过上面两章的优化，超时报错有所减少，但是只是得到了缓解但是当流量切换时还是会有大量超时。 方案 这里又增加了一个启动后预热，即在程序启动后执行测试用例n次，让hystrix、web容器线程池等资源初始化。在测试用例执行完成之前，为了保证服务不对外提供服务，这里可以分两种。 延迟注册到注册中心 如果时使用注册中心来进行服务发现等，这里可以采用延迟注册来保证测试用例的成功执行， 如果时eureka为注册中心可以配置initial-instance-info-replication-interval-seconds参数，默认是40s，可以将其改为1分钟 如果是consul或者zk，可以修改响应的延时注册时间，或者修改服务端有效时间 kubernetes中增加服务ready延时时间 这里再deploy.yml中配置如下： spec: replicas: 1 template: spec: containers: - args: livenessProbe: failureThreshold: 5 httpGet: path: /health port:

上一篇 Zipkin+Sleuth 链路追踪整合 增加基于 MQ 向 Zipkin 埋点功能 1.rabbitmq docker run --name rabbitmq -d -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=spring -e RABBITMQ_DEFAULT_PASS=spring rabbitmq:management 2.启动 Zipkin绑定 rabbitmq docker run --name rabbit-zipkin -d -p 9411 : 9411 --link rabbitmq -e RABBIT_ADDRESSES=rabbitmq: 5672 -e RABBIT_USER=spring -e RABBIT_PASSWORD=spring openzipkin/zipkin 3.添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-rabbit</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId

要完整的模拟一套consul+MGR的完整环境，我们可能需要配置如下的服务器： 3台作为consul server,另外3台作为MySQL服务器，做MGR单主模式。 一、Mysql MGR 的搭建： 下载新版的mysql 8.0.13 wget https://cdn.mysql.com/archives/mysql-8.0/mysql-8.0.13-linux-glibc2.12-x86_64.tar.xz 使用uuidgen命令生成个uuid： uuidgen b71ed720-3219-4cb9-8349-0ecc04be979b 修改hosts 10.99.35.211 opsys-vm1-211 10.99.35.212 opsys-vm2-212 10.99.35.213 opsys-vm3-213 安装mysql-8.0.13 cd /apps tar xvf mysql-8.0.13-linux-glibc2.12-x86_64.tar tar xvf mysql-8.0.13-linux-glibc2.12-x86_64.tar.xz mv mysql-8.0.13-linux-glibc2.12-x86_64 mysql-8.0.13 mkdir -p /data/mysql/3307 chown -R mysql:mysql /data/mysql/3307

场景 公司微服务快上线了，微服务都是用Docker容器进行部署的，在同一台主机下，把服务都部署上，注册到Nacos的IP与PORT都是内网的IP与Dockerfile中定义的端口号，看起来好像也没什么问题，通过网关去调用也是可以调通的，请注意这有一个大前提： 必须把所有服务容器部署在同一台主机上时才可以！ 当服务实例没有部署在同一主机上，比如网关服务在A服务器，服务a在B服务器上，同样注册到Nacos (或其它注册中心) ，此时上报上来的都是内网的IP，那么当外部有请求进来的时候，网关通过Nacos的服务列表，找到了对应的服务a的内网IP，一调用发现调用不通 ps:内网怎么会通…… 任务 微服务容器可以不在同一台服务器上，互相调用 想法 既然上报的是内网的IP，我直接让他上报宿主机的IP和端口呗 使用Docker的host网络模式 修改部署脚本，通过shell部署容器时，获取宿主机IP与设置的映射端口号 让Docker的网络互通 分析 以下分别按上边的“想法”部分来进行说明下问题 翻遍官方文档与Github，得出的方案又有两个： 固定IP端口，把宿主机IP与端口写死在配置文件中：看起来是解决了，但是问题是无法水平扩展了 —— 勉强能用 固定网卡，防止因多网卡环境上报错误IP端口：没有用的，进入容器中 ifconfig 发现内部网卡只有两个，分别是 eth0 与 lo

DOCKER的内置OVERLAY网络 内置跨主机的网络通信一直是Docker备受期待的功能，在1.9版本之前，社区中就已经有许多第三方的工具或方法尝试解决这个问题，例如Macvlan、Pipework、Flannel、Weave等。 虽然这些方案在实现细节上存在很多差异，但其思路无非分为两种： 二层VLAN网络和Overlay网络 简单来说，二层VLAN网络解决跨主机通信的思路是把原先的网络架构改造为互通的大二层网络，通过特定网络设备直接路由，实现容器点到点的之间通信。这种方案在传输效率上比Overlay网络占优，然而它也存在一些固有的问题。 这种方法需要二层网络设备支持，通用性和灵活性不如后者。 由于通常交换机可用的VLAN数量都在4000个左右，这会对容器集群规模造成限制，远远不能满足公有云或大型私有云的部署需求； 大型数据中心部署VLAN，会导致任何一个VLAN的广播数据会在整个数据中心内泛滥，大量消耗网络带宽，带来维护的困难。 相比之下， Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。这样不但能够充分利用成熟的IP路由协议进程数据分发；而且在Overlay技术中采用扩展的隔离标识位数，能够突破VLAN的4000数量限制支持高达16M的用户，并在必要时可将广播流量转化为组播流量，避免广播数据泛滥。