Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback about this repository #950

Closed
williamdes opened this issue May 13, 2021 · 7 comments
Closed

Feedback about this repository #950

williamdes opened this issue May 13, 2021 · 7 comments

Comments

@williamdes
Copy link
Contributor

I use Sentry for quite some time and need to run it self-hosted.

I managed to make the old Docker official version run fine with a very minimalist docker-compose setup.

minimalist setup

version: '2.3'

services:
  redis:
    restart: on-failure:5
    image: redis:6.0-alpine
    healthcheck:
        test: ["CMD", "redis-cli", "ping"]
        interval: 1s
        timeout: 3s
        retries: 30

  postgres:
    restart: on-failure:5
    image: postgres:13-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U sentry"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s
    environment:
      POSTGRES_USER: sentry
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      POSTGRES_DB: sentry
    volumes:
     - ${POSTGRES_DATA_VOLUME}:/var/lib/postgresql/data

  sentry:
    image: sentry:9.1.2
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
     - 9000:9000
    environment:
      SENTRY_SECRET_KEY: "${SENTRY_SECRET_KEY}"
      SENTRY_POSTGRES_HOST: postgres
      SENTRY_DB_USER: sentry
      SENTRY_DB_PASSWORD: "${POSTGRES_PASSWORD}"
      SENTRY_REDIS_HOST: redis

  cron:
    image: sentry:9.1.2
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    command: "sentry run cron"
    environment:
      SENTRY_SECRET_KEY: "${SENTRY_SECRET_KEY}"
      SENTRY_POSTGRES_HOST: postgres
      SENTRY_DB_USER: sentry
      SENTRY_DB_PASSWORD: "${POSTGRES_PASSWORD}"
      SENTRY_REDIS_HOST: redis

  worker:
    image: sentry:9.1.2
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    command: "sentry run worker"
    environment:
      SENTRY_SECRET_KEY: "${SENTRY_SECRET_KEY}"
      SENTRY_POSTGRES_HOST: postgres
      SENTRY_DB_USER: sentry
      SENTRY_DB_PASSWORD: "${POSTGRES_PASSWORD}"
      SENTRY_REDIS_HOST: redis

My questions to use this new repository are:

  • why do you require so much services ?
  • so much volumes ?
  • is it possible to have a readable and light version ? (I mean do not have to clone the repository at all, keep it slim)
  • is to possible to not have to clone the repository ?

Notes:

  • I think redis and postgres could have a health check like in my example
  • Redis could be upgraded to redis:6.0-alpine
  • And postgres to postgres:13-alpine (yes, using alpine would also be better)
@github-actions
Copy link

Sorry, friend. As far as this ol' bot can tell, your issue does not properly use one of this repo's available issue templates. Please try again, if you like. (And if I'm confused, please let us know. 😬)


Did you see the memo about this?

(log)

@williamdes
Copy link
Contributor Author

Hi @BYK
Could you re-open this one so we can discuss, please ?

@BYK
Copy link
Member

BYK commented May 13, 2021

Hi @williamdes, we use the forum for discussions. You can post a thread there and we can continue.

why do you require so much services ?

Because we need those services for further data processing.

so much volumes ?

Because we have more data stores now and they need to be persistent.

This may help you have a better image in your head: https://develop.sentry.dev/architecture/

is it possible to have a readable and light version ? (I mean do not have to clone the repository at all, keep it slim)

Not sure what you mean with readable and slim. Happy to improve if you can be more specific about these.

is to possible to not have to clone the repository ?

Yes, you can download the source code for releases from the releases page for each release. That said it still will have all the repo contents, except for the .git folder. Not sure if this is what you mean.

@williamdes
Copy link
Contributor Author

Yes, you can download the source code for releases from the releases page for each release. That said it still will have all the repo contents, except for the .git folder. Not sure if this is what you mean.

Well a .gitattributes would be nice to keep the downloaded repository slim

Hi @williamdes, we use the forum for discussions. You can post a thread there and we can continue.

Thanks, I will probably open something about my request

To short explain I see the slim version as using the most minimal of everything to work

You know, like when you use alpine.

I want sentry but maybe not geoip, from my tests the container can just be removed without issues

So, the most minimal file, no config files if possible, using alpine as much as possible and no useless services running

You get the idea

@BYK
Copy link
Member

BYK commented May 13, 2021

Well a .gitattributes would be nice to keep the downloaded repository slim

I don't really understand how this would help keep things slimmer. Can you elaborate?

To short explain I see the slim version as using the most minimal of everything to work

This is not far from that. The only extra things you see there are geoip and smtp images which are quite tiny and easy to strip off by folks who are not interested in. I'd say geoip isn't even optional tho as without that you lose a core and important data, the geographical distribution of events.

We aim to maintain and support a single package that is light but still delivers all the basic functionality. Folks are free to create their own versions with the load of maintaining that.

@williamdes
Copy link
Contributor Author

I don't really understand how this would help keep things slimmer. Can you elaborate?

For example: is the folder .github usefull for users, no. Is test.sh usefull for users, probably not. Etc..
See this example: https://github.com/code-lts/doctum/blob/main/.gitattributes

This is not far from that. The only extra things you see there are geoip and smtp images which are quite tiny and easy to strip off by folks who are not interested in. I'd say geoip isn't even optional tho as without that you lose a core and important data, the geographical distribution of events.

What if you do not want to know your users IPs ? 🤔
(I am from the phpMyAdmin project and plan to migrate to Sentry, that said I am stuck to version 9 until I am sure all the components used are not a security risk and are well configured)

We aim to maintain and support a single package that is light but still delivers all the basic functionality. Folks are free to create their own versions with the load of maintaining that.

Sure

I can contribute to this repository but I need to know if the time spent will end up merged ;)

@BYK
Copy link
Member

BYK commented May 17, 2021

For example: is the folder .github usefull for users, no. Is test.sh usefull for users, probably not. Etc..
See this example: https://github.com/code-lts/doctum/blob/main/.gitattributes

Sure, I'm okay getting this in if you are willing to submit a PR as you suggested.

What if you do not want to know your users IPs ? 🤔
(I am from the phpMyAdmin project and plan to migrate to Sentry, that said I am stuck to version 9 until I am sure all the components used are not a security risk and are well configured)

You can scrub that out easily. I'd prefer shipping a "full" experience as the default rather than making people pick and chose from the get go. Clearly, power-users like yourself can figure out what to cut out when needed :)

I can contribute to this repository but I need to know if the time spent will end up merged ;)

I cannot give you a blanket statement for all PRs but overall we are always open to improvements by the community as long as they are widely applicable and don't come with a very heave maintenance burden.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants