Docker de DE

Docker

ASF ist als Docker Container verfügbar. Our docker packages are currently available on ghcr.io as well as Docker Hub.

Es ist wichtig zu beachten, dass ASF im Docker Container als erweitertes Setup angesehen wird, was für die überwiegende Mehrheit der Benutzer nicht benötigt wird und gibt in der Regel keine Vorteile gegenüber einer containerlosen Einrichtung. Wenn Sie Docker als eine Lösung für den Betrieb von ASF als Dienst betrachten, zum Beispiel indem Sie ihn automatisch mit Ihrem Betriebssystem starten, dann sollten Sie möglicherweise stattdessen den Abschnitt Verwaltung lesen, und einen korrekten systemd Dienst einrichten, der fast immer eine bessere Lösung ist, als ASF in einem Docker Container auszuführen.

Die Ausführung von ASF im Docker-Container beinhaltet in der Regel mehrere neue Probleme und Probleme, die Sie selbst bewältigen und lösen müssen. Aus diesem Grund empfehlen wir Ihnen sehr dies zu vermeiden; es sei denn, Sie haben bereits Docker-Kenntnisse und benötigen keine Hilfe beim Verständnis seiner internen Daten, über die wir hier im ASF Wiki nicht eingehen. Dieser Abschnitt ist hauptsächlich für gültige Anwendungsfälle sehr komplexer Setups. Zum Beispiel in Bezug auf erweiterte Vernetzung oder Sicherheit über Standard-Sandboxing hinaus, die ASF im systemd Dienst beinhaltet (der bereits eine überlegene Prozessisolierung durch sehr fortgeschrittene Sicherheitsmechanismen sicherstellt). Für diese wenigen Nutzer erklären wir hier bessere ASF-Konzepte in bezüglich der Docker-Kompatibilität und nur das. Voraussetzung ist, dass Sie selbst über adäquate Docker Kenntnisse verfügen, wenn Sie sich dafür entscheiden, es zusammen mit ASF zu verwenden.

Welcher Tag ist für mich der Beste?

Das hängt davon ab, wonach Sie suchen. Für die Mehrheit der Benutzer sollte das latest Tag das Beste sein, da es genau das bietet, was Desktop-ASF bietet, nur eben als Dienst in einem speziellen Docker-Container. Nutzer, die Ihre Images oft neu erstellen und stattdessen lieber die volle Kontrolle über die ASF-Version haben, die an diese Veröffentlichung gebunden ist, können das released Tag verwenden. Wenn Sie stattdessen eine bestimmte eingefrorene ASF-Version verwenden möchten, die sich ohne Ihre eindeutige Absicht nie ändern wird, stehen Ihnen A.B.C.D Versionen als feste ASF-Meilensteine zur Verfügung, auf die Sie immer zurückgreifen können.

Wir raten generell davon ab, main Builds auszuprobieren, da diese für uns hier sind, um den aktuellen Stand des ASF-Projekts zu kennzeichnen. Nichts garantiert, dass ein solcher Zustand ordnungsgemäß funktioniert, aber natürlich können Sie ihn gerne ausprobieren, wenn Sie an der ASF-Entwicklung interessiert sind.

Architekturen

ASF Docker Image (Abbild) ist derzeit auf Linux Plattform für 3 Architekturen verfügbar – x64, arm und arm64. Sie können im Abschnitt Kompatibilität mehr darüber lesen.

Unsere Tag(s) verwenden das Multi-Plattform-Manifest, was bedeutet, dass Docker auf Ihrem Gerät automatisch das passende Image (Abbild) für Ihre Plattform auswählt, wenn Sie dieses herunterladen. Wenn Sie ein bestimmtes Plattform-Image (Abbild) beziehen möchten, welches nicht dem entspricht, das Sie gerade verwenden, können Sie dies mittels --platform in den geeigneten Docker-Befehlen erreichen, wie zum Beispiel Docker run. Mehr Informationen hierzu finden Sie in der Docker Dokumentation unter image manifest.

Nutzung

Für eine vollständige Referenz sollten Sie die offizielle Docker-Dokumentation verwenden. Wir werden in diesem Leitfaden nur die grundlegende Anwendung behandeln. Sie sind herzlich dazu eingeladen, Ihr Wissen zu vertiefen.

Hallo ASF!

Zuallererst sollten wir überprüfen, ob unser Docker momentan überhaupt funktioniert. Das wird als unser ASF „Hallo Welt“ dienen:

docker run -it --name asf --pull always --rm justarchi/archisteamfarm

docker run erstellt einen neuen ASF Docker-Container für Sie und führt ihn im Vordergrund aus (-it). --pull always sorgt dafür, dass das aktuelle Image (Abbild) zuerst bezogen und --rm stellt sicher, dass unser Container nach dem Stoppen gereinigt wird, da wir gerade testen, ob alles im Moment gut funktioniert.

Wenn alles erfolgreich geendet hat, nachdem Sie alle Schichten und den Start-Container geholt haben, sollten Sie feststellen, dass ASF richtig gestartet wurde und uns mitgeteilt hat, dass es keine definierten Bots gibt; was gut ist – wir haben verifiziert, dass ASF im Docker richtig funktioniert. Hit CTRL+C to terminate the ASF process and therefore also the container.

Wenn Sie sich den Befehl genauer ansehen, werden Sie feststellen, dass wir kein Tag deklariert haben, da es automatisch auf latest voreingestellt ist. Sofern Sie ein anderes Schlagwort als latest verwenden möchten, zum Beispiel released, dann sollten Sie es explizit erklären:

docker run -it --name asf --pull always --rm justarchi/archisteamfarm:released

Verwendung eines Volumes (Laufwerk)

Wenn Sie ASF im Docker-Container verwenden, dann müssen Sie natürlich das Programm selbst konfigurieren. Sie können es auf verschiedene Weise erreichen, aber die empfohlene wäre, das ASF config Verzeichnis auf dem lokalen Geräte zu erstellen und es dann als gemeinsames Volume (Laufwerk) im ASF-Docker-Container zu mounten.

Zum Beispiel gehen wir davon aus, dass sich Ihr ASF-Konfigurationsordner im Verzeichnis /home/archi/ASF/config befindet. Dieses Verzeichnis enthält den Kern ASF.json sowie Bots, die wir ausführen möchten. Jetzt müssen wir nur noch dieses Verzeichnis als Shared Volume (gemeinsames Laufwerk) in unserem Docker-Container anhängen, wo ASF sein Konfigurationsverzeichnis erwartet (/app/config).

docker run -it -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

Und das war’s! Jetzt verwendet Ihr ASF-Docker-Container das freigegebene Verzeichnis mit Ihrem lokalen Geräte im Lese-/Schreibmodus, was alles ist, was Sie für die Konfiguration von ASF brauchen. In similar, way you can mount other volumes that you'd like to share with ASF, such as /app/logs or /app/plugins.

Natürlich ist dies nur ein konkreter Weg, um das zu erreichen, was wir möchten. Nichts hält Sie davon ab, z. B. eine eigene Dockerfile zu erstellen, die Ihre Konfigurationsdateien in das Verzeichnis /app/config im ASF Docker-Container kopiert. Wir behandeln in diesem Leitfaden nur die grundlegende Anwendung.

Zugriffsrechte für Volumes

ASF Container wird standardmäßig mit dem Standardbenutzer root initialisiert, die es ihm erlaubt, die interne Berechtigung zu handhaben und schließlich für den verbleibenden Teil des Hauptprozesses zu asf (UID 1000) wechseln. Während dies für die große Mehrheit der Benutzer zufriedenstellend sein sollte; es wirkt sich auf das geteilte Volume (Laufwerk) aus, da neu generierte Dateien normalerweise im Besitz von asf sind. Dies könnte unerwünscht sein, wenn Sie einen anderen Benutzer für Ihr geteiltes Volume (Laufwerk) möchten.

There are two ways you can change the user ASF is running under. The first one, recommended, is to declare ASF_USER environment variable with target UID you want to run under. Second, alternative one, is to pass --user flag, which is directly supported by docker.

You can check your uid for example with id -u command, then declare it as specified above. For example, if your target user has uid of 1001:

docker run -it -e ASF_USER=1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

# Alternatively, if you understand the limitations below
docker run -it -u 1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

The difference between ASF_USER and --user flag is subtle, but important. ASF_USER is custom mechanism supported by ASF, in this scenario docker container still starts as root, and then ASF startup script starts main binary under ASF_USER. When using --user flag, you're starting whole process, including ASF startup script as given user. First option allows ASF startup script to handle permissions and other stuff automatically for you, resolving some common issues that you might've caused, for example it ensures that your /app and /asf directories are actually owned by ASF_USER. In second scenario, since we're not running as root, we can't do that, and you're expected to handle all of that yourself in advance.

If you've decided to use --user flag, you need to change ownership of all ASF files from default asf to your new custom user. You can do so by executing command below:

# Execute only if you're not using ASF_USER
docker exec -u root asf chown -hR 1001 /app /asf

This has to be done only once after you created your container with docker run, and only if you decided to use custom user through --user docker flag. Also don't forget to change 1001 argument in command above to the UID you actually want to run ASF under.

Volume (Laufwerk) mit SELinux

Wenn Sie SELinux im erzwungenen Zustand auf Ihrem Betriebssystem verwenden, ist dies die StandarIhrstellung zum Beispiel für RHEL-basierte Distributionen, dann sollten Sie das Volume (Laufwerk) zusammen mit der Flag :Z einhängen, die den korrekten SELinux Kontext dafür setzt.

docker run -it -v /home/archi/ASF/config:/app/config:Z --name asf --pull always justarchi/archisteamfarm

Dies erlaubt ASF Dateien zu erstellen, die das Volume (Laufwerk) im Docker-Containers anvisieren.

Synchronisation mehrerer Instanzen

ASF unterstützt die Synchronisation mehrerer Instanzen, wie im Abschnitt Verwaltung erläutert. Beim Ausführen von ASF im Docker-Container, können Sie optional „opt-in“ in den Prozess einschalten für den Fall, dass Sie mehrere Container mit ASF (synchronisiert) verwenden möchten.

Standardmäßig ist jede ASF in einem eigenständigen Docker-Container und das bedeutet, dass keine Synchronisation stattfindet. Um die Synchronisation zwischen Ihnen zu aktivieren, müssen Sie den Pfad /tmp/ASF in jedem ASF Container, den Sie synchronisieren möchten, zu einem gemeinsamen Pfad (im Lese-Schreib-Modus) des Docker-Hosts einbinden. Dies wird genauso wie bei der Bindung eines Volumes (Laufwerk) erreicht (wie oben erläutert), nur mit verschiedenen Pfaden:

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/archisteamfarm
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/john/ASF/config:/app/config --name asf2 --pull always justarchi/archisteamfarm
# Und so weiter, alle ASF Container sind jetzt miteinander synchronisiert

Wir empfehlen das ASF-Verzeichnis /tmp/ASF auch an ein temporäres /tmp Verzeichnis auf Ihrem Rechner zu binden, aber Sie können natürlich jedes andere wählen, die Ihren Zweck erfüllt. Jeder ASF-Container, der synchronisiert werden soll, sollte sein /tmp/ASF Verzeichnis mit anderen Containern teilen, die am gleichen Synchronisierungsprozess teilnehmen.

Wie Sie vermutlich am Beispiel oben erraten haben, ist es auch möglich, zwei oder mehr „Synchronisierungsgruppen“ zu erstellen, indem Sie verschiedene Docker Host-Pfade in ASFs /tmp/ASF einbinden.

Das Einbinden von /tmp/ASF ist komplett optional und aktuell nicht empfehlenswert, es sei denn, Sie möchten explizit zwei oder mehr ASF-Container synchronisieren. Wir raten davon ab, /tmp/ASF für den Einsatz mit einem Container einzubinden, da es absolut keine Vorteile bringt, wenn Sie nur einen ASF-Container laufen lassen möchten, und es könnte tatsächlich zu Problemen führen, die sonst Vermeidbar wären.

Befehlszeilenargumente

ASF erlaubt es Ihnen Befehlszeilenargumente in Docker-Containern durch Umgebungsvariablen weiterzugeben. Sie sollten spezifische Umgebungsvariablen für die unterstützten Schalter verwenden und für den Rest ASF_ARGS. Dies kann mit dem Schalter -e erreicht werden, der zum Docker Run hinzugefügt wurde; zum Beispiel:

docker run -it -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--no-config-migrate" --name asf --pull always justarchi/archisteamfarm

Dies wird sowohl das Argument --cryptkey korrekt an den ASF-Prozess übergeben, der im Docker-Container ausgeführt wird, als auch andere Argumente. Falls Sie ein fortgeschrittener Benutzer sind, können Sie natürlich auch den ENTRYPOINT bearbeiten oder eine CMD hinzufügen und Ihre Argumente selbst übergeben.

Sofern Sie keinen benutzerdefinierten Verschlüsselungsschlüssel oder andere erweiterte Optionen bereitstellen möchten, müssen Sie in der Regel keine speziellen Umgebungsvariablen einfügen, da unsere Docker-Container bereits so konfiguriert sind, dass sie mit einer vernünftig erwarteten Standardoption ausgeführt --no-restart --process-required und --system-required; sodass diese Flags nicht explizit in ASF_ARGS angegeben werden müssen.

IPC

Angenommen, Sie haben den Standardwert für IPC globale Konfigurationseigenschaft nicht geändert, ist diese bereits aktiviert. Allerdings müssen Sie zuvor zwei zusätzliche Dinge erledigen, damit IPC im Docker Container funktioniert. Zuerst müssen Sie IPCPassword verwenden oder das standardmäßige KnownNetworks in der benutzerdefinierten IPC.config bearbeiten, um eine Verbindung von außen ohne Verwendung zu ermöglichen. Wenn Sie nicht wirklich wissen, was Sie tun, verwenden Sie einfach IPCPassword. Darüber hinaus müssen Sie die Standard-Abhöradresse von localhost ändern, da Docker keinen externen Traffic (Verkehr) an die Loopback-Schnittstelle umleiten kann. Ein Beispiel für eine Einstellung, die auf allen Schnittstellen lauscht, wäre http://*:1242. Natürlich können Sie auch restriktivere Bindungen verwenden, etwa nur lokales LAN oder VPN-Netzwerk, aber es muss eine von außen zugängliche Route sein; localhost reicht nicht aus, da die Route vollständig innerhalb des Gastcomputers liegt.

Um das oben Gesagte zu erreichen, sollten Sie eine benutzerspezifische IPC-Konfiguration verwenden, wie die untenstehende:

{
 "Kestrel": {
  "Endpoints": {
   "HTTP": {
    "Url": "http://*:1242"
   }
  }
 }
}

Sobald wir IPC auf einer Nicht-Loopback-Schnittstelle eingerichtet haben, ist es notwendig Docker mitzuteilen, dass er den ASF-Port 1242/tcp (entweder mit dem Schalter -P oder -p) zuordnen soll.

Dieser Befehl würde die ASF-IPC-Schnittstelle beispielsweise (nur) zum Host-Computer freigeben:

docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 --name asf --pull always justarchi/archisteamfarm

Wenn Sie alles richtig eingestellt haben, wird der oben gezeigte docker run Befehl das IPC Interface von Ihrem Host-Computer aus auf der Standardroute localhost:1242 laufen lassen, die nun korrekt auf Ihre Gast-Maschine umgeleitet wird. Es ist auch gut zu wissen, dass wir diese Route nicht weiter offenlegen, sodass die Verbindung nur innerhalb des Docker-Hosts erfolgen kann und somit sicher bleibt. Natürlich können Sie die Route tiefer freigeben, sofern Sie wissen, was Sie tun, und für entsprechende Sicherheitsmaßnahmen sorgen.

Vollständiges Beispiel

Wenn man das gesamte obige Wissen kombiniert, würde ein Beispiel für ein komplettes Setup so aussehen:

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 justarchi/archisteamfarm

Dies setzt voraus, dass Sie einen einzigen ASF-Container mit allen ASF-Konfigurationsdateien in /home/archi/ASF/config verwenden. Sie sollten den Konfigurationspfad zu dem ändern, der zu Ihrem Rechner passt. Es ist auch möglich, eigene Erweiterungen für ASF bereitzustellen, indem Sie diese in /home/archi/ASF/plugins Einfügen. Dieses Setup ist auch für die optionale IPC-Nutzung bereit, wenn Sie sich entschieden haben, IPC.config in Ihr Konfigurationsverzeichnis mit einem Inhalt wie unten erläutert aufzunehmen:

{
 "Kestrel": {
  "Endpoints": {
   "HTTP": {
    "Url": "http://*:1242"
   }
  }
 }
}

Profi-Tipps

Wenn Sie Ihren ASF-Docker-Container bereits startklar haben, müssen Sie nicht jedes Mal docker run verwenden. Sie können den ASF-Docker-Container einfach mit docker stop asf und docker start asf stoppen/starten. Beachten Sie, dass, wenn Sie nicht den latest Tag verwenden, die Verwendung des aktuellen ASF von Ihnen immer noch docker stop und docker rm benötigt wird. Schließlich starten Sie mit docker start erneut. Dies liegt daran, dass Sie Ihren Container jedes Mal aus einem frischen ASF-Docker-Image neu erstellen müssen, wenn Sie die in diesem Image (Abbild) enthaltene ASF-Version verwenden möchten. Beim Tag neuestem hat ASF die Fähigkeit eingebaut, sich selbst zu aktualisieren, sodass der Wiederaufbau des Bildes nicht notwendig ist, um die aktuelle ASF zu verwenden (aber es ist immer noch eine gute Idee, es von Zeit zu Zeit zu tun, um .NET Laufzeitabhängigkeiten und das zugrundeliegende Betriebssystem aktuell zu halten, das benötigt werden könnte, wenn Sie wichtige ASF-Versionsupdates überspringen).

Wie oben angedeutet, wird sich ASF in einem anderen Tag als latest nicht automatisch aktualisieren, was bedeutet, dass Sie dafür verantwortlich sind, ein aktuelles justarchi/archisteamfarm Repository zu verwenden. Dies hat viele Vorteile, da die Anwendung typischerweise nicht Ihren eigenen Quellcode berühren sollte, wenn sie ausgeführt wird, aber wir verstehen auch Komfort, der dadurch entsteht, dass Sie sich nicht um die ASF-Version in Ihrem Docker-Container kümmern müssen. Wenn Sie sich um gute Praktiken und die korrekte Verwendung von Dockern kümmern, dann schlagen wir Ihnen den released Tag – anstelle von latest vor; aber wenn Sie sich für ASF lediglich automatische Updates und Funktionalität wünschen, dann reicht latest aus.

Sie sollten ASF typischerweise im Docker-Container mit der globalen Konfiguration Headless: true ausführen. Dies wird ASF klar signalisieren, dass Sie nicht hier sind, um fehlende Details zu liefern und es sollte nicht nach diesen fragen. Natürlich sollten Sie für die Erstkonfiguration in Betracht ziehen, diese Option bei false zu belassen, damit Sie Dinge einfach einrichten können, aber auf lange Sicht sind Sie typischerweise nicht an die ASF-Konsole gebunden, deshalb wäre es sinnvoll, ASF darüber zu informieren und input Befehl zu verwenden, wenn Bedarf entsteht. Auf diese Weise muss ASF nicht ewig auf Benutzereingaben warten, die nicht erfolgen (und dabei Ressourcen verschwenden). Dies ermöglicht es, dass ASF im nicht-interaktiven Modus innerhalb eines Containers ausgeführt werden kann, was entscheidend ist, z. B. in Bezug auf die Weiterleitungssignale, die es ASF ermöglichen, auf Anfrage von docker stop asf angemessen zu schließen.