Skip to content
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

Open
agaskins opened this issue Dec 22, 2024 · 4 comments
Open

Why not put the pdsadmin scripts in the docker image? #187

agaskins opened this issue Dec 22, 2024 · 4 comments

Comments

@agaskins
Copy link

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!

@jacobpretorius
Copy link

+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.

@jbash
Copy link

jbash commented Feb 13, 2025

... 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:

  • One container that listens on one or two well-defined HTTP ports, with the user providing any needed front end HTTP server. And if you're going to interact with CAs on the user's behalf, warn the user and make it optional.
  • Raw node.js running on user-provided everything.

@Cronocide
Copy link

If anyone wants a Dockerfile that includes pdsadmin, here's one:

FROM ghcr.io/bluesky-social/pds:latest
RUN wget "https://github.com/bluesky-social/pds/raw/refs/heads/main/pdsadmin.sh" -O /bin/pdsadmin && sed -i 's#--force#-f#' /bin/pdsadmin && chmod +x pdsadmin
RUN apk add bash curl jq util-linux
RUN env > ${PDS_DATA_DIRECTORY}/pds.env

@agaskins
Copy link
Author

agaskins commented Feb 22, 2025

@jbash

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.

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.

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.

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants