DevSecOps パイプラインについて
リファレンス継続的インテグレーションと継続的デプロイメントツールチェーンで提供される様々なパイプラインは、Tekton Pipelinesの Continuous Delivery サポートに基づいています。 Tekton パイプラインについて詳しくは、Tekton パイプラインの操作を参照してください。
リファレンス・パイプラインを使うのにTektonの専門家である必要はない。 リファレンスパイプラインは、ビルド、自動テスト、デプロイなどのステップのためのカスタムスクリプトのプレースホルダーを含む基本的な構造で事前に定義されている。 ユーザーは独自のパイプライン用のカスタム・スクリプトを宣言し、特定のパイプラインにさまざまな環境プロパティーの値を設定できます。
パイプラインの状況タイプ
いくつかのポイントで、参照用パイプラインのエラーや失敗の状態を理解することが重要です。 概念的には、コンプライアンス・パイプラインでタスクを実行した結果として、次の 2 種類の状況があります。
- コンプライアンス状況:
some検査または一連の検査についての状態 (合格または失格)。 - パイプライン状況: タスクの実行自体についての状態 (成功または失敗)。
テスト、スキャン、または検査に失格しても、パイプライン自体が失敗したり停止したりすることはありません。そのテストを実行中のタスクのマークは緑色です。
コンプライアンスの観点から言うと、単体テストの結果はデプロイメントに影響しません。 検査に失格した成果物をデプロイできます。ただし、そのようなアクティビティーについてのエビデンスがプロセスによって保持されます。 障害発生時にフィックスをリリースすることをコンプライアンス・フローがブロックすることはありません。 例えば、テストに失格したことが判明した単体テスト・タスクの実行状況が緑色であるのは、The task ran successfully and found the following issuesということを意味しています。
赤色の状況でタスクが失敗した場合は、パイプラインを続行できないか、続行すべきでないことが原因です。 失敗の状態の例を次に示します。
- タスクまたはパイプラインのエラー。
- パイプラインの実行を続行しても意味がないようなことが起こった。
例えば、継続的統合で成果物のビルドが失敗した場合は、継続的統合のプロセス自体の意味がなくなります。
パイプラインの最終的な状況をコンプライアンスの結果に合わせるために、パイプラインの最後のタスクが、コンプライアンスの結果を検査し、パイプラインの実行状況をredまたはgreenのどちらかに設定します。
プル要求パイプライン
プル要求パイプラインは、指定されたアプリケーション・リポジトリーのプル要求に対して、事前設定されたコンプライアンス状況検査を実行します。 これらのステータスチェックに失敗すると、プルリクエストをデフォルトのアクティブブランチ（通常は master ）にマージできない可能性があります。 デフォルトのアクティブブランチに対してプルリクエストをオープンまたは更新し、プルリクエストパイプラインの実行をトリガーします。 ユーザーは、カスタム・ステージで、このパイプラインのセットアップとテストを独自に実行することができます。
プル要求パイプラインについて詳しくは、プル要求パイプラインを参照してください。
継続的統合パイプライン
継続的統合パイプラインは、アプリケーション (アプリ) リポジトリーにあるデプロイ可能な成果物をビルドします。 このパイプラインは、成果物をビルドする前に、プル要求の処理と同じようにコードがスキャンされてテストされていることを検査します。 ビルドされた成果物もまた、パイプラインで脆弱性がないかスキャンされ、署名された後に、インベントリーの中で、リリースおよびデプロイできる状態であることを示すマークが付けられます。 プル要求パイプラインとは異なり、継続的統合パイプラインは、ビルドの各ステージ (テスト、スキャン、署名など) でエビデンスと結果の成果物を収集します。 このデータは、ビルドされた成果物に対応しているので、デプロイメント・プロセスと変更管理で追跡できます。 継続的統合パイプラインについて詳しくは、継続的統合パイプラインを参照してください。
継続的デプロイメント・パイプライン
継続的デプロイメントパイプラインは、すべてのエビデンスと変更要求の要約コンテンツを生成する。 このパイプラインは、ステージング環境や実稼働環境などの特定の環境にビルド成果物をデプロイしてから、既存のログ・ファイル、エビデンス、成果物のすべてを収集、作成して、エビデンス・ロッカーにアップロードします。 継続的デプロイメント・パイプラインについて詳しくは、 継続的デプロイメント・パイプライン を参照してください。
継続的コンプライアンス・パイプライン
継続的コンプライアンス・パイプラインは、成果物が実稼働環境にデプロイされて以降、デプロイされた成果物とそのソース・リポジトリーを定期的にスキャンして、より新しい脆弱性がないかどうかを調べます。 パイプラインはまた、自動的に期日との乖離を追跡し、アプリケーションの認識を提供するのに役立ちます。 詳細については、 継続的コンプライアンス・パイプラインを 参照。
インベントリー・ワークフロー
エビデンスを参照してください。
インベントリーを参照してください。
継続的統合によるインベントリーへの書き込み
インベントリには、デフォルトのブランチを含むいくつかのブランチが含まれています。 これらのブランチで、デプロイメントの各ステージ、環境、リージョン、あるいはこれらのオプションの組み合わせをセットアップと用途に応じて表すことができます。
デフォルトのブランチは、継続的インテグレーションのビルドから作成されます。 ターゲット (staging など) の最終コミットには、最後に完了したデプロイメントであることを示すタグが付いています。
インベントリのデフォルトブランチが別のブランチに切り替わった場合、 Git のコミット履歴を直線的にするため、以前のデフォルトブランチからのコミットを新しいデフォルトブランチにリベースする必要があります。
プロモーション
ターゲット・ブランチにプロモートするには、プル要求を作成します。 プル要求の内容から、変更要求のフィールドにデータが取り込まれます。 レビューされたら、プロモーションのプル要求をマージできます。
デルタとデプロイメント
プロモーションのプル要求がマージされたら、デプロイメント・パイプラインを開始できます。 デプロイメント・デルタは、完了した最後のデプロイメントの内容と、現行のデプロイメントの内容との差分です。 デプロイメント・デルタは、デプロイされるインベントリー項目のリストです。
完了
デプロイメントが完了すると、latest タグが前に移動します。
開発モード・トリガーの間、タグは拡張されません。開発モード・トリガーの目的は、CD パイプラインのテストのみであり、実稼働環境での使用は推奨されません。
他の環境へのプロモート
プロモーションとデプロイメントは、任意のブランチから別のブランチに対して実行できます。
インベントリーの全体像
デプロイ済みの最新の状態には、環境にデプロイする内容が入っています。 ターゲット・ブランチにプロモートされたすべてのコミットに、関連するパイプライン実行 ID と変更要求 ID がタグとして含まれています。 失敗したデプロイメントが再実行された場合などには、コミットに複数のタグが含まれることがあります。 デプロイメントをやり直せるように、すべての情報がインベントリーに保管されます。
単一ターゲット - 複数リージョンのセットアップ
「単一ターゲット - 複数リージョンのセットアップ」は、単一のターゲット環境に複数の latest タグが導入されるというモデルのイテレーションです。 このモデルでは、同じターゲットに対して、さまざまなタイプのユース・ケース用の複数の継続的パイプラインを機能させることができます。
例えば、ターゲットの実稼働環境やインベントリー・ブランチの複数のリージョン (例えば us-south と eu-de など) に、同じターゲット環境を使用できます。
継続的デプロイメント・パイプラインによってデプロイメント地域を指定するには、 region パラメーターを使用します。 このパラメーターについて詳しくは、 継続的デプロイメントのパイプライン・パラメーター を参照してください。
チームは、 us-south-prod や eu-de-prod のように、地域ごとに異なる支店を設立し、プロモーションを重複して実行する必要はない。 代わりに、同じインベントリー・ブランチにこれらの追加ターゲットを指定し、それらを Git タグとして使用します。
この設定では、prodブランチには、 us-south_prod_latest や eu-de_prod_latest など、同じブランチ上に複数の latest タグがあり、それぞれのリージョンを担当する継続的デプロイメントパイプラインは、これらのタグを使用してデプロイできる。
シナリオの例
最終的にはあらゆる場所にデプロイできる一連の変更を、まずは単一のリージョンにリリースします。 そして、他のリージョンをターゲットとする継続的デプロイメントパイプラインを使用することで、この一連の変更を徐々に他のリージョンにデプロイすることができる。