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
no ref
- This adds disk space checks, MySQL connection checks and outputs more informative messages
- We go over what all the changes involve and add an escape hatch in the event that people want to back out or run into issues
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
- Ghost requires env variables to be in a special `__` format which is hard to construct manually
- This script automates that for ease of migration
- Currently doesn't meet our ESLint rules in the slightest so will need tweaking
- This script handles the copy of both assets and the MySQL database
from an existing install to a new Docker based install
- Its currently been tested on the "happy path" of a Ghost CLI install
and works
- Unfortunately the TB CLI doesn't just output the token and instead
tries to copy it to the clipboard
- Since we're running inside a container we can't do that, so need to
just update the docs to get it from the UI
- 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.
