Registrator中文文档

快速入门

这个简短的教程帮你快速开始使用Registrator。完整参看,查看运行参考node

概述

Registrator监控新建的Docker容器,而且检查断定这些容器提供的服务。从咱们的目的出发,任何监听在某个端口的程序都是服务。Registrator发如今容器内发现的任务服务,都将被添加到一个服务注册端,好比Consul或etcd。
在这个教程中,咱们将使用Registrator和Consul,运行一个Redis容器并自动添加到Consul。nginx

准备

咱们须要一个运行Docker的主机,能够是一个本地的boot2doker虚拟机和一个安装了docker client能够链接到虚拟机的shell。
咱们在容器里运行一个Server模式的consul实例redis

$ docker run -d --name=consul --net=host gliderlabs/consul-server -bootstrap

Consul在产品模式下的不是这样运行的,咱们这里使用这种方式完成教程。如今咱们能够访问经过Docker主机的IP访问Consul的HTTP API。docker

$ curl $(boot2doker ip):8500/v1/catalog/services
{"consul":[]}

如今咱们能够启动Registrator了。shell

运行Registrator

Registrator运行在每台主机上,咱们这里只有一台主机,就运行一次就行。启动Registrator须要配置如何链接到注册机,即这里的Consul。
除了标志选项,惟一须要的参数就是注册机URI。注册机URI编码了注册机类型,如何链接等选项。json

$ docker run -d \
    --name=registrator
    --net=host \
    gliderlabs/registrator:latest \
    consul://localhost:8500

先说一下Docker运行参数。首先,咱们独立的运行容器和命名。咱们也采用主机网络模式。这确保Registrator拥有实际主机的主机名和IP,也使Registrator更容易链接到Consul。咱们也必须挂载Docker socket。bootstrap

最后一行是Registrator运行参数,只有注册机URI。咱们使用consul//localhost:8500,由于Registrator和Consul 运行在同一个网口。ubuntu

$ docker logs registrator

咱们应该能够看到Registrator运行起来并在“监听Docker事件"。Registrator正常运行了。后端

运行Redis

如今当你启动的容器若是提供任何服务,他们将被添加到Consul。咱们如今运行标准镜像库的Redis:

$ docker run -d -P --name=redis redis

咱们使用-P发布全部端口,除了Registrator咱们不常常这样使用。这样不只发布了容器的全部端口,并且随机分配了一个主机端口。从Registrator和Consul提供服务发现的角度看,端口并不重要。尽管还有一些状况,你仍然想手动指定端口。

咱们再来看看Consul的服务端:

$ curl $(boot2docker ip):8500/v1/catalog/services
{"consul":[],"redis":[]}

如今Consul已经有了一个redis服务。咱们能够经过Consul的服端API查看更多诸如服务发布端口等信息:

$ curl $(boot2docker ip):8500/v1/catalog/service/redis
[{"Node":"boot2docker","Address":"10.0.2.15","ServiceID":"boot2docker:redis:6379","ServiceName":"redis","ServiceTags":null,"ServiceAddress":"","ServicePort":32768}]

若是咱们移除redis容器,咱们可以看到服务也从consul移除了。

$ docker rm -f redis
redis
$ curl $(boot2docker ip):8500/v1/catalog/service/redis
[]

就到这了。我知道单独来看这并没什么意义,可是当服务注册到Consul后你能够作不少事情。固然,这超出了Registrator的范围,它作的就是把容器中的服务放进Consul。

下一步

这还有不少方法配置Registrator,而且有不少方法运行容器,自定义服务。想了解这些,去看看运行参考服务模型

运行参考

Registrator设计是在每一个主机上运行一次。你能够在一个集群中运行单个Registrator,可是在每一个主机上运行可使你或得更好的扩展属性和更简单的配置。从必定程度的自动化来讲,每一个主机都运行比在某个地方运行一次更简单。

运行Registrator

docker run [docker options] gliderlabs/registrator[:tag] [options] <registry uri>

Registrator要求和推荐一些Docker选项,也有它本身的选项集,而后须要个注册机URI。下面是一个运行Registrator的经典方式:

$ docker run -d \
    --name=registrator \
    --net=host \
    --volume=/var/run/docker.sock:/tmp/docker.sock \
    gliderlabs/registrator:latest \
    consul://localhost:8500

Docker选项

Option Required Description
--volume=/var/run/docker.sock:/tmp/docker.sock yes 容许Registrator访问Docker API
--net=host recommended 帮助Registrator获取主机级的IP和主机名

与设置主机网络模式相比,另外一个可选的方案是设置容器名字为宿主主机名(-h $HOSTNAME),而且使用下面Registrator的-ip选项。

Registrator选项

Option Since Description
-cleanup v7 清理悬挂服务
-deregister v6 取消注册退出的服务 "always"或"on-success".缺省值:always
-internal   使用暴露端口代替发布端口
-ip v6 强制设置注册服务使用的IP地址
-resync v6 服务再同步频率。缺省值:0,never
-retry-attempts v7 与注册机后台创建链接的最大重试次数
-retry-interval v7 重试间隔(以毫秒为单位)
-tags v5 强制设置全部注册服务的都好分割的tags
-ttl   服务TTL。缺省值0,no expiry(注册机后台惟一支持)
-ttl-refresh   服务TTL刷新频率(注册机后台惟一支持)
-useIdFromLabel   使用存储在给定label的IP地址,这个label在容器中设置,用以注册Consul。

若是设置了-internal选项,Registrator会注册docker内部IP和端口,而不是映射到主机的端口。

默认状况下,注册服务时,Registrator会尝试解析当前主机名来设置服务地址。若是你想强制指定服务地址为某个特定地址,你能够指定-ip参数。

对于支持TTL超期的注册机后端,Registrator支持设置和刷新服务的TTLs,使用-ttl-ttl-refresh

若是你想无限制的重连尝试,可使用-retry-attempts -1

-resync选项控制Registrator查询Docker中全部容器而且注册全部服务的频率。这个选项容许Registrator和服务注册机从新找到掉出同步的服务。要谨慎使用这个选项,它会通知已经注册到你服务上的全部观察者,可能会迅速淹没你的系统(好比consul-template就大量使用监测)。

Consul ACL令牌

若是consul配置要求提供ACL令牌,Registrator须要知道,或者你会在consul的docker容器中看到警告。

[WARN] consul.catalog: Register of service 'redis' on 'hostname' denied due to ACLs

ACL令牌经过一个环境变量传入docker:CONSUL_HTTP_TOKEN

$ docker run -d \
    --name=registrator \
    --net=host \
    --volume=/var/run/docker.sock:/tmp/docker.sock \
    -e CONSUL_HTTP_TOKEN=<your acl token> \
    gliderlabs/registrator:latest \
    consul://localhost:8500

注册URI

<backend>://<address>[/<path>]

注册机后台使用URI来定义。架构是支持的注册机名字。地址是用来链接注册机的一个主机或者主机和端口。一些注册机支持一个定义的路径,好比做为前缀在服务定义中供基于注册机的key-value使用。

因此支持的后端参考,查看注册机后端

服务模型

Registrator主要关注的那些要被添加到服务发现注册机的服务。对咱们而言,全部监听在某个端口的程序都是服务。若是一个容器监听了多个端口,它就又多个服务。

服务,包括来自容器的信息和用户在容器上定义的元数据被建立成一个服务对象。这个服务对象随后被传递给注册机后端,尝试放置到一个特定的注册项。

type Service struc {
    ID string //unique service instance ID
    Name string //service name
    IP string //IP address service is located at
    Port int //Port service is listening on
    Tags []string //extra tags to classify service
    Attrs map[string]string //extra attribute metadata
}

容器覆盖

Name,Tags,Attrs,ID字段能够被用户自定义的容器元数据覆盖。你可使用前缀SERVICE_或者SERVICE_x_,其中x是内部暴露端口的环境变量或者标签设置这些值。例如,SERVICE_NAME=customerdbSERVICE_80_NAME=api

你在这些环境变量中使用的端口指的是在这个端口上的特定服务。名字中没有使用端口的元数据变量用做全部服务的缺省值,或者便捷的指向暴露的单个服务。

Attrs字段集合全部使用其余字段名的关键字,例如,SERVICE_REGION=us-east

由于元数据被存储为环境变量或者标签,所以容器做者能够在Dockerfile中包含他们本身的元数据定义。操做者仍然可以覆盖这些做者定义的缺省值。

发现服务

缺省状况下,你能够指望Registrator从那些已经显式发布端口(例如使用'-p'或者-P)的容器中获取服务。这对于那些以主机网络模式运行的容器也是正确的,所以你必须发布端口,即便它没什么作任何网络智慧的事情。

$ docker run --net=host -p 8080:8080 -p 8443:8443 ...

若是使用-internal选项运行,相反它将寻找暴露的端口。这些能够在Dockerfile中隐式设置或者使用docker run --expose=8080... 显式设定。

你也能够经过设置一个叫SERVICE_IGNORE的标签或者环境变量告诉Registrator忽略一个容器。

若是你须要在某些容器中忽略几个服务,你可使用SERVICE_<port>_IGNORE=true

服务名称

服务名是你在服务发现查找中使用的。缺省状况下,服务名按下面的格式肯定:

<base(container-image)>[-<exposed-port> if >1 ports]

使用容器镜像的基础,若是镜像是gliderlabs/footbar,服务名就是footbar。若是镜像是redis,服务名就是简单的redis

并且若是一个容器有多个暴露端口,它将各自追加内部暴露端口以区别。例如,一个镜像nginx有两个暴露端口,80和443,将产生两个服务,分别命名nginx-80nginx-443

你可使用标签或者环境变量,SERVICE_NAME或者'SERVICE_x_NAME',其中x是内部暴露端口,覆盖这些缺省名字。注意若是一个容器有多个暴露端口,设置SERVICE_NAME会致使多个服务命名为SERVICE_NAME-<exposed port>

IP和端口

IP和端口组成了服务名解析的地址。这有许多方法Registrator可以依赖你的设置判断IP地址和端口。缺省状况下,端口就是发布的公共端口,IP将是你的主机IP。

因为自动断定正确的IP是困难的,推荐使用-ip选项显式告诉Registrator使用什么IP。

若是你使用-internal选项,Regisrator会使用暴露端口和docker分配的内部容器IP。

Tags和Attributes

Tags和attributes是服务额外的元数据字段。并非全部的后端都支持他们。事实上,目前consul支持tags,而且最近的v1.0.7以KV元数据的形式添加了对attributes的支持,可是没有其余的后端支持attributes。

Attributes也能被后端用来注册特定的特性,不只仅是元数据。例如,consul使用他们指定specifying HTTP health checks

Unique ID

ID是服务示例在集群内的惟一标识。大部分状况下,它是一个实现细节,一般用户使用服务名而不是ID。Registrator使用一我的机友好的字符串,基于下面的格式编码了有用的信息在ID中:

<hostname>:<container-name>:<exposed-port>[:udp if udp]

ID包括了主机名,帮助你识别服务运行的主机。这也是Registrator运行在主机网络模式下或者设置Registrator的主机名为寄宿主机的主机名重要的缘由。不然它将是Registrator容器的ID,那没有什么用处

这个服务的容器名称也包含进来了。它使用容器名称代替容器ID,由于它更人性化,而且用户可配置。

为了识别出容器中这个服务,它使用内部暴露端口。这表明这个服务在容器内在这个端口上监听。咱们使用这个是由于它比公共的发布端口更好的表达了这个服务。一个公共的端口多是一个任意的54292,然而暴露的端口多是80,表示它是一个HTTP服务。

最后,若是服务定义为UDP,这会被包括到ID中与监听在相同端口的TCP服务区别开。

尽管这可使用容器的SERVICE_ID或者SERVICE_x_ID覆盖,可是不推荐这样作。

示例

缺省的单个服务

$ docker run -d --name redis.0 -p 10000:6379 progrium/redis

Service结果是:

{
    "ID": "hostname:redis.0:6379",
    "Name": "redis",
    "Port": 10000,
    "IP": "192.168.1.102",
    "Tags": [],
    "Attrs": {}
}

指定元数据的单个服务

$ docker run -d --name redis.0 -p 10000:6379 \
    -e "SERVICE_NAME=db" \
    -e "SERVICE_TAGS=master,backups" \
    -e "SERVICE_REGION=us2" progrium/redis

Service结果是:

{
    "ID": "hostname:redis.0:6379",
    "Name": "db",
    "Port": 10000,
    "IP": "192.168.1.102",
    "Tags": ["master", "backups"],
    "Attrs": {"region": "us2"}
}

记住并非全部的Service对象都会被注册后端使用。例如,目前不支持注册任意attributes。这个字段留做未来使用。
逗号可能能够经过反斜杠转义,像下面的例子:

$ docker run -d --name redis.0 -p 10000:6379 \
    -e "SERVICE_NAME=db" \
    -e "SERVICE_TAGS=/(;\\,:-_)/" \
    -e "SERVICE_REGION=us2" progrium/redis

缺省的多个服务

$ docker run -d --name nginx.0 -p 4443:443 -p 8000:80 progrium/nginx

两个Service对象的结果:

[
    {
        "ID": "hostname:nginx.0:443",
        "Name": "nginx-443",
        "Port": 4443,
        "IP": "192.168.1.102",
        "Tags": [],
        "Attrs": {},
    },
    {
        "ID": "hostname:nginx.0:80",
        "Name": "nginx-80",
        "Port": 8000,
        "IP": "192.168.1.102",
        "Tags": [],
        "Attrs": {}
    }
]

指定元数据的多个服务

$ docker run -d --name nginx.0 -p 4443:443 -p 8000:80 \
    -e "SERVICE_443_NAME=https" \
    -e "SERVICE_443_ID=https.12345" \
    -e "SERVICE_443_SNI=enabled" \
    -e "SERVICE_80_NAME=http" \
    -e "SERVICE_TAGS=www" progrium/nginx

两个Service对象的结果:

[
    {
        "ID": "https.12345",
        "Name": "https",
        "Port": 4443,
        "IP": "192.168.1.102",
        "Tags": ["www"],
        "Attrs": {"sni": "enabled"},
    },
    {
        "ID": "hostname:nginx.0:80",
        "Name": "http",
        "Port": 8000,
        "IP": "192.168.1.102",
        "Tags": ["www"],
        "Attrs": {}
    }
]

使用labels定义元数据

$ docker run -d --name redis.0 -p 10000:6379 \
    -l "SERVICE_NAME=db" \
    -l "SERVICE_TAGS=master,backups" \
    -l "SERVICE_REGION=us2" dockerfile/redis

Service结果:

{
    "ID": "hostname:redis.0:6379",
    "Name": "db",
    "Port": 10000,
    "IP": "192.168.1.102",
    "Tags": ["master", "backups"],
    "Attrs": {"region": "us2"}
}

注册后端

Registrator支持不少后端注册机。为了发挥Registrator的用途,你须要运行其中一个。下面是被支持后端使用的注册URI和它们的特性文档。

查看Contributing Backends

Consul

consul://<address>:<port>
consul-unix://<filepath>
consul-tls://<address>:<port>

Consul是推荐的注册机,由于它专门为服务发现提供了健康检查服务。

若是没有指定地址和端口,默认将使用127.0.0.1:8500。

consul支持tags,但不是任意服务attributes。

当使用consul-tls架构,Registrator经过TLS与Consul通讯。你必须设置下面的环境变量:CONSUL_CAERT:CA 文件位置, CONSUL_TLSKEY:Key位置

了解更多关于Consul检查参数信息,查看API documentation

Consul HTTP Check

这个特性只能在Consul 0.5及更新版本中使用。容器经过环境变量或者标签指定的这些额外的元数据用来在服务中注册一个HTTP健康检查。

SERVICE_80_CHECK_HTTP=/health/endpoint/path
SERVICE_80_CHECK_INTERVAL=15s
SERVICE_80_CHECK_TIMEOUT=1s     # optional, Consul default used otherwise

它适用于任何端口的服务,不只仅是80端口。若是它是惟一的服务,你也可使用

SERVICE_CHECK_HTTP

Consul HTTPS Check

这个特性只能在Consul 0.5及更新版本中使用。容器经过环境变量或者标签指定的这些额外的元数据用来在服务中注册一个HTTPS健康检查。

SERVICE_443_CHECK_HTTPS=/health/endpoint/path
SERVICE_443_CHECK_INTERVAL=15s
SERVICE_443_CHECK_TIMEOUT=1s        # optional, Consul default used otherwise

Consul TCP Check

这个特性只能在Consul 0.6及更新版本中使用。容器经过环境变量或者标签指定的这些额外的元数据用来在服务中注册一个TCP健康检查。

SERVICE_443_CHECK_TCP=true
SERVICE_443_CHECK_INTERVAL=15s
SERVICE_443_CHECK_TIMEOUT=3s        # optional, Consul default used otherwise

Consul Script Check

这个特性很难用,由于它让你指定一个脚本检查从Consul运行。若是在容器中运行Consul,你就被限制只能在那个容器中运行。例如,curl必须按照以使用这个特性:

SERVICE_CHECK_SCRIPT=curl --silent --fail example.com

任务no-TTL检查的缺省间隔是10秒,可是你可使用_CHECK_INTERVAL设置。检查命令可使用$SERVICE_IP$SERVICE_PORT占位符插值:

SERVICE_CHECK_SCRIPT=nc $SERVICE_IP $SERVICE_PORT | grep OK

Consul TTL Check

你也能够向consul注册一个TTL Check。记住这意味着Consul将期待一个常规的心跳ping到他的API,用以保持服务标志健康。

SERVICE_CHECK_TTL=30s

Consul Initial Health Check Status

缺省的当一个服务在Consul注册时,状态被设置为"critical"。你能够指定初始的健康检查状态:

SERVICE_CHECK_INITIAL_STATUS=passing

Consul Critical Service Deregistration

Consul可能撤销注册一个服务,若是检查在critical状态超过设定的时间值。若是启用,这应该比可期待的恢复故障更长。

SERVICE_CHECK_DEREGISTER_AFTER=10m

Consul KV

consulkv://<address>:<port>/<prefix>
consulkv-unix://<filepath>:/<prefix>

这是一个分离后端,使用Consul的key-value存储代替它的本地服务目录。这种表现更像etcd,由于它有类似的语义,可是目前不支持TTLs。

若是没有指定地址和端口,默认是127.0.0.1:8500

使用Registry URI前缀,服务定义存储为下面的格式:

<prefix>/<service-name>/<service-id> = <ip>:<port>

Etcd

etcd://<address>:<port>/<prefix>

Etcd工做方式与Consul KV类似,并且支持服务TTLs。它目前也不支持服务attributes和tags。

若是没有指定地址和端口,它将使用默认值127.0.0.1:2379

使用Registry URI做为前缀,服务定义被储存为下面的格式:

<prefix>/<service-name>/<service-id> = <ip>:<port>

SkyDNS 2

skydns2://<address>:<port>/<domain>

SkyDNS2 使用etcd,所以这个后端写服务定义的格式兼容SkyDNS2。path不能被省略,必须是一个对SkyDNS有效的DNS域名。

若是没有指定地址和端口,它将是默认值:127.0.0.1:2379

使用Registry URI和域名cluster.local,服务定义存储为下面的格式:

/skydns/local/cluster/<service-name>/<service-id> = {"host":"<ip>","port":<port>}

SkyDNS要求服务ID是一个有效的DNS主机名,所以这个后端要求容器用一个有效的DNS名字覆盖服务ID。例如:

$ docker run -d --name redis-1 -e SERVICE_ID=redis-1 -p 6379:6379 redis

Zookeeper Store

Zookeeper后端让你发布临时的znodes到zookeeper。这个模式在指定zookeeper路径后可使用。zookeeper后端支持发布一个json格式的znode body,完成定义服务attributes/tags,也包括服务名和容器id。URI示例:

$ registrator zookeeper://zookeeper.host/basepath
$ registrator zookeeper://192.168.1.100:9999/basepath

在zookeeper URI指定的base path中,registrator将为服务建立下面的包括一个JSON入口路径树:

<service-name>/<service-port> = <JSON>

JSON将包括发布容器服务的全部信息。例以下面的容器启动:

docker run -i -p 80 -e 'SERVICE_80_NAME=www' -t ubuntu:14.04 /bin/bash

将产生的zookeeper path和JSON znode body:

/basepath/www/80 = {"Name":"www","IP":"192.168.1.123","PublicPort":49153,"PrivatePort":80,"ContainerID":"9124853ff0d1","Tags":[],"Attrs":{}}

 

原文链接:点击这里

相关文章
相关标签/搜索