add support for local arango cluster [SCT-3172] #447
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While attempting to replicate a concurrent arangodb update timeout error, I needed to recreate the deployment as closely as possible. This is the first leg of an attempt to do so. It is a variant, if you will, of the existing development-with-docker support. The primary differences are that this docker-compose configuration defines a cluster configuration for arangodb.
A new pair of make tasks are added to stop and start it, a new small set of mock data added (to support the attempt to replicate this issue), the docker compose configuration, and documentation. It is notable too that the configuration includes an haproxy container to load-balance requests to arangodb.
Future work should attempt to have this configuration match the actual deployment more closely, to the point at which we can replicate production issues.
It may also be that some of the issues we have experienced will disappear when moving to a newer version of ArangoDB - this project was actually an attempt to replicate the problem, then switch the ArangoDB version to see if the problem disappears. There is support for specifying the ArangoDB version in an environment variable (which is in turn utilized as the image tag in docker compose.)
The existing deployment, testing, actual service code are not touched.