Official Docker Image

On-Premise
1

It’s super cool that Sentry 10 is available now. Big thanks for the new release!

Will there be an official Docker image like for version 9 or is cloning the repo and building the docker image the only way to run Sentry in version 10?

I’m using Docker in Swarm Mode, but the customizations for version 10 are a bit tricky. Do I need to build the cleanup services for sentry, snuba and symbolicator? Because they don’t have pre-build images, right?

Is it still possible to use the following ENV variables to configure the container?

SENTRY_SECRET_KEY="my-secret-key"
SENTRY_POSTGRES_HOST=postgres
SENTRY_DB_NAME=dbname
SENTRY_DB_USER=dbuser
SENTRY_DB_PASSWORD=dbpassword
SENTRY_REDIS_HOST=redis
SENTRY_EMAIL_HOST=smtp.example.com
SENTRY_EMAIL_PORT=587
SENTRY_EMAIL_USER=mailer@example.com
SENTRY_EMAIL_PASSWORD=secret
SENTRY_EMAIL_USE_TLS=true
SENTRY_SERVER_EMAIL=mailer@example.com
SENTRY_USE_SSL=1
SENTRY_SINGLE_ORGANIZATION=0

Thanks!

2

Hi! We have tagged a v10 image: https://hub.docker.com/layers/getsentry/sentry/10/images/sha256-e6e48677c3a6a88ffa7509486152966ab7b47faf91755eeb23cf969217f2d2c0 - That said I strongly recommend using a more recent tag (you don’t have to use latest).

You can find the supported environment variables over at https://github.com/getsentry/sentry/blob/9e3dc85de162f58c24f0818a81b3ec7389cd202b/docker/sentry.conf.py#L7-L34

The cleanup images are bit tricky. The main reason we have them is docker-compose offering no way for scheduled runs (otherwise they are simply scheduled command runs on existing container images). Kubernetes for instance offers scheduled runs, making those containers obsolete. I did a quick Google search for a similar functionality on Docker Swarm and couldn’t find anything so you may have to build them yourself.

Hope this helps!

3

So which tag would be a good idea for an kind of stable version?

4

You just pick one and stick to that. All of them are the same in terms of stability as they are being deployed to sentry.io continuously. Any bad commits are very quickly reverted or fixed.

5

I expected this answer somehow :wink:

it would be really great to get some more “stability commitment” because “picking one” can lead to a bad one with errors and then a deep review of all changes before and after it to see if it got fixed … or just using latest then leads to risk for other problems again :frowning:

1 Like
6

@Apollon77 - the stability commitment is that the code you are using being battle-tested with our extensive test suite and being used and tested on sentry.io. It really doesn’t make much sense to pick a specific SHA and then try to shine it because it is a constantly moving and improving target. There won’t be any time with a 100% bug-free version of Sentry. The best thing one can do is to make sure you can get the newest version easily when you notice a bug and it gets fixed.

7

Ok, understood.Thank you!

is there a chance that the CHangelog gets updated at least from time to time to see features or change in it? or will this be published on “release tag timepoint” like the 10.0?

8

So using one of these tags is still a good option, right?

https://hub.docker.com/r/getsentry/sentry/tags?page=1&name=10.

Will the upcoming minor and bugix releases also get a version tag?

EDIT: The image getsentry/snuba doesn’t have a version tag. Which one should I use in combination with getsentry/sentry:10.0?

9

@paeddl - a tag that is pushed/built around the same time of 10.0.0 should work (such as this one https://hub.docker.com/layers/getsentry/snuba/f7beee32e2f179bcacdc3b2cff8a1d210b565c62/images/sha256-252982516068535b1b928203c9031717e671d7f55e55954648e0cfb8c17a5d6a?context=explore)

We are planning a better system for this to avoid future confusion as @Apollon77 also asked some months ago.