You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Great work! The cluster setup deserves a bunch of stars on its own.
We have the need of running multiple environments (e.g. dev, int, prod etc.). There are places in the code where service name and port are hardcoded. It would be just sweet if those could be parameterised as well. Example:
curl -X PUT http://$COUCHDB_USER:$COUCHDB_PASSWORD@couchdb1:5984/_users
curl -X PUT http://$COUCHDB_USER:$COUCHDB_PASSWORD@couchdb1:5984/_replicator
curl -X PUT http://$COUCHDB_USER:$COUCHDB_PASSWORD@couchdb1:5984/_global_changes
Given the Swarm setup, each service need their own port. Forking is of course an alternative but better yet would be if this service definition becomes the de facto standard for couchdb and swarm.
The use case I think of is to launch multiple services in the same Swarm by altering the service name and port.
Thanks, @robertgartman! Yeah, I completely agree that those areas should be made configurable. Any chance you want to submit a PR and I'll code review it?
Great work! The cluster setup deserves a bunch of stars on its own.
We have the need of running multiple environments (e.g. dev, int, prod etc.). There are places in the code where service name and port are hardcoded. It would be just sweet if those could be parameterised as well. Example:
Given the Swarm setup, each service need their own port. Forking is of course an alternative but better yet would be if this service definition becomes the de facto standard for couchdb and swarm.
The use case I think of is to launch multiple services in the same Swarm by altering the service name and port.
The text was updated successfully, but these errors were encountered: