It seems mail.from is required in the latest version (Ghost 6.0), otherwise mail setting won't work, which would result in the following log: "Missing mail.from config, falling back to a generated email address. Please update your config file and set a valid from address"
- The main meaningful change here is commenting the GHOST_VERSION variable
- I've also reordered the blocks to prioritise things in the documented setup flow
- Made various changes to the comments for clarity
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
- 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/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
- 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
- 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
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/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.
