e75e6f1dee
Hi, I've been through quite a few different ways of implementing this fix and settled on creating a variable to store the output of checking whether the zookeeper copy target folder exists and copying the snapshot file based on the copy target folder existing. I've ran quite a few manual tests for each option as well. Currently the PR sits on Option 3 from the below options. **Option 1** Judging from the [Jira issue](https://issues.apache.org/jira/browse/ZOOKEEPER-3056), it seems like the work around for zookeeper upgrades could be omitted entirely since the issue relates to upgrades from v3.4.10 to v3.5.4. I've tested removing the zookeeper workaround entirely and that install ran smoothly on a clean install of Sentry (no existing data) as well as an install of Sentry that currently has very minimal amount of log entries (roughly 100 log entries). Could we possibly remove the workaround entirely? **Option 2** The second option was to simply add a check to the currently [existing line](https://github.com/getsentry/onpremise/blob/master/install.sh#L178) of whether the copy target folder exists and perform the snapshot file copy only if the copy target folder exists. This is the least amount of code and possibly the simpler fix while also setting the `ZOOKEEPER_SNAPSHOT_TRUST_EMPTY` env var to `true`, however, some unnecessary calculations will be done to determine the `ZOOKEEPER_LOG_FILE_COUNT` and `ZOOKEEPER_SNAPSHOT_FILE_COUNT`. **Option 3** I've created a variable to store whether the copy target folder exists and proceed with the zookeeper upgrade workaround only if the copy target folder exists. This means that if the copy target folder does not exist, the env var `ZOOKEEPER_SNAPSHOT_TRUST_EMPTY` will not be set. Fixes #547. Co-authored-by: chamirb <chamirb@globalkinetic.com> |
||
|---|---|---|
| .github/workflows | ||
| cron | ||
| nginx | ||
| relay | ||
| scripts | ||
| sentry | ||
| zookeeper | ||
| .craft.yml | ||
| .env | ||
| .gitignore | ||
| .travis.yml | ||
| docker-compose.yml | ||
| install.sh | ||
| LICENSE | ||
| README.md | ||
| test.sh | ||
Sentry Nightly On-Premise 
Official bootstrap for running your own Sentry with Docker.
Requirements
- Docker 17.05.0+
- Compose 1.23.0+
Minimum Hardware Requirements:
- You need at least 2400MB RAM
Setup
To get started with all the defaults, simply clone the repo and run ./install.sh in your local check-out.
There may need to be modifications to the included example config files (sentry/config.example.yml and sentry/sentry.conf.example.py) to accommodate your needs or your environment (such as adding GitHub credentials). If you want to perform these, do them before you run the install script and copy them without the .example extensions in the name (such as sentry/sentry.conf.py) before running the install.sh script.
The recommended way to customize your configuration is using the files below, in that order:
config.ymlsentry.conf.py.envw/ environment variables
We currently support a very minimal set of environment variables to promote other means of configuration.
If you have any issues or questions, our Community Forum is at your service! Everytime you run the install script, it will generate a log file, sentry_install_log-<ISO_TIMESTAMP>.txt with the output. Sharing these logs would help people diagnose any issues you might be having.
Versioning
If you want to install a specific release of Sentry, use the tags/releases on this repo.
We continously push the Docker image for each commit made into Sentry, and other services such as Snuba or Symbolicator to our Docker Hub and tag the latest version on master as :latest. This is also usually what we have on sentry.io and what the install script uses. You can use a custom Sentry image, such as a modified version that you have built on your own, or simply a specific commit hash by setting the SENTRY_IMAGE environment variable to that image name before running ./install.sh:
SENTRY_IMAGE=getsentry/sentry:83b1380 ./install.sh
Note that this may not work for all commit SHAs as this repository evolves with Sentry and its satellite projects. It is highly recommended to check out a version of this repository that is close to the timestamp of the Sentry commit you are installing.
Event Retention
Sentry comes with a cleanup cron job that prunes events older than 90 days by default. If you want to change that, you can change the SENTRY_EVENT_RETENTION_DAYS environment variable in .env or simply override it in your environment. If you do not want the cleanup cron, you can remove the sentry-cleanup service from the docker-compose.ymlfile.
Securing Sentry with SSL/TLS
If you'd like to protect your Sentry install with SSL/TLS, there are
fantastic SSL/TLS proxies like HAProxy
and Nginx. You'll likely want to add this service to your docker-compose.yml file.
Updating Sentry
You need to be on at least Sentry 9.1.2 to be able to upgrade automatically to the latest version. If you are not, upgrade to 9.1.2 first by checking out the 9.1.2 tag on this repo.
The included install.sh script is meant to be idempotent and to bring you to the latest version. What this means is you can and should run install.sh to upgrade to the latest version available. Remember that the output of the script will be stored in a log file, sentry_install_log-<ISO_TIMESTAMP>.txt, which you may share for diagnosis if anything goes wrong.