-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not put the pdsadmin scripts in the docker image? #187
Comments
+1. I already have a server with Docker and multiple services running with nginx reverse proxy, watchtower etc. I don't want to host a PDS in another fresh Linux VM just for this, it is a waste of resources. I would much rather have a single Docker image I can pull and run for my PDS with a data dir mapped out somewhere so I can back it up with a script. |
... and if you put the whole product inside the container, you automatically get support for hosting on every Linux distro plus Windows. I'm sure there's some kind of history behind it, but in the end you have some stuff running in a container, plus some stuff running on the host (and reaching into the filesystem of the container, and potentially doing who-knows-what else outside of the container). Plus a second container for a front end/reverse proxy. Which precludes having your own, and makes misconfigurations all the more likely. And which apparently goes out and applies for certs for your domain without any warning. And it's all orchestrated by an install script that makes a bunch of undocumented changes to your host system. And it wants to create a subdirectory in your root directory. So you effectively have to provide a Debian-based VM that's totally dedicated to the PDS, and offers no other HTTP-based services even for other domains, let alone other endpoints within the same domain. For somebody who already self-hosts things, which probably means most of the people who'd ever try to self-host a PDS, that raises the cost from $0 (on a host they already have) to about $15/month. And it burns an IP address, which apparently must be IPv4 because nothing else on the AT network supports IPv6. And gives you another machine to admin. And even then it makes undocumented assumptions about the surrounding setup of the DNS (at a minimum, your CAA records had better be what it expects). Yet I still don't think it's going to succeed in making running the PDS either easy or safe for people who don't already know how to admin their own servers. There are tons of unfixable reasons that you have know what you're doing to run Internet-exposed services. I think the ideal would be two supported installation options:
|
If anyone wants a
|
Really you don't even need this, if you don't already have a native system rproxy like nginx running, just use one of the existing rproxy dockers and just a simple config/port map. It's still way more elegant than the install script. The documentation to pull that off would be so much more simple and approachable that it is now.
That's true, 100%, but I should not have to learn nodejs just to update my PDS. The way it is now you end up having to screw around with all that stuff if you don't want to use the script AND don't already have the acoount data folders to map to the docker image (catch 22 if it's your first rodeo). Having the admin scripts would solve all of this, unless I'm missing something (which is possible ha) It looks like @Cronocide posted a pretty cool bit to solve the problem. I'll give that a try this weekend. Thank you! |
Then call it a day! This install script is nonsense and over complicates the whole process.
I'm running just fine atm with only the single docker image, nginx proxy and my original .env & data dir. If the docker image had the pdsadmin script folder embedded then it could just be another volume mapping.
This way the whole install is a docker one-line (or compose file) instead of this crazy script that bloats my system and does everything I do NOT want it to do. So simple, easy and elegant!
The text was updated successfully, but these errors were encountered: