Mount a certificate folder to local ca storage in containers,
and add update command to cron image's entrypoint.
Result of poking and prodding from getsentry/sentry#26851
We used to build local images for Sentry services to be able to
include required plugins in the image. With this change we instead
do this in a custom entrypoint script and use the volume `/data`
to store the plugins permanently.
This should resolve many issues people have around building local
images and pushing them to places like private repositories or swarm
clusters.
This is not 100% compatible with the old way but it should still be
a mostly transparent change to many folks.
Fixes#823. In `install.sh` we build a local sentry image that is used by many services from using the build context under the `./sentry` directory. To avoid building this image multiple times, we also give it a specific name which is referred from multiple services. The issue is, we also run `docker-compose build --parallel` which creates a race condition when building this image as `docker-compose` doesn't check whether the image is already there or not. This is the root cause of all these random failures: an unsurprising race condition.
Based on my reading, this error comes from urllib3.
https://urllib3.readthedocs.io/en/latest/advanced-usage.html
>The behavior of the pooling for ConnectionPool is different from PoolManager. By default, if a new request is made and there is no free connection in the pool then a new connection will be created. However, this connection will not be saved if more than maxsize connections exist. This means that maxsize does not determine the maximum number of connections that can be open to a particular host, just the maximum number of connections to keep in the pool.
I think the ideal solution would be to add `retry` and `block` options to [docker-py](ce2669e3ed/docker/transport/unixconn.py (L58-L70)) but that's a long shot.
Removes the obsolete `echo ''` at the end, fixes detection as `python --version` outputs to `stderr` instead of `stdout` in versions prior to 3.4 or something.
This is in preparation to make the PY3 version the default for Docker images and self-hosted. It is part **4/5**:
1. ~~Add `-py2` variants for the Python 2 build tags and introduce the `SENTRY_PYTHON2` env variable usage~~ (getsentry/sentry#22460)
2. ~~Switch getsentry/onpremise to Python 3 by default*, introducing the `SENTRY_PYTHON2` env var for Py2 builds via the `-py2` suffix~~ (getsentry/onpremise#763)
3. ~~Move the unsuffixed version of the builds to Python 3~~ (getsentry/sentry#22466)
4. **Remove the `SENTRY_PYTHON3` env var support and `-py3` prefix usage from getsentry/onpremise**
5. Remove tagging of `-py3` builds from getsentry/sentry
This is in preparation to make the PY3 version the default* for Docker images and self-hosted. It is part **2/5**:
1. ~~Add `-py2` variants for the Python 2 build tags and introduce the `SENTRY_PYTHON2` env variable usage~~ (getsentry/sentry#22460)
2. __Switch getsentry/onpremise to Python 3 by default*, introducing the `SENTRY_PYTHON2` env var for Py2 builds via the `-py2` suffix__
3. Move the unsuffixed version of the builds to Python 3
4. Remove the `SENTRY_PYTHON3` env var support and `-py3` prefix usage from getsentry/onpremise
5. Remove tagging of `-py3` builds from here
_* this will only happen when item 3 above gets landed_
We need `docker-compose ps -a` for CI so we were already using 1.24.1, this aligns the rest with that.
For Docker, there are a bunch of network-related fixes in 19.03.12 and prior (DNS fallback and IPv6 advertising) that we'd like to have to see if they are going to fix some reported connectivity issues w/ onpremise.
GitHub team pointed us to docker/compose#3586 as the likely root cause and some digging around revealed got us to https://git.io/JUn7p as a potential fix, which we are trying here.
This continues on the ideas from #607. By "downtime" here I mean "not accepting events" - web, smtp and background processes are out of scope.
This PR adds a `--minimize-downtime` option to install.sh. This options changes the behaviour of the script by:
1. keeping nginx and relay running until the very end,
2. disabling cleanup on exit and failure,
3. explicitly reloading nginx configuration,
4. and starting the whole cluster at the end.
The results are promising: no downtime if relay version doesn't change, and only a second when it does. So far this was only tested with a curl loop, so I'm still not sure if Relay flushes the events to Sentry before getting recreated by `$dc up`.
