本页目录
Docker Compose集群安装
本指南将帮助你使用Docker Compose工具以集群模式配置ThingsBoard。
先决条件
ThingsBoard微服务正在dockerized环境中运行。
在开始之前确保已在系统中安装Docker社区版和Docker Compose。
步骤1.拉取镜像
确保你已使用命令行登录到docker hub。
1
2
3
4
5
6
7
8
| docker pull thingsboard/tb-node:3.5.1
docker pull thingsboard/tb-web-ui:3.5.1
docker pull thingsboard/tb-js-executor:3.5.1
docker pull thingsboard/tb-http-transport:3.5.1
docker pull thingsboard/tb-mqtt-transport:3.5.1
docker pull thingsboard/tb-coap-transport:3.5.1
docker pull thingsboard/tb-lwm2m-transport:3.5.1
docker pull thingsboard/tb-snmp-transport:3.5.1
|
步骤2.查看架构
从ThingsBoard v2.2开始可以使用新的微服务架构和Docker容器安装ThingsBoard集群。
有关更多详细信息请参见微服务架构页面。
步骤3.克隆代码
1
2
| git clone -b release-3.5 https://github.com/thingsboard/thingsboard.git
cd thingsboard/docker
|
步骤4.配置数据库
在执行初始安装之前可以配置与ThingsBoard一起使用的数据库的类型。
设置数据库类型在.env
文件中的DATABASE
变量的值更改为以下值:
postgres
- 使用PostgreSQL数据库;
hybrid
- 使用PostgreSQL保存实体Cassandra时间序列数据;
注意:根据数据库类型将部署相应的docker服务(请参见docker-compose.postgres.yml
, docker-compose.hybrid.yml
)相关详细信息。
步骤5.选择消息队列服务
ThingsBoard使用消息系统存储服务之间的通信,请正确选择队列?
参见相应的架构页面和规则引擎页面以获取更多详细信息。
AWS SQS配置
首先需要创建AWS账户然后访问AWS SQS服务。
使用此说明创建AWS SQS服务凭证。
- Access key ID
- Secret access key
配置环境变量文件:
检查下面行:
配置环境变量文件:
添加配置将”YOUR_KEY”和”YOUR_SECRET”替换为真实的AWS用户凭证并将”YOUR_REGION”替换成AWS SQS帐户区域:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| TB_QUEUE_TYPE=aws-sqs
TB_QUEUE_AWS_SQS_ACCESS_KEY_ID=YOUR_KEY
TB_QUEUE_AWS_SQS_SECRET_ACCESS_KEY=YOUR_SECRET
TB_QUEUE_AWS_SQS_REGION=YOUR_REGION
# These params affect the number of requests per second from each partitions per each queue.
# Number of requests to particular Message Queue is calculated based on the formula:
# ((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues)
# + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS
# For example, number of requests based on default parameters is:
# Rule Engine queues:
# Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30
# Core queue 10 partitions
# Transport request Queue + response Queue = 2
# Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2
# Total = 44
# Number of requests per second = 44 * 1000 / 25 = 1760 requests
# Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.
# By UI set the parameters - interval (1000) and partitions (1) for Rule Engine queues.
# Sample parameters to fit into 10 requests per second on a "monolith" deployment:
TB_QUEUE_CORE_POLL_INTERVAL_MS=1000
TB_QUEUE_CORE_PARTITIONS=2
TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000
TB_QUEUE_VC_INTERVAL_MS=1000
TB_QUEUE_VC_PARTITIONS=1
|
可以使用UI更新默认规则引擎队列配置(轮询间隔和分区)有关ThingsBoard规则引擎队列的更多信息请参阅文档。
|
Google发布/订阅配置
创建一个Google帐户并访问发布/订阅服务。
使用此说明创建一个项目并使用发布/订阅服务。
使用此说明创建服务帐户凭据并编辑角色或管理员后保存json凭据步骤9的文件此处。
配置环境变量文件:
检查下面行:
配置环境变量文件:
添加下面配置内容使用真正用户密码替换“YOUR_PROJECT_ID”, “YOUR_SERVICE_ACCOUNT”:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| TB_QUEUE_TYPE=pubsub
TB_QUEUE_PUBSUB_PROJECT_ID=YOUR_PROJECT_ID
TB_QUEUE_PUBSUB_SERVICE_ACCOUNT=YOUR_SERVICE_ACCOUNT
# These params affect the number of requests per second from each partitions per each queue.
# Number of requests to particular Message Queue is calculated based on the formula:
# ((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues)
# + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS
# For example, number of requests based on default parameters is:
# Rule Engine queues:
# Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30
# Core queue 10 partitions
# Transport request Queue + response Queue = 2
# Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2
# Total = 44
# Number of requests per second = 44 * 1000 / 25 = 1760 requests
# Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.
# By UI set the parameters - interval (1000) and partitions (1) for Rule Engine queues.
# Sample parameters to fit into 10 requests per second on a "monolith" deployment:
TB_QUEUE_CORE_POLL_INTERVAL_MS=1000
TB_QUEUE_CORE_PARTITIONS=2
TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000
TB_QUEUE_VC_INTERVAL_MS=1000
TB_QUEUE_VC_PARTITIONS=1
|
可以使用UI更新默认规则引擎队列配置(轮询间隔和分区)有关ThingsBoard规则引擎队列的更多信息请参阅文档。
|
Azure服务总线配置
创建Azure帐户并访问Azure服务总线。
通过使用说明了解并使用总线服务。
使用说明创建共享访问签名。
配置环境变量文件:
检查下面行:
1
| TB_QUEUE_TYPE=service-bus
|
配置环境变量文件:
1
| nano queue-service-bus.env
|
添加下面配置内容使用真正的服务总线名称空间替换”YOUR_NAMESPACE_NAME”和”YOUR_SAS_KEY_NAME”及”YOUR_SAS_KEY”:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| TB_QUEUE_TYPE=service-bus
TB_QUEUE_SERVICE_BUS_NAMESPACE_NAME=YOUR_NAMESPACE_NAME
TB_QUEUE_SERVICE_BUS_SAS_KEY_NAME=YOUR_SAS_KEY_NAME
TB_QUEUE_SERVICE_BUS_SAS_KEY=YOUR_SAS_KEY
# These params affect the number of requests per second from each partitions per each queue.
# Number of requests to particular Message Queue is calculated based on the formula:
# ((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues)
# + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS
# For example, number of requests based on default parameters is:
# Rule Engine queues:
# Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30
# Core queue 10 partitions
# Transport request Queue + response Queue = 2
# Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2
# Total = 44
# Number of requests per second = 44 * 1000 / 25 = 1760 requests
# Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.
# Sample parameters to fit into 10 requests per second on a "monolith" deployment:
TB_QUEUE_CORE_POLL_INTERVAL_MS=1000
TB_QUEUE_CORE_PARTITIONS=2
TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS=1000
TB_QUEUE_RE_MAIN_POLL_INTERVAL_MS=1000
TB_QUEUE_RE_MAIN_PARTITIONS=2
TB_QUEUE_RE_HP_POLL_INTERVAL_MS=1000
TB_QUEUE_RE_HP_PARTITIONS=1
TB_QUEUE_RE_SQ_POLL_INTERVAL_MS=1000
TB_QUEUE_RE_SQ_PARTITIONS=1
TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS=1000
TB_QUEU_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000
|
|
你可以使用官方文档安装RabbitMQ或按照以下说明:
配置环境变量文件:
检查下面行:
配置环境变量文件:
1
| nano queue-rabbitmq.env
|
将以下行添加到配置文件将“YOUR_USERNAME”和“YOUR_PASSWORD”替换为真实的信息将“localhost”和“5672”替换为真实的RabbitMQ主机和端口:
1
2
3
4
5
| TB_QUEUE_TYPE=rabbitmq
TB_QUEUE_RABBIT_MQ_HOST=localhost
TB_QUEUE_RABBIT_MQ_PORT=5672
TB_QUEUE_RABBIT_MQ_USERNAME=YOUR_USERNAME
TB_QUEUE_RABBIT_MQ_PASSWORD=YOUR_PASSWORD
|
|
Confluent配置
你应该创建一个帐户后访问Confluent云然后创建一个Kafka集群和 API Key。
配置环境变量文件:
检查下面行:
1
| TB_QUEUE_TYPE=confluent
|
配置环境变量文件:
1
| nano queue-confluent-cloud.env
|
添加下面配置内容使用真正的Confluent云服务器地址替换”CLUSTER_API_KEY”, “CLUSTER_API_SECRET”和”localhost:9092”:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
| TB_QUEUE_TYPE=kafka
TB_KAFKA_SERVERS=confluent.cloud:9092
TB_QUEUE_KAFKA_REPLICATION_FACTOR=3
TB_QUEUE_KAFKA_USE_CONFLUENT_CLOUD=true
TB_QUEUE_KAFKA_CONFLUENT_SSL_ALGORITHM=https
TB_QUEUE_KAFKA_CONFLUENT_SASL_MECHANISM=PLAIN
TB_QUEUE_KAFKA_CONFLUENT_SASL_JAAS_CONFIG=org.apache.kafka.common.security.plain.PlainLoginModule required username="CLUSTER_API_KEY" password="CLUSTER_API_SECRET";
TB_QUEUE_KAFKA_CONFLUENT_SECURITY_PROTOCOL=SASL_SSL
TB_QUEUE_KAFKA_CONFLUENT_USERNAME=CLUSTER_API_KEY
TB_QUEUE_KAFKA_CONFLUENT_PASSWORD=CLUSTER_API_SECRET
TB_QUEUE_KAFKA_RE_TOPIC_PROPERTIES=retention.ms:604800000;segment.bytes:52428800;retention.bytes:1048576000
TB_QUEUE_KAFKA_CORE_TOPIC_PROPERTIES=retention.ms:604800000;segment.bytes:52428800;retention.bytes:1048576000
TB_QUEUE_KAFKA_TA_TOPIC_PROPERTIES=retention.ms:604800000;segment.bytes:52428800;retention.bytes:1048576000
TB_QUEUE_KAFKA_NOTIFICATIONS_TOPIC_PROPERTIES=retention.ms:604800000;segment.bytes:52428800;retention.bytes:1048576000
TB_QUEUE_KAFKA_JE_TOPIC_PROPERTIES=retention.ms:604800000;segment.bytes:52428800;retention.bytes:104857600
# These params affect the number of requests per second from each partitions per each queue.
# Number of requests to particular Message Queue is calculated based on the formula:
# ((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues)
# + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS
# For example, number of requests based on default parameters is:
# Rule Engine queues:
# Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30
# Core queue 10 partitions
# Transport request Queue + response Queue = 2
# Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2
# Total = 44
# Number of requests per second = 44 * 1000 / 25 = 1760 requests
# Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low.
# By UI set the parameters - interval (1000) and partitions (1) for Rule Engine queues.
# Sample parameters to fit into 10 requests per second on a "monolith" deployment:
TB_QUEUE_CORE_POLL_INTERVAL_MS=1000
TB_QUEUE_CORE_PARTITIONS=2
TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS=1000
TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000
TB_QUEUE_VC_INTERVAL_MS=1000
TB_QUEUE_VC_PARTITIONS=1
|
可以使用UI更新默认规则引擎队列配置(轮询间隔和分区)有关ThingsBoard规则引擎队列的更多信息请参阅文档。
|
步骤6.启用监控(可选)
配置文件启用Grafana和Prometheus服务:
MONITORING_ENABLED
变量值为true
:
1
| MONITORING_ENABLED=true
|
部署后能够通过Prometheus:http://localhost:9090
和Grafana:http://localhost:3000
(默认用户admin
和密码foobar
)访问。
步骤7.运行
在启动Docker容器之前请运行以下命令以创建用于存储数据和日志的目录然后将其所有者更改为Docker容器用户,以便能够更改用户使用chown命令该命令需要sudo权限(该命令将要求sudo访问的密码):
1
| ./docker-create-log-folders.sh
|
执行以下命令以运行安装:
1
| ./docker-install-tb.sh --loadDemo
|
说明:
--loadDemo
-可选参数用于是否加载演示数据。
执行以下命令以启动服务:
1
| ./docker-start-services.sh
|
执行完命令后你可以http://{your-host-ip}
在浏览器中打开(例如http://localhost
)。
使用以下默认凭据:
- System Administrator: sysadmin@thingsboard.org / sysadmin
如果使用演示数据(使用--loadDemo
标志)安装了数据库则还可以使用以下凭据:
- Tenant Administrator: tenant@thingsboard.org / tenant
- Customer User: customer@thingsboard.org / customer
如有任何问题可以检查服务日志中是否有错误。
例如要查看ThingsBoard节点日志请执行以下命令:
1
| docker compose logs -f tb-core1 tb-rule-engine1
|
如果依然使用Docker Compose请执行如下命令:
docker-compose logs -f tb-core1 tb-rule-engine1
查看所有容器的状态:
如果依然使用Docker Compose请执行如下命令:
docker-compose ps
查看运行的服务的日志:
如果依然使用Docker Compose请执行如下命令:
docker-compose logs -f
请参阅docker-compose命令详细信息。
执行服务停止命令:
1
| ./docker-stop-services.sh
|
删除已部署的docker容器:
1
| ./docker-remove-services.sh
|
执行服务更新命令:
1
| ./docker-update-service.sh [SERVICE...]
|
说明
[SERVICE...]
- 更新的服务列表(docker-compose文件中定义的服务)如果未指定会更新所有服务。
升级
如果需要升级数据库请编辑.env文件以将“TB_VERSION”设置为目标版本(例如升级到最新版本请将其设置为3.5.13.4.3)然后执行以下命令:
1
2
3
| ./docker-stop-services.sh
./docker-upgrade-tb.sh --fromVersion=[FROM_VERSION]
./docker-start-services.sh
|
FROM_VERSION
- 有关有效值为开始升级版本升级说明查看fromVersion
值。
HTTPS证书
我们使用HAproxy将流量代理到容器默认情况下使用Web UI的80和443端口,将HTTPS与有效证书一起使用请执行以下命令:
1
2
| docker exec haproxy-certbot certbot-certonly --domain your_domain --email your_email
docker exec haproxy-certbot haproxy-refresh
|
注意:当在URL中通过域名访问Web UI时使用的有效证书,通过IP地址访问UI则使用自签名证书。
下一步
-
入门指南 - 快速学习ThingsBoard相关功能。
-
连接设备 - 学习如何根据你的连接方式或解决方案连接设备。
-
可 视 化 - 学习如何配置复杂的ThingsBoard仪表板说明。
-
数据处理 - 学习如何使用ThingsBoard规则引擎。
-
数据分析 - 学习如何使用规则引擎执行基本的分析任务。
-
硬件样品 - 学习如何将各种硬件平台连接到ThingsBoard。
-
高级功能 - 学习高级ThingsBoard功能。
-
开发指南 - 学习ThingsBoard中的贡献和开发。