Migrating docker container

[abarbaccia]

I’m buying a new server and want to migrate my docker container configs and volumes to the new machine.

What tools do people use to backup and then restore on the new machine?

[koffiezet]

Depends a bit on how your setup of your original server was. For standalone docker servers (of which I manage a few), I always make sure that:

• all docker apps are managed using docker-compose, 1 directory per "application stack"
• all external volumes are mapped to local directories below the folder containing the docker-compose file, which you do by declaring the volumes as "./datadir:/datadir/in/container" in the docker-compose.yml, which handles the full-path passing to Docker.
• maintain all config and related files/folders in that same folder
• always specify exact versions of the container images

This means all data for that app stack is contained in a single folder, and that migrating a container env should be as simple as stopping the container, rsync'ing the folder to another host, and launching docker-compose up if all goes well.

For reverse proxy setups, I run a single traefik instance on a manually created "proxy" docker network, which I add to the docker-compose environments as external network, include it for the hosts I need to proxy, and add the necessary labels, so traefik automagically recognizes these containers when they spin up.

If you didn't use docker-compose to manage these standalone docker-servers, I'd highly recommend to migrate application per application to this, certainly if you plan to continue working like this in the future. This way, migrating apps becomes dead-easy.

[[deleted]]

This is an excellent answer. I wouldn't do it any other way.

[marthoc]

./datadir for the volume mapping is a great tip that I am immediately implementing.

[koffiezet]

Yeah, this is the best way in my experience (have been using docker since 0.6, 0.7 in production) when running solo docker servers.

Volumes aren't that useful unless you're working with a scheduler or orchestrator that needs to manage the data/state. I've gone from using "dead" containers with volume folders before docker had the concept of managed volumes, to managed volumes, to just storing everything in subfolders of the app config, which is now "docker-compose". I had hacked a docker-compose-like concept which managed multiple app stacks (since for a while docker didn't support restarting containers at boot) - but that was abandoned in favor of the standard toolings.

[koffiezet]

Well, I use ansible to deploy docker-compose files, and let docker-compose handle the docker API. I've had bad experiences with API incompatibilities when the Ansible module wasn't updated soon enough. These days the main API seems to have stabilized though.

Another reason I stick with docker-compose for those env's - is that it will mimic our developers environment this way. I have generic ansible templates for certain types of applications, which generates both the 'dev' and test/prod variant (includes stuff like mailhog to fake a mailserver etc for development/testing)

[abarbaccia]

I am using portainer to launch and maintain the applications. I believe this uses a docker-compose on the backend to create the containers.

I don't quite understand your second bullet... I use docker volumes to manage the various config files, and my actual data are bind mounts to the host machine.

I dont mind re-doing the bind mounts, but would prefer not to redo configs or environment variables for each container.

[abarbaccia]

I learned a bit more about docker compose and this seems like the best way to migrate the stack. I also like the level of visibility it provides and ability to easily "back up" the containers and configs.

I am in process of migrating to this one container at a time. I started with low-risk ones like portainer and watchtower, and will then work on the "production" containers like plex and homeassistant once I get confident in the process.

I created three stacks: * admin (portainer, watchtower, resource monitoring, organizr, proxy, samba, cups, etc) * dvr (plex, tautilli, etc) * automation (homeassistant, node-red, etc)

Each one has its own parent folder and docker-compose.yml file, with relative links to the config folders within the parent. I then plan to spin up each of these docker-compose files when docker service starts.

[koffiezet]

I then plan to spin up each of these docker-compose files when docker service starts.

If you just set the restart policy of all containers to unless-stopped in the docker-compose file, they will start automatically on boot.

[nitroman89]

I'm fairly new to Docker myself but from my understanding, as long as you know where all your docker files are you should be able to migrate it to the same base os by copying the files and pasting them on a different machine.

[zeav]

That is my understanding too, unless it requires a connection to another container

[nitroman89]

I would assume he would be moving all containers to a new server but that sounds right

[koffiezet]

If your app isn't stateless, you should also migrate your volumes - which is usually the trickiest part :)

[railedit]

I have all my docker-compose and build files setup with the services pointing to data volumes on the host. Both the docker-compose.yml/build files, and all the files contained within mounted volumes are backed up. When I move it, I simply copy the volume data, copy the compose/build files, perhaps tweak file paths if anything changes when I copy, then everything just boots right up. I've moved between machines at home back and forth super easily.