I would documented everything as I go.
I am a hobbyist running a proxmox server with a docker host for media server, a plex host, a nas host, and home assistant host.
I feel if It were to break It would take me a long time to rebuild.
Ansible everything and automate as you go. It is slower, but if it’s not your first time setting something up it’s not too bad. Right now I literally couldn’t care less if the SD on one of my raspberry pi’s dies. Or my monitoring backend needs to be reinstalled.
IMO ansible is over kill for my homelab. All of my docker containers live on two servers. One remote and one at home. Both are built with docker compose and are backed up along with their data weekly to both servers and third party cloud backup. In the event one of them fails I have two copies of the data and could have everything back up and running in under 30 minutes.
I also don’t like that Ansible is owned by RedHat. They’ve shown recently they have zero care for their users.
I would have taken a deep dive into docker and containerised pretty much everything.
Converting my environment to be mostly containerized was a bit of a slow process that taught me a lot, but now I can try out new applications and configurations at such an accelerated rate it’s crazy. Once I got the hang of Docker (and Ansible) it became so easy to try new things, tear them down and try again. Moving services around, backing up or restoring data is way easier.
I can’t overstate how impactful containerization has been to my self hosting workflow.
Same for me. I’ve known about Docker for many years now but never understood why I would want to use it when I can just as easily install things directly and just never touch them. Then I ran into dependency problems where two pieces of software required different versions of the same library. Docker just made this problem completely trivial.
I wouldn’t change anything, I like fixing things as I go. Doing things right the first time is only nice when I know exactly what I’m doing!
That being said, in my current enviroment, I made a mistake when I discovered docker compose. I saw how wonderfully simply it made deployment and helped with version control and decided to dump every single service into one singular docker-compose.yaml. I would separate services next time into at least their relevant categories for ease of making changes later.
Better yet I would automate deployment with Ansible… But that’s my next step in learning and I can fix both mistakes while I go next time!
I do the same. I use caddy reverse proxy, and find it useful to use the container name for url, and no ports exposed
What is the benefit for making changes with separate files?
If you have relevant containers (e.g. the *arr stack) then you can bring all of them up with a single docker compose command (or pull fresh versions etc.). If everything is in a single file then you have to manually pull/start/stop each container or else you have to do it to everything at once.
This. In addition, I’ve read that it’s best practice to make adding and removing services less of a pain.
You’re not messing with stacks that benefit from extended uptime just to mess around with a few new projects. Considering my wife uses networks that the homelab influences, it would be a smarter choice for me long term to change things up.
I should have learned Ansible earlier.
Docker compose helped me get started with containers but I kept having to push out new config files and manually cycle services. Now I have Ansible roles that can configure and deploy apps from scratch without me even needing to back up config files at all.
Most of my documentation has gone away entirely, I don’t need to remember things when they are defined in code.
