Nessie Docker镜像文档

镜像概述和主要用途

Nessie是一个开源的数据湖版本控制系统，支持在提交更改前进行隔离的数据实验。Bitnami Nessie镜像提供了一种简单、安全且可扩展的方式来部署Nessie，适用于开发和生产环境。

了解Nessie概述

核心功能和特性

• 支持数据版本控制，实现隔离的数据实验
• 提供多种版本存储后端（JDBC、RocksDB、内存存储等）
• 集成Prometheus指标监控
• 支持分布式追踪
• 可配置的认证机制
• 灵活的资源管理和部署选项
• 与Kubernetes生态系统紧密集成

使用场景和适用范围

• 数据湖版本管理和变更控制
• 数据科学实验和模型训练
• 数据治理和合规性管理
• 多团队协作的数据环境
• 数据管道开发和测试
• 大数据分析平台的版本化需求

详细的使用方法和配置说明

快速入门

helm install my-release oci://registry-1.docker.io/bitnamicharts/nessie

如需在生产环境中使用Nessie，建议尝试VMware Tanzu Application Catalog，即Bitnami目录的商业版本。

⚠️ 重要通知：Bitnami目录即将变更

自2025年8月28日起，Bitnami将改进其公共目录，通过新的Bitnami Secure Images计划提供精选的强化安全型镜像。作为此过渡的一部分：

• 首次向社区用户提供流行容器镜像的安全优化版本访问权限
• Bitnami将开始在其免费层级中弃用对非强化的基于Debian的软件镜像的支持，并将逐步从公共目录中移除非最新标签。因此，社区用户将只能访问数量减少的强化镜像，这些镜像仅以"latest"标签发布，适用于开发目的
• 从8月28日开始，在两周内，所有现有容器镜像，包括旧版本或特定版本标签（如2.50.0、10.6）将从公共目录（docker.io/bitnami）迁移到"Bitnami Legacy"仓库（docker.io/bitnamilegacy），迁移后将不再接收更新
• 对于生产工作负载和长期支持，建议用户采用Bitnami Secure Images，包括强化容器、更小的攻击面、CVE透明度（通过VEX/KEV）、SBOM和企业支持

这些变更旨在通过促进软件供应链完整性和最新部署的最佳实践，提高所有Bitnami用户的安全态势。有关更多详细信息，请访问Bitnami Secure Images公告。

简介

此chart使用Helm包管理器在Kubernetes集群上引导Nessie部署。

先决条件

• Kubernetes 1.23+
• Helm 3.8.0+

安装Chart

要安装发布名称为my-release的chart：

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/nessie

注意：需要将占位符REGISTRY_NAME和REPOSITORY_NAME替换为Helm chart仓库和存储库的引用。例如，对于Bitnami，需要使用REGISTRY_NAME=registry-1.docker.io和REPOSITORY_NAME=bitnamicharts。

该命令使用默认配置在Kubernetes集群上部署Nessie。参数部分列出了可在安装过程中配置的参数。

提示：使用helm list列出所有发布

卸载Chart

要卸载/删除my-release部署：

helm delete my-release

该命令将删除与chart关联的所有Kubernetes组件并删除发布。

配置和安装详情

资源请求和限制

Bitnami charts允许为chart部署内的所有容器设置资源请求和限制。这些设置位于resources值内（参见参数表）。设置请求对于生产工作负载至关重要，应根据具体用例进行调整。

为简化此过程，chart包含resourcesPreset值，可根据不同预设自动设置resources部分。在bitnami/common chart中查看这些预设。但是，在生产工作负载中不建议使用resourcesPreset，因为它可能无法完全适应您的特定需求。有关容器资源管理的更多信息，请参阅Kubernetes官方文档。

备份和恢复

要在Kubernetes上备份和恢复Helm chart部署，需要备份源部署的持久卷并使用Velero（Kubernetes备份/恢复工具）将其附加到新部署。在本指南中查找使用Velero的说明。

Prometheus指标

通过将metrics.enabled设置为true，此chart可以与Prometheus集成。这将在服务中公开Nessie原生Prometheus端点，并包含必要的注解以被Prometheus自动抓取。

Prometheus要求

要使集成工作，必须安装Prometheus或Prometheus Operator。安装Bitnami Prometheus helm chart或Bitnami Kube Prometheus helm chart，可以轻松在集群中部署Prometheus。

与Prometheus Operator集成

该chart可以部署ServiceMonitor对象，用于与Prometheus Operator集成。要实现此目的，设置值metrics.serviceMonitor.enabled=true。确保在集群中安装了Prometheus OperatorCustomResourceDefinitions，否则将失败并显示以下错误：

no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

安装Bitnami Kube Prometheus helm chart以获取必要的CRD和Prometheus Operator。

滚动标签与不可变标签

在生产环境中强烈建议使用不可变标签。这可确保如果相同标签使用不同镜像更新，部署不会自动更改。

如果主容器有新版本、重大更改或严重漏洞，Bitnami将发布新chart来更新其容器。

Nessie应用属性

该chart支持通过两个参数设置Nessie应用属性：

• configOverrides：覆盖非敏感应用属性，如quarkus.micrometer.enabled。支持嵌套和普通YAML格式
• secretConfigOverrides：覆盖敏感应用属性，如quarkus.datasource.postgresql.password。支持嵌套和普通YAML格式

在以下示例中，我们使用configOverrides禁用HTTP访问日志和HTTP解压缩：

configOverrides:
  quarkus:
    http:
      access-log:
        enabled: false
      enable-decompression: false

或者，可以使用外部配置映射和外部密钥进行此配置：existingConfigmap和existingSecret。

注意：配置覆盖优先于chart值。例如，通过configOverrides设置quarkus.http.port将使containerPorts.http无效。

启用追踪

在以下示例中，我们按照上游Nessie文档启用遥测（替换TRACE_ENDPOINT占位符）：

configOverrides:
  quarkus.otel.exporter.otlp.traces.endpoint: TRACE_ENDPOINT

在上游Quarkus文档中找到可用属性的完整列表。在以下示例中，我们还定义了两次连续导出之间的延迟：

configOverrides:
  quarkus.otel.exporter.otlp.traces.endpoint: TRACE_ENDPOINT
  quarkus.otel.bsp.schedule.delay: 10S

支持的版本存储类型

此chart原生支持以下版本存储方法：

• JDBC with PostgreSQL：设置versionStoreType=JDBC_POSTGRESQL。如果使用嵌入式PostgreSQL子chart，设置postgresql.enabled=true。如果使用外部PostgreSQL，设置postgresql.enabled=false并配置externalDatabase部分（参见相应部分）
• RocksDB：设置versionStoreType=ROCKSDB和persistence.enabled=true以保持发布之间的持久性。注意，这将创建一个PVC，供Deployment的所有副本共享
• 内存存储：设置versionStoreType=IN_MEMORY

可以通过使用configOverrides和secretConfigOverrides配置其他存储后端，设置适当的应用属性。在以下部分中，我们展示两个示例：

使用Bitnami MariaDB helm chart作为版本存储

在以下示例中，我们将安装Bitnami MariaDB helm chart并配置Nessie使用它作为版本存储。替换DB_USER、DB_DATABASE和DB_PASSWORD占位符。

helm install mariadb oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb --set auth.username=DB_USER --set auth.database=DB_DATABASE --set auth.password=DB_PASSWORD

然后使用以下值安装Nessie helm chart：

#
# JDBC MariaDB示例
#
versionStoreType: JDBC
# 此部分将进入ConfigMap
configOverrides:
  nessie.version.store.persist.jdbc.datasource: mariadb
  quarkus.datasource.mariadb.username: DB_USER
  quarkus.datasource.mariadb.jdbc.url: jdbc:mariadb://mariadb:3306/DB_DATABASE
# 此部分将进入Secret
secretConfigOverrides:
  quarkus.datasource.mariadb.password: DB_PASSWORD
postgresql:
  enabled: false

使用Bitnami MongoDB helm chart作为版本存储

在以下示例中，我们将安装Bitnami MongoDB helm chart并配置Nessie使用它作为版本存储。替换DB_USER、DB_DATABASE和DB_PASSWORD占位符。

helm install mongodb oci://REGISTRY_NAME/REPOSITORY_NAME/mongodb --set auth.usernames[0]=DB_USER --set auth.passwords[0]=DB_PASSWORD --set auth.databases[0]=DB_DATABASE

然后使用以下值安装Nessie helm chart：

#
# MongoDB示例
#
versionStoreType: MONGODB
# 此部分将进入ConfigMap
configOverrides:
  quarkus.mongodb.database: DB_DATABASE
# 此部分将进入Secret
secretConfigOverrides:
  quarkus.mongodb.connection-string: mongodb://DB_USER:DB_PASSWORD@mongodb:27017
postgresql:
  enabled: false

使用外部OIDC提供商进行身份验证

Nessie允许使用外部OIDC提供商进行身份验证。可以使用configOverrides和secretConfigOverrides值进行配置。替换OIDC_SERVER_URL、OIDC_SECRET和OIDC_CLIENT_ID占位符：

configOverrides:
  nessie.server.authentication.enabled: true
  quarkus.oidc.auth-server-url: OIDC_SERVER_URL
secretConfigOverrides:
  quarkus.oidc.credentials.secret: OIDC_SECRET
  quarkus.oidc.client-id: OIDC_CLIENT_ID

额外环境变量

如果需要添加额外的环境变量（对于高级操作如自定义初始化脚本很有用），可以使用extraEnvVars属性。

extraEnvVars:
  - name: LOG_LEVEL
    value: error

或者，可以使用包含环境变量的ConfigMap或Secret。为此，使用extraEnvVarsCM或extraEnvVarsSecret值。

边车容器

如果在与nessie相同的pod中需要额外的容器（如额外的指标或日志导出器），可以使用sidecars参数定义它们。

sidecars:
- name: your-image-name
  image: your-image
  imagePullPolicy: Always
  ports:
  - name: portname
    containerPort: 1234

如果这些边车容器导出额外的端口，可以使用service.extraPorts参数添加额外的端口定义（如果可用），如下例所示：

service:
  server:
    extraPorts:
    - name: extraPort
      port: 11311
      targetPort: 11311

如果在同一个pod中需要额外的初始化容器，可以使用initContainers参数定义它们。以下是一个示例：

initContainers:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
      - name: portname
        containerPort: 1234

了解更多关于边车容器和初始化容器的信息。

Pod亲和性

此chart允许使用affinity参数设置自定义亲和性。在kubernetes文档中找到有关Pod亲和性的更多信息。

作为替代方案，可以使用bitnami/commonchart中提供的pod亲和性、pod反亲和性和节点亲和性的预设配置之一。为此，设置podAffinityPreset、podAntiAffinityPreset或nodeAffinityPreset参数。

部署额外资源

在某些情况下，可能需要部署额外的对象，如包含应用配置的ConfigMap或应用使用的微服务的额外部署。为满足这种情况，chart允许使用extraDeploy参数添加其他对象的完整规范。

配置Ingress

此chart提供对Ingress资源的支持。如果集群上安装了ingress控制器，如nginx-ingress-controller或contour，可以利用ingress控制器来服务应用。要启用Ingress集成，将ingress.enabled设置为true。

最常见的场景是将一个主机名映射到部署。在这种情况下，可以使用ingress.hostname属性设置主机名。ingress.tls参数可用于为此主机添加TLS配置。

但是，也可以有多个主机。为方便起见，可以将ingress.extraHosts参数（如果可用）设置为指定为数组的主机名。ingress.extraTLS参数（如果可用）也可用于为额外的主机添加TLS配置。

注意：对于ingress.extraHosts参数中指定的每个主机，需要设置名称、路径以及Ingress控制器应了解的任何注解。并非所有注解都受所有Ingress控制器支持，但此注解参考文档列出了许多流行Ingress控制器支持的注解。

添加TLS参数（如果可用）将导致chart生成HTTPS URL，应用将在端口443上可用。TLS密钥不必由此chart生成。但是，如果启用了TLS，则Ingress记录在TLS密钥存在之前将无法工作。

了解更多关于Ingress控制器。

配置用于Ingress的TLS密钥

此chart便于创建用于Ingress控制器的TLS密钥（尽管这不是强制性的）。有几种常见用例：

• 基于chart参数生成证书密钥
• 启用外部生成的证书
• 通过外部服务（如cert-manager）管理应用证书
• 在chart内创建自签名证书（如果支持）

在前两种情况下，需要证书和密钥。文件应为.pem格式。

以下是证书文件的示例：

注意：如果存在证书链，可能有多个证书。

-----BEGIN CERTIFICATE-----
MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
...
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
-----END CERTIFICATE-----

以下是证书密钥的示例：

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
...
wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX