马上体验
解决方案
客户
案例
合作伙伴
关于我们
报价 文档 指南

安装

ThingsBoard安装和配置文档。

Docker Compose集群

本指南将帮助你使用Docker Compose工具以集群模式配置ThingsBoard。

先决条件

ThingsBoard微服务正在dockerized环境中运行。

在开始之前确保已在系统中安装Docker社区版和Docker Compose。

步骤1.拉取ThingsBoard社区版镜像

确保你已使用命令行登录到docker hub。

docker pull thingsboard/tb-node:3.1.1
docker pull thingsboard/tb-web-ui:3.1.1
docker pull thingsboard/tb-js-executor:3.1.1
docker pull thingsboard/tb-http-transport:3.1.1
docker pull thingsboard/tb-mqtt-transport:3.1.1
docker pull thingsboard/tb-coap-transport:3.1.1

步骤2.查看架构页面

从ThingsBoard v2.2开始可以使用新的微服务架构和Docker容器安装ThingsBoard集群。

有关更多详细信息请参见微服务架构页面。

步骤3.克隆ThingsBoard代码库

git clone https://github.com/thingsboard/thingsboard.git
cd docker

步骤4.配置数据库

在执行初始安装之前可以配置与ThingsBoard一起使用的数据库的类型。 设置数据库类型在.env文件中的DATABASE变量的值更改为以下值：

  • postgres - 使用PostgreSQL数据库;
  • hybrid - 使用PostgreSQL保存实体Cassandra时间序列数据;

注意：根据数据库类型将部署相应的kubernetes资源（请参阅basic/postgres.yml或high-availability/postgres-ha.yaml进行复制的postgrescommon/cassandra.yml有关详细信息）。

步骤5.选择消息队列服务

选择下面消息中间件代理服务之前的通信。

  • 内存 默认队列适用于开发环境很有用请勿用于生产环境。

  • Kafka 对于本地和私有云部署可以独立于云服务供应商生产环境中使用。

  • RabbitMQ 如果没有太多负载并且已经具备一定的使用经验建议使用此方式。

  • AWS SQS 如是你打算在AWS上使用ThingsBoard则可以使用此消息队列。

  • Google发布/订阅 如果你打算在Google Cloud上部署ThingsBoard则可以使用此消息队列。

  • Azure服务总线 如果你打算在Azure上部署ThingsBoard则可以使用此消息队列。

  • Confluent云 基于Kafka的完全托管的事件流平台。

参见相应的架构页面和规则引擎页面以获取更多详细信息。

Kafka(本地安装)
AWS (AWS托管)
Google发布/订阅(Google托管)
Azure服务总线(Azure托管)
RabbitMQ(本地最小安装)
Confluent云(基于Kafka事件流)

Apache Kafka是一个开放源代码的流处理软件平台。

配置环境变量文件：

sudo nano .env

检查以下行：

TB_QUEUE_TYPE=kafka

AWS SQS配置

首先需要创建一个AWS账户然后访问AWS SQS服务。

要使用AWS SQS服务您将需要使用此说明创建下一个凭证。

  • Access key ID
  • Secret access key

配置环境变量文件：

sudo nano .env

检查以下行：

TB_QUEUE_TYPE=aws-sqs

配置队列服务AWS SQS环境变量：

sudo nano queue-aws-sqs.env

将以下行添加到环境变量文件用真实的AWS用户凭证替换”YOUR_KEY”, “YOUR_SECRET”并用“AWS SQS帐户区域”替换”YOUR_REGION”：

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.
# 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_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000

Google发布/订阅配置

创建一个Google云帐户并访问发布/订阅服务。

使用此说明创建一个项目并使用发布/订阅服务。

使用此说明创建服务帐户凭据并编辑角色或管理员后保存json凭据步骤9的文件此处。

配置环境变量文件：

sudo nano .env

检查以下行：

TB_QUEUE_TYPE=pubsub

配置队列服务发布/订阅环境变量：

sudo nano queue-pubsub.env

将以下行添加到环境变量文件用真实的帐户信息替换”YOUR_PROJECT_ID”,”YOUR_SERVICE_ACCOUNT”

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.
# 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_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000

Azure服务总线配置

创建一个Azure帐户并访问Azure服务总线。

通过使用说明了解并使用总线服务。

使用说明创建共享访问签名。

配置环境变量文件：

sudo nano .env

检查以下行：

TB_QUEUE_TYPE=service-bus

配置队列服务总线环境变量：

sudo nano queue-service-bus.env

将以下行添加到环境变量文件用真实服务总线名称空间替换”YOUR_NAMESPACE_NAME”和”YOUR_SAS_KEY_NAME”及”YOUR_SAS_KEY”：

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。

配置环境变量文件：

sudo nano .env

检查以下行：

TB_QUEUE_TYPE=rabbitmq

配置队列服务RabbitMQ云环境变量：

sudo nano queue-rabbitmq.env

将以下行添加到环境变量文件用真实用户凭据替换”YOUR_USERNAME”和”YOUR_PASSWORD并修改”localhost”和”5672”为真实的RabbitMQ主机和端口：

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。

配置环境变量文件：

sudo nano .env

Check following line:

TB_QUEUE_TYPE=confluent

配置队列服务Confluent云环境变量：

sudo nano queue-confluent-cloud.env

将以下行添加到环境变量文件用真实的Confluent云服务器地址替换”CLUSTER_API_KEY”, “CLUSTER_API_SECRET”和”localhost:9092”：

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.
# 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_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS=1000

步骤6.运行

在启动Docker容器之前请运行以下命令以创建用于存储数据和日志的目录然后将其所有者更改为Docker容器用户，以便能够更改用户使用chown命令该命令需要sudo权限（该命令将要求sudo访问的密码）：

$ ./docker-create-log-folders.sh

执行以下命令以运行安装：

$ ./docker-install-tb.sh --loadDemo

说明:

  • --loadDemo - 可选参数是否安装演示数据。

执行以下命令以启动服务：

$ ./docker-start-services.sh

执行完命令后你可以http://{your-host-ip}:9090在浏览器中打开(例如http://localhost:9090)。

使用以下默认凭据：

  • System Administrator: sysadmin@thingsboard.org / sysadmin

如果使用演示数据（使用--loadDemo标志）安装了数据库则还可以使用以下凭据：

  • Tenant Administrator: tenant@thingsboard.org / tenant
  • Customer User: customer@thingsboard.org / customer

如有任何问题可以检查服务日志中是否有错误。 例如要查看ThingsBoard节点日志请执行以下命令：

$ docker-compose logs -f tb-core1 tb-rule-engine1

使用docker-compose ps查看所有容器的状态。 使用docker-compose logs --f检查所有正在运行的服务的日志。 有关详细信息请参见docker-compose日志命令参考。

执行以下命令停止服务：

$ ./docker-stop-services.sh

执行以下命令以停止并完全删除已部署的Docker容器：

$ ./docker-remove-services.sh

执行以下命令以更新特定或所有服务（拉出较新的Docker映像并重建容器）：

$ ./docker-update-service.sh [SERVICE...]

说明:

  • [SERVICE ...] - 要更新的服务列表（在docker-compose配置中定义）。如果未指定则将更新所有服务。

升级

如果需要数据库升级请执行以下命令：

$ ./docker-stop-services.sh
$ ./docker-upgrade-tb.sh --fromVersion=[FROM_VERSION]
$ ./docker-start-services.sh

说明：

  • FROM_VERSION - 从哪个版本开始升级关于fromVersion值请参见升级说明。

下一步

  • 入门指南 - 这些指南提供了ThingsBoard主要功能的快速概述。

  • 设备连接 - 了解如何根据您的连接方式或解决方案连接设备。

  • 数据看板 - 这些指南包含有关如何配置复杂的ThingsBoard仪表板的说明。

  • 数据处理 - 了解如何使用ThingsBoard规则引擎。

  • 数据分析 - 了解如何使用规则引擎执行基本的分析任务。

  • 硬件样品 - 了解如何将各种硬件平台连接到ThingsBoard。

  • 高级功能 - 了解高级ThingsBoard功能。

  • 开发指南 - 了解ThingsBoard中的贡献和开发。