Docker Container verschieben

[Heiner (Gast)]

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.

[Rolf M. (rmagnus)]

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

[Andre (Gast)]

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

[Εrnst B. (ernst)]

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

[Sheeva P. (sheevaplug)]

Ε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... ;-)

[Εrnst B. (ernst)]

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.

[Andre (Gast)]

Ε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

[Sheeva P. (sheevaplug)]

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?

[Andre (Gast)]

> 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.

[Sheeva P. (sheevaplug)]

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:

        
  registry:
    image: registry:latest
    restart: always
    depends_on:
      - dnsmasq
    environment:
      REGISTRY_HTTP_ADDR: "0.0.0.0:5000"
      REGISTRY_HTTP_TLS_CERTIFICATE: "/certs/server.crt"
      REGISTRY_HTTP_TLS_KEY: "/certs/server.key"
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
    volumes:
      - "./registry/mounts/certs/:/certs/"
      - "./registry/mounts/data/:/var/lib/registry/"
    ports:
      - "0.0.0.0:5000:5000"

  reg:
    image: joxit/docker-registry-ui:static
    restart: always
    depends_on:
      - dnsmasq
    environment:
      VIRTUAL_HOST: "reg.home.sheevaplug.de"
      REGISTRY_URL: "https://registry:5000"
      REGISTRY_TITLE: "registry.home.sheevaplug.de:5000"
      DELETE_IMAGES: "true"
    links:
      - "registry"

Alles ganz easy, mit einem einfachen Webfrontend, das Komplizierteste 
(naja) war vielleicht die eigene Certification Authority. ;-)

[Andre (Gast)]

> 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? ;)

version: "3"
services:
  grafana:
    image: grafana/grafana
    container_name: grafana
    restart: always
    ports:
      - 3000:3000
    networks:
      - grafana_network
    volumes:
      #- grafana_data:/var/lib/grafana
      - C:/ownTemp/volume/grafana:/var/lib/grafana
    depends_on:
      - influxdb

  influxdb:
    image: influxdb:latest
    container_name: influxdb
    restart: always
    ports:
      - 8086:8086
    networks:
      - grafana_network
    volumes:
      #- influxdb_data:/var/lib/influxdb
      - C:/ownTemp/volume/influxdb:/var/lib/influxdb

     
networks:
  grafana_network:
volumes:
  grafana_data:
  influxdb_data:

[Sheeva P. (sheevaplug)]

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

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... ;-)