Docker-Installation
Übersicht
Diese Seite beschreibt die manuelle (schrittweise) Installation der PlantPulse Platform als Docker Compose Stack.
In einer typischen Umgebung wird die Einzeilen-Installation empfohlen. Die Einzeilen-Installation übernimmt alles in einem Durchgang, vom Paket-Download über die automatische Erkennung der Umgebung und Installation bis hin zur Boot-Validierung. Bitte verwenden Sie das manuelle Verfahren auf dieser Seite nur in folgenden Fällen:
- Wenn jeder Installationsschritt direkt geprüft und genehmigt werden muss (z. B. bei Sicherheitsaudits oder Change-Management-Verfahren).
- Wenn Umgebungsvariablen (
bin/env.sh) manuell auf Werte festgelegt werden müssen, die von der automatischen Erkennung abweichen. - Bei der Installation in einem Air-Gap-Netzwerk ohne Internetzugang → Air-Gap-Installation.
Architektur — Neun Container
Die Platform wird als ein einziger docker compose Stack betrieben. Die Referenzdatei ist compose/docker-compose.yml; alle Betriebsskripte steuern die Container über diese Datei.
| Container | Ebene | Rolle |
|---|---|---|
plantpulse-certs | Zertifikat | Erstellt TLS-Material und überwacht kontinuierlich das Ablaufdatum. (healthy) ist der Normalzustand |
plantpulse-datalake | Infrastruktur | Storage, Messaging, Analyse, CEP, SQL, Monitoring |
plantpulse-server-web | Applikation | Web-Konsole |
plantpulse-batch-web | Applikation | Batch |
plantpulse-warehouse-web | Applikation | Data Warehouse |
plantpulse-plugin-opcua | Applikation | OPC-UA-Server-Plugin (11004 / 11005) |
plantpulse-plugin-aasx | Applikation | AASX-Server-Plugin |
plantpulse-ha | Applikation | Redundanz-Recovery-Daemon (10210) |
plantpulse-proxy | Edge | Einziger Zugangspunkt für Benutzer (80 / 443 / 1883 / 1884) |
Es ist normal, wenn in docker ps alle neun Container als (healthy) angezeigt werden.
Darüber hinaus ist plantpulse-mirror-maker für das Mirroring im Compose-File definiert, wird jedoch aufgrund des mirror Profils standardmäßig nicht gestartet.
Vor dem 29.08.2026 konnte eine «Monolith»-Konfiguration gewählt werden, bei der alle Komponenten in einem einzigen plantpulse-platform Container liefen. Diese Konfiguration wurde eingestellt, und die entsprechende Auswahlvariable (PP_TOPOLOGY) sowie das Compose-File wurden gelöscht. Es gibt keine Auswahlmöglichkeit mehr — bin/up.sh startet den oben genannten Stack.
Befehle wie docker logs plantpulse-platform aus alten Runbooks funktionieren nicht mehr, da ein Container dieses Namens nicht existiert. Ersatzbefehle finden Sie in der Zusammenfassung der Betriebsbefehle.
Der Hauptgrund für die Trennung der Applikationen in eigene Container ist die OOM-Isolation. Wenn eine App den gesamten Speicher verbraucht, bleiben andere Apps und die Infrastruktur stabil; zudem können Neustarts oder Rollbacks auf App-Ebene durchgeführt werden.
Voraussetzungen
Bitte prüfen Sie die folgenden Punkte vor Beginn der Installation.
| Punkt | Anforderung |
|---|---|
| Benutzerrechte | root (oder sudo-Rechte). Das Installationsskript konfiguriert OS-Einstellungen und den Docker-Daemon |
| Betriebssystem | RHEL · Rocky Linux · Oracle Linux 8.x · 9.x · 10.x, Ubuntu 20.04+, Amazon Linux 2/2023 |
| Docker | Compose v2 erforderlich (docker compose — Form ohne Bindestrich). Falls install.sh fehlt, wird es installiert |
| Datendisk | Empfohlen wird ein großdimensioniertes Disk-Mount unter dem Pfad /data1 — Docker-Daten(/data1/docker-data) und Platform-Datenvolumes nutzen diesen Pfad |
| Registry-Zugriff | HTTPS-Zugriff auf docker.kopens.io (Image-Registry) und product.kopens.io (Installationspaket) muss möglich sein. In Umgebungen ohne Zugriff nutzen Sie bitte die Air-Gap-Installation |
| Registry-Credentials | Login-Daten für docker.kopens.io (ausgestellt vom KOPENS-Betriebsteam) |
Hinweis zum Disk-Pfad: Falls keine separate Datendisk vorhanden ist, kann das Verzeichnis
/data1auf der Root-Disk erstellt werden. In Produktionsumgebungen wird jedoch empfohlen, eine dedizierte Disk unter/data1zu mounten.
Manuelles Installationsverfahren
Schritt 1: Download des Installationspakets
Laden Sie das Installationspaket (tar.gz) vom Download-Server herunter und entpacken Sie es im Standardpfad. Es sind keine Git-Clones oder separaten Tool-Installationen erforderlich.
sudo -i
# 표준 설치 경로 생성 후 패키지 다운로드 + 압축 해제
mkdir -p /opt/kopens/plantpulse-platform-docker
curl -fsSL "https://product.kopens.io/plantpulse-platform/plantpulse-platform-docker.tar.gz" \
| tar -xz -C /opt/kopens/plantpulse-platform-docker --strip-components=1
cd /opt/kopens/plantpulse-platform-docker/bin
chmod +x *.sh tools/*.sh
Innerhalb des Pakets werden primär zwei Bereiche genutzt:
| Ort | Inhalt |
|---|---|
bin/ | Alle Installations- und Betriebsskripte |
compose/ | Referenzdatei des Stacks docker-compose.yml und Cluster-Worker-Overlay |
Schritt 2: Vorabprüfung (Preflight)
preflight.sh prüft lediglich die Installationsfähigkeit, ohne Änderungen am System vorzunehmen.
./preflight.sh
Geprüfte Punkte:
- Status der Docker-Installation/Daemon-Operation (nicht installiert ist möglich —
install.shinstalliert es) - Vorhandensein des übergeordneten Pfads für Docker data-root (
/data1) - Vorhandensein des Secret-Sidecars (
/etc/kopens/plantpulse-platform.env) - Belegung wichtiger Betriebsports (80, 443, 4949, 4950)
Fahren Sie nur bei einem Ergebnis von OK mit dem nächsten Schritt fort. Bei ERROR beachten Sie bitte die Problembehebung. (WARN dient nur zur Information und blockiert die Installation nicht.)
Schritt 3: Prüfung der Umgebungsvariablen (env.sh)
bin/env.sh legt die Standardwerte für die Host-Seite fest, während der Operator individuelle Werte im Sidecar
/etc/kopens/plantpulse-platform.env einträgt. Die Werte, welche die Container tatsächlich sehen, werden von
compose/docker-compose.yml bestimmt — für die detaillierten Zusammenhänge beachten Sie die Referenz der Umgebungsvariablen.
vi /etc/kopens/plantpulse-platform.env
Werte, die in bin/env.sh eingetragen wurden, gehen bei Neuinstallationen oder Upgrades verloren. Das Installationsskript löscht das Verzeichnis und lädt es neu herunter.
env.sh ermittelt CPU, Speicher und Disk eigenständig basierend auf dem Host. Da es sich nicht um fixierte Standardwerte handelt, werden in kleineren Boxen automatisch kleinere Werte zugewiesen, ohne dass ein manueller Eingriff nötig ist. Box-spezifisch zugewiesene Werte haben immer Priorität.
| Variable | Bestimmung | Wann anpassen? |
|---|---|---|
DOCKER_PP_CPUS | nproc (falls Lesefehler, dann 8) | Wenn dem Container weniger Kerne zugewiesen werden sollen |
DOCKER_PP_CLUSTER_CORES | DOCKER_PP_CPUS - 2, Min. 4 · Max. 30 | Meist unverändert lassen |
DOCKER_PP_MEMORY | 90% des Host-RAMs, Min. 8G | Um mehr RAM für das OS zu reservieren |
DOCKER_DATALAKE_MEMORY | 96G (Minimum). Kappung bei 90% des Host-RAMs — Hosts unter 107G erfüllen die Mindestanforderung nicht | Nur bei Erhöhung. Nicht unter 96G senken |
DOCKER_PP_DATA_DISK_NAME | Automatische Rückverfolgung der physischen Disk, die / stützt (bei Fehler sda) | Wenn die automatische Erkennung fehlerhaft ist |
PP_LANG | en | Bei Betrieb in Korea: ko |
PP_TZ | Asia/Seoul | Für internationale Boxen |
DOCKER_PP_EXTERNAL_IP | Leerwert | Nur in NAT-Umgebungen, wenn die externe öffentliche IP angegeben werden muss |
DOCKER_PP_EXTERNAL_IP einDieser Wert fließt über PP_SERVICE_IP in die SAN-Liste des TLS-Zertifikats. Wenn auch nur eine einzige IP ein falsches Format hat, lehnt openssl die gesamte Extensions-Datei ab, wodurch kein einziges Zertifikat erstellt wird und der Stack nicht starten kann. Wenn Sie sich nicht hinter einem NAT befinden, lassen Sie dieses Feld leer — das ist der Standardwert.
Die aktuellen Werte des Servers können mit dem folgenden Befehl geprüft werden:
hostname -I | awk '{print $1}' # 서버 IP
free -g | awk '/^Mem:/{print $2"G"}' # 전체 메모리
nproc # CPU 코어 수
lsblk # 디스크 이름 (sda, sdb, nvme0n1 …)
Bei Boxen für den Betrieb in Korea werden üblicherweise nur zwei Zeilen angepasst:
export PP_LANG=ko
export PP_TZ=Asia/Seoul
PP_LANG / PP_TZ werden zur JVM-Bootzeit fixiert. Um diese in einem laufenden Stack zu ändern, ist ./restart.sh erforderlich. Da Aster TSDB Zeitreihen im KST-Epoch-Format speichert, behalten Sie für den Betrieb in Korea bitte Asia/Seoul bei.
Schritt 4: Ausführung der Installation (install.sh)
sudo ./install.sh
install.sh führt den gesamten Installationsprozess automatisch aus.
- OS-Erkennung und Systemkonfiguration — Dateilimits (limits), Kernel-Parameter (sysctl), Zeitsynchronisation (chrony), SELinux-Umschaltung auf permissive, Deaktivierung von Swap.
- Installation der Docker Engine — Installation über den jeweiligen OS-Paketmanager + Konfiguration des data-root auf
/data1/docker-data(Compose v2 wird bei Bedarf mitinstalliert). - Firewall-Konfiguration — Öffnen der öffentlichen Ports (80/443/4949/4950) und Beschränkung interner Ports auf den Zugriff aus privaten Netzwerkbereichen.
- Erstellung der Service-Credentials — Erstellung des
/etc/kopens/plantpulse-platform.envSecret-Sidecars (Berechtigung 0600, bestehende Werte werden bei Wiederholung nicht überschrieben). - Registry-Login — Eingabe der
docker.kopens.ioCredentials (wird automatisch übersprungen, falls bereits eingeloggt). - Stack-Start — Erstellung von Netzwerken/Volumes → Image pull → Seed der Konfigurationsvorlagen →
docker compose up -d.
Einmalige Optionen bei der Installation (nur bei Bedarf über Umgebungsvariablen angeben):
| Option | Effekt |
|---|---|
SKIP_OS=1 | Überspringt OS-Konfiguration und Docker-Installation (falls Docker bereits installiert und aktiv ist) |
SKIP_LOGIN=1 | Überspringt Registry-Login (falls bereits eingeloggt oder Images lokal vorhanden sind) |
SKIP_FW=1 | Überspringt Firewall-Konfiguration (falls die Firewall separat verwaltet wird) |
DOCKER_DATA_DIR=<path> | Ändert Docker data-root (Standard /data1/docker-data) |
# 예: Docker가 이미 설치된 서버
SKIP_OS=1 sudo -E ./install.sh
Der Secret-Sidecar (/etc/kopens/plantpulse-platform.env) verwendet eine bedingungslose Zuweisung in Form von export VAR=값 und überschreibt somit Shell-Exports. Auf einem bereits installierten Knoten wird PP_PG_PASSWORD=... ./up.sh stillschweigend ignoriert. Tauschen Sie Credentials bei der Auslieferung vor der Installation mittels export PP_*_PASSWORD=... aus; nach Abschluss der Installation nutzen Sie passwd.sh aus der Passwortrotation.
Schritt 5: Start und Boot-Validierung
install.sh startet den Stack und kehrt zurück. Ob der Boot-Vorgang abgeschlossen ist, muss separat geprüft werden.
./up.sh
up.sh ist idempotent, d. h. es ist sicher, den Befehl auszuführen, auch wenn der Stack bereits läuft, und wartet, bis das System bereit ist. Der Exit-Code 0 bedeutet nicht «Befehl erfolgreich», sondern «das System ist nun einsatzbereit».
| Umgebungsvariable | Standardwert | Bedeutung |
|---|---|---|
PP_READY_TIMEOUT | 900 | Maximales Zeitlimit für die Bereitschaft (Sekunden) |
PP_READY_INTERVAL | 15 | Prüfintervall (Sekunden) |
PP_WAIT=0 | — | Kein Warten. In diesem Fall bedeutet 0 nicht, dass die Bereitschaft erreicht wurde |
Der reine Prozessstart dauert 3–5 Minuten (JVM-Warmup), aber es dauert 15–18 Minuten, bis alle Komponenten stabil sind. Die Aster TSDB Schema-Migration und Stabilisierung sind die zeitintensivsten Schritte. Neustarts erfolgen deutlich schneller, da das Schema bereits existiert.
Messwerte (31.08.2026, 32 vCPU / 128GiB): Data Lake 217s, Webserver 316s.
Die Bereitschaftsprüfung kann auch manuell gestartet werden:
./stack-verify-boot.sh
Dieses Skript prüft nicht nur einen einzelnen Container, sondern den gesamten Stack — ob alle neun Container im Zustand running·healthy sind und ob der Proxy den Port 443 bedient.
Schritt 6: Status- und Betriebsprüfung
./status.sh # 0 = 정상 / 2 = 비정상
./ops-check.sh
status.sh fasst die Service-Liste, den Container-Status, Health und Volumes zusammen. Der Exit-Code ist bindend und kann direkt in Automatisierungen verwendet werden.
| Entscheidung | Was wird als abnormal gewertet? |
|---|---|
| Service-Liste nicht lesbar | Fehler beim Parsen von Compose oder kein Docker-Zugriff |
| Kein Container für in Compose definierten Service | Nicht gestartet |
Container ist nicht running | Alle neun Container müssen permanent laufen — es gibt keine Ausnahmen |
Health des permanenten Containers ist unhealthy | starting / none gilt als Prüfung ausstehend |
| Health-API liefert kein OK | Probe innerhalb des Data Lakes |
Volumes und Konfigurationen werden nur berichtet und fließen nicht in den Exit-Code ein, da es je nach Installationskonfiguration normal ist, dass einige fehlen.
ops-check.sh scannt zusätzlich die neuesten kritischen Logs (OOM, FATAL, SSL-Fehler etc.).
Health-Prüfung
Die Monitoring-API wird vom plantpulse-datalake Container bereitgestellt. Der Befehl unterscheidet sich je nach Abfrageort.
# 컨테이너 안에서 — 어떤 구성에서도 동작하는 방법
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq
# 호스트/외부에서 — 4950 이 publish 되어 있습니다
curl -kfsS https://<server-ip>:4950/api/health | jq
Wenn "status" den Wert OK oder WARN hat, liegt der Zustand im Normalbereich; bei FAIL liegt eine Störung vor.
Die Konsole und die Health-API werden über beide Ports bereitgestellt — 4950 (HTTPS) und 4949 (Klartext-HTTP). Es handelt sich um dieselbe Konsole und API, lediglich das Schema unterscheidet sich. Port 4949 leitet nicht mehr auf 4950 weiter.
4949 ist Klartext — Login-Passwörter und Session-Cookies werden unverschlüsselt übertragen. Nutzen Sie in nicht vertrauenswürdigen Netzwerken 4950. 4949 ist eine Option für Boxen, bei denen Selbstsignatur-Zertifikatswarnungen den Operator tatsächlich behindern würden.
Installationsergebnisse
Netzwerke und Volumes
| Ressource | Name | Zweck |
|---|---|---|
| Netzwerk | pp-net | Platform-spezifisches Docker-Netzwerk (Standard 10.99.0.0/24, Gateway 10.99.0.1) |
| Volume | pp-data | Permanente Datenspeicherung (Aster TSDB, PostgreSQL, Kafka etc.) |
| Volume | pp-temp | Temporäre Daten (Spark, Hive Workspace) |
| Volume | pp-backup | Backup-Speicher |
| Volume | pp-security | TLS-Zertifikate/Keystore. Wird von plantpulse-certs geschrieben, andere lesen nur |
| Volume | pp-proxy-certs | Vom Proxy auf Port 443 verwendete Zertifikate |
Volumes werden auch beim Stoppen oder Entfernen von Containern immer beibehalten, sodass Daten bei Updates oder Neuinstallationen erhalten bleiben.
Host-Verzeichnisse
| Pfad | Zweck |
|---|---|
/opt/kopens/plantpulse-platform-docker | Installations- und Betriebsskripte sowie Referenz-Compose-Datei |
/etc/kopens/conf | Platform-Konfigurationsvorlagen (Host-Bind-Mount). Werden beim ersten Start automatisch aus dem Image geseedet; können danach vom Operator auf dem Host bearbeitet werden und bleiben bei Neuinstallationen erhalten |
/etc/kopens/plantpulse-platform.env | Secret-Sidecar für Service-Credentials (Berechtigung 0600) |
/etc/kopens/platform.node.env | Knotenidentität (IP, Disk etc., Werte spezifisch für diese Box). Kopieren zwischen Knoten verboten |
/etc/kopens/ca | Gemeinsame Cluster-CA (wird bei getrennter 2-Knoten-Installation verwendet) |
Zugriffsadressen
| Zweck | Adresse |
|---|---|
| Web-Konsole | http://<server-ip>/ · https://<server-ip>/ — wird von plantpulse-proxy empfangen |
| Admin-UI | https://<server-ip> (gleiche Adresse wie Web-Konsole) |
| Monitor-UI · Health | https://<server-ip>:4950/api/health |
| MQTT | <server-ip>:1883 (Klartext) · <server-ip>:1884 (TLS) |
| OPC-UA | <server-ip>:11004 · <server-ip>:11005 |
Sicherheitshinweis: Bitte ändern Sie unbedingt das Standard-Administratorpasswort nach dem ersten Login in der Web-Konsole. → Initialpasswort
Zusammenfassung der Betriebsbefehle
Befehle für den täglichen Betrieb. Alle werden in /opt/kopens/plantpulse-platform-docker/bin/ ausgeführt. Alle Verben unterstützen --help.
| Aufgabe | Befehl | Anmerkung |
|---|---|---|
| Statusprüfung | ./status.sh | Zusammenfassung von Service / Health / Volumes. 0=Normal / 2=Abnormal |
| Betriebsprüfung | ./ops-check.sh | Container Health + Health-API + aktuelle kritische Logs |
| Start | ./up.sh | Idempotent. 0 = Bereit |
| Stopp | ./down.sh | Zustand wird beibehalten |
| Neustart | ./restart.sh | Graceful Drain → Stopp → Start → Bereitschaftswarten |
| Logs einsehen | ./logs.sh [서비스] | Zeigt die letzten 200 Zeilen und beendet. Für Live-Verfolgung -f. Ohne Argument: alle Container. Liste: --list |
| Container-Zugriff | ./shell.sh [서비스] | Ohne Argument: Data Lake |
| Versionsupgrade | Erneute Ausführung des Installations-Einzeilers | Nicht ./update.sh — Upgrade |
| Vollständige Entfernung | ./remove.sh | Entfernt nur Container (Volumes und Konfiguration bleiben erhalten). RM_IMAGE=1 / RM_NETWORK=1 |
| Backup | ./backup.sh [볼륨 …] | Standard pp-data · pp-security |
| Boot-Validierung | ./stack-verify-boot.sh | Bereitschaftsprüfung für den gesamten Stack |
| Diagnose-Bundle | ./doctor.sh | Tarball für Support-Anfragen. Geheime Werte werden maskiert |
| Passwortänderung | ./passwd.sh --list | Liste der änderbaren Schlüssel |
# 운영 중 빠른 점검 루틴
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh
# 문제가 의심되면 진단 번들 생성
./doctor.sh
stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh wurden nicht gelöscht. Bei direkter Ausführung wird lediglich der neue Name in einer Zeile angezeigt, die Funktion bleibt gleich. Bestehende Kunden-Runbooks müssen nicht massenhaft aktualisiert werden.
Achtung — Löschen aller Volumes:
./tools/remove-all-volumes.shlöscht alle Daten dauerhaft. Verwenden Sie dies nur nach einem erfolgreichen Backup.
Air-Gap-Installation
Die Air-Gap-Installation wurde in den Abschnitt Air-Gap-Installation verschoben. Dort finden Sie Informationen zum Inhalt des Bundles, zu den Umgebungsvariablen von airgap-bundle.sh sowie zu den Dingen, die airgap-load.sh vor der Installation blockiert.
Problembehebung
Preflight-Prüfung schlägt fehl
| Meldung | Maßnahme |
|---|---|
docker is installed but daemon is not ready while SKIP_OS=1 | Bitte starten Sie zuerst den Docker-Daemon: systemctl start docker. Alternativ konfigurieren install.sh Docker bei Ausführung ohne SKIP_OS |
| Port bereits belegt (WARN) | Der betreffende Port wird von einem anderen Dienst verwendet. Prüfen Sie den Prozess mit ss -tlnp | grep :<port> und bereinigen Sie ihn vor der Platform-Installation |
| Übergeordneter Pfad für Docker data-root fehlt (WARN) | Verzeichnis /data1 existiert nicht. Mounten Sie eine Datendisk unter /data1 oder erstellen Sie das Verzeichnis |
Stack startet nicht
docker compose up -d wartet auf alle Bedingungen in depends_on. Wenn ein einziger Container den Healthcheck nicht besteht, schlägt der gesamte Befehl mit einer einzigen verbleibenden Zeile fehl.
dependency failed to start: container plantpulse-server-web is unhealthy
Diese Zeile gibt außer dem Containernamen keinen Aufschluss. Da das Betriebsskript in diesem Fall automatisch die Containerliste, Status, Health-Probe-Ausgabe und das Ende der jeweiligen Logs ausgibt, lesen Sie bitte zuerst diese Ausgabe. Zur manuellen Prüfung:
cd /opt/kopens/plantpulse-platform-docker/bin
# 어떤 컨테이너가 어떤 상태인가
./status.sh
# 문제가 있는 컨테이너의 로그
./logs.sh --list # 볼 수 있는 서비스 목록
./logs.sh plantpulse-server-web -n 200
# 자원 상황
df -h
docker stats --no-stream
Häufige Ursachen:
| Ursache | Prüfung |
|---|---|
| Speichermangel (OOM) | docker inspect <컨테이너> --format '{{.State.OOMKilled}}'. Für app-spezifische mem_limit siehe Referenz der Umgebungsvariablen |
| Disk voll | Freiraum prüfen mit /data1 |
| Fehlende erforderliche Credentials | Compose fordert Passwörter über :?. Wenn diese leer sind, startet der Stack nicht teilweise, sondern gar nicht — führen Sie zuerst install.sh aus, um den Sidecar zu erstellen |
| Verzögerung bei DB-Initialisierung | Die Erstinstallation dauert aufgrund der Schema-Erstellung länger. Wenn in den Logs Fortschritte ohne Fehler sichtbar sind, warten Sie bitte noch etwas |
Falls die Ursache schwer zu ermitteln ist, erstellen Sie mit ./doctor.sh ein Diagnose-Bundle und fügen Sie dieses Ihrer Support-Anfrage bei. Das Diagnose-Bundle enthält Status und Logs aller Container.
TLS-Handshake erscheint nur als TimeoutException
Wenn der Name, den eine App zur Verbindung mit dem Backend verwendet, nicht in der SAN-Liste des Zertifikats enthalten ist, erscheint in der Fehlermeldung kein Hinweis auf das Zertifikat, sondern es sieht aus wie ein Timeout. Wenn Sie Containernamen geändert oder Backend-Hosts direkt指定 haben, prüfen Sie diesen Fall. Das Verfahren zur Neuerstellung von Zertifikaten finden Sie unter Sicherheitsmanagement.
Registry-Authentifizierung fehlgeschlagen
# unauthorized 오류 시 재로그인
docker login docker.kopens.io
- Falls Login-Credentials fehlen oder abgelaufen sind, fordern Sie eine Ausstellung beim KOPENS-Betriebsteam an.
- Die firmeninterne Firewall könnte den Zugriff auf die Registry blockieren. Bitten Sie den Netzwerkadministrator, HTTPS-Zugriff auf die Domains
docker.kopens.ioundproduct.kopens.iozu erlauben. - In Umgebungen, in denen der externe Zugriff grundsätzlich gesperrt ist, nutzen Sie bitte die Air-Gap-Installation.
Technischer Support
Wenn Sie während der Installation oder des Betriebs Hilfe benötigen, kontaktieren Sie uns jederzeit unter: webmaster@kopens.com