IronFlock Appliance

IronFlock Appliance は、IronFlock システム一式をすぐに使える状態で出荷する事前設定済みのセルフコンテインドボックスです。管理対象の機械のそばに現場設置するだけで利用でき、DMZ、VPC、Kubernetes クラスターは不要です。

これはまさに IronFlock in a box だとお考えください。

対象ユーザー

Appliance は、主に 2 つの対象ユーザーに適しています。

機械メーカーおよび OEM — 自社の機械とともにデジタルサービスを提供したいお客様。エンドカスタマーに DMZ の開放やクラウドインフラのプロビジョニングを求める代わりに、メーカーは自社のデジタルサービスを含む IronFlock Appliance を機械納入の一部として出荷します。お客様はローカルネットワークに接続するだけで利用を開始できます。
少人数の IT チームを持つ小規模工場 — Kubernetes スタック全体を運用することなく、ローカルでターンキーの IoT プラットフォームを利用したいお客様。Appliance は事前設定済みの状態で届き、数分でインストールでき、すべてのデータをオンサイトに保持します。フルクラウドデプロイメントと同じダッシュボード、アプリ管理、デバイス制御を、インフラのオーバーヘッドなしで小規模な現場に提供します。

プライベートクラウドデプロイメントとの違い

Appliance とプライベートクラウドデプロイメントは、いずれも IronFlock をローカルで実行します。主な違いは規模と複雑さです。

プライベートクラウドは本格的な IT インストールです。お客様の DMZ または VPC 内で稼働し、お客様の IT チームが運用し、組織全体で多数のアカウントやプロジェクトに対応できます。
Appliance はコンパクトなターンキーボックスです。事前設定済みの状態で届き、機械のそばのローカルネットワーク上に設置され、お客様側の IT 関与は一切不要です。限定された台数の機械向けに設計されています。

はじめに

ご自身のファクトリーローカル IronFlock インスタンスのセットアップは、わずか数分で完了します。素の産業用 PC から完全に動作するプラットフォームまで — 3 ステップ、1 コマンド、手動設定なしで実現します。

要件

インストール中にインターネットアクセスが利用可能な、Linux OS を搭載した産業用 PC（または仮想マシン）。
ARM64 または AMD64 アーキテクチャ。
最小要件は CPU 2 コア、2 GB RAM、ストレージ 24 GB。機械から収集する解析用データ履歴を保存するためには、はるかに大容量のストレージ（例：500 GB 超）を推奨します。

時刻同期（NTP）

インストールする前に、アプライアンスのホストが実際に到達できる時刻サーバーを設定してください。システムクロックは見た目の問題ではありません。TLS 証明書の検証、ライセンスの定期的な再チェック、リモートアクセスのトークン、そして機械が生成するすべてのデータポイントのタイムスタンプが、これに依存します。数分ずれたホストは、証明書エラー、ログイン失敗、そして現場で実際に起きたこととかみ合わない履歴を生み出します。

企業ネットワークでは、OS に同梱されている公開の時刻サーバーは通常到達できません。UDP ポート 123 の外向き NTP がファイアウォールでブロックされているためです。目立ったエラーは出ず、ホストは単に一度も同期しないままずれていきます。社内の時刻サーバーを情報システム部門に確認してホストに設定するか、外向きの UDP 123 を許可してもらってください。

systemd-timesyncd の場合（Debian と Ubuntu の既定）:


sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo tee /etc/systemd/timesyncd.conf.d/corporate.conf > /dev/null <<'EOF'
[Time]
NTP=ntp.your-company.com
EOF
sudo systemctl restart systemd-timesyncd
timedatectl status

chrony の場合:


echo "server ntp.your-company.com iburst" | sudo tee -a /etc/chrony/chrony.conf
sudo systemctl restart chrony
chronyc sources

インストーラーを実行する前に、timedatectl status が System clock synchronized: yes と表示する必要があります。

仮想マシンは物理ハードウェアよりも速くずれます。アプライアンスを仮想マシンで動かす場合は、ハイパーバイザーのゲスト時刻同期も有効にしたうえで、ゲスト内でも NTP を設定してください。

手順

ironflock.com でアカウントを作成します。
Instance Key を生成 — IronFlock UI で Profile → Instances を開き、ユースケースに合ったプランを選んで新しい Instance Key を作成します。生成されたキーをコピーします。
アプライアンスホスト上でインストーラを実行します。産業用 PC のターミナルを開き、次のコマンドを実行してください。IronFlock ソフトウェアのダウンロードと設定、スタックの起動まで、すべて無人で実行されます。
```
# 企業プロキシの背後で運用していますか？ 実行する前に、以下の注記を参照してください。
curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
  | sudo bash -s -- <your-instance-key>
```
<your-instance-key> をステップ 2 で取得したキーに置き換えてください。

企業プロキシの背後で運用していますか？ アプライアンスが企業の HTTP プロキシ経由でしかインターネットに到達できない場合は、Docker デーモンがイメージをプルできるよう、インストールコマンドでプロキシを指定する必要があります — 指定しないと、インストールはログインのステップで停止します。企業プロキシの背後でを参照してください。

以上で完了です。インストーラが終了すると、アプライアンスは IronFlock プラットフォーム一式を起動し、再起動時にも自動的に立ち上がります。

ironflock.com からインスタンスにアクセスする

アプライアンスは完全にローカルなプラットフォームですが、利用するために工場ネットワーク内にいる必要はありません。アプライアンスがインターネットに接続されており、アプライアンスのアカウントが ironflock.com のアカウントと接続されていれば（アカウントの連携を参照）、IronFlock クラウド UI からインスタンスに直接切り替えることができます — VPN もポートフォワーディングも、追加のツールも不要です。

これにより、次のことが可能になります。

統一された UI — クラウドプロジェクトとアプライアンスインスタンスを、1 つのブラウザタブで並べて管理できます。
どこからでも作業可能 — オペレーター、開発者、サポートスタッフはインターネット経由でアプライアンスに到達できる一方、すべての本番データとワークロードはアプライアンス上にローカルで保持されます。
マルチサイトの管理が容易 — 複数の工場で複数のアプライアンスを運用している場合、それぞれが ironflock.com アカウントに表示され、ワンクリックでアクセスできます。

アプライアンスがインターネット接続を失っても、ローカルでは引き続き動作し、工場ネットワーク内からは http://<appliance-host> で引き続きアクセスできます — リモートアクセス経路だけが、接続が復旧するまで一時的に停止されます。

ファイアウォールの設定

アプライアンスを制限されたローカルネットワーク内で運用する場合は、クラウドに到達できるよう、以下の IronFlock エンドポイントへのアウトバウンドアクセスを許可してください。すべての接続はアプライアンス側から開始されるため、ファイアウォールでインバウンドポートを開放する必要はありません。


instance-registry.ironflock.com:443   # IronFlock ソフトウェアとエージェントのダウンロードと更新、AI アシスタントと SMS 通知
cbw.ironflock.com:443                 # クラウドからのアプライアンスのリモート管理
web.ironflock.com:443                 # ライセンスの有効化と検証
registry.ironflock.com:443            # パブリックの IronFlock Store から同期する際のアプリイメージのプル
regauth.ironflock.com:443             # パブリック Store からのイメージプルの認証
app.ironflock.com:7000                # クラウドからアプリおよびデバイスのユーザーインターフェースを開く（任意。プロキシ経由ではポート 443）
smtp-proxy.ironflock.com:2525         # アカウントメールおよび通知メールの送信（任意）

registry.ironflock.com と regauth.ironflock.com のエントリは、パブリックの IronFlock Store から local App Store へアプリを同期するために必要です。registry.ironflock.com がアプリイメージを提供し、regauth.ironflock.com が各プルを認可するトークンを発行します — 両方に到達できなければ、同期（およびリモートのアプリ閲覧・インストール）は失敗します。アプライアンスがローカルでビルドしたアプリのみを提供する場合は、省略できます。Docker Hub などのパブリックレジストリのイメージを使うアプリは、同期時にそのレジストリからコピーされるため、アプライアンスはそのレジストリにも到達できる必要があります。

app.ironflock.com のエントリは、ironflock.com からインスタンスで作業する際に、アプリやデバイスのユーザーインターフェースへ到達できるようにするリモートアクセストンネルを通します。インターネットに直接接続されたアプライアンスはポート 7000 を使用し、企業プロキシの背後ではインストーラが自動的にポート 443 に切り替えます。このエントリがブロックされていても、目立ったエラーは発生しません — これらのインターフェースがクラウドから開けなくなるだけで、ローカルネットワーク上では引き続き動作します。アプライアンスをローカルでのみ使用する場合は、省略できます。

smtp-proxy.ironflock.com のエントリは、組み込みの IronFlock メールリレーを使用する場合にのみ必要です。独自の SMTP サーバーを設定する場合は、省略できます。

任意の接続先。 AI アシスタントはモデルとウィジェットのメタデータを raw.githubusercontent.com と cdn.jsdelivr.net から更新し、デバイスの設置場所の住所検索には nominatim.openstreetmap.org を使用します。3 つはいずれも任意です。ブロックされている場合、AI アシスタントは組み込みのデータで動作し、住所検索は利用できなくなります。

時刻同期は IronFlock 宛ての通信ではないため、この一覧には含まれていません。それでもアプライアンスには機能する時刻ソースが必要です。時刻サーバー宛ての外向き UDP 123 を許可するか、ホストに社内の時刻サーバーを設定してください — 時刻同期（NTP）を参照してください。

ネットワークが企業の HTTP プロキシ経由でしかインターネットに到達できない場合は、企業プロキシの背後でを参照してください — インストーラが Docker デーモンを自動的にプロキシへ向けるよう設定できます。

アプライアンスに接続するデバイス

エッジデバイスは、クラウドではなくアプライアンスに接続します。デバイスがアプライアンスとは異なるネットワークセグメントに存在する場合は、デバイスネットワークが以下のポートでアプライアンスホストに到達できるよう許可してください。


<APPLIANCE_HOST>:18080   # デバイスリンク（WebSocket）— 必須
<APPLIANCE_HOST>:15001   # local App Store レジストリ（アプリイメージのプル）— 必須
<APPLIANCE_HOST>:15002   # レジストリ認証（イメージプルトークン）、デバイスエージェントの更新およびデバイスインストーラー — 必須
<APPLIANCE_HOST>:7000    # デバイス UI へのリモートアクセス（任意のトンネル機能）

これらは直接接続であり、企業の HTTP プロキシ経由でルーティングしてはいけません。デバイスのネットワークがすべてのトラフィックをプロキシ経由に強制する場合は、デバイス側でアプライアンスホストをプロキシの対象外にするか、アプライアンスを企業証明書による HTTPS に切り替えてください。このモードでは、すべてのデバイストラフィック — デバイスリンク、イメージのプル、エージェントの更新、およびリモートアクセストンネル — が、自社ドメイン上の単一のプロキシフレンドリーなポート：443 に集約され、ポートごとの例外設定なしで企業プロキシや厳格なファイアウォールを通過して動作します。

ポート 15002 はデバイスエージェントの更新とデバイスインストーラーにも使われます。アプライアンスに接続されたデバイスはエージェントの更新を、新しいデバイスはインストーラーを、インターネットからではなくアプライアンス自身からダウンロードします — ドメインモードでは代わりに https://registry.<APPLIANCE_DOMAIN>/dl からポート 443 経由で取得します。デバイスエージェントの更新とインターネットに接続できないデバイスの登録を参照してください。

通常の運用では、デバイスにインターネットアクセスは必要ありません。 接続されたデバイスが行う通信 — デバイスリンク、アプリイメージ、エージェントの更新、リモートアクセス — はすべてアプライアンス宛てです。デバイスがインターネットに接続するのは、ベースイメージがパブリックレジストリにある Dockerfile からアプリをビルドするとき、パブリックイメージを使用するアプリを公開するとき、Docker 自体をまだインストールする必要があるとき、そして — FlockOS を実行しているデバイスでは — instance-registry.ironflock.com で OS の更新を確認するときだけです。デプロイするアプリには、それぞれ独自のネットワーク要件がある場合があります。

IronFlock ホストのネットワーク ID

アプライアンスとすべてのエッジデバイスは、IronFlock を無人のシステムサービスとして実行します。起動時に開始し、誰かがサインインしているかどうかに関係なく常時接続を維持します。そのため、これらのホストに対するファイアウォールおよびプロキシのルールはマシンに紐づける必要があります — たまたまそのマシンにログインしている人に紐づけてはいけません。エッジデバイスについては、どのプラットフォームに接続する場合でもこれが当てはまります。詳しくはデバイスガイドの ID 認識型ファイアウォールとプロキシで説明しています。

これが特に重要になるのは、アドレスではなくディレクトリ上の ID に基づいてアクセスを許可する ID 認識型ファイアウォールまたはプロキシ（identity-aware firewall / proxy）を使用しているネットワークです。IronFlock ホストを許可するルールがユーザーに紐づいていると、そのユーザーのセッションが切れた時点でホストはアクセスを失います。すでに開いている接続は動作し続ける一方、新しい接続はすべて通知なく破棄されるため、ホストは次に接続が必要になるまで正常に見えます。そのときにアプリのインストール、エージェントの更新、再接続が失敗し、次に再起動した後はデバイスがオフラインのままになります。

ID による制御の対象外にする必要はありません。各ホストを、そのホストが実際に持っている ID で識別するよう、ネットワークチームに依頼してください。

ホスト	ルールで使用する ID
ドメインに参加している Windows エッジデバイス	そのコンピューターアカウント — コンピューターオブジェクト、または IronFlock Edge Devices のようなグループ
その他のエッジデバイス（Linux、FlockOS、ドメイン外の Windows）およびアプライアンス	予約済み IP アドレスを持つ名前付きホストオブジェクト、またはネットワークアクセス制御（802.1X または MAC 認証）が割り当てる ID
認証付きプロキシ経由でのアプライアンスのインターネットアクセス	アプライアンス専用のサービスアカウント — プロキシ認証を参照してください

主な製品では、次のように対応します。

Check Point Identity Awareness： Access Role で、ユーザーではなくマシン（コンピューターオブジェクトまたはグループ）を選択します。マシン ID はコンピューター自身のドメイン上のアクティビティによって更新されます。ゲートウェイ上でマシン ID が失効する可能性がある場合は、代わりにネットワークオブジェクトを使用してください。
Palo Alto Networks User-ID： コンピューターアカウントからは IP とユーザーのマッピングが生成されないため、アドレスオブジェクト、タグ、または Device-ID を使用してください。
Fortinet FSSO および同様のディレクトリベースのファイアウォール： ホストのアドレスオブジェクト、またはネットワークアクセス制御が割り当てるダイナミックアドレスを使用してください。
Zscaler、Prisma Access などのクラウドセキュリティゲートウェイ： アプライアンスのアドレスをサーバーまたは IoT のロケーション（信頼できる送信元）として登録し、そのトラフィックがユーザーではなくロケーションによって識別されるようにしてください。

障害の見分け方。 デバイスはオンラインのままなのに、新しい接続 — イメージのプル、レジストリへのログイン、再接続 — がすべて失敗し、ping と既存のセッションは動作し続けている場合、原因はデバイスではなく、期限切れになった ID ルールにあります。デバイスからの新しい接続が再び成功するまでは、エージェントを再起動しないでください。まだ開いているセッションが、唯一機能している接続だからです。

ライセンスのライフサイクル

ライセンスは 1 台の物理アプライアンスに紐付けられます。同じライセンスを、異なるハードウェア上の 2 つ目の IronFlock インスタンスで同時に稼働させることはできません。日常運用ではアプライアンスはオフラインで動作します — 本番データ、ダッシュボード、アプリ管理、エッジデバイス制御はすべてボックス上にローカルで保持されます。

アプライアンスにインターネットが必要なとき

インターネット接続が必要となるのは、以下のタイミングのみです。

初回インストールおよびアプライアンスの更新 — いずれにせよ IronFlock の配布サーバーからソフトウェアを取得するために必要であり、ライセンスのアクティベーションも同じステップの中で行われます。
定期的なライセンス再チェック — お使いのプランによって異なります。
- 月次ライセンス：30日に 1 回。
- 年次ライセンス：365日に 1 回。
- 永続ライセンス：定期的な再チェックはなし — インターネットはインストール時および更新時にのみ必要です。
新しいハードウェアへのライセンスの引き渡し（後述）。
AI Multi Agent サービス — 実際に利用している間のみ。

グレースピリオドとロック

定期的な再チェックがクラウドに到達できない場合（ネットワーク障害、一時的なクラウド側のエラーなど）、アプライアンスは 7日間のグレースピリオド に入ります。グレースピリオド中、アプライアンスは通常どおり動作し続け、再チェックを自動的にリトライします。

7日間が完全に経過しても再チェックに成功しない場合、アプライアンスは自身をロックします：ほとんどの操作が拒否され、UI 上ではライセンスが無効と表示されます。復旧するには、アプライアンスのインターネット接続を回復したうえで、アプライアンス UI のプロフィールにあるライセンスパネル（ローカルの http://<appliance-host> ビュー、または ironflock.com 経由でアクセスするインスタンス）で「今すぐ再検証」をクリックしてください。

ライセンスを新しいハードウェアへ移行する（引き渡し）

ライセンスは 1 台のマシンのハードウェアフィンガープリントに紐付けられています。別のマシンに移行するには、IronFlock のクラウドプロフィールから引き渡しを開始します。

ironflock.com の Profile → Instances を開きます。
移行したいインスタンスで「ハードウェアフィンガープリントをリセット」をクリックします。

引き渡しには、現在バインドされているアプライアンスがオンラインである必要があります。クラウドはそのアプライアンスに接続し直し、ローカルで自身を失効させるよう要求したうえで、はじめてクラウド側のフィンガープリントを解除します。このハンドシェイクにより、新しいアプライアンスがバインドされる間に古いアプライアンスが動作し続けることはできなくなり、同じライセンスが誤って二重利用されることを防ぎます。

ロック解除が成功したら、次の手順を行います。

はじめにの手順に従って、同じインスタンスキーを使用して新しいハードウェアをセットアップします。
新しいアプライアンスがライセンスを検証し、自身のフィンガープリントをバインドして、アクティブなデバイスになります。

古いハードウェアが故障またはアクセス不能な場合

以前バインドされていたアプライアンスが停止している、または何らかの理由で到達不能な場合、ハンドシェイクはタイムアウトし、クラウド UI には appliance_unreachable_contact_support と表示されます。その場合は IronFlock チームまでご連絡ください — 所有権を確認のうえ、バインディングを手動で解除いたします。

ヒント：古いハードウェアを廃棄する前に、まだオンラインのうちに引き渡しを実行してください。古いアプライアンスにまだ到達できる状態であれば、お客様にとってもサポートチームにとっても、はるかに迅速に処理できます。

ローカル運用

アプライアンスをオンラインに保ちたくない場合でも、同じローカルネットワーク上のブラウザからアプライアンスの IP アドレスまたはホスト名にアクセスして利用できます。


http://<appliance-host>

デフォルトの認証情報でログインします。

ユーザー名： admin
パスワード： ironflock

初回ログイン時に admin の認証情報を変更することを忘れないでください。

アプリの Web UI

接続されたデバイス上のアプリが Web インターフェースを公開すると、アプライアンスは組み込みのトンネルを通じてそれに到達できるようにします。追加設定不要で、企業 IT に依頼するものは何もありません — 各アプリの UI は、アプライアンスのアドレスの自動的に割り当てられたポート上でプレーン HTTP として公開され（http://<appliance-host>:<port>）、IronFlock UI にリンクが表示されます。アクセスは引き続きアプライアンスのログインで保護されます。

共有の企業ネットワークで信頼された https:// URL を利用するには — 自社 CA のワイルドカード証明書や、TLS を終端するリバースプロキシを使って — アプリ UI と HTTPS を参照してください。

アカウントの連携

アプライアンスのプロジェクト設定からチームメンバーをメールで招待して、ローカルユーザーアカウントを作成します。招待メールには、招待されたメンバーに必要なものがすべて含まれています。

個人用の接続リンク — このリンクを ironflock.com で開くと、招待されたメンバーの ironflock.com アカウントがアプライアンスに接続されます。ironflock.com アカウントをまだ持っていない場合は、まず招待されたメールアドレスを使用してアカウントを作成します（接続は 2 つのメールアドレスが一致する場合にのみ許可されます）。接続が完了すると、アプライアンスがその方の ironflock.com プロジェクトセレクターに表示され、すぐにリモートで作業を開始できます — 手動でのキー入力もローカルでのサインアップも不要です。
ローカルサインアップ用リンク — 任意：ローカルサインアップを完了すると、さらにアプライアンス UI（http://<appliance-host>）に直接ログインできるようになります。

いくつか知っておくべきポイントがあります。

既存のローカルユーザーには、プロジェクトオーナーからの新たな招待は不要です。アプライアンス UI でプロフィールを開き、ironflock.comに接続 セクションの 接続リンクをメールで送信 をクリックします。
再送について：同じメールアドレスをもう一度招待する（またはプロフィールのボタンを再度クリックする）と、新しい接続リンクが発行されます。有効なのは最新のメールに記載されたリンクのみです。
アプライアンスがメールを送信できない場合 — たとえばメールリレーがブロックされる制限された企業ネットワーク上など — は、代わりに接続リンクが UI に直接表示されます。招待者がこれをコピーし、任意の手段で相手に渡してください。リンクはインターネットにアクセスできるブラウザで開く必要があります。
接続の解除：ユーザーは ironflock.com の Profile → Instances → 接続済みインスタンス で、いつでも接続を解除できます。最新の接続リンクをもう一度開くと、接続が復元されます。

インスタンスのオーナー — ironflock.com で Instance Key を作成したユーザー — は、自動的にインスタンスのローカル管理者アカウントに接続されます。オーナーに招待は不要です。

エッジデバイスの追加

追加のエッジデバイス（つまり産業用 PC）を導入することで、より多くの機械に IronFlock アプリをデプロイし、アプライアンスからアプリの運用負荷をオフロードできます。アプライアンス自体もエッジデバイスとして機能しますが、IronFlock クラウドでエッジデバイスをデプロイするのと同じ方法で、さらに多くのエッジデバイスを接続できます。 プロジェクト設定 -> デバイス -> 新しいデバイス に移動し、指示に従ってください。

メンテナンス

アプライアンスの IronFlock システムを更新するには、新しいバージョンが利用可能になった際に、管理者がプロフィールのライセンスセクションにある更新ボタンを使用できます。アプライアンスは更新をダウンロードするためにインターネット接続が必要です。更新が完了すると、IronFlock は自動的に再起動します。

Linux OS のアップデートはお客様ご自身で維持・管理してください。

デバイスエージェントの更新

アプライアンスに接続されたエッジデバイスは、IronFlock デバイスエージェントの更新をアプライアンス自身から受け取ります。デバイスが instance-registry.ironflock.com に接続することはなく、更新のためにインターネットアクセスも必要ありません。

シンプルモード（IP）： http://<appliance-host>:15002/dl — デバイスがレジストリトークンの取得にすでに使用しているポートと同じです。
ドメイン／TLS モード： https://registry.<appliance-domain>/dl（ポート 443）。

アプライアンスはエージェントのバイナリのローカルミラーを保持し、https://instance-registry.ironflock.com（すでにファイアウォールの許可リストに含まれています）から 6 時間ごとに更新します。設定 → ライセンス／アプライアンス → デバイスエージェントの更新 → 今すぐ同期 から手動で更新することもできます。アプライアンスのミラーは IronFlock クラウドからも更新できます。インスタンスを開く必要も、アプライアンス自体にログインする必要もありません。クラウドの Studio で Profile → Instances を開くと、ご自身が所有する各アプライアンスに デバイスエージェントの更新 列があり、そのミラーが現在デバイスに提供しているエージェントのバージョン（その下にデバイスインストーラーのバージョン）が表示され、同じセルから 今すぐ同期 を実行できます。ミラーはクラウドのリリースマニフェストに従います。クラウドのマニフェストが現在参照しているすべてのエージェントバージョンが、すべての Linux ターゲットと Windows について保持され、各バージョンはアプライアンス上に完全に揃ってはじめてデバイスに提供されます。クラウドが公開したバージョンがアプライアンス上でまだ完全に揃っていない場合、デバイスには引き続き以前のバージョンが表示されます。

デバイスは更新の取得先を .flock ファイル（update_url）から取得し、エージェントバージョン 0.21.2 以降は、ハートビートのたびにアプライアンスからも受け取ります。そのため、アプライアンスの IP アドレスの変更やドメインモードへの切り替えは、デバイスに自動的に反映されます。

この機能より前にプロビジョニングされたデバイスで古いエージェントが動作している場合は、.flock ファイルを一度ダウンロードし直す必要があります。Windows の場合：reagent サービスを停止し、%ProgramData%\IronFlock\Reagent\device.flock を新しいファイル（BOM なしで保存）に置き換えてから、サービスを再度開始します。

インターネットに接続できないデバイスの登録

アプライアンスはデバイスインストーラー（ironflock-init）とそのインストールスクリプトもミラーしているため、アプライアンスにしか到達できない新しいエッジデバイスでも登録できます。プロジェクト設定 → デバイス → 新しいデバイス に表示されるコマンドは、すでにアプライアンスを指しています — シンプルモード（IP）では http://<appliance-host>:15002/dl/...、ドメインモードでは https://registry.<appliance-domain>/dl/... です。

Linux： ワンライナーは curl -sSL <base>/reswarmify/install.sh | IRONFLOCK_DL_BASE=<base> bash という形式です。その後、デバイスの .flock ファイルをコピーして sudo ./ironflock-init -c <file>.flock を実行します。ironflock-init はダウンロード元のベース URL を .flock ファイルから取得します。--download-base で上書きできます。
Windows： <base>/re-agent/windows/amd64/latest/reagent.exe から reagent.exe をダウンロードし、デバイスの接続の手順に従ってサービスをインストールします。

インターネットに接続できないデバイスの前提条件： Docker（Engine と Compose プラグイン）および基本パッケージがあらかじめインストールされている必要があります。アプライアンスがミラーするのは IronFlock 自身のバイナリであり、ディストリビューションのパッケージではありません — ironflock-init が get.docker.com にアクセスを試みるのは、Docker が見つからない場合のみです。

インストーラーの保存領域はエージェントのミラーと一緒に更新されます — 同じ 6 時間周期で、同じ 今すぐ同期 ボタンから更新できます。

メール送信元のカスタマイズ（SMTP）

デフォルトでは、アカウント確認、パスワード復旧、招待、アラーム通知などすべてのプラットフォームメールは IronFlock クラウド SMTP プロキシ経由で送信され、no-reply@ironflock.com として表示されます。メールを御社からの送信として表示したい場合は、アプライアンスを自社の SMTP サーバーに向けることができます。

アプライアンスのホスト上で、インストーラーが生成した環境ファイル /opt/ironflock/.env を編集し、以下の変数を設定してください。


SMTP_CONNECTION_URI=smtps://USERNAME:PASSWORD@smtp.your-company.com:465/
SMTP_FROM_ADDRESS=no-reply@your-company.com
SMTP_FROM_NAME=Your Company

暗黙的 TLS（通常はポート 465）の場合は smtps:// を、STARTTLS（ポート 587）の場合は smtp:// を使用します。
ユーザー名やパスワード内の特殊文字は URL エンコードしてください（例：@ → %40）。
SMTP_FROM_ADDRESS と SMTP_FROM_NAME は、受信者が各プラットフォームメールの From ヘッダーで目にする値です。

スタックを再起動して変更を反映します：


sudo systemctl restart ironflock.service

再起動後、すべての認証メール、プラットフォーム通知、アラームメールは、御社の送信者アドレスと表示名で自社の SMTP サーバー経由で送信されます。

SMTP_CONNECTION_URI が設定されていない場合、アプライアンスはライセンスキーで認証された IronFlock クラウド SMTP プロキシを引き続き使用してメールを送信します。追加の設定は不要ですが、メールには IronFlock のブランドが表示されます。

ボックスの内容

Appliance には、すべての IronFlock サービスがプリインストール・事前設定済みで出荷されます。

ローカルネットワークからアクセス可能な IronFlock UI
オフラインアプリ配布用の local App Store
Board Studio、Alarms、Data Store
AI Multi Agent システム（インターネット接続時のみ動作）

エッジデバイスとサーバーを 1 台に

Appliance は IronFlock プラットフォームを実行するだけでなく、IronFlock のコンテキストにおけるエッジデバイスとしても同時に機能します。つまり、他の管理対象デバイスと同様にコンテナ化されたアプリを実行しながら、同じネットワーク上の他のデバイスの中央管理ノードとしても機能します。これにより、プラットフォームサーバーとエッジコンピューティングが 1 台に集約された、コンパクトかつ完全なソリューションとなります。

Appliance は、管理対象のあらゆるエッジデバイスと同じ IronFlock デバイスエージェントを実行しているため、エージェントの接続性とレジリエンスによる保護の恩恵も受けます — 無期限の自動ネットワーク再接続、ディスクが満杯になってもボックスを到達可能に保ち自動的に回復するストレージ緊急事態の状態、out-of-memory 保護、そして自己再起動するエージェントです。これは、Appliance が — そしてそれへのリモートアクセスが — ローカルネットワーク、ディスク、メモリの問題を通じてオンラインを維持できる重要な理由です。

アーキテクチャ

ハードウェア

Appliance のハードウェアは応相談で、通常は OEM または機械メーカーが提供します。IronFlock はソフトウェアスタックを提供し、出荷前に選定されたハードウェアにシステムを事前設定します。一般的には、中規模の産業用エッジ PC（4 コア、8 GB RAM）があれば、スタック全体と追加のアプリケーションを十分に実行できます。ユースケースに応じたハードウェア要件については、IronFlock チームにお問い合わせください。

オンラインストアからのアプリ同期

Appliance には local App Store — ローカルネットワーク上のデバイスにアプリを提供するプライベートなアプリカタログとコンテナレジストリ — が含まれています。Appliance が同期時にインターネット接続を利用できれば、パブリックのオンライン IronFlock Store からアプリを同期してこの local App Store を構成できます。常時のインターネット接続は不要で、必要なアプリをプルするための一時的な接続で十分です。

前提条件

パブリックの ironflock.com プラットフォーム上のアカウント。
アプライアンスのアカウントが ironflock.com アカウントに接続されていること（アカウントの連携を参照）。インスタンスオーナーの管理者アカウントは自動的に接続されます。

アプリ同期の仕組み


┌────────────────────┐                       ┌────────────────────┐
│  Online IronFlock  │  ◄──── account ─────► │  Appliance         │
│  Store (cloud)     │      connection       │  local Store       │
└────────────────────┘                       └────────────────────┘
         │                                            │
   apps available to                          sync button shown
   the connected account                      instead of install

local App Store を開く — Appliance が有効なインターネット接続を持っている場合、App Store には接続済みの ironflock.com アカウントがオンラインプラットフォームで利用可能なすべてのアプリが表示されます。
必要なアプリを同期する — 各アプリには Install ボタンの代わりに Sync ボタンが表示されます。クリックすると、コンテナイメージとメタデータを含むアプリがオンラインストアからローカルストアにダウンロードされます。
デバイスを追加する — 同期が完了すると、アプリはローカルストアで完全に利用可能になり、通常どおりデバイスを追加できます。インターネット接続は不要です。

アップデートのワークフロー

同期済みアプリの新バージョンがオンラインストアに公開されると、そのアプリに再び Sync ボタンが表示されます。Appliance を短時間インターネットに接続して更新後のリリースを同期し、その後、標準のアプリアップグレードフローを通じてデバイスにロールアウトします。

この設計により、ネットワークに入ってくるものを完全に制御できます — 何も自動的にはダウンロードされず、インターネット接続は同期ステップの間だけ必要になります。

制限事項

AppStudio は単一マスターアカウントのみ — Appliance は、1 つのマスターアカウント専用の AppStudio 環境のみをホストできます。アプリ開発は単一の組織に限定されます。
スケールが限定的 — Appliance は 1 拠点内の限られた台数の機械向けにサイズ設計されています。複数拠点にまたがるフリートや数万台規模のデバイスには、クラウドまたはプライベートクラウドデプロイメントの方が適しています。
AI サービスにはアウトバウンドの LLM アクセスが必要 — Appliance がインターネットにまったくアクセスできない場合のオプションは、プライベートクラウドを参照してください。

お問い合わせ

アプライアンスのデプロイメントは IronFlock チームとのパートナーシップで構成します。ハードウェア、機械台数、ブランディング要件についてはお問い合わせください。