Kestraは、フローをYAMLで定義してスケジュール実行できる、イベント駆動型のオーケストレーション基盤です。Java・Micronautで構築されたサーバーとCLI、Vueベースのuiフォルダ、Kubernetes向けHelmチャートまで一式が同じリポジトリに含まれています。ミッションクリティカルな自動化やデータパイプラインの実行基盤として、自前でホストする前提の設計です。
エントリーポイントはcli/src/main/java/io/kestra/cli/Kestra.javaで、Picocliのサブコマンド構成でplugin・server・flow・sys・config・namespace・migrationなどを提供します。server配下にはstandalone・executor・worker・scheduler・webserver・indexer・controllerといった役割別コマンドがあり、AbstractCommandがプラグインレジストリの初期化や起動フックを共通処理しています。flowはYAMLで記述し、スケジューラーがトリガーを検知、エグゼキューターがタスク割当を決め、ワーカーが実際の処理を実行するという分離構造です。データ永続化はrepository・queue・storageという抽象層で、README記載のとおりローカルモードはH2、standaloneモードはPostgresをFlyway migrationで管理します。プラグインはjarとしてPluginRegistry・PluginManagerが読み込み、KESTRA_PLUGINS_PATHで拡張できます。
- STEP 01
devcontainer.jsonとDockerfileに従いVSCodeのRemote Developmentでコンテナを開くと、Java25・Node24・Python・uvが自動セットアップされます。
- STEP 02
初回はGradleビルドとJavaファイルのコンパイル待ちが発生し、README自身も完了まで数分かかると案内しています。
- STEP 03
uiフォルダでnpm installを実行してフロントエンド依存を用意し、cli/src/main/resourcesにapplication-override.ymlを新規作成します。
- STEP 04
ローカルモードならH2設定だけで済み、./gradlew runLocalでバックエンドが起動、CORS設定でlocalhost:5173からの接続を許可します。
- STEP 05
standaloneモードを選ぶ場合はPostgresを事前に用意し、repository・queue・storageの各typeとFlyway migrationのlocationsを自分で設定する必要があります。
- STEP 06
npm run devをuiフォルダで実行するとフロントエンドがホットリロード付きでlocalhost:5173に立ち上がり、バックエンドAPIと接続されます。
手元にはKestraのAPIサーバーとWeb UIが立ち上がり、YAMLで書いたフローをCLIやUI経由でスケジュール実行・監視できる状態が得られます。standaloneモードならPostgresを永続層としたローカル検証環境、Helmチャートを使えばKubernetesクラスタへのデプロイ構成も手に入ります。
Java25とGradle、Node24、Docker、場合によってはPostgresと複数のランタイムを同時に用意する必要があり、環境構築の負荷は軽くありません。
standaloneモードの設定例ではhost.docker.internalの指定が必須で、localhostを使うとdevcontainer内から接続できないと明記されています。
README前半はdevcontainer向けの開発者向け手順であり、本番運用向けの構成はcharts/kestraのHelmチャート側を別途読み解く必要があります。
EE向けのコンパイルチェックワークフローが存在するため、一部機能はオープンソース版だけでは確認できない可能性があります。
自前インフラでワークフローオーケストレーションを構築したいデータエンジニアリングチームやDevOps担当者に向いています。CLIのサーバー分離構造やHelmチャートのテストコードまで揃っており、コードとREADMEの記述が一致しているため、実際にビルドしなくても構成の妥当性はある程度判断できます。ただし本番導入の可否はPostgresやKubernetes環境での検証が別途必要です。