后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载本指南基于 Prisma 1.12 版本逐步讲解如何将一个完整的 Prisma 数据库服务含 MySQL 存储后端部署到生产级 Kubernetes 集群涵盖命名空间隔离、持久化存储、无状态 Pod 部署、Service 内部负载均衡、ConfigMap 配置注入以及通过kubectl port-forward打通本地 Prisma CLI 与集群内服务等全部关键环节。读完本文你将掌握一套可复制的 Kubernetes 部署范式并能用prisma deploy向集群内的 Prisma 服务器推送数据模型。本文所有 Kubernetes 定义文件均可按原文路径在本地kubernetes-demo目录中依次创建并应用对应的 Docker Compose 配置方式可参考仓库中的 本地 Docker 部署教程.md)服务器配置的底层解析逻辑见 ConfigLoader.scala。前置准备在开始部署之前需要满足以下两个前置条件一个运行中的 Kubernetes 集群例如托管在 Google Cloud Platform 上的 Kubernetes EngineGKE。本教程刻意保持 Provider 无关——因为 Kubernetes 本身就是一层抽象不同云厂商的差异仅体现在创建Persistent Volume持久化卷的机制上其余步骤完全一致。本地可用的kubectl一个已配置好、能够与目标集群通信的 kubectl 命令行工具。完成上述准备后在本地创建一个名为kubernetes-demo的工作目录本文所有 YAML 文件都将在该目录下按相对路径创建与维护。第一步创建独立的 NamespaceKubernetes 提供了namespace命名空间这一原语用于对工作负载进行逻辑分组。合理使用命名空间可以避免不同环境如 dev、staging、production之间互相干扰也便于后续通过标签与资源配额统一管理。在kubernetes-demo目录下创建namespace.ymlapiVersion: v1 kind: Namespace metadata: name: prisma该定义将创建一个名为prisma的命名空间。通过kubectl应用它kubectl apply -f namespace.yml随后可用kubectl get namespaces验证命名空间是否创建成功。在一个全新的集群上输出大致如下❯ kubectl get namespaces NAME STATUS AGE default Active 1d kube-public Active 1d kube-system Active 1d prisma Active 2s可以看到prisma命名空间已经处于Active状态后续所有资源数据库、Prisma 服务器、Service都将部署在这个命名空间内。第二步部署 MySQL 数据库Prisma 支持多种主流数据库系统如 PostgreSQL、MongoDB 等。本教程以 MySQL 为例但所涉及的步骤可以轻松迁移到其他数据库——只需替换镜像与连接参数。磁盘供给创建 PersistentVolumeClaim数据库天然是有状态stateful的部署需要一块磁盘来持久化数据。Kubernetes 通过PersistentVolumeClaimPVC来向集群请求一块磁盘kind: PersistentVolumeClaim apiVersion: v1 metadata: name: database-disk namespace: prisma labels: stage: production name: database app: mysql spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi这里向集群请求了一块容量为20GB的磁盘accessModes: ReadWriteOnce表示该磁盘同一时间仅能被一个节点以读写方式挂载——这正是单实例数据库的典型诉求。应用该 PVCkubectl apply -f database/pvc.yml几秒钟后在 Google Cloud Platform 的磁盘概览页面就能看到新创建的磁盘。值得注意的是不同云厂商创建持久化卷的机制略有差异这是本教程中唯一因 Provider 不同而需要调整的部分其余资源定义可以原样复用。部署数据库 PodKubernetes 提供Pod与ReplicationController两个核心原语Pod类似于一台虚拟机容器化应用运行其中拥有独立的内部 IP 地址并可挂载磁盘ReplicationController负责将 Pod 调度到集群节点并保证 Pod 按配置的副本数持续运行。在较新的 Kubernetes 版本中这两者被合并进了新的资源类型Deployment你只需声明容器镜像、副本数量以及要挂载的磁盘调度与自愈由控制面完成。MySQL 的 Deployment 定义如下apiVersion: extensions/v1beta1 kind: Deployment metadata: name: database namespace: prisma labels: stage: production name: database app: mysql spec: replicas: 1 strategy: type: Recreate template: metadata: labels: stage: production name: database app: mysql spec: containers: - name: mysql image: mysql:5.7 args: - --ignore-db-dirlostfound env: - name: MYSQL_ROOT_PASSWORD value: prisma ports: - name: mysql-3306 containerPort: 3306 volumeMounts: - name: database-disk readOnly: false mountPath: /var/lib/mysql volumes: - name: database-disk persistentVolumeClaim: claimName: database-disk该定义的关键点replicas: 1调度一个 Pod 副本image: mysql:5.7容器基于官方 MySQL 5.7 镜像env将 MySQLroot用户的密码设置为prisma生产环境应改用 Secret 注入避免明文写在定义文件中args: --ignore-db-dirlostfound避免 MySQL 初始化时因挂载点下的lostfound目录而报错strategy: Recreate更新时先销毁旧 Pod 再创建新 Pod适合这种磁盘仅支持单节点读写挂载的场景volumeMountsvolumes将 PVCdatabase-disk挂载到容器的/var/lib/mysqlMySQL 数据目录实现数据持久化。应用该定义kubectl apply -f database/deployment.yml检查 Pod 是否成功调度kubectl get pods --namespace prisma NAME READY STATUS RESTARTS AGE database-3199294884-93hw4 1/1 Running 0 1mPod 处于Running状态数据库实例已经正常运行。部署数据库 ServiceMySQL Pod 现在已在集群内部运行Kubernetes 为其分配了一个内部 IP。但这里存在一个隐患如果数据库 Pod 崩溃控制面会重新调度一个新 Pod此时新 Pod 会被分配不同的 IP 地址导致所有依赖该 IP 的应用随之崩溃。为解决这个问题Kubernetes 提供了Service原语——一个可通过服务名访问的内部负载均衡器。它负责将流量转发到匹配的 Pod们并让整个集群通过稳定的服务名访问后端从而屏蔽 Pod IP 的变化。MySQL 的 Service 定义如下apiVersion: v1 kind: Service metadata: name: database namespace: prisma spec: ports: - port: 3306 targetPort: 3306 protocol: TCP selector: stage: production name: database app: mysql关于spec的两个核心字段ports将 Service 端口映射到容器端口这里为3306 → 3306selector类似于查询条件负载均衡器通过匹配 Pod 上的标签来筛选目标 Pod。这里正是选中了前面 Deployment 中带stage: production、name: database、app: mysql三个标签的 MySQL Pod。应用并验证kubectl apply -f database/service.yml kubectl get services --namespace prisma NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE database ClusterIP 10.3.241.165 none 3306/TCP 1mTYPE: ClusterIP表明这是一个仅集群内部可达的服务从此刻起集群内的任何应用都可以通过服务名database访问 MySQL。第三步部署 Prisma 服务器数据库就绪后接下来部署真正的 Prisma 服务器。它作为 Prisma CLI 的端点与前面部署的database服务通信并将其作为存储后端。与 MySQL 不同Prisma 服务器是无状态应用——它不需要任何额外的磁盘存储因此部署更简单。注入配置部署 ConfigMapPrisma 服务器需要数据库连接信息以及使用哪个 connector。这类配置最适合用ConfigMap承载——它像一个独立的配置文件内容可以被注入为环境变量。配置内容正是本仓库服务器端实际解析的PRISMA_CONFIG其完整字段解析逻辑见 ConfigLoader.scala 中的tryLoad/convertToConfig/readExplicitDb实现apiVersion: v1 kind: ConfigMap metadata: name: prisma-configmap namespace: prisma labels: stage: production name: prisma app: prisma data: PRISMA_CONFIG: | port: 4466 # uncomment the next line and provide the env var PRISMA_MANAGEMENT_API_SECRETmy-secret to activate cluster security # managementApiSecret: my-secret databases: default: connector: mysql host: database port: 3306 user: root password: prisma migrations: true对PRISMA_CONFIG各字段的说明port: 4466Prisma 服务器监听端口仓库server/docker-compose/mysql/prisma.yml中的本地示例同样使用 4466managementApiSecret默认注释掉集群安全开关。取消注释并设置该值后Prisma CLI 的所有请求都需要携带此密钥未配置时为无鉴权的公开集群。仓库中 Docker 部署参考文档 也强调了该字段是 CLI 向服务器鉴权的凭据databases.default声明服务器连接的数据库其中connector: mysql指定使用 MySQL 连接器可替换为postgres或mongohost: database正是引用上一步创建的 Service 名集群内部 DNS 会解析它user/password与 MySQL 容器的凭据保持一致migrations: true启用迁移功能在 ConfigLoader.scala 中migrations或active被解析为数据库的 active 标志允许prisma deploy自动执行 schema 迁移若设置为false则数据库被视作被动passive连接。从源码角度印证ConfigLoader.tryLoad优先读取环境变量PRISMA_CONFIG其次回退到工作目录下的prisma.yml/prisma.yaml文件由PRISMA_CONFIG_PATH指定最后兼容旧版独立环境变量。也就是说这里通过 ConfigMap 注入的PRISMA_CONFIG环境变量正是服务器配置的主入口。应用 ConfigMapkubectl apply -f prisma/configmap.yml部署 Prisma Pod定义 Prisma 服务器的 DeploymentapiVersion: extensions/v1beta1 kind: Deployment metadata: name: prisma namespace: prisma labels: stage: production name: prisma app: prisma spec: replicas: 1 strategy: type: Recreate template: metadata: labels: stage: production name: prisma app: prisma spec: containers: - name: prisma image: prismagraphql/prisma:1.12 ports: - name: prisma-4466 containerPort: 4466 env: - name: PRISMA_CONFIG valueFrom: configMapKeyRef: name: prisma-configmap key: PRISMA_CONFIG这份定义与 MySQL Deployment 结构类似调度 1 个副本容器镜像为prismagraphql/prisma:1.12并通过configMapKeyRef将前面 ConfigMap 中的PRISMA_CONFIG键注入为环境变量——这正是 ConfigMap 注入配置的标准姿势Prisma 服务器启动时即从该环境变量加载全部配置。应用并验证kubectl apply -f prisma/deployment.yml kubectl get pods --namespace prisma NAME READY STATUS RESTARTS AGE database-3199294884-93hw4 1/1 Running 0 5m prisma-1733176504-zlphg 1/1 Running 0 1m数据库与 Prisma 两个 Pod 都处于Running状态。部署 Prisma ServicePrisma Pod 虽然已经运行但还缺少前置的负载均衡器Service。补上它apiVersion: v1 kind: Service metadata: name: prisma namespace: prisma spec: ports: - port: 4466 targetPort: 4466 protocol: TCP selector: stage: production name: prisma app: prisma应用kubectl apply -f prisma/service.yml至此Prisma 服务器已在 Kubernetes 集群内通过服务名prisma对外可达。整个集群的链路为Service(prisma:4466) → Pod(prismagraphql/prisma:1.12) → Service(database:3306) → Pod(mysql:5.7) PVC(20Gi 磁盘)。第四步配置 Prisma CLI 并执行部署Prisma 服务器使用内部负载均衡ClusterIP这是合理的安全默认——不会将 Prisma 服务器直接暴露到公网。你的 GraphQL API 服务同样应部署到集群内通过内部 DNS 访问 Prisma。但随之而来的问题是在本地如何执行prisma deploy来推送数据模型答案是利用kubectl的port-forward机制将本地端口转发到集群内的应用。每次需要与集群中的 Prisma 服务器通信时执行以下两步用kubectl get pods --namespace prisma找出 Pod 名称执行端口转发kubectl port-forward --namespace prisma the-pod-name 4467:4466这条命令将流量从本地127.0.0.1:4467转发到集群内 Pod 的4466端口。转发生效后Prisma 服务器即可通过http://localhost:4467访问。这就是要在prisma.yml中填写的endpoint。假设服务名为myservice、部署到production阶段端点 URL 为http://localhost:4467/myservice/production。一个示例prisma.ymlendpoint: http://localhost:4467/myservice/production datamodel: datamodel.graphql这里endpoint指定服务名与部署阶段datamodel指向数据模型文件——该结构在仓库 CLI 的 PrismaDefinition.ts 中被解析get endpoint()读取definition.endpointload()负责加载并校验prisma.yml。只要端口转发保持活动就可以在本地执行prisma deploy将数据模型部署到 Kubernetes 集群上的 Prisma 服务器。这一步同样适用于把prisma deploy集成进 CI/CD 流水线的场景。结语至此你已经完成了全部步骤创建命名空间 → 通过 PVC 供给 20Gi 磁盘 → 以 Deployment 部署 MySQL 5.7 并挂载数据盘 → 用 Service 提供稳定的内部 DNS 入口 → 通过 ConfigMap 注入PRISMA_CONFIG→ 部署无状态的 Prisma 服务器prismagraphql/prisma:1.12及其 Service → 最后用kubectl port-forward打通本地 CLI 与集群的通道并执行prisma deploy。这套部署方案的价值在于数据库层通过 PVC 实现数据持久化与跨节点重建Prisma 层作为无状态服务天然支持水平扩展调整replicas即可Service 抽象屏蔽了 Pod IP 的动态变化而PRISMA_CONFIG的注入方式与本仓库 ConfigLoader.scala 的加载逻辑完全对应——从 Docker Compose见 server/docker-compose/mysql/prisma.yml迁移到 Kubernetes 只需调整配置载体配置内容本身可以直接复用。如需进一步了解 Prisma 服务器在 Docker 环境下的完整参数如managementApiSecret、legacySecret、active等可查阅 Docker 部署参考MySQL 连接器的更多配置细节如managementSchema、database字段及本地数据库连接排障见 MySQL 连接器文档。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐使用 Kubernetes 部署 Prisma 服务器从 MySQL 到 Prisma CLI 的完整实战指南使用 Kubernetes 部署 Prisma 服务器从 MySQL 到 Prisma CLI 的完整实战指南 本文面向需要把 Prisma 数据库服务部署到后端数据库GraphQLKubernetes Dashboard 访问指南kubectl port-forward 与 kubectl proxy 实战解析Kubernetes Dashboard 访问指南kubectl port forward 与 kubectl proxy 实战解析 本指南围绕 Kubern前端后端云原生Lucky 部署教程在路由上跑通一条公网端口转发Lucky 部署教程在路由上跑通一条公网端口转发 Lucky 是一款运行在软硬路由器、x86 与 Linux 服务器上的网络工具集成端口转发、DDNS、反向后端网络通信创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prisma 服务器 Kubernetes 部署实战：从 Namespace 到 kubectl port-forward 的完整指南
后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载本指南基于 Prisma 1.12 版本逐步讲解如何将一个完整的 Prisma 数据库服务含 MySQL 存储后端部署到生产级 Kubernetes 集群涵盖命名空间隔离、持久化存储、无状态 Pod 部署、Service 内部负载均衡、ConfigMap 配置注入以及通过kubectl port-forward打通本地 Prisma CLI 与集群内服务等全部关键环节。读完本文你将掌握一套可复制的 Kubernetes 部署范式并能用prisma deploy向集群内的 Prisma 服务器推送数据模型。本文所有 Kubernetes 定义文件均可按原文路径在本地kubernetes-demo目录中依次创建并应用对应的 Docker Compose 配置方式可参考仓库中的 本地 Docker 部署教程.md)服务器配置的底层解析逻辑见 ConfigLoader.scala。前置准备在开始部署之前需要满足以下两个前置条件一个运行中的 Kubernetes 集群例如托管在 Google Cloud Platform 上的 Kubernetes EngineGKE。本教程刻意保持 Provider 无关——因为 Kubernetes 本身就是一层抽象不同云厂商的差异仅体现在创建Persistent Volume持久化卷的机制上其余步骤完全一致。本地可用的kubectl一个已配置好、能够与目标集群通信的 kubectl 命令行工具。完成上述准备后在本地创建一个名为kubernetes-demo的工作目录本文所有 YAML 文件都将在该目录下按相对路径创建与维护。第一步创建独立的 NamespaceKubernetes 提供了namespace命名空间这一原语用于对工作负载进行逻辑分组。合理使用命名空间可以避免不同环境如 dev、staging、production之间互相干扰也便于后续通过标签与资源配额统一管理。在kubernetes-demo目录下创建namespace.ymlapiVersion: v1 kind: Namespace metadata: name: prisma该定义将创建一个名为prisma的命名空间。通过kubectl应用它kubectl apply -f namespace.yml随后可用kubectl get namespaces验证命名空间是否创建成功。在一个全新的集群上输出大致如下❯ kubectl get namespaces NAME STATUS AGE default Active 1d kube-public Active 1d kube-system Active 1d prisma Active 2s可以看到prisma命名空间已经处于Active状态后续所有资源数据库、Prisma 服务器、Service都将部署在这个命名空间内。第二步部署 MySQL 数据库Prisma 支持多种主流数据库系统如 PostgreSQL、MongoDB 等。本教程以 MySQL 为例但所涉及的步骤可以轻松迁移到其他数据库——只需替换镜像与连接参数。磁盘供给创建 PersistentVolumeClaim数据库天然是有状态stateful的部署需要一块磁盘来持久化数据。Kubernetes 通过PersistentVolumeClaimPVC来向集群请求一块磁盘kind: PersistentVolumeClaim apiVersion: v1 metadata: name: database-disk namespace: prisma labels: stage: production name: database app: mysql spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi这里向集群请求了一块容量为20GB的磁盘accessModes: ReadWriteOnce表示该磁盘同一时间仅能被一个节点以读写方式挂载——这正是单实例数据库的典型诉求。应用该 PVCkubectl apply -f database/pvc.yml几秒钟后在 Google Cloud Platform 的磁盘概览页面就能看到新创建的磁盘。值得注意的是不同云厂商创建持久化卷的机制略有差异这是本教程中唯一因 Provider 不同而需要调整的部分其余资源定义可以原样复用。部署数据库 PodKubernetes 提供Pod与ReplicationController两个核心原语Pod类似于一台虚拟机容器化应用运行其中拥有独立的内部 IP 地址并可挂载磁盘ReplicationController负责将 Pod 调度到集群节点并保证 Pod 按配置的副本数持续运行。在较新的 Kubernetes 版本中这两者被合并进了新的资源类型Deployment你只需声明容器镜像、副本数量以及要挂载的磁盘调度与自愈由控制面完成。MySQL 的 Deployment 定义如下apiVersion: extensions/v1beta1 kind: Deployment metadata: name: database namespace: prisma labels: stage: production name: database app: mysql spec: replicas: 1 strategy: type: Recreate template: metadata: labels: stage: production name: database app: mysql spec: containers: - name: mysql image: mysql:5.7 args: - --ignore-db-dirlostfound env: - name: MYSQL_ROOT_PASSWORD value: prisma ports: - name: mysql-3306 containerPort: 3306 volumeMounts: - name: database-disk readOnly: false mountPath: /var/lib/mysql volumes: - name: database-disk persistentVolumeClaim: claimName: database-disk该定义的关键点replicas: 1调度一个 Pod 副本image: mysql:5.7容器基于官方 MySQL 5.7 镜像env将 MySQLroot用户的密码设置为prisma生产环境应改用 Secret 注入避免明文写在定义文件中args: --ignore-db-dirlostfound避免 MySQL 初始化时因挂载点下的lostfound目录而报错strategy: Recreate更新时先销毁旧 Pod 再创建新 Pod适合这种磁盘仅支持单节点读写挂载的场景volumeMountsvolumes将 PVCdatabase-disk挂载到容器的/var/lib/mysqlMySQL 数据目录实现数据持久化。应用该定义kubectl apply -f database/deployment.yml检查 Pod 是否成功调度kubectl get pods --namespace prisma NAME READY STATUS RESTARTS AGE database-3199294884-93hw4 1/1 Running 0 1mPod 处于Running状态数据库实例已经正常运行。部署数据库 ServiceMySQL Pod 现在已在集群内部运行Kubernetes 为其分配了一个内部 IP。但这里存在一个隐患如果数据库 Pod 崩溃控制面会重新调度一个新 Pod此时新 Pod 会被分配不同的 IP 地址导致所有依赖该 IP 的应用随之崩溃。为解决这个问题Kubernetes 提供了Service原语——一个可通过服务名访问的内部负载均衡器。它负责将流量转发到匹配的 Pod们并让整个集群通过稳定的服务名访问后端从而屏蔽 Pod IP 的变化。MySQL 的 Service 定义如下apiVersion: v1 kind: Service metadata: name: database namespace: prisma spec: ports: - port: 3306 targetPort: 3306 protocol: TCP selector: stage: production name: database app: mysql关于spec的两个核心字段ports将 Service 端口映射到容器端口这里为3306 → 3306selector类似于查询条件负载均衡器通过匹配 Pod 上的标签来筛选目标 Pod。这里正是选中了前面 Deployment 中带stage: production、name: database、app: mysql三个标签的 MySQL Pod。应用并验证kubectl apply -f database/service.yml kubectl get services --namespace prisma NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE database ClusterIP 10.3.241.165 none 3306/TCP 1mTYPE: ClusterIP表明这是一个仅集群内部可达的服务从此刻起集群内的任何应用都可以通过服务名database访问 MySQL。第三步部署 Prisma 服务器数据库就绪后接下来部署真正的 Prisma 服务器。它作为 Prisma CLI 的端点与前面部署的database服务通信并将其作为存储后端。与 MySQL 不同Prisma 服务器是无状态应用——它不需要任何额外的磁盘存储因此部署更简单。注入配置部署 ConfigMapPrisma 服务器需要数据库连接信息以及使用哪个 connector。这类配置最适合用ConfigMap承载——它像一个独立的配置文件内容可以被注入为环境变量。配置内容正是本仓库服务器端实际解析的PRISMA_CONFIG其完整字段解析逻辑见 ConfigLoader.scala 中的tryLoad/convertToConfig/readExplicitDb实现apiVersion: v1 kind: ConfigMap metadata: name: prisma-configmap namespace: prisma labels: stage: production name: prisma app: prisma data: PRISMA_CONFIG: | port: 4466 # uncomment the next line and provide the env var PRISMA_MANAGEMENT_API_SECRETmy-secret to activate cluster security # managementApiSecret: my-secret databases: default: connector: mysql host: database port: 3306 user: root password: prisma migrations: true对PRISMA_CONFIG各字段的说明port: 4466Prisma 服务器监听端口仓库server/docker-compose/mysql/prisma.yml中的本地示例同样使用 4466managementApiSecret默认注释掉集群安全开关。取消注释并设置该值后Prisma CLI 的所有请求都需要携带此密钥未配置时为无鉴权的公开集群。仓库中 Docker 部署参考文档 也强调了该字段是 CLI 向服务器鉴权的凭据databases.default声明服务器连接的数据库其中connector: mysql指定使用 MySQL 连接器可替换为postgres或mongohost: database正是引用上一步创建的 Service 名集群内部 DNS 会解析它user/password与 MySQL 容器的凭据保持一致migrations: true启用迁移功能在 ConfigLoader.scala 中migrations或active被解析为数据库的 active 标志允许prisma deploy自动执行 schema 迁移若设置为false则数据库被视作被动passive连接。从源码角度印证ConfigLoader.tryLoad优先读取环境变量PRISMA_CONFIG其次回退到工作目录下的prisma.yml/prisma.yaml文件由PRISMA_CONFIG_PATH指定最后兼容旧版独立环境变量。也就是说这里通过 ConfigMap 注入的PRISMA_CONFIG环境变量正是服务器配置的主入口。应用 ConfigMapkubectl apply -f prisma/configmap.yml部署 Prisma Pod定义 Prisma 服务器的 DeploymentapiVersion: extensions/v1beta1 kind: Deployment metadata: name: prisma namespace: prisma labels: stage: production name: prisma app: prisma spec: replicas: 1 strategy: type: Recreate template: metadata: labels: stage: production name: prisma app: prisma spec: containers: - name: prisma image: prismagraphql/prisma:1.12 ports: - name: prisma-4466 containerPort: 4466 env: - name: PRISMA_CONFIG valueFrom: configMapKeyRef: name: prisma-configmap key: PRISMA_CONFIG这份定义与 MySQL Deployment 结构类似调度 1 个副本容器镜像为prismagraphql/prisma:1.12并通过configMapKeyRef将前面 ConfigMap 中的PRISMA_CONFIG键注入为环境变量——这正是 ConfigMap 注入配置的标准姿势Prisma 服务器启动时即从该环境变量加载全部配置。应用并验证kubectl apply -f prisma/deployment.yml kubectl get pods --namespace prisma NAME READY STATUS RESTARTS AGE database-3199294884-93hw4 1/1 Running 0 5m prisma-1733176504-zlphg 1/1 Running 0 1m数据库与 Prisma 两个 Pod 都处于Running状态。部署 Prisma ServicePrisma Pod 虽然已经运行但还缺少前置的负载均衡器Service。补上它apiVersion: v1 kind: Service metadata: name: prisma namespace: prisma spec: ports: - port: 4466 targetPort: 4466 protocol: TCP selector: stage: production name: prisma app: prisma应用kubectl apply -f prisma/service.yml至此Prisma 服务器已在 Kubernetes 集群内通过服务名prisma对外可达。整个集群的链路为Service(prisma:4466) → Pod(prismagraphql/prisma:1.12) → Service(database:3306) → Pod(mysql:5.7) PVC(20Gi 磁盘)。第四步配置 Prisma CLI 并执行部署Prisma 服务器使用内部负载均衡ClusterIP这是合理的安全默认——不会将 Prisma 服务器直接暴露到公网。你的 GraphQL API 服务同样应部署到集群内通过内部 DNS 访问 Prisma。但随之而来的问题是在本地如何执行prisma deploy来推送数据模型答案是利用kubectl的port-forward机制将本地端口转发到集群内的应用。每次需要与集群中的 Prisma 服务器通信时执行以下两步用kubectl get pods --namespace prisma找出 Pod 名称执行端口转发kubectl port-forward --namespace prisma the-pod-name 4467:4466这条命令将流量从本地127.0.0.1:4467转发到集群内 Pod 的4466端口。转发生效后Prisma 服务器即可通过http://localhost:4467访问。这就是要在prisma.yml中填写的endpoint。假设服务名为myservice、部署到production阶段端点 URL 为http://localhost:4467/myservice/production。一个示例prisma.ymlendpoint: http://localhost:4467/myservice/production datamodel: datamodel.graphql这里endpoint指定服务名与部署阶段datamodel指向数据模型文件——该结构在仓库 CLI 的 PrismaDefinition.ts 中被解析get endpoint()读取definition.endpointload()负责加载并校验prisma.yml。只要端口转发保持活动就可以在本地执行prisma deploy将数据模型部署到 Kubernetes 集群上的 Prisma 服务器。这一步同样适用于把prisma deploy集成进 CI/CD 流水线的场景。结语至此你已经完成了全部步骤创建命名空间 → 通过 PVC 供给 20Gi 磁盘 → 以 Deployment 部署 MySQL 5.7 并挂载数据盘 → 用 Service 提供稳定的内部 DNS 入口 → 通过 ConfigMap 注入PRISMA_CONFIG→ 部署无状态的 Prisma 服务器prismagraphql/prisma:1.12及其 Service → 最后用kubectl port-forward打通本地 CLI 与集群的通道并执行prisma deploy。这套部署方案的价值在于数据库层通过 PVC 实现数据持久化与跨节点重建Prisma 层作为无状态服务天然支持水平扩展调整replicas即可Service 抽象屏蔽了 Pod IP 的动态变化而PRISMA_CONFIG的注入方式与本仓库 ConfigLoader.scala 的加载逻辑完全对应——从 Docker Compose见 server/docker-compose/mysql/prisma.yml迁移到 Kubernetes 只需调整配置载体配置内容本身可以直接复用。如需进一步了解 Prisma 服务器在 Docker 环境下的完整参数如managementApiSecret、legacySecret、active等可查阅 Docker 部署参考MySQL 连接器的更多配置细节如managementSchema、database字段及本地数据库连接排障见 MySQL 连接器文档。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐使用 Kubernetes 部署 Prisma 服务器从 MySQL 到 Prisma CLI 的完整实战指南使用 Kubernetes 部署 Prisma 服务器从 MySQL 到 Prisma CLI 的完整实战指南 本文面向需要把 Prisma 数据库服务部署到后端数据库GraphQLKubernetes Dashboard 访问指南kubectl port-forward 与 kubectl proxy 实战解析Kubernetes Dashboard 访问指南kubectl port forward 与 kubectl proxy 实战解析 本指南围绕 Kubern前端后端云原生Lucky 部署教程在路由上跑通一条公网端口转发Lucky 部署教程在路由上跑通一条公网端口转发 Lucky 是一款运行在软硬路由器、x86 与 Linux 服务器上的网络工具集成端口转发、DDNS、反向后端网络通信创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考