Couchbase Server Docker images do not listen on port 8092

Having a bunch of trouble running XDCR between two docker containers.

Confusingly the XDCR error was as follows:

2018-07-16T22:56:02.731Z INFO GOXDCR.CapiSvc: Received error when making rest call. baseURL=example.com:8092, path=_pre_replicate, ret_err=Post http://example.com:8092/_pre_replicate: dial tcp 172.23.96.34:8092: getsockopt: connection refused, statusCode=0, num_retry=3

Clearly the view engine should be running correctly on port 8092.
Looking at the logs for the view engine it seems to be running correctly, but nothing is listening on port 8092:

netstat -anp | grep "8092"

tcp        0      0 0.0.0.0:18092           0.0.0.0:*               LISTEN      -

Digging deeper, I checked the couchdb config file at /opt/couchbase/etc/couchdb/default.d/capi.ini and could see the following:

[couchdb]

max_dbs_open = 10000

database_dir = /opt/couchbase/var/lib/couchbase/data

view_index_dir = /opt/couchbase/var/lib/couchbase/data

[httpd]

db_frontend = capi_frontend

bind_address = 0.0.0.0

port = 

There is no value for the port, where there should be 8092.

I can fix this by filling in the port value and then restarting the cluster manager, then the view engine is listening on port 8092 as expected.

Whenever I restart the container, the file resets itself and couchdb stops listening on port 8092, so there must be something updating this file whenever the container starts.

I then checked the entrypoint script for the container and found https://github.com/couchbase/docker/blob/master/enterprise/couchbase-server/5.1.1/scripts/entrypoint.sh.
The key part of the script is this:

    if [ "$portNameUpper" == "CAPI_PORT" ]; then

        if grep -Fq "{${portValue}," ${capiConfigFile}

        then

            echo "Don't override port ${portName} because already available in $staticConfigFile"

        else

            sed -i -e "s/${capiPortValue}/${portValue}/g" ${capiConfigFile}

        fi

fi

The problem here is that CAPI_PORT ALWAYS gets overwritten, even if no override value is specified, so it will default to an empty string.
As a result, under a normal docker run or even under Kubernetes, the view engine will not work correctly, which means both view and XDCR cannot be used, which is a big problem.

Right now this problem is only isolated to the automated couchbase/server builds, but when Vulcan releases this issue will also affect couchbase:5.5.0, so I have raised this as a blocker.

This will become more of a problem if it's not fixed before the Couchbase Autonomous Operator is released.