Skip to Content
Building Osオペレーティング システム イメージの構築

オペレーティング システム イメージの構築

OpenFactory は、正規化されたレシピをイメージ アーティファクトに変換し、要求されて利用可能な場合は、検証のためにそのアーティファクトを起動します。正確なビルダーとステージは、基本イメージ ファミリと展開によって異なります。

レシピが制御するもの

エリア正規の場所質問を確認する
ベースとハードウェアの意図base_imagehardwareこれは正しいディストリビューション、リリース、アーキテクチャ、および最小プロファイルですか?
機能とパッケージos.featuresos.packages要求された機能はこのベースに存在し、サポートされていますか?
サービスとアカウントos.servicesos.users構成と最小特権アクセスは明示的ですか?
デスクトップとブランディングos.desktop_settingsos.branding選択したデスクトップはこれらの設定と資産を所有していますか?
インストーラーと永続性os.installeros.persistenceディスクへのインストールと永続性の要件は実際にテストされていますか?
カスタムオートメーションos.startup_scripts、添付ファイル、ソース パッケージ入力は固定され、制限されており、宣言されたユーザーとして安全に実行できますか?
検証scenariosテストは単に起動するだけでなく、あらゆる重要な結果を観察しますか?

全体の形状については レシピスキーマ を参照してください。

ビルドのライフサイクル

パブリック ステータス ストリームには、計画、構成、ソース パッケージ作業、イメージ生成、ファイナライズ、テストが含まれます。これらは、すべてのターゲットに対して同じ名前のステージとして表示されることは保証されません。開始リクエストによって返されたビルド ID に従い、バックエンドの現在のステータスを権限のあるものとして扱います。

これらの結果を別々に保管してください。

  1. validated は、認識されたレシピ形状が受け入れられたことを意味します。
  2. ターミナルのビルドが成功したということは、アーティファクトが完成したことを意味します。
  3. テストの成功は、選択されたアサーションが環境に対して合格したことを意味します。そして
  4. 認証または公開が有効になっている場合は、後のポリシー決定によって決定されます。

進行状況が静かであっても、重複したビルドを作成する理由にはなりません。同じビルド ID を使用して、ビルド コンソールまたはステータス エンドポイントに再接続します。ビルドが最終的に失敗した場合は、再試行する前にステージ、エラー、ログを保存してください。

推奨されるワークフロー

  1. 観察可能な受け入れ基準を作成します。
  2. レシピを生成または編集します。
  3. それを検証し、正規化された結果を会話全体と比較します。
  4. 推定された機能、外部ソース、インストーラー設定、およびシナリオを検査します。
  5. 1 つのビルドを開始し、その永続 ID に従います。
  6. アーティファクト ダイジェスト、パッケージ インベントリ、警告、およびテスト証拠を確認します。
  7. 要求に応じた使い捨て環境でブートまたはインストールします。
  8. 該当する承認ゲートを通じてのみ宣伝または公開します。

トピックガイド

|トピック | |に使用します。 | --- | --- | | 基本イメージ |サポートされているビルド ファミリの選択 | | 特徴 |登録された機能モジュールについて理解する | | サービス |サービス構成の宣言 | | カスタムソフトウェア |リポジトリベースのパッケージ入力の確認 | | ユーザー |イメージローカルアカウントを安全に作成する | | デスクトップ |デスクトップ設定の選択と確認 | | 起動スクリプト |制限された初回起動ユニットのオーサリング |

有用な最小の画像から始めます。以前のアーティファクトの動作と証拠を理解した後にのみ、機能を追加してください。