Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Isn't this just duplicating effort that's probably already been done, in many cases by the first-party maintainers, in Dockerfiles?

I don't mean to start 'Docker vs. Ansible', I just wonder why if you wanted a quick way to setup a single-server 'own private cloud' you wouldn't just go with what already exists, and list the images you want in a docker-compose.yaml file?

(Which would additionally set you up for 'scaling' if you had any concern that you might be able to save some cash with a two or three smaller servers than one big one by the time you'd installed everything you want.)



Isn't docker just duplicating effort that's already been done in LXC or jails?


Are LXC and jails polularly used by maintainers of projects like owncloud, readlater, and such that Sovereign installs?

I explicitly said that I wasn't making it about Docker vs. Ansible - I don't care - I just mean that Docker is very often used by first party maintainers (and if not by someone else) to package these services, so use what's there; if it had happened to have been something else that took off in that way, an Ansible playbook say, then that, but it's Dockerfiles that are in that position.


Not everyone wants Docker installed on their servers. It’s not a requirement with this playbook.

Furthermore, if you do want to use containers, there are tools like ansible-bender[1] that use Ansible to build container images.

[1] https://github.com/ansible-community/ansible-bender (edited the link to point to the ansible-community repo)


But I'd have thought if you care that Docker isn't installed on your servers, you're probably not running this anyway?

It seems to me that the target demographic is people that just want the least effort minimal faff way of getting some services up and running for personal non-production use. And for that it was my suggestion that many of the services probably already provide a Dockerfile upstream, so the easiest thing to do would be to install docker-compose, list the images, and `up`.


This project has nothing to do with Docker, and there are many reasons why someone would want to avoid running Docker on a server (a separate issue from using containers). I'm confused about why you think Docker is relevant to this set of Ansible playbooks, and also why this would only be suitable for "personal non-production use."

The only requirement for a remote host to be managed by Ansible is python, and even that can be installed by Ansible itself using the `raw` module on an initial run with nothing but ssh access.

No need to gather a bunch of random Dockerfiles from various places, tweak them to be compatible, and create a docker-compose file from scratch... how is that "the easiest thing" when this is a complete set of Ansible playbooks where the work is already done?


I meant easier than creating these Ansible playbooks from scratch, when many if not all of the playbooks will do the same required steps as have already been encoded in Dockerfiles in many cases by the maintainer of the upstream project (the one being deployed) itself. There certainly could be value in collecting that in one place still.

The first line of the readme says it's for a 'personal cloud'.


The initial commit of this repo is from August 2013, a few months before the first public beta release of docker-compose.


This looks useful. Is the fork more out of date than the source it was forked from, or am I reading the dates wrong?


Oh, good catch, I would use https://github.com/ansible-community/ansible-bender

I just copied the first link that showed up in a search, which looks like it's the personal repo of the project maintainer but is pretty far behind the upstream repo now.


This is dated 2015. I hadn't heard of Docker in 2015.


That's as may be, but it did exist, and was popular.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: