Kubernetes マイクロサービス自動リリースシステム

[[340132]]

この記事はWeChatの公開アカウント「Invincible Coder」から転載したもので、著者はInvincible Coderです。この記事を転載する場合は、Wudi Coder の公開アカウントにご連絡ください。

オリジナルリンク: https://mp.weixin.qq.com/s/WPwoRi240rKaWeIs0yNZ2g

マイクロサービスアーキテクチャを実装すると、元の単一システム構造が多数のマイクロサービスアプリケーションになり、開発、テスト、運用、保守の展開で多くの課題に直面することになります。マイクロサービスアーキテクチャの下でエンジニアリングの研究開発効率を向上させ、開発、テスト、運用、保守の展開などのプロセスを円滑に進めることが、マイクロサービステクノロジーシステムを真に定着させ、メリットを生み出すための鍵となります。

上記の目標を達成するためには、開発者がいつでもどこでもコードをビルドし、指定された動作環境に公開できる、DevOps（開発と運用）のコンセプトに基づいた高度に自動化されたリリースシステムを構築する必要があります。このプロセスは、通常、CI/CD (継続的インテグレーション/継続的デリバリー) プロセスと呼ばれます。

DevOps の具体的な実践に関しては、一般的に各企業が自社の開発段階や実際のニーズに基づいて具体的な実装計画を選択します。資格のある企業は機能豊富なビジュアルパブリッシングシステムを開発できますが、条件が限られているスタートアップは、オープンソースまたは既存の技術コンポーネント (GitLab、Jenkins など) を使用して、比較的シンプルでありながら完全に機能する自動パブリッシングシステムを実装できます。

この記事では、Spring Cloud マイクロサービス技術システムを背景に、GitLab 独自の CI/CD メカニズムと Kubernetes コンテナ化技術を使用して、比較的充実した CI/CD プロセスを備えた自動リリースシステムを実装します。

CI/CD プロセスの概要

実際、DevOps はマイクロサービスアーキテクチャの普及後に登場した概念ではなく、長年のソフトウェア開発の実践を通じて業界が蓄積した理論とツールの集合体です。この記事で説明する自動リリースシステムは、実際には、CI/CD パイプラインを構築することで、アプリケーションの構築、テスト、パッケージ化、リリースを効率的に自動化する方法を確立することです。 CI (継続的インテグレーション)/CD (継続的デリバリー) の概念は、特定のテクノロジーを指すのではなく、ソフトウェアエンジニアリング文化と一連の運用原則および特定のプラクティスを指します。

CI (継続的インテグレーション) の主な目的は、一貫した自動ビルド方法を確立してプログラムコードをパッケージ化することです。これにより、チームメンバーはコードをより頻繁に送信し、コードをより早く統合し、コード内の問題を迅速に発見して解決できるため、共同開発の効率とソフトウェア配信の品質が向上します。継続的インテグレーション (CI) の基本的なプロセスを図に示します。

実装プロセスの観点から見ると、CI の主なプロセスは、開発者が送信したコードを、特定のインフラストラクチャ環境で高度に自動化された方法で実行できるプログラムパッケージ (Docker イメージなど) にパッケージ化することです。このプロセスは、GitLab Runner (CI パイプライン)、Sonar (コードチェックツール) などのツールセットによって完了することができ、CI プロセスを構築するときに実際のニーズに応じて統合および適用できます。

継続的デリバリー (CD) の主なロジックは、CI プロセスで構築されたプログラムイメージをイメージリポジトリから特定のインフラストラクチャ環境 (テスト/本番 Kubernetes クラスターなど) に自動的に公開することです。 CD を実装するための主なツールとしては、GitLab Runner (CD パイプライン)、Helm (Kubernetes パッケージ管理ツール) などが挙げられます。

実際、CD の核心は、さまざまなユーザー入力パラメータ (yaml ファイル、環境構成パラメータなど) を通じて特定のリリース指示 (Helm 指示など) を自動的に生成し、パラメータに設定された対応する情報に従ってプログラムの特定の実行環境を構成することです。持続可能なデリバリー（CD）の基本的な運用プロセスを次の図に示します。

上記は CI/CD の基本的な概念とプロセスであり、自動リリースシステムの実装の基礎でもあります。以下のコンテンツでは、主にこれら 2 つの段階に焦点を当てて、自動公開システムの基本的なプロセスロジックを実装します。

システムの基本コンポーネント

この記事で解説する自動リリースシステムは、主に GitLab が提供する GitLab CI メカニズムを利用して、コードの送信やマージなどのイベントが発生したときに、あらかじめ設定された CI/CD プロセスを自動的にトリガーします。 CI プロセスには、主に基本的なコードのコンパイル、構築、パッケージ化などの段階が含まれます。上記の手順を完了すると、パッケージ化されたアプリケーションの Docker イメージがイメージウェアハウスに公開されます。

CD ステージでは、イメージリポジトリからアプリケーション Docker イメージをプルし、設定された CD プロセスに従って、指定された Kubernetes クラスターにアプリケーションを公開します。具体的なシステム構造を下図に示します。

上図に示すように、自動リリースシステムは主に GitLab、Harbor イメージリポジトリ、Kubernetes クラスターで構成されています。 GitLab は主にコードのバージョン管理、CI/CD プロセスの定義とトリガーを担当し、Harbor はアプリケーション Docker イメージの保存と配布を担当し、Kubernetes クラスターはアプリケーションコンテナを動作させるためのインフラストラクチャ環境です。

GitLab-CI自動リリースシステムの主要実装

先ほど、GitLab-CI メカニズムに基づく自動リリースシステムの基本コンポーネントについて説明しました。このシステムを実装するには、GitLabサーバーをインストールしてデプロイし、GitLab Runner機能、プライベートイメージリポジトリサービス（HarborまたはJFrog）、Kubernetesクラスターを構成する必要があります（詳細についてはこのコラムの他の記事を参照してください）。

GitLab サーバーは CI/CD プロセス実行の主なキャリアポイントであるため、サービスが Maven に基づいて構築された Java サービスである場合は、ビルド速度を上げるために、GitLab サーバーに Maven クライアントをインストールし、Maven プライベートサーバーのアドレスを構成する必要もあります。さらに、GitLab サーバーは、CI/CD プロセス中に Docker イメージのパッケージ化とビルドを実行し、イメージを Docker イメージリポジトリにプッシュし、プライベートリポジトリから Kubernetes クラスターに Docker イメージを公開します。したがって、GitLab サーバーには Docker 環境と kubelet クライアントもインストールする必要があります。

環境が問題なければ、Gitlab プロジェクトのルートディレクトリコードに「.gitlab-ci.yml」ファイルを作成し、特定の CI/CD プロセスを定義できます。ただし、具体的な定義の前に、次のように、Maven プロジェクトにアプリケーション Docker イメージパッケージのプラグイン構成と Dockerfile ファイル定義を追加する必要があります。

 <! --Docker イメージ Maven パッケージング プラグインを追加-->  
 <プラグイン>
    <groupId>com.spotify</groupId>
    <artifactId>dockerfile-maven-plugin</artifactId>
    <バージョン>1.4.13</バージョン>
    <処刑>
        <実行>
            <id>ビルドイメージ</id>
            <phase>パッケージ</phase>
            <目標>
                <goal>ビルド</goal>
            </目標>
        </実行>
    </処刑>
    <構成>
        <! --Dockerfileファイルの場所を指定します-->  
        <dockerfile>docker/Dockerfile</dockerfile>
        <! --Docker イメージ リポジトリ パスを指定します -->  
        <リポジトリ>${docker.repository}/springcloud- action /${app.名前}</リポジトリ>
        <ビルド引数>
            <! -- Dockerfile に渡すパラメータを指定します -->  
            <JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
        </buildArgs>
    </構成>
 </プラグイン>

プロジェクトの pom.xml ファイルに「dockerfile-maven-plugin」プラグインを追加します。このプラグインは、以前の「docker-maven-plugin」プラグインの代わりであり、Maven プロジェクトビルドを Docker イメージとしてパッケージ化することをサポートします。上記の構成では、Dockerイメージの具体的な構築方法は、これは、タグで Dockerfile ファイルを指定することによって行われます。具体的には、プロジェクト内に docker ディレクトリを作成し、次の内容の Dockerfile ファイルを作成します。

 openjdk:8u191-jre-alpine3.9から
ENTRYPOINT [ "/usr/bin/java" 、 "-jar" 、 "/app.jar" ]
引数 JAR_FILE
 ${JAR_FILE} /app.jar を追加します。
エクスポーズ8080

Maven パッケージングプラグインを構成した後、Maven パッケージングコマンドを使用してアプリケーションコードを Docker イメージにパッケージ化できるようになります。この時点で、「.gitlab-ci.yml」ファイルで特定の CI/CD ビルドステージを定義します。例は次のとおりです。

 #環境パラメータ情報
変数:
  #Docker イメージ リポジトリ アドレスとアカウント パスワード情報
  DOCKER_REPO_URL: "10.211.55.11:8088"  
  DOCKER_REPO_USERNAME: 管理者
  DOCKER_REPO_パスワード: Harbor12345
  #Kubernetes関連情報の設定（スペースとサービスポート）
  K8S_NAMESPACE: "ウディマノン"  
  ポート: "8080"   
 
 #CI/CDステージを定義する
ステージ:
  - テスト
  - 建てる
  - 押す
  - 展開する
 
 #ユニットテストフェーズを実行する
mavenテスト:
  ステージ: テスト
  スクリプト：
    - mvnクリーンテスト
 
 #コードのコンパイルとイメージのパッケージ化段階
Mavenビルド:
  ステージ: ビルド
  スクリプト：
    -mvn パッケージをクリーンアップ -DskipTests 
 
 #パッケージ化されたDockerイメージをプライベートイメージリポジトリにアップロードする
docker-push:
  ステージ: プッシュ
  スクリプト：
    #パッケージ化されたイメージにタグを付ける
    - docker タグ $DOCKER_REPO_URL/$CI_PROJECT_PATH $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
    #プライベートイメージリポジトリにログイン
    - docker ログイン $DOCKER_REPO_URL -u $DOCKER_REPO_USERNAME -p $DOCKER_REPO_PASSWORD
    #アプリケーションイメージをイメージリポジトリにアップロードする
    - docker push $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
    - docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
    - docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH 
 
 #Kubernetes テスト クラスターにアプリケーションを公開します (ここでは手動確認を指定します)
デプロイテスト:
  ステージ: デプロイ
いつ：手動
  スクリプト：
    - kubectl config 使用コンテキスト kubernetes-admin@kubernetes
    - sed -e "s/__REPLICAS__/1/; s/__PORT__/$PORT/; s/__APP_NAME__/$CI_PROJECT_NAME/; s/__PROFILE__/test/; s/__IMAGE__/$DOCKER_REPO_URL\/${CI_PROJECT_PATH//\//\\//\/${CI_BUILD_REF_NAME//\//\\/:${CI_COMMIT_SHA:0:8}/" kubernetes/deploy.yaml | kubectl -n ${K8S_NAMESPACE} を適用 -f -

前述のように、「.gitlab-ci.yml」ファイルで「テスト、ビルド、プッシュ、デプロイ」の 4 つのステージを定義しました。これらの段階の具体的な説明は次のとおりです。

test: ユニットテストコードを実行します。
build: ビルドおよびパッケージ化の指示を実行して、アプリケーションを Docker イメージにパッケージ化します。
プッシュ: この段階では主に、ビルドによって構築されたローカル Docker イメージをタグ処理後に Harbor イメージリポジトリにアップロードし、成功した後にローカルイメージファイルをクリーンアップします。
デプロイ: このフェーズでは、主に Kubernetes の命令を実行し、Kubernetes によってリリースされたデプロイメントファイルの構成に従ってコンテナイメージを Kubernetes クラスターにデプロイします。

デプロイフェーズでは、Docker イメージが公開され、Kubernetes クラスターに実行されます。これには、Kubernetes デプロイリリース YAML ファイルの記述が含まれます。具体的な例は以下のとおりです。

 ---  
 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: __APP_NAME__
仕様:
  レプリカ: __REPLICAS__
  セレクタ：
    一致ラベル:
      アプリ: __APP_NAME__
  戦略：
    タイプ: ローリングアップデート
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: __APP_NAME__
    仕様:
      イメージプルシークレット:
        -名前: wudimanong-ecr
      コンテナ:
        -名前: __APP_NAME__
          画像: __画像__
          リソース：
            リクエスト:
              メモリ: "1000M"  
            制限:
              メモリ: "1000M"  
          ボリュームマウント:
            -名前:タイムゾーン
              マウントパス: /etc/localtime
            -名前: java-logs
              マウントパス: /opt/logs
          ポート:
            - コンテナポート: __PORT__
          環境:
            -名前: SPRING_PROFILES_ACTIVE
              値: __PROFILE__
            -名前: JAVA_OPTS
              値: -Xms1G -Xmx1G -Dapp.home=/opt/
      ボリューム:
        -名前:タイムゾーン
          ホストパス:
            パス: /etc/localtime
        -名前: java-logs
          ホストパス:
            パス: /data/app/deployment/logs