Skip to Content
Getting Startedレシピを理解する

レシピを理解する

BuildRecipe は、OpenFactory がイメージパイプラインに送る正規化された仕様である。チャットは作成を支援できるが、レシピ、ソーススナップショット、生成ファイル、テスト証拠がビルドを定義する。

メンタルモデル

正規レシピには主に 4 つの層がある:

  1. Identity and target: 名前、説明、ベースイメージ、ハードウェア意図。
  2. Operating system: os 配下の feature、パッケージ、サービス、ユーザー、セキュリティ、デスクトップ、インストーラー、添付、起動スクリプト。
  3. Verification: 組み込みテストとカスタムアサーションを含む 1 つ以上の scenario。
  4. Delivery intent: 要求された公開先とオプションの配信設定。
{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  },
  "os": {
    "features": ["ssh"],
    "packages": ["curl"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    }
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

snake_case を使う。新しい統合は baseImage、トップレベルの features、startupScripts などのレガシー形状を送らない。

3 つのチェック、3 つの異なる答え

スキーマ検証

検証が答えるのは、「認識されたデータが許容可能な形状か？」である。パッケージが存在する、動作する、とは証明しない。互換性のため未知フィールドは無視されることがあり、検証成功でも重要な要求が欠けることがある。

返された正規化レシピを元のチャットと要求と常に比較する。デスクトップ、アプリケーション、インストーラー、添付、テストの欠落は、検証が valid と言ってもレシピ欠陥である。

ビルド証拠

成功したビルドが答えるのは、「パイプラインがアーティファクトを生成したか？」である。意図した feature がすべてイメージに入った、とは証明しない。パッケージインベントリ、ソース由来、警告、ビルドステージ証拠を確認する。

ゲスト検証

ゲストテストは狭いランタイム質問に答える。VM が起動したか、サービスが active か、ポートが listen するか、ファイル内容が期待どおりか、アプリケーションが起動したか。合格アサーションは、実際に観測した動作だけを支持する。

セキュリティ設定は意図である

受理される hardening_level の値は minimal、standard、strict だが、これらのラベルは移植可能なコンプライアンスプロファイルではない。ターゲットジェネレーターは異なる解釈をする場合がある。ベンチマークが必要なら、適用可能なベンチマークを正確に選び、コントロールごとの結果を保持する。strict から CIS 適合を推論しない。

同様に、disk_encryption、audit_logging、SELinux、fail2ban、Secure Boot、dm-verity、インストーラー設定には、対応するアーティファクトとランタイムテストが必要である。

チャットとレシピの所有

チャット作成レシピを検証または編集するとき、既存の会話は作成コンテキストの一部のままである。検証は現在のレシピを洗練すべきであり、汎用デフォルトで黙って置き換えてはならない。それでも正規化レシピは、ビルド前の最終チェックポイントである。

各重要な要求について:

  • 対応する正規化フィールドを見つける;
  • 値と対象スコープを確認する;
  • ランタイム証明が可能ならアサーションを追加する; および
  • デプロイのみの作業は、イメージビルド中に実行したふりをせず、明示的な警告として残す。

レビューチェックリスト

  • ベースイメージとアーキテクチャは正しいか?
  • 要求したデスクトップとアプリケーション feature はすべてあるか?
  • 外部ソースは意図用途に合わせて pin され、ライセンスは適切か?
  • 保存されたレシピフィールドとスクリプトにシークレットはないか?
  • インストーラーは要求されていれば使い捨てディスクで設定・テストされているか?
  • scenario は実際の受入基準をテストしているか?
  • サポート外またはデプロイ時の要求は明示されているか?

フィールドリファレンスは Recipe Schema、ビルドとダウンロードのワークフローは はじめてのビルド を参照。

はじめてのビルドビルドガイド