no ref
Refactored the activitypub env vars:
- Removed `USE_MQ` as this is only required when the value needs to be set to `true`
- Removed `PORT` as the application is now running on port 8080 by default
- Removed `ALLOW_PRIVATE_ADDRES` as this is not needed for `production` environment
- Added `ACTIVITYPUB_COLLECTION_PAGE_SIZE` as this is required for the
`following` dispatcher to work correctly
- Added link to documented env vars
ref: https://github.com/TryGhost/ghost-docker/pull/40
- Docker published RC2 on Friday I think
- Note 1: I just cut RC3, but that won't be available yet!
- Note 2: we prob need to rethink how we do versioning so we aren't pinning to exact versions
This will only have an effect when the version isn't set in the .env file and we have it in the .env.example but did still need updating as the fallback.
- Our setup docs recommend having Ghost Admin on a separate domain from the content domain
- This lets users optionally set this up if they want whilst continuing to align Admin <-> content domain through templates
no ref
- The goal here is to be able to provide more functionality to self-hosters through snippets and other segmented config
- Some customers run Admin <-> content domains on separate ones which our current config doesn't support
- Our current config also hardcodes a www redirect which complicates setups when you don't have that domain setup or don't even want it
- Moving to a default template customers will have to copy which includes snippets allows us to update these later on without breaking peoples setups
ref https://linear.app/ghost/issue/PROD-2300/add-file-based-salt-store-for-self-hosters
In the analytics service, we generate user signatures based on a randomly generated salt per site_uuid. The salts are regenerated every day at midnight UTC so we can't pass a static value, and they need to be persisted throughout the day so the same user (based on IP and user agent) will generate the same signature in any given day.
We use an adapter-like pattern for the persistence of the salts — the default is a MemoryStore intended for local development, and we use Firestore in production. The MemoryStore appears to work well enough, but if the analytics service container is rebooted (i.e. during an update), all the salts from the current day will be lost, and it will skew the "unique visitors" and related metrics.
This PR adds the configuration to use a simple file based store for the salts, and a volume mounted into the Traffic Analytics service for persistent storage. This was the salts are persisted across container reboots, which avoids skewing the unique visitors metrics.
There are no additional setup steps required — all sites can use the same configuration, and the volumes are managed by docker compose.
- AP migration should be tagged along with the main AP instance to keep things in line
- Renovate will now group them together so it bumps them at the same time in the same PR/commit etc to keep things aligned
- Moving to specific version pinning as well to make the renovate diffs clearer
