第5章 ビルドプロセス
5.1. 1 回のビルドでどこにでもデプロイが可能
コンテナー環境では、ソフトウェアのビルドプロセスはライフサイクルのステージであり、ここでは、アプリケーションコードが必要なランタイムライブラリーと統合されます。このビルドプロセスの管理は、ソフトウェアのスタックのセキュリティーを保護する上で鍵となります。
OpenShift Container Platform をコンテナービルドの標準プラットフォームとして使用することで、ビルド環境のセキュリティーを確保できます。「1 回のビルドでどこにでもデプロイが可能」という理念を背景に、ビルドプロセスの製品がそのままの状態で実稼働にデプロイされるようにすることができます。
コンテナーのイミュータブルな状態を維持することも重要です。実行中のコンテナーにパッチを当てることはできません。その代わりに再ビルドおよび再デプロイを実行します。
5.2. ビルドの管理およびセキュリティー
Source-to-Image (S2I) を使用して、ソースコードとベースイメージを組み合わせることができます。ビルダーイメージ は S2I を利用し、開発および運用チームの再現可能なビルド環境での協業を可能にします。
開発者がビルドイメージを使用して、アプリケーション用に Git でコードをコミットする場合、OpenShift Container Platform は以下の機能を実行できます。
- コードリポジトリーの Webhook または他の自動化された継続的インテグレーション (CI) プロセスのいずれかで、利用可能なアーティファクト、S2I ビルダーイメージ、および新たにコミットされたコードを使用して新規イメージの自動アセンブルをトリガーします。
- 新規にビルドしたイメージを自動的にデプロイし、テストします。
- テスト済みのイメージを実稼働にプロモートします。ここでは CI プロセスを使用して自動的にデプロイされます。
OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。
CI の組み込まれた Jenkins のほかに、独自のビルド/ CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。
関連資料
『OpenShift Container Platform 開発者ガイド』
- 『OpenShift Container Platform アーキテクチャー』:「Source-to-Image (S2I) ビルド」
-
『OpenShift Container Platform イメージの使用』:「「その他のイメージ
Jenkins」
5.3. ビルド時の入力のセキュリティー保護
シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。
たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc ファイルを指定する必要があります。セキュリティー上の理由により、使用する認証情報はアプリケーションイメージで公開しないようにしてください。
この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig に追加できます。
シークレットがない場合は作成します。
$ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
これにより、secret-npmrc という名前の新規シークレットが作成されます。これには、~/.npmrc ファイルの base64 でエンコードされたコンテンツが含まれます。
シークレットを既存の
BuildConfigのsourceセクションに追加します。source: git: uri: https://github.com/openshift/nodejs-ex.git secrets: - secret: name: secret-npmrcシークレットを新規の
BuildConfigに追加するには、以下のコマンドを実行します。$ oc new-build \ openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git \ --build-secret secret-npmrc
関連資料
- 『OpenShift Container Platform 開発者ガイド』: 「入力シークレット」
5.4. ビルドプロセスの設計
コンテナーの層を使用できるようにコンテナーイメージ管理およびビルドプロセスを設計して、制御を分離可能にすることができます。
たとえば、運用チームはベースイメージを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。これにより、開発者はアプリケーション層のみを使用し、コードの作成に集中することができます。
新しい脆弱性情報は常に更新されるので、コンテナーのコンテンツを継続的かつプロアクティブに確認する必要があります。これを実行するには、自動化されたセキュリティーテストをビルドまたは CI プロセスに統合する必要があります。以下に例を示します。
- SAST / DAST – 静的および動的なセキュリティーテストツール
- 既知の脆弱性をリアルタイムにチェックするためのスキャナー。このようなツールは、コンテナー内のオープンソースパッケージをカタログ化し、既知の脆弱性について通知し、スキャン済みのパッケージに新たな脆弱性が検出されるとその更新情報を送信します。
CI プロセスには、セキュリティースキャンで発見される問題について担当チームが適切に対処できるように、これらの問題のフラグをビルドに付けるポリシーを含める必要があります。カスタマイズしたコンテナーに署名することで、ビルドとデプロイメント間に改ざんが発生しないようにします。
関連資料
- 『Red Hat Enterprise Linux Atomic Host Managing Containers』:「Signing Container Images」
