構成データの検証と修正

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間:5分
  • 環境が変更されるたびに、数十または数百のルール (ポリシー) をチェックする必要がある場合があります。 CDM を使用すると、構成データを自動検証して、構成データが消費される前に、構成変更にエラーがなく、ポリシーに準拠していることを確認できます。

    重要:
    DevOps コンフィグ は現在は廃止されており、新しいアクティベーションのサポートや利用は終了しています。

    CDM 検証プロセスの多くを自動化

    チームがアプリケーションをデプロイするときは、通常、コードおよび構成レベルでエラーが発生しないようにし、コンプライアンス ポリシーが遵守されていることを確認する必要があります。環境が変更されるたびに、数十または数百のルール (ポリシー) をチェックする必要がある場合があります。手動の検証プロセスではエラーが発生しやすくなります。

    DevOps は、開発者、IT アドミン、 DevOps コンフィグ エンジニア、またはチームリーダーに、構成変更にエラーがなく、ポリシーに準拠していることを確認する方法を提供します。さらに、検証後に、問題を特定して修正するのに十分なコンテキスト情報を開発者または IT アドミニストレーターに提供します。つまり、ユーザーが構成データへの変更をコミットすると、関連するすべてのポリシーが適用され、結果が評価され、適切なアクションがトリガーされます (展開するかしないかなど)。

    構成データを消費する前に自動検証する CDM プロセスを次に示します。

    1. 既存のポリシーに基づいてポリシーバージョンを作成し、新しいバージョンをアクティブ化して公開します。
    2. ポリシーを展開可能項目にマッピングし、要求 (手動または自動要求) 時に展開可能項目の任意のスナップショットに対してポリシーが実行されるようにします。
    3. 展開可能項目の変更セットをコミットする場合、システムは結果のスナップショットを検証する必要があります。変更セットがコミットされるたびにマッピングされたポリシーの実行を自動トリガーするには、変更セットをコミットするときに [検証 ] オプションを選択します。スナップショットを手動で検証するオプションもあります。

      どちらの場合も、静的マッピングと動的マッピングを使用してマッピングされたポリシーが実行されます。

      • パイプラインと統合されるように自動プロセスを構成した場合、ポリシーは検証プロセスの結果を JSON ファイルでパイプラインに返します。パイプラインは、検証の決定 (準拠、非準拠) に基づいて続行するかどうかを決定します。
      • プロセスがパイプラインと統合されていない場合、または検証に失敗した場合や完了しなかった場合は、検証の決定を確認し、適切なアクションを実行します。

    カスタムポリシーのモデルとして事前定義されたポリシーを使用する

    CDM には、特定のニーズを満たすカスタムポリシーのモデルとして使用できるポリシーが含まれています。事前定義されたポリシーの次の重要なパターンに注意してください。
    • すべてのポリシーは、 CdmQuery スクリプトインクルードを使用して構成データを取得します。
    • CdmQuery をシークレットとともに使用して、すべてのデータが含まれるようにします。
    • CdmPolicyUtil スクリプトインクルードは、警告と失敗を追加します。
    • すべてのポリシーが実行され、出力にエラーが入力されると、決定は non_compliantになります。
    • デバッグにはロガーを使用します。ポリシーを公開する準備ができたら、ログを削除します。
    • マッピング入力パラメーターを使用して、動的入力値を指定します。

    スナップショットの検証に関するガイドライン

    • 既に検証および公開されているスナップショットを手動で検証しないでください。
    • 変更セットのコミット時に [ スナップショットを検証 ] または [ スナップショットを検証して公開] オプションを選択した場合、各スナップショットは最初に生成されたときに自動検証されます。
    • スナップショットの現在の検証の失敗または警告を表示するには、スナップショットを開き、[ 検証結果 ] タブを選択します。詳細については、「スナップショット検証の結果を表示する」を参照してください。
    • ポリシーテストプレイグラウンド機能を使用して、ポリシーの開発中にスナップショットを再検証します。結果の検証結果にはテスト結果としてフラグが付けられ、操作には影響しません。
    • 展開可能項目のすべてのスナップショットを再検証する必要がある場合は、ポリシーをテストして公開した後にのみ再検証します。

    避けるべきプラクティス

    • 構成データレコードの取得に GlideRecord を使用しないでください。
    • UI にポリシー決定を表示するには、 CDM で特定の構造に警告および失敗データが必要です。CdmPolicyUtil を使用して、警告または失敗 (手動挿入ではない) を追加します。(少なくとも、 CdmPolicyUtil が失敗と警告に挿入する構造を理解してください)。
    • ポリシーでは、 CDM データに由来しないデータを取得しようとしないでください。この方法では、クロススコープアクセスの問題が発生する可能性があります。
    • 「常に準拠」または「常に準拠しない」ポリシーを作成しないでください。
    • ポリシーには名前や値をハードコーディングしないでください。代わりに、マッピング入力パラメーターを使用して動的入力値を指定します。

    スナップショットステータス

    • 未検証:これは、スナップショットに対してポリシーが実行されていない初期スナップショットステータスです。
    • 要求済み:検証フローが開始されました。
    • 進行中:検証フローが実行されており、ポリシーが現在実行中です。
    • Passed:スナップショットはすべてのポリシーに合格しました。
    • 失敗:スナップショットが 1 つ以上のポリシーで失敗しました。
    • 実行エラー:予期しないエラーにより、ポリシーを完了まで実行できませんでした

    フロー例

    ユーザーは、展開前に構成データへの変更をコミットします。

    データは、アサインされているすべてのポリシーに対して検証されます。

    検証に失敗すると、デプロイが停止します。構成データ内の場所を示すエラーのリストがユーザーに表示されます。使用可能なアクションは、アプリケーション自体とアプリケーションがデプロイされている環境のコンテキストで決定する必要があります。たとえば、次のようになります。
    • エラーや警告の数に関係なく、TEST 環境での展開を許可します。
    • エラーが発生した場合は、本番での展開を停止します。
    • 警告が発生した場合、およびアプリケーションが重要な場合は、本番での展開を停止します。
    • 重大でない場合は、警告の数に関係なく本番での展開を許可します。

    ユーザーがエラーを修正し、変更を再コミットします。

    データが再度検証され、結果は問題ありません。

    スナップショットが取得されます。

    展開が実行されます。