simplify running couchdb-docker in single-node mode

[jkhsjdhjs]

Hello,

at work we're using gitlab ci to test a project. The project supports couchdb as a database backend, that's why we're also running tests on it.
However, since couchdb doesn't run in single-node mode, required databases like _users or _replicator are not created automatically. That's (probably) why the setup of couchdb doesn't complete successfully and eventually times out: https://gist.github.com/jkhsjdhjs/203d7c762a05d9cbf2b11757911def3a
The gitlab ci test configuration is the following:

test:
  stage: test
  only: [branches, tags, merge_requests]
  inherit:
    variables: ["PIP_CACHE_DIR"]
  variables:
    COUCHDB_USER: "admin"
    COUCHDB_PASSWORD: "yo0Quai3"
  services:
    - couchdb:2.3
  script:
    - [... test commands ...]

Single-node mode can only be enabled with a config file, which has be placed or mounted inside the docker container. That's why @wohali proposed the following for the gitlab ci configuration:

echo "[couchdb]" >10-single-node.ini
echo "single_node=true" >> 10-single-node.ini
docker run -p 5984:5984 -v /path/to/10-single-node.ini:/opt/couchdb/etc/local.d/10-single-node.ini apache/couchdb:3.1.0

While I'm convinced this would work, for it to work inside the gitlab ci runner, we'd have to change the image to something that includes the docker command (we're currently using python:3.6).
And even with gitlab/dind - an image, that includes docker - I couldn't get it to work (TBF I didn't test further after it failed the first time). See apache/couchdb-docker#54 (comment)

I also asked in #gitlab on freenode for a solution, the only suggestion there was to maintain my own fork of couchdb-docker in single-node mode, or to build a single-node docker image as part of the pipeline.

Because there seems to be no easy solution to this for me, I suggest adding a COUCHDB_SINGLE_NODE environment variable to couchdb-docker, which is set to false or 0 by default to preserve existing behavior.

I'd like to hear your opinion on this, and if you have other ideas to solve this issue, please let me hear them!

[janl]

I think a PR against https://github.com/apache/couchdb-docker would have a good chance of being accepted.

[wohali]

@janl I'm against adding an env var for COUCHDB_SINGLE_NODE since this can be so easily achieved by mapping your own .ini file into the container's file system.

For persistent use, this is mandatory anyway - since you're going to want to make other configuration changes to CouchDB and persist those, along with the data.

We've had no end of people wanting to add "just one more env var" to the startup script and I put my foot down a long while ago on that. I'm unconvinced we really need this.

That's why I sent this over here for discussion from apache/couchdb-docker#54 - because I had a feeling the issue the OP had wasn't actually our problem...looks like I was right (see below).

[jkhsjdhjs]

Thanks for your reply. I did some further research on why the healthcheck fails for couchdb. GitLab attempts to connect to the highest port number exposed by the container [1]. I noticed this when first exposing ports 5984 5983 and then 5984 5985. The healthcheck succeeded for the former, but failed for the latter.
The couchdb docker image exposes ports 5984 4369 9100 by default, which explains why the healthcheck fails: 9100 is the highest port number of all three, it's the couchdb cluster communication port and there's probably nothing listening by default. So, couchdb not running in single node mode is actually not the cause of the healthcheck failing. It's rather the fault of GitLab trying to automatically determine the health of services.
There's currently an open issue at gitlab-runner where they're discussing whether to switch to docker healthchecks (which would make a good addition to the couchdb dockerfiles IMO) or to allow the user to specify healthchecks in the .gitlab-ci.yml [2].
So I think it's just a matter of time until I can easily resolve the healthcheck issue for my project.

I'd still be willing to open a PR for couchdb-docker. What's your opinion on this, now that you know that the docker image not running in single node mode doesn't actually cause any issues, just some error messages?

[1] https://gitlab.com/gitlab-org/gitlab-runner/-/blob/82ee8b29637f4b5406e206b97710d279165bdd30/executors/docker/docker.go#L1325
[2] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3984

[wohali]

Would be happy to see a PR opened in couchdb-docker to add the Docker healthchecks, that seems like the best path forward.

[nicolas-albert]

The COUCHDB_SINGLE_NODE is useful for keep a deployment simple, like a one file docker compose stack or a Kubernetes configuration, and without manual operation after deployment.
Adding a separated configuration file isn't easy for beginner users and they probably want to use a single node mode.
IMO COUCHDB_SINGLE_NODE is useless because the single node mode should be the default mode and advanced users that want a CouchDB cluster can configure their local.ini or a COUCHDB_CLUSTER env variable.