Hallo Ich bin recht neu in Docker und habe da mal eine Frage. Ich habe auf einem Server einige Docker Container laufen, Diese würde ich gerne wie sie sind auf einen anderen Server übertragen können. Ich könnte sie auch anhalten um sie zu übertragen. Aber ich möchte nicht nur das dockerfile kopieren und den Container neu erstellen. Wie stellt man das an? Und kennt ihr ein "Tool" mit dessen Hilfe man das zb per Weboberfläche machen kann? Ich habe Rancher und Portainer ausprobiert aber beide scheinen nur neue Container erstellen zu können. Grund für dieses vermutlich nicht docker gerechte Verhalten ist das die Anwendung welche im Container läuft ursprünglich nicht dafür gemacht wurde und einige configs im Container anlegt.
Heiner schrieb: > Wie stellt man das an? https://docs.docker.com/engine/reference/commandline/save/ oder https://docs.docker.com/engine/reference/commandline/container_export/ > Und kennt ihr ein "Tool" mit dessen Hilfe man das zb per Weboberfläche > machen kann? Vielleicht ist hier was passendes dabei: https://www.linuxjournal.com/content/search-gui-docker
:
Bearbeitet durch User
Hi, Sehr gute Frage: Wie ist der genau Ablauf um alle Container/Images mit den aktuellen Konfiguration von einem Host auf einen anderen zu portieren? 1. Sichern der aktuellen Änderungen: docker commit [CONTAINER_ID] [new_image_name] 2. Man speichert all Container in ein tar-File ab (Host A): docker save $(docker images -q) -o /path/to/save/mydockersimages.tar 3. Dann läd man das tar-File auf Host B: docker load -i \dockersimages.tar Meine Frage ist: Reicht es aus den Zustand auf Host A mit dem commit Befehl zu speichern? Gruß Andre
Erstmal: Lieber neuen Thread für neue Frage, statt einen Post vom letzten Jahr zu reaktivieren. Andre schrieb: > Reicht es aus den Zustand auf Host A mit dem commit Befehl zu speichern? Hängt davon ab, was du unter "Zustand" verstehst. Gäb' mit "CRIU" auch Software, die unter "Zustand" deutlich mehr als "Dateisystem" versteht, und auch in die Docker-Tools integrierbar wäre. https://criu.org/Docker
Εrnst B. schrieb: > Erstmal: Lieber neuen Thread für neue Frage, statt einen Post vom > letzten Jahr zu reaktivieren. Wenn es jetzt eh zu spät ist... > Hängt davon ab, was du unter "Zustand" verstehst. Gäb' mit "CRIU" auch > Software, die unter "Zustand" deutlich mehr als "Dateisystem" versteht, > und auch in die Docker-Tools integrierbar wäre. All das ist allerdings nicht die Idee von Docker. Die Idee ist, daß ein Prozeß seine zu persistierenden Zustände externalisiert und sich von seinem Image nur durch die Laufzeitkonfiguration unterscheidet... ;-)
Sheeva P. schrieb: > All das ist allerdings nicht die Idee von Docker. Die Idee ist, daß ein > Prozeß seine zu persistierenden Zustände externalisiert und sich von > seinem Image nur durch die Laufzeitkonfiguration unterscheidet... ;-) So sollte es sein. Aber der TE hat das vor einem Jahr anders gemacht: Heiner schrieb: > Grund für dieses vermutlich nicht docker gerechte Verhalten ist das die > Anwendung welche im Container läuft ursprünglich nicht dafür gemacht > wurde und einige configs im Container anlegt. und Andre hat sich diesen Thread ausgesucht (und will "docker commit" verwenden), insofern hat er vmtl. auch das Problem einer schlecht geplanten Docker-Umgebung.
Εrnst B. schrieb: > Erstmal: Lieber neuen Thread für neue Frage, statt einen Post vom > letzten Jahr zu reaktivieren. Sorry für das Reaktivieren des Posts. Εrnst B. schrieb: > Hängt davon ab, was du unter "Zustand" verstehst. Gäb' mit "CRIU" auch > Software, die unter "Zustand" deutlich mehr als "Dateisystem" versteht, > und auch in die Docker-Tools integrierbar wäre. Mit Zustand ist gemeint, dass man mit Docker Board-Mitteln die gleichen Funktionalitäten auf dem Host B wie auf dem Host A herstellen kann. Eine Einschränkung in meinem Fall ist, dass es keine Verbindung zur Außenwelt (Internet) gibt. Deswegen ist der Weg (save/load) über das tar-File schon ok. Wie es scheint, werden mit dem "commit" Befehl nicht die Volumes (persistente Daten) mit gesichert. Gruß Andre
Andre schrieb: > Sorry für das Reaktivieren des Posts. Alles gut. > Εrnst B. schrieb: >> Hängt davon ab, was du unter "Zustand" verstehst. Gäb' mit "CRIU" auch >> Software, die unter "Zustand" deutlich mehr als "Dateisystem" versteht, >> und auch in die Docker-Tools integrierbar wäre. > > Mit Zustand ist gemeint, dass man mit Docker Board-Mitteln die gleichen > Funktionalitäten auf dem Host B wie auf dem Host A herstellen kann. Funktionalität ist nicht das Thema, das geht problemlos. Das Problem sind in Deinem Falle vielmehr die Daten, bzw. die Zustände. > Eine Einschränkung in meinem Fall ist, dass es keine Verbindung zur > Außenwelt (Internet) gibt. Deswegen ist der Weg (save/load) über das > tar-File schon ok. Der Weg ist, Pardon: Mist. Der richtige (TM) Weg wäre eine Registry, in die das Image hochgeladen wird und aus der alle Docker-Hosts das Image ziehen und daraus eine Instanz (Container) erzeugen können. > Wie es scheint, werden mit dem "commit" Befehl nicht die Volumes > (persistente Daten) mit gesichert. Absolut richtig, dafür ist Docker weder gemacht noch gedacht. Docker steht für die Entkoppelung von Daten -- bzw: Zuständen -- und Prozessen. Dabei sind Daten und Zustände etwas sehr Heterogenes; schon bei der Persistenz gibt es etliche Möglichkeiten. Klassisches Master-Slave, moderneres Master-Master, oder richtig modern: Distributed. Was sagen Deine SLAs denn dazu?
> Der Weg ist, Pardon: Mist. Der richtige (TM) Weg wäre eine Registry, in > die das Image hochgeladen wird und aus der alle Docker-Hosts das Image > ziehen und daraus eine Instanz (Container) erzeugen können. > Stimmt, komfortabel ist es bisher nicht. Aber ohne einen eigenen Docker-Hub aufzusetzen, ist es bisher der einzige Weg, den ich bisher gefunden habe.
Andre schrieb: >> Der Weg ist, Pardon: Mist. Der richtige (TM) Weg wäre eine Registry, in >> die das Image hochgeladen wird und aus der alle Docker-Hosts das Image >> ziehen und daraus eine Instanz (Container) erzeugen können. >> > Stimmt, komfortabel ist es bisher nicht. Aber ohne einen eigenen > Docker-Hub aufzusetzen, ist es bisher der einzige Weg, den ich bisher > gefunden habe. Dann setz' doch einen auf?! Mein entsprechendes Composefile sieht etwa so aus:
1 | |
2 | registry: |
3 | image: registry:latest |
4 | restart: always |
5 | depends_on: |
6 | - dnsmasq |
7 | environment: |
8 | REGISTRY_HTTP_ADDR: "0.0.0.0:5000" |
9 | REGISTRY_HTTP_TLS_CERTIFICATE: "/certs/server.crt" |
10 | REGISTRY_HTTP_TLS_KEY: "/certs/server.key" |
11 | REGISTRY_STORAGE_DELETE_ENABLED: "true" |
12 | volumes: |
13 | - "./registry/mounts/certs/:/certs/" |
14 | - "./registry/mounts/data/:/var/lib/registry/" |
15 | ports: |
16 | - "0.0.0.0:5000:5000" |
17 | |
18 | reg: |
19 | image: joxit/docker-registry-ui:static |
20 | restart: always |
21 | depends_on: |
22 | - dnsmasq |
23 | environment: |
24 | VIRTUAL_HOST: "reg.home.sheevaplug.de" |
25 | REGISTRY_URL: "https://registry:5000" |
26 | REGISTRY_TITLE: "registry.home.sheevaplug.de:5000" |
27 | DELETE_IMAGES: "true" |
28 | links: |
29 | - "registry" |
Alles ganz easy, mit einem einfachen Webfrontend, das Komplizierteste (naja) war vielleicht die eigene Certification Authority. ;-)
> Dann setz' doch einen auf?! Mein entsprechendes Composefile sieht etwa > so aus: > > Alles ganz easy, mit einem einfachen Webfrontend, das Komplizierteste > (naja) war vielleicht die eigene Certification Authority. ;-) Super, danke für den Ansatz: Damit wäre die das Erstellen von Tar-Files überflüssig: Aber wie sieht es nun mit den Volumes (Daten) aus? Ich mache es mal konkret: In meiner Docker Umgebung laufen eine Grafana Umgebung in Verbindung mit einer InfluxDB Datenbank. Der Grund warum ich die Volumes brauche, ist, dass ich die Dashboards mit den Queries nicht immer wieder neue erstellen will. Ein anderer Weg wäre die Grafana Rest API, über die man die Dashboards in einem JSON Format ziehen kann und wieder laden könnte. Sollte es jedoch möglich sein die Docker-Volumes des Grafana Images verschieben zu können, könnte man sich das Skripten der RestAPI sparen Ich vermute, es reicht nicht aus den von Grafana erzeugten Inhalt "C:/ownTemp/volume/grafana" einfach zu kopieren? ;)
1 | version: "3" |
2 | services: |
3 | grafana: |
4 | image: grafana/grafana |
5 | container_name: grafana |
6 | restart: always |
7 | ports: |
8 | - 3000:3000 |
9 | networks: |
10 | - grafana_network |
11 | volumes: |
12 | #- grafana_data:/var/lib/grafana
|
13 | - C:/ownTemp/volume/grafana:/var/lib/grafana |
14 | depends_on: |
15 | - influxdb |
16 | |
17 | influxdb: |
18 | image: influxdb:latest |
19 | container_name: influxdb |
20 | restart: always |
21 | ports: |
22 | - 8086:8086 |
23 | networks: |
24 | - grafana_network |
25 | volumes: |
26 | #- influxdb_data:/var/lib/influxdb
|
27 | - C:/ownTemp/volume/influxdb:/var/lib/influxdb |
28 | |
29 | |
30 | networks: |
31 | grafana_network: |
32 | volumes: |
33 | grafana_data: |
34 | influxdb_data: |
Andre schrieb: > volumes: > #- influxdb_data:/var/lib/influxdb > - C:/ownTemp/volume/influxdb:/var/lib/influxdb Tipp: im Gegensatz zu Docker funktioniert docker-compose vom aktuellen Verzeichnis aus. Wenn Deine Volumes in C:\ownTemp\ liegen, dann kannst Du einfach
1 | volume/influxdb:/var/lib/influxdb |
benutzen. Besser wäre aber vielleicht ein Docker Volume, das von Docker verwaltet wird. Aber mit Windows kenne ich mich nicht aus... ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.