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

すべての準備が整ったら、GitLab リポジトリにコードを送信するとビルド パイプラインが自動的にトリガーされ、パイプラインは「.gitlab-ci.yml」ファイルで定義した特定の CI/CD パイプライン ロジックを自動的に実行して、アプリケーションの自動リリースを実現します。

GitLab-CI メカニズムに基づく自動リリース システムは構築が比較的簡単で、多くの開発作業を必要としません。そのため、現在多くのスタートアップ企業がこのタイプのソリューションを使用して、マイクロサービスの自動構築と配信を実現しています。

以上がこの記事で私が伝えたいことの全てです。自動公開システムの実装原理を理解する一助になれば幸いです。