Comment

Comment on Selfhosting Sunday - What's up?

sugar_in_your_tea@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

Docker compose is great! Good luck!

I’ve been moving from docker compose to podman, and I think that’s the better long term plan for me. However, the wins here are pretty marginal, so I don’t recommend it unless you want those marginal wins and everything is already in containers. IMO: Podman > docker compose >>>no containers. Docker compose has way better examples online, so stick with that until you feel like tinkering.

source

Sort:hotnew top

TK420@lemmy.world ⁨2⁩ ⁨weeks⁩ ago
I really like the idea of containers, it def solves my problems of running multiple services in the host OS. I’d like to build my own containers to pull the few “bare metal” services I’ll have outside of docker. Anyway, I’ll keep podman in the back of my head.

One thing I’m already happy I did was create a docker directory and having sub directories keep all of my container volumes separate. Should make backing things up easier as well.

source
- sugar_in_your_tea@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago
  Yeah, containers are great! It’s really nice knowing exactly which directories to move if I need to rebalance my services onto other hardware or something.
  
  Most of my services are on my NAS, so I have this setup:
  
  /srv/nas/<folder> - everything here is on my RAID, and offsite backups look here (and exclude certain directories to save on cost
  
  /home/<user>/containers - my git repo with configs, sans passwords/keys
  
  configs w/keys live in my password manager
  
  Disaster recovery should be as simple as:
  
  Copy my data from backup into /srv/nas
  
  Clone my container repo
  
  Copy env files to their respective locations
  
  Run a script to get things set up
  
  I use specific container versions, so I should get exactly the same setup.
  
  I’m going to be reinstalling my NAS soon (boot drive is getting old), so we’ll see how this process works, though I’ll skip step 1 since I’m keeping the drives.
  
  source