マスター/エージェント・モードでのJenkinsのデプロイ

ソフトウェア開発の高速化は、企業にとって競争上の優位性となっています。ソフトウェア開発プロセスの自動化により、速度と一貫性が向上し、継続的な統合(CI)および継続的なデリバリとデプロイメント(CD)パイプラインが増加します。Jenkinsは、CIおよびCDのすべてのフェーズを自動化できるため、Oracle Cloud Infrastructureのお客様の間で人気のある製品です。Oracle Cloud InfrastructureでJenkinsをホストすると、ビルド自動化を集中化し、ソフトウェア・プロジェクトのニーズの拡大に合せてデプロイメントをスケーリングできます。

アーキテクチャ

このリファレンス・アーキテクチャは、Jenkins Oracle Cloud Infrastructure Computeプラグインを使用して、コントローラ/エージェント・モードでJenkinsをデプロイする方法を示しています。Jenkinsコントローラ・インスタンスにインストールされている場合、プラグインではOracle Cloud Infrastructure内でオンデマンドでエージェント・インスタンスを作成し、ビルド・ジョブの終了後にインスタンスまたは空きリソースを自動的に削除できます。

このアーキテクチャには、1つのデプロイメントの開始点として1つのコントローラ・インスタンスと2つのエージェント・インスタンスが含まれます。エージェント・インスタンスの数またはコントローラ・インスタンスのサイズを必要に応じて調整できます。Jenkinsコントローラ・インスタンスは、Oracle Cloud Infrastructureプラグイン・コードとともにインストールする必要があります。

このアーキテクチャでは、1つの可用性ドメインとリージョナル・サブネットを持つリージョンを使用します。同じ参照アーキテクチャを複数の可用性ドメインを持つリージョンで使用できます。可用性ドメインの数に関係なく、デプロイメントにリージョナル・サブネットを使用することをお薦めします。

このアーキテクチャには、インターネットへのセキュアなアクセスを提供するロード・バランサとNATゲートウェイも含まれています。

次の図は、この参照アーキテクチャを示しています。

jenkins-oci.pngの説明が続きます
図jenkins-oci.pngの説明

jenkins-oci-oracle.zip

このアーキテクチャの代替手段として、Oracle Container Engine for Kubernetes (OKE)を使用できます。このアーキテクチャーはOKEより簡単に設定できますが、OKEは使用するエージェントの数をスケーリングする際の柔軟性を提供します。

アーキテクチャには、次のコンポーネントがあります。

  • Jenkinsコントローラ・インスタンス

    この仮想コンピュート・インスタンスはコントローラ・ノードとして機能します。エージェント・インスタンスの状態(オフラインまたはオンライン)を監視し、エージェントからタスク結果レスポンスを受信します。

  • Jenkinsエージェント・インスタンス

    これらの仮想コンピュート・インスタンスは、エージェント・ノードとして機能します。コントローラノードは必要に応じてそれらを作成し、コントローラノードの指示に従ってすべてのジョブを実行します。

  • リージョン

    Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。地域は他の地域から独立しており、広大な距離で(国または大陸間で)分離できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    すべてのコンピュート・インスタンスは、サブネットにセグメント化できるVCNにデプロイされます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却などのインフラストラクチャや内部可用性ドメイン・ネットワークを共有しません。したがって、ある可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインに影響する可能性はほとんどありません。

  • フォルト・ドメイン

    フォルト・ドメインは、アベイラビリティ・ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインには、独立した電源およびハードウェアを持つ3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションはフォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。

  • ロード・バランサ

    ロード・バランサは、受信トラフィックをJenkinsコントローラ・ノードに分散し、コントローラ・ノードにアクセスするユーザーにインターネット・アクセスを提供します。100Mbpsのロード・バランサを使用することをお薦めします。これは、主にJenkinsコントローラへの接続に使用され、ユーザーへのトラフィック・フローが重くならないためです。

  • NATゲートウェイ

    ネットワーク・アドレス変換(NAT)ゲートウェイはNATサービスを提供します。ゲートウェイのサイズを選択する必要はありません

  • Bastionホスト

    要塞ホストは、クラウド外部からトポロジに対して制御されたセキュアなエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは通常、非武装ゾーン(DMZ)でプロビジョニングされます。クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる既知の単一のエントリ・ポイントがあります。そのため、トポロジへのアクセスを損なうことなく、より機密性の高いコンポーネントを公開しないようにできます。

  • セキュリティ・リスト

    サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

  • ルート表

    仮想ルート表には、サブネットからVCN外部の宛先(通常はゲートウェイを介して)にトラフィックをルーティングするルールが含まれます。

推奨事項

実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として、次の推奨事項を使用します。

  • コンピュート・シェイプ(Jenkinsコントローラ)

    このアーキテクチャは、Jenkinsコントローラ・ノードに2つのコア仮想マシン(VM)シェイプを使用します。コントローラ・ノードは、タスクの分散、エージェント・ノード結果の収集および可用性のエージェント・ノードの監視を担当します。

  • コンピュート・シェイプ(Jenkinsエージェント)

    このアーキテクチャは、Jenkinsエージェント・ノードに4つのコアVMシェイプを使用します。エージェントのCPUがコントローラノードよりも高いことを確認してください。

  • コンピュート・シェイプ(要塞ホスト)

    Bastionホストは、プライベート・サブネット内のすべてのノードにアクセスするために使用されます。VMを使用することをお薦めします。 Standard.E2.1またはVM。 Standard.E2.2シェイプ。

  • VCN

    VCNを作成する場合、VCNのサブネットにアタッチする予定のリソースの数に基づいて、必要なCIDRブロックの数と各ブロックのサイズを決定します。標準のプライベートIPアドレス空間内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、CIDRブロックを変更、追加および削除できます。

    サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。

    リージョナル・サブネットを使用する。

  • セキュリティ・リスト

    セキュリティ・リストを使用して、サブネット全体に適用されるイングレスおよびエグレス・ルールを定義します。

    このアーキテクチャでは、プライベート・サブネット全体に対してICMPが内部的に許可されます。

注意事項

  • パフォーマンス

    最高のパフォーマンスを得るには、Jenkinsコントローラ・ノードに十分なコアおよびメモリーがあることを確認します。エージェント・ノードによって実行されるビルドまたはその他のタスクに応じて、十分なコアおよびメモリーを持つエージェント・ノードを作成します。

  • 可用性

    Jenkinsコントローラ・ノードは、エージェント・ノードの可用性を監視し、必要に応じて新しいノードを生成します。複数の可用性ドメインがあるリージョンでは、異なる可用性ドメイン内のエージェント・ノードのデプロイメント・テンプレート(Jenkinsコントローラ)を作成できます。

  • COSTS

    予想される作業負荷配備に応じて、コントローラノードとエージェントノードの両方でCPUをサイズ設定します。コンソールでノード・シェイプを変更できるため、CPUの数が少なく(できれば2つ)、必要に応じてスケーリングできます。コントローラ・ノードのインスタンス・テンプレートを使用して、エージェント・ノードのシェイプを指定します。

  • モニタリングとアラート

    必要に応じてVMシェイプをスケール・アップまたはスケール・ダウンできるように、コントローラおよびエージェント・ノードのCPUおよびメモリー使用量に対する監視およびアラートを設定します。

デプロイ

この参照アーキテクチャのTerraformコードは、GitHubで使用できます。シングルクリックでコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。または、Terraform CLIを使用して、GitHubからコンピュータにコードをダウンロードし、コードをカスタマイズし、アーキテクチャをデプロイすることもできます。

  • Oracle Cloud Infrastructure Resource Managerを使用してデプロイします。
    1. Oracle Cloudへのデプロイをクリックします

      まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

    2. 条件をレビューし、受け入れます。
    3. スタックをデプロイするリージョンを選択します。
    4. 画面に表示されるプロンプトと指示に従って、スタックを作成します。
    5. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
    6. ジョブが完了するまで待機し、計画を確認します。

      変更を加えるには、「Stack Details」ページに戻り、「Edit Stack」をクリックして、必要な変更を行います。次に、プラン処理を再実行します。

    7. これ以上変更が必要ない場合は、「Stack Details」ページに戻り、「Terraform Actions」をクリックして「Apply」を選択します。
  • Terraform CLIを使用してデプロイします。
    1. GitHubにアクセスします。
    2. コードをローカル・コンピュータにダウンロードまたはクローニングします。
    3. READMEの指示に従います。

変更ログ

このログには、重要な変更のみがリストされます。