Upgrade/Backup/Restore
アップグレード~
ページ: 管理 → アップグレード
すでにAoTをインストール済みの場合は、Webインターフェースのアップグレードオプションを使う方法(推奨)か、ターミナルで次のコマンドを実行する方法のいずれかで、最新のAoTリリースにアップグレードできます。アップグレード処理のログは/var/log/aot/aotupgrade.logに作成され、管理 → システムログページからも確認できます。
Docker環境のアップグレード~
ページ: 管理 → アップグレード
Docker環境は、ディスク上のファイルを置き換える形ではアップグレードされません。公開されたイメージを実行しているため、アップグレードとは新しいイメージを取得してコンテナを再作成することを意味します。アップグレードページはこれを検知して、動作を変えます。
更新できるかどうかは、リリース一覧ではなくコンテナレジストリから判断します。リリースタグはプッシュした瞬間にGitHub上に現れますが、イメージは数分後にマルチアーキテクチャビルドが完了して初めてダウンロード可能になります。そのためこのページは、実際に存在するイメージをレジストリに問い合わせます。「更新あり」と表示されれば、その更新はすぐにインストールできる状態です。
インターネットテストは行いません。直接インストールのアップグレード画面は、まず一般設定のインターネットテストのIPアドレス・ポート・タイムアウトを使って、インターネットに届くかを確認します。Dockerのアップグレード画面はこの確認を行わないため、この3つの設定はDockerでは何の影響もありません。
アップデーターサービス(任意)~
ワンクリック更新と自動更新には、小さな追加サービスが必要です。このサービスがなくてもアップグレードページは正確な状態を表示しますが、更新自体はホスト上で自分で適用することになります。
docker compose -f docker/docker-compose.prod.yml pull
docker compose -f docker/docker-compose.prod.yml up -d
アプリケーションは自分自身の更新をインストールできません。コンテナを再作成すると、そのコマンドを実行しているプロセス自体が途中で終了させられてしまうためです。そのため、この作業は別のサービスが担当します。
有効にするには、docker/.envに2つの値を追加します。
AOT_PROJECT_DIR=/opt/AoT # このチェックアウトの絶対パス
AOT_HEALTH_KEY=$(openssl rand -hex 24) # アップデーターが新しいビルドを確認するためのキー
そのうえで、アップデーターのオーバーレイと一緒にスタックを起動します。
このサービスはホストのDockerを操作できます
アップデーターはDockerソケットを保持しており、これはホストのroot権限と同等です。意図的に極めて小さく作られており、公式のAoTイメージしか取得しませんが、有効にするのはそれを受け入れられる場合に限ってください。特権コンテナを動かしたくない場合は、同じ作業をホストのsystemdタイマーで行うこともできます — install/aot-docker-update.serviceを参照してください。
更新中に起こること~
- まずデータベースとアップロードされたファイルのバックアップを取得します。
- 新しいイメージをダウンロードします。
- デーモンを正常に停止します。停止前に出力を終了時の状態へ切り替える時間を確保します。
- 新しいイメージでコンテナを再作成し、スキーマを自動的にマイグレーションします。
- 新しいバージョンが、サービスを提供していることかつマイグレーションが反映されたことを報告して初めて、更新は完了したとみなされます。
- 正常に起動しない場合は、以前のバージョンに自動的に復元されます——マイグレーションがすでに実行されていた場合は、データベースも一緒に復元されます。イメージだけを復元すると、古いコードが新しいスキーマの上で動作する状態になってしまうためです。
アップグレードページには進行状況がリアルタイムに表示され、終了後には直前の試行結果が表示されます。
更新中は制御が一時停止します
コンテナが再起動している間(通常は数分間)、出力は制御されません。その時点で動作していたもの(灌水、補光、シーケンスなど)は停止します。
自動更新~
アップデーターサービスが起動していると、アップグレードページには次の項目が表示されます。
- アップデートを自動でインストール — デフォルトではオフです。
- アップデート時刻 — この時刻に1日1回、確認が行われます。時刻は
管理 → システム管理 → 一般設定のシステムのタイムゾーンで設定したローカルタイムゾーン基準です。
その時刻になると、AoTはレジストリを確認し、新しいバージョンが公開されていれば、ボタンを押した場合とまったく同じ方法でインストールします。新しいものがなければ何もせず、その旨を1行ログに記録します。
重要な処理が動いていない時間帯を選んでください。「稼働中は延期する」という機能はまだありません。設定した時刻になると、出力がオンかどうかにかかわらずコンテナが再作成されます。
データ~
データベース、アップロードされたファイル、地図オーバーレイ画像、施設の3Dモデル、バックアップ、ユーザースクリプト、測定値(InfluxDB)はすべてDockerボリュームに保存されており、イメージを入れ替えても失われません。以前のバージョンに戻すには、docker/.envのAOT_IMAGE_TAGを設定してコンテナを再作成するだけです——アップデーターは最後に正常動作したタグを、同じファイルにAOT_IMAGE_TAG_PREVとして記録します。
バックアップ・復元~
ページ: 管理 → バックアップ復元
システムがアップグレードされたとき、または管理 → バックアップ復元ページのWebインターフェースから指示されたときに、/var/AoT-backupsへバックアップが作成されます。
バックアップを復元する必要がある場合は、管理 → バックアップ復元ページで行うことができます(推奨)。復元したいバックアップを見つけて、その横のバックアップを復元ボタンを押してください。Webインターフェースにアクセスできない場合は、コマンドラインからも復元を開始できます。復元を開始するには、次のコマンドを使用してください。[backup_location]には、復元するバックアップの完全なパスを指定する必要があります(例: 引用符なしで「/var/AoT-backups/AoT-backup-2018-03-11_21-19-15-5.6.4/」)。
Note
Webインターフェースからのバックアップのダウンロードと復元は管理者のみが行えます。バックアップにはユーザーアカウント・ロール・パスワードハッシュを含む設定データベースが入っており、復元するとユーザーアカウントとロールもバックアップ時点に戻るためです。他のロールにはバックアップをダウンロード・バックアップを復元ボタンが表示されません。
Docker環境のバックアップ~
Dockerでは[歯車アイコン] -> Backup Restoreは、ネイティブ用の/var/AoT-backupsではなくaot_backupsボリュームにバックアップを作成します。これはシステム全体ではなく設定単位のバックアップです。
| 含まれるもの | 含まれないもの | |
|---|---|---|
| Docker | 設定データベース(ユーザー・ロール・デバイス・機能・ダッシュボード)、アップロード(ノート・お知らせ・施設・区画の写真)、施設3Dモデル、地図オーバーレイ画像、ユーザースクリプト | InfluxDBの測定値(センサー履歴)、ログ、custom_*拡張モジュール(ホストのフォルダー) |
| ネイティブ | envとcamerasを除くインストールフォルダー全体(データベース・アップロード・オーバーレイ・スクリプト) | InfluxDBの測定値(インストールフォルダー外のシステムサービス) |
アップデーターが更新前に作成するバックアップも同じ一覧を使います。
復元しても測定値は戻りません
バックアップを復元すると設定がその時点に戻ります。センサー履歴は現在の状態のまま残ります。履歴を守るには、下の2つの方法のどちらかで別にバックアップしてください。
測定値~
- エクスポート(データが少〜中程度のとき):
[歯車アイコン] -> Export Importで測定値をInfluxDBのZIPとして書き出します(エクスポート/インポート参照)。手軽ですが、数年分のデータでは遅く大きくなります。 - ボリューム丸ごとコピー(危険な作業・移行・ディスク交換の前に推奨): 以下のようにDockerボリュームをコピーします。測定値を含むすべてが入ります。
ボリュームのコピー~
# 0) 実際のボリューム名を確認します。接頭辞はcomposeプロジェクト名
# (composeファイルのあるフォルダー名、既定値は"docker")です。
docker volume ls --format '{{.Name}}' | grep -E 'aot_|influxdb_'
P=docker # <- 上で確認した接頭辞に変更
mkdir -p ~/aot-volume-backup && cd ~/aot-volume-backup
# 1) 書き込むサービスをすべて停止します(整合したコピーのためInfluxDBも停止が必要です)。
docker compose -f /opt/AoT/docker/docker-compose.prod.yml stop
# 2) ボリュームごとに.tgzへまとめます。
for v in aot_data aot_uploads aot_model_assets aot_geo_overlays aot_user_scripts influxdb_data influxdb_config; do
docker run --rm -v ${P}_$v:/v:ro -v "$PWD":/out alpine tar czf /out/$v.tgz -C /v .
done
# 3) 再起動します。
docker compose -f /opt/AoT/docker/docker-compose.prod.yml up -d
コピーは~/aot-volume-backupにできます。必ず別の機器へ移してください——同じディスクのバックアップはディスク故障を防げません。
コピーからの復元~
cd ~/aot-volume-backup
P=docker
docker compose -f /opt/AoT/docker/docker-compose.prod.yml stop
docker compose -f /opt/AoT/docker/docker-compose.prod.yml create # 存在しないボリュームを空で作成します
for v in aot_data aot_uploads aot_model_assets aot_geo_overlays aot_user_scripts influxdb_data influxdb_config; do
docker run --rm -v ${P}_$v:/v -v "$PWD":/out alpine sh -c "rm -rf /v/* /v/.[!.]* 2>/dev/null; tar xzf /out/$v.tgz -C /v"
done
docker compose -f /opt/AoT/docker/docker-compose.prod.yml up -d
必要になる前に復元をテストしておく~
予備の機器、または別のプロジェクト名(docker compose -p restoretest ...)で行ってください。稼働中のスタックでは行わないでください。
- スタックを一度起動してボリュームを作り、停止します。
- そのプロジェクトの接頭辞で、上のとおり
.tgzを復元します。 - 起動し、普段のアカウントでログインします。
- 確認:ダッシュボードとデバイスがあるか、地図オーバーレイ画像が表示されるか、グラフに過去の測定値が出るか。
docker compose down -vは絶対に実行しないでください
-vはスタックの名前付きボリュームをすべて削除します。データベース、アップロード、バックアップ(aot_backups)、測定値まで、確認なしに一度で消えます。-vなしのdocker compose downとdocker compose stopは安全です。バックアップも同じスタックのボリュームにありdown -vで一緒に消えるため、コピーを別の場所に置いてください。