- We want customers to now copy the example Caddyfile so this still gives people the option but also makes it easier for customers who don't want to redirect themselves
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.
no ref
- As Chris notes this isn't actually required when doing the initial setup/mentioning the specific container you want to deploy
- This standardises us in just doing the `--rm run` command for all of them to keep everything nice and neat
no ref
- By outputting the tokens in the format the `.env` file expects this greatly simplifies the initial setup by just makign it copy -> paste able
- This will mean users don't need to load up the UI and copy/paste tokens at all and can do the whole setup (after they've signed up for TB) from the CLI
no ref
- Since we've created v1 now we can auto-merge new updates + pin digests
- This helps us ensure customers are running the specific version we want
- 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
no ref
- This just makes updates simpler by having Renovate handle them for us via commits
- This means it'll auto bump all minor + match updates to TA images but _not_ major and it'll instead open up a PR
ref
- Use best-practices instead of recommended as its the newer default
- Don't rate limit, just slam us
- Use branch merges over PRs where told to
- Pin all deps not just dev ones
- Everything else that was removed is now just included via `config:best-practices`
ref https://linear.app/ghost/issue/PROD-2270/update-the-ghost-docker-repo-to-use-the-apiv1page-hit-endpoint
The Analytics Service is now using a new versioned endpoint at `/api/v1/page_hit` instead of the `/tb/web_analytics` endpoint. This update's Ghost's configuration to use this new endpoint for the tracker requests.
Note: this will require a docker compose pull to get the latest version of the analytics service, which includes the new versioned endpoint.
ref https://linear.app/ghost/issue/ENG-2435
- Mail must be setup to have a proper functioning Ghost install
- Bulk mail doesn't require env variables but standard SMTP mail does
- We'll update the docs but prompting users in the example env file is a starting point
no ref
- Our docs suggest installation Ghost by default in `/var/www/` so search one level deep for Ghost installations
- If we find any, prompt the user if any of these are the ones they want to migrate otherwise let users prompt for a custom dir
no ref
- Using a passsord on the CLI causes MySQL to print 'mysql: [Warning] Using a password on the command line interface can be insecure.' which doing via environment variables prevents
- This also fixes our other `cut` usages in the event the string has a
`=` in it not printing the whole string
no ref
- The thinking here is this allows users to more easily run multiple Ghost instances on the same server by templating the Ghost port
- Majority wont need this but it also simplifies the message around having to forward traffic if you don't start Caddy
no ref
- 99% of users will want to import their configuration by default so just do it and let users know
- We now just print the config we're importing then continue on
no ref
- Currently we prompt a user for a username to dump their Ghost database with which can be confusing if users can't remember their database details
- The Ghost user _likely_ has the required permissions to dump the database itself so we can first try that without prompting the user and _then_ prompt them if it doesn't work
- We added `--no-tablespaces` to the dump command to try and reduce the likelyhood of hitting users not having the `PROCESS` permission since most hosted DBs don't let this and Ghost's DB setup doesn't require DBs be dumped with that anyway
no ref
- This follows a more Docker standard approach by using MySQL admin's `ping` tool
- `start_interval` and `start_period` are required just to give MySQL a bit of time to start up and create the initial DBs on first boot
- We need to use `$$` to escape the variable in the compose file so it
goes through to the healthcheck as a variable to expanded there
- TB can now be toggled via the UI and setting it via env variables means the setting can never be toggled on/off properly
- Doing it this way lets users control things more
Closes https://linear.app/ghost/issue/ENG-2442/
ref e97d6c027c
- Ghost used to require this to set/manage a UUID in TB/clickhouse but we now use Ghost's generated one directly, instead of requiring it here
- Cleaning this up because otherwise if they don't match the UI and the tracking events don't go to the same bucket
