分类： 未分类

快乐分享，Java干货及时送达👇

1. 资料文档

Kafka：中，有 kafka 作者自己写的书，网上资料也有一些。

rabbitmq：多，有一些不错的书，网上资料多。

zeromq：少，没有专门写 zeromq 的书，网上的资料多是一些代码的实现和简单介绍。

rocketmq：少，没有专门写 rocketmq 的书，网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述。

activemq：多，没有专门写 activemq 的书，网上资料多。

2. 开发语言

Kafka：Scala

rabbitmq：Erlang

zeromq：c

rocketmq：java

activemq：java

3. 支持的协议

Kafka：自己定义的一套…（基于 TCP）

rabbitmq：AMQP

zeromq：TCP、UDP

rocketmq：自己定义的一套…

activemq：OpenWire、STOMP、REST、XMPP、AMQP

4. 消息存储

Kafka：内存、磁盘、数据库。支持大量堆积。

kafka 的最小存储单元是分区，一个 topic 包含多个分区，kafka 创建主题时，这些分区会被分配在多个服务器上，通常一个 broker 一台服务器。分区首领会均匀地分布在不同的服务器上，分区副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的 broker 加入集群的时候，部分副本会被移动到新的 broker 上。根据配置文件中的目录清单，kafka 会把新的分区分配给目录清单里分区数最少的目录。默认情况下，分区器使用轮询算法把消息均衡地分布在同一个主题的不同分区中，对于发送时指定了 key 的情况，会根据 key 的 hashcode 取模后的值存到对应的分区中。

rabbitmq：内存、磁盘。支持少量堆积。

rabbitmq 的消息分为持久化的消息和非持久化消息，不管是持久化的消息还是非持久化的消息都可以写入到磁盘。持久化的消息在到达队列时就写入到磁盘，并且如果可以，持久化的消息也会在内存中保存一份备份，这样可以提高一定的性能，当内存吃紧的时候会从内存中清除。非持久化的消息一般只存在于内存中，在内存吃紧的时候会被换入到磁盘中，以节省内存。

引入镜像队列机制，可将重要队列“复制”到集群中的其他 broker 上，保证这些队列的消息不会丢失。配置镜像的队列，都包含一个主节点 master 和多个从节点 slave,如果 master 失效，加入时间最长的 slave 会被提升为新的 master，除发送消息外的所有动作都向 master 发送，然后由 master 将命令执行结果广播给各个 slave，rabbitmq 会让 master 均匀地分布在不同的服务器上，而同一个队列的 slave 也会均匀地分布在不同的服务器上，保证负载均衡和高可用性。

zeromq：消息发送端的内存或者磁盘中。不支持持久化。

rocketmq：磁盘。支持大量堆积。

commitLog 文件存放实际的消息数据，每个 commitLog 上限是 1G，满了之后会自动新建一个 commitLog 文件保存数据。ConsumeQueue 队列只存放 offset、size、tagcode，非常小，分布在多个 broker 上。ConsumeQueue 相当于 CommitLog 的索引文件，消费者消费时会从 consumeQueue 中查找消息在 commitLog 中的 offset，再去 commitLog 中查找元数据。关注工众号：码猿技术专栏，回复关键词：1111 获取阿里内部Java性能调优手册！ConsumeQueue 存储格式的特性，保证了写过程的顺序写盘（写 CommitLog 文件），大量数据 IO 都在顺序写同一个 commitLog，满 1G 了再写新的。加上 rocketmq 是累计 4K 才强制从 PageCache 中刷到磁盘（缓存），所以高并发写性能突出。

activemq：内存、磁盘、数据库。支持少量堆积。

5. 消息事务

Kafka：支持

rabbitmq：支持。客户端将信道设置为事务模式，只有当消息被 rabbitMq 接收，事务才能提交成功，否则在捕获异常后进行回滚。使用事务会使得性能有所下降

zeromq：不支持

rocketmq：支持

activemq：支持

6. 负载均衡

Kafka：支持负载均衡。

1、一个 broker 通常就是一台服务器节点。对于同一个 Topic 的不同分区，Kafka 会尽力将这些分区分布到不同的 Broker 服务器上，zookeeper 保存了 broker、主题和分区的元数据信息。分区首领会处理来自客户端的生产请求，kafka 分区首领会被分配到不同的 broker 服务器上，让不同的 broker 服务器共同分担任务。

每一个 broker 都缓存了元数据信息，客户端可以从任意一个 broker 获取元数据信息并缓存起来，根据元数据信息知道要往哪里发送请求。

2、kafka 的消费者组订阅同一个 topic，会尽可能地使得每一个消费者分配到相同数量的分区，分摊负载。

3、当消费者加入或者退出消费者组的时候，还会触发再均衡，为每一个消费者重新分配分区，分摊负载。

kafka 的负载均衡大部分是自动完成的，分区的创建也是 kafka 完成的，隐藏了很多细节，避免了繁琐的配置和人为疏忽造成的负载问题。

4、发送端由 topic 和 key 来决定消息发往哪个分区，如果 key 为 null，那么会使用轮询算法将消息均衡地发送到同一个 topic 的不同分区中。如果 key 不为 null，那么会根据 key 的 hashcode 取模计算出要发往的分区。

rabbitmq：对负载均衡的支持不好。

1、消息被投递到哪个队列是由交换器和 key 决定的，交换器、路由键、队列都需要手动创建。

rabbitmq 客户端发送消息要和 broker 建立连接，需要事先知道 broker 上有哪些交换器，有哪些队列。通常要声明要发送的目标队列，如果没有目标队列，会在 broker 上创建一个队列，如果有，就什么都不处理，接着往这个队列发送消息。假设大部分繁重任务的队列都创建在同一个 broker 上，那么这个 broker 的负载就会过大。（可以在上线前预先创建队列，无需声明要发送的队列，但是发送时不会尝试创建队列，可能出现找不到队列的问题，rabbitmq 的备份交换器会把找不到队列的消息保存到一个专门的队列中，以便以后查询使用）

使用镜像队列机制建立 rabbitmq 集群可以解决这个问题，形成 master-slave 的架构，master 节点会均匀分布在不同的服务器上，让每一台服务器分摊负载。slave 节点只是负责转发，在 master 失效时会选择加入时间最长的 slave 成为 master。

当新节点加入镜像队列的时候，队列中的消息不会同步到新的 slave 中，除非调用同步命令，但是调用命令后，队列会阻塞，不能在生产环境中调用同步命令。

2、当 rabbitmq 队列拥有多个消费者的时候，队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者，不会重复。

这种方式非常适合扩展，而且是专门为并发程序设计的。

如果某些消费者的任务比较繁重，那么可以设置 basicQos 限制信道上消费者能保持的最大未确认消息的数量，在达到上限时，rabbitmq 不再向这个消费者发送任何消息。

3、对于 rabbitmq 而言，客户端与集群建立的 TCP 连接不是与集群中所有的节点建立连接，而是挑选其中一个节点建立连接。但是 rabbitmq 集群可以借助 HAProxy、LVS 技术，或者在客户端使用算法实现负载均衡，引入负载均衡之后，各个客户端的连接可以分摊到集群的各个节点之中。

客户端均衡算法

1. 轮询法。按顺序返回下一个服务器的连接地址。
2. 加权轮询法。给配置高、负载低的机器配置更高的权重，让其处理更多的请求；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载。
3. 随机法。随机选取一个服务器的连接地址。
4. 加权随机法。按照概率随机选取连接地址。
5. 源地址哈希法。通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算。
6. 最小连接数法。动态选择当前连接数最少的一台服务器的连接地址。

zeromq：去中心化，不支持负载均衡。本身只是一个多线程网络库。

rocketmq：支持负载均衡。

一个 broker 通常是一个服务器节点，broker 分为 master 和 slave,master 和 slave 存储的数据一样，slave 从 master 同步数据。

1、nameserver 与每个集群成员保持心跳，保存着 Topic-Broker 路由信息，同一个 topic 的队列会分布在不同的服务器上。

2、发送消息通过轮询队列的方式发送，每个队列接收平均的消息量。发送消息指定 topic、tags、keys，无法指定投递到哪个队列（没有意义，集群消费和广播消费跟消息存放在哪个队列没有关系）。

tags 选填，类似于 Gmail 为每封邮件设置的标签，方便服务器过滤使用。目前只支 持每个消息设置一个 tag，所以也可以类比为 Notify 的 MessageType 概念。

keys 选填，代表这条消息的业务关键词，服务器会根据 keys 创建哈希索引，设置后， 可以在 Console 系统根据 Topic、Keys 来查询消息，由于是哈希索引，请尽可能 保证 key 唯一，例如订单号，商品 Id 等。

3、rocketmq 的负载均衡策略规定：Consumer 数量应该小于等于 Queue 数量，如果 Consumer 超过 Queue 数量，那么多余的 Consumer 将不能消费消息。这一点和 kafka 是一致的，rocketmq 会尽可能地为每一个 Consumer 分配相同数量的队列，分摊负载。

activemq：支持负载均衡。可以基于 zookeeper 实现负载均衡。

7. 集群方式

Kafka：天然的‘Leader-Slave’无状态集群，每台服务器既是 Master 也是 Slave。

分区首领均匀地分布在不同的 kafka 服务器上，分区副本也均匀地分布在不同的 kafka 服务器上，所以每一台 kafka 服务器既含有分区首领，同时又含有分区副本，每一台 kafka 服务器是某一台 kafka 服务器的 Slave，同时也是某一台 kafka 服务器的 leader。

kafka 的集群依赖于 zookeeper，zookeeper 支持热扩展，所有的 broker、消费者、分区都可以动态加入移除，而无需关闭服务，与不依靠 zookeeper 集群的 mq 相比，这是最大的优势。

rabbitmq：支持简单集群，’复制’模式，对高级集群模式支持不好。

rabbitmq 的每一个节点，不管是单一节点系统或者是集群中的一部分，要么是内存节点，要么是磁盘节点，集群中至少要有一个是磁盘节点。

在 rabbitmq 集群中创建队列，集群只会在单个节点创建队列进程和完整的队列信息（元数据、状态、内容），而不是在所有节点上创建。引入镜像队列，可以避免单点故障，确保服务的可用性，但是需要人为地为某些重要的队列配置镜像。

zeromq：去中心化，不支持集群。

rocketmq：常用 多对’Master-Slave’ 模式，开源版本需手动切换 Slave 变成 Master

Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

Broker 部署相对复杂，Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master，Master 与 Slave 的对应关系通过指定相同的 BrokerName，不同的 BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave。Master 也可以部署多个。每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。

Producer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态，可集群部署。

Consumer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave 发送心跳。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定。

客户端先找到 NameServer, 然后通过 NameServer 再找到 Broker。

一个 topic 有多个队列，这些队列会均匀地分布在不同的 broker 服务器上。rocketmq 队列的概念和 kafka 的分区概念是基本一致的，kafka 同一个 topic 的分区尽可能地分布在不同的 broker 上，分区副本也会分布在不同的 broker 上。

rocketmq 集群的 slave 会从 master 拉取数据备份，master 分布在不同的 broker 上。

activemq：支持简单集群模式，比如’主-备’，对高级集群模式支持不好。

8. 管理界面

Kafka：一般

rabbitmq：好

zeromq：无

rocketmq：无

activemq：一般

9. 可用性

Kafka：非常高（分布式）

rabbitmq：高（主从）

zeromq：高

rocketmq：非常高（分布式）

activemq：高（主从）

10. 消息重复

Kafka：支持 at least once、at most once

rabbitmq：支持 at least once、at most once

zeromq：只有重传机制，但是没有持久化，消息丢了重传也没有用。既不是 at least once、也不是 at most once、更不是 exactly only once

rocketmq：支持 at least once

activemq：支持 at least once

11. 吞吐量 TPS

Kafka：极大 Kafka 按批次发送消息和消费消息。发送端将多个小消息合并，批量发向 Broker，消费端每次取出一个批次的消息批量处理。

rabbitmq：比较大

zeromq：极大

rocketmq：大

rocketMQ ：接收端可以批量消费消息，可以配置每次消费的消息数，但是发送端不是批量发送。

activemq：比较大

12. 订阅形式和消息分发

Kafka：基于 topic 以及按照 topic 进行正则匹配的发布订阅模式。

【发送】

发送端由 topic 和 key 来决定消息发往哪个分区，如果 key 为 null，那么会使用轮询算法将消息均衡地发送到同一个 topic 的不同分区中。如果 key 不为 null，那么会根据 key 的 hashcode 取模计算出要发往的分区。

【接收】

1、consumer 向群组协调器 broker 发送心跳来维持他们和群组的从属关系以及他们对分区的所有权关系，所有权关系一旦被分配就不会改变除非发生再均衡(比如有一个 consumer 加入或者离开 consumer group)，consumer 只会从对应的分区读取消息。

2、kafka 限制 consumer 个数要少于分区个数,每个消息只会被同一个 Consumer Group 的一个 consumer 消费（非广播）。

3、kafka 的 Consumer Group 订阅同一个 topic，会尽可能地使得每一个 consumer 分配到相同数量的分区，不同 Consumer Group 订阅同一个主题相互独立，同一个消息会被不同的 Consumer Group 处理。

rabbitmq：提供了 4 种：direct, topic ,Headers 和 fanout。

【发送】

先要声明一个队列，这个队列会被创建或者已经被创建，队列是基本存储单元。

由 exchange 和 key 决定消息存储在哪个队列。

direct：发送到和 bindingKey 完全匹配的队列。

topic：路由 key 是含有”.”的字符串，会发送到含有“*”、“#”进行模糊匹配的 bingKey 对应的队列。

fanout：与 key 无关，会发送到所有和 exchange 绑定的队列

headers：与 key 无关，消息内容的 headers 属性（一个键值对）和绑定键值对完全匹配时，会发送到此队列。此方式性能低一般不用

【接收】

rabbitmq 的队列是基本存储单元，不再被分区或者分片，对于我们已经创建了的队列，消费端要指定从哪一个队列接收消息。

当 rabbitmq 队列拥有多个消费者的时候，队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者，不会重复。

这种方式非常适合扩展，而且是专门为并发程序设计的。

如果某些消费者的任务比较繁重，那么可以设置 basicQos 限制信道上消费者能保持的最大未确认消息的数量，在达到上限时，rabbitmq 不再向这个消费者发送任何消息。

zeromq：点对点(p2p)

rocketmq：基于 topic/messageTag 以及按照消息类型、属性进行正则匹配的发布订阅模式

【发送】

发送消息通过轮询队列的方式发送，每个队列接收平均的消息量。发送消息指定 topic、tags、keys，无法指定投递到哪个队列（没有意义，集群消费和广播消费跟消息存放在哪个队列没有关系）。

tags 选填，类似于 Gmail 为每封邮件设置的标签，方便服务器过滤使用。目前只支 持每个消息设置一个 tag，所以也可以类比为 Notify 的 MessageType 概念。

keys 选填，代表这条消息的业务关键词，服务器会根据 keys 创建哈希索引，设置后， 可以在 Console 系统根据 Topic、Keys 来查询消息，由于是哈希索引，请尽可能 保证 key 唯一，例如订单号，商品 Id 等。

【接收】

1、广播消费。一条消息被多个 Consumer 消费，即使 Consumer 属于同一个 ConsumerGroup，消息也会被 ConsumerGroup 中的每个 Consumer 都消费一次。

2、集群消费。一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个 Consumer Group 有 3 个实例，那么每个实例只消费其中的 3 条消息。即每一个队列都把消息轮流分发给每个 consumer。

activemq：点对点(p2p)、广播（发布-订阅）

点对点模式，每个消息只有 1 个消费者；

发布/订阅模式，每个消息可以有多个消费者。

【发送】

点对点模式：先要指定一个队列，这个队列会被创建或者已经被创建。

发布/订阅模式：先要指定一个 topic，这个 topic 会被创建或者已经被创建。

【接收】

点对点模式：对于已经创建了的队列，消费端要指定从哪一个队列接收消息。

发布/订阅模式：对于已经创建了的 topic，消费端要指定订阅哪一个 topic 的消息。

13. 顺序消息

Kafka：支持。

设置生产者的 max.in.flight.requests.per.connection 为 1，可以保证消息是按照发送顺序写入服务器的，即使发生了重试。kafka 保证同一个分区里的消息是有序的，但是这种有序分两种情况

1、key 为 null，消息逐个被写入不同主机的分区中，但是对于每个分区依然是有序的

2、key 不为 null , 消息被写入到同一个分区，这个分区的消息都是有序。

rabbitmq：不支持

zeromq：不支持

rocketmq：支持

activemq：不支持

14. 消息确认

Kafka：支持。

1、发送方确认机制

ack=0，不管消息是否成功写入分区

ack=1，消息成功写入首领分区后，返回成功

ack=all，消息成功写入所有分区后，返回成功。

2、接收方确认机制

自动或者手动提交分区偏移量，早期版本的 kafka 偏移量是提交给 Zookeeper 的，这样使得 zookeeper 的压力比较大，更新版本的 kafka 的偏移量是提交给 kafka 服务器的，不再依赖于 zookeeper 群组，集群的性能更加稳定。

rabbitmq：支持。

1、发送方确认机制，消息被投递到所有匹配的队列后，返回成功。如果消息和队列是可持久化的，那么在写入磁盘后，返回成功。支持批量确认和异步确认。

2、接收方确认机制，设置 autoAck 为 false，需要显式确认，设置 autoAck 为 true，自动确认。

当 autoAck 为 false 的时候，rabbitmq 队列会分成两部分，一部分是等待投递给 consumer 的消息，一部分是已经投递但是没收到确认的消息。如果一直没有收到确认信号，并且 consumer 已经断开连接，rabbitmq 会安排这个消息重新进入队列，投递给原来的消费者或者下一个消费者。

未确认的消息不会有过期时间，如果一直没有确认，并且没有断开连接，rabbitmq 会一直等待，rabbitmq 允许一条消息处理的时间可以很久很久。

zeromq：支持。

rocketmq：支持。

activemq：支持。

15. 消息回溯

Kafka：支持指定分区 offset 位置的回溯

rabbitmq：不支持

zeromq：不支持

rocketmq：支持指定时间点的回溯

activemq：不支持

16. 消息重试

Kafka：不支持，但是可以实现。

kafka 支持指定分区 offset 位置的回溯，可以实现消息重试。

rabbitmq：不支持，但是可以利用消息确认机制实现

rabbitmq 接收方确认机制，设置 autoAck 为 false

当 autoAck 为 false 的时候，rabbitmq 队列会分成两部分，一部分是等待投递给 consumer 的消息，一部分是已经投递但是没收到确认的消息。如果一直没有收到确认信号，并且 consumer 已经断开连接，rabbitmq 会安排这个消息重新进入队列，投递给原来的消费者或者下一个消费者。

zeromq：不支持

rocketmq：支持

消息消费失败的大部分场景下，立即重试 99%都会失败，所以 rocketmq 的策略是在消费失败时定时重试，每次时间间隔相同。

1、发送端的 send 方法本身支持内部重试，重试逻辑如下：

a)至多重试 3 次；

b)如果发送失败，则轮转到下一个 broker；

c)这个方法的总耗时不超过 sendMsgTimeout 设置的值，默认 10s，超过时间不在重试。

2、接收端。

Consumer 消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer 消费消息失败通常可以分为以下两种情况：

由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被注销，无法充值）等。定时重试机制，比如过 10s 秒后再重试。

由于依赖的下游应用服务不可用，例如 db 连接不可用，外系统网络不可达等。

即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况可以 sleep 30s，再消费下一条消息，减轻 Broker 重试消息的压力。

activemq：不支持

17. 并发度

Kafka：高

一个线程一个消费者，kafka 限制消费者的个数要小于等于分区数，如果要提高并行度，可以在消费者中再开启多线程，或者增加 consumer 实例数量。

rabbitmq：极高

本身是用 Erlang 语言写的，并发性能高。

可在消费者中开启多线程，最常用的做法是一个 channel 对应一个消费者，每一个线程把持一个 channel，多个线程复用 connection 的 tcp 连接，减少性能开销。

当 rabbitmq 队列拥有多个消费者的时候，队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者，不会重复。

这种方式非常适合扩展，而且是专门为并发程序设计的。

如果某些消费者的任务比较繁重，那么可以设置 basicQos 限制信道上消费者能保持的最大未确认消息的数量，在达到上限时，rabbitmq 不再向这个消费者发送任何消息。

zeromq：高

rocketmq：高

1、rocketmq 限制消费者的个数少于等于队列数，但是可以在消费者中再开启多线程，这一点和 kafka 是一致的，提高并行度的方法相同。

修改消费并行度方法

a) 同一个 ConsumerGroup 下，通过增加 Consumer 实例数量来提高并行度，超过订阅队列数的 Consumer 实例无效。

b) 提高单个 Consumer 的消费并行线程，通过修改参数 consumeThreadMin、consumeThreadMax

2、同一个网络连接 connection，客户端多个线程可以同时发送请求，连接会被复用，减少性能开销。

activemq：高

单个 ActiveMQ 的接收和消费消息的速度在 1 万笔/秒（持久化 一般为 1-2 万， 非持久化 2 万以上），在生产环境中部署 10 个 Activemq 就能达到 10 万笔/秒以上的性能，部署越多的 activemq broker 在 MQ 上 latency 也就越低，系统吞吐量也就越高。

目录

• 什么是流水线
• 声明式流水线
• Jenkinsfile 的使用

jenkins 有 2 种流水线分为声明式流水线与脚本化流水线，脚本化流水线是 jenkins 旧版本使用的流水线脚本，新版本 Jenkins 推荐使用声明式流水线。文档只介绍声明流水线。

在声明式流水线语法中，流水线过程定义在 Pipeline{}中，Pipeline 块定义了整个流水线中完成的所有工作，比如

参数说明：

• agent any：在任何可用的代理上执行流水线或它的任何阶段，也就是执行流水线过程的位置，也可以指定到具体的节点
• stage：定义流水线的执行过程（相当于一个阶段），比如下文所示的 Build、Test、Deploy， 但是这个名字是根据实际情况进行定义的，并非固定的名字
• steps：执行某阶段具体的步骤。

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
    stages {
      stage('Build') {
        steps {
          echo 'Build'
        }
      }
      stage('Test') {
        steps {
          echo 'Test'
        }
      }
      stage('Deploy') {
        steps {
          echo 'Deploy'
      }
    }
  }
}

在脚本化流水线语法中，会有一个或多个 Node（节点）块在整个流水线中执行核心工作

参数说明:

• node：在任何可用的代理上执行流水线或它的任何阶段，也可以指定到具体的节点
• stage：和声明式的含义一致，定义流水线的阶段。Stage 块在脚本化流水线语法中是可选的，然而在脚本化流水线中实现 stage 块，可以清楚地在 Jenkins UI 界面中显示每个 stage 的任务子集。

//Jenkinsfile (Scripted Pipeline)
node {
  stage('Build') {
    echo 'Build'
  }
  stage('Test') {
    echo 'Test'
  }
  stage('Deploy') {
    echo 'Deploy'
  }
}

声明式流水线必须包含在一个 Pipeline 块中，比如是一个 Pipeline 块的格式

pipeline {
  /* insert Declarative Pipeline here */
}

在声明式流水线中有效的基本语句和表达式遵循与 Groovy 的语法同样的规则，但有以下例外

• 流水线顶层必须是一个 block，即 pipeline{}
• 分隔符可以不需要分号，但是每条语句都必须在自己的行上
• 块只能由 Sections、Directives、Steps 或 assignment statements 组成
• 属性引用语句被当做是无参数的方法调用，比如 input 会被当做 input()。

声明式流水线中的 Sections 不是一个关键字或指令，而是包含一个或多个 Agent、Stages、 post、Directives 和 Steps 的代码区域块。

1.1 Agent

Agent 表示整个流水线或特定阶段中的步骤和命令执行的位置，该部分必须在 pipeline 块的顶层被定义，也可以在 stage 中再次定义，但是 stage 级别是可选的。

any

在任何可用的代理上执行流水线，配置语法

pipeline {
  agent any
}

none

表示该 Pipeline 脚本没有全局的 agent 配置。当顶层的 agent 配置为 none 时， 每个 stage 部分都需要包含它自己的 agent。配置语法

pipeline {
  agent none
  stages {
    stage('Stage For Build'){
      agent any
    }
  }
}

label

以节点标签形式选择某个具体的节点执行 Pipeline 命令，例如：agent { label 'my-defined-label' }。节点需要提前配置标签。

pipeline {
  agent none
    stages {
      stage('Stage For Build'){
        agent { label 'role-master' }
        steps {
          echo "role-master"
        }
      }
    }
}

node

和 label 配置类似，只不过是可以添加一些额外的配置，比如 customWorkspace(设置默认工作目录)

pipeline {
  agent none
    stages {
      stage('Stage For Build'){
        agent {
          node {
            label 'role-master'
            customWorkspace "/tmp/zhangzhuo/data"
          }
        }
        steps {
          sh "echo role-master > 1.txt"
        }
      }
    }
}

dockerfile

使用从源码中包含的 Dockerfile 所构建的容器执行流水线或 stage。此时对应的 agent 写法如下

agent {
   dockerfile {
     filename 'Dockerfile.build'  //dockerfile文件名称
     dir 'build'                  //执行构建镜像的工作目录
     label 'role-master'          //执行的node节点，标签选择
     additionalBuildArgs '--build-arg version=1.0.2' //构建参数
   }
}

docker

相当于 dockerfile，可以直接使用 docker 字段指定外部镜像即可，可以省去构建的时间。比如使用 maven 镜像进行打包，同时可以指定 args

agent{
  docker{
    image '192.168.10.15/kubernetes/alpine:latest'   //镜像地址
    label 'role-master' //执行的节点，标签选择
    args '-v /tmp:/tmp'      //启动镜像的参数
  }
}

kubernetes

需要部署 kubernetes 相关的插件，官方文档：

https://github.com/jenkinsci/kubernetes-plugin/

Jenkins 也支持使用 Kubernetes 创建 Slave，也就是常说的动态 Slave。配置示例如下

• cloud: Configure Clouds 的名称，指定到其中一个 k8s

• slaveConnectTimeout: 连接超时时间

• yaml: pod 定义文件，jnlp 容器的配置必须有配置无需改变，其余 containerd 根据自己情况指定

• workspaceVolume：持久化 jenkins 的工作目录。

• persistentVolumeClaimWorkspaceVolume：挂载已有 pvc。

workspaceVolume persistentVolumeClaimWorkspaceVolume(claimName: "jenkins-agent", mountPath: "/", readOnly: "false")

• nfsWorkspaceVolume：挂载 nfs 服务器目录

workspaceVolume nfsWorkspaceVolume(serverAddress: "192.168.10.254", serverPath: "/nfs", readOnly: "false")

• dynamicPVC：动态申请 pvc，任务执行结束后删除

workspaceVolume dynamicPVC(storageClassName: "nfs-client", requestsSize: "1Gi", accessModes: "ReadWriteMany")

• emptyDirWorkspaceVolume：临时目录，任务执行结束后会随着 pod 删除被删除，主要功能多个任务 container 共享 jenkins 工作目录。

workspaceVolume emptyDirWorkspaceVolume()

• hostPathWorkspaceVolume：挂载 node 节点本机目录，注意挂载本机目录注意权限问题，可以先创建设置 777 权限，否则默认 kubelet 创建的目录权限为 755 默认其他用户没有写权限，执行流水线会报错。

workspaceVolume hostPathWorkspaceVolume(hostPath: "/opt/workspace", readOnly: false)

示例

agent {
  kubernetes {
      cloud 'kubernetes'
      slaveConnectTimeout 1200
      workspaceVolume emptyDirWorkspaceVolume()
      yaml '''
kind: Pod
metadata:
  name: jenkins-agent
spec:
  containers:
  - args: ['$(JENKINS_SECRET)', '$(JENKINS_NAME)']
    image: '192.168.10.15/kubernetes/jnlp:alpine'
    name: jnlp
    imagePullPolicy: IfNotPresent
  - command:
      - "cat"
    image: "192.168.10.15/kubernetes/alpine:latest"
    imagePullPolicy: "IfNotPresent"
    name: "date"
    tty: true
  restartPolicy: Never
'''
  }
}

1.2 agent 的配置示例

kubernetes 示例

pipeline {
  agent {
    kubernetes {
      cloud 'kubernetes'
      slaveConnectTimeout 1200
      workspaceVolume emptyDirWorkspaceVolume()
      yaml '''
kind: Pod
metadata:
  name: jenkins-agent
spec:
  containers:
  - args: ['$(JENKINS_SECRET)', '$(JENKINS_NAME)']
    image: '192.168.10.15/kubernetes/jnlp:alpine'
    name: jnlp
    imagePullPolicy: IfNotPresent
  - command:
      - "cat"
    image: "192.168.10.15/kubernetes/alpine:latest"
    imagePullPolicy: "IfNotPresent"
    name: "date"
    tty: true
  - command:
      - "cat"
    image: "192.168.10.15/kubernetes/kubectl:apline"
    imagePullPolicy: "IfNotPresent"
    name: "kubectl"
    tty: true
  restartPolicy: Never
'''
    }
  }
  environment {
    MY_KUBECONFIG = credentials('kubernetes-cluster')
  }
  stages {
    stage('Data') {
      steps {
        container(name: 'date') {
          sh """
            date
          """
        }
      }
    }
    stage('echo') {
      steps {
        container(name: 'date') {
          sh """
            echo 'k8s is pod'
          """
        }
      }
    }
    stage('kubectl') {
      steps {
        container(name: 'kubectl') {
          sh """
            kubectl get pod -A  --kubeconfig $MY_KUBECONFIG
          """
        }
      }
    }
  }
}

docker 的示例

pipeline {
  agent none
  stages {
    stage('Example Build') {
      agent { docker 'maven:3-alpine' }
      steps {
        echo 'Hello, Maven'
        sh 'mvn --version'
      }
    }
    stage('Example Test') {
      agent { docker 'openjdk:8-jre' }
      steps {
        echo 'Hello, JDK'
        sh 'java -version'
      }
    }
  }
}

1.3 Post

Post 一般用于流水线结束后的进一步处理，比如错误通知等。Post 可以针对流水线不同的结果做出不同的处理，就像开发程序的错误处理，比如 Python 语言的 try catch。

Post 可以定义在 Pipeline 或 stage 中，目前支持以下条件

• always：无论 Pipeline 或 stage 的完成状态如何，都允许运行该 post 中定义的指令；
• changed：只有当前 Pipeline 或 stage 的完成状态与它之前的运行不同时，才允许在该 post 部分运行该步骤；
• fixed：当本次 Pipeline 或 stage 成功，且上一次构建是失败或不稳定时，允许运行该 post 中定义的指令；
• regression：当本次 Pipeline 或 stage 的状态为失败、不稳定或终止，且上一次构建的 状态为成功时，允许运行该 post 中定义的指令；
• failure：只有当前 Pipeline 或 stage 的完成状态为失败（failure），才允许在 post 部分运行该步骤，通常这时在 Web 界面中显示为红色
• success：当前状态为成功（success），执行 post 步骤，通常在 Web 界面中显示为蓝色 或绿色
• unstable：当前状态为不稳定（unstable），执行 post 步骤，通常由于测试失败或代码 违规等造成，在 Web 界面中显示为黄色
• aborted：当前状态为终止（aborted），执行该 post 步骤，通常由于流水线被手动终止触发，这时在 Web 界面中显示为灰色；
• unsuccessful：当前状态不是 success 时，执行该 post 步骤；
• cleanup：无论 pipeline 或 stage 的完成状态如何，都允许运行该 post 中定义的指令。和 always 的区别在于，cleanup 会在其它执行之后执行。

示例

一般情况下 post 部分放在流水线的底部，比如本实例，无论 stage 的完成状态如何，都会输出一条 I will always say Hello again!信息

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  stages {
    stage('Example1') {
      steps {
        echo 'Hello World1'
      }
    }
    stage('Example2') {
      steps {
        echo 'Hello World2'
      }
    }
  }
  post {
    always {
      echo 'I will always say Hello again!'
    }
  }
}

也可以将 post 写在 stage，下面示例表示 Example1 执行失败执行 post。

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  stages {
    stage('Example1') {
      steps {
        sh 'ip a'
      }
      post {
        failure {
          echo 'I will always say Hello again!'
        }
      }
    }
  }
}

1.4 sepes

Steps 部分在给定的 stage 指令中执行的一个或多个步骤，比如在 steps 定义执行一条 shell 命令

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  stages {
    stage('Example') {
      steps {
        echo 'Hello World'
      }
    }
  }
}

或者是使用 sh 字段执行多条指令

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  stages {
    stage('Example') {
      steps {
        sh """
           echo 'Hello World1'
           echo 'Hello World2'
        """
      }
    }
  }
}

Directives 可用于一些执行 stage 时的条件判断或预处理一些数据，和 Sections 一致，Directives 不是一个关键字或指令，而是包含了 environment、options、parameters、triggers、stage、tools、 input、when 等配置。

2.1 Environment

Environment 主要用于在流水线中配置的一些环境变量，根据配置的位置决定环境变量的作用域。可以定义在 pipeline 中作为全局变量，也可以配置在 stage 中作为该 stage 的环境变量。该指令支持一个特殊的方法 credentials()，该方法可用于在 Jenkins 环境中通过标识符访问预定义的凭证。对于类型为 Secret Text 的凭证，credentials()可以将该 Secret 中的文本内容赋值给环境变量。对于类型为标准的账号密码型的凭证，指定的环境变量为 username 和 password，并且也会定义两个额外的环境变量，分别为MYVARNAME_USR和MYVARNAME_PSW。

基本变量使用

//示例
pipeline {
  agent any
  environment {   //全局变量，会在所有stage中生效
    NAME= 'zhangzhuo'
  }
  stages {
    stage('env1') {
      environment { //定义在stage中的变量只会在当前stage生效，其他的stage不会生效
        HARBOR = 'https://192.168.10.15'
      }
      steps {
        sh "env"
      }
    }
    stage('env2') {
      steps {
        sh "env"
      }
    }
  }
}

使用变量引用 secret 的凭证

//这里使用k8s的kubeconfig文件示例
pipeline {
  agent any
  environment {
    KUBECONFIG = credentials('kubernetes-cluster')
  }
  stages {
    stage('env') {
      steps {
        sh "env"  //默认情况下输出的变量内容会被加密
      }
    }
  }
}

使用变量引用类型为标准的账号密码型的凭证

这里使用 HARBOR 变量进行演示，默认情况下账号密码型的凭证会自动创建 3 个变量

• HARBOR_USR:会把凭证中 username 值赋值给这个变量
• HARBOR_PSW:会把凭证中 password 值赋值给这个变量
• HARBOR:默认情况下赋值的值为usernamme:password

//这里使用k8s的kubeconfig文件示例
pipeline {
  agent any
  environment {
    HARBOR = credentials('harbor-account')
  }
  stages {
    stage('env') {
      steps {
        sh "env"
      }
    }
  }
}

2.2 Options

Jenkins 流水线支持很多内置指令，比如 retry 可以对失败的步骤进行重复执行 n 次，可以根据不同的指令实现不同的效果。比较常用的指令如下:

• buildDiscarder ：保留多少个流水线的构建记录
• disableConcurrentBuilds：禁止流水线并行执行，防止并行流水线同时访问共享资源导致流水线失败。
• disableResume ：如果控制器重启，禁止流水线自动恢复。
• newContainerPerStage：agent 为 docker 或 dockerfile 时，每个阶段将在同一个节点的新容器中运行，而不是所有的阶段都在同一个容器中运行。
• quietPeriod：流水线静默期，也就是触发流水线后等待一会在执行。
• retry：流水线失败后重试次数。
• timeout：设置流水线的超时时间，超过流水线时间，job 会自动终止。如果不加 unit 参数默认为 1 分。
• timestamps：为控制台输出时间戳。

定义在 pipeline 中

pipeline {
  agent any
  options {
    timeout(time: 1, unit: 'HOURS')  //超时时间1小时，如果不加unit参数默认为1分
    timestamps()                     //所有输出每行都会打印时间戳
    buildDiscarder(logRotator(numToKeepStr: '3')) //保留三个历史构建版本
    quietPeriod(10)  //注意手动触发的构建不生效
    retry(3)    //流水线失败后重试次数
  }
  stages {
    stage('env1') {
      steps {
        sh "env"
        sleep 2
      }
    }
    stage('env2') {
      steps {
        sh "env"
      }
    }
  }
}

定义在 stage 中

Option 除了写在 Pipeline 顶层，还可以写在 stage 中，但是写在 stage 中的 option 仅支持 retry、 timeout、timestamps，或者是和 stage 相关的声明式选项，比如 skipDefaultCheckout。处于 stage 级别的 options 写法如下

pipeline {
  agent any
  stages {
    stage('env1') {
      options {   //定义在这里这对这个stage生效
        timeout(time: 2, unit: 'SECONDS') //超时时间2秒
        timestamps()                     //所有输出每行都会打印时间戳
        retry(3)    //流水线失败后重试次数
      }
      steps {
        sh "env && sleep 2"
      }
    }
    stage('env2') {
      steps {
        sh "env"
      }
    }
  }
}

2.3 Parameters

Parameters 提供了一个用户在触发流水线时应该提供的参数列表，这些用户指定参数的值可以通过 params 对象提供给流水线的 step（步骤）。只能定义在 pipeline 顶层。

目前支持的参数类型如下

• string：字符串类型的参数。
• text：文本型参数，一般用于定义多行文本内容的变量。
• booleanParam：布尔型参数。
• choice：选择型参数，一般用于给定几个可选的值，然后选择其中一个进行赋值。
• password：密码型变量，一般用于定义敏感型变量，在 Jenkins 控制台会输出为*。

插件 Parameters

• imageTag：镜像 tag，需要安装 Image Tag Parameter 插件后使用
• gitParameter：获取 git 仓库分支，需要 Git Parameter 插件后使用

示例

pipeline {
  agent any
  parameters {
    string(name: 'DEPLOY_ENV', defaultValue:  'staging', description: '1')   //执行构建时需要手动配置字符串类型参数，之后赋值给变量
    text(name:  'DEPLOY_TEXT', defaultValue: 'OnenTwonThreen', description: '2')  //执行构建时需要提供文本参数，之后赋值给变量
    booleanParam(name: 'DEBUG_BUILD',  defaultValue: true, description: '3')   //布尔型参数
    choice(name: 'CHOICES', choices: ['one', 'two', 'three'], description: '4')  //选择形式列表参数
    password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'A  secret password')  //密码类型参数，会进行加密
    imageTag(name: 'DOCKER_IMAGE', description: '', image: 'kubernetes/kubectl', filter: '.*', defaultTag: '', registry: 'https://192.168.10.15', credentialId: 'harbor-account', tagOrder: 'NATURAL')   //获取镜像名称与tag
    gitParameter(branch: '', branchFilter: 'origin/(.*)', defaultValue: '', description: 'Branch for build and deploy', name: 'BRANCH', quickFilterEnabled: false, selectedValue: 'NONE', sortMode: 'NONE',  tagFilter: '*', type: 'PT_BRANCH')
  }  //获取git仓库分支列表，必须有git引用
  stages {
    stage('env1') {
      steps {
        sh "env"
      }
    }
    stage('git') {
      steps {
        git branch: "$BRANCH", credentialsId: 'gitlab-key', url: 'git@192.168.10.14:root/env.git'   //使用gitParameter，必须有这个
      }
    }
  }
}

2.4 Triggers

在 Pipeline 中可以用 triggers 实现自动触发流水线执行任务，可以通过 Webhook、Cron、 pollSCM 和 upstream 等方式触发流水线。

Cron

定时构建假如某个流水线构建的时间比较长，或者某个流水线需要定期在某个时间段执行构建，可以 使用 cron 配置触发器，比如周一到周五每隔四个小时执行一次

注意：H 的意思不是 HOURS 的意思，而是 Hash 的缩写。主要为了解决多个流水线在同一时间同时运行带来的系统负载压力。

pipeline {
  agent any
  triggers {
    cron('H */4 * * 1-5')   //周一到周五每隔四个小时执行一次
    cron('H/12 * * * *')   //每隔12分钟执行一次
    cron('H * * * *')   //每隔1小时执行一次
  }
  stages {
    stage('Example') {
      steps {
        echo 'Hello World'
      }
    }
  }
}

Upstream

Upstream 可以根据上游 job 的执行结果决定是否触发该流水线。比如当 job1 或 job2 执行成功时触发该流水线

目前支持的状态有 SUCCESS、UNSTABLE、FAILURE、NOT_BUILT、ABORTED 等。

pipeline {
  agent any
  triggers {
    upstream(upstreamProjects: 'env', threshold: hudson.model.Result.SUCCESS)  //当env构建成功时构建这个流水线
  }
  stages {
    stage('Example') {
      steps {
        echo 'Hello World'
      }
    }
  }
}

2.5 Input

Input 字段可以实现在流水线中进行交互式操作，比如选择要部署的环境、是否继续执行某个阶段等。

配置 Input 支持以下选项

• message：必选，需要用户进行 input 的提示信息，比如：“是否发布到生产环境？”；
• id：可选，input 的标识符，默认为 stage 的名称；
• ok：可选，确认按钮的显示信息，比如：“确定”、“允许”；
• submitter：可选，允许提交 input 操作的用户或组的名称，如果为空，任何登录用户均可提交 input；
• parameters：提供一个参数列表供 input 使用。

假如需要配置一个提示消息为“还继续么”、确认按钮为“继续”、提供一个 PERSON 的变量的参数，并且只能由登录用户为 alice 和 bob 提交的 input 流水线

pipeline {
  agent any
  stages {
    stage('Example') {
      input {
        message "还继续么?"
        ok "继续"
        submitter "alice,bob"
        parameters {
          string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
        }
      }
      steps {
        echo "Hello, ${PERSON}, nice to meet you."
      }
    }
  }
}

2.6 when

When 指令允许流水线根据给定的条件决定是否应该执行该 stage，when 指令必须包含至少 一个条件。如果 when 包含多个条件，所有的子条件必须都返回 True，stage 才能执行。

When 也可以结合 not、allOf、anyOf 语法达到更灵活的条件匹配。

目前比较常用的内置条件如下

• branch：当正在构建的分支与给定的分支匹配时，执行这个 stage。注意，branch 只适用于多分支流水线
• changelog：匹配提交的 changeLog 决定是否构建，例如:when { changelog '.*^\[DEPENDENCY\] .+$' }
• environment：当指定的环境变量和给定的变量匹配时，执行这个 stage，例如：when { environment name: 'DEPLOY_TO', value: 'production' }
• equals：当期望值和实际值相同时，执行这个 stage，例如：when { equals expected: 2, actual: currentBuild.number }；
• expression：当指定的 Groovy 表达式评估为 True，执行这个 stage，例如：when { expression { return params.DEBUG_BUILD } }；
• tag：如果 TAG_NAME 的值和给定的条件匹配，执行这个 stage，例如：when { tag "release-" }；
• not：当嵌套条件出现错误时，执行这个 stage，必须包含一个条件，例如：when { not { branch 'master' } }；
• allOf：当所有的嵌套条件都正确时，执行这个 stage，必须包含至少一个条件，例如：when { allOf { branch 'master'; environment name: 'DEPLOY_TO', value: 'production' } }；
• anyOf：当至少有一个嵌套条件为 True 时，执行这个 stage，例如：when { anyOf { branch 'master'; branch 'staging' } }。

示例：当分支为 main 时执行 Example Deploy 步骤

pipeline {
  agent any
  stages {
    stage('Example Build') {
      steps {
        echo 'Hello World'
      }
    }
    stage('Example Deploy') {
      when {
        branch 'main' //多分支流水线，分支为才会执行。
      }
      steps {
        echo 'Deploying'
      }
    }
  }
}

也可以同时配置多个条件，比如分支是 production，而且 DEPLOY_TO 变量的值为 main 时，才执行 Example Deploy

pipeline {
  agent any
  environment {
    DEPLOY_TO = "main"
  }
  stages {
    stage('Example Deploy') {
      when {
        branch 'main'
        environment name: 'DEPLOY_TO', value: 'main'
      }
      steps {
        echo 'Deploying'
      }
    }
  }
}

也可以使用 anyOf 进行匹配其中一个条件即可，比如分支为 main 或 DEPLOY_TO 为 main 或 master 时执行 Deploy

pipeline {
  agent any
  stages {
    stage('Example Deploy') {
      when {
        anyOf {
          branch 'main'
          environment name: 'DEPLOY_TO', value: 'main'
          environment name: 'DEPLOY_TO', value: 'master'
        }
      }
      steps {
        echo 'Deploying'
      }
    }
  }
}

也可以使用 expression 进行正则匹配，比如当 BRANCH_NAME 为 main 或 master，并且 DEPLOY_TO 为 master 或 main 时才会执行 Example Deploy

pipeline {
  agent any
  stages {
    stage('Example Deploy') {
      when {
        expression { BRANCH_NAME ==~ /(main|master)/ }
        anyOf {
          environment name: 'DEPLOY_TO', value: 'main'
          environment name: 'DEPLOY_TO', value: 'master'
        }
      }
      steps {
        echo 'Deploying'
      }
    }
  }
}

默认情况下，如果定义了某个 stage 的 agent，在进入该 stage 的 agent 后，该 stage 的 when 条件才会被评估，但是可以通过一些选项更改此选项。比如在进入 stage 的 agent 前评估 when， 可以使用 beforeAgent，当 when 为 true 时才进行该 stage

目前支持的前置条件如下

• beforeAgent：如果 beforeAgent 为 true，则会先评估 when 条件。在 when 条件为 true 时，才会进入该 stage
• beforeInput：如果 beforeInput 为 true，则会先评估 when 条件。在 when 条件为 true 时，才会进入到 input 阶段；
• beforeOptions：如果 beforeInput 为 true，则会先评估 when 条件。在 when 条件为 true 时，才会进入到 options 阶段；
• beforeOptions 优先级大于 beforeInput 大于 beforeAgent

示例

pipeline {
  agent none
  stages {
    stage('Example Build') {
      steps {
        echo 'Hello World'
      }
    }
    stage('Example Deploy') {
      when {
        beforeAgent true
        branch 'main'
      }
      steps {
        echo 'Deploying'
      }
    }
  }
}

在声明式流水线中可以使用 Parallel 字段，即可很方便的实现并发构建，比如对分支 A、B、 C 进行并行处理

pipeline {
  agent any
  stages {
    stage('Non-Parallel Stage') {
      steps {
        echo 'This stage will be executed first.'
      }
    }
    stage('Parallel Stage') {
      failFast true         //表示其中只要有一个分支构建执行失败，就直接推出不等待其他分支构建
      parallel {
        stage('Branch A') {
          steps {
            echo "On Branch A"
          }
        }
        stage('Branch B') {
          steps {
            echo "On Branch B"
          }
        }
        stage('Branch C') {
          stages {
            stage('Nested 1') {
              steps {
                echo "In stage Nested 1 within Branch C"
              }
            }
            stage('Nested 2') {
              steps {
               echo "In stage Nested 2 within Branch C"
              }
            }
          }
        }
      }
    }
  }
}

上面讲过流水线支持两种语法，即声明式和脚本式，这两种语法都支持构建持续交付流水线。并且都可以用来在 Web UI 或 Jenkinsfile 中定义流水线，不过通常将 Jenkinsfile 放置于代码仓库中（当然也可以放在单独的代码仓库中进行管理）。

创建一个 Jenkinsfile 并将其放置于代码仓库中，有以下好处

• 方便对流水线上的代码进行复查/迭代
• 对管道进行审计跟踪
• 流水线真正的源代码能够被项目的多个成员查看和编辑

1.1 静态变量

Jenkins 有许多内置变量可以直接在 Jenkinsfile 中使用，可以通过 JENKINS_URL/pipeline/syntax/globals#env 获取完整列表。目前比较常用的环境变量如下

• BUILD_ID：当前构建的 ID，与 Jenkins 版本 1.597+中的 BUILD_NUMBER 完全相同
• BUILD_NUMBER：当前构建的 ID，和 BUILD_ID 一致
• BUILD_TAG：用来标识构建的版本号，格式为：jenkins-{BUILD_NUMBER}， 可以对产物进行命名，比如生产的 jar 包名字、镜像的 TAG 等；
• BUILD_URL：本次构建的完整 URL，比如：http://buildserver/jenkins/job/MyJobName/17/%EF%BC%9B
• JOB_NAME：本次构建的项目名称
• NODE_NAME：当前构建节点的名称；
• JENKINS_URL：Jenkins 完整的 URL，需要在 SystemConfiguration 设置；
• WORKSPACE：执行构建的工作目录。

示例如果一个流水线名称为print_env，第 2 次构建，各个变量的值。

BUILD_ID：2
BUILD_NUMBER：2
BUILD_TAG：jenkins-print_env-2
BUILD_URL：http://192.168.10.16:8080/job/print_env/2/
JOB_NAME：print_env
NODE_NAME：built-in
JENKINS_URL：http://192.168.10.16:8080/
WORKSPACE：/bitnami/jenkins/home/workspace/print_env

上述变量会保存在一个 Map 中，可以使用 env.BUILD_ID 或 env.JENKINS_URL 引用某个内置变量

pipeline {
  agent any
  stages {
    stage('print env') {
      parallel {
        stage('BUILD_ID') {
          steps {
            echo "$env.BUILD_ID"
          }
        }
        stage('BUILD_NUMBER') {
          steps {
            echo "$env.BUILD_NUMBER"
          }
        }
        stage('BUILD_TAG') {
          steps {
            echo "$env.BUILD_TAG"
          }
        }
      }
    }
  }
}

1.2 动态变量

动态变量是根据某个指令的结果进行动态赋值，变量的值根据指令的执行结果而不同。如下所示

• returnStdout：将命令的执行结果赋值给变量，比如下述的命令返回的是 clang，此时 CC 的值为“clang”。
• returnStatus：将命令的执行状态赋值给变量，比如下述命令的执行状态为 1，此时 EXIT_STATUS 的值为 1。

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  environment {
    // 使用 returnStdout
    CC = """${sh(
         returnStdout: true,
         script: 'echo -n "clang"'   //如果使用shell命令的echo赋值变量最好加-n取消换行
         )}"""
    // 使用 returnStatus
    EXIT_STATUS = """${sh(
         returnStatus: true,
         script: 'exit 1'
         )}"""
  }
  stages {
    stage('Example') {
      environment {
        DEBUG_FLAGS = '-g'
      }
      steps {
        sh 'printenv'
      }
    }
  }
}

Jenkins 的声明式流水线语法有一个 credentials()函数，它支持 secret text（加密文本）、username 和 password（用户名和密码）以及 secret file（加密文件）等。接下来看一下一些常用的凭证处理方法。

2.1 加密文本

本实例演示将两个 Secret 文本凭证分配给单独的环境变量来访问 Amazon Web 服务，需要 提前创建这两个文件的 credentials（实践的章节会有演示），Jenkinsfile 文件的内容如下

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  environment {
    AWS_ACCESS_KEY_ID = credentials('txt1')
    AWS_SECRET_ACCESS_KEY = credentials('txt2')
  }
  stages {
    stage('Example stage 1') {
      steps {
        echo "$AWS_ACCESS_KEY_ID"
      }
    }
    stage('Example stage 2') {
      steps {
        echo "$AWS_SECRET_ACCESS_KEY"
      }
    }
  }
}

2.2 用户名密码

本示例用来演示 credentials 账号密码的使用，比如使用一个公用账户访问 Bitbucket、GitLab、 Harbor 等。假设已经配置完成了用户名密码形式的 credentials，凭证 ID 为 harbor-account

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  environment {
    BITBUCKET_COMMON_CREDS = credentials('harbor-account')
  }
  stages {
    stage('printenv') {
      steps {
        sh "env"
      }
    }
}

上述的配置会自动生成 3 个环境变量

• BITBUCKET_COMMON_CREDS：包含一个以冒号分隔的用户名和密码，格式为 username:password
• BITBUCKET_COMMON_CREDS_USR：仅包含用户名的附加变量
• BITBUCKET_COMMON_CREDS_PSW：仅包含密码的附加变量。

2.3 加密文件

需要加密保存的文件，也可以使用 credential，比如链接到 Kubernetes 集群的 kubeconfig 文件等。

假如已经配置好了一个 kubeconfig 文件，此时可以在 Pipeline 中引用该文件

//Jenkinsfile (Declarative Pipeline)
pipeline {
  agent {
    kubernetes {
      cloud 'kubernetes'
      slaveConnectTimeout 1200
      workspaceVolume emptyDirWorkspaceVolume()
      yaml '''
kind: Pod
metadata:
  name: jenkins-agent
spec:
  containers:
  - args: ['$(JENKINS_SECRET)', '$(JENKINS_NAME)']
    image: '192.168.10.15/kubernetes/jnlp:alpine'
    name: jnlp
    imagePullPolicy: IfNotPresent
  - command:
      - "cat"
    image: "192.168.10.15/kubernetes/kubectl:apline"
    imagePullPolicy: "IfNotPresent"
    name: "kubectl"
    tty: true
  restartPolicy: Never
'''
    }
  }
  environment {
    MY_KUBECONFIG = credentials('kubernetes-cluster')
  }
  stages {
    stage('kubectl') {
      steps {
        container(name: 'kubectl') {
          sh """
            kubectl get pod -A  --kubeconfig $MY_KUBECONFIG
          """
        }
      }
    }
  }
}

• 架构和设计的对比
  
• 查询对比实战
  
• 总结

前言

Elasticsearch 是一个实时的分布式搜索分析引擎，它的底层是构建在Lucene之上的。简单来说是通过扩展Lucene的搜索能力，使其具有分布式的功能。ES通常会和其它两个开源组件logstash（日志采集）和Kibana（仪表盘）一起提供端到端的日志/搜索分析的功能，常常被简称为ELK。

Clickhouse是俄罗斯搜索巨头Yandex开发的面向列式存储的关系型数据库。ClickHouse是过去两年中OLAP领域中最热门的，并于2016年开源。

ES是最为流行的大数据日志和搜索解决方案，但是近几年来，它的江湖地位受到了一些挑战，许多公司已经开始把自己的日志解决方案从ES迁移到了Clickhouse，这里就包括：携程，快手等公司。

ES的底层是Lucenc，主要是要解决搜索的问题。搜索是大数据领域要解决的一个常见的问题，就是在海量的数据量要如何按照条件找到需要的数据。搜索的核心技术是倒排索引和布隆过滤器。ES通过分布式技术，利用分片与副本机制，直接解决了集群下搜索性能与高可用的问题。

ElasticSearch是为分布式设计的，有很好的扩展性，在一个典型的分布式配置中，每一个节点（node）可以配制成不同的角色，如下图所示：

• Client Node，负责API和数据的访问的节点，不存储／处理数据
• Data Node，负责数据的存储和索引
• Master Node， 管理节点，负责Cluster中的节点的协调，不存储数据。

ClickHouse是基于MPP架构的分布式ROLAP（关系OLAP）分析引擎。每个节点都有同等的责任，并负责部分数据处理（不共享任何内容）。ClickHouse 是一个真正的列式数据库管理系统（DBMS)。在 ClickHouse 中，数据始终是按列存储的，包括矢量（向量或列块）执行的过程。让查询变得更快，最简单且有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储和数据压缩就可以帮助实现上述两点。Clickhouse同时使用了日志合并树，稀疏索引和CPU功能（如SIMD单指令多数据）充分发挥了硬件优势，可实现高效的计算。Clickhouse 使用Zookeeper进行分布式节点之间的协调。

为了支持搜索，Clickhouse同样支持布隆过滤器。

为了对比ES和Clickhouse的基本查询能力的差异，我写了一些代码（https://github.com/gangtao/esvsch）来验证。

这个测试的架构如下：

架构主要有四个部分组成：

• ES stack ES stack有一个单节点的Elastic的容器和一个Kibana容器组成，Elastic是被测目标之一，Kibana作为验证和辅助工具。部署代码如下：

version: '3.7'

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.4.0
    container_name: elasticsearch
    environment:
      - xpack.security.enabled=false
      - discovery.type=single-node
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    cap_add:
      - IPC_LOCK
    volumes:
      - elasticsearch-data:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
      - 9300:9300
    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 4096M
        reservations:
          memory: 4096M

  kibana:
    container_name: kibana
    image: docker.elastic.co/kibana/kibana:7.4.0
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - 5601:5601
    depends_on:
      - elasticsearch

volumes:
  elasticsearch-data:
    driver: local

• Clickhouse stack Clickhouse stack有一个单节点的Clickhouse服务容器和一个TabixUI作为Clickhouse的客户端。部署代码如下：

version: "3.7"
services:
  clickhouse:
    container_name: clickhouse
    image: yandex/clickhouse-server
    volumes:
      - ./data/config:/var/lib/clickhouse
    ports:
      - "8123:8123"
      - "9000:9000"
      - "9009:9009"
      - "9004:9004"
    ulimits:
      nproc: 65535
      nofile:
        soft: 262144
        hard: 262144
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "localhost:8123/ping"]
      interval: 30s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 4096M
        reservations:
          memory: 4096M

  tabixui:
    container_name: tabixui
    image: spoonest/clickhouse-tabix-web-client
    environment:
      - CH_NAME=dev
      - CH_HOST=127.0.0.1:8123
      - CH_LOGIN=default
    ports:
      - "18080:80"
    depends_on:
      - clickhouse
    deploy:
      resources:
        limits:
          cpus: '0.1'
          memory: 128M
        reservations:
          memory: 128M

• 数据导入 stack 数据导入部分使用了Vector.dev开发的vector，该工具和fluentd类似，都可以实现数据管道式的灵活的数据导入。
• 测试控制 stack 测试控制我使用了Jupyter，使用了ES和Clickhouse的Python SDK来进行查询的测试。

用Docker compose启动ES和Clickhouse的stack后，我们需要导入数据，我们利用Vector的generator功能，生成syslog，并同时导入ES和Clickhouse，在这之前，我们需要在Clickhouse上创建表。ES的索引没有固定模式，所以不需要事先创建索引。

创建表的代码如下：

CREATE TABLE default.syslog(
    application String,
    hostname String,
    message String,
    mid String,
    pid String,
    priority Int16,
    raw String,
    timestamp DateTime('UTC'),
    version Int16
) ENGINE = MergeTree()
    PARTITION BY toYYYYMMDD(timestamp)
    ORDER BY timestamp
    TTL timestamp + toIntervalMonth(1);

创建好表之后，我们就可以启动vector，向两个stack写入数据了。vector的数据流水线的定义如下：

[sources.in]
  type = "generator"
  format = "syslog"
  interval = 0.01
  count = 100000

[transforms.clone_message]
  type = "add_fields"
  inputs = ["in"]
  fields.raw = "{{ message }}"

[transforms.parser]
  # General
  type = "regex_parser"
  inputs = ["clone_message"]
  field = "message" # optional, default
  patterns = ['^d*)>(?Pd) (?Pd{4}-d{2}-d{2}Td{2}:d{2}:d{2}.d{3}Z) (?Pw+.w+) (?Pw+) (?Pd+) (?PIDd+) - (?P.*)$']

[transforms.coercer]
  type = "coercer"
  inputs = ["parser"]
  types.timestamp = "timestamp"
  types.version = "int"
  types.priority = "int"

[sinks.out_console]
  # General
  type = "console"
  inputs = ["coercer"]
  target = "stdout"

  # Encoding
  encoding.codec = "json"


[sinks.out_clickhouse]
  host = "http://host.docker.internal:8123"
  inputs = ["coercer"]
  table = "syslog"
  type = "clickhouse"

  encoding.only_fields = ["application", "hostname", "message", "mid", "pid", "priority", "raw", "timestamp", "version"]
  encoding.timestamp_format = "unix"

[sinks.out_es]
  # General
  type = "elasticsearch"
  inputs = ["coercer"]
  compression = "none"
  endpoint = "http://host.docker.internal:9200"
  index = "syslog-%F"

  # Encoding

  # Healthcheck
  healthcheck.enabled = true

这里简单介绍一下这个流水线：

• http://source.in 生成syslog的模拟数据，生成10w条，生成间隔和0.01秒
• transforms.clone_message 把原始消息复制一份，这样抽取的信息同时可以保留原始消息
• transforms.parser 使用正则表达式，按照syslog的定义，抽取出application，hostname，message ，mid ，pid ，priority ，timestamp ，version 这几个字段
• transforms.coercer 数据类型转化
• sinks.out_console 把生成的数据打印到控制台，供开发调试
• sinks.out_clickhouse 把生成的数据发送到Clickhouse
• sinks.out_es 把生成的数据发送到ES

运行Docker命令，执行该流水线：

docker run 
  -v $(mkfile_path)/vector.toml:/etc/vector/vector.toml:ro 
  -p 18383:8383 
  timberio/vector:nightly-alpine

数据导入后，我们针对一下的查询来做一个对比。ES使用自己的查询语言来进行查询，Clickhouse支持SQL，我简单测试了一些常见的查询，并对它们的功能和性能做一些比较。

• 返回所有的记录

# ES
{
  "query":{
    "match_all":{}
  }
}

# Clickhouse
"SELECT * FROM syslog"

• 匹配单个字段

# ES
{
  "query":{
    "match":{
      "hostname":"for.org"
    }
  }
}

# Clickhouse
"SELECT * FROM syslog WHERE hostname='for.org'"

• 匹配多个字段

# ES
{
  "query":{
    "multi_match":{
      "query":"up.com ahmadajmi",
        "fields":[
          "hostname",
          "application"
        ]
    }
  }
}

# Clickhouse、
"SELECT * FROM syslog WHERE hostname='for.org' OR application='ahmadajmi'"

• 单词查找，查找包含特定单词的字段

# ES
{
  "query":{
    "term":{
      "message":"pretty"
    }
  }
}

# Clickhouse
"SELECT * FROM syslog WHERE lowerUTF8(raw) LIKE '%pretty%'"

• 范围查询， 查找版本大于2的记录

# ES
{
  "query":{
    "range":{
      "version":{
        "gte":2
      }
    }
  }
}

# Clickhouse
"SELECT * FROM syslog WHERE version >= 2"

• 查找到存在某字段的记录
  ES是文档类型的数据库，每一个文档的模式不固定，所以会存在某字段不存在的情况；而Clickhouse对应为字段为空值

# ES
{
  "query":{
    "exists":{
      "field":"application"
    }
  }
}

# Clickhouse
"SELECT * FROM syslog WHERE application is not NULL"

• 正则表达式查询，查询匹配某个正则表达式的数据

# ES
{
  "query":{
    "regexp":{
      "hostname":{
        "value":"up.*",
          "flags":"ALL",
            "max_determinized_states":10000,
              "rewrite":"constant_score"
      }
    }
  }
}

# Clickhouse
"SELECT * FROM syslog WHERE match(hostname, 'up.*')"

• 聚合计数，统计某个字段出现的次数

# ES
{
  "aggs":{
    "version_count":{
      "value_count":{
        "field":"version"
      }
    }
  }
}

# Clickhouse
"SELECT count(version) FROM syslog"

• 聚合不重复的值，查找所有不重复的字段的个数

# ES
{
  "aggs":{
    "my-agg-name":{
      "cardinality":{
        "field":"priority"
      }
    }
  }
}

# Clickhouse
"SELECT count(distinct(priority)) FROM syslog "

我用Python的SDK，对上述的查询在两个Stack上各跑10次，然后统计查询的性能结果。

我们画出出所有的查询的响应时间的分布：

总查询时间的对比如下：

通过测试数据我们可以看出Clickhouse在大部分的查询的性能上都明显要优于Elastic。在正则查询（Regex query）和单词查询（Term query）等搜索常见的场景下，也并不逊色。

在聚合场景下，Clickhouse表现异常优秀，充分发挥了列村引擎的优势。

注意，我的测试并没有任何优化，对于Clickhouse也没有打开布隆过滤器。可见Clickhouse确实是一款非常优秀的数据库，可以用于某些搜索的场景。当然ES还支持非常丰富的查询功能，这里只有一些非常基本的查询，有些查询可能存在无法用SQL表达的情况。

本文通过对于一些基本查询的测试，对比了Clickhouse 和Elasticsearch的功能和性能，测试结果表明，Clickhouse在这些基本场景表现非常优秀，性能优于ES，这也解释了为什么用很多的公司应从ES切换到Clickhouse之上。

大家好，昨晚看到 IDEA 官推宣布 IntelliJ IDEA 2023.1 正式发布了。简单看了一下，发现这次的新版本包含了许多改进，进一步优化了用户体验，提高了便捷性。

至于是否升级最新版本完全是个人意愿，如果觉得新版本没有让自己感兴趣的改进，完全就不用升级，影响不大。软件的版本迭代非常正常，正确看待即可，不持续改进就会慢慢被淘汰！

根据官方介绍：

IntelliJ IDEA 2023.1 针对新的用户界面进行了大量重构，这些改进都是基于收到的宝贵反馈而实现的。官方还实施了性能增强措施，使得 Maven 导入更快，并且在打开项目时 IDE 功能更早地可用。由于后台提交检查，新版本提供了简化的提交流程。IntelliJ IDEA Ultimate 现在支持 Spring Security 匹配器和请求映射导航。

下面对这个版本的一些比较有意思的改进进行详细介绍。

新 UI 增强（测试版）

针对收到的有关 IDE 新用户界面的反馈，IntelliJ IDEA 官方实施了一些更新，以解决最受欢迎的请求。引入了紧凑模式，通过缩小间距和元素提供更加集中的 IDE 外观和感觉。新 UI 现在提供一个选项来垂直分割工具窗口区域，并方便地排列窗口，就像旧 UI 一样。主窗口标题栏中的运行小部件已经重新设计，使其外观不显眼且更易于查看。

在项目打开时更早提供 IDE 功能

IntelliJ IDEA 官方通过在智能模式下执行扫描文件以建立索引的过程来改进了 IDE 启动体验，这样即可使 IDE 的全部功能在启动过程中更早地可用。当打开一个项目时，IntelliJ IDEA 2023.1 会使用上一次与该项目的会话中存在的缓存，并同时查找要建立索引的文件。如果扫描中没有发现任何更改，则 IDE 将准备就绪，消除了之前由于启动时进行索引而导致的延迟。

更快地导入 Maven 项目

官方通过优化依赖解析以及重新设计导入和配置 facets 的过程，显著提高了 IDE 在导入 Maven 项目时的性能。

后台提交检查

官方重新设计了 Git 和 Mercurial 的提交检查行为，以加速整个提交过程。现在，在提交但尚未推送之前会在后台执行检查。

Spring Security 匹配器和请求映射的导航

为了简化查看应用安全规则，IntelliJ IDEA Ultimate 2023.1 提供了从 Spring 控制器到安全匹配器的轻松导航。该导航可以从安全匹配器到控制器以及反向工作。

全 IDE 缩放

在 v2023.1 中，可以完全放大和缩小 IDE，同时增加或缩减所有 UI 元素的大小。从主菜单中，选择 View | Appearance（视图 | 外观），调整 IDE 的缩放比例。此外，您可以在 Settings/Preferences | Keymap | Main Menu | View | Appearance（设置/偏好设置 | 按键映射 | 主菜单 | 视图 | 外观）中指定调用这些操作的自定义快捷键。

新的 Java 检查

官方为了帮助保持代码整洁和无错误，升级了一些现有的 Java 检查，并添加了新的检查。格式不正确字符串检查现在报告不符合常见 Java 语法的非法时间转换。冗余字符串操作检查现在能够检测到多余的 StringBuilder.toString() 调用，并提供一个快速修复来将它们替换为 contentEquals()，以便您不会创建中间 String 对象。它还报告 String 构造函数调用中不必要的参数，并建议一个快速修复来删除它们。在这篇博客文章中了解更多关于 IntelliJ IDEA 2023.1 其他代码检查改进。

Java 20 支持

继续减少 Java 开发人员认知负荷，IntelliJ IDEA 2023.1 支持最新更新添加到 Java 20 中，包括语言特性模式匹配和记录模式的更改。

改进了 Extract Method（提取方法）重构

官方通过引入选项来升级提取方法重构，即使所选代码片段具有需要返回的多个变量也可以应用该选项。在这些情况下，IDE 首先建议将这些变量封装到一个新记录或 bean 类中，然后执行方法提取。

VM Options（虚拟机选项）字段中的自动补全

自动补全功能以及集成到 Run/Debug configuration（运行/调试配置）弹出窗口的 VM Options（虚拟机选项）字段中。现在，输入标志的名称时，IDE 会建议可用命令行选项的列表。这适用于 -XX: 和 -X 选项，以及一些未由 IntelliJ IDEA 自动配置的标准选项，如 -ea，但不适用于 -cp 或 –release。

Spring Security 6 支持

IntelliJ IDEA Ultimate 2023.1 提供了更新的支持，可以导航到 Spring Security 6 中引入的 API 的 URL 映射和安全角色。

Apache Dubbo 支持

IntelliJ IDEA 实现了一个新的专用插件，集成了 Apache Dubbo，将该框架的功能作为 IntelliJ IDEA 对 Spring 的支持的一部分。

Structure（结构）工具窗口中的 VCS 状态颜色提示

针对 GitHub 改进了代码审查工作流

为了简化在 IDE 中审查代码的过程，重做了 Pull Request（拉取请求）工具窗口。它现在为您打开的每个拉取请求提供一个专用标签页。标签页会立即显示已更改文件的列表，但它提供的信息比先前更少，让您可以更好地专注于当前任务。现在，可以通过一个新增的专属按钮轻松执行拉取请求当前状态下最相关的操作。

参考资料

IntelliJ IDEA 2023.1 更多改进的介绍请参考官方文档：https://www.jetbrains.com/zh-cn/idea/whatsnew/

快乐分享，Java干货及时送达👇

nginx-proxy-manager 是一个反向代理管理系统，它基于 NGINX，具有漂亮干净的 Web UI。还可以获得受信任的 SSL 证书，并通过单独的配置、自定义和入侵保护来管理多个代理。它是开源的，斩获 11.8K 的 Star 数。

特征

• 基于 Tabler(https://tabler.github.io/) 的美观安全的管理界面
• 无需了解 Nginx 即可轻松创建转发域、重定向、流和 404 主机
• 使用 Let’s Encrypt 的免费 SSL 或提供您自己的自定义 SSL 证书
• 主机的访问列表和基本 HTTP 身份验证
• 高级 Nginx 配置可供超级用户使用
• 用户管理、权限和审核日志

安装

1、安装 Docker 和 Docker-Compose

2、创建一个docker-compose.yml文件

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

3、运行

docker-compose up -d

#如果使用的是 docker-compose-plugin
docker compose up -d

4、访问网页

运行成功后，访问 http://127.0.0.1:81 就能看到界面啦

5、登录

网站默认账号和密码为

账号：admin@example.com
密码：changeme

登录成功后第一次要求修改密码，按照步骤修改即可！

6、登录成功主界面

实战：设置后台管理界面的反向代理

这里，我们就用 http://a.test.com 来绑定我们的端口号为81的后台管理界面，实现浏览器输入 http://a.test.com 即可访问后台管理界面，并且设置HTTPS。

1、前提

• 安装好Nginx Proxy Manager
• 拥有一个域名
• 将 http://a.test.com 解析到安装Nginx Proxy Manager的服务器ip地址上

2、反向代理操作

先用ip:81 访问后台管理界面，然后输入账号密码进入后台。

点击绿色图标的选项

点击右边Add Proxy Host ，在弹出的界面Details选项中填写相应的字段。

• Domain Names: 填写要反向代理的域名，这里就是http://a.test.com
• Forward Hostname / IP: 填写的ip值见下文解释
• Forward Port: 反向代理的端口，这里就是81
• Block Common Exploits: 开启后阻止一些常见漏洞
• 其余两个暂不知作用

Forward Hostname / IP填写说明

如果搭建的服务和nginx proxy manager服务所在不是一个服务器，则填写能访问对应服务的IP。如果都在同一台服务器上，则填写在服务器中输入ip addr show docker0 命令获取得到的ip。

这里不填127.0.0.1的原因是使用的是docker容器搭建web应用，docker容器和宿主机即服务器不在同一个网络下，所以127.0.0.1并不能访问到宿主机，而ip addr show docker0获得的ip地址就是宿主机地址。

接下来即可用a.test.com 访问后台管理界面，此时还只是http协议，没有https。不过此时就可以把之前的81端口关闭了，输入a.test.com 访问的是服务器80端口，然后在转发给内部的81端口。

3、申请ssl证书

申请一个a.test.com 证书，这样就可以提供https访问了。

在Nginx Proxy Manager管理后台，选择Access Lists->Add SSL Certificate->Let's Encrypt选项。

按照下图方式填写，点击Save就可以了

4、设置HTTPS

进入反向代理设置界面，编辑上文创建的反代服务，选择SSL选项，下拉菜单中选择我们申请的证书，然后可以勾选Force SSL即强制HTTPS。

总结

以上就是本教程的全部内容，更多的使用教程，大家可以访问官方文档。

官方文档：https://nginxproxymanager.com/guide/