KubernetesでJenkinsを使用するCI / CD

こんにちは

ジェンキンス、ci / cdおよびkubernetesに関するHabréの記事はすでにいくつかありますが、ここではこれらの技術の機能の分析に集中するのではなく、ci / cdパイプラインを構築するための最も単純な構成に集中します。

読者がdockerの基本を理解していることを意味します。kubernetesのインストールと構成のトピックについては触れません。 すべての例はminikubeで表示されますが、大きな変更なしでEKS、GKEなどにも適用できます。

環境

次の環境を使用することをお勧めします。

• テスト-手動展開およびブランチテスト用
• ステージング-マスターに分類されるすべての変更が自動的に展開される環境
• 本番-実際のユーザーが使用する環境。ステージングでの操作性を確認した後にのみ変更が行われます

環境は、同じクラスター内のkubernetes名前空間を使用して編成されます。 このアプローチは、最初はできるだけシンプルかつ高速ですが、欠点もあります。kubernetesでは名前空間が互いに完全に分離されていません。

この例では、各名前空間には、この環境の構成と同じConfigMapのセットがあります。

apiVersion: v1 kind: Namespace metadata: name: production --- apiVersion: v1 kind: ConfigMap metadata: name: environment.properties namespace: production data: environment.properties: | env=production
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヘルム

Helmは、kubernetesにインストールされたリソースの管理に役立つアプリケーションです。

インストール手順はこちらにあります 。

開始するには、クラスターでhelmを使用するように耕うんポッドを初期化する必要があります。

 helm init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ジェンキンス

Jenkinsは、プロジェクトを構築するための非常にシンプルで柔軟性があり人気のあるプラットフォームなので、使用します。 他の環境から分離するために、別のネームスペースにインストールされます。 将来的にヘルムを使用する予定なので、既存のオープンソースチャートを使用してJenkinsのインストールを簡素化することができます。

 helm install --name jenkins --namespace jenkins -f jenkins/demo-values.yaml stable/jenkins
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

demo-values.yamlには、Jenkinsバージョン、インストール済みプラグインのセット、ドメイン名、およびその他の構成が含まれています

この構成では、ログイン用のユーザー名とパスワードとしてadmin / adminを使用し、後で再構成できます。 可能なオプションの1つはgoogle SSOです（これにはgoogle-loginプラグインが必要です。その設定はJenkins> Manage Jenkins> Configure Global Security> Access Control> Security Realm> Login with Googleにあります）。

Jenkinsは、各アセンブリに対して1回限りのスレーブを自動的に作成するようにすぐに構成されます。 これにより、チームはアセンブリに無料のエージェントを期待しなくなり、企業は必要なサーバーの数を節約できるようになります。

また、デフォルトで、PersistenceVolumeは再起動または更新時にパイプラインを保存するように構成されています。

自動展開スクリプトを正しく機能させるには、Jenkinsにcluster-admin権限を付与して、kubernetesのリソースのリストを取得して操作する必要があります。

 kubectl create clusterrolebinding jenkins --clusterrole cluster-admin --serviceaccount=jenkins:default
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

将来的には、新しいバージョンのプラグインや設定変更の場合に、ヘルムを使用してJenkinsを更新できます。

 helm upgrade jenkins stable/jenkins -f jenkins/demo-values.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはJenkins自体のインターフェースを介して実行できますが、ヘルムを使用すると、以下を使用して以前のリビジョンにロールバックする機会があります。

 helm history jenkins helm rollback jenkins ${revision}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーション構築

例として、最も単純なスプリングブートアプリケーションをビルドしてデプロイします。 Jenkinsでも同様にヘルムを使用します。

アセンブリは次の順序で行われます。

• チェックアウト
• 編集
• 単体テスト
• 統合テスト
• アーティファクトアセンブリ
• Dockerレジストリでのアーティファクトの展開
• ステージングへのアーティファクトの展開（マスターブランチのみ）

このために、私はJenkinsファイルを使用します 。 私の意見では、これはプロジェクトアセンブリを構成するための非常に柔軟な（ただし、残念ながら、最も簡単ではありません）方法です。 その利点の1つは、プロジェクト自体のリポジトリにプロジェクトアセンブリの構成を保持できることです。

チェックアウト

bitbucketまたはgithubの組織の場合、Jenkinsfileを使用してリポジトリの存在をアカウント全体で定期的にスキャンし、それらのアセンブリを自動的に作成するようにJenkinsを構成できます。 Jenkinsはマスターとブランチの両方を収集します。 プルリクエストは別のタブに表示されます。 より簡単なオプションがあります-ホストされている場所に関係なく、別個のgitリポジトリを追加します。 この例では、まさにそれを行います。 必要なのは、Jenkins> New item> Multibranch Pipelineメニューで、アセンブリ名を選択し、gitリポジトリをバインドすることです。

編集

Jenkinsはアセンブリごとに新しいポッドを作成するため、mavenまたは同様のコレクターを使用する場合、依存関係は毎回再度ダウンロードされます。 これを回避するには、.m2または同様のキャッシュにPersistenceVolumeを選択し、プロジェクトをビルドするポッドにマウントします。

 apiVersion: "v1" kind: "PersistentVolumeClaim" metadata: name: "repository" namespace: "jenkins" spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の場合、これによりパイプラインを約4分から1分に高速化できました。

バージョニング

CI / CDが正常に機能するには、各ビルドに固有のバージョンが必要です。

非常に良いオプションは、 セマンティックバージョン管理を使用することです。 これにより、後方互換性と非互換性のある変更を追跡できますが、そのようなバージョン管理は自動化がより困難です。

この例では、IDとコミットの日付からバージョンを生成します。ブランチがマスターでない場合は、ブランチの名前も生成します。 例： 56e0fbdc-201802231623またはb3d3c143-201802231548-PR-18

このアプローチの利点：

• 自動化の容易さ
• バージョンからソースコードとその作成時間を取得するのは簡単です
• 視覚的には、候補のリリースバージョン（ウィザードから）または実験的（ブランチから）を区別できます。
  
  しかし：
• このバージョンは口頭でのコミュニケーションでは使いにくい
• 互換性のない変更があったかどうかは明らかではありません。

dockerイメージは同時に複数のタグを持つことができるため、アプローチを組み合わせることができます。すべてのリリースは生成されたバージョンを使用し、本番に該当するものはセマンティックバージョン管理で追加（手動）タグ付けされます。 これは、さらに複雑な実装と、アプリケーションが表示するバージョンのあいまいさに関連しています。

アーティファクト

アセンブリの結果は次のようになります。

• Dockerレジストリから保存およびロードされるアプリケーションを含むdockerイメージ。 この例では、minikubeの組み込みレジストリを使用します。これは、dockerハブ、またはAmazon（ecr）またはgoogleのプライベートレジストリに置き換えることができます（withCredentialsコンストラクトを使用して資格情報を提供することを忘れないでください）。
• ヘルムディレクトリ内のアプリケーションの展開の説明（展開、サービスなど）を含むヘルムチャート。 理想的には、アーティファクトの別のリポジトリに保存する必要がありますが、簡素化するために、gitから必要なコミットをチェックアウトして使用できます。

ジェンキンスファイル

その結果、アプリケーションは次のJenkinsfileを使用して構築されます。

アプリケーションライフサイクル管理用の追加のJenkinsパイプライン

リポジトリが次のように編成されていると仮定します。

• Dockerイメージの形式で個別のアプリケーションを含む
• helmディレクトリにあるhelmファイルを使用して展開できます
• 同じアプローチを使用してバージョン管理され、ヘルムチャートにリビジョンを設定するためのhelm / setVersion.shファイルがあります

その後、アプリケーションのライフサイクルを管理するために、いくつかのJenkinsfileパイプラインを構築できます。

• あらゆる環境への展開
• 環境からの削除
• 生産のステージングで促進する
• 前のバージョンへのロールバック

各プロジェクトのJenkinsfileに、マスターブランチが正常にコンパイルされるたびに、またはデプロイブランチがテスト環境を明示的に要求するたびに実行されるデプロイパイプラインコールを追加できます。

ここでは、すべての手順を含むJenkinsfileを見つけることができます。

したがって、選択したテストまたは戦闘環境で継続的な展開を構築し、ジェンキンスまたはそのメール/スラック/などの通知を使用して、どのアプリケーション、どのバージョン、誰、いつ、どこでインストールされたかを監査することができます。

おわりに

Jenkinsfileとhelmを使用すると、アプリケーション用にci / cdを簡単に構築できます。 この方法は、最近kubernetesの使用を開始し、そのような機能をすぐに使用できるサービスを（理由に関係なく）使用できない小規模なチームに最も関連する場合があります。

ここでは、アプリケーションライフサイクルを管理するための環境、Jenkins、およびパイプラインの構成例と、Jenkinsfileを使用したサンプルアプリケーションを見つけることができます。