View previous topic :: View next topic |
Author |
Message |
ladmanj n00b
Joined: 16 Feb 2012 Posts: 3
|
Posted: Wed Jan 01, 2025 12:53 am Post subject: Moving all services from old box to new freshly installed |
|
|
Hi all (and happy new year)
I am running a ~20 years old gentoo box.
It was my daily desktop in the early years, then I reused it as family and DIY "busyness" server.
Graphical environment and applications were then purged from the system, and gentoo itself overcome a few crashes due to delayed updates leading to incompatibilities and difficulties upgrading.
The hardware changed slightly over the time, but the mainboard and cpu are now more than 12 years old.
The disks are of several vintages and are not mirrored, my fear of upcoming failure is growing.
There are few services running:
cups network printers, saned network scanner, nfs and samba disks, imap-ssl server,
qemu with dos machine available via vnc, svn server with hundred of projects,
minidlna, ghidra server
gpib interface with custom python server to access measurement instruments from network
lately caddy reverse proxy and
apache with nextcloud
then docker with collabora, homeassistant and inventree
The importance of the services increased over the last months so I bought new components and built a whole new computer.
Because the old box is BIOS one and the new one is UEFI booted, because the old disks containing deposits of history, I chose rather fresh and clean install instead of the system migration.
Now i have all the necessary ebuilds installed and system (systemd) booting, disk array prepared and so on.
I want to start slowly migrating the particular services one by one wherever possible.
Some services are quite easy to move, but some aren't for me.
For example, I don't know where are all the docker images and stuff. I can easily "docker compose" it from scratch, but that's not what I want.
Docker was installed by emerge, but the services weren't.
I don't know where to start and experiencing analysis paralysis.
It can be seen clearly from the fact I wrote this long BS.
But maybe someone did something similar and can reply with a few useful tips.
Thanks in advance |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1355 Location: Richmond Hill, Canada
|
Posted: Wed Jan 01, 2025 1:30 am Post subject: |
|
|
If all the concern is about docker stuff may be I can help. Something else (not docker related) I am not sure.
docker images vs docker container
docker image can be easily transferred with docker image save/load.
docker container is bit of tricky to transfer, so depend on your situation, it is possible to first commit the container into a image then do image transfer or export the file system content in the container then transfer the export to new machine and build a new image with the export. |
|
Back to top |
|
|
Ralphred l33t
Joined: 31 Dec 2013 Posts: 673
|
Posted: Wed Jan 01, 2025 11:03 am Post subject: |
|
|
pingtoo wrote: | it is possible to first commit the container | If you do that does it not create a "disconnect" between the original container and it's source as defined in the compose file?
ladmanj wrote: | For example, I don't know where are all the docker images and stuff. I can easily "docker compose" it from scratch, but that's not what I want. | If you can docker compose down and up the service without "breaking" it then all the directories/files you need to copy are outlined in the compose file, for example HASS Code: | homeassistant:
container_name: HomeAssistant
image: "ghcr.io/home-assistant/home-assistant:stable"
volumes:
- /path/to/local/config/hass:/config
- /etc/localtime:/etc/localtime:ro
- /run/dbus:/run/dbus:ro
- /etc/letsencrypt/:/config/ssl:ro | So in this case /path/to/local/config/hass contains all the data/config needed to turn the default image: entry into "your HASS set-up".
If you can't down/up the containers without them breaking then you can just copy /var/lib/docker, but YMMV as you have already said you can't update so may fall foul of a version mismatch, but it's worth a try, you can always "reinstall docker"* and return the folder to its default state if it gets messed up. *or make a backup.
ladmanj wrote: | I don't know where to start and experiencing analysis paralysis.
But maybe someone did something similar and can reply with a few useful tips. |
It's quite easy to get caught up in "the software analysis" and end up spiralling; think about it from the "service" perspective, pick the easiest ones, move them, test them, then alter the firewall to finish the "transition" - if this means you end up having to alter some configs (like changing "localhost" to an FQDN or IP) for services with dependencies/dependants still on the original server then just roll with it. Before long you be down to the only few services that require some serious reading to duplicate, but by reducing the load on the original hardware you have also bought yourself more time to move them, "softly, softly, catchee monkey" is the key. Rome wasn't built in a day, and neither was you existing server: Making a simple TODO list and storing config snippets, useful URLs and your own notes takes the mental/memory pressure off too - you get to mentally file it as "taken care of" because you know all the info that you may need is at your fingertips. |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1355 Location: Richmond Hill, Canada
|
Posted: Wed Jan 01, 2025 3:11 pm Post subject: |
|
|
Ralphred wrote: | pingtoo wrote: | it is possible to first commit the container | If you do that does it not create a "disconnect" between the original container and it's source as defined in the compose file? | I am not sure I understand this question.
Once container is committed, it is like a freeze dry copy of the original container. so it is like backup. The freeze dry copy cannot be use directly by the original compose file because it will have different image name. |
|
Back to top |
|
|
Ralphred l33t
Joined: 31 Dec 2013 Posts: 673
|
Posted: Wed Jan 01, 2025 9:49 pm Post subject: |
|
|
pingtoo wrote: | I am not sure I understand this question. | Maybe you don't, but you did answer it : "The freeze dry copy cannot be use directly by the original compose file".
So when the compose file pulls a "latest" image, the freeze dried image would be for the older/original version, not the one (updated in the background) of the "image: [URL]" from the compose file.
You really should have more confidence in your English Pingtoo; I, an Englishman, understand you every time. Plus I know we speak the same dialect of Linux . |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1355 Location: Richmond Hill, Canada
|
Posted: Wed Jan 01, 2025 10:04 pm Post subject: |
|
|
Ralphred wrote: | pingtoo wrote: | I am not sure I understand this question. | Maybe you don't, but you did answer it : "The freeze dry copy cannot be use directly by the original compose file".
So when the compose file pulls a "latest" image, the freeze dried image would be for the older/original version, not the one (updated in the background) of the "image: [URL]" from the compose file.
You really should have more confidence in your English Pingtoo; I, an Englishman, understand you every time. Plus I know we speak the same dialect of Linux . |
Thank you very much for your compliment.
In docker term. The committed container. sometime missing lots of docker configuration, for example the network setup (--network [default|host|none]) or -e <environment variable setting> list so it is more of way for quick backup and may be use for transfer. but it need some work to get it back to its original state.
I bring up as some sort of last resort in case it is not possible to find more up to date image for the desired service. there are someway to inspect the running container to get docker setting so it can be reused in new environment, |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|