Docker de DE

Docker

ASF ist als Docker Container verfügbar. Unsere Docker-Pakete sind derzeit auf ghcr.io sowie Docker-Hub verfügbar.

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 Management 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 Service 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 **Tags verwenden das Multi-Plattform-Manifest, was bedeutet, dass Docker auf Ihrem Rechner 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. Drücken Sie CTRL+P, dann STRG+Q um den Vordergrund-Docker-Container zu beenden, dann stoppen Sie den ASF-Container mit docker stop asf.

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

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 wollen. 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. Auf ähnliche Weise können Sie andere Volumes (Laufwerk) einhängen, die Sie mit ASF teilen möchten, wie /app/logs oder /app/plugins/MyCustomPluginDirectory.

Natürlich ist dies nur ein konkreter Weg, um das zu erreichen, was wir wollen. 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.

Docker erlaubt es Ihnen, das --user Flag an den Befehl docker run zu übergeben, der den Standardbenutzer definiert, unter dem ASF ausgeführt wird. Sie können Ihre uid und gid zum Beispiel mit dem Befehl id überprüfen und ihn dann an den Rest des Befehls übergeben. Zum Beispiel, wenn Ihr Ziel-Benutzer die uid und gid von 1001 hat:

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

Bedenken Sie, dass das von ASF verwendete Verzeichnis /app standardmäßig immer noch im Besitz von asf ist. Wenn Sie ASF mit einem benutzerdefinierten Anwender ausführen, hat Ihr ASF-Prozess keinen Schreibzugriff auf seine eigenen Dateien. Dieser Zugriff ist für den Betrieb nicht zwingend erforderlich, aber er ist z. B. für die Funktion Automatische-Aktualisierung entscheidend. Um dies zu beheben, genügt es, den Besitzer aller ASF-Dateien von Standard asf zu Ihren neuen benutzerdefinierten Anwender zu ändern.

docker exec -u root asf chown -hR 1001:1001 /app

Dies muss nur einmal durchgeführt werden, nachdem Sie Ihren Container mit docker run erstellt haben, und nur dann, wenn Sie sich dazu entschieden haben, einen benutzerdefinierten Anwender für den ASF-Prozess zu verwenden. Vergessen Sie auch nicht, das Argument 1001:1001 in beiden obigen Befehlen auf die uid und gid zu ändern, unter dem Sie ASF ausführen möchten.

Volume (Laufwerk) mit SELinux

Wenn Sie SELinux im erzwungenen Zustand auf Ihrem Betriebssystem verwenden, ist dies die Standardeinstellung 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 Management beschrieben. 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 beschrieben), 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 wollen, 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 benutzen 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 werden --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, wie 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 --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. 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 beschrieben 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.