Hardware + Software + Tutorial für Lancache (als VM)?

[besterino]

Hallo zusammen,

Ich werde wohl demnächst mal wieder das Projekt "lancache" angehen - nervt mich inzwischen zu sehr, bei irgendwas um die 6 Gaming-PCs im Fuhrpark jedes Mal alles durch die DSL-Leitung ziehen zu müssen, selbst wenn die eigentlich recht flott ist. Hat jemand evtl. ein gutes Tutorial für Doofe, um einmal alle gängigen Gaming-Plattformen zu erschlagen?

Der Proxy soll idealerweise folgende Services zwischenspeichern:

Steam
Epic Games
Uplay
Origin
Battle.net

Ich muss zu meiner Schande gestehen, dass ich vor Docker noch irgendwie zurückschrecke - habe mich damit bisher nicht wirklich auseinander gesetzt und dieses Zwischenlayer einfach noch nicht wirklich verstanden, so dass ich mich damit noch nicht so wirklich wohl fühle. Vor allem hab ich Sorge, dass ich den Überblick verliere, wenn ich mehrere Services auf einem Host kombiniere und trenne daher Services bereits auf VM-Ebene.

Wollte trotzdem hiermit mal mein Glück versuchen: https://hoerli.net/lancache-der-cache-server-fuer-dein-netzwerk/

Zur Hardware (ist ja hier ein Hardware-Subforum) wollte ich mal 4 Kerne und 8GB veranschlagen - ans Netz angebunden wird das Ding wohl per 10Gbit. Speicherplatz muss ich mal schauen - da kommen ja u.U. schnell mehrere TB zusammen.

Ich gehe mal davon aus, dass ich den DHCP/DNS-Server meiner Fritzbox auch so umbiegen kann, dass der auf die VM zeigt - kann da ja einen alternativen lokalen DNS-Server eintragen.

Thoughts?

 

[oNyX`]

Ich wuerd mich an die offizielle Doku halten https://lancache.net/docs/ abgesehen davon ich mag und trau Docker auch nicht, wuerds in ner extra VM und nicht aufm Host laufen lassen. Was mich bisher davon abgehalten hat ist deren DNS Server, trau ich nicht und ist mit Abstand das kritischste im Netzwerk.

 

[Ceiber3]

Dann wird es Zeit sich mit Docker auseinander zu setzen. Ein Docker Container ist für mich nichts anderes als eine App/Anwendung. Du kannst Docker Container wie beispielweise Ngnix und SQL Server kombinieren.
In einer VM würdest du warscheinlich alles auf einen Host laufen lassen. Der Vorteil von Docker/Container ist ja, leicht einzurichten und es läuft nicht ein weiteres ganzes OS im Hintergrund was extrem ressourcenschonend ist. Wenn man sich ein wenig mit Container beschäftigt, merkt man erstmal wofür man eigentlich alles keine VM mehr braucht.

 

[besterino]

Ich hab mal schlechte Erfahrungen mit Abhängigkeiten gemacht… und dann schnell wieder getrennt. Ist aber schon ewig her.

 

[p4n0]

Containier schoen und gut.
Fuer Sachen, die jedoch mehr als ne Kleinigkeit serven wuerde ich davon abraten. SQL Server, Owncloud etc haben nix im Container verloren. Das Zeug aktuell und sicher zu halten is sowieso schon maeh, im Container noch schlimmer.

Microservices/Container ergeben durchaus sinn bei Eigenentwicklungen. Um statische, fertige Sachen zu betreiben halte ich da nich viel von. Man handelt sich eher Nachteile ein und laesst die Vorteile von Microservices auf der Strasse liegen.

 

[konfetti]

wir hatten auf der letzten LAN den Cache auf nem Ubuntu-Host mit eben dem Docker-Container - den DNS kannst, bzw. musst Du ja sogar anpassen, dafür gabs aber doch ne Anleitung - is auch schon wieder 1,5 Jahre her. - davor war das alles direkt in dem Ubuntu-Host mit NGINX untergebracht - gefühlt lief der Docker-Container etwas flüssiger - so oder So haben wir aber recht gute Cache-Hit-Ratio mit 1:7 gehabt

@home hatte ich das auch mal vor, aber dann doch sein lassen, weil ich zum einen den Space anders besser nutzen kann und zum anderen es aktuell eh nur 2 PCs betrifft.

So richtig Spaß macht der Cache ja erst mit ordentlich SSDs.
Wir hatten mal mit nem Verbund aus 8x 320GB SATA 2.5" HDDs vor 8 Jahren angefangen, sind dann über 8x300GB SAS HDD auf 8x600GB SAS HDDs gekommen, die vom Platz als auch Speed in Ordnung waren.
das nächste Ziel wäre dann eigentlich SSDs, aber da die Disks bisher auch nur ausgemusterter Speicher war, wird da so schnell nichts kommen.

 

[besterino]

Ich hätte theoretisch 8TB SSD Platz frei…

 

[besterino]

So, ich denke, ich hangele mich mal hier entlang anhand des "The harder but more interesting way: DIY" Abschnitts:

Building a local Steam caching server to ease the bandwidth blues

A bit of Linux, a bit of Nginx, and boom—fast and free Steam downloads.

arstechnica.com

Ich verstehe gerne, was ich da tue und außerdem kann man dann die Details besser an die eigene Landschaft anpassen (gefällt mir besser als die Landschaft an ein Tutorial anzupassen).

Oftopic: Bei der Gelegenheit werde ich evtl. auch mal mit TrueNAS als Storage-Option austesten.

 

[besterino]

So. Steamcache lüppt nach manueller Installation, nginx und DNS manuell konfiguriert und das erste Steam-Spiel ist mal testweise gecached.

Jetzt stellt sich nur die Frage, wie ergänze ich am schnellsten uplay, epic und battle.net (origin geht ja offenbar nicht)?

Irgendwie wird alles nur noch per Docker gemacht und keiner beschreibt (mehr), wie das in Docker genau konfiguriert ist. Kann ich irgendwie unkompliziert so einen Dockercontainer herunterladen / auseinandernehmen und dort die Configs inspizieren / klauen?

Im Prinzip müsste ich doch "nur" nginx erklären, dass er weitere Server beachten soll und weitere DNS-Zonen (?) kreieren, also hier ergänzen:

#/etc/nginx/sites-available/steamcache

server_name *.cs.steampowered.com content1.steampowered.com content2.steampowered.com content3.steampowered.com content4.steampowered.com content5.steampowered.com content6.steampowered.com content7.steampowered.com content8.steampowered.com *.steamcontent.com *.steampipe.steamcontent.com;

...und bind beibringen, welche Zonen relevant sind, nach dem Tutorial oben:

#/etc/bind/steamcache.conf as "included" in /etc/bind/named.conf
zone "cs.steampowered.com" in { type master; file "/var/lib/bind/db.cs.steampowered.com"; };
zone "content1.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content2.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content3.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content4.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content5.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content6.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content7.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "content8.steampowered.com" in { type master; file "/var/lib/bind/db.content_.steampowered.com"; };
zone "steamcontent.com" in { type master; file "/var/lib/bind/db.steamcontent.com"; };{/CODE]

...und dann noch irgendwelche Zone-Files passend dazu erstellen...


Oder ich geb's auf und mach's doch mit lancache oder dem [URL='https://linustechtips.com/topic/962655-steam-caching-tutorial/']LTT-Tutorial[/URL]...

 

[Ceiber3]

Das liegt daran wie ich meine, das immer mehr von VM's oder Programmen zu Containern wechselt.

 

[Morpheuz]

@besterino : schau mal nach den cache domains hier: https://github.com/uklans/cache-domains

Diese werden von lancache/monolithic genutzt (guckstu hier)

 

[besterino]

Ich hab so das Gefühl, das mir das zu komplex ist. Probiere vielleicht doch mal mein Glück mit dem Docker-approach. Nervt mich zwar, aber wenn's funktioniert, funktioniert's...

 

[besterino]

Ok, los gehts - entsteht hier ein kleines Lancache howto "from scratch" step by step - falls es am Ende funktioniert, update ich den Start-Post!

0A.
VM aufsetzen, ich nehme dafür mal:
4 Cores
8 GB RAM
64 GB Disk

0B.
Netzwerk Storage aufsetzen, ich nehme dafür mal eine NFS-Freigabe auf meiner Storage-VM

1.
Ubuntu (als VM) installieren - ich nehm Ubuntu Server 20.04.3
1.1 Beim Setup deaktiviere ich schonmal ipv6 und setze eine feste IP für ipv4

Ich hatte zwischenzeitlich mal IPv6 deaktiviert. Das gab aber Fehlermeldungen mit den Containern und man muss ja nicht unnötig die Logs zumüllen (für eine manuelle Anpassung des/der Container war ich zu faul und gibt dann ja ggf. nur Ärger nach einem Update). Daher hier nur ein Errinerungs-Posten im Spoiler

Spoiler

1.2 Post-Setup, wer will: ipv6 wirklich rauswerfen (Quelle, Quelle2):

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

ipv6 in Grub deaktivieren:
mit Editor und root-Rechten /etc/default/grub öffnen, zu GRUB_CMDLINE_LINUX navigieren und dort eintragen: ipv6.disabled=1"

Bei der Gelegenheit: wenn bei GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity" steht: das ist ein Bug und Überbleibsel aus der Installation - können wir löschenm also ändern in "".
Ausführen: sudo update-grub und reboot.
Nach reboot überprüfen mit "ip a" - da sollte dann nix mehr mit ipv6 stehen.

Dann das übliche:

sudo apt update
sudo apt upgrade

2.
NFS Storage einbinden (Quelle), d.h. nfs-support installieren, lokales Verzeichnis zum Einhängen erstellen (hier /mnt/lancache) und testen

sudo apt install nfs-common
sudo mkdir -p /mnt/lancache
sudo mount [NAS IP address]:/nas/share/path /mnt/lancache
df |grep -i lan
[CODE]

Bei Erfolg sieht das dann so aus:
[CODE]
$ df | grep -i lan
192.168.xxx.xx:x/xxx/xxx/lancache 7736371712     128 7736371584   1% /mnt/lancache

/etc/fstab editieren und am Ende anfügen:
192.168.xxx.xxx:/xxx/xxx/lancache /mnt/lancache nfs4 _netdev,auto,noatime 0 0

Reboot & wieder mit df | grep -i lan prüfen.

Achtung: Berechtigungen
Ihr müsst sicherstellen, dass der spätere user in Eurer Lancache-VM die richtigen Rechte auf dem NFS-Share hat, um auf dem NFS-Share Verzeichnisse anzulegen und diese mit "chown" zu übernehmen.

3.
Docker installieren (Quelle)

sudo apt install apt-transport-https ca-certificates curl gnupg
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

TEST:

sudo docker run hello-world

...sollte ergeben...

$ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
2db29710123e: Pull complete
Digest: sha256:393b81f0ea5a98a7335d7ad44be96fe76ca8eb2eaa76950eb8c989ebf2b78ec0
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

4.
docker-compose installieren (Quelle)
4.1 vorsichtshalber aktuelle Version hier checken.
4.2 installieren & testen:

sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

...sollte ergeben:

$ docker-compose --version
docker-compose version 1.29.2, build 5becea4c

5.
Lancache installieren

cd ~
git clone https://github.com/lancachenet/docker-compose/ lancache
cd lancache
vi .env #oder anderer editor

Meine .env sieht danach so aus (geänderte IP=Server-IP, Cache-Verzeichnis=mein gemountetes NFS-Share, max disk cache=4TB, Zeitzone=Berlin):

Spoiler

## See the "Settings" section in README.md for more details

## Set this to true if you're using a load balancer, or set it to false if you're using seperate IPs for each service.
## If you're using monolithic (the default), leave this set to true
USE_GENERIC_CACHE=true

## IP addresses that the lancache monolithic instance is reachable on
## Specify one or more IPs, space separated - these will be used when resolving DNS hostnames through lancachenet-dns. Multiple IPs can improve cache priming performance for some services (e.g. Steam)
## Note: This setting only affects DNS, monolithic and sniproxy will still bind to all IPs by default
LANCACHE_IP=192.168.xxx.xxx

## IP address on the host that the DNS server should bind to
DNS_BIND_IP=192.168.xxx.xxx

## DNS Resolution for forwarded DNS lookups
UPSTREAM_DNS=8.8.8.8

## Storage path for the cached data
## Note that by default, this will be a folder relative to the docker-compose.yml file
CACHE_ROOT=/mnt/lancache

## Change this to customise the size of the disk cache (default 1000000m)
## If you have more storage, you'll likely want to increase this
## The cache server will prune content on a least-recently-used basis if it
## starts approaching this limit.
## Set this to a little bit less than your actual available space
CACHE_DISK_SIZE=4000000m

## Change this to customise the size of the nginx cache manager (default 500m)
## DO NOT CHANGE THIS LIGHTLY. The defaults are enough to address 8TB of cache storage.  Increasing
## this value will cause performance problems, and may cause the cache to fail to start entirely.
CACHE_MEM_SIZE=500m

## Change this to limit the maximum age of cached content (default 3650d)
CACHE_MAX_AGE=3650d

## Set the timezone for the docker containers, useful for correct timestamps on logs (default Europe/London)
## Formatted as tz database names. Example: Europe/Oslo or America/Los_Angeles
TZ=Europe/Berlin

6.
Lancache Docker starten:

cd ~/lancache
sudo docker-compose up -d

7.
DNSStubListener deaktiveren (Quelle) - sonst startet zumindest Steam auf'm Client nicht sauber mit dem 20.04.3er Ubuntu

sudo -e /etc/systemd/resolved.conf ausführen und #DNSStubListener=yes ändern in DNSStubListener=no und # entfernen (wichtig!)
sudo rm /etc/resolv.conf
sudo ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo service systemd-resolved restart

Test: cmd --> nslookup --> heise.de (o.ä.)




JETZT GEHT'S ZU TESTZWECKEN ERSTMAL RÜBER ZUM (WINDOWS) CLIENT:

8.
Manuell DNS-Server auf den Lancache setzen:
7.1 Systemsteuerung --> Netzwerk- und Freigabecenter --> auf Eure Verbindung clicken --> Darin dann auf Eigenschaften --> Internetprotokoll (...) IPv4 wählen --> Eigenschaften --> Folgenden DNS-Server Verwenden und Euren in der .env oben eingetragenen verwenden.

9.
Eurem Router beibringen, dass der DHCP-Server den Clients statt der eigenen IP die DNS eures neuen DNS-Servers mitteilt
Bei der Fritzbox geht das unter
Heimnetz --> Netzwerk --> Netzwerkeinstellungen --> Sektion "IP-Adressen", IPv4-Adressen anclicken --> Feld "Lokaler DNS-Server": HIER.EURE.SERVER-IP.EINTRAGEN

10.
Änderungen aus Nr. 8 rückgängig machen
10.1 Für Internetprotokoll Version 4 wieder "DNS-Serveradresse automatisch beziehen" auswählen (siehe oben Nr. 8)
10.2 Reboot des Client oder ipconfig /renew in einer admin-CMD
10.3 mit "nslookup" in einer CMD richtigen DNS-Server überprüfen

 

[besterino]

Hab mal kurz getestet mit einem kleinen Spiel (Monkey Island 2 Special Edition). Es läuft:

Erster Download: max ca. 19 MB/s - das ist so ziemlich das aktuelle Limit meiner DSL-Leitung.

Zweiter Download: max 145 MB/s - noch nicht ganz bei 10Gbit aber schonmal schneller als meine DSL-Leitung...

Coming up: Test mit Witcher 3 - das ist bisserl Größer

 

[besterino]

Hmmm... so richtig der Highspeed-Burner ist das noch nicht. Ja, schneller als meine DSL-Leitung. Aber deutlich unter dem, was Server, Client und Netzwerk hergäben. Bisher wäre ich bei meinen Libraries wohl noch deutlich flotter unterwegs, wenn ich den Quatsch einmal komplett über's Netz wegsichere und dann zurück kopiere (da, wo es die Launcher erlauben *lookingatyouEpic/Origin-Idioten*). Und da rächt es sich jetzt, dass ich nur diese Docker-Krücke habe: kann so ohne weiteres nicht in die einzelnen Configs (DNS, Nginx) reinschauen, geschweige denn selbst Hand anlegen. Die Geschwindigkeit ist auch total schwankend, selbst von Spiel zu Spiel (innerhalb von Steam).

Immerhin, Epic und Uplay funktionieren auch:

Battle.net ist gerade mal eher so richtig lahm unterwegs - allerdings kann das ja vielleicht am D2-Ressurected Launch liegen...

 

[v3nom]

Wie ist denn die CPU Last server- und clientseitig in dem Moment? Steam DLs sind ordentlich komprimiert und nehmen gut CPU Last beim Client.

 

[besterino]

Langweilen sich extrem. CPU sowohl bei der Lancache VM teilweise noch <1GHz (hat 8 TR-Kerne!), auch die Storage VM langweilt sich zu Tode. RAM 8GB auch nicht am Limit.

Hab auch mal spaßeshalber der VM 24 Kerne und 32GB RAM gegeben - kein Unterschied.

Neben der Battle.net Lahmheit brauchen verschiedene Launcher auch gefühlt länger beim Start (aufm Client). Steam wirft teilweise sogar timeouts (connection failed - retry?) und hat’s dann erst nach mehreren Anläufen.

Überzeugt mich grad nicht so. Na, mal noch ein paar Tage testen…

Sehe mich schon mich tiefer in bind einlesen. Nervig.

 

[fdsonne]

Er meint eher den Client PC. Also wo Steam läuft. Denn Steam muss den Spaß dann während der Fahrt entschlüsseln. Um so schneller du vorn die Daten rein kippst, desto mehr wird irgendwann die CPU limitieren.
Am Screen sieht man schön, 420MB/sec Disk usage -> ist das zufällig ne SATA SSD wo du das Game drauf installierst? Respektive wo der Download/Temp Folder hin zeigt für Steam?
Steam downloaded per default meine ich in einen Download Folder, der im Steam Verzeichnis ist. Also im Root Steam Verzeichnis, den du bei der Installation angegeben hast.

Bei Steam kommt btw. noch dazu, dass gerade Patches manchmal sehr bescheiden gehandhabt werden. ARK bspw. ist so ein Titel, wo das absolut beschissen läuft. Weil Steam für das Patchen die Daten von der Install Destination in den Download Folder kopiert! (nicht verschiebt, das ist ne Kopie) und dann die Änderungen der Patches da rein impft, teils werden wohl ganze Files getauscht, teils nur Inhalt - und wenn das durch ist, wird der Spaß zurück an den Installort kopiert. ARK ist dabei eins der extrem Beispiele, weil das Game je nach DLC Anzahl und Mods/Karten ganz paar 100GB haben kann. Da werden hunterte GB an Daten hin und her geschubst für ein paar MB Patch. Company of Heroes 2 und PayDay2 sind auch gleiches Kaliber. Bei PayDay2 hats mich so ultra hart genervt, weil da alle paar Tage ein Patch gekommen ist, dass ich das Ding irgendwann runtergeschmissen hab. Hab ich eh nicht gespielt

Ansonsten, Thema Docker - mach mal ein "docker container ls" -> der sollte dir mindesten einen Container zeigen. Die ID bzw. den Namen merkst du dir mal und dann führst du mal ein "docker exec -it <container name> /bin/bash" -> damit sollte sich ne interaktive Bash für dich in den Container öffnen. Dann kommste auch an alle Configs innerhalb des Containers ran.
Ich hab das jetzt selbst noch nicht mit diesem LANCache Ding getestet, aber rein aus dem Gefühl raus würde ich sagen, müssten die Configs ja auch irgendwo gespeichert sein. Da gibts also entweder Ordner, welche er da an eine (oder meherere) Stellen im Container mountet oder es ist ein Docker Volume eingebunden, was im Docker Install Folder unter Volumes liegt. (kommste mit Root ran)


EDIT:
Ansonsten, hab grad mal geschaut, wenn du das etwas auseinander nehmen und selbst verteilen willst - https://github.com/lancachenet
Da findest du die einzelnen "dockerfile" Files. Also die Beschreibungen was Docker innerhalb des Containers machen will/soll.
Um es kurz zu umreißen, sie nutzen Bionic Ubuntu (18.04 LTS) innerhalb des ersten Containers und bauen dann in mehreren Layern dort die Software übereinander auf
Der Lancache Monolithic Container basiert auf diesem Baum:
- ubuntu:bionic
-> lancachenet/ubuntu:latest
-> lancachenet/ubuntu-nginx:latest
-> lancachenet/generic:latest

Der Lancache DNS "nur" auf:
- ubuntu:bionic
-> lancachenet/ubuntu:latest

Du müsstest also zwei Container sehen bei dir?

Ansich kannst du anhand der "dockerfile" Files komplett beschrieben sehen, was da genau passiert. Docker parst die Files von oben nach unten und baut für jede Anwendung einen Subcontainer. Da siehst du auch welche Files wo wie gespeichert und was genau wie geändert wurde innerhalb des Containers.
Mit viel Muße kannste das komplett "entdockern" und nativ in dein Ubuntu installieren...

Hat halt alles so seine Kehrseiten. Dann musst du selbst die Wartung übernehmen. Dafür weist du was da passiert. Im Falle von Containern hat es immer so nen etwas faden Geschmack sich auf Dritte zu verlassen. Zudem noch Vierte, wo die Dritten ihre Images hin laden. (Dockerhub als Registry)

 

[besterino]

Hey super, da hab ich mal einen Ansatz! Werde ich definitiv mal anschauen!

 

[myBerg]

Ansonsten, Thema Docker - mach mal ein "docker container ls" -> der sollte dir mindesten einen Container zeigen. Die ID bzw. den Namen merkst du dir mal und dann führst du mal ein "docker exec -it <container name> /bin/bash" -> damit sollte sich ne interaktive Bash für dich in den Container öffnen. Dann kommste auch an alle Configs innerhalb des Containers ran.
Ich hab das jetzt selbst noch nicht mit diesem LANCache Ding getestet, aber rein aus dem Gefühl raus würde ich sagen, müssten die Configs ja auch irgendwo gespeichert sein. Da gibts also entweder Ordner, welche er da an eine (oder meherere) Stellen im Container mountet oder es ist ein Docker Volume eingebunden, was im Docker Install Folder unter Volumes liegt. (kommste mit Root ran)

Um die laufenden Container anzuzeigen docker ps:

docker ps

bzw.

docker ps -a

Um in den Container zu schauen, wie geschrieben "docker exec ..".

docker exec -it <container id> /bin/sh

Hinweis dazu: Das funktioniert nur dann, wenn das Containerimage die entsprechende Shell auch mitbringt. Mehr Details über einen laufenden Container liefert docker inspect:

docker inspect <container id>

Wichtig sind auch die docker logs:

docker logs <container id>

Es gibt ein paar wichtige Befehle für den täglichen Bedarf. Alle Befehle sind hier sehr gut dokumentiert:
https://docs.docker.com/engine/reference/commandline/cli/

Im Grunde sind Container nicht viel anders als VMs nur leichtgewichtiger. Ich kann Volumes/Disks, das Netzwerk und CPU/RAM Resourcen isolieren. Es gibt viele Defaults, darum fällt einem das am Anfang nicht so auf. Aber im Grunde ist das sehr ähnlich.

Ein wichtiger Default sind anonyme Volumes. D.h. Wenn ich nichts mache bekommt ein Container ein Defaultvolume bereitgestellt, dass mit dem entfernen des Containers (docker rm) auch wieder verschwindet. Da sind z.B. immer alle Binärdateien drin. Damit Daten wie Konfigurationsdateien oder andere Anwendungsdaten nicht verlorengehen, muss man ein named Volume definieren. Das ist dann ein konstanter Mount auf deinem Host, der nach dem entfernen des Containers auch nicht gelöscht wird. Dort sollten sich in der Regel auch alle Konfigurationsdateien befinden. Mit docker inspect, kannst Du schauen, welche named Volumes wohin gemounted sind. Eine andere Möglichkeit ist auf DockerHub zu schauen. Da liegen viele Bauvorschriften (Dockerfile) auch im Quellcode.

Beispiel: Attlassian Confluence

Docker

Hier sieht man an der Zeile "VOLUME [/var/atlassian/application-data/confluence]" welche Verzeichnisse als Mountpoint bereitgestellt werden. Typischerweise liegen die dann unter /var/lib/docker/volumes. Mit docker volume bekommt man mehr heraus:

docker volume ls
DRIVER VOLUME NAME
local 21a49b8ba5616aa6b29bbc2b428e8f440fa206c043a782f397f40ed769b43326

docker volume inpsect 21a49b8ba5616aa6b29bbc2b428e8f440fa206c043a782f397f40ed769b43326

Zeigt dir dann die Orte auf dem Host an. Die lassen sich beim Start des Containers per Volumemapping auch in andere Verzeichnisse legen.

Ein sehr wichtiges Konzept bei Containern ist die Orchestrierung, d.h. das Zusammenschalten mehrer Container zu einer Gruppe. Lokal oft mit docker-compose. Verteilt dann mit Docker Swarm, Kubernetes o.ä. . Das macht man jetzt zu Hause eher weniger, aber docker-compose läuft einem da schon mal über den Weg, z.B. um die Anwendung mit der zugehörigen Datenbank zusammenzuschalten. Das ist jetzt für die Konfigurationsdateien nicht so wichtig, aber wichtig zu wissen, um zu verstehen, warum Container so beliebt sind.

docker-compose ist auch ein Weg, um sich die Parameterorgie beim Aufruf von docker run zu sparen.

Mit "docker ps -a", "docker exec" und "docker inspect" kommt man aber schon ziemlich weit, was den Erkenntnisgewinn angeht.

 

[besterino]

Ihr seid großartig - so ein erster Einstieg für Doofe hat mir gefehlt! (...und ich war bisher vielleicht auch noch zu faul, selbst zu suchen...)

CONTAINER ID   IMAGE                             COMMAND                  CREATED        STATUS                    PORTS                                                    NAMES
de2df7fcb0c2   lancachenet/lancache-dns:latest   "/bin/bash -e /init/…"   23 hours ago   Up 18 hours               192.168.178.18:53->53/tcp, 192.168.178.1  8:53->53/udp   lancache_dns_1
9aff1a5496cd   lancachenet/monolithic:latest     "/bin/bash -e /init/…"   23 hours ago   Up 18 hours               0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp                 lancache_monolithic_1

Für alles Weitere brauch ich jetzt vor allem mal "nur" ein paar Stündchen Zeit am Stück...

 

[besterino]

Noch zu der Frage der Datenträger: auf dem einen PC sind die Spiele auf einem Raid0 aus 2 SATA-SSDs und das OS/Standardverzeichnisse auf einer NVME. Auf dem anderen PC (zu Testzwecken) ist alles auf einer NVMe.

Vielleicht ist das auch echt sehr spielabhängig. Hab mal gerade auf PC1 fortnite installiert und danach auf PC2 (nur gbit-Netz). So soll's sein und bliebt dann auch sauber bis zum Ende der Installation auf 110MB/s:

 

[fdsonne]

Um die laufenden Container anzuzeigen docker ps:

Mal ne verständnis Frage - bin leider nicht sooo tief im Docker Game drin, dass ich in der Lage wäre, sowas im Business use case ernsthaft seriös zu betreiben - aber ist "docker ps" und "docker container ls" nicht das gleiche beim Thema Anzeigen der Container??
Mir war so als wäre "docker container ls" respektive "ls -a" für alle (auch nicht laufende) der neumodische Befehl, den man da seinerzeit eingeführt hat um das ganze etwas mehr verständlich zu machen?

Wichtig sind auch die docker logs:

Dem stimme ich zu - vielleicht noch ein Nachtrag bzgl. den Logs @besterino
Per default speichert Docker wohl schon immer? oder wenigstens seit geraumer Zeit die Logs im JSON Format innerhalb des Container "Ordner" auf der Disk des Hosts. Der Log Provider für JSON rotiert dabei die Logfiles NICHT. Sprich wenn du Container laufen hast, die seeehr viel Logoutput erzeugen, dann hast du da nach geraumer Zeit riesige Files. Vor allem bei Langläufercontainern. Hab es nicht probiert, aber sollte der da jedes kleine Schnippsel in nem Access Log speichern, dürfte da ne Menge an Daten beim Download von einigen Games rumkommen.

Nach nem "docker rm <container id>" wird das zwar geputzt und wenn du updatest bzw. die Container neu erzeugst, erledigt sich das sozusagen, aber je nach dem, was man da betreibt, macht man das ja auch nicht täglich.
Für meinen Gitlab Container privat hab ich das so eingedreht, dass er den "local" Provider nutzen soll. Dafür gibts dann auch ein Logrotate.

Weiterhin, weil es vllt interessant ist, das Umbiegen der Docker Pfade von "/var/lib/docker/" auf ne andere Disk, nen anderen Mountpoint oder sonstwas kannst du in der "/etc/docker/daemon.json" (musst du anlegen, wenn nicht vorhanden) tätigen.
Sieht dann so in etwa aus:

{
    "data-root": "/opt/docker",
    "log-driver": "local",
    "log-opts": {
        "max-size": "128m"
    }
}

Danach einfach noch den Inhalt von "/var/lib/docker/" in den neuen Pfad kopieren und ab dafür...



Was die Datenträger/den Speed angeht, schau mal im Taskmanager respektive im Ressourcen Monitor, was da je nach Game das Limit sein könnte. Auch das Raid aus den SSDs könnte ja tendentiell zu nem Limit werden, weil je nach Game und Art und Weise der Pakete wird da mit vielen kleinen Files gearbeitet. Das geht dann schon Richtung Random Write IO. CPU wie gesagt wäre noch ggf. ein Problem. Ne activity Anzeige von 100% auf dem Datenträger wäre bspw. ein Indikator, dass das Storage limitiert, zumindest wenn dabei nicht gleichsam auch die LAN Strippe dicht ist.

 

[besterino]

Naja, battle.net ist irgendwo im zweistelligen Kb-Bereich… da geht wohl schon noch bissi mehr.

 

[fdsonne]

Zu battle.net kann ich absolut keine Aussagen treffen - hab ich net

 

[besterino]

Na wenn ich das richtig verstanden habe, sind die logs schon umgebogen und liegen bei mir aufm NFS Share.

 

[sch4kal]

GitHub - uklans/cache-domains: Domain Names required for LAN Content Cache DNS spoofing

Domain Names required for LAN Content Cache DNS spoofing - uklans/cache-domains

github.com

Da sind doch sogar Shellscripts die dir aus der Liste ne passende Unbound/dnsmasq Cfg zimmern ?

Und die nginx Config wird auch mithilfe eines Shellscripts erzeugt...

 

[besterino]

Es funzt ja, nur nicht ideal und ich will mal genauer reinschauen.

 

[myBerg]

Mal ne verständnis Frage - bin leider nicht sooo tief im Docker Game drin, dass ich in der Lage wäre, sowas im Business use case ernsthaft seriös zu betreiben - aber ist "docker ps" und "docker container ls" nicht das gleiche beim Thema Anzeigen der Container??
Mir war so als wäre "docker container ls" respektive "ls -a" für alle (auch nicht laufende) der neumodische Befehl, den man da seinerzeit eingeführt hat um das ganze etwas mehr verständlich zu machen?

Jepp, ich denke das ist weitgehend kompatibel. Beim Nachschlagen in der Doku ist es besser die bei den direkten docker Befehlen zu schauen. Da hat man dann auch Beispiele.

 

[besterino]

Mal ein kleines Update: Die Battle.net Geschwindigkeit hat sich inzwischen normalisiert, scheint also doch ein temporäres Thema gewesen zu sein.

Auch Steam läuft sehr sauber: hier von einem "normalen" Client bei uns an einer ganz normalen 1gbit-Verbindung zum Server:

Am "großen" Desktop mit 10Gbit hab ich immerhin auch schon mal 250MB/s gesehen. Das reicht mir. =)