Oracle Cloud Infrastructure Kubernetes EngineでのJenkinsのスケーリングと最適化
Jenkinsは、開発者がコードを自動的に検証、ビルドおよびデプロイするために引き続き使用されるCI/CDシステムであり、新機能の提供のみに集中できます。
Kubernetesのリリースにより、分散アーキテクチャと共有なしアーキテクチャが徐々に標準となり、最新のCI/CDシステムがKubernetesにデプロイされるようになりました。Jenkinsの場合、コントローラ/エージェント・アーキテクチャは、大規模な組織や開発チームに十分な拡張性がない可能性がありますが、コミュニティの努力のおかげで、Jenkinsをコンテナ化し、クラウドネイティブな方法でデプロイすることが可能です。
Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes EngineまたはOKE)でJenkinsをホストして、ビルド自動化を一元化し、ソフトウェア・プロジェクトの成長に合せてスケーリングできます。OKEにスケーラブルなJenkinsを実装することで、開発者はアジリティの高い新しいサービスを開発し、CI/CDパイプラインを簡単に拡張できるようになります。
アーキテクチャ
この高レベルのリファレンス・アーキテクチャは、OKEでの複数のJenkinsデプロイメントの例を示しています。OKE as a ServiceにJenkinsをデプロイすることで、必要に応じてスケーリングできます。
各Jenkinsコントローラ・ポッドには、パイプライン履歴とチームによってインストールされる追加のプラグインを保持するために、永続ボリュームがアタッチされています。Jenkinsエージェントは、パイプライン・ジョブが最後に自動的にトリガーおよび破棄されるたびに作成されます。
すべてのJenkinsインスタンスは、ロード・バランサまたはKubernetesイングレスを使用して個別に公開できます。
次の図は、このリファレンス・アーキテクチャを示しています。
oci-jenkins-oke-arch-oracle.zip
このアーキテクチャには、次のコンポーネントがあります。
- リージョン
Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。
- 可用性ドメイン
可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、ある可用性ドメインでの障害は、リージョン内の他の可用性ドメインには影響しません。
- 仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用するとネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- セキュリティ・リスト
サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
- Kubernetes Engine
Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes EngineまたはOKE)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、完全に管理されたスケーラブルで可用性の高いサービスです。アプリケーションで必要なコンピュート・リソースを指定すると、KubernetesエンジンがそれらをOracle Cloud Infrastructureの既存のテナンシにプロビジョニングします。OKEは、Kubernetesを使用して、ホストのクラスタにわたるコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化します。
レコメンデーション
- VCN
VCNを作成するときには、必要なCIDRブロックの数を決定し、VCN内のサブネットにアタッチする予定のリソースの数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。
プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。
VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。
サブネットを設計するときには、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能できる同じサブネットにアタッチします。
- セキュリティ
Oracle Cloud Guardを使用して、Oracle Cloud Infrastructure内のOCIリソースのセキュリティをプロアクティブにモニターおよびメンテナンスします。クラウド・ガードでは、定義できるディテクタ・レシピを使用して、リソースにセキュリティの弱点がないか確認し、オペレータおよびユーザーにリスクのあるアクティビティがないか監視します。構成の誤りやセキュアでないアクティビティが検出されると、クラウド・ガードは修正アクションを推奨し、ユーザーが定義できるレスポンダ・レシピに基づいてそれらのアクションの実行を支援します。
最大限のセキュリティーを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成して更新すると、OCIでは、セキュリティ・ゾーン・レシピのポリシーに対して操作が検証され、ポリシーに違反する操作が拒否されます。
- ロード・バランサの帯域幅
ロード・バランサの作成時に、固定帯域幅を提供する事前定義済のシェイプを選択するか、帯域幅範囲を設定するカスタム(フレキシブル)シェイプを指定して、トラフィック・パターンに基づいて帯域幅を自動的にスケーリングできます。どちらの方法でも、ロード・バランサの作成後にいつでもシェイプを変更できます。
- Oracle Cloud Infrastructure Kubernetes Engineおよびコンピュート・シェイプ
少なくとも、2つのノード・プールがOCI Kubernetes Engineにデプロイされます。1つはJenkinsコントローラ用、もう1つはJenkinsエージェント用です。
コストを節約し、ソリューション全体を最適化するには、VM.Standard.A1を使用することをお薦めします。JenkinsはARMインスタンスと完全に互換性があるため、Jenkinsコントローラのフレックス・インスタンス。エージェント・ノード・プールでは、一般にパイプライン・ジョブが短期間でフォルト・トレラントであるため、プリエンプティブル・インスタンスを使用することをお薦めします。
- Oracle Cloud Infrastructure Registry
Oracle Cloud Infrastructure Registryは、イメージをホストするプライベートOCI準拠のコンテナ・リポジトリです。このアーキテクチャではオプションであり、必要なすべてのプラグインがインストールされた独自のJenkinsカスタム・イメージをホストするために使用できます。セキュリティを適用し、一般的に使用されるすべてのプラグインを1つのコンテナ・イメージにパッケージ化するには、カスタムJenkinsコントローラ・イメージを作成することをお薦めします。
考慮事項
このリファレンス・アーキテクチャをデプロイする場合は、次の点を考慮してください。
- パフォーマンスとスケーラビリティ
Kubernetesを使用することで、開発チームの成長や縮小に伴い、Jenkinsコントローラとエージェントの両方を簡単に拡張できます。さらに、パイプライン・ジョブが実行されるたびにエージェント・ポッドが作成されるため、パイプライン・ベースごとにこれらのポッドで使用されるリソースをカスタマイズできます。
- 可用性
可用性を最大限に高めるために、複数のOKEノードを異なる可用性ドメインまたはフォルト・ドメインにプロビジョニングすることをお薦めします。また、Jenkinsを自発的および自発的な中断から保護するために、ポッド中断予算やポッド反アフィニティなどの標準のKubernetesメカニズムを使用できます。
- コスト
このアーキテクチャの目的は、OKEでJenkinsを使用する際のコストを最小限に抑えることでもあります。JenkinsコントローラにARMノードを使用できるため、柔軟なコンピュート・インスタンスの4分の1のコストがかかります。Jenkinsエージェントの場合、プリエンプティブル・インスタンス・ノードを使用すると、顧客は予算の半分を節約できます。