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 暴露给工作节点。

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

你有没有思考过 rkerke2等 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 架构

    rocketmq4.x-arch.png

  • RocketMQ 5.X 架构

    rocketmq5.x-arch.png

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

- 阅读剩余部分 -