方案设计文档

背景和目标

本方案旨在优化现有系统的内置应用管理方式，通过外置化内置应用、精简 Dockerfile 以及调整应用市场功能，来实现减小镜像大小、简化工程维护，并增强内置应用的灵活性和可维护性。

主要调整内容

  1. 内置应用外置化
  2. 精简 Dockerfile
  3. 应用市场调整
  4. 通过 MinIO 挂载方式加载应用

详细方案

1. 内置应用外置化

目标：

  • 将内置应用与普通应用一样，通过挂载的方式统一加载到 apps 目录下。

好处：

  • 减小镜像大小。
  • 减少引擎代码工程中内置应用的 jar 包维护，使项目工程更简洁。
  • 可直接沿用已有的apps目录作为挂载点。

2. 精简 Dockerfile

目标：

  • 去掉 Dockerfile 中的 cp 命令，不再需要拷贝源码中的内置应用到镜像中。

实现步骤：

  • 删除 Dockerfile 中与内置应用相关的 COPY 和 CMD 命令。

3. 应用市场调整

目标：

  • 调整应用市场功能，允许安装内置应用，并通过种子数据的方式预安装所有的内置应用，同时支持内置应用的升级。

实现步骤：

  • 修改应用市场的配置和逻辑，允许内置应用的安装和升级。
  • 通过种子数据的方式预先配置所有内置应用，并在系统初始化时自动安装这些应用。

4. 通过 MinIO 挂载方式加载应用

目标：

  • 通过将存储应用市场 jar 的 MinIO 挂载到镜像中，直接加载内置应用和业务应用，而不需要下载 jar。

实现步骤：

  • 使用 Kubernetes 的 CSI（Container Storage Interface）驱动将 MinIO 存储挂载到容器中，更为具体方式参考业界方案。
  • 修改应用的启动脚本或配置文件，使其能够从挂载的 MinIO 目录中加载应用。

示例： 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  csi:
    driver: minio.csi.min.io
    volumeHandle: "minio-volume"
    volumeAttributes:
      bucket: "apps"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: minio-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

---

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
    - name: app-container
      image: my-app-image
      volumeMounts:
        - mountPath: "/apps"
          name: minio-apps
  volumes:
    - name: minio-apps
      persistentVolumeClaim:
        claimName: minio-pvc

总结

通过上述方案，内置应用不再打包在镜像中，而是通过挂载的方式统一加载到 apps 目录下。此举不仅减小了镜像大小，还简化了工程维护。同时，应用市场也进行了相应调整，允许安装内置应用并支持其升级。最后，作为更简洁的方式，可考虑通过 MinIO 挂载的方式加载应用，进一步简化了应用的加载过程。 此外，可解决在多个容器同时启动时并发拷贝内置应用可能导致的 jar 包找不到的 bug，如下： pic http://iidp.chinasie.com:9999/iidpminio/home/error.png

Table of Contents