インストーラー

1 つのコマンドで、Linux サーバー上の AnsibleForms をインストール、アップグレード、管理します

  1. インストールされるもの
  2. 実行する
  3. ウィザード
  4. ランナー
  5. Kubernetes
  6. コマンド
  7. フラグ
  8. 無人実行
  9. 既存のインストール
  10. アップグレード
  11. 7.2 のランナー
  12. バージョン

管理者向けです。動作するインスタンスを用意する、あるいは別の場所にインストールされた AnsibleForms 用のランナーを用意する最も早い方法です。7.3.0 以降で使えます。

インストールされるもの

インストーラーはフルスクリーンのウィザードでいくつかの質問をし、すべての回答を確認のために表示してから、初めてサーバーを変更します。 インストールするのは 2 つの役割のどちらかで、4 つのエンジンのいずれかの上に構築します。

役割 内容
コントローラー アプリケーション一式です。Web インターフェース、そのデータベース、そして専用のランナーを含みます。初めてのインストールではこれを選びます
ランナー 別の場所にインストールされた AnsibleForms のプレイブックを実行する RTE です。別のネットワーク、DMZ、別のデータセンターなどに置きます。1 本の WebSocket で AnsibleForms と通信し、データベースの認証情報は持ちません

インストール先のエンジンは次のとおりです。

エンジン 動作のしかた
Docker Docker Engine とその compose プラグイン上の Docker Compose プロジェクト 。コンテナーは Docker と一緒に再起動します
Podman 同じプロジェクトを Podman 上で、rootless または root として、podman-compose で動かします。systemd ユニットが起動時にコンテナーを開始します
Kubernetes kubectl が接続するクラスター上の Helm チャート 。コントローラーは Ingress の背後で公開され、ランナーはチャートのランナーモードを使います
このサーバーに直接 コンテナーなし。サーバーに Node.js、MariaDB、Ansible を入れ、AnsibleForms を systemd サービスとして動かします。 ネイティブインストール を参照してください

インストール後は、同じプログラムでインストールのアップグレード、バックアップ、ステータス表示、削除を行えます。インストーラーが インストールしていない AnsibleForms、たとえば Docker Compose プロジェクトから手動で構築したものを引き継ぐこともできます（ 既存のインストール を参照）。

実行する

インストールスクリプトがこのサーバー用のインストーラーをダウンロードして起動します。

curl -fsSL https://ansibleforms.com/install | sh

よく使うバリエーションは次のとおりです。Docker や Podman をインストールする場合、サーバーに直接インストールする場合、 /opt の下にインストールする場合は root として実行します。コマンドや フラグを付けて実行することもでき（ フラグ を参照）、最新版ではなく特定のリリースのインストーラーを使うこともできます。

curl -fsSL https://ansibleforms.com/install | sudo sh
curl -fsSL https://ansibleforms.com/install | sh -s -- --lang es
curl -fsSL https://ansibleforms.com/install | AF_INSTALLER_VERSION=7.3.0 sh

スクリプトの動作は次のとおりです。

  1. サーバーが amd64 または arm64 の Linux であることを確認し、 curl または wget と sha256sum を探します
  2. ansibleforms/installer の最新リリース、または AF_INSTALLER_VERSION で指定したリリースから ansibleforms-installer_linux_<arch> をダウンロードします
  3. リリースの checksums.txt と照合し、チェックサムが一致しないダウンロードは使いません
  4. 後のアップグレードやバックアップのために、root の場合は /usr/local/bin に、それ以外は ~/.local/bin に ansibleforms-installer として保存します。 sudo 経由で実行するときはフルパスを指定してください。Red Hat 系のシステムのように、sudo の secure_path に /usr/local/bin が含まれていないことがよくあります
  5. 指定されたフラグで起動します。スクリプトがパイプ経由で渡されても、キーボード入力は端末から読み取ります

CI ジョブなど端末がない環境では、インストーラーは無人で実行されます（ 無人実行 を参照）。

ウィザード

ウィザードは一度に 1 つずつ質問し、左側にステップを表示します。 Esc で前のステップに戻ります。そのステップの回答は保持されます。

ステップ 質問の内容
言語 インストーラーの言語。既定ではこのサーバーのロケールから決まります。カタルーニャ語、ドイツ語、英語、スペイン語、フランス語、イタリア語、日本語、オランダ語、ポーランド語、ポルトガル語、中国語から選べます。見つかったインストールについてインストーラーが何か表示する前に、最初に質問します
リリースノート インストールするバージョンの新機能。互換性のない変更、削除、非推奨が先に表示されます
役割 コントローラーまたはランナー
エンジン Docker、Podman、Kubernetes、またはこのサーバーに直接
フォルダー インストール先フォルダーとインスタンス名
参加、アプリ、モード ランナーのみ。 ランナー を参照してください。Kubernetes ではモードは質問しません
ネットワーク Web インターフェースまたはランナーのポート。Kubernetes では質問しません
HTTPS ブラウザーがコントローラーに接続する方法
管理者 最初の管理者のパスワード。2 回入力します
クラスター、Ingress、ストレージ Kubernetes のみ。Namespace とリリース、Ingress（コントローラーの場合）、ストレージクラス
確認 すべての回答。 インストール または 回答を変更

エンジン。 一覧にはこのサーバーにあるものが表示されます。ないエンジンは Docker (未インストール: インストーラーが導入します) のように表示され、Podman も同様です。確定すると、インストーラーは Docker を Docker 公式のスクリプト（ get.docker.com 、compose プラグイン 付き）で、Podman をディストリビューションのパッケージから podman-compose と一緒にインストールします。これには root が必要です。Kubernetes は kubectl と helm がインストールされ、クラスターに接続できる場合に表示されます。 このサーバーに直接 には root と対応する Linux が必要で、グレー表示のときはその理由が示されます。

フォルダー。 既定値は次のとおりです。

  コントローラー ランナー
フォルダー（root の場合） /opt/ansibleforms /opt/ansibleforms-runner
フォルダー（その他のユーザーの場合） ~/ansibleforms ~/ansibleforms-runner
インスタンス名（Docker または Podman） af runner
インスタンス名（ネイティブ） ansibleforms ansibleforms-runner

Docker または Podman の場合、フォルダーには compose ファイルとシークレットを含む .env 、そしてデータベース、フォーム、プレイブック、 ログといったすべてのデータが入ります。フォルダーは空でなければなりません。インスタンス名は英小文字、数字、 - で構成し、コンテナーの接頭辞になります（ af_app 、 af_db 、 af_rte ）。そのため、 複数のインスタンスで 1 台のサーバーを共有できます。ランナーのインスタンス名は、 接続 > ランナー でのランナー名（ RTE_NAME ）にもなります。

ネットワーク。 コントローラーの Web インターフェースは 443 、または次に空いているポートで待ち受けます。続いて HTTPS で次の選択肢が表示されます。

選択肢 内容
HTTPS、このサーバー用に作成する自己署名証明書 このサーバーの名前に対する証明書で、10 年間有効です。ブラウザーで一度だけ受け入れる必要があります
HTTPS、自分の証明書と鍵 CA または Let’s Encrypt から取得した、PEM 形式の自分の証明書と鍵
HTTP、HTTPS は前段のリバースプロキシで処理 ポートでプレーンな HTTP を提供します。HTTPS を処理する nginx、Traefik、ロードバランサー向けです

管理者。 admin ユーザーのパスワードです。入力ミスで締め出されないよう 2 回入力します。空のままにすると、インストーラーが 強力なパスワードを生成します。

完了。 インストーラーはデータベースのパスワードとシークレットを生成し、AnsibleForms を起動して応答するまで待ちます。その後、 開くアドレス、ユーザー、パスワード、フォルダーを表示します。このコントローラー用にインストールしたランナーは参加を求めるので、管理者が 接続 > ランナー で承認します（ ランナー を参照）。

ランナー

ランナーは、別の場所で動いているバージョン 7.3.0 以降の AnsibleForms のための RTE です。データベースの認証情報は持たず、 専用のトークンでサインインします。AnsibleForms はこのトークンを RTE の認証情報に保存します（ モード を参照）。フォルダーの後、ウィザードは さらに 3 つのことを質問します。

ステップ 質問の内容
アプリ このランナーが担当する AnsibleForms のアドレス。利用者がブラウザーで開くアドレスです
モード アウトバウンド: ランナーが AnsibleForms に接続 （既定）、または インバウンド: AnsibleForms がランナーに接続
ネットワーク ランナーのポート。既定は 8000 です。アウトバウンドでは、ヘルスチェックだけがこのポートで待ち受け、このサーバーからしか到達できません。インバウンドでは、AnsibleForms から到達できるこのサーバーのアドレスも質問します

--role runner を付けると役割の質問が省略されるので、ランナーのサーバーで次のコマンドを実行すると、ランナーの質問から始まります。

curl -fsSL https://ansibleforms.com/install | sh -s -- install --role runner

インストーラーは次に AnsibleForms に接続します。自己署名証明書やプライベート CA の証明書の場合は この証明書を信頼しますか? と質問され、 はいと答えるとランナーに APP_TLS_VERIFY=0 が設定されます。インストーラーは AnsibleForms が動かしているバージョンを読み取り、 7.3.0 より古ければ中止し、インストーラー自体が本来インストールするバージョンに関係なく、それと同じバージョンでランナーをインストールします。

DMZ、NAT、または着信接続を許可しないゾーンではアウトバウンドを選びます。必要な通信は、このサーバーから AnsibleForms のポートへの 通信だけです。中央側がすべての接続を開始するネットワークではインバウンドを選びます。

確認画面には 登録: 承認を求めます 、または --join で参加トークンを指定した場合は 自動 (参加トークン) と表示されます。最後にインストーラーは ランナーの名前、モード、アプリ、インバウンドの場合はそのアドレスを表示し、AnsibleForms に参加を求めたことを伝えます。 接続 > ランナー で、表示されるフィンガープリントがインストーラーの出力と同じであることを確認してから承認してください。

Fingerprint: abcd-ef12

フィンガープリントは、ランナーのトークン RTE_TOKEN の SHA-256 の先頭 16 進数 8 桁です。トークンはフォルダーの .env ファイル（ ネイティブインストール では rte.env ）に保存されています。 RTE の承認 を参照してください。 --join を使うと、ランナーはすぐに承認されます。 ランナーは自分自身を登録し、 接続 > ランナー で接続済みとして表示されます。

インバウンドのランナーは HTTPS でソケットを提供します。インストーラーは AnsibleForms から到達するアドレスに対する自己署名証明書を作成し （10 年間有効）、フォルダーの data/certificates に置き、 RTE_URL を https://<address>:<port> に設定します。 ランナーは参加を求めるときに証明書を送り、AnsibleForms はそれをピン留めします。そのランナーが同じ証明書を提示した場合にのみ接続するので、 CA は必要ありません。インストーラーはトークンのフィンガープリントの下に、証明書のフィンガープリントを表示します。

Fingerprint: abcd-ef12
Certificate fingerprint: 3f9c-07a1

これは証明書の DER バイト列の SHA-256 の先頭 16 進数 8 桁で、 xxxx-xxxx の形式です。ランナーを承認する前に、 承認ダイアログに同じ証明書のフィンガープリントが表示されていることを確認してください。 --join で登録したランナーも、これを表示します。

Kubernetes では、ランナーは Helm チャートのランナーモードで、常にアウトバウンドです。外部から到達するものがないため、ウィザードはモードもネットワークも 質問しません（ Kubernetes を参照）。

Kubernetes

Kubernetes 上のコントローラーでは、インストーラーは kubectl が接続するクラスターに Helm チャート をインストールします。

質問 既定値
Namespace ansibleforms
Helm リリース名 ansibleforms
Ingress で公開するホスト名 なし。必須です。例 ansibleforms.example.com
Ingress クラス クラスターにあるもののいずれか。既定は nginx
HTTPS で公開しますか (Ingress の証明書を使用)? はい
ボリュームのストレージクラス クラスターの既定

管理者のパスワードは、その Namespace の Secret <release>-secrets のキー ADMIN_PASSWORD にあります。インストーラーは チャートの values を状態ファイルの隣にあるファイル <release>-values.yaml に保存し、アップグレードのたびに再適用します。 --values で独自のファイルを追加できます。リリースのチャートは、リリースの少し後に公開されます。

ランナーの場合、インストーラーは同じチャートを ランナーモード （ runner.enabled ）でインストールします。アプリもデータベースも Ingress もない RTE だけの構成で、AnsibleForms に接続します（アウトバウンド）。アプリのアドレスの後、ウィザードは次を質問します。

質問 既定値
Namespace ansibleforms
Helm リリース名 ansibleforms-runner 。これは 接続 > ランナー でのランナー名にもなります
ボリュームのストレージクラス クラスターの既定

インストーラーはランナーのトークンを作成し、アプリのアドレスとランナー名を設定します。アプリの証明書を信頼した場合は runner.appTlsVerify: false も設定します。 --join を使うと参加トークンでランナーがすぐに承認されます。使わない場合はランナーが参加を求め、 インストーラーがフィンガープリントを表示するので、それを確認してから 接続 > ランナー で承認します。

コマンド

インストーラーはフラグの前または後にコマンドを受け取ります。コマンドを指定しなければインストールを行います。

コマンド 内容
install AnsibleForms をコントローラーまたはランナーとしてインストールします（既定）。すでにインストールがあるサーバーでは、自分がインストールしたものでも見つけたものでも、アップグレードを提案します
upgrade 新しいバージョンにアップグレードします。先にリリースノートを表示します（ アップグレード を参照）
status インストール（役割、エンジン、バージョン）と、そのコンテナー、Pod、サービス、応答するかどうかを表示します。その後、サーバー上で見つかったほかの AnsibleForms を一覧表示します
backup 今すぐデータベースをバックアップします。保存先はインストール先フォルダーの installer-backups です（Kubernetes ではインストーラーの状態ファイルの隣の backups ）。ランナーにはバックアップするデータがありません
release-notes バージョン（ --version またはこのインストーラーのバージョン）のリリースノートを表示します。互換性のない変更が先に表示されます
uninstall インストールを削除します。 --purge を付けるとデータも削除します
version インストーラーのバージョンを表示します

インストーラーはインストールの情報を、root の場合は /etc/ansibleforms/installer.json に、それ以外のユーザーの場合は ~/.config/ansibleforms/installer.json に記録します。そのため、 install の後のコマンドにはフラグが不要で、自動的にインストールを見つけます。このフォルダーにバイナリは入っておらず、 インストーラーが AnsibleForms をインストールするか引き継いだ後にだけ存在します。

sudo /usr/local/bin/ansibleforms-installer status
sudo /usr/local/bin/ansibleforms-installer backup
sudo /usr/local/bin/ansibleforms-installer upgrade

uninstall は データ (データベース、フォーム、プレイブック、ログ) も削除しますか? と質問します。削除するには、インスタンス名（Kubernetes では Helm リリース）を 入力します。それ以外の場合は、コンテナー、Pod、サービスを削除してデータは残します。

フラグ

各フラグは 1 つの質問に答えるもので、ウィザードはその質問を省略します。 ansibleforms-installer --help で一覧を表示できます。

フラグ 答える質問
--lang <code> 言語。 ca 、 de 、 en 、 es 、 fr 、 it 、 ja 、 nl 、 pl 、 pt 、 zh のいずれか
--version <version> インストールまたはアップグレード先の AnsibleForms のバージョン。既定はこのインストーラーのバージョン
--role <role> controller または runner
--mode <mode> compose 、 kubernetes 、 native のいずれか
--runtime <runtime> docker または podman （compose）
--install-runtime Docker または Podman がない場合、質問せずにインストールします
--dir <folder> インストール先フォルダー（compose）
--name <name> インスタンス名。コンテナーの接頭辞になります（compose、既定は af ）
--port <port> ホスト上のポート。コントローラーでは Web インターフェース、ランナーでは RTE のポート
--tls <choice> self 、 own 、 off のいずれか（compose のコントローラー）
--cert <file>, --key <file> 証明書と鍵のファイル。 --tls own と一緒に使います
--admin-password <password> 最初の管理者のパスワード。既定では生成されます
--join <token> API で作成した参加トークン（ afj_... ）。ランナーをすぐに承認します（ランナー、無人実行。 参加トークン を参照）
--app-url <address> アプリのアドレス。例 https://forms.example.com （ランナー）
--runner-mode <mode> outbound （RTE がアプリに接続）または inbound （アプリが RTE に接続）（ランナー）
--host <address> アプリが接続するこのサーバーのアドレス（インバウンドのランナー）
--namespace <namespace> Kubernetes の Namespace。既定は ansibleforms
--release <release> Helm リリース。既定は ansibleforms
--hostname <name> Ingress のホスト名（kubernetes）
--ingress-class <class> Ingress クラス（kubernetes）
--storage-class <class> ストレージクラス（kubernetes）
--values <file> 追加の Helm values ファイル（kubernetes）
--purge uninstall と一緒に使い、データも削除します
--source <folder> インストール元にする ansibleforms/docker リポジトリのローカルコピー（エアギャップ環境）
--bundle <file> ネイティブインストールに使うリリースバンドル ansibleforms-<version>-linux-<arch>.tar.gz （ ネイティブインストール を参照）
--yes すべての質問に既定値で答えます（無人実行）
--verbose 実行するすべてのコマンドを表示します

無人実行

--yes を付けるか端末がない場合、インストーラーは何も質問しません。フラグがそれぞれの質問に答え、残りは既定値で答えます。 言語、リリースノート、管理者のパスワード（ --admin-password で指定しない限り生成されます）、確認を省略し、代わりに リリースノートへのリンクを表示します。Docker や Podman がない場合にインストールするのは --install-runtime または --yes があるときだけで、ランナーには --app-url が必要です。 --join がなければランナーは参加を求めて管理者の承認を待ち、あればすぐに承認されます。

Docker 上のコントローラーで、Docker がなければインストールする例です。

curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
  --role controller --runtime docker --install-runtime --tls self --admin-password '<password>'

Podman 上のインバウンドのランナーで、アプリが rte-dmz.example.com:8000 に接続する例です。

curl -fsSL https://ansibleforms.com/install | sudo sh -s -- install --yes \
  --role runner --runtime podman --install-runtime --app-url https://forms.example.com --join afj_<...> \
  --runner-mode inbound --host rte-dmz.example.com --port 8000

既存のインストール

インストーラーは、インストールしたものを installer.json に記録します。このファイルがない場合、 install 、 upgrade 、 status はまず、 何でインストールされたかに関係なく、サーバー上にすでにある AnsibleForms を探します。

見つかるもの 見つけ方 引き継げる条件
Docker または Podman アプリまたは RTE のイメージのコンテナーを、compose プロジェクトごとにまとめて見つけます フォルダーに ansibleforms/docker リポジトリの compose ファイルと .env があること。サービス mysqldb 、 app 、 rte が、コンテナー <name>_db 、 <name>_app 、 <name>_rte で動いていること
7.2 のランナー compose プロジェクト内に単独で存在し、アプリの DB_* を持ち、 RTE_MODE がない RTE（データベースモード） compose ファイルが読み取れること。アップグレードでソケットモードに移行します（ 7.2 のランナー を参照）
Kubernetes ansibleforms チャートの Helm リリース、およびそのイメージの Deployment と StatefulSet チャートのリリースであること。現在の values がその values ファイルになります
ネイティブ Node.js で AnsibleForms を実行している systemd サービス インストーラーのレイアウトに従っていること。 releases/ 、 current 、 app.env 、 rte.env （ ネイティブインストール を参照）
エンジンなし 通常のポート（443、3000、3001、8000、8001、8010、8443）で応答するアプリまたは RTE 引き継げません。ソースから、または手動で実行されています。インストーラーは報告するだけです

数えるのはアプリと RTE のイメージだけです。AnsibleForms にちなんだ名前の MySQL コンテナーはインストールとはみなしません。インストーラーは 見つけたものを 1 行ずつ一覧表示し、その理由と、引き継げないものについては手動で行うべきことを示します。引き継げない理由には、compose ファイルがリポジトリのものではない、 データベースが compose プロジェクトの外にある、Helm チャートを使わずに Kubernetes で動いている、Argo CD で管理されている（その場合は Application の チャートのバージョンを変更して、Argo CD 側でアップグレードします）、バージョンを読み取れない、といったものがあります。

引き継げるインストールに対して、 install は 3 つの選択肢を示します。

選択肢 内容
引き継いでアップグレード 記録する内容を表示し、確定すると installer.json を書き込んで、 アップグレード に進みます
それでも隣に新しい AnsibleForms をインストールする 専用のフォルダー、ポート、データベースを持つ 2 つ目のインストールです。別途確認があります
中止 何も変更しません

インストーラーがインストールするはずのバージョンがすでに動いている場合、最初の選択肢は代わりに 引き継ぐ になります。インストーラーは その場所と動作方法をバックアップ、ステータス、次回以降のアップグレードのために記録し、今は何も変更しません。

upgrade も 2 つ目の選択肢を除いて同じ選択肢を示し、引き継げるものがなければ中止します。無人実行では install はメッセージを出して中止し、 upgrade --yes は引き継げるインストールがちょうど 1 つ見つかった場合にのみ引き継ぎます。Kubernetes のリリースの現在の values は installer.json の隣に保存され、アップグレードでは新しいバージョンのチャートと一緒に再適用されます。

アップグレード

ansibleforms-installer upgrade は、インストールを同じメジャーバージョン内の新しいバージョンに移行します。新しいバージョンを 新しい順に一覧表示し（無人実行では最新を選びます）、通過するすべてのバージョンのリリースノートを、互換性のない変更と 削除を先頭にして表示します。互換性のない変更が含まれている場合は、読んだことの確認を求めます。無人実行では --yes がある場合にのみ続行します。

インストーラーは何かを変更する前にデータベースをバックアップします。新しいバージョンが応答しない場合はロールバックを提案します。前の バージョンに戻り、データベースはそのバックアップから復元されます。ダウングレードはせず、メジャーバージョンもまたぎません。その場合は アップグレードガイド に従ってください。たとえば 6.x から 7.x へのアップグレードでは、アップグレード前に 6.5 で行うべきことも説明しています。

Docker または Podman では、コントローラーのアップグレードでファイルも docker リポジトリの新しいバージョンに合わせて更新されます。

ファイル アップグレードでの処理
docker-compose.yml installer-backups にコピーを保存した後、新しいバージョンのものに置き換えます
.env 既存の行はすべて残し、新しいバージョンに必要なキーを追加します。シークレットは新規インストールと同じように作成します。先にコピーを保存します
data/seed.yaml docker リポジトリが配布したシードが変更されていなければ置き換えます。手動で変更したものは残し、新しいものをその隣に保存します
data/ 新しいプレイブックなど、そのバージョンで追加されたファイルを追加します。既存のファイルはすべて残します

データベースの設定（ MYSQLDB_USER やパスワード）が欠けている場合、既存のデータベースに対して作り出すことはできないため、アップグレードは 何も変更する前に中止します。ロールバックでは compose ファイル、 .env 、シードが元に戻ります。

ランナーはその AnsibleForms と同じバージョンで動作します。先に AnsibleForms をアップグレードし、次にそのランナーをアップグレードしてください。ランナーのアップグレードでは 新しい RTE イメージ用に compose ファイルを書き換え、 .env とデータはそのまま残します。

7.2 のランナー

7.2 のランナーは、7.3.0 以降非推奨のデータベースモードで動作します。その RTE は AnsibleForms のデータベース設定を持っています。インストーラーは これを見つけ（ 既存のインストール を参照）、アップグレードで同じランナーのままソケットモードに移行します。

  1. 古い RTE コンテナーからランナーの名前（ RTE_NAME ）とトークン（ RTE_TOKEN ）を読み取ります。RTE が自分自身を登録していなかった場合 （ RTE_REGISTER=0 ）は、 接続 > ランナー でのランナー名を入力します
  2. アプリのアドレスとモード（既定は アウトバウンド 、またはインバウンド）を質問し、インバウンドの場合はポートとこのサーバーのアドレスも質問します
  3. 計画を表示し、古い compose ファイルと .env を installer-backups にバックアップします
  4. DB_* の設定を含まない、インストーラーのランナーのレイアウトを書き込みます。ソケットモードの RTE も読み取る RTE_MAX_JOBS 、 RTE_DRAIN_SECONDS 、 PROCESS_MAX_BUFFER 、 METRICS_TOKEN は残します
  5. 古い RTE の隣で新しい RTE を起動します。新しい RTE はランナー自身のトークンでサインインし、AnsibleForms は自動でランナーを 新しいモードに移行します。 承認は不要 で、そのジョブやそのランナーを指定しているフォームは変わりません
  6. 新しい RTE が接続したら、古いコンテナーを停止して削除します

インバウンドのランナーは、新規のものと同様にピン留めされた証明書で HTTPS を提供し（ ランナー を参照）、インストーラーはその 証明書のフィンガープリントを表示します。新しい RTE が必要とするポートを古い RTE が使っている場合は先に古い RTE を停止するため、新しい RTE が 接続するまでランナーはオフラインになります。アウトバウンドのランナーの新しい RTE は 127.0.0.1 の空いているポートを使い、古い RTE と並行して動くので途切れません。

インストーラーが古い RTE からトークンを読み取れない場合は、新しい RTE のサインイン方法を選びます。

選択肢 その後の流れ
ランナーのトークンを入力する 接続 > 認証情報 にあるランナーの RTE 認証情報のパスワードです。ランナーの名前とジョブはそのまま残ります
参加トークンで新しいランナーとして参加する 参加トークン で別の名前の新しいランナーを追加します。古いランナーは手動で廃止してください

新しい RTE が接続しない場合、インストーラーは古いファイルを戻して古いコンテナーを再起動することを提案します。AnsibleForms がすでに ランナーを移行していた場合は、 接続 > ランナー でモードをデータベースに戻してください。新しい RTE が接続した後は 元に戻せません。古いファイルは installer-backups に残ります。

AnsibleForms がその名前のランナーを知らない場合、新しい RTE は代わりに参加を求めて承認を待ちます。その要求を 接続 > ランナー で拒否し、そこでのランナー名を指定してもう一度アップグレードを実行してください。

バージョン

インストーラーのバージョンはアプリのバージョンに従います。AnsibleForms の各リリースには同じバージョンのインストーラーが一緒にリリースされ、 そのインストーラーは既定でそのバージョンをインストールします。 --version で別のバージョンをインストールできます。 インストーラーの Releases ページ にあるすべてのリリースには、amd64 と arm64 の Linux 用バイナリと チェックサムが含まれています。