Not able create same restored Rancher server from committed Rancher server container in Docker host

General Discussions
1

docker version
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:10:22 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm

Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:08:52 2018
OS/Arch: linux/amd64
Experimental: false

I have created rancher server with this command below:

sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server

I have worked on the rancher server for some time. Now I want to backup this rancher container and deploy into new rancher container with the same data (Environment, Stacks, Containers … etc) that I have worked earlier in the old rancher server.

I stopped the current running container and I have committed that container into new image. I have created a container from that image. But in that newly created rancher server was empty. The environments, containers, stacks… etc all the configurations are gone.

This the command I have created the rancher server container from that newly created rancher server image:

sudo docker run -d --restart=unless-stopped -e CATTLE_PROMETHEUS_EXPORTER=true -p 8080:8080 -p 9108:9108 ranjith/mainrancher

How to backup and restore container with same data? How to restart the same container with different configurations?

2

As a general rule, you don’t. Before you launch the container you should understand where and how it’s storing data in its filesystem, and use the docker run -v option to mount a persistent external data store there.

This is hopefully documented with each image. In the Rancher documentation I can find write-ups like Rancher Docs: Installing Rancher Server that explain what to run. (P.S. you should read the third paragraph behind that link)

Assume you’ll eventually lose your /var/lib/docker tree (because you’re on a different computer; because a scripted cleanup step cleaned up too much; because of a Docker issue; …) and plan accordingly.