DockerとDocker Compose

要旨

DockerとDocker Composeの使用は、開発では非常に推奨されており、プロダクション環境でも良い解決策となります。

1. 説明
2. 前提条件
3. アプリケーションのDockerイメージを構築する
4. 複数のアプリケーション用のカスタムDocker-Compose設定の生成
5. データベースの操作
6. Elasticsearch
7. Sonar
8. Keycloak
9. 共通コマンド
10. メモリの調整

Description

注意:このDocker設定は、生成されたアプリケーションをコンテナイメージ内で実行するために使用されます。これは、JHipsterが提供するDocker setupとはまったく異なります。これは、コンテナ_内でJHipsterジェネレータを実行するためのものです。

JHipsterは、次の目的のために、完全なDockerサポートを提供します。

• 開発が容易になります。複雑なマイクロサービスアーキテクチャを使用している場合でも、1つのコマンドで完全なインフラストラクチャを開始できます。
• Docker Swarmを使用しているユーザであれば、同じDocker Compose設定を使用するため、プロダクション環境に直接デプロイできます。

Docker Composeの優れた機能の1つは、docker-compose scaleコマンドを使用してコンテナをスケールできることです。これは、マイクロサービスアーキテクチャでJHipsterを使用する場合に非常に興味深いことです。

アプリケーションを生成するとき、JHipsterは、データベースなどのサードパーティサービスでアプリケーションを実行するのに役立ついくつかのDocker Compose構成を生成します。これらのファイルは、フォルダsrc/main/docker/内にあります。

前提条件

DockerとDocker Composeをインストールする必要があります。

• Docker
• Docker Compose

Docker for MacとDocker for Windowsをダウンロードするには、Dockerストアのアカウントを作成する必要があります。今回はこれを回避します。

tip

WindowsとMac OS Xにおいては、KitematicはDocker Toolboxで提供される使いやすいグラフィカルインタフェースであり、Dockerをより簡単に使用できます。

:::注意

MacまたはWindowsでDocker Machineを使用している場合、DockerデーモンはOS XまたはWindowsファイルシステムへのアクセスが制限されています。Docker Machineは、/Users(OS X)やC:\Users<username>(Windows)ディレクトリを自動共有しようとします。そのため、問題を回避するには、このディレクトリの下にプロジェクトフォルダを作成する必要があります。

:::

JHipster UML（またはバンドルされていないパッケージ）のインストール時にエラーnpm ERR! Error: EACCES: permission deniedが発生した場合は、コンテナにsudoがインストールされていない可能性があります（たとえば、sudoはUbuntu Xenialにバンドルされていません）。

手順 1

NPMのドキュメントでは、NPMパッケージをルートとしてインストールしないことを推奨しています。これを修正するには、公式ドキュメントに従ってください。

手順 2

• docker container exec -u root -it jhipster bash,
• npm install -g YOUR_PACKAGE,
• exitしてから docker container exec -it jhipster bash でコンテナにログインします。

アプリケーションのDockerイメージの構築と実行

Jibを使用してアプリケーションのDockerイメージを構築するために、ローカルのDockerデーモンに接続します。

• NPM: npm run java:dockerを実行。Apple Siliconの場合はnpm run java:docker:arm64となります。
• Maven: ./mvnw package -Pprod verify jib:dockerBuild
• Gradle: ./gradlew -Pprod bootJar jibDockerBuild

Dockerを使用せずにアプリケーションのDockerイメージを構築し、Dockerレジストリに直接プッシュするには、次のコマンドを実行します。

• Maven: ./mvnw package -Pprod verify jib:build -Djib.to.image=<dockerhub-username>/<artifact-id>
• Gradle: ./gradlew -Pprod bootJar jib -Djib.to.image=<dockerhub-username>/<artifact-id>

これがそのままではうまくいかない場合、Jibのドキュメントを参照して、設定の詳細、特にDockerレジストリへの認証の設定方法に関する詳細を確認してください。

• Jib maven plugin documentation
• Jib gradle plugin documentation

warning

Jibの動作原理として、Jibはまず、設定されたDockerレジストリからベースDockerイメージの最新バージョンをプルしようとします。CI環境では、常に最新のパッチが適用されたベースイメージの上に構築する必要があるため、これは意図的な動作です。

ただしローカル環境では、jibがDockerレジストリにアクセスできない場合ビルドに失敗する可能性があります。この回避策は、--offlineフラグを使用することであり、jibがキャッシュ内のベースDockerイメージをすでにプルしている限り、この問題を修正します。

Mavenでは

./mvnw -Pprod package verify jib:dockerBuild --offline

とします。 Gradleでは

./gradlew -Pprod bootJar jibDockerBuild --offline

とします。

jibがキャッシュ内のベースDockerイメージをまだプルしていない場合、それを行うには、pom.xml(Mavenの場合)またはdocker.gradle(Gradleの場合)を修正して、ベースイメージのプレフィックスとしてdocker://を追加する必要があります("from"タグにネストされた"image"タグの位置に該当します)。

例:

docker://imagename:latest

このようにして、jibはローカルのdockerデーモンにあるイメージをキャッシュに入れます。

このイメージを実行するには、アプリケーションのsrc/main/dockerフォルダにあるDocker Compose設定を使用します。

• docker-compose -f src/main/docker/app.yml up

このコマンドによって、アプリケーションとそれに依存するサービス（データベース、検索エンジン、Consul、JHipster Registryなど）が起動されます。

認証にOAuth 2.0を選択した場合は、このドキュメントのKeycloakセクションを必ずお読みください。

複数のアプリケーション用のカスタムDocker-Compose設定の生成

アーキテクチャが複数のJHipsterアプリケーションで構成されている場合は、docker-composeサブジェネレータを使用して、選択したすべてのアプリケーションに対してグローバルなDocker Compose設定を生成できます。これにより、1つのコマンドでアーキテクチャ全体をデプロイし、スケーリングできます。 docker-composeサブジェネレータを使用するには以下のようにします。

• すべてのモノリス、ゲートウェイ、マイクロサービスを同じディレクトリに置く必要があります。
• mkdir docker-compose で、別のディレクトリを作成します。
• cd docker-compose で、ディレクトリに移動します。
• サブジェネレータjhipster docker-composeを実行します。
• サブジェネレータは、アーキテクチャにどのアプリケーションを含めるか、また、ELKまたはPrometheusを使用して監視を設定するかどうかを尋ねます。

これにより、グローバルなDocker Compose設定が生成され、docker-compose upと入力して実行すると、すべてのサービスが一度に実行されます。

マイクロサービスアーキテクチャの場合、この設定によりConsulまたはJHipster Registryも事前設定され、サービスも自動的に設定されます。

• これらのサービスは、Consul（またはJHipsterレジストリ）が起動するまで待機します。これは、spring.cloud[.consul].config.fail-fastおよびspring.cloud[.consul].config.retryキーを使用して、bootstrap-prod.ymlファイルで設定できます。
• レジストリーはアプリケーションを構成します。例えば、すべてのサービス間でJWTシークレットトークンを共有します。
• 各サービスのスケーリングはDocker Composeを使用して行われます。たとえば、docker-compose scale test-app=4と入力すると、アプリケーション"test"の4つのインスタンスが実行されます。これらのインスタンスはゲートウェイによって自動的にロードバランシングされ、同じHazelcastクラスタに自動的に参加します（HazelcastがHibernateの第2レベルのキャッシュである場合）。

データベースの操作

MySQL, MariaDB, PostgreSQL, Oracle, MongoDB, Couchbase, Neo4j, Cassandra

docker-compose -f src/main/docker/app.yml upを実行するとデータベースが自動的に起動されます。

データベースのみを起動し、他のサービスを起動しない場合は、データベースのDocker Compose設定を使用します。

• MySQL: docker-compose -f src/main/docker/mysql.yml up
• MariaDB: docker-compose -f src/main/docker/mariadb.yml up
• PostgreSQL: docker-compose -f src/main/docker/postgresql.yml up
• Oracle: docker-compose -f src/main/docker/oracle.yml up
• MongoDB: docker-compose -f src/main/docker/mongodb.yml up
• Cassandra: docker-compose -f src/main/docker/cassandra.yml up
• Couchbase: docker-compose -f src/main/docker/couchbase.yml up
• Neo4j: docker-compose -f src/main/docker/neo4j.yml up

MongoDBのクラスタモード

MongoDBをレプリカセットまたはシャードとそれらの間の共有構成で使用したい場合は、手動でMongoDBイメージを構築して設定する必要があります。 そのためには、次の手順を実行します。

• イメージをビルドします：docker-compose -f src/main/docker/mongodb-cluster.yml build
• データベースを実行します：docker-compose -f src/main/docker/mongodb-cluster.yml up -d
• MongoDBノードサービスをスケールさせます（奇数のノードを選択する必要があります）：docker-compose -f src/main/docker/mongodb-cluster.yml scale <name_of_your_app>-mongodb-node=<X>
• mongo設定サーバのレプリカを初期化します：docker exec -it <name_of_your_app>-mongodb-config mongo  --port 27019 --eval 'rs.initiate();'
• レプリカセットを初期化します（パラメータXは前のステップで入力したノードの数です。フォルダはYMLファイルがあるフォルダ、デフォルトではdockerです）:docker container exec -it <yml_folder_name>_<name_of_your_app>-mongodb-node_1 mongo --port 27018 --eval 'var param=<X>, folder="<yml_folder_name>"' init_replicaset.js
• シャードを初期化します：docker container exec -it <yml_folder_name>_<name_of_your_app>-mongodb_1 mongo --eval 'sh.addShard("rs1/<yml_folder_name>_<name_of_your_app>-mongodb-node_1:27018")'
• アプリケーションのDockerイメージを構築します：./mvnw -Pprod clean verify jib:dockerBuildまたは./gradlew -Pprod clean bootJar jibDockerBuild
• アプリケーションを起動します：docker-compose -f src/main/docker/app.yml up -d <name_of_your_app>-app

MongoDBノードを追加または削除する場合は、ステップ3と4を繰り返します。

Couchbaseクラスタモード

Couchbaseを複数のノードで使用したい場合は、Couchbaseイメージを手動で構築して設定する必要があります。 そのためには、次の手順を実行します。

• イメージをビルドします：docker-compose -f src/main/docker/couchbase-cluster.yml build
• データベースを実行します：docker-compose -f src/main/docker/couchbase-cluster.yml up -d
• Couchbaseノードサービスをスケールさせます（奇数のノードを選択する必要があります）：docker-compose -f src/main/docker/couchbase-cluster.yml scale <name_of_your_app>-couchbase-node=<X>
• アプリケーションのDockerイメージを構築します：./mvnw -Pprod clean verify jib:dockerBuildまたは./gradlew -Pprod clean bootJar jibDockerBuild
• アプリケーションを起動します：docker-compose -f src/main/docker/app.yml up -d <name_of_your_app>-app

Cassandra

スキーママイグレーションがアプリケーション自体によって適用される他のデータベースとは異なり、Cassandraのスキーママイグレーションは専用のDockerコンテナによって適用されます。

開発環境のCassandra

Cassandraクラスタを起動してアプリケーションをローカルで実行するには、開発用のdocker_composeファイルを使用します。 docker-compose -f src/main/docker/cassandra.yml up -d

Docker-composeは2つのサービスを開始します。

• <name_of_your_app>-cassandra: Cassandraノードのコンタクト・ポイントを持つコンテナ
• <name_of_your_app>-cassandra-migration: すべてのCQL移行スクリプト（キースペースの作成、テーブルの作成、すべてのデータ移行など）を自動的に適用するコンテナ

ローカルクラスタを再起動せずに新しいCQLスクリプトを追加する方法の詳細については、Cassandraのページを参照してください。

プロダクション環境のCassandra：

app.ymldocker-composeファイルは、クラスタの設定にcassandra-cluster.ymlを使用します。 アプリケーションは数秒後に起動し（_JHIPSTER_SLEEP_変数を参照）、クラスタが起動して移行が適用されるまでの時間が与えられます。

Cassandraと他のデータベースの大きな違いとして、Docker Composeを使用してクラスタをスケールできることがあります。クラスタ内にX+1ノードを配置するには、次のコマンドを実行します。

• docker-compose -f src/main/docker/cassandra-cluster.yml scale <name_of_your_app>-cassandra-node=X

Microsoft SQL Server

JHipsterでMSSQL Dockerイメージを使用したい場合は、以下のステップに従う必要があります。

• Dockerで利用可能なRAMを少なくとも3.25 GBに増やします。
• データベースを起動します：docker-compose -f src/main/docker/mssql.yml up -d
• 任意のMSSQLクライアントを使用してデータベースを作成します。
• アプリケーションを起動します：docker-compose -f src/main/docker/app.yml up -d <name_of_your_app>-app

Elasticsearch

docker-compose -f src/main/docker/app.yml up によって検索エンジンが自動的に起動されます。

Elasticsearchノードのみを起動し、他のサービスを起動しない場合は、特定のDocker Compose設定を使用します。

• docker-compose -f src/main/docker/elasticsearch.yml up

Sonar

Sonarを実行するためのDocker Compose設定が生成されます。

• docker-compose -f src/main/docker/sonar.yml up

コードを分析するには、プロジェクトでSonarを実行します。

• Maven: ./mvnw initialize sonar:sonar
• Gradle: ./gradlew sonar

Sonarのレポートは次のサイトで入手できます：http://localhost:9000

Keycloak

認証にOAuth 2.0を選択した場合、KeycloakがデフォルトのIDプロバイダとして使用されます。docker-compose -f src/main/docker/app.yml upによりKeycloakが自動的に起動します。

Keycloakを動作させるには、hostsファイルに次の行を追加する必要があります（Mac/Linuxの場合は/etc/hosts、Windowsの場合はc:\Windows\System 32\Drivers\etc\hosts）。

127.0.0.1	keycloak

理由として、マシン上のブラウザ（名前はlocalhostまたは127.0.0.1）を使用してアプリケーションにアクセスしますが、Docker内では独自のコンテナ（名前はkeycloak）で実行されるためです。

他のサービスではなく、Keycloakのみを起動したい場合は、特定のDocker Compose設定を使用します。

• docker-compose -f src/main/docker/keycloak.yml up

共通コマンド

コンテナの一覧を出力

docker container ps -aでコンテナ一覧を出力できます。

$ docker container ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
fc35e1090021        mysql               "/entrypoint.sh mysql"   4 seconds ago       Up 4 seconds        0.0.0.0:3306->3306/tcp   sampleApplication-mysql

コンテナのDocker統計情報

docker container stats or docker container stats $(docker container ps --format={{.Names}}) により実行中のすべてのコンテナについて、CPU、メモリ、ネットワークI/O、およびブロックI/Oの統計情報とともに一覧表示します。

$ docker container stats $(docker container ps --format={{.Names}})
CONTAINER                 CPU %               MEM USAGE / LIMIT     MEM %               NET I/O               BLOCK I/O             PIDS
jhips-mysql               0.04%               221 MB / 7.966 GB     2.77%               66.69 kB / 36.78 kB   8.802 MB / 302.5 MB   37
00compose_msmongo-app_1   0.09%               965.6 MB / 7.966 GB   12.12%              121.3 kB / 54.64 kB   89.84 MB / 14.88 MB   35
00compose_gateway-app_1   0.39%               1.106 GB / 7.966 GB   13.89%              227.5 kB / 484 kB     117 MB / 28.84 MB     92
jhipster-registry         0.74%               1.018 GB / 7.966 GB   12.78%              120.2 kB / 126.4 kB   91.12 MB / 139.3 kB   63
gateway-elasticsearch     0.27%               249.1 MB / 7.966 GB   3.13%               42.57 kB / 21.33 kB   48.16 MB / 4.096 kB   58
00compose_jhips-app_1     0.29%               1.042 GB / 7.966 GB   13.08%              101.8 kB / 78.84 kB   70.08 MB / 13.5 MB    68
msmongo-mongodb           0.34%               44.8 MB / 7.966 GB    0.56%               49.72 kB / 48.08 kB   33.97 MB / 811 kB     18
gateway-mysql             0.03%               202.7 MB / 7.966 GB   2.54%               60.84 kB / 31.22 kB   27.03 MB / 297 MB     37

コンテナのスケール

docker-compose scale test-app=4により、アプリケーション"test"の4つのインスタンスを実行します。

コンテナの停止

docker-compose -f src/main/docker/app.yml stop

Dockerへの直接の操作もできます。

docker container stop <container_id>

コンテナを停止しても、コンテナを削除しない限り、データは削除されません。

コンテナの削除

すべてのデータが削除されることに注意してください。

docker container rm <container_id>

メモリの調整

コンテナで実行されるアプリケーションのメモリ使用量を最適化するために、Dockerfileまたはdocker-compose.ymlでJavaメモリパラメータを設定できます。

Dockerfileへのメモリパラメータの追加

環境変数を設定します。

ENV JAVA_OPTS=-Xmx512m -Xms256m

docker-compose.ymlへのメモリパラメータの追加

Dockerfileよりも望ましい方法です。このようにすると、アプリケーションを構成するすべてのコンテナのメモリ構成に対して、単一のコントロールポイントを持つことができます。

JAVA_OPTSをenvironmentセクションに追加します。

environment:
  - (...)
  - JAVA_OPTS=-Xmx512m -Xms256m

Dockerベースイメージによっては、JAVA_OPTSが動作しない場合があります。この場合は、代わりに_JAVA_OPTIONSを使用してみてください。

environment:
  - (...)
  - _JAVA_OPTIONS=-Xmx512m -Xms256m