Docker ja JP
ASFは、 docker container として利用可能です。 ドッカーパッケージは現在、 ghcr.io および Docker Hub で入手できます。
Docker コンテナで ASF を実行することは高度なセットアップと見なされる点に注意してください。これは大多数のユーザーには不要であり、通常はコンテナを使用しないセットアップに比べて利点もありません。 ASF をサービスとして実行する手段として Docker を検討している場合、たとえば OS と一緒に自動起動させたい場合は、代わりに 管理セクションを読み、適切な systemd サービスを設定することを検討してください。その方が、Docker コンテナで ASF を実行するよりもほぼ常に良い方法です。
DockerコンテナでASFを実行するには、通常、 いくつかの新しい問題と 問題があります。 そのため、Docker の知識がすでにあり、その内部の仕組みを理解するための助けを必要としていない場合を除き、これを避けることを強くおすすめします。Docker の内部については、この ASF wiki では詳しく説明しません。 このセクションは、主に非常に複雑なセットアップの妥当なユースケース向けです。たとえば、高度なネットワークや、ASF に同梱されている systemd サービスの標準サンドボックス化を超えるセキュリティに関する場合です（このサービスは、非常に高度なセキュリティ機構により、すでに優れたプロセス分離を実現しています）。 少数の人々のために、ここではDocker互換性に関してより良いASFの概念を説明します。 ASFと一緒に使う場合は、Dockerの知識を十分に持っているとみなされます。
ASFは、いくつかのタイプの タグ で利用できます:
メイン ブランチ内の最新のコミットからビルドされた ASF の一般的なビルド。 CI パイプラインから直接最新のアーティファクトを取得するのと同じです。 これは、開発目的で開発者や上級ユーザー専用の最高レベルのバグのソフトウェアです。 イメージは メイン GitHub ブランチ内の各コミットで更新されています。 したがって、あなたは非常に頻繁に変化を期待することができます (そして、物事が壊れている)。 ASFプロジェクトの現在の状態をマークするためにここにあります。 リリースサイクルで指摘されたように、必ずしも安定しているわけではありません。 このタグは、本番環境 では使用しないでください。 特定のコミットが発生した問題を修正しているかどうかを検証するのに役立ちます。そのコミットのプレリリースを待たずに。
プレリリースを含む最新の ASFバージョンを常に指すASFの一般的なビルド。 メインの タグと比較すると、新しいGitHubタグがプッシュされるたびに画像が更新されています。 安定していると同時に新鮮であると考えることができるものの端に住むことを愛する高度な/パワーユーザーに専念。 実際には、プル時に最新の A.B.C.D リリースを指すローリングタグと同じように動作します。 このタグを使用することは、 プリリリース を使用することと等しいことに注意してください。
常に最新の stable ASFバージョンを指すASFの一般的なビルド。 がリリースした タグと比較して、新しい安定版の ASF が利用可能になると、ここでの画像が更新されています。 安定した を探している人には、上記の タグをリリースしました。
常に最新の stable ASFバージョンを指すOS固有のビルド。 他のタグと比較して、これは ASF の自動更新を含む唯一のタグです。 このタグの目的は、ASFのOS固有のビルドで自己更新を実行できる正常なデフォルトのDockerコンテナを提供することです。 そのため、画像をできるだけ頻繁に更新する必要はありません。 ASFバージョンは、必要に応じて常にアップデートすることができます。
もちろん、UpdatePeriod は安全に無効化できます（0 に設定）。ただし、この場合は代わりに stable リリースを使用するべきでしょう。 同様に、プリリリースを追跡するために、デフォルトの UpdateChannel を変更することができます。
latest イメージには自動更新機能が備わっているため、OS 専用の linux ASF バージョンを含む最小限の OS が含まれています。これは、.NET ランタイムを含む OS と generic ASF バージョンを含む他のすべてのタグとは異なります。 これは、新しい(更新された)ASFバージョンでは、イメージがビルドされる可能性のあるものよりも新しいランタイムが必要になる可能性があるためです。 それ以外の場合は、計画されたユースケースを無効にするために、ゼロから再構築する必要があります。
タグに一致する固定ASFバージョンを指し示すASFの一般的なビルド。 上記のタグと比較して、このタグは完全に凍結されているため、公開されると画像は更新されません。 これは最初のリリース後には触れられないGitHubリリースと同様に動作し、安定した環境と凍結した環境を保証します。 通常、特定の ASF リリースを使用し、ビルドの決定論的な結果を期待する場合は、このタグを使用する必要があります。 を選択します。
それはあなたが探しているものによって異なります。 大多数のユーザーにとって、 最新の タグは、ASF のデスクトップを正確に提供する最高のタグでなければなりません サービスとして特別なDockerコンテナで。 しかし、これは必ずしもdockerがどのように使用されるべきかではありません - 通常はコンテナを再構築し、それらを永久に実行しないことが期待されます。 そしてこの場合、 stable または は docker のガイドラインに従ってリリースされた タグを考慮する必要があります。 最後に、固定ASFバージョンを代わりに実行したい場合は、当然 A.B.C.D リリースが求められています。
メイン ビルドを試すことは、通常、これらのビルドはASFプロジェクトの現在の状態をマークするためにここにあります。 そのような状態が正常に動作することを保証するものはありません もちろんASF開発に興味があるなら、ぜひお試しください。
ASF Docker イメージは現在、linux プラットフォームを対象として、x64、arm、arm64 の 3 つのアーキテクチャ向けにビルドされています。 これらについて詳しくは、**互換性**セクションで確認できます。
私たちのタグはマルチプラットフォームマニフェストを使用しています。 つまり、マシンにインストールされている Docker は、イメージをプルする際にプラットフォームに適したイメージを自動的に選択します。 特定のプラットフォームイメージを引き出したい場合は、現在実行しているものと一致しません。 --platform スイッチを介して適切な docker コマンド ( docker run など) を切り替えることができます。 詳細については、 イメージ manifest の docker documentation を参照してください。
完全な参照のためには、 **公式docker docker**を使用する必要があります。 このガイドでは基本的な使い方だけをカバーしますあなたはもっと深く掘り下げるのを歓迎します。
まず、dockerが正しく動作しているかどうかを確認する必要があります。これはASFの「こんにちは世界」として機能します：
docker run -it -name asf --pull always --rm justarchi/archisteamfardocker run は新しいASFドッカーコンテナを作成し、フォアグラウンド(-it)で実行します。 --pull always は、まず最新のイメージが取得されるようにし、--rm は、今はすべてが正常に動作するかをテストしているだけなので、停止後にコンテナが削除されるようにします。
すべてのレイヤーを引っ張ってコンテナを開始した後、すべてが正常に終了した場合。 ASFが適切に起動し、定義されたボットがないことを私たちに知らせる必要があります。 これは良いことです - 私たちはdockerでASFが正しく動作することを確認しました。 CTRL+C を押すとASFプロセスが終了し、したがってコンテナも終了します。
コマンドを詳しく見てみると、タグが宣言されていないことがわかります。 これは自動的に 最新の をデフォルトにしました。 latest以外のタグを使用する場合は、例えば がリリースされたを使用し、明示的に宣言する必要があります。
docker run -it -name asf --pull always --rm justarchi/archisteamfarm:releaseddocker containerでASFを使用している場合は、明らかにプログラム自体を設定する必要があります。 様々な方法で行うことができます しかし、推奨されるのは、ローカル マシン上に ASF config ディレクトリを作成することです。 次に、ASFドッカーコンテナに共有ボリュームとしてマウントします。
例えば、ASF config フォルダーが /home/archi/ASF/config ディレクトリにあるとします。 このディレクトリには、コア ASF.json と実行したいボットが含まれています。 今、私たちがする必要があるのは、単に docker コンテナー内の共有ボリュームとしてそのディレクトリを追加するだけです。 ここでASFはconfigディレクトリを期待します (/app/config).
docker run -it -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarmこれで、ASFドッカーコンテナは読み書きモードでローカルマシンと共有ディレクトリを使用します。 ASFを構成するために必要なものはすべてこれです。 同様に、 /app/logs や /app/plugins など、ASFと共有したいボリュームをマウントすることができます。
もちろん、これは私たちが望むことを達成するための唯一の特定の方法です。例えば、あなたを停止させるものはありません。 独自の Dockerfile を作成すると、ASF docker container内の設定ファイルが /app/config ディレクトリにコピーされます。 このガイドでは基本的な使い方について説明しています。
ASF コンテナはデフォルトで root ユーザーとして初期化されます。これにより内部の権限関連処理を行い、その後、最終的にメインプロセスの残りの部分を asf（UID 1000）ユーザーに切り替えて実行できます。 これは大多数のユーザーにとって満足すべきですが。 新しく生成されたファイルは通常、 asf ユーザーが所有するため、共有ボリュームに影響します。 共有ボリュームの他のユーザーを望んでいる場合は望ましくないかもしれません。
ASFが実行しているユーザーを変更するには、2つの方法があります。 1 つ目の推奨される方法は、実行したい対象 UID を指定して ASF_UID 環境変数を宣言することです。 第二に、代替案として、 --user **フラグ**を渡します。これはdockerが直接サポートしています。
例えば、 uid コマンドを id -u コマンドでチェックし、上記で指定したように宣言することができます。 例えば、ターゲットユーザーが 1001 の uid を持っている場合:
docker run -it -e ASF_UID=1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm
# または、以下の制限を理解している場合
docker run -it -u 1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarmASF_UID と --user フラグの違いは微妙ですが、重要です。 ASF_UID は ASF がサポートする独自の仕組みです。このシナリオでは Docker コンテナは引き続き root として起動し、その後 ASF の起動スクリプトが ASF_UID の下でメインバイナリを起動します。 --user フラグを使用する場合は、指定されたユーザーとしてASF起動スクリプトを含むプロセス全体を開始します。 最初のオプションでは、ASFの起動スクリプトが自動的に権限やその他の要素を処理し、発生した一般的な問題を解決することができます。 例えば、 /app と /asf ディレクトリが実際に ASF_UID によって所有されていることを保証します。 2つ目のシナリオでは、 rootとして実行していないので、 我々はそれを行うことはできませんそして、あなたは事前にすべてのことを自分で処理する必要があります。
--user フラグを使用することにした場合は、すべての ASF ファイルの所有者をデフォルトの 1000 から新しいカスタムユーザーに変更する必要があります。 以下のコマンドを実行することで可能です:
# ASF_UID を使用していない場合のみ実行してください
docker exec -u root asf_container_name chown -hR 1001 /app /asfこれは、docker run でコンテナを作成した後に一度だけ実行する必要があります。また、--user Docker フラグを使ってカスタムユーザーを使用することにした場合にのみ必要です。 また、上記コマンドの 1001 引数を実際にASFを実行したい UID に変更することを忘れないでください。
お使いのOSでSELinuxを強制状態で使用している場合、たとえばRHELベースのdistrosのデフォルトです。 次に、 :Z オプションを追加するボリュームをマウントします。このオプションは、それに対して正しいSELinuxコンテキストを設定します。
docker run -it -v /home/archi/ASF/config:/app/config:Z ---name asf --pull always justarchi/archisteamfarm
これにより、ASFはdockerコンテナ内でボリュームを取得している間にファイルを作成できます。
ASF は、管理 セクションに記載されているように、複数インスタンスの同期をサポートしています。 docker containerでASFを実行する場合、プロセスにオプションで「オプトイン」することができます。 ASFを使用して複数のコンテナを実行していて、それらが相互に同期するようにしたい場合。
デフォルトでは、Dockerコンテナ内で実行される各ASFはスタンドアロンであるため、同期は行われません。 同期を有効にするには、同期するすべてのASFコンテナに /tmp/ASF パスをバインドする必要があります。 読み書きモードで、docker hostの共有パスを1つに設定します。 これは、異なるパスを使用して、上記のボリュームをバインディングするのとまったく同じです。
mkdir -p /tmp/ASF-g1
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/archi/ASF/config:/app/config -name asf1 --pull always justarchi/archisteamfar
docker run -v /tmp/ASF-g1:/tmp/asF -v /home/john/config:/app/config ---name asf2 -pull justamfar
# など。 すべてのASFコンテナが互いに同期されるようになりましたASFの /tmp/ASF ディレクトリをあなたのマシンの一時的な /tmp ディレクトリにバインドすることをお勧めします。 もちろん自由に使えるものを選べます 同期されると予想される各ASFコンテナは、同期プロセスに参加している他のコンテナと共有される /tmp/ASF ディレクトリを持つ必要があります。
上記の例から推測したように、2つ以上の「同期グループ」を作成することも可能です。 異なるdocker hostのパスをASFの /tmp/ASF にバインドすることで。
/tmp/ASF のマウントは完全に任意であり、2 つ以上の ASF コンテナを同期させる場合を除き、実際には推奨されません。 単一コンテナでの使用には、 /tmp/ASF のマウントはお勧めしません。 ASFコンテナを1つだけ動かせば利益はありません そうしなければ避けられる問題を引き起こすかもしれません
ASF では、環境変数を通じて Docker コンテナー内で コマンドライン引数 を渡すことができます。 サポートされているスイッチには特定の環境変数を、残りのスイッチには ASF_ARGS を使用する必要があります。 これは、 -e スイッチを docker runに追加することで実現できます。例えば、
docker run -it -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--no-config-migrate" -name asf --pull always justarchi/archisteamfarmこれはdocker container内で実行されているASFプロセスに、他の引数と同様に、あなたの --cryptkey 引数を適切に渡します。 もちろん、上級ユーザーであれば、 ENTRYPOINT を変更したり、 CMD を追加して、自分でカスタム引数を渡すこともできます。
カスタム暗号化キーやその他の高度なオプションを指定したい場合を除き、通常は特別な環境変数を含める必要はありません。私たちの Docker コンテナは、妥当なデフォルトオプションとして --no-restart で実行されるようにすでに設定されているため、このフラグを ASF_ARGS で明示的に指定する必要はありません。
IPC の グローバル設定プロパティ の既定値を変更していない場合、これはすでに有効になっています。 ただし、IPCがDockerコンテナで動作するようにするには、さらに2つのことを行う必要があります。 まず、外部から接続できるようにするには、IPCPassword を使用するか、カスタム IPC.config でデフォルトの KnownNetworks を変更する必要があります。 実際に何をしているのかわからない限り、 IPCPassword を使ってください。 第二に、docker が外部トラフィックを loopback インターフェイスにルーティングできないため、 localhostのデフォルトのリスニングアドレスを変更する必要があります。 すべてのインターフェイスでリッスンする設定の例は、 http://*:1242 です。 もちろん、ローカルLANやVPNネットワークなどの制限付きバインディングを使用することもできます。 しかし、外部からアクセス可能なルートである必要があります - localhost は行いません。 ルートは完全にゲストマシンの中にある
上記を行うには、以下のような**カスタム IPC 設定**を使用する必要があります：
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}非ループバックインターフェイスにIPCを設定したら、次にIPCを設定します。 ASFの 1242/tcp ポートを -P または -p スイッチでマッピングするよう、ドッカーに指示する必要があります。
たとえば、このコマンドはASFのIPCインターフェイスをホストマシンに公開します(以下のように)。
docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 -name asf --pull always justarchi/archisteamfarmすべてを適切に設定していれば、上記の docker run コマンドにより、ホストマシンから**IPC**インターフェースを標準の localhost:1242 ルートで利用できるようになります。このルートは現在、ゲストマシンへ適切にリダイレクトされています。 このルートをさらに公開しないことにも注意してください。 接続はドッカーホスト内でのみ行えるので安全に保つことができます もちろん、あなたが何をしているかを知っていて、適切なセキュリティ対策を確保すれば、ルートをさらに公開することができます。
上記の全知識を組み合わせると、完全なセットアップの例は次のようになります。
docker run -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 -v /home/archi/ASF/config:/app/config -v /home/archi/ASF/plugins:/app/plugins --name asf --pull always --restart unless-stoped justarchi/archistamfarこれは、すべての ASF 設定ファイルが /home/archi/ASF/config に含まれる単一の ASF コンテナを使用することを前提としています。 マシンに一致する設定パスを変更してください。 /home/archi/ASF/plugins に入れることができるASF用のカスタムプラグインを提供することもできます。 このセットアップは、以下のような内容の IPC.config を config ディレクトリに含めることにした場合、任意で IPC を使用する準備もできています：
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}以下の docker compose 設定を使用すると、上記の docker run コマンドと同じ効果を得ることができます。
version: "3.8"
services:
asf:
image: justarchi/archisteamfarm
container_name: asf
restart: unless-stopped
ports:
- "127.0.0.1:1242:1242"
- "[::1]:1242:1242"
volumes:
- /home/archi/ASF/config:/app/config
- /home/archi/ASF/plugins:/app/plugins我々はすでに上で議論した以外の事柄から。 上記の両方の例に --restart が停止していない を追加し、マシンの再起動後にこのコンテナを自動的に起動します。 あなたのニーズに合わせて自由に取り外し/変更してください。
ASFドッカーコンテナの準備ができている場合は、毎回 dockerを 使用する必要はありません。 docker stop asf と docker start asf で、ASF docker container を簡単に停止/起動できます。 latest タグを使用していない場合、ASF を最新の状態で使用するには、引き続き docker stop、docker rm、docker run を再度実行する必要があることに注意してください。 これは、そのイメージに含まれるASFバージョンを使用するたびに、新鮮なASFドッカーイメージからコンテナを再構築する必要があるためです。 最新の タグには、ASF に自動更新機能が含まれています。 したがって、最新のASFを使用するためにイメージを再構築する必要はありません(しかし、新鮮なものを使用するためには、時々それを行うことは良い考えです。 ETランタイムの依存関係と基礎となるOSは、主要なASFバージョンアップデートをジャンプする際に必要になる可能性があります。
上記で示したように、latest 以外のタグの ASF は自動更新されません。つまり、あなたが最新の justarchi/archisteamfarm リポジトリを使用する責任を負うことになります。 これは通常、アプリケーションが実行されるときに独自のコードに触れるべきではないので、多くの利点があります。 しかし、我々はまた、便利を理解していますあなたのドッカーコンテナ内のASFバージョンを心配する必要がないからです。 適切な慣行や正しい Docker の使い方を重視するなら、released タグを latest の代わりに使用することをおすすめします。ただし、そこまで気にせず、ASF を動作させつつ自動更新もさせたいだけであれば、latest で十分です。
通常、 ヘッドレス: true グローバル設定で、docker containerでASFを実行する必要があります。 これは明らかにあなたが欠けている詳細を提供するためにここにいるのではなく、それらを求めるべきではないことをASFに伝えます。 もちろん、初期セットアップでは簡単に設定できるよう、このオプションを false のままにしておくことを検討するべきです。ただし、長期的には通常 ASF コンソールに接続したままにはしないため、そのことを ASF に知らせておき、必要が生じた場合は input **コマンド**を使用するのが理にかなっています。 このようにしてASFは発生しないユーザー入力を無限に待つ必要はありません(そしてそうすることでリソースを無駄にします)。 また、コンテナ内の非対話モードでASFを実行することもできます。これは例えば重要です。 転送信号に関しては、ASFが docker asf リクエストを正常に閉じることが可能になります。
