アプライアンスのコマンド

ironflock appliance コマンドは、自分で運用する Linux サーバーに IronFlock アプライアンスをインストールし、その後も管理します。アプライアンスのインストール、設定の変更、更新、開始、停止、再起動、ログの読み取り、admin パスワードのリセット、シークレットのバックアップ、復元、ローテーション、そして削除に使います。

アプライアンスとは、現場の 1 台のマシン上で動作する IronFlock システム一式です。アプライアンスとは何か、その HTTPS モード、ネットワーク、運用については IronFlock アプライアンス で説明しています。マシンの要件（CPU、メモリ、ストレージ、時刻同期）は、その インストール のページにあります。

注意：これらのコマンドは、ironflock のリリース 2.1.0 で新しく追加されました。新規の Ubuntu 24.04 仮想マシン（amd64）上で、appliance install から appliance remove --purge までのテスト実行に 1 回合格しています。失敗する更新と、それに伴う以前のリリースへのロールバックは、まだ検証されていません。

アプライアンス

アプライアンスのコマンドは Linux で動作します。appliance install には、systemd を備えた Debian または Ubuntu ベースのシステムが必要です。macOS では、コマンドは何かを調べる前に終了コード 3 で終了します。アプライアンスのマシン上で実行するか、Mac から --host で実行してください。

コマンドは root として、sudo で実行してください。システムを変更するコマンドは、root でない場合は終了コード 3 で終了し、自分で sudo を呼び出すことはありません（root 権限）。

各コマンドは、グローバルフラグ --yes、--json、--download-base、--host、--hosts、--parallel も受け付けます（グローバルフラグ）。質問には端末が必要です。端末がない場合は --yes を指定してください（質問と確認）。

ironflock status は、インストール済みのアプライアンスについて、バージョンとチャネル、UI のアドレス、ライセンスがあるかどうか、サービス、サービスの健全性、待機中の更新を表示します（ironflock status）。

インストール済みのアプライアンスの構成

インストールは ironflock.service のほかに、ウォッチドッグと、UI からの更新が失敗したときに 1 時間ごとに再試行するタイマーをセットアップします。ウォッチドッグは 5 分ごとにルーターとバックエンドをチェックし、正常でなければ ironflock.service を再起動します（5 分に 1 回まで）。

/usr/local/bin/ironflock はそのままにしておいてください。アプライアンスのユニットが、開始のたびにこれを実行します。appliance install は別の場所からの実行を拒否し、そこにインストールする方法を示します。ironflock status を root で実行すると、このバイナリがない場合や、最後にアプライアンスをインストールまたは更新したものより古い場合に警告します。sudo ironflock self-update で最新のリリースに置き換えられます（ironflock self-update）。

アプライアンスは、ホスト自身のデバイスエージェントも実行します。appliance install は、--no-agent を指定しない限りこれをインストールします。このエージェントは agent コマンド で管理します。

一度に 1 つの変更

アプライアンスのインストール、更新、その他の変更は、一度に 1 つだけ実行されます。2 つ目の実行は 1 つ目を待ち、その旨を示します：

Another IronFlock install, update or other change of the appliance is running on this host (process <pid>); waiting up to <time> for it to finish

install、update、configure、rotate、revoke-direct-access、reset-admin-password、restore は最大 1 時間待ちます。start、stop、restart、remove は最大 30 秒待ちます。それでもほかの実行が続いている場合、コマンドは何も変更せず、終了コード 3 で終了します。

ironflock appliance install

IronFlock アプライアンスを /opt/ironflock にインストールして開始します。すべてのサービスが正常になり、IronFlock クラウドがアプライアンスに到達できるまで待ってから、Web UI の admin ログインを 1 回だけ端末に表示します。

ironflock appliance install --license-file <file> [flags]

動作環境： systemd を備えた Debian または Ubuntu ベースの Linux。root： 必要。

インストールは次のものをセットアップします：

• チャネルのリリース、または --version で指定したリリース。アプライアンスのリリース鍵で検証します。
• アプライアンスの設定とシークレット。
• ホスト自身のデバイスエージェントと、ない場合は Docker。
• ホストの設定。
• ライセンスキーによる、レジストリへの Docker のログイン。
• リリースのイメージ。
• ironflock.service。

Docker がない場合、インストールは get.docker.com の Docker のインストールスクリプトを root で実行します。このダウンロードは TLS だけで保護されています。

HTTPS モードと、それぞれが暗号化するものについては、HTTPS と証明書 と セキュリティ で説明しています。プロキシのパスワードは シークレット のルールに従います。パスワードを含むプロキシ URL は、コマンドラインの誤りです。

ライセンスキー

ライセンスキーは、ironflock.com の プロフィール → インスタンス で作成する Instance Key です（インストール）。--license-file または --license で渡します。すでにインストール済みのアプライアンスは、どちらも指定しなくてもキーを保持します。license.env にある、有効なライセンスキーではないキー（ライセンスキーは UUID です）は、アプライアンスのどのコマンドも警告を出して無視します。その場合、実行にはキーか --skip-login が必要です。

環境変数

一部のフラグは、既定値を環境変数から取得します：

sudo は、シェルの変数のほとんどを引き継ぎません。sudo env NAME=value ironflock appliance install ... で渡してください。

インストールの選択の記録

root だけが読める <install-dir>/install.json は、.env にもユニットにも残らない選択を保持します。レジストリとそのユーザー、アプライアンスのホスト（IRONFLOCK_APPLIANCE_HOST）、--no-agent、--bucket-url のダウンロードベース、最後にアプライアンスをインストールまたは更新した ironflock のバージョンです。パスワード、トークン、鍵は含みません。

以降の appliance install、appliance update、appliance configure は、フラグ（またはその変数）で別の指定がない限り、これらの選択を保ちます。指定したフラグが優先され、記録されます。既定値に戻すには、--registry ""、--no-agent=false、または空の IRONFLOCK_APPLIANCE_HOST を指定します。

記録が読み取れない場合や、より新しい形式の記録の場合、install、update、configure は何かを変更する前に、終了コード 3 で停止します。メッセージには対処方法が示されます。記録を別の場所に移してフラグを付けて再度インストールするか、より新しい ironflock を使います。

再実行

インストール済みのアプライアンスで実行すると、コマンドはアプライアンスを指定したリリースとオプションに合わせ、シークレットと設定は保ちます。リリースを意図的に変更するときに使います。ironflock appliance install --version <version> は、そのリリースがすでに動作している場合でも、もう一度プルし、再起動し、チェックします。

途中で止まった実行は、同じコマンドをもう一度実行すると、止まったところから続行します。

ヘルスチェックに合格すると、インストールは更新が保存した以前のリリースのコピー（/opt/ironflock/.update-previous）を削除します。インストールしたリリースが、動作させるべきリリースだからです。

最初の変更以降は、端末や SSH セッションが失われても（SIGHUP）、出力が読まれなくなっても（閉じたパイプ）、インストールは止まりません。Ctrl-C と SIGTERM では止まります。admin パスワードが失われないように、インストールは SSH セッションが失われた後も端末に書き込み続けます。そのため、sudo の use_pty 設定では、開いたままで読まれなくなった端末が、インストールロックを保持したままインストールを止めてしまうことがあります。

例

# アプライアンスをインストールする。ライセンスキーはファイルから読み取る
sudo ironflock appliance install --license-file license.txt
# アプライアンス独自の CA による HTTPS でインストールする。キーは標準入力から読み取る
sudo ironflock appliance install --license-file - --tls < license.txt
# プロキシの背後でインストールする。.corp.example.com 配下のホストはプロキシを経由しない
sudo ironflock appliance install --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
# アプライアンスのアドレスとドメインを質問し、HTTPS でインストールする
sudo ironflock appliance install --license-file license.txt --interactive --tls

拒否する場合と失敗する場合

• ユニットがそのままでは記載できない --bucket-url のダウンロードベース（ログイン情報、%、空白、$、\、引用符、制御文字、UTF-8 でないバイトを含むもの）は、何かが書き込まれる前に終了コード 2 で拒否されます。
• root で実行されていない場合、インストールの選択の記録が読み取れない場合、ほかの実行が 1 時間の待機を超えてインストールロックを保持している場合、コマンドは終了コード 3 で拒否します。実行中の ironflock が /usr/local/bin/ironflock でない場合も拒否し、そこにインストールする方法を示します。
• 手順が失敗すると、コマンドは終了コード 1 で終了します。続行するには、同じコマンドをもう一度実行してください。

ironflock appliance configure

インストール済みのアプライアンスの設定を変更します。ライセンス、TLS モード（自社の証明書も含む）、プロキシ、UI の追加のホスト名、トンネル、二要素認証のポリシーです。

ironflock appliance configure [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。

設定はアプライアンスの .env とファイルに残るため、更新しても保たれます。指定しなかった設定は、アプライアンスの現在の値を保ちます。アプライアンスを再起動するのは何かを変更した実行だけなので、同じコマンドを 2 回実行しても、2 回目は何も変更しません。

• 新しいライセンス（--license、--license-file、標準入力からの --license-file -）は、書き込まれる前にレジストリを開けることが確認されます。そのレジストリのログインは、--registry に --registry-user として行い、なければインストールが選んだもの（記録）、それもなければアプライアンスのミラーが同期元にしているレジストリに対して行います。--registry または --registry-user を付けたログインは、更新のためにそれらを記録に残します。
• --tls-cert と --tls-key は自社の証明書をインストールして TLS を有効にし、デバイスはアプライアンスのドメインに移行します。
• --http-proxy "" または --https-proxy "" を単独で指定すると、プロキシを解除します。
• インストールの --no-agent はそのまま保たれます。
• TLS に必要な Caddyfile は、--bucket-url から、なければインストールがリリースを取得した場所から取得します。

例

# アプライアンスに、ファイルから新しいライセンスキーを設定する
sudo ironflock appliance configure --license-file license.txt
# 組織の証明書で UI を提供する
sudo ironflock appliance configure --tls-cert wildcard.crt --tls-key wildcard.key
# プロキシを設定し、再び解除する
sudo ironflock appliance configure --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
sudo ironflock appliance configure --https-proxy ""
# すべてのユーザーに二要素認証を必須にする
sudo ironflock appliance configure --2fa required

--2fa required を設定する前に、すべてのアカウントに二要素認証が設定されていることを確認してください。設定していないユーザーはサインインできなくなります（アカウントとアクセス）。

拒否する場合

root で実行されていない場合、インストールの選択の記録が読み取れない場合、ほかの実行が 1 時間の待機を超えてインストールロックを保持している場合、そして更新が途中で中断されている間（更新が途中で中断された場合）、コマンドは終了コード 3 で拒否し、何も変更しません。

ironflock appliance update

このマシンのアプライアンスを、そのチャネルの最新のリリース、または --version で指定したリリースに更新します。リリースはアプライアンスのリリース鍵で検証され、そのイメージがプルされ、アプライアンスはそのリリースで再起動します。コマンドは、すべてのサービスが正常になり、IronFlock クラウドがアプライアンスに到達できるまで待ちます。アプライアンスはシークレットと設定を保ちます。新しいリリースが正常になると、以前のリリースのイメージは削除されます。

ironflock appliance update [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： --discard-previous の場合を除き、しません。

リリースは、--bucket-url、なければ IRONFLOCK_BUCKET_URL、なければインストールがリリースを取得した場所（その選択の記録 /opt/ironflock/install.json、またはユニットが示すもの）、それもなければ IronFlock から取得します。レジストリ、そのユーザー、アプライアンスのホスト、--no-agent は、インストールが選んだままです。

新しいチャネルは、更新が成功すればそのまま残ります。ロールバックすると、以前のチャネルに戻ります。UI の Apply update も同じ更新を実行します。

チェックに合格すると、インストールや更新は、アプライアンス自身のデバイスを、以前はすべてのアプライアンスが共有していたシークレットから APPLIANCE_DEVICE_SECRET の値に移行させます。その後、そのエージェントは実行の 35 秒後に再起動します。移行できない場合は理由を示す警告になり、次のインストールまたは更新で再試行します。

すでに最新の場合

チャネルの最新のリリース（または --version で指定したリリース）を、同じチャネルとダウンロードベースですでに実行しているアプライアンスは、そのままにされます。コマンドはその旨を示し、終了コード 0 で終了します。--json では result が nothing-to-do です。そのリリースを意図的にもう一度プルし、再起動し、チェックするには、ironflock appliance install --version <version> を実行してください。

これが当てはまるのは、最後の更新がきれいな状態で終わったアプライアンスだけです。以前のリリースのコピーが保存されている場合（途中で中断された更新）や、ステータスファイルが failed または running を示している場合、更新はすべてをもう一度実行します。

ロールバック

更新は、何かを変更する前に、動作中のリリースのファイルを /opt/ironflock/.update-previous に保存します。アプライアンスを変更した後で更新が失敗すると、それらのファイルが元に戻され、以前のリリースが再び開始します。イメージはマシン上にあるため、ネットワークは不要です。これは最大 3 回試みられます。その後、コマンドはあきらめ、以前のリリースのファイルをそのまま残すため、アプライアンスが次に開始するのはそのリリースです。

何かを変更する前に失敗した更新は、それ以上何も変更せず、その旨を示します。たとえば、リリースが存在しない、署名されていない、ダウンロードベースが応答しない場合です。

リリースによっては、実行中のものより新しい ironflock が必要なことがあります。その場合は何も変更されず、コマンドは先にどの ironflock をインストールすべきかを示します。appliance update が ironflock を自分で更新することはありません。ironflock self-update で最新のものをインストールします。

ステータスファイルと再試行

更新は、UI の更新と同じく進捗を triggers/apply-update.status に書き込むため、UI にそれが表示されます。出力は triggers/apply-update.log にも書き込まれます。UI からの失敗した更新を再試行するタイマーは、このコマンドによる更新が失敗した場合や、何かを変更する前に停止された場合には再試行しません。

中断

• Ctrl-C または SIGTERM は、更新が何かを変更する前であれば、更新を停止します。それ以降は、1 回目で以前のリリースに戻し（終了コード 130）、2 回目ですぐに停止します。
• 端末や SSH セッションが失われても（SIGHUP）、出力が読まれなくなっても、更新は止まりません。更新もロールバックも最後まで実行されます。どう終わったかは、ステータスファイルと ironflock status で確認できます。
• 端末なしの --host 経由では、最初の 2 回の Ctrl-C がマシンに届きます。1 回目の後、コマンドはマシン上の更新が終わるのを最大 30 分待ちます。2 回目の後は 15 秒待ち、3 回目でこちら側はすぐに終了します。こちら側でセッションが失われた場合や SIGTERM は Ctrl-C とはみなされず、コマンドはこちら側ですぐに終了します。こちら側が先に終了した場合でも、更新はマシン上で続き、どう終わったかは ironflock --host <machine> status で確認できます。

更新が途中で中断された場合

更新が途中で中断されたとは、更新がアプライアンスの変更を始めた後で終わらなかったことを指します。停止された、マシンが停止した、またはロールバックで以前のリリースを起動できなかった場合です。このとき、インストールディレクトリには 2 つのリリースのファイルが混在していることがあります。保存されたコピーは動作することがわかっているリリースを示し、ironflock status もそれを示します。

• 次の更新は、まずそのコピーを元に戻してから更新します。コピーが読み取れない場合や元に戻せない場合は、終了コード 3 で更新を停止し、エラーは ironflock appliance install --version <version> を示します。
• 1 時間ごとの再試行タイマーは、新しいリリースがない場合でも、自分でコピーを元に戻し、そのリリースを再起動してチェックします。
• configure、rotate、revoke-direct-access、restore、reset-admin-password は、何かを変更する前に終了コード 3 で拒否します。これらは 3 つの解決策を示します：ironflock appliance update、ironflock appliance install --version <version>、そしてネットワークがない場合は ironflock appliance update --discard-previous です。
• backup は読み取るだけで、警告を出します。start、stop、restart はコピーに触れません。remove は、アプライアンスのほかのファイルとともにコピーも削除します。
• appliance install はいつもどおり実行され、ヘルスチェックに合格するとコピーを削除します。

途中で中断された更新のファイルを手動で扱うには、先に .env に IRONFLOCK_UPDATE_RETRY=off を設定してください。そうしないと、再試行タイマーが約 1 時間以内に以前のリリースを元に戻します。この設定は、ロールバックも含めて再試行タイマー全体を無効にします。

--discard-previous

ironflock appliance update --discard-previous [--yes]

何も更新しません。更新が保存した以前のリリースのコピー（/opt/ironflock/.update-previous）を、どのような状態でも、読み取れない場合でも削除し、それ以外は何も変更しません。ネットワークは不要です。

更新が途中で中断され、以前のリリースが再び開始しない場合に、ネットワークなしで抜け出す方法です。インストールディレクトリのファイルは現在の状態のまま残り、そのリリースには戻せなくなり、拒否していたコマンドが再び実行できるようになります。

削除するものを示してから質問し、「No」があらかじめ選択されています。--yes は「はい」と答えます。端末がない場合や --json では --yes が必要で、ない場合は終了コード 4 で終了します。コピーがない場合はその旨を示し、終了コード 0 で終了します。--version、--channel、--bucket-url とは組み合わせられません（終了コード 2）。--json では、結果に action（discarded、cleaned、none）、path、version、state、removed が含まれます。

例

# チャネルの最新のリリースに更新する
sudo ironflock appliance update
# リリース 1.6.41 をインストールする。それに戻す場合にも使う
sudo ironflock appliance update --version 1.6.41
# test チャネルに切り替え、結果を JSON で読み取る
sudo ironflock appliance update --channel test --json
# ネットワークなしで、以前のリリースのコピーを削除する
sudo ironflock appliance update --discard-previous

結果

{"from":"1.6.40","target":"1.6.41","version":"1.6.41","result":"updated"}

失敗した更新は、アプライアンスが以前のリリースに戻ったかどうかを示すエラーになります。--json では、中断された場合も含め、その kind は次のいずれかです：

ironflock appliance start

動作していないアプライアンスを開始します。ironflock.service がそのコンテナを開始し（docker compose up）、ウォッチドッグとそのほかのパスとタイマーが再び開始します。サービスが立ち上がるまで 1、2 分かかります。サービスの健全性は ironflock status で確認できます。

ironflock appliance start [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： なし。このコマンドに固有のフラグはありません。

アプライアンスが動作していなかったために、復元 がデータベースロールを古いパスワードのまま残した場合、それらのロールは、データベースが動作し始めると（最大 1 分）、復元した .env のパスワードになります。応答しないロールは警告を出して次の開始に持ち越され、開始は続行します。

sudo ironflock appliance start
sudo ironflock appliance start --json

ほかの実行がアプライアンスを変更している間、コマンドは最大 30 秒待ち、その旨を示します。その実行が続いている場合は、何も変更せずに終了コード 3 で終了します。

ironflock appliance stop

アプライアンスを停止します。ウォッチドッグとそのほかのパスとタイマー、およびそれらが開始したものを停止し、次に ironflock.service を停止します。これによりコンテナが停止して削除されます（docker compose down）。データは残ります。

ironflock appliance stop [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： あり。停止すると何が止まるかを示した後で質問します。--yes で答えられます。

UI がオフラインになり、アプライアンスに接続するすべてのデバイスも、このマシンのエージェントも含めてオフラインになります。アプライアンスは ironflock appliance start で、または次の起動で再び開始します。このコマンドに固有のフラグはありません。

# アプライアンスを停止する。コマンドは何が止まるかを示して質問する
sudo ironflock appliance stop
# 質問なしで停止する
sudo ironflock appliance stop --yes

「いいえ」と答えた場合、または端末がなく --yes もない場合は、終了コード 4 で終了します。ほかの実行がアプライアンスを変更している間は、start と同じように待ちます。

ironflock appliance restart

アプライアンスを再起動します。ironflock.service は、ウォッチドッグと同じように、コンテナを停止して再び開始します（docker compose down、次に up）。appliance stop が停止したパスとタイマーも再び開始します。

ironflock appliance restart [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： なし。このコマンドに固有のフラグはありません。

UI と、アプライアンスに接続するデバイスは 1、2 分オフラインになります。データは残ります。サービスが立ち上がったら、ironflock status でその健全性を確認できます。復元が古いパスワードのまま残したデータベースロールは、start と同じく .env のパスワードになります。

sudo ironflock appliance restart
sudo ironflock appliance restart --json

ほかの実行がアプライアンスを変更している間は、start と同じように待ちます。

ironflock appliance logs

docker compose logs と同じ形で、アプライアンスのサービスが書き込んだ内容を表示します。既定では、各サービスの最後の 100 行です。何も変更しません。

ironflock appliance logs [<service>...] [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： なし。

router、backend、kratos、caddy のようにサービス名を指定すると、そのサービスのログだけを表示します。

--json を付けると、各行がその行をメッセージとする JSON オブジェクトになります。

# 各サービスの最後の 100 行
sudo ironflock appliance logs
# 直近 1 時間にバックエンドが書き込んだすべて
sudo ironflock appliance logs backend --since 1h
# ルーターと Kratos の最後の 20 行と、その後 Ctrl-C までのすべての新しい行
sudo ironflock appliance logs router kratos --follow --lines 20

ironflock appliance reset-admin-password

パスワードを紛失したオペレーターのために、UI ユーザー admin に新しいパスワードを設定します。パスワードはまずデータベースに設定され、これにより admin のアクティブなセッションがすべて終了します。次に .env に APPLIANCE_ADMIN_PASSWORD として設定されます。アプライアンスが動作している必要があります。

ironflock appliance reset-admin-password [flags]

動作環境： 動作中のアプライアンスがある Linux。root： 必要。

新しいパスワードは 1 回だけ、端末にだけ表示されます。端末がない場合や --json を付けた場合、コマンドは代わりにその保存場所を示します。更新が途中で中断されている間は、終了コード 3 で拒否します（更新が途中で中断された場合）。

sudo ironflock appliance reset-admin-password

ironflock appliance backup

アプライアンスのうち、作り直せないものすべてを tar.gz アーカイブに書き出します。すべてのシークレットを含む .env、license.env、TLS 証明書のローカル CA、レジストリのトークン鍵ペア、シークレットの台帳、rotation.log です。

ironflock appliance backup [-o <file>] [flags]

動作環境： Linux。root： 必要。

-o がない場合、アーカイブは標準出力に出力されます。標準出力は端末であってはなりません。リダイレクト先のファイルは、その所有者だけが読めるようにされます。

警告：アーカイブには、アプライアンスのすべてのシークレットが含まれます。失われた FLEETDB_SECRET_KEYS や FILE_CRED_KEY は、ほかの方法では復元できません。アーカイブを暗号化し、ボリュームのバックアップと一緒に保管してください。

アーカイブに含まれないもの：TLS 証明書とその鍵（生成された証明書は CA から再署名されます）、Kratos の設定、リリースのファイル、Docker ボリューム。certs/ca と registry-token-certs からは、インストールがそこに作成するファイル（rootCA.crt、rootCA.key、rootCA.srl、token_private.key、token_public.crt、token_public.der。.prev または .new 付きのものも）を取り込みます。そこにあるほかのファイルは、restore がほかのファイルを受け付けないため、その名前を示す警告を出して除外されます。

# root だけが読めるファイルにアーカイブを書き出す
sudo ironflock appliance backup -o /root/appliance-secrets.tar.gz
# 標準出力に書き出し、ファイルに保存する
sudo ironflock appliance backup > appliance-secrets.tar.gz

ironflock appliance restore

appliance backup が書き出したバックアップを、インストールディレクトリに戻します。

ironflock appliance restore <file> [flags]

動作環境： Linux。root： 必要。

コマンドはバックアップに含まれるファイルだけを取り込み、それぞれにインストールと同じ所有者とモードを設定します。certs/ca と registry-token-certs では、インストールがそこに作成するファイルだけを取り込みます。それ以外のものを含むアーカイブは、何かが変更される前に拒否され、エラーはそれが何かを示します。

インストール済みのアプライアンスのシークレットは、--force を付けた場合にだけ置き換えられます。その .env は .env.prev として残ります。--force がない場合、インストール済みのアプライアンスへの復元は、何かを変更する前に終了コード 3 で拒否され、メッセージは --force を付けた復元と、その後の appliance restart を示します。

バックアップ内のライセンスキーが有効なライセンスキーでない場合は、警告を出してそのまま復元されます。アプライアンスのどのコマンドもそのキーを無視します。

データベースのパスワード

• アプライアンスのデータベースが動作している間は、そのロールはすぐに復元したパスワードになります。その後、すべてのサービスが復元したファイルを読み込むように、アプライアンスを再起動してください（appliance restart）。
• アプライアンスが動作していない間は、データベースロールは以前のパスワードのままです。復元はそれらに印を付けます（<install-dir>/.db-roles-pending。--json では roles_pending）。次の開始で、復元した .env のパスワードが設定されます。appliance start または restart、起動時の開始、インストール、更新のいずれでもかまいません。

# インストール済みのアプライアンスに復元し、再起動する
sudo ironflock appliance restore appliance-secrets.tar.gz --force
sudo ironflock appliance restart

更新が途中で中断されている間は、終了コード 3 で拒否します（更新が途中で中断された場合）。

ironflock appliance rotate

アプライアンスのシークレットを 1 つ新しい値にします。新しい値は、古い値が保持されている場所（データベースロール、エージェントのデバイスファイル、レジストリのトークン鍵ペア）と .env に設定されます。その後、そのシークレットを読み取るサービスだけが再作成され、コマンドはそれらが正常であることを確認します。

ironflock appliance rotate <name> [flags]

動作環境： 動作中のアプライアンスがある Linux。root： 必要。質問： ほかの場所にも保持されているシークレットの場合。--yes で答えられます。

変更前の .env は .env.prev として残り、root だけが読めます。rotation.log には各ローテーションが記録され、値は記録されません。

• ほかの場所にも保持されているシークレット（データ、デバイス、トークン）は、ローテーションの前に質問します。--yes で答えられます。
• FILE_CRED_KEY では、顧客の直接アクセスキーをどうするかの選択が必要です。--keep-direct-access：引き続き使えます。定期的なローテーション向けで、後で revoke-direct-access で終了させます。--revoke-direct-access：無効になって削除されます。漏えいの疑いがある場合に使います。
• APPLIANCE_ADMIN_PASSWORD は reset-admin-password と同じです。

ローテーションできるシークレット：

POSTGRES_PASSWORD, PGPASSWORD_KRATOS, PGPASSWORD_ACCT_MANAGER,
PGPASSWORD_ACCT_PUSHER, PGPASSWORD_EXT_ACCT_USER, PGPASSWORD_AUDIT_SANDBOX,
DATASERVICE_PASSWORD, WAMP_SYSTEM_SECRET, WAMP_SECRET_SVC_VDM,
WAMP_SECRET_SVC_IDE, WAMP_SECRET_SVC_IDE_PROXY, WAMP_SECRET_SVC_GIT,
WAMP_SECRET_SVC_REGISTRY, WAMP_SECRET_SVC_REGISTRY_PROXY,
WAMP_SECRET_SVC_ACCT, WAMP_SECRET_SVC_ACCT_PUSH, WAMP_SECRET_SVC_PAYMENT,
WAMP_SECRET_SVC_FLEETDB, WAMP_SECRET_SVC_FLEETFILES, WAMP_SECRET_SVC_AI,
WAMP_SECRET_SVC_TUNNEL, WAMP_SECRET_SVC_RENDERER, WAMP_SECRET_SVC_WEBSERVER,
WAMP_SECRET_SVC_REAPI, WAMP_SECRET_SVC_AUTH, RENDER_TICKET_KEY,
FILES_FORWARD_SECRET, KRATOS_WEBHOOK_SECRET, KRATOS_SECRETS_PAGINATION,
REGISTRY_HTTP_SECRET, TUNNEL_DASHBOARD_PASSWORD, EDGE_SESSION_SECRET,
OBJECTSTORE_ADMIN_ACCESS_KEY, OBJECTSTORE_ADMIN_SECRET_KEY, FILE_CRED_KEY,
FLEETDB_SECRET_KEYS, KRATOS_SECRETS_COOKIE, KRATOS_SECRETS_CIPHER,
APPLIANCE_DEVICE_SECRET, APPLIANCE_ADMIN_PASSWORD, REGISTRY_TOKEN_KEY

ローテーションが各種類のシークレットに与える影響と、IronFlock チームと一緒にしかローテーションすべきでないシークレットについては、内部シークレットのローテーション で説明しています。

# 1 つのサービスのシークレットをローテーションする
sudo ironflock appliance rotate WAMP_SECRET_SVC_AI
# ファイルキーを定期的にローテーションする。直接アクセスキーは引き続き使える
sudo ironflock appliance rotate FILE_CRED_KEY --keep-direct-access --yes

更新が途中で中断されている間は、終了コード 3 で拒否します（更新が途中で中断された場合）。

ironflock appliance revoke-direct-access

--keep-direct-access を付けて行った FILE_CRED_KEY のローテーションを終了させます。現在の FILE_CRED_KEY で作成されていない顧客の直接アクセスキーは、すべて無効になって削除されます。キー自体は残ります。fleetfiles サービスが再作成され、削除したものを報告します。

ironflock appliance revoke-direct-access [flags]

動作環境： インストール済みのアプライアンスがある Linux。root： 必要。質問： あり。それらのキーの所有者は新しいキーを作成する必要があるためです。--yes で答えられます。

sudo ironflock appliance revoke-direct-access

更新が途中で中断されている間は、終了コード 3 で拒否します（更新が途中で中断された場合）。

ironflock appliance remove

このマシンから IronFlock アプライアンスを削除し、インストールがホストに記録した変更を元に戻します。--purge を指定しない限り、データは残ります。

ironflock appliance remove [flags]

動作環境： Linux。root： 必要。質問： あり。削除されるものと残るものを一覧表示した後で質問します。「No」があらかじめ選択されているため、Enter だけでは何も削除されません。

削除するもの：

• アプライアンスの systemd ユニット、コンテナ、Docker のネットワーク。
• IronFlock レジストリへの Docker のログイン。
• インストールがホストに記録したすべての変更（/etc/ironflock/appliance.json）：書き込んだプロキシ設定、Docker の daemon.json の設定、ジャーナルの設定、マスクしたスリープターゲット。
• 更新がロールバックのために保存した以前のリリースのコピー（インストールディレクトリ内の .update-previous）。

アプライアンスのコンテナの匿名ボリュームも、--purge の有無にかかわらず削除されます。名前付きボリュームと、コンテナがまだ使っているボリュームは削除されません。

残るもの

--purge を指定しない場合、後でインストールしたときに引き継げるよう、アプライアンスのデータは残ります：

• インストールディレクトリ（/opt/ironflock）。シークレットを含む .env、license.env、インストールの選択の記録（install.json）、復元で設定できなかったデータベースのパスワードの印（.db-roles-pending）を含みます。
• Docker のボリューム。

--purge はこれらとイメージも削除します。アプライアンスが保持していたものは完全になくなります。

--purge を指定しても、次のものは残ります：

• Docker 自体と、ホストのデバイスエージェント。 エージェントは ironflock agent remove で削除します。
• アプライアンスが書き込んだ後に変更されたファイル。 たとえば ironflock agent configure が設定したプロキシ設定と、それを指定するドロップインです。これにより、エージェントはプロキシを保ちます。
• エージェントの記録（/opt/ironflock/device-init/installed.json）がエージェントのものとしているもの、およびエージェントがマスクしたスリープターゲット。これらは ironflock agent remove が削除します。

呼び出しが失敗した場合

元に戻す処理の呼び出しが失敗し続ける場合（たとえば、手動で削除された Docker の再起動）、記録は残ります。コマンドはどの呼び出しが失敗したかを示し、エラーで終了します。その呼び出しが成功するようになってから再度実行するか、--force を付けて実行してください。--force は記録をそのまま破棄し、無効にできないユニットや応答しない Docker を越えて続行します。

アプライアンスのインストール、更新、その他の変更が実行されている間、コマンドは最大 30 秒待ち、その旨を示します。その実行が続いている場合は、何も変更せずに終了コード 3 で終了します。

例

# アプライアンスを削除し、データは残す。コマンドは削除されるものを一覧表示して質問する
sudo ironflock appliance remove
# 質問なしで、すべてのデータとともにアプライアンスを削除する
sudo ironflock appliance remove --purge --yes

「いいえ」と答えた場合、または端末がなく --yes もない場合は、終了コード 4 で終了します。

アプライアンスを完全に削除する前に、まだオンラインのうちにライセンスを移行または解放してください（廃止）。