Communitygithub.com

Nuvraxis/nuvraxis-plugins

Nuvraxis Next.js アプリ向けのHelmチャートルール — 各アプリごとに charts/ ディレクトリにチャートを作成し、OCIレジストリに公開、Argo CDで同期します。

nuvraxis-plugins とは?

このスキルは、Nuvraxis の Next.js アプリケーションを Kubernetes 上にデプロイ、スケーリング、公開、設定するための Helm チャートのルールを定義します。各アプリはリポジトリルートの `charts/<app>/` に独自のチャートを持ち、`release.yaml` によってバージョンが管理され、`ghcr.io/nuvraxis/charts` の OCI レジストリに公開されます。Argo CD は開発環境では Git から、本番環境では OCI レジストリからチャートを同期します。チャートは、`/api/health` エンドポイントを使用したスタートアップ、Liveness、Readiness プローブ、非 root 読み取り専用のセキュリティコンテキスト、`.next/cache` 用の emptyDir、ConfigMap と外部 Secret の `envFrom` による設定、Service、Ingress (cert-manager を使用)、HPA、PDB、ServiceAccount、トポロジースプレッド制約などを定義します。Helm フック、`lookup`、ランダム値の使用は禁止されており、`helm lint --strict` と `kubeconform` による厳格なバリデーションが行われます。このスキルは、リポジトリに `charts/` ディレクトリ、`Chart.yaml`、`values*.yaml`、`templates/*.yaml` が存在する場合、または Argo CD Application が設定されている場合、あるいは Kubernetes 上でのアプリのデプロイ、スケーリング、公開、設定が要求された場合に使用されます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/helm-nextjs

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Next.js アプリの Helm チャート

charts/<app>/ と、Argo CD がそれをどのように使用するかについて説明します。実行されるイメージは docker-nextjs から提供され、両方を公開するパイプラインは github-actions です。

テンプレートの charts/__APP__/ が信頼できる情報源です。コメント付きのすべての値: references/values.md。Argo CD の配線: references/argocd.md。

ルール

  1. アプリごとに 1 つのチャートを、アプリのリポジトリルートの charts/<app>/ に配置します。 その理由: Argo CD は開発環境では Git から (path: charts/<app>) 直接同期でき、本番環境では OCI レジストリから同じファイルで同期できます。apps/ の外にあるため、Docker ビルドコンテキストにも pnpm ワークスペースパッケージにも含まれません。また、チャートの変更は、それを必要とするコードと同じ PR で行われます。チャートは意図的にシングルアプリであり、アンブレラチャートやサブチャートはありません。汎用的で値駆動型のテンプレート (バックエンドアンブレラチャートなど) は、単一のアプリが Ingress、HPA、PDB、トポロジースプレッドなどのスイッチを必要とする場合にのみ使用します。

  2. version または appVersion を手動で編集しないでください。 両方とも Git では 0.0.0 のままにします。release.yaml はタグ vX.Y.Z から helm package --version X.Y.Z --app-version vX.Y.Z を実行するため、公開されたチャートとイメージタグは常に一致します。

  3. image.tag はデフォルトで appVersion になります。Git 同期環境でのみ設定します。 OCI からは、appVersion がリリースタグであり、イメージは ghcr.io/nuvraxis/<app>:vX.Y.Z です。Git から同期する場合、appVersion は 0.0.0 であるため、Argo CD Application は image.tag: sha-<short-sha> (または main) を設定します。image.repository は常に小文字です。

  4. プローブ: startup、liveness、readiness、すべて /api/health を使用します。 startup プローブ (2秒 × 30) は起動をカバーし、liveness と readiness はその後にのみ開始されます。このルートは依存関係にまったく触れないため、データベースの障害でポッドが再起動されることはありません。プローブを / に向けないでください: ページがレンダリングされます。

  5. セキュリティコンテキストはイメージと一致します: uid/gid 1001、runAsNonRoot、readOnlyRootFilesystem、権限昇格なし、すべてのケーパビリティをドロップ、RuntimeDefault seccomp。 ServiceAccount とポッドの両方で automountServiceAccountToken: false にします。アプリは Kubernetes API を呼び出しません。

  6. .next/cache は sizeLimit 付きの emptyDir です。 これは唯一の書き込み可能パス (/app/apps/<app>/.next/cache) です。制限により、暴走したイメージキャッシュがノードを満杯にするのを防ぎます。

  7. envFrom による設定: values.config からの ConfigMap と、既に存在する Secret。

    config:
      API_BASE_URL: https://api.nuvraxis.com
    existingSecret: portal-secrets
    

    チャートは Secret の値をテンプレート化しません: kind: Secret と値からの data、--set secret=… はありません。Secret は External Secrets、Sealed Secrets、またはオペレーターによって作成され、その名前のみが値に含まれます。ConfigMap の変更は、checksum/config アノテーションを通じてポッドをロールアウトします。

  8. チャートに NEXT_PUBLIC_* は含めません。 これらはイメージビルド時に焼き付けられます (docker-nextjs を参照)。実行時に設定しても何も効果がありません。

  9. リソース: CPU とメモリのリクエスト、メモリ制限、CPU 制限なし。 CPU 制限は、バースト中に Node サーバーをスロットルし、テールレイテンシを増加させます。メモリ制限は、Node のヒープが与えられたものに成長するため、そのまま残します。

  10. デフォルトで高可用性: 2 レプリカ、PDB maxUnavailable: 1、maxUnavailable: 0 のローリングアップデート、ゾーンとノード間のトポロジースプレッド (ScheduleAnyway)。 autoscaling.enabled が有効な場合、Deployment は replicas を省略するため、Argo CD と HPA が競合しません。

  11. Ingress はオプトイン、TLS は cert-manager アノテーションを使用します。 ingress.enabled、className、hosts、secretName を持つ tls、およびアノテーション内の cert-manager.io/cluster-issuer。ingress-nginx でストリーミング応答を行うには、nginx.ingress.kubernetes.io/proxy-buffering: "off" を追加します。レート制限には、limit-rps を使用します (nextjs-security を参照)。

  12. Helm フック、lookup、ランダム値は使用しません。 Argo CD は helm template でチャートをレンダリングし、その結果を適用します。フックは Argo CD では異なるセマンティクスのフックになり、lookup は何も返さず、randAlphaNum は同期のたびに変更され、アプリを恒久的に同期状態から外します。レンダリングされるものはすべて、値の純粋関数でなければなりません。

  13. プライベート GHCR パッケージにはプル資格情報が必要です。 GHCR パッケージは最初のプッシュ時にはプライベートです。イメージの場合: read:packages 権限を持つトークンを含む docker-registry Secret を imagePullSecrets で参照します (本番値は ghcr-pull を参照)。Argo CD のチャートの場合: enableOCI: "true" を持つリポジトリ Secret を使用します (references/argocd.md を参照)。または、コードが公開されている場合は、GitHub でパッケージを公開にします。

  14. values-production.yaml には、本番環境で異なるもののみを保持します。 レイヤー化: -f values.yaml -f values-production.yaml。デフォルトをコピーしないでください。

  15. helm lint --strict と helm template | kubeconform -strict で検証します。 helm-unittest ではなく kubeconform を使用する理由: シングルアプリチャートが実際に持つバグは、レンダリング出力のフィールド名、タイプ、API バージョンの誤りであり、kubeconform は実際の Kubernetes スキーマに対して、テストコードなしでこれらをキャッチします。helm-unittest はテンプレートロジックをアサートしますが、このチャートにはほとんどありません。pr.yaml と同様に、両方の値ファイルに対して lint と検証を実行します。

追加項目

必要なもの変更内容
ランタイム環境変数値の config: (非シークレット) または既存の Secret のキー
シークレット外部 Secret に追加。チャートは変更なし
別のポートまたはサイドカー最初に正当化。Next アプリには 1 ポート必要
スケジュールジョブこの Deployment ではなく、別のチャートまたはアプリ
NetworkPolicytemplates/networkpolicy.yaml を追加、networkPolicy.enabled で切り替え

検証

helm lint --strict charts/<app>
helm lint --strict charts/<app> -f charts/<app>/values-production.yaml
helm template <app> charts/<app> -f charts/<app>/values-production.yaml \
  | docker run --rm -i ghcr.io/yannh/kubeconform:v0.8.0 -strict -summary -kubernetes-version 1.34.0 -

出典

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Nuvraxis/nuvraxis-plugins

>- Biome 2.5 setup and rules for Nuvraxis monorepos — root biome.json with pinned $schema, VCS ignore, formatter settings, the recommended preset with a11y and the react/next domains, nursery policy, organize imports, overrides, nested per-package configs ("extends": "//"), biome check --write locally, biome ci in CI, VS Code settings, and migrating from ESLint/Prettier. Use when the repo has biome.json or biome.jsonc, @biomejs/biome in package.json, .eslintrc*/eslint.config.*/.prettierrc* to migrate, or when fixing lint and formatting errors.

Nuvraxis/nuvraxis-plugins

>- Dockerfile rules for Next.js standalone apps in a pnpm + Turborepo monorepo — multi-stage build (turbo prune → pnpm fetch/offline install → turbo build → minimal runner), pinned Node 26 Alpine by digest, checksum-verified pnpm binary, non-root uid 1001, read-only root filesystem with a writable .next/cache, HEALTHCHECK on /api/health, build args only for NEXT_PUBLIC_* values, BuildKit secrets and cache mounts, multi-arch, OCI labels and .dockerignore. Use when the repo has a Dockerfile, .dockerignore, compose file, or next.config with output "standalone", or when asked to containerise, shrink, harden or debug an image.

Nuvraxis/nuvraxis-plugins

>- GitHub Actions conventions for Nuvraxis Next.js apps — exactly three workflows: pr.yaml (every PR to any branch: Biome, stylelint, typecheck/test/build with turbo --affected, Docker build + health check, helm lint + kubeconform; publishes nothing), main.yaml (push to main: one multi-arch image to GHCR tagged sha-SHORTSHA and main, provenance + SBOM, gha cache), release.yaml (tag vX.Y.Z: verify on main, retag the existing image without rebuilding, package and push the Helm chart to OCI, GitHub Release with chart, digest and SBOM). Minimal permissions per job, GITHUB_TOKEN only, pinned action majors. Use when editing .github/workflows/*, adding a CI step, or debugging a failed run or release.

Nuvraxis/nuvraxis-plugins

>- Production rules for Next.js 16 App Router apps at Nuvraxis — Server/Client Component boundaries, Cache Components ("use cache", cacheLife, cacheTag, updateTag), Server Actions, route handlers, env handling, instrumentation, output standalone and the /api/health route. Use when the project has "next" in package.json, an app/ or src/app/ directory, next.config.ts, proxy.ts, instrumentation.ts, or files named page.tsx, layout.tsx, route.ts, loading.tsx, error.tsx.

関連スキル