mcpField
T
tigris-lifecycle-management

tigris-lifecycle-management

github.com/tigrisdataクラウド・DevOps280 回インストール14 週間前に更新
リポジトリ

tigris-lifecycle-management について

Tigris CLIでTigrisオブジェクトストレージのライフサイクルを管理するスキルです。アップロード、ログ、セッション、バックアップなどに、プレフィックス単位の期限切れやストレージ階層移行を設定できます。

主な機能

  1. 01プレフィックス別のルール設定
  2. 02オブジェクトの期限切れ設定
  3. 03ストレージ階層間の移行
  4. 04既存ルールの確認と削除

活用シーン

  1. 01一時アップロードやセッションファイルの自動削除
  2. 02古いログのアーカイブと後日の削除
  3. 03バックアップやビルド成果物の保持期間設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tigrisdata/skills --skill tigris-lifecycle-management

インストール後、Claude Code で/tigris-lifecycle-managementを入力して読み込まれたか確認します。

同梱ファイルmetadata.jsonREADME.md

詳細

Tigris のライフサイクル管理

ライフサイクルルールを使って、オブジェクトの有効期限、ストレージ階層の移行、クリーンアップを自動化します。一時ファイルの自動削除、古いデータのアーカイブ、ストレージコストの管理を行うポリシーを設定できます。

前提条件

ほかの作業を始める前に、まだ利用できない場合は Tigris CLI をインストールしてください。

tigris help || npm install -g @tigrisdata/cli

インストールが必要な場合は、ユーザーに次のように伝えてください:「Tigris オブジェクトストレージを操作できるように、Tigris CLI(@tigrisdata/cli)をインストールしています。」

クイックリファレンス

操作コマンド
ルールを設定tigris buckets lifecycle set <bucket> --config lifecycle.json
ルールを表示tigris buckets lifecycle get <bucket>
ルールを削除tigris buckets lifecycle delete <bucket>

ライフサイクルルールの設定

tigris buckets lifecycle set my-app-uploads --config lifecycle.json
ルールの形式
{
  "Rules": [
    {
      "ID": "rule-name",
      "Filter": { "Prefix": "path/prefix/" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 },
      "Transitions": [
        { "Days": 7, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ]
    }
  ]
}
フィールド用途
ID人が読みやすいルール名
Filter.Prefixこのプレフィックスに一致するオブジェクトのみを対象にします
Status"Enabled" または "Disabled"
Expiration.DaysN 日後にオブジェクトを削除します
Transitionsオブジェクトをストレージ階層間で移動します

よくあるパターン

一時アップロードのクリーンアップ

tmp/ 内のファイルを 24 時間後に削除します。

{
  "Rules": [
    {
      "ID": "cleanup-temp-uploads",
      "Filter": { "Prefix": "tmp/" },
      "Status": "Enabled",
      "Expiration": { "Days": 1 }
    }
  ]
}
未検証アップロードの有効期限

未処理のアップロードを 7 日後に削除します。

{
  "Rules": [
    {
      "ID": "expire-unverified-uploads",
      "Filter": { "Prefix": "uploads/pending/" },
      "Status": "Enabled",
      "Expiration": { "Days": 7 }
    }
  ]
}
セッションデータのクリーンアップ

セッションファイルを 1 日後に自動削除します。

{
  "Rules": [
    {
      "ID": "cleanup-sessions",
      "Filter": { "Prefix": "sessions/" },
      "Status": "Enabled",
      "Expiration": { "Days": 1 }
    }
  ]
}
ログのアーカイブ

ログをより安価なストレージに移動し、1 年後に削除します。

{
  "Rules": [
    {
      "ID": "archive-logs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}
バックアップの保持

バックアップを 30 日間保持します。

{
  "Rules": [
    {
      "ID": "expire-old-backups",
      "Filter": { "Prefix": "backups/" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 }
    }
  ]
}
古いアセットのバージョン

古いビルド成果物をクリーンアップします。

{
  "Rules": [
    {
      "ID": "cleanup-old-builds",
      "Filter": { "Prefix": "builds/" },
      "Status": "Enabled",
      "Expiration": { "Days": 14 }
    }
  ]
}

ストレージ階層

階層コストアクセス用途
STANDARD最高即時頻繁にアクセスするファイル
STANDARD_IA低め即時、取得料金ありアクセス頻度が低いファイル(30 日以上経過)
GLACIER最低取得に数分〜数時間アーカイブ、コンプライアンス(90 日以上経過)
移行のタイミング
シナリオ移行時期削減額
再アクセスがほとんどないユーザーアップロード30 日後 → IAストレージコストを約 40% 削減
コンプライアンス用アーカイブ90 日後 → Glacierストレージコストを約 80% 削減
ビルド成果物7 日後 → IA、30 日後 → 削除削除によって約 90% 削減

複数ルールの例

複数のルールを組み合わせて、完全なライフサイクルポリシーを設定します。

{
  "Rules": [
    {
      "ID": "cleanup-temp",
      "Filter": { "Prefix": "tmp/" },
      "Status": "Enabled",
      "Expiration": { "Days": 1 }
    },
    {
      "ID": "archive-uploads",
      "Filter": { "Prefix": "uploads/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 90, "StorageClass": "STANDARD_IA" }
      ]
    },
    {
      "ID": "expire-backups",
      "Filter": { "Prefix": "backups/" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 }
    },
    {
      "ID": "archive-logs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

アプリケーションレベルの TTL

ライフサイクルルールでは粒度が十分でない場合(例:経過時間ではなくメタデータに基づいて有効期限を設定する場合)は、アプリケーションで TTL を実装します。

import { put, list, remove, head } from "@tigrisdata/storage";

// Store with expiration metadata
await put("tokens/abc123.json", data, {
  contentType: "application/json",
  // Store expiry as part of the key or track in your database
});

// Cleanup job: delete expired objects
async function cleanupExpired(prefix: string, maxAgeMs: number) {
  const result = await list({ prefix });
  const now = Date.now();

  for (const item of result.data?.items ?? []) {
    const age = now - new Date(item.modified).getTime();
    if (age > maxAgeMs) {
      await remove(item.path);
    }
  }
}

// Run daily
cleanupExpired("tokens/", 24 * 60 * 60 * 1000); // 24 hours

スナップショットとの連携

  • ライフサイクルルールはスナップショットのコピーではなく、ソースバケットに適用されます
  • ライフサイクルルールで削除されたオブジェクトは、削除前に取得したスナップショットから復元できます
  • 有効期限ポリシーを設定する際は、スナップショットの取得頻度を考慮してください

重要なルール

必ず行うこと: 予測可能なクリーンアップにはライフサイクルルールを使う | 一時データや一過性データに有効期限を設定する | コスト削減のためにストレージ階層の移行を利用する | まず本番環境以外のバケットでルールをテストする

絶対にしないこと: 重要なデータの削除をライフサイクルのみに頼る(アプリケーションレベルのチェックも追加する) | バックアップなしで重要なデータを含むバケットに短い有効期限を設定する | 削除したオブジェクトは(スナップショットがない限り)完全に失われることを忘れる


関連スキル

  • tigris-backup-export — バックアップ保持ポリシー
  • tigris-egress-optimizer — コスト削減のための階層移行
  • tigris-snapshots-forking — 削除前のポイントインタイムリカバリー

公式ドキュメント

コメント