move postgres

I would suggest that the safest way would be to create a dump of each database, including the commands to create the database and import into the docker container. You'll find the documentation for pg_dump here - https://www.postgresql.org/docs/11/app-pgdump.html

If you create a text based export, you can then run the resulting script using psql - https://www.postgresql.org/docs/11/app-psql.html

thank you. i think it would be the easiest way. last question:
each database should be a docker or you just have a one docker running?
i mean if you have a database x,y,z on postgres.
after create on docker when you say docker ps
then you have  running 3 postgres docker   .... database-x ...
                                                                              .... database-y ....
                                                                              ..... database-z
or you just have a one running postgres docker and you have many database running on that
?

That would depend upon how you want to run things. There is an argument that it could be more efficient to run a single database so that the one database engine can manage it's buffers across all databases (particularly if they are small databases) but you would have more capability to tune the system if you ran separate containers. The container overhead could become more significant if you do this, though. It's one situation where I would try both configurations to see and I am not sure that anyone can give a definitive answer for you.

Naturally, you could extend this and group different databases into different containers and tune separately. Again, it depends on your requirements and the configurations used.

Remember that databases generally work at their best on physical hardware, with no virtualisation or containerisation and adding layers of software into the mix can cause issues. So, whatever route you take, test thoroughly and measure performance.

1) Backups - follow Martyn's suggestion.

2) Container organization - as Martyn suggested, their are pros + cons for either approach.

Likely the primary consideration will be if the databases are related to the same project.

Generally when I setup containers.

First - I use LXD over Docker, because LXD is designed to manage containers with persistent data, like databases. Docker is geared more toward Ephemeral containers, which keep no state when they die.

Second - Generally I keep all project related files - databases + code (like PHP) - in one container, so I can do database connections over UNIX domain sockets rather than TCP connections, which provide a large performance boost.

As per my view, you can take a dump all the database as a whole or individually database. Once the backup is done, you can start the Postgres docker container. then start restoring the database individually or as a whole.

@Martyn Spencer,
if i create a container for each database, then should change port to connect for each one i mean i can't use 5432 standard port for all container
or what?

ok Thanks,
In the other model if i create all database on one container. How to do that i t? I mean, if i create one conatiner and logon to postgres and create all my 10 databases ,its running until i next restart after restart it's gun.

If you are saying that the container is being destroyed when you restart it, you need to make sure that the container is persistent.

no i mean, i have a container, then login to container and create all databases. what i do in this container is gun when i restart it. or what?

A container and its storage should persist. You can also map external storage inside a container. You can always test this with a single disposable database. Familiarise yourself with how the container software you use works before moving on.