HBuilderX 目前仅支持 Windows 和 macOS，这给发布流水线造成不小的阻碍，我们最初的做法是在一台 Windows 上安装 HBuilderX、Jenkins（下文称之为HXJenkins），HXJenkins 使用 HBuilder cli 命令行打包，主 Jenkins 调用 HXJenkins API 进行构建。我们实践之后，发现不少问题：

• HXJenkins 打包 h5，我们要制作成容器镜像，打包后的 dist 需要回传给 Linux 服务器，Linux 服务器再制作容器镜像。流程非常复杂，还需要考虑文件如何回传等问题；
• HBuilder cli 时不时会出现打不开项目的问题，需要重启 HBuilderX
• 有时打包会特别的慢，且容易报错
• 主 Jenkins 调用 HXJenkins API 进行构建，HXJenkins 构建报错上游无法知道，增加心智负担
• ……

我们希望能实现基于容器的 uniapp 打包方案，经过在 DCloud 官网及搜索一番了解后，主要的方案有两个：

1. HBuilderX 项目转为 vue cli 项目
2. 底层都是 node，HBuilderX 只是把操作封装罢了，因此研究 HBuilderX 的打包原理，通过一些技术手段分析 HBuilderX 最终是执行的什么命令来打包的

方案一相对简单，也是本文所探讨的方案，但是可能在你的项目上实践不会轻而易举就能成功，一般会在依赖包以及依赖包的版本上会踩坑。

方案二相对复杂，但是通用性应该更好，方案二已经有大佬写了博客以及在 github 上维护了源码，有兴趣的读者请参考 漫谈Uniapp App热更新包-Jenkins CI/CD打包工具链的搭建_uniapp jenkins-CSDN博客。

- 阅读剩余部分 -

Dockerfile 最佳实践

现阶段 docker-cli 仍然是最流行的容器镜像构建工具之一，因此本文以 Docker 作为构建工具举例，其它构建工具同样适用。

选择合适的基础镜像

为减少镜像大小和提高安全性，应选择一个包含应用程序所需最小依赖项的基础镜像。同时，确保该基础镜像得到及时更新和维护。

以下是一些建议帮助你选择合适的基础镜像：

1. 最小化基础镜像：选择 Alpine Linux 等轻量级发行版作为基础镜像，可以显著减小最终镜像的大小。
2. 官方镜像：优先考虑使用官方提供的镜像，如在 Docker Hub 上的官方镜像仓库，如 docker.io/library/<name>。官方镜像是经过良好测试和维护的，通常包含了稳定的基础环境和常用的工具包。
3. 语言和框架特定镜像：对于特定编程语言或框架，如 Node.js、Python、Java、Ruby 等，使用对应的语言环境镜像，如 node:<version>, python:<version>, openjdk:<version>, ruby:<version> 等。这些镜像包含了运行语言应用所需的基本环境和工具。
4. 安全更新：关注基础镜像的安全更新。官方镜像通常会定期更新补丁，选择最新的稳定版本有助于确保安全性。
5. 应用需求：根据应用的需求选择基础镜像，例如，若应用需要 Apache 或 Nginx 服务器，则可以选择相应的官方镜像作为基础。
6. OS 特性：考虑到 OS 的特性，有些应用可能需要完整的操作系统环境，例如 apt-get 或 yum 包管理器等，此时可能需要 Debian 或 CentOS 类似的完整发行版镜像。
7. 尺寸与便利权衡：虽然较小的基础镜像有利于减少部署时间和节省磁盘空间，但是过于精简的镜像可能缺乏某些常用工具或库，需要根据具体情况权衡。
8. 社区支持与成熟度：选择活跃社区支持且较为成熟的镜像，以便于遇到问题时能找到更多资源和支持。

- 阅读剩余部分 -

Kubernetesg官网中有这么一张图，使用 kubeadm 引导的 Kubernetes 集群，使用负载均衡器将kube-apiserver 暴露给工作节点。

如果你使用过rke、rke2等 Kubernetes 发行版，你会发现，他们并没有使用负载均衡器也能实现 kube-apiserver 的高可用。

你有没有思考过 rke、rke2等 Kubernetes 发行版是如何做 kube-apiserver 的高可用的呢？

要搞清楚这个问题，我们看一下 kubelet 是如何连接 kube-apiserver 的就有答案了。

- 阅读剩余部分 -

查看证书有效期

kubeadm安装的kubernetes集群查看证书有效期

kubeadm certs list

这个命令将列出所有当前使用的证书，包括其名称、状态和过期时间。

rke安装的kubernetes集群查看证书有效期

for i in /etc/kubernetes/ssl/*.pem; do echo $i; openssl x509 -noout -dates -in $i; done

rke2安装的kubernetes集群查看证书有效期

控制节点：

for i in /var/lib/rancher/rke2/server/tls/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

for i in /var/lib/rancher/rke2/server/tls/*/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

工作节点：

for i in /var/lib/rancher/rke2/agent/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

- 阅读剩余部分 -

背景

RacketMQ 5.X 的发布，向云原生迈出了一大步。从官方的文档中，我们可以看到其中最大的一块变化是新增了 Proxy 模块，新旧版本架构对比如下：

• RocketMQ 4.X 架构

  

• RocketMQ 5.X 架构

  

在 RocketMQ4.X 的时候，深入使用过 RocketMQ 的人很多都可能遇到一个问题，RocketMQ 在复杂网络下是有缺陷的，比如说网上就有很多人问 RocketMQ 如何同时对内网和外网提供服务。得到的答案可能是让你修改brokerIP1、brokerIP2，brokerIP1 指向公网IP，brokerIP2 指向内网IP。但是这样并不能解决问题，因为 NameServer 始终会向客户端返回 brokerIP1 的地址，并不是真正解决了内外网的问题。

- 阅读剩余部分 -