第14章 Docker 中 Zookeeper 的安装与配置

第14章 Docker 中 zookeeper 的安装与配置

前言

  • 为什么要使用 Zookeeper?

    Apache ZooKeeper致力于开发和维护开源服务器,实现高度可靠的分布式协调。

  • 什么是 Zookeeper?

    Apache ZooKeeper是Apache Software Foundation的一个软件项目,为大型分布式系统提供开源分布式配置服务,同步服务和命名注册表。 ZooKeeper是Hadoop的一个子项目,但现在它本身就是一个顶级项目。

    ZooKeeper是一种集中式服务,用于维护配置信息,命名,提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用。每次实施它们都需要做很多工作来修复不可避免的错误和竞争条件。由于难以实现这些类型的服务,应用程序最初通常会吝啬它们,这使得它们在变化的情况下变得脆弱并且难以管理。即使正确完成,这些服务的不同实现也会在部署应用程序时导致管理复杂性。

    Learn more about ZooKeeper on the ZooKeeper Wiki.

  • 什么是 Docker?

    具体请参考我的第08章内容。

  • 为什么要在 Docker 中安装 Jenkins?

    为了开发环境一致性、可移植性、易于管理和维护性。

目标

  • 完成 Jenkins 在 Docker 中的安装与配置。
  • 安装在 Docker 中的 Jenkins 能正常对外提供服务。
  • 在外部开发环境中能正常访问和使用 Jenkins 持续集成服务。

环境

  • **VMware:**VMware Workstation 14 Pro
  • **Linux:**CentOS7.4
  • **Docker:**18.06.0-ce, build 0ffa825
  • **Jenkins:**Jenkins2.121.1
  • **JDK:**jdk1.8.0_172

概述

A Distributed Coordination Service for Distributed Applications(分布式应用程序的分布式协调服务)

ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语,分布式应用程序可以构建这些原语,以实现更高级别的服务,以实现同步,配置维护以及组和命名。它的设计易于编程,并使用在熟悉的文件系统目录树结构之后设计的数据模型。它在Java中运行,并且具有Java和C的绑定。

众所周知,协调服务很难做到。他们特别容易出现诸如竞争条件和死锁等错误。 ZooKeeper背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。

设计目标(Design Goals)

ZooKeeper很简单。 ZooKeeper允许分布式进程通过共享的层级命名空间相互协调,该命名空间与标准文件系统类似地组织。名称空间由数据寄存器组成 - 在ZooKeeper用语中称为znodes - 这些与文件和目录类似。与专为存储而设计的典型文件系统不同,ZooKeeper数据保存在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟数量。

ZooKeeper实现非常重视高性能,高可用性,严格有序的访问。 ZooKeeper的性能方面意味着它可以在大型分布式系统中使用。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。

**ZooKeeper被复制。**与它协调的分布式进程一样,ZooKeeper本身也可以在称为集合的一组主机上进行复制。

img

组成ZooKeeper服务的服务器必须彼此了解。它们维护内存中的状态图像,以及持久性存储中的事务日志和快照。只要大多数服务器可用,ZooKeeper服务就可用。

客户端连接到单个ZooKeeper服务器。客户端维护TCP连接,通过该连接发送请求,获取响应,获取监视事件以及发送心跳。如果与服务器的TCP连接中断,则客户端将连接到其他服务器。

ZooKeeper是有序的。 ZooKeeper使用反映所有ZooKeeper事务顺序的数字标记每个更新。后续操作可以使用该顺序来实现更高级别的抽象,例如同步原语。

**ZooKeeper是很快的。**它在“read-dominant”工作负载中特别快。 ZooKeeper应用程序在数千台计算机上运行,并且在读取比写入更常见的情况下表现最佳,比率大约为10:1。

数据模型和分层命名空间(Data model and the hierarchical namespace)

ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜杠(/)分隔的路径元素序列。 ZooKeeper名称空间中的每个节点都由路径标识。

img

节点和短暂节点(Nodes and ephemeral nodes)

与标准文件系统不同,ZooKeeper命名空间中的每个节点都可以包含与之关联的数据以及子项。这就像拥有一个允许文件也是目录的文件系统。 (ZooKeeper旨在存储协调数据:状态信息,配置,位置信息等,因此存储在每个节点的数据通常很小,在字节到千字节范围内。)我们使用术语znode来表明我们正在谈论ZooKeeper数据节点。

Znodes维护一个stat结构,包括数据更改,ACL更改和时间戳的版本号,以允许缓存验证和协调更新。每次znode的数据更改时,版本号都会增加。例如,每当客户端检索数据时,它也接收数据的版本。

存储在命名空间中每个znode的数据以原子方式读取和写入。读取获取与znode关联的所有数据字节,写入替换所有数据。每个节点都有一个访问控制列表(ACL),限制谁可以做什么。

ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态,就会存在这些znode。会话结束时,znode将被删除。当您想要实现[tbd]时,短暂节点很有用。

有条件的更新和监控(Conditional updates and watches)

ZooKeeper支持手表的概念。客户端可以在znodes上设置监视。当znode更改时,将触发并删除手表。当触发手表时,客户端会收到一个数据包,说明znode已更改。如果客户端与其中一个Zoo Keeper服务器之间的连接中断,客户端将收到本地通知。这些可以用于[tbd]。

保障(Guarantees)

ZooKeeper非常快速且非常简单。但是,由于其目标是构建更复杂的服务(如同步)的基础,因此它提供了一系列保证。这些是:

  • 顺序一致性 - 客户端的更新将按发送顺序应用。

  • 原子性 - 更新成功或失败。没有部分结果。

  • 单系统映像 - 无论服务器连接到哪个服务器,客户端都将看到相同的服务视图。

  • 可靠性 - 一旦应用了更新,它将从那时起持续到客户端覆盖更新。

  • 及时性 - 系统的客户视图保证在特定时间范围内是最新的。

有关这些以及如何使用它们的更多信息,请参阅[tbd]

简单的API(Simple API)

ZooKeeper的设计目标之一是提供一个非常简单的编程接口。因此,它仅支持以下操作:

create
creates a node at a location in the tree

delete
deletes a node

exists
tests if a node exists at a location

get data
reads the data from a node

set data
writes data to a node

get children
retrieves a list of children of a node

sync
waits for data to be propagated

有关这些内容的更深入讨论,以及如何使用它们来实现更高级别的操作,请参阅[tbd]

实现(Implementation)

ZooKeeper Components shows 高级组件 Zookeeper 服务。除请求处理器外,构成ZooKeeper服务的每个服务器都复制其自己的每个组件的副本。

img

复制数据库是包含整个数据树的内存数据库。更新将记录到磁盘以获取可恢复性,并且写入在应用于内存数据库之前会序列化到磁盘。

每个ZooKeeper服务器都为客户端服务。客户端只连接到一台服务器以提交请求。读取请求由每个服务器数据库的本地副本提供服务。更改服务状态,写请求的请求由协议协议处理。

作为协议协议的一部分,来自客户端的所有写入请求都被转发到称为领导者的单个服务器。其余的ZooKeeper服务器(称为关注者)接收来自领导者的消息提议并同意消息传递。消息传递层负责替换失败的领导者并将关注者与领导者同步。

ZooKeeper使用自定义原子消息传递协议。由于消息传递层是原子的,因此ZooKeeper可以保证本地副本永远不会发散。当领导者收到写入请求时,它会计算应用写入时系统的状态,并将其转换为捕获此新状态的事务。

用途(Users)

ZooKeeper的编程接口非常简单。但是,使用它,您可以实现更高阶的操作,例如同步原语,组成员资格,所有权等。某些分布式应用程序已将其用于:[tbd:从白皮书和视频演示添加用途。]有关详细信息,请参阅[TBD]

性能(Performance)

ZooKeeper旨在提供高性能。不就是这样吗? ZooKeeper雅虎开发团队的成果!研究表明它是。 (请参阅ZooKeeper吞吐量作为读写比率变化 ZooKeeper Throughput as the Read-Write Ratio Varies)在读取数量超过写入的应用程序中,它的性能尤其高,因为写入涉及同步所有服务器的状态。 (读取数量超过写入通常是协调服务的情况。)

img

图中ZooKeeper吞吐量作为读写比率( ZooKeeper Throughput as the Read-Write Ratio Varies )变化是ZooKeeper版本3.2的吞吐量图,运行在具有双2Ghz Xeon和两个SATA 15K RPM驱动器的服务器上。一个驱动器用作专用的ZooKeeper日志设备。快照已写入OS驱动器。写请求是1K写入,读取是1K读取。 “服务器”表示ZooKeeper集合的大小,即构成服务的服务器数量。大约30个其他服务器用于模拟客户端。 ZooKeeper集合的配置使得领导者不允许来自客户端的连接。

Note

In version 3.2 r/w performance improved by ~2x compared to the previous 3.1 release.

基准也表明它也是可靠的。存在错误时的可靠性(Reliability in the Presence of Errors )显示了部署如何响应各种故障。图中标记的事件如下:

  1. Failure and recovery of a follower
  2. Failure and recovery of a different follower
  3. Failure of the leader
  4. Failure and recovery of two followers
  5. Failure of another leader

可靠性(Reliability)

为了在注入故障时显示系统随时间的行为,我们运行了由7台机器组成的ZooKeeper服务。我们运行与之前相同的饱和度基准,但这次我们将写入百分比保持在恒定的30%,这是我们预期工作负载的保守比率。

img

这是图表中的一些重要观察结果。首先,如果追随者失败并迅速恢复,那么即使失败,ZooKeeper也能够维持高吞吐量。但也许更重要的是,领导者选举算法允许系统足够快地恢复以防止吞吐量大幅下降。在我们的观察中,ZooKeeper选择新领导者的时间不到200毫秒。第三,随着追随者的恢复,ZooKeeper能够在开始处理请求后再次提高吞吐量。

谁在使用(The ZooKeeper Project)

ZooKeeper已成功应用于许多工业应用( successfully used in)。它用于Yahoo!作为Yahoo!的协调和故障恢复服务Message Broker,是一个高度可扩展的发布 - 订阅系统,可管理数千个主题以进行复制和数据传递。雅虎的获取服务使用它! crawler,它还管理故障恢复。一些雅虎!广告系统也使用ZooKeeper来实现可靠的服务。

鼓励所有用户和开发人员加入社区并贡献他们的专业知识。有关更多信息,请参阅Apache上的Zookeeper项目。

安装

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TYfZ71YL-1599611935812)(https://raw.githubusercontent.com/docker-library/docs/f906e95d1c27856aa79ea1bd8600da51466e7b0b/zookeeper/logo.png)]

如何使用镜像

查找镜像
$ sudo docker search zookeeper
下载镜像
# sudo docker image pull zookeeper:3.4.13
启动Zookeeper服务器实例
$ docker run --name some-zookeeper --restart always -d zookeeper
启动虚拟机与容器端口映射实例
$ sudo docker run --name zookeeper -p 2181:2181 -p 2888:2888 -p 3888:3888 --restart always -d zookeeper:3.4.13

此镜像包括EXPOSE 2181 2888 3888(分别是zookeeper客户端端口[client port],跟随端口「follower port,」,选择端口「election port」),因此标准容器链接将使其自动可用于链接容器。由于Zookeeper“fails fast”,最好始终重启它。

打开端口
$ sudo firewall-cmd --zone=public --add-port=2181/tcp --permanent 
$ sudo firewall-cmd --zone=public --add-port=2888/tcp --permanent 
$ sudo firewall-cmd --zone=public --add-port=3888/tcp --permanent 
## 重启防火墙
$ sudo firewall-cmd --reload 
$ sudo firewall-cmd --list-port
从另一个Docker容器中的应用程序连接到Zookeeper
$ docker run --name some-app --link some-zookeeper:zookeeper -d application-that-uses-zookeeper
从Zookeeper命令行客户端连接到Zookeeper
$ docker run -it --rm --link some-zookeeper:zookeeper zookeeper zkCli.sh -server zookeeper
…通过docker stack deploy或docker-
compose

Example stack.yml for zookeeper:

version: '3.1'

services:
  zoo1:
    image: zookeeper
    restart: always
    hostname: zoo1
    ports:
      - 2181:2181
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=0.0.0.0:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

  zoo2:
    image: zookeeper
    restart: always
    hostname: zoo2
    ports:
      - 2182:2181
    environment:
      ZOO_MY_ID: 2
      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=0.0.0.0:2888:3888 server.3=zoo3:2888:3888

  zoo3:
    image: zookeeper
    restart: always
    hostname: zoo3
    ports:
      - 2183:2181
    environment:
      ZOO_MY_ID: 3
      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=0.0.0.0:2888:3888

这将以复制模式( replicated mode. )启动Zookeeper。运行docker stack deploy -c stack.yml zookeeper(或docker-compose -f stack.yml up)并等待它完全初始化。将暴露端口2181-2183

请注意,在一台计算机上设置多台服务器不会产生任何冗余。如果发生导致机器死机的事情,所有zookeeper服务器都将脱机。完全冗余要求每台服务器都有自己的机器。它必须是完全独立的物理服务器。同一物理主机上的多个虚拟机仍然容易受到该主机的完全故障的影响。

在复制模式下运行Zookeeper时,请考虑使用 Docker Swarm

配置(Configuration)

配置文件

Zookeeper配置位于/conf。更改它的一种方法是将配置文件作为卷安装:

$ docker run --name some-zookeeper --restart always -d -v $(pwd)/zoo.cfg:/conf/zoo.cfg zookeeper

环境变量

如果未提供zoo.cfg文件,则使用ZooKeeper推荐的默认值。可以使用以下环境变量覆盖它们。

$ docker run -e "ZOO_INIT_LIMIT=10" --name some-zookeeper --restart always -d 31z4/zookeeper
ZOO_TICK_TIME

Defaults to 2000. ZooKeeper’s tickTime

单个tick的长度,即ZooKeeper使用的基本时间单位,以毫秒为单位。它用于调节心跳和超时。例如,最小会话超时将是两个滴答

ZOO_INIT_LIMIT

Defaults to 5. ZooKeeper’s initLimit

以滴答为单位的时间量(请参阅tickTime),以允许关注者连接并同步到领导者。如果ZooKeeper管理的数据量很大,则根据需要增加此值。

ZOO_SYNC_LIMIT

Defaults to 2. ZooKeeper’s syncLimit

以滴答为单位的时间量(请参阅tickTime),以允许关注者与ZooKeeper同步。如果粉丝落后于领导者,他们就会被淘汰。

ZOO_MAX_CLIENT_CNXNS

Defaults to 60. ZooKeeper’s maxClientCnxns

限制由IP地址标识的单个客户端可以对ZooKeeper集合的单个成员进行的并发连接数(在套接字级别)。

ZOO_STANDALONE_ENABLED

Defaults to false. Zookeeper’s standaloneEnabled

在3.5.0之前,可以在独立模式或分布式模式下运行ZooKeeper。这些是单独的实现堆栈,并且无法在运行时在它们之间进行切换。默认情况下(为了向后兼容),standaloneEnabled设置为true。使用此默认值的结果是,如果以单个服务器启动,则不允许集合增长,如果从多个服务器启动,则不允许缩小以包含少于两个参与者。

ZOO_AUTOPURGE_PURGEINTERVAL

Defaults to 0. Zookeeper’s autoPurge.purgeInterval

3.4.0中的新增功能:必须触发清除任务的时间间隔(以小时为单位)。设置为正整数(1和更高)以启用自动清除。默认为0。

ZOO_AUTOPURGE_SNAPRETAINCOUNT

Defaults to 3. Zookeeper’s autoPurge.snapRetainCount

3.4.0中的新增功能:启用后,ZooKeeper自动清除功能分别在dataDir和dataLogDir中保留autopurge.snapRetainCount最新快照和相应的事务日志,并删除其余日志。默认为3.最小值为3。

复制模式(Replicated mode)

如果要以复制模式运行Zookeeper,则必须使用下面的环境变量。

ZOO_MY_ID

id必须在整体中是唯一的,并且应该具有介于1和255之间的值。请注意,如果使用已包含myid文件的/ data目录启动容器,则此变量不会产生任何影响。

ZOO_SERVERS

此变量允许您指定Zookeeper集合的计算机列表。每个条目都具有server.id = host:port:port的形式。参赛作品以空格分隔。请注意,如果使用已包含zoo.cfg文件的/conf目录启动容器,则此变量不会产生任何影响。

在3.5中,这种语法已经改变。服务器应该如下指定:server.id=<address1>:<port1>:<port2>[:role];[<client port address>:]<client port> Zookeeper Dynamic Reconfiguration

存储数据的位置

此映像使用/data/datalog中的卷配置,以分别保存Zookeeper内存数据库快照和数据库更新的事务日志。

放置事务日志的位置要小心。专用的事务日志设备是始终如一的良好性能的关键。将日志置于繁忙的设备上会对性能产生负面影响。

参考

Docker Hub 官方镜像安装参考:https://hub.docker.com/_/zookeeper/

第三方公司提供镜像参考:https://hub.docker.com/r/bitnami/zookeeper/

wikipedia.org/wiki/Apache_ZooKeeper

官方网址:https://zookeeper.apache.org/

Supported tags and respective Dockerfile links

Quick reference

library/official-images/commits/master/library/zookeeper))

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值