コンテナアプリケーション

JelinaOS は Docker コンテナランタイムを内蔵していますが、デプロイは統一された原則に従います。デバイス上でコンテナを手動実行するのではなく、Release を通じて管理します。本番環境のコンテナはすべてリリースフローを使用し、定義、デプロイ、稼働監視、更新、ロールバックを一貫して制御することを推奨します。

推奨するデプロイフロー

イメージをビルド・プッシュ → リリースでコンテナアプリを定義 → デバイスへ配置 → エージェントが取得・実行

手順 1：イメージの準備

アプリケーションをコンテナイメージにビルドし、企業のプライベートレジストリまたは公開レジストリにプッシュします。

docker build -t registry.example.com/myapp:1.0.0 .
docker push registry.example.com/myapp:1.0.0

手順 2：リリースでの宣言

JelinaCloud でリリースを作成し、コンテナアプリケーションを追加します。

イメージの場所とバージョンタグを指定します。意図しない更新を避けるため、明確なバージョンを推奨します。
環境変数、ポートマッピング、ボリュームを設定します。
再起動ポリシー（always を推奨）とリソース制限を設定します。

手順 3：デプロイ

対象フリートやデバイスへリリースを配信すると、エージェントが次を自動実行します。

イメージの取得とコンテナの作成。
設定に従った環境変数の注入、ポートのマッピング、ボリュームのマウント。
コンテナの起動と継続監視。異常時は自動再起動し、デバイス再起動後も自動復旧します。

データの永続化

コンテナの再作成時にファイルシステム内のデータは失われます。永続化が必要なデータはデータパーティションにマウントしてください。

リリース内でアプリケーション用のボリュームを宣言するか、デバイスのデータパーティションのディレクトリをマウントします。
データはコンテナのライフサイクルから独立し、更新や再作成の影響を受けません。

確認と診断

デバイス上の Docker コマンドは確認・診断用であり、デプロイ管理には使用しません。

docker ps                     # コンテナの稼働状態を確認
docker logs <コンテナ名>           # コンテナログを確認
docker events                 # コンテナイベントを追跡（診断用）

本番運用の要点

バージョン固定：リリースでは明確なイメージバージョンタグを使用します。
ヘルスチェック：サービスにヘルスチェックを設定し、再起動ポリシーと組み合わせて自動復旧を実現します。
リソース制限：メモリーと CPU の上限を設け、デバイス全体への影響を防ぎます。
プライベートレジストリ：企業環境ではプライベートレジストリを使い、エージェントがイメージ配信を一元実行します。
更新とロールバック：新リリースの公開で更新し、元のリリースの再指定でロールバックします。いずれもクラウドで構成します。

よくある質問

デバイス上で docker run を実行して直接デプロイできますか。 技術的には可能ですが、推奨しません。直接実行したアプリケーションはリリース体系の管理外となり、統一された稼働監視、更新、ロールバックを利用できません。本番ではリリースからデプロイしてください。

コンテナが異常終了した場合はどうなりますか。 リリースに restart: always を設定したアプリケーションは、異常終了後にエージェントが自動再起動します。