Skip to Content
Building Osソース リポジトリからのカスタム ソフトウェア

ソース リポジトリからのカスタム ソフトウェア

OpenFactory レシピは、サポートされているイメージ ビルダーのカスタム パッケージ入力として Git リポジトリを参照できます。これはサプライチェーンに依存するパスです。リポジトリ、解決されたリビジョン、パッケージ化手順、ビルドの依存関係、および生成されたパッケージはすべてレビューが必要です。

サポートはターゲットごとに異なります。現在の Raspberry Pi や Proxmox パスなど、一部のビルダーではソース パッケージ ビルドが拒否されます。パッケージが生成されることを約束する前に、正規化されたレシピとビルド計画で可用性を確認してください。

レシピの形状

カスタム パッケージ エントリは os.custom_packages の下に存在します。

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

スキーマは、不変のコミット フィールドではなく、ブランチ名を受け入れます。制御リリースの場合は、ビルドによって解決された正確なコミットを記録し、そのコミットを保持される出所の一部にします。移動するブランチだけでは再現可能な入力ではありません。

リポジトリを準備する

現在のパッケージ パスでは、ターゲットに適切なネイティブ パッケージング メタデータが必要です。一般的な例は、Debian debian/ ディレクトリまたは RPM 仕様です。ビルダーの正確な動作とサポートされるターゲット バージョンは変更される可能性があるため、静的な互換性テーブルに依存するのではなく、デプロイされた環境で最小限のパッケージを検証してください。

Debian パッケージ化については、少なくとも以下を確認してください。

  • debian/control ソース/バイナリ ID と依存関係。
  • debian/changelog パッケージのバージョン。
  • debian/rules およびその他の実行可能なメンテナ スクリプト。
  • マニフェストと systemd ユニットをインストールします。そして
  • ライセンスおよびバンドルされたサードパーティ素材。

RPM パッケージ化については、仕様のソース、ビルド要件、スクリプトレット、ファイル リスト、ライセンス メタデータを確認してください。

リポジトリの所有権によってビルド スクリプトが安全になるとは決して考えないでください。パッケージ ビルドは、信頼できないソースとパッケージ化ロジックをビルド インフラストラクチャの分離境界内で実行します。

その他のパッケージ コントロール

ネイティブパッケージ

選択したディストリビューションまたは明示的に構成されたリポジトリによってすでに提供されているパッケージには os.packages を使用します。

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

パッケージの上書き

os.package_overrides は、add、remove、または replace インテントを宣言できます。

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

オーバーライドは、依存関係の解決がオーバーライドを尊重したことを証明するものではありません。最終的なパッケージの在庫と不在/存在のアサーションを確認します。

追加のリポジトリ

os.extra_repos は高度な入力です。古い例に示されているように、署名されていない HTTP リポジトリを追加しないでください。承認されたリポジトリ統合には、HTTPS トランスポート、固定された署名キー、署名の強制、パッケージ マネージャーに適切なリリース メタデータ、および文書化された所有権と更新ポリシーが必要です。これらの信頼コントロールを現在のビルダーで表現できない場合は、リポジトリを使用しないでください。

受理証拠

すべてのカスタム パッケージについて、以下を保持します。

  • リポジトリ URL と解決されたコミット。
  • ソースおよび宣言されたライセンスのレビュー。
  • 環境と依存関係のスナップショットを構築します。
  • ビルド ログとその結果のパッケージ名/バージョン/アーキテクチャ;
  • 該当する場合、パッケージダイジェストとリポジトリ署名の証拠。
  • インストールされたパッケージを示す最終イメージ インベントリ。
  • サービスまたは実行可能なスモーク テスト。そして
  • 削除とアップグレードの動作。

ソースパッケージ段階が成功しただけでは十分ではありません。後でイメージのビルドがパッケージの使用に失敗し、インストールされたパッケージが依然として使用できない可能性があります。

トラブルシューティング

  • パッケージ化メタデータが拒否されました: 同じディストリビューション リリースとアーキテクチャを使用してネイティブ パッケージをローカルで検証します。
  • ビルド依存関係が欠落しています: そのターゲットの承認されたリポジトリから入手可能な依存関係を使用します。メンテナー スクリプトで任意のバイナリをサイレントにフェッチしないでください。
  • イメージにパッケージがありません: 生成されたバイナリ パッケージ名を、正規化されたインストール リクエストおよび最終インベントリと比較します。
  • バージョンは変更されませんでした: ネイティブ バージョンのメタデータを更新し、新しいソース コミットが解決されたことを確認します。
  • サービスが失敗しました: ユニット、実行時の依存関係、権限、ゲスト ログを検査します。再構築する前に動作レベルのアサーションを追加します。
ベースイメージデスクトップイメージ