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.
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.