fix(root): remove healthcheck option in docker-compose.yml

[jainpawan21]

What changed? Why was the change needed?

closes #7478

• removes the health check in docker-compose.yml file
• adds default values for new relic env values
• updates default value for mongo db pool connections

Screenshots

Expand for optional sections

Related enterprise PR

Special notes for your reviewer

[linear]

NV-5160 🐛 Bug Report: ghcr.io/novuhq/novu/web:2.1.0 docker container STATUS (unhealthy) - curl: not found

[netlify]

✅ Deploy Preview for dashboard-v2-novu-staging canceled.

Name	Link
🔨 Latest commit	46b4793
🔍 Latest deploy log	https://app.netlify.com/sites/dashboard-v2-novu-staging/deploys/67d7b12babe9c30008f9faaf

[merrcury]

LGTM

[netlify]

✅ Deploy Preview for dashboard-v2-novu-staging canceled.

Name	Link
🔨 Latest commit	9344ab7
🔍 Latest deploy log	https://app.netlify.com/sites/dashboard-v2-novu-staging/deploys/67d7b136fd4e240008af7458

[zettlrobert]

I just set this up for my current project dev environment and wrote a simple health check that uses a node expression which would integrate without the curl dependency or any additional modification

Should I open an additional PR or make the adjustment here?

[jainpawan21]

I just set this up for my current project dev environment and wrote a simple health check that uses a node expression which would integrate without the curl dependency or any additional modification

Should I open an additional PR or make the adjustment here?

cc: @merrcury

[Aaron-Ritter]

In addition to the comment for the pool size changes.

Why are health checks removed from the configuration?

These have nothing to do with monitoring in the sense of New Relic but more in relationship to container dependency. e.g.

    depends_on:
      mongodb:
        condition: service_healthy
      redis:
        condition: service_healthy

If implemented correctly could even improve this dependency with a health condition https://github.com/novuhq/novu/blob/next/docker%2Fcommunity%2Fdocker-compose.yml#L144-L148

In addition to that the expectation that New Relic is used everywhere is surprising to me, especially in a community config.

I will create a PR on how to properly disable New Relic as not everyone in the community uses or even knows it:

.env.example

# change these values
NEW_RELIC_ENABLED=false
NEW_RELIC_APP_NAME="NEW_RELIC_APP_NAME"
NEW_RELIC_LICENSE_KEY="NEW_RELIC_LICENSE_KEY"

compose.yml sections

      NEW_RELIC_ENABLED: ${NEW_RELIC_ENABLED}
      NEW_RELIC_APP_NAME: ${NEW_RELIC_APP_NAME}
      NEW_RELIC_LICENSE_KEY: ${NEW_RELIC_LICENSE_KEY}

[Aaron-Ritter]

@zettlrobert

I just set this up for my current project dev environment and wrote a simple health check that uses a node expression which would integrate without the curl dependency or any additional modification

Should I open an additional PR or make the adjustment here?

From my side this would be much appreciated and in my opinion a better solution to #7478. @jainpawan21 @merrcury

[Aaron-Ritter]

@jainpawan21 @merrcury I've created a PR and related issue for a better handling of New Relic #7943

[merrcury]

I just set this up for my current project dev environment and wrote a simple health check that uses a node expression which would integrate without the curl dependency or any additional modification

Should I open an additional PR or make the adjustment here?

Sure, Please go ahead. We'll integrate if we found it useful

[merrcury]

@jainpawan21 @merrcury I've created a PR and related issue for a better handling of New Relic #7943

That looks like a good idea, Thanks

[zettlrobert]

I just set this up for my current project dev environment and wrote a simple health check that uses a node expression which would integrate without the curl dependency or any additional modification
Should I open an additional PR or make the adjustment here?

Sure, Please go ahead. We'll integrate if we found it useful

There are in theory multiple ways to go about that.

Proposal One

For reusability and maintainability, I would recommend a healthchecks directory in the docker/community directory which could be bind mounted into the container instance.

This would allow writing any form of js/mjs script and execute it as healthcheck.

Possible issues

After a quick look at the Dockerfile and build stages, I think there will be missing executable permissions on the mounted files.
The simplest solution probably is including a health check script in the image, to be executed in the compose file with already applied permissions...

Edit

Based on the structure, I would place the healthcheck directory in the individual widgets so for example, for the web application in apps/web/healthchecks

Same for the other widgets to keep it modular but it would not strictly be 'DRY'

Proposal Two

Try to make it an onliner, executed via the available node runtime

[Aaron-Ritter]

@zettlrobert In my opinion, healtcheck endpoints (Scripts/Commands) should always be part of the container image. A few good examples which have very stable health endpoints are:

• redis: redis-cli ping
• postgres: pg_isready
• clamav: clamdcheck.sh

[zettlrobert]

#7953 just a draft of the approach i would take, let me know if I should continue.

[Aaron-Ritter]

@jainpawan21 @merrcury I'd appreciate your insights on the significant reduction - a factor of 15-20 - in MongoDB's PoolSize.

[merrcury]

@Aaron-Ritter Regarding the reduction in MongoDB pool size: For a small setup and initial usage, you likely don’t need hundreds of connections, especially since most operations are fairly quick. Maintaining a large number of connections increases RAM and CPU usage on MongoDB, which can be inefficient.

[Aaron-Ritter]

@merrcury thanks a lot for the clarification, do you have any sizing guidelines documented?