Include pdsadmin in the Docker image

[kyleconroy]

I've deployed my PDS on Render, which uses the Dockerfile in the repository. The Dockerfile doesn't include the pdsadmin.sh script by default. I had to manually pull it down in a shell. Even after that, the script doesn't run by default. First, I needed to install the following packages:

bash
curl
openssl
jq

I also needed to create a dummy text file at /pds/pds.env, even though all the environment variables were already set.

[Jacob2161]

This might make sense but part of the reason pdsadmin is expected to run on the host and not inside the pds container is so that it can do things such as e.g. upgrading the container. But maybe it could exist in the container with a subset of commands.

[kyleconroy]

@Jacob2161 The issue here is that Render doesn't have the concept of running on the host. You only have access to the container itself, which is a common pattern for many hosting providers.

[adamisafk]

Hopefully this helps someone:

I have my own docker stack on my server with my own management of SSL and reverse proxy which I want pds to use instead. I've got it working with this compose item (you'd need to fill in some values, i.e. the volume and the first 4 env vars):

  bluesky:
    container_name: bluesky
    build:
      context: .
      dockerfile_inline: |
        FROM ghcr.io/bluesky-social/pds:0.4
        RUN apk add bash curl openssl jq
        RUN curl --silent --show-error --fail --output "/usr/local/bin/pdsadmin" "https://raw.githubusercontent.com/bluesky-social/pds/main/pdsadmin.sh"
        RUN chmod +x /usr/local/bin/pdsadmin
    restart: unless-stopped
    volumes:
      - [YOUR DIR]:/pds
    environment:
      - PDS_ADMIN_EMAIL=[YOUR EMAIL]
      - PDS_ADMIN_PASSWORD=[YOUR ADMIN PASSWORD]
      - PDS_JWT_SECRET=[GENERATE WITH; openssl rand --hex 16]
      - PDS_PLC_ROTATION_KEY_K256_PRIVATE_KEY_HEX=[GENERATE WITH; openssl ecparam --name secp256k1 --genkey --noout --outform DER | tail --bytes=+8 | head --bytes=32 | xxd --plain --cols 32]
      - PDS_BLOBSTORE_DISK_LOCATION=/pds/blocks
      - PDS_BLOBSTORE_DISK_TMP_LOCATION=/pds/temp
      - PDS_BSKY_APP_VIEW_DID=did:web:api.bsky.app
      - PDS_BSKY_APP_VIEW_URL=https://api.bsky.app
      - PDS_CRAWLERS=https://bsky.network
      - PDS_DATA_DIRECTORY=/pds
      - PDS_DID_PLC_URL=https://plc.directory
      - PDS_HOSTNAME=[YOUR HOSTNAME]
      - PDS_REPORT_SERVICE_DID=did:plc:ar7c4by46qjdydhdevvrndac
      - PDS_REPORT_SERVICE_URL=https://mod.bsky.app

I also created an empty pds.env file in /pds, but I'm not sure if that is necessary.

Then I add a reverse proxy for my PDS_HOSTNAME to bluesky:3000, adding a custom location for my .well-known endpoint that serves plain text.

It's not a great solution because I'll end up having to read installer.sh and edit the env vars and build script every time I update the image. But it works and I can exec into the container and use pdsadmin.

[samanthavbarron]

I ran into this issue as well when trying to install my own PDS with Docker. Seconding @adamisafk that the way to go would be to have these commands available within the container itself.

@Jacob2161: If pdsadmin were to be in the container itself, is upgrading the container the only exception for the functionality intended to be run on the host that you're describing? If that's the case, it seems like that would be better handled by pulling a newer image. Then someone running commands with docker would instead do:

docker exec -it my-pds-container pdsadmin COMMAND

[samanthavbarron]

After poking around a little bit more, I'm wondering what distinguishes what's in the docker image that this repo provides vs the Dockerfile defined here?

Is it just that this repo provides the pdsadmin commands to more easily perform common tasks? If that's the case, then another possibility might be to build on that image here, rather than defining another package here.

I hope I'm not too off-base with this, very new to these projects, but I'm very interested.

[iTim314]

I just ran into this after being extremely apprehensive to run the installer script on a host machine that's running 20-25 other containers. In my opinion, requiring specific software to run on the host defies the very idea of containerization.

I've tried @adamisafk's solution with moderate success; however, I'm unable to run any pdsadmin commands, as they all return curl: (22) The requested URL returned error: 404.

I'll have to revisit this at another point.