picnicolas@slrpnk.net 2 months ago
I used a similar project called Ansible NAS a while back and it’s been working beautifully. I had a problem and had to reinstall the OS on my NAS at some point and this made it a breeze. That project requires Ubuntu and I prefer Debian so I may try this out next time.
Dylancyclone@programming.dev 2 months ago
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: dylancyclone.github.io/…/introduction/
Or copy-pasted:
- Does not require root to run - Runs containers with minimum privileges (no root unless absolutely necessary) - Allow any application to have it’s name, image name and version overridden (in case of version pinning or running forks) - Does not modify existing system settings/configuration - Separates DNS access from external access (for example, access
portainer.example.comon local network without exposing it to the internet) - Notifies the user of breaking changes in an application’s ansible role before updating them - Everything is optional, doesn’t install anything except what’s configured by the user - Cleans up networks and containers more gracefully after disabling applications, and ensure nothing is left dangling - Supports more OSs than just Ubuntu - Includes suite of tests to ensure clean code and functionality - All created containers and networks are removed when stopping applications - Ensures all applications have consistent variable names and settings - Ensures all applications properly implement DNS and external access settings - Ensures no port conflicts between applications - etcpicnicolas@slrpnk.net 2 months ago
Awesome improvements! Really nice work. I’ll definitely be switching at some point when I have a reason to mess with it. Thanks for all the extra work you’ve done to improve the fork and gift the project to the commons.
moonpiedumplings@programming.dev 2 months ago
Does it require docker installed and being in the docker group, with the docker daemon running?
Just an FYI, having the ability to create containers and do other docker is equivalent to root: docs.docker.com/engine/security/#docker-daemon-at…
It’s not really accurate to say that your playbooks don’t require root to run when they basically do.
Dylancyclone@programming.dev 2 months ago
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 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