0
Fork 0
mirror of https://github.com/TryGhost/Ghost.git synced 2025-03-04 02:01:58 -05:00
ghost/compose.yml

306 lines
16 KiB
YAML
Raw Normal View History

name: ghost
services:
ghost:
build:
context: .
dockerfile: ./.docker/Dockerfile
target: development
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
entrypoint: ["/home/ghost/.docker/development.entrypoint.sh"]
command: ["yarn", "dev"]
ports:
- "2368:2368" # Ghost
- "4200:4200" # Admin
- "4201:4201" # Admin tests
- "4173:4173" # Lexical
- "41730:41730" # Lexical HTTPS
- "4175:4175" # Portal
- "4176:4176" # Portal HTTPS
- "4177:4177" # Announcement bar
- "4178:4178" # Search
- "6174:6174" # Signup form
- "7173:7173" # Comments
- "7174:7174" # Comments HTTPS
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
profiles: [ full ]
volumes:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
# Mount the source code
- .:/home/ghost
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
# Volume exclusions:
## Prevent collisions between host and container node_modules
- node_modules_ghost_root:/home/ghost/node_modules:delegated
- node_modules_ghost_activitypub:/home/ghost/ghost/activitypub/node_modules:delegated
- node_modules_ghost_adapter-cache-memory-ttl:/home/ghost/ghost/adapter-cache-memory-ttl/node_modules:delegated
- node_modules_ghost_adapter-cache-redis:/home/ghost/ghost/adapter-cache-redis/node_modules:delegated
- node_modules_ghost_adapter-manager:/home/ghost/ghost/adapter-manager/node_modules:delegated
- node_modules_ghost_admin:/home/ghost/ghost/admin/node_modules:delegated
- node_modules_ghost_announcement-bar-settings:/home/ghost/ghost/announcement-bar-settings/node_modules:delegated
- node_modules_ghost_api-framework:/home/ghost/ghost/api-framework/node_modules:delegated
- node_modules_ghost_api-version-compatibility-service:/home/ghost/ghost/api-version-compatibility-service/node_modules:delegated
- node_modules_ghost_audience-feedback:/home/ghost/ghost/audience-feedback/node_modules:delegated
- node_modules_ghost_bookshelf-repository:/home/ghost/ghost/bookshelf-repository/node_modules:delegated
- node_modules_ghost_bootstrap-socket:/home/ghost/ghost/bootstrap-socket/node_modules:delegated
- node_modules_ghost_captcha-service:/home/ghost/ghost/captcha-service/node_modules:delegated
- node_modules_ghost_constants:/home/ghost/ghost/constants/node_modules:delegated
- node_modules_ghost_core:/home/ghost/ghost/core/node_modules:delegated
- node_modules_ghost_custom-fonts:/home/ghost/ghost/custom-fonts/node_modules:delegated
- node_modules_ghost_custom-theme-settings-service:/home/ghost/ghost/custom-theme-settings-service/node_modules:delegated
- node_modules_ghost_data-generator:/home/ghost/ghost/data-generator/node_modules:delegated
- node_modules_ghost_domain-events:/home/ghost/ghost/domain-events/node_modules:delegated
- node_modules_ghost_donations:/home/ghost/ghost/donations/node_modules:delegated
- node_modules_ghost_dynamic-routing-events:/home/ghost/ghost/dynamic-routing-events/node_modules:delegated
- node_modules_ghost_email-addresses:/home/ghost/ghost/email-addresses/node_modules:delegated
- node_modules_ghost_email-analytics-provider-mailgun:/home/ghost/ghost/email-analytics-provider-mailgun/node_modules:delegated
- node_modules_ghost_email-analytics-service:/home/ghost/ghost/email-analytics-service/node_modules:delegated
- node_modules_ghost_email-content-generator:/home/ghost/ghost/email-content-generator/node_modules:delegated
- node_modules_ghost_email-events:/home/ghost/ghost/email-events/node_modules:delegated
- node_modules_ghost_email-service:/home/ghost/ghost/email-service/node_modules:delegated
- node_modules_ghost_email-suppression-list:/home/ghost/ghost/email-suppression-list/node_modules:delegated
- node_modules_ghost_express-dynamic-redirects:/home/ghost/ghost/express-dynamic-redirects/node_modules:delegated
- node_modules_ghost_external-media-inliner:/home/ghost/ghost/external-media-inliner/node_modules:delegated
- node_modules_ghost_ghost:/home/ghost/ghost/ghost/node_modules:delegated
- node_modules_ghost_html-to-plaintext:/home/ghost/ghost/html-to-plaintext/node_modules:delegated
- node_modules_ghost_i18n:/home/ghost/ghost/i18n/node_modules:delegated
- node_modules_ghost_identity-token-service:/home/ghost/ghost/identity-token-service/node_modules:delegated
- node_modules_ghost_importer-handler-content-files:/home/ghost/ghost/importer-handler-content-files/node_modules:delegated
- node_modules_ghost_importer-revue:/home/ghost/ghost/importer-revue/node_modules:delegated
- node_modules_ghost_in-memory-repository:/home/ghost/ghost/in-memory-repository/node_modules:delegated
- node_modules_ghost_job-manager:/home/ghost/ghost/job-manager/node_modules:delegated
- node_modules_ghost_link-redirects:/home/ghost/ghost/link-redirects/node_modules:delegated
- node_modules_ghost_link-replacer:/home/ghost/ghost/link-replacer/node_modules:delegated
- node_modules_ghost_link-tracking:/home/ghost/ghost/link-tracking/node_modules:delegated
- node_modules_ghost_magic-link:/home/ghost/ghost/magic-link/node_modules:delegated
- node_modules_ghost_mail-events:/home/ghost/ghost/mail-events/node_modules:delegated
- node_modules_ghost_mailgun-client:/home/ghost/ghost/mailgun-client/node_modules:delegated
- node_modules_ghost_member-attribution:/home/ghost/ghost/member-attribution/node_modules:delegated
- node_modules_ghost_member-events:/home/ghost/ghost/member-events/node_modules:delegated
- node_modules_ghost_members-api:/home/ghost/ghost/members-api/node_modules:delegated
- node_modules_ghost_members-csv:/home/ghost/ghost/members-csv/node_modules:delegated
- node_modules_ghost_members-events-service:/home/ghost/ghost/members-events-service/node_modules:delegated
- node_modules_ghost_members-importer:/home/ghost/ghost/members-importer/node_modules:delegated
- node_modules_ghost_members-ssr:/home/ghost/ghost/members-ssr/node_modules:delegated
- node_modules_ghost_mentions-email-report:/home/ghost/ghost/mentions-email-report/node_modules:delegated
- node_modules_ghost_metrics-server:/home/ghost/ghost/metrics-server/node_modules:delegated
- node_modules_ghost_milestones:/home/ghost/ghost/milestones/node_modules:delegated
- node_modules_ghost_minifier:/home/ghost/ghost/minifier/node_modules:delegated
- node_modules_ghost_model-to-domain-event-interceptor:/home/ghost/ghost/model-to-domain-event-interceptor/node_modules:delegated
- node_modules_ghost_mw-api-version-mismatch:/home/ghost/ghost/mw-api-version-mismatch/node_modules:delegated
- node_modules_ghost_mw-cache-control:/home/ghost/ghost/mw-cache-control/node_modules:delegated
- node_modules_ghost_mw-error-handler:/home/ghost/ghost/mw-error-handler/node_modules:delegated
- node_modules_ghost_mw-session-from-token:/home/ghost/ghost/mw-session-from-token/node_modules:delegated
- node_modules_ghost_mw-update-user-last-seen:/home/ghost/ghost/mw-update-user-last-seen/node_modules:delegated
- node_modules_ghost_mw-version-match:/home/ghost/ghost/mw-version-match/node_modules:delegated
- node_modules_ghost_mw-vhost:/home/ghost/ghost/mw-vhost/node_modules:delegated
- node_modules_ghost_nql-filter-expansions:/home/ghost/ghost/nql-filter-expansions/node_modules:delegated
- node_modules_ghost_oembed-service:/home/ghost/ghost/oembed-service/node_modules:delegated
- node_modules_ghost_offers:/home/ghost/ghost/offers/node_modules:delegated
- node_modules_ghost_package-json:/home/ghost/ghost/package-json/node_modules:delegated
- node_modules_ghost_payments:/home/ghost/ghost/payments/node_modules:delegated
- node_modules_ghost_post-events:/home/ghost/ghost/post-events/node_modules:delegated
- node_modules_ghost_post-revisions:/home/ghost/ghost/post-revisions/node_modules:delegated
- node_modules_ghost_posts-service:/home/ghost/ghost/posts-service/node_modules:delegated
- node_modules_ghost_prometheus-metrics:/home/ghost/ghost/prometheus-metrics/node_modules:delegated
- node_modules_ghost_recommendations:/home/ghost/ghost/recommendations/node_modules:delegated
- node_modules_ghost_referrers:/home/ghost/ghost/referrers/node_modules:delegated
- node_modules_ghost_security:/home/ghost/ghost/security/node_modules:delegated
- node_modules_ghost_session-service:/home/ghost/ghost/session-service/node_modules:delegated
- node_modules_ghost_settings-path-manager:/home/ghost/ghost/settings-path-manager/node_modules:delegated
- node_modules_ghost_slack-notifications:/home/ghost/ghost/slack-notifications/node_modules:delegated
- node_modules_ghost_staff-service:/home/ghost/ghost/staff-service/node_modules:delegated
- node_modules_ghost_stats-service:/home/ghost/ghost/stats-service/node_modules:delegated
- node_modules_ghost_stripe:/home/ghost/ghost/stripe/node_modules:delegated
- node_modules_ghost_tiers:/home/ghost/ghost/tiers/node_modules:delegated
- node_modules_ghost_update-check-service:/home/ghost/ghost/update-check-service/node_modules:delegated
- node_modules_ghost_verification-trigger:/home/ghost/ghost/verification-trigger/node_modules:delegated
- node_modules_ghost_version-notifications-data-service:/home/ghost/ghost/version-notifications-data-service/node_modules:delegated
- node_modules_ghost_webmentions:/home/ghost/ghost/webmentions/node_modules:delegated
- node_modules_apps_admin-x-activitypub:/home/ghost/apps/admin-x-activitypub/node_modules:delegated
- node_modules_apps_admin-x-demo:/home/ghost/apps/admin-x-demo/node_modules:delegated
- node_modules_apps_admin-x-design-system:/home/ghost/apps/admin-x-design-system/node_modules:delegated
- node_modules_apps_admin-x-framework:/home/ghost/apps/admin-x-framework/node_modules:delegated
- node_modules_apps_admin-x-settings:/home/ghost/apps/admin-x-settings/node_modules:delegated
- node_modules_apps_announcement-bar:/home/ghost/apps/announcement-bar/node_modules:delegated
- node_modules_apps_comments-ui:/home/ghost/apps/comments-ui/node_modules:delegated
- node_modules_apps_portal:/home/ghost/apps/portal/node_modules:delegated
- node_modules_apps_posts:/home/ghost/apps/posts/node_modules:delegated
- node_modules_apps_shade:/home/ghost/apps/shade/node_modules:delegated
- node_modules_apps_signup-form:/home/ghost/apps/signup-form/node_modules:delegated
- node_modules_apps_sodo-search:/home/ghost/apps/sodo-search/node_modules:delegated
tty: true
depends_on:
mysql:
condition: service_healthy
redis:
condition: service_healthy
environment:
- DEBUG=${DEBUG:-}
- GHOST_DEV_APP_FLAGS=${GHOST_DEV_APP_FLAGS:-}
- STRIPE_SECRET_KEY=${STRIPE_SECRET_KEY:-}
- STRIPE_PUBLISHABLE_KEY=${STRIPE_PUBLISHABLE_KEY:-}
- STRIPE_ACCOUNT_ID=${STRIPE_ACCOUNT_ID:-}
mysql:
image: mysql:8.0.35
container_name: ghost-mysql
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
command: --innodb-buffer-pool-size=1G --innodb-log-buffer-size=500M
--innodb-change-buffer-max-size=50 --innodb-flush-log-at-trx_commit=0
--innodb-flush-method=O_DIRECT
ports:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
- 3306:3306
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: ghost
restart: always
volumes:
- ./.docker/mysql-preload:/docker-entrypoint-initdb.d
- mysql-data:/var/lib/mysql
healthcheck:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
test: mysql -uroot -proot ghost -e 'select 1'
interval: 1s
retries: 120
redis:
image: redis:7.0
container_name: ghost-redis
ports:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
- 6379:6379
restart: always
volumes:
- redis-data:/data
healthcheck:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
test:
- CMD
- redis-cli
- --raw
- incr
- ping
interval: 1s
retries: 120
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
prometheus:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
profiles: [ monitoring ]
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
image: prom/prometheus:v2.30.3
container_name: ghost-prometheus
ports:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
- 9090:9090
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
restart: always
volumes:
- ./.docker/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
grafana:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
profiles: [ monitoring ]
image: grafana/grafana:8.3.0
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
container_name: ghost-grafana
ports:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
- 3000:3000
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
restart: always
environment:
- GF_AUTH_ANONYMOUS_ENABLED=true
- GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
Added prometheus and grafana services to docker compose (#21213) ref https://linear.app/tryghost/issue/ENG-1591/add-prometheus-and-grafana-services-to-docker-compose This commit adds 2 new services to the docker compose file to enable monitoring metrics from Ghost locally in real-time: 1. Prometheus - a service that scrapes Ghost's new `/metrics` endpoint introduced in this [commit](https://github.com/TryGhost/Ghost/commit/768336efad067241ca848027f4ac758148ca3e29). 2. Grafana - a service that consumes the metrics from prometheus and exposes them in a dashboard that you can view locally at `localhost:3000`. # Usage Both of these services are selectively enabled using docker compose [profiles](https://docs.docker.com/compose/how-tos/profiles/). This way, if you don't opt-in to using these monitoring tools, they won't start and consume resources on your host machine. To enable these services, enable the `monitoring` profile by either setting the `COMPOSE_PROFILES` environment variable to `monitoring`, or specifying the `--profile monitoring` CLI argument to any `docker compose ...` commands. I've found the easiest way to configure this in an 'always on' fashion is to create a `.env` file in the project's root directory and add `COMPOSE_PROFILES=monitoring` to it. As an added convenience, you can also set `COMPOSE_FILE=.github/scripts/docker-compose.yml`, which will allow you to run `docker compose ...` commands from the root directory without specifying the full path each time. # Intended for development only These services are meant for local development only, and are not configured for a production use-case. For example, the Grafana instance is configured to have _no authorization_ so you won't need a username/password to login at `localhost:3000`. Prometheus is also configured to scrape the metrics once every second, which is likely excessive for production use-cases, but may be useful for getting more granular metrics while e.g. load testing locally. # Dashboards The Grafana instance includes a default dashboard including most of the main default metrics provided by our prometheus client integration. The dashboard is defined in a JSON file at `.github/scripts/docker/grafana/dashboards/main-dashboard.json' and can be modified & committed to add new visualizations that will be available to anyone work on Ghost locally. You can also add other dashboards to the same directory for specific use-cases, which should be picked up and made available in the Grafana UI. [Read more](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/view-dashboard-json-model/) about Grafana's JSON schema for dashboards.
2024-10-03 14:43:07 -07:00
volumes:
- ./.docker/grafana/datasources:/etc/grafana/provisioning/datasources
- ./.docker/grafana/dashboard.yml:/etc/grafana/provisioning/dashboards/main.yaml
- ./.docker/grafana/dashboards:/var/lib/grafana/dashboards
Added ability to push prometheus metrics to a pushgateway (#21526) ref https://linear.app/ghost/issue/ENG-1746/enable-ghost-to-push-metrics-to-a-pushgateway - We'd like to use prometheus to expose metrics from Ghost, but the "standard" approach of having prometheus scrape the `/metrics` endpoint adds some complexity and additional challenges on Pro. - A suggested simpler alternative is to use a pushgateway, to have Ghost _push_ metrics to prometheus, rather than have prometheus scrape the running instances. - This PR introduces this functionality behind a configuration. - It also includes a refactor to the current metrics-server implementation so all the related code for prometheus is colocated, and the configuration is a bit more organized. `@tryghost/metrics-server` has been renamed to `@tryghost/prometheus-metrics`, and it now includes the metrics server and prometheus-client code itself (including the pushgateway code) - To enable the prometheus client alone, `prometheus:enabled` must be true. This will _not_ enable the metrics server or the pushgateway — it will essentially collect the metrics, but not do anything with them. - To enable the metrics server, set `prometheus:metrics_server:enabled` to true. You can also configure the host and port that the metrics server should export the `/metrics` endpoint on in the `prometheus:metrics_server` block. - To enable the pushgateway, set `prometheus:pushgateway:enabled` to true. You can also configure the pushgateway's `url`, the `interval` it should push metrics in (in milliseconds) and the `jobName` in the `prometheus:pushgateway` block.
2024-11-05 11:50:39 -08:00
pushgateway:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
profiles: [ monitoring ]
Added ability to push prometheus metrics to a pushgateway (#21526) ref https://linear.app/ghost/issue/ENG-1746/enable-ghost-to-push-metrics-to-a-pushgateway - We'd like to use prometheus to expose metrics from Ghost, but the "standard" approach of having prometheus scrape the `/metrics` endpoint adds some complexity and additional challenges on Pro. - A suggested simpler alternative is to use a pushgateway, to have Ghost _push_ metrics to prometheus, rather than have prometheus scrape the running instances. - This PR introduces this functionality behind a configuration. - It also includes a refactor to the current metrics-server implementation so all the related code for prometheus is colocated, and the configuration is a bit more organized. `@tryghost/metrics-server` has been renamed to `@tryghost/prometheus-metrics`, and it now includes the metrics server and prometheus-client code itself (including the pushgateway code) - To enable the prometheus client alone, `prometheus:enabled` must be true. This will _not_ enable the metrics server or the pushgateway — it will essentially collect the metrics, but not do anything with them. - To enable the metrics server, set `prometheus:metrics_server:enabled` to true. You can also configure the host and port that the metrics server should export the `/metrics` endpoint on in the `prometheus:metrics_server` block. - To enable the pushgateway, set `prometheus:pushgateway:enabled` to true. You can also configure the pushgateway's `url`, the `interval` it should push metrics in (in milliseconds) and the `jobName` in the `prometheus:pushgateway` block.
2024-11-05 11:50:39 -08:00
image: prom/pushgateway:v1.6.0
container_name: ghost-pushgateway
ports:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
- 9091:9091
volumes:
Improved docker development setup (#22177) no issue This commit is a fairly significant rework of the docker development setup, with the goal of improving the performance of the Ghost container and generally improving the DX of the docker development setup. **Enumerating `node_modules` directories as volume exclusions for the bind mount** - The main source of performance overhead with the docker setup is the bind mount, which mounts all the code into the container. Especially on macOS, the bind mount introduces quite a bit of file system overhead. Currently the bind mount includes all the `node_modules` directories, which adds up to many thousands of files in the bind mount. This change attempts to reduce this overhead by mounting in named volumes for each `node_modules` directory in the monorepo, which effectively tells the main bind mount to ignore these directories, thus reducing the filesystem overhead. **Removing the `yarn install` from the entrypoint script and the `yarn setup:docker` step** - This change has two more benefits: since all the `node_modules` are installed into named volumes, we can now be confident that our local `node_modules` won't conflict with the `node_modules` in the container. Therefore, we can install `node_modules` at build time in the Dockerfile instead of in the entrypoint script, and we can also get rid of the `yarn setup:docker` setup command, which nukes your local `node_modules` before building the container. **Build optimization - enumerating all `package.json` files** - In a typical node app's Dockerfile, you copy the `package.json` and `yarn.lock` files into the container first, then run `yarn install`, then copy the rest of the code in. This takes advantage of Docker's build cache to avoid having to reinstall `node_modules` on every build if you've only changed code files, but not any dependencies. - This is more challenging to do with the monorepo since we have many `package.json` files. This commit brute forces our way through that by copying every single `package.json` file in the Dockerfile before installing dependencies and copying the code in. The result is that Docker builds become much faster, after the initial full build. **Additional scripts** - Since enumerating all the `node_modules` directories and `package.json` files is tedious to do manually, this commit also includes two new scripts to automate this work. Ideally we'll eventually integrate these scripts with Slimer, so when you add a new package to the monorepo it automatically updates the `Dockerfile` and `compose.yml`, but for now we can manage that ourselves since it's a fairly rare occurrence.
2025-02-18 15:47:39 -08:00
mysql-data: {}
redis-data: {}
node_modules_ghost_root: {}
node_modules_ghost_activitypub: {}
node_modules_ghost_adapter-cache-memory-ttl: {}
node_modules_ghost_adapter-cache-redis: {}
node_modules_ghost_adapter-manager: {}
node_modules_ghost_admin: {}
node_modules_ghost_announcement-bar-settings: {}
node_modules_ghost_api-framework: {}
node_modules_ghost_api-version-compatibility-service: {}
node_modules_ghost_audience-feedback: {}
node_modules_ghost_bookshelf-repository: {}
node_modules_ghost_bootstrap-socket: {}
node_modules_ghost_captcha-service: {}
node_modules_ghost_constants: {}
node_modules_ghost_core: {}
node_modules_ghost_custom-fonts: {}
node_modules_ghost_custom-theme-settings-service: {}
node_modules_ghost_data-generator: {}
node_modules_ghost_domain-events: {}
node_modules_ghost_donations: {}
node_modules_ghost_dynamic-routing-events: {}
node_modules_ghost_email-addresses: {}
node_modules_ghost_email-analytics-provider-mailgun: {}
node_modules_ghost_email-analytics-service: {}
node_modules_ghost_email-content-generator: {}
node_modules_ghost_email-events: {}
node_modules_ghost_email-service: {}
node_modules_ghost_email-suppression-list: {}
node_modules_ghost_express-dynamic-redirects: {}
node_modules_ghost_external-media-inliner: {}
node_modules_ghost_ghost: {}
node_modules_ghost_html-to-plaintext: {}
node_modules_ghost_i18n: {}
node_modules_ghost_identity-token-service: {}
node_modules_ghost_importer-handler-content-files: {}
node_modules_ghost_importer-revue: {}
node_modules_ghost_in-memory-repository: {}
node_modules_ghost_job-manager: {}
node_modules_ghost_link-redirects: {}
node_modules_ghost_link-replacer: {}
node_modules_ghost_link-tracking: {}
node_modules_ghost_magic-link: {}
node_modules_ghost_mail-events: {}
node_modules_ghost_mailgun-client: {}
node_modules_ghost_member-attribution: {}
node_modules_ghost_member-events: {}
node_modules_ghost_members-api: {}
node_modules_ghost_members-csv: {}
node_modules_ghost_members-events-service: {}
node_modules_ghost_members-importer: {}
node_modules_ghost_members-ssr: {}
node_modules_ghost_mentions-email-report: {}
node_modules_ghost_metrics-server: {}
node_modules_ghost_milestones: {}
node_modules_ghost_minifier: {}
node_modules_ghost_model-to-domain-event-interceptor: {}
node_modules_ghost_mw-api-version-mismatch: {}
node_modules_ghost_mw-cache-control: {}
node_modules_ghost_mw-error-handler: {}
node_modules_ghost_mw-session-from-token: {}
node_modules_ghost_mw-update-user-last-seen: {}
node_modules_ghost_mw-version-match: {}
node_modules_ghost_mw-vhost: {}
node_modules_ghost_nql-filter-expansions: {}
node_modules_ghost_oembed-service: {}
node_modules_ghost_offers: {}
node_modules_ghost_package-json: {}
node_modules_ghost_payments: {}
node_modules_ghost_post-events: {}
node_modules_ghost_post-revisions: {}
node_modules_ghost_posts-service: {}
node_modules_ghost_prometheus-metrics: {}
node_modules_ghost_recommendations: {}
node_modules_ghost_referrers: {}
node_modules_ghost_security: {}
node_modules_ghost_session-service: {}
node_modules_ghost_settings-path-manager: {}
node_modules_ghost_slack-notifications: {}
node_modules_ghost_staff-service: {}
node_modules_ghost_stats-service: {}
node_modules_ghost_stripe: {}
node_modules_ghost_tiers: {}
node_modules_ghost_update-check-service: {}
node_modules_ghost_verification-trigger: {}
node_modules_ghost_version-notifications-data-service: {}
node_modules_ghost_webmentions: {}
node_modules_apps_admin-x-activitypub: {}
node_modules_apps_admin-x-demo: {}
node_modules_apps_admin-x-design-system: {}
node_modules_apps_admin-x-framework: {}
node_modules_apps_admin-x-settings: {}
node_modules_apps_announcement-bar: {}
node_modules_apps_comments-ui: {}
node_modules_apps_portal: {}
node_modules_apps_posts: {}
node_modules_apps_shade: {}
node_modules_apps_signup-form: {}
node_modules_apps_sodo-search: {}