マイクロサービスをデプロイする方法を学びます。 パート 1. Spring Boot と Docker

おい、ハブル。

この記事では、マイクロサービスを実験するための学習環境を作成した私の経験について話したいと思います。 新しいツールを学ぶたびに、ローカル マシンだけでなく、より現実的な条件でも試してみたいと常に思っていました。 したがって、私は、後であらゆる種類の興味深いテクノロジで「カバー」できる、簡素化されたマイクロサービス アプリケーションを作成することにしました。 このプロジェクトの主な要件は、実際のシステムに最大限の機能的近接性を持たせることです。

最初に、プロジェクトの作成をいくつかのステップに分けました。

1. XNUMX つのサービス - 「backend」 (バックエンド) と「gateway」 (ゲートウェイ) を作成し、それらを Docker イメージにパックして、連携して動作するように設定します。

   キーワード: Java 11、Spring Boot、Docker、イメージの最適化

2. Google Kubernetes Engine での Kubernetes 構成の開発とシステムのデプロイメント

   キーワード: Kubernetes、GKE、リソース管理、自動スケーリング、シークレット

3. Helm 3 でチャートを作成してクラスター管理を改善する

   タグ: Helm 3、チャートの展開

4. コードをクラスターに自動配信するための Jenkins とパイプラインのセットアップ

   キーワード: Jenkins 構成、プラグイン、個別の構成リポジトリ

各ステップについては別の記事にまとめる予定です。

この一連の記事の焦点は、マイクロサービスの作成方法ではなく、マイクロサービスを単一のシステムで動作させる方法です。 通常、これらすべてのことは開発者の責任の範囲外ですが、少なくとも 20% は知っておくと役に立つと思います (ご存じのとおり、結果の 80% が得られます)。 作成者はこのシステムが個人使用のみを目的として作成されたものであることをほとんど理解していないため、セキュリティなどの無条件に重要なトピックはこのプロジェクトから除外されます。 あらゆる意見や建設的な批判を歓迎します。

マイクロサービスの作成

サービスは Spring Boot を使用して Java 11 で作成されました。 サービス間の対話は REST を使用して組織されます。 プロジェクトには最小限のテストが含まれます (後で Jenkins でテストするものがあるようにするため)。 サービスのソース コードは GitHub で入手できます。 バックエンド и ゲートウェイ.

各サービスのステータスを確認できるようにするために、Spring Actuator が依存関係に追加されました。 /actuator/health エンドポイントを作成し、サービスがトラフィックを受け入れる準備ができている場合は 200 ステータスを返し、問題がある場合は 504 ステータスを返します。 この場合、サービスは非常に単純であり、何らかの不可抗力が発生した場合、部分的に動作し続けるよりも完全に利用できなくなる可能性の方が高いため、これはかなり架空のチェックです。 しかし、実際のシステムでは、Actuator は、ユーザーが問題について格闘し始める前に問題を診断するのに役立ちます。 たとえば、データベースへのアクセスに問題が発生した場合、壊れたサービス インスタンスによるリクエストの処理を停止することで、これに自動的に対応できます。

バックエンドサービス

バックエンド サービスは、受け入れられたリクエストの数を単純にカウントして返します。

コントローラーコード:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/requests")
    public Long getRequestsCount() {
        return counter.incrementAndGet();
    }
}

コントローラーのテスト:

@WebMvcTest(RequestsCounterController.class)
public class RequestsCounterControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void firstRequest_one() throws Exception {
        mockMvc.perform(get("/requests"))
            .andExpect(status().isOk())
            .andExpect(MockMvcResultMatchers.content().string("1"));
    }
}

サービスゲートウェイ

ゲートウェイはリクエストをバックエンド サービスに転送し、次の情報を追加します。

• ゲートウェイID。 これは、サーバーの応答によってゲートウェイのインスタンスを別のインスタンスから区別できるようにするために必要です。
• 非常に重要なパスワードの役割を果たすいくつかの「秘密」（重要なクッキーの暗号化キーの番号）

application.properties の構成:

backend.url=http://localhost:8081
instance.id=${random.int}
secret="default-secret"

バックエンドアダプター:

@Service
public class BackendAdapter {

    private static final String REQUESTS_ENDPOINT = "/requests";

    private final RestTemplate restTemplate;

    @Value("${backend.url}")
    private String backendUrl;

    public BackendAdapter(RestTemplateBuilder builder) {
        restTemplate = builder.build();
    }

    public String getRequests() {
        ResponseEntity<String> response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

コントローラ：

@RestController
@RequiredArgsConstructor
public class EndpointController {

    private final BackendAdapter backendAdapter;

    @Value("${instance.id}")
    private int instanceId;

    @Value("${secret}")
    private String secret;

    @GetMapping("/")
    public String getRequestsCount() {
        return String.format("Number of requests %s (gateway %d, secret %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

実行：

バックエンドを開始します。

./mvnw package -DskipTests
java -Dserver.port=8081 -jar target/microservices-backend-1.0.0.jar

ゲートウェイの起動:

./mvnw package -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

私たちはチェックします：

$ curl http://localhost:8080/
Number of requests 1 (gateway 38560358, secret "default-secret")

すべてが機能しています。 注意深い読者は、ゲートウェイをバイパスしてバックエンドに直接アクセスすることを妨げるものは何もないことに気づくでしょう (http://localhost:8081/requests）。 これを修正するには、サービスを XNUMX つのネットワークに結合し、ゲートウェイのみを外側に「突き出す」必要があります。
また、両方のサービスは XNUMX つのファイル システムを共有し、ストリームを生成し、ある瞬間に相互に干渉し始める可能性があります。 マイクロサービスを分離すると良いでしょう。 これは、アプリケーションを異なるマシンに分散する (多額の費用がかかり、困難)、仮想マシンを使用する (リソースを大量に消費し、起動に時間がかかる)、またはコンテナ化を使用することによって実現できます。 予想どおり、XNUMX 番目のオプションを選択します。 デッカー コンテナ化のツールとして。

デッカー

つまり、docker はアプリケーションごとに XNUMX つずつ、分離されたコンテナーを作成します。 Docker を使用するには、アプリケーションを構築して実行するための手順である Dockerfile を作成する必要があります。 次に、イメージを構築し、イメージ レジストリにアップロードします (いいえ。 Dockerhub) を実行し、XNUMX つのコマンドで任意の Dockerized 環境にマイクロサービスをデプロイします。

ドッカーファイル

画像の最も重要な特性の XNUMX つはそのサイズです。 コンパクトなイメージはリモート リポジトリからのダウンロードが速くなり、占有するスペースが少なくなり、サービスの開始が速くなります。 すべてのイメージは基本イメージに基づいて構築されるため、最も最小限のオプションを選択することをお勧めします。 良い選択肢は、最小限のパッケージを備えた完全な Linux ディストリビューションである Alpine です。

まず、Dockerfile を「額に」書いてみましょう (これは悪い方法だとすぐに言いますので、やめてください)。

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests
EXPOSE 8080
ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

ここでは、JDK がすでにインストールされている Alpine ベースのベース イメージを使用してプロジェクトを構築しています。 ADD コマンドを使用して、現在の src ディレクトリをイメージに追加し、それを作業中 (WORKDIR) としてマークし、ビルドを開始します。 EXPOSE 8080 コマンドは、コンテナ内のアプリケーションがポート 8080 を使用することを Docker に信号で伝えます (これにより、アプリケーションが外部からアクセスできるようになりますが、たとえば、同じ Docker ネットワーク上の別のコンテナからアプリケーションにアクセスできるようになります) ）。

サービスをイメージにパッケージ化するには、各プロジェクトのルートからコマンドを実行する必要があります。

docker image build . -t msvc-backend:1.0.0

結果は 456 MB のイメージになります (このうち、ベースの JDK イメージは 340 MB を占めていました)。 それは、私たちのプロジェクトのクラスが指で数えられるほどであるという事実にもかかわらずです。 画像のサイズを小さくするには:

• 多段階アセンブリを使用します。 最初のステップでプロジェクトをビルドし、XNUMX 番目のステップで JRE をインストールし、XNUMX 番目のステップですべてを新しいクリーンな Alpine イメージにコピーします。 最終的なイメージには、合計で必要なコンポーネントのみが含まれます。
• Javaのモジュール化を使ってみましょう。 Java 9 以降では、jlink ツールを使用して、必要なモジュールだけから JRE を作成できます。

興味のある方のために、画像削減のアプローチに関する優れた記事をここに掲載します。 https://habr.com/ru/company/ruvds/blog/485650/.

最終的な Dockerfile:

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine as builder
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests

FROM alpine:3.10.3 as packager
RUN apk --no-cache add openjdk11-jdk openjdk11-jmods
ENV JAVA_MINIMAL="/opt/java-minimal"
RUN /usr/lib/jvm/java-11-openjdk/bin/jlink 
    --verbose 
    --add-modules 
        java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
    --compress 2 --strip-debug --no-header-files --no-man-pages 
    --release-info="add:IMPLEMENTOR=radistao:IMPLEMENTOR_VERSION=radistao_JRE" 
    --output "$JAVA_MINIMAL"

FROM alpine:3.10.3
LABEL maintainer="Anton Shelenkov [email protected]"
ENV JAVA_HOME=/opt/java-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"
COPY --from=packager "$JAVA_HOME" "$JAVA_HOME"
COPY --from=builder /src/target/microservices-backend-*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

画像を再作成した結果、重量は 6 倍の 77 MB に減りました。 悪くない。 その後、既製のイメージをイメージ レジストリにアップロードして、イメージをインターネットからダウンロードできるようにします。

Docker でサービスを共同実行する

まず、当社のサービスは同じネットワーク上に存在する必要があります。 Docker にはいくつかの種類のネットワークがあり、私たちはその中で最も原始的なブリッジを使用します。これにより、同じホスト上で実行されているコンテナをネットワーク化できます。 次のコマンドを使用してネットワークを作成します。

docker network create msvc-network

次に、microservices-backend:1.0.0 イメージを使用して「backend」という名前のバックエンド コンテナーを起動します。

docker run -dit --name backend --network msvc-net microservices-backend:1.0.0

ブリッジ ネットワークでは、名前によるコンテナーのすぐに使用できるサービス検出が提供されることは注目に値します。 つまり、バックエンド サービスは Docker ネットワーク内で利用可能になります。 http://backend:8080.

ゲートウェイの起動:

docker run -dit -p 80:8080 --env secret=my-real-secret --env BACKEND_URL=http://backend:8080/ --name gateway --network msvc-net microservices-gateway:1.0.0

このコマンドでは、ホストのポート 80 をコンテナのポート 8080 に転送していることを示します。 env オプションを使用して、Spring によって自動的に読み取られる環境変数を設定し、application.properties のプロパティをオーバーライドします。

開始後に呼び出します http://localhost/ 前のケースと同様に、すべてが機能することを確認します。

まとめ

その結果、XNUMX つの単純なマイクロサービスを作成し、それらを Docker コンテナーにパッケージ化して、同じマシン上で一緒に起動しました。 ただし、結果として得られるシステムには、次のような多くの欠点があります。

• 耐障害性が低い - XNUMX 台のサーバーですべてが機能する
• スケーラビリティが低い - 負荷が増加した場合、追加のサービス インスタンスを自動的にデプロイして、それらの間で負荷のバランスをとるとよいでしょう。
• 起動の複雑さ - 少なくとも 3 つのコマンドと特定のパラメーターを入力する必要がありました (これは 2 つのサービスのみに適用されます)。

上記の問題を解決するには、Docker Swarm、Nomad、Kubernetes、OpenShift などの多くのソリューションがあります。 システム全体が Java で書かれている場合は、Spring Cloud (良い記事).

В 次のパート Kubernetes をセットアップし、プロジェクトを Google Kubernetes Engine にデプロイした方法について説明します。

出所： habr.com