コンテナオーケストレーション（Compose）

業務サービス、データベース、メッセージキューなど複数のサービスで構成されるアプリケーションは、構成ファイルで定義、依存関係、実行方法をまとめて宣言できます。実行はデバイスエージェントが一元的に担当します。リリースで設定すれば自動デプロイされ、デバイス上で手作業を行う必要はありません。

デバイス側の実行機構

リリースで構成を宣言（services + programs）
        │
        ▼
デバイスエージェントが目標状態を同期 ──▶ イメージ／アプリパッケージを取得 ──▶ サービスを作成・起動 ──▶ 継続監視
        │                                                        │
        │                                                        ▼
        └────────────────────────────── バージョン更新／ロールバック ◀────── 異常時に自動再起動

• 複数サービスの起動順序と依存関係を、宣言された構成に従ってエージェントが処理します。
• サービスの異常終了時は自動再起動し、デバイス再起動後も自動復旧します。
• バージョン更新とロールバックはリリースで管理し、エージェントが自動実行します。

構成の設定例

以下はリリース内の構成例です。全フィールドの説明は docker-compose の互換性と拡張を参照してください。

version: "2.4"

services:
  app:
    image: myapp:1.0.0
    restart: always
    ports:
      - "8080:80"
    depends_on:
      - db

  db:
    image: postgres:16
    volumes:
      - dbdata:/var/lib/postgresql/data

programs:
  collector:
    command: collector --config /data/collector.conf
    restart: on-failure

volumes:
  dbdata:

リリースでの設定

構成はリリース作成時に入力します。編集モードと構成ファイルのアップロードに対応します。コンテナイメージやネイティブアプリケーションのパッケージは、リリース詳細ページでアップロードします。詳しくは次を参照してください。

• JelinaCloud Release の作成
• JelinaCloud Release のデプロイ

データの永続化

• 構成内のボリュームはコンテナのライフサイクルから独立し、コンテナの再作成や更新はデータに影響しません。
• 重要なデータは、デバイスのデータパーティションにもマウントすることを推奨します。

互換性について

• 対応は 2.x 仕様に基づき、一般的な構成ファイルをそのまま使用できます。
• 3.x で追加されたフィールドはサポート対象外です。
• 全フィールドと互換性の詳細は docker-compose の互換性と拡張を参照してください。

関連ドキュメント

• アプリケーション管理 — リリース体系の概要
• ネイティブアプリケーションと ProgramSet — ネイティブアプリケーションのリリース設定
• クラウドからのアプリケーション配信と OTA — デプロイと更新の流れ