第6章 デプロイメント

ビルドプロセスで何らかの問題が生じる場合や、イメージのデプロイ後に脆弱性が発見される場合に、自動化されるポリシーベースのデプロイを実行するツールを使用できます。イメージの再ビルドおよび置き換えはトリガーを使用して実行できます。実行中のコンテナーにパッチを当てる方法は推奨されていません。

たとえば、3 つのコンテナーイメージ層 (コア、ミドルウェア、アプリケーション) を使用してアプリケーションをビルドするとします。コアイメージに問題が見つかり、そのイメージは再ビルドされました。ビルドが完了すると、イメージは OpenShift Container レジストリーにプッシュされます。OpenShift Container Platform はイメージが変更されたことを検知し、定義されたトリガーに基づいてアプリケーションイメージを自動的に再ビルドし、デプロイします。この変更には修正されたライブラリーが組み込まれ、実稼働コードが最新のイメージと同じ状態になります。

oc set triggers コマンドは、デプロイメント設定のデプロイメントトリガーを設定するために使用できます。たとえば、frontend というデプロイメント設定に ImageChangeTrigger を設定する場合は、以下を実行します。

$ oc set triggers dc/frontend \
    --from-image=myproject/origin-ruby-sample:latest \
    -c helloworld

関連資料

重要な点として、対象とするイメージが実際にデプロイされていることや、そのイメージが信頼されるソースからのものであること、またそれらが変更されていないことを確認できる必要があります。これは、暗号による署名を使用して実行できます。OpenShift Container Platform では、クラスター管理者がデプロイメント環境とセキュリティー要件を反映した (広義または狭義のものを含む) セキュリティーポリシーを適用できます。このポリシーは、以下の 2 つのパラメーターで定義されます。

これらのポリシーパラメーターにより、レジストリーまたはレジストリーの一部および個別のイメージもホワイトリスト化 (accept) またはブラックリスト化 (reject) するか、または信頼されたパブリックキーを使用して信頼関係を定義し、ソースが暗号を使って検証されていることを確認できます。このポリシールールはノードに適用されます。ポリシーは、すべてのノード全体に均一に適用されるか、または異なるノードのワークロード (例: ビルド、ゾーン、または環境) ごとにターゲットが設定される場合があります。

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "insecureAcceptAnything"}]
        }
    }
}

ポリシーは /etc/containers/policy.json としてノードに保存できます。この例では、以下のルールを実施しています。

ホストの設定に関する詳細な説明については、「イメージ署名サポートの有効化」を参照してください。「署名トランスポート」に関する詳細は、以下のセクションを参照してください。イメージ署名ポリシーに関する詳細は、「署名検証ポリシーファイル形式」のソースコードについてのドキュメントを参照してください。

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、dockercfg ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種のアクションを実行することもできます。

たとえば、プライベートイメージリポジトリーにアクセスできるように、シークレットを Web コンソールを使用してデプロイメント設定に追加するには、以下を実行します。

ConfigMap はシークレットに似ていますが、機密情報を含まない文字列の使用をサポートするように設計されています。ConfigMap オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。

関連資料

Security Context Constraints (SCC) を使用して、Pod のシステムでの受け入れを可能にするために (コンテナーのコレクションである) Pod の実行時に必要となる一連の条件を定義することができます。

以下は、SCC で管理できる分野の一部です。

必要なパーミッションがある場合は、デフォルトの SCC ポリシーの許容度を上げるように調整することができます。

関連資料

独自の継続的デプロイメント (CD) のツールを OpenShift Container Platform に統合することができます。

CI/CD および OpenShift Container Platform を利用することで、アプリケーションの再ビルドプロセスを自動化し、最新の修正の組み込み、テスト、および環境内の至るところでのデプロイを可能にします。