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.
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
- 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
no ref
- I mistakenly didn't realise we don't import our `.env` file and instead populate the settings individually into each container
- This fixes that by just importing it all into the Ghost container which eases importing settings from existing installations
- This will result in a bit of duplication and split env vars but the rest are generally required across multiple containers so it makes sense
- This helps clean up the TB setup since we no longer need to install the CLI tools locally
- The service dependency chaining is a bit annoying here but it should all work
- We have to change some of the mounts around because of how TB works
and where it expects tokens to be
Closes https://linear.app/ghost/issue/ENG-2414
- These two containers must run the same version of Ghost since the TB container uses assets from the Ghost container
- If the two are out of sync we'd be updating or migrating Tinybird to a different set of APIs than what Ghost is expecting which could break things
Closes https://linear.app/ghost/issue/ENG-2413
- This makes migration from standard `ghost-cli` installs to Docker a bit easier and also tries to prevent people from accidentally pruning their Docker volumes are removing data
ref https://linear.app/ghost/issue/ENG-2411
- This doesn't completely solve the 'Ghost mustn't start will AP does' problem _but_ does save it on cold boots or when the whole stack isn't running
- If Ghost is already running it unfortunately wont restart but we can work around that with docs
ref https://linear.app/ghost/issue/PROD-2009
ActivityPub now supports configuring a local storage adapter, we defer
to the ghost service for actually serving the images, so we write to a
shared volume and point our URLs at the Ghost content directory.
no refs
The current setup runs the base Ghost installation without Traffic Analytics functionality. This commit adds:
- `tinybird-sync` service, which copies the latest Tinybird datafiles from the `ghost` container into a shared volume
- `tinybird-deploy` service & Dockerfile that includes the `tb` CLI, and runs `tb --cloud deploy` on boot
- Instructions for one-time manual setup of the Tinybird workspace in `TINYBIRD.md`
After the one-time manual setup, this configuration should automatically update Tinybird's datasources and endpoints in sync with the Ghost container when it is updated.
The initial setup is a bit clumsy and requires more manual steps than expected:
- The tinybird datafiles are in the Ghost image, but we need to access them from the `tinybird-deploy` service, which includes the `tb` CLI.
- When creating a new workspace in Tinybird, you can't access your admin token right away. Instead, it forces you to run `tb login` and `tb --cloud deploy` before you can access the rest of your workspace UI. This requires the user to install the `tb` CLI locally, and run an interactive login to authenticate with their Tinybird workspace. The generated `.tinyb` file is then mounted into the `tinybird-deploy` container, so this is only required for initial setup.
- Ghost requires the Tinybird `stats` and `tracker` token to be provided at boot. This means the user has to manually copy these tokens (either from CLI or the Workspace UI) and add them to their `.env` file manually.
- We may want to either publish the Docker image with the Tinybird CLI installed, or possibly add the `tb` CLI to the traffic-analytics container.
