If you’ll let me self promote for a second, this was part of the inspiration for my Ansible Homelab Orchestration project. After dealing with a lot of those projects that practically force you to read through the code to get a working environment, I wanted a way to reproducably spin up my entire homelab should I need to move computers or if my computer dies (both of which have happened, and having a setup like this helped tremendously). So far the ansible playbook supports 117 applications, most of which can be enabled with a single configuration line:

immich_enabled: true
nextcloud_enabled: true

And it will orchestrate all the containers, networks, directories, etc for you with reasonable defaults. All of which can be overwritten, for example to enable extra features like hardware acceleration:

immich_hardware_acceleration: "-cuda"

Or to automatically get a letsencrypt cert and expose the application on a subdomain to the outside world:

immich_available_externally: true

It also comes with scripts and tests to help add your own applications and ensure they work properly

I also spent a lot of time writing the documentation so no one else had to suffer through some of the more complicated applications haha (link)

Edit: I am personally running 74 containers through this setup, complete with backups, automatic ssl cert renewal, and monitoring

deleted by creator

That is very true, I suppose a more accurate way to say it would be the playbook does not need to run as the root user, and can instead use the permissions of a regular user. This lets all the volume mounts be owned by your user, instead of root. I think it’s still an important distinction to make though, since by not running the playbook as root, the playbook can’t directly change any of your server’s settings, and only has the access the user you’re SSHing as has.

Yes, this playbook is intended to orchestrate an already set up environment. I know Ansible can easily install and set up docker (using something like the awesome https://github.com/geerlingguy/ansible-role-docker), but I decided against it (at least for now) for two main reasons: Firstly to avoid becoming the root user, and secondly to avoid the Ansible role installing a second version of Docker, causing things to break. I ran into that myself while testing this playbook, where I had set up a Ubuntu VM, told the installer to install Docker during setup not knowing it would install it through snap, then the Ansible playbook would install docker again through conventional means causing a lot of strange problems. So instead I opted to let the user install docker however they’d like and not have any gotchas like “Remember to add --skip-tags="docker" if you installed Docker during OS installation on Ubuntu” or uninstalling their version of docker for them

This is definitely inspired by ansible-nas! I’d also used it for awhile, and made my own fork to add/fix things since the project has gone a little dormant. I started making so many changes though that I started fresh and it turned it into a whole project of it’s own. You can see a list of differences here: https://dylancyclone.github.io/ansible-homelab-orchestration/guides/introduction/

This project was basically how I learned Ansible haha. It is incredibly powerful and this really only scratches the surface