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.
