初期化タスク
Quarkusのエクステンションによって実行される初期化タスクには、一度だけ実行されるものがよくあります。 例えば、FlywayやLiquibaseの初期化などがそれに該当します。 しかし、アプリケーションのスケーリングニーズによって、より多くのインスタンスを実行する必要がある場合はどうなるでしょうか? あるいは、アプリケーションが再起動した場合はどうなるでしょうか?
この両方のケースがよくある環境は、Kubernetesです。 このような課題に対処するため、Quarkusでは、このようなタスクをKubernetes ジョブ として外部化し、 initコンテナー を使用して、初期化ジョブが終了した後にのみアプリケーションインスタンスが起動するようにします。 このアプローチでは、アプリケーションに複数のレプリカがあっても、初期化ロジックは一度しか実行されません。
このアプローチは、 Kubernetesエクステンション によって生成されるマニフェストに反映されています。
機能の無効化
この機能はタスクごとに明示的に無効にすることができます(デフォルトでは有効)。デフォルトの動作は、次のプロパティを false
に設定することで変更できます:
quarkus.kubernetes.init-task-defaults.enabled=false
あるいはOpenShift上では次を使用することができます:
quarkus.openshift.init-task-defaults.enabled=false
注意 : このガイドのすべての設定オプションは、OpenShiftとKubernetesの両方で利用可能です。残りのガイドではKubernetes( quarkus.kubernetes
prefix)の設定プレフィックスを使用しますが、すべての設定オプションはOpenShift( quarkus.openshift
prefix)でも使用できます。
特定のタスクを無効にする必要がある場合、以下のプロパティを使用できます:
quarkus.kubernetes.init-tasks."<task name>".enabled=false
タスク名は初期化を実行するエクステンションの名前です。例
Flywayの場合:
quarkus.kubernetes.init-tasks.flyway.enabled=false
Liquibaseの場合:
quarkus.kubernetes.init-tasks.liquibase.enabled=false
Liquibase Mongodb の場合:
quarkus.kubernetes.init-tasks.liquibase-mongodb.enabled=false
生成されたジョブの制御
ジョブコンテナはアプリケーションコンテナとよく似ていて、変わるのは設定された環境変数だけです。 具体的には、初期化直後にジョブを終了させるために次の環境変数が追加されます。
QUARKUS_INIT_AND_EXIT=true
イメージ、イメージプルポリシー、サービスアカウント、ボリューム、マウント、および追加の環境変数は、デプロイメントリソースから継承/コピーされます。 元の配置リソースを(設定またはエクステンションによって)カスタマイズした場合も、ジョブに反映されます。
生成されたinitコンテナーの制御
生成される init コンテナの名前は、デフォルトでは wait-for-${task name}
です。
init コンテナは実際のアプリケーションと同じポッドの一部であるため、アプリケーションと同じサービスアカウント (およびパーミッション) とボリュームを取得します。
init コンテナの設定オプションを使用することで、コンテナをさらにカスタマイズすることができます ( quarkus.kubernetes.init-containers
または quarkus.openshift.init-containers
を参照ください)。
例:
flyway
ジョブを待つ init コンテナで imagePullPolicy を IfNotPresent
に設定:
quarkus.kubernetes.init-containers.wait-for-flyway.image-pull-policy=IfNotPresent
flyway
ジョブを待つ init コンテナにカスタムコマンド( custom-wait-for
)を設定:
quarkus.kubernetes.init-containers.wait-for-flyway.command=custom-wait-for
初期化タスクのオーケストレーション
デプロイメントリソースは、ジョブが完了するまで開始すべきではありません。Kubernetesユーザーの間で使用されている典型的なパターンは、これを実現するためにinitコンテナを使用することです。この要件を実現するためには、ジョブの完了を wait for
するinitコンテナだけで十分です。
カスタムwait-forコンテナイメージの使用
デフォルトでは groundnuty/k8s-wait-for:no-root-v1.7
である wait-for
イメージを変更するには、次を使用できます。
quarkus.kubernetes.init-task-defaults.wait-for-container.image=my/wait-for-image:1.0
特定の init コンテナ(例: wait-for-flway
)の wait-for
イメージを変更するには、次のようにします:
quarkus.kubernetes.init-containers.wait-for-flyway=my/wait-for-image:1.0
パーミッションの設定
init コンテナが wait for job
を実行できるようにするには、ジョブ・リソースに対して get
操作を実行できる必要があります。
これは自動的に行われ、生成されたマニフェストには必要な Role
と RoleBinding
リソースが含まれます。
何らかの理由でinitコンテナやジョブで追加のパーミッションが必要な場合は、 KubernetesのRBAC設定 で設定できます。
注意 : アプリケーション、init コンテナー、ジョブは同じ ServiceAccount
を使用するため、同じパーミッションを共有します。
初期化タスクを提供するエクステンション
現在、この機能は以下のエクステンションで使われています: - Flyway - Liquibase - Liquibase MongoDB