Connection issue using Docker and .NET SDK

I was trying to create a small POC using the docker image couchbase:community-7.0.2. When I create a docker container (and bind/forward all the ports) and connect like so:

        var options = new ClusterOptions { 
            EnableTls = false,
            ConnectionString = "couchbase://localhost",
            UserName = "Administrator",
            Password = "password"
        };

        var cluster = await CB.Cluster.ConnectAsync( options );
        
        var waitOptions = new WaitUntilReadyOptions().CancellationToken( cancellationToken );
        await cluster.WaitUntilReadyAsync( TimeSpan.FromSeconds( 5 ), waitOptions ).ConfigureAwait( false );

        await cluster.Buckets.CreateBucketAsync( 
            new BucketSettings { Name = "test", BucketType = BucketType.Couchbase, RamQuotaMB = 100 } );

        var buckets = await cluster.Buckets.GetAllBucketsAsync();

Everything seems to work.

But when I create a console application that runs in another container that shares a docker network bridge. I get one of two issues.

1- If my connection string is: couchbase://db (db being the docker network name/alias for the Couchbase container) I’m able to connect to the cluster, but then I get the following error when calling “GetAllBucketsAsync”

Couchbase.ServiceNotAvailableException: Service mgmt is either not configured or cannot be reached. Check logs for details.
Couchbase.Core.ClusterContext.GetRandomNodeForService(ServiceType service, String bucketName)
Couchbase.Core.ServiceUriProvider.GetRandomManagementUri()
Couchbase.Management.Buckets.BucketManager.GetUri(String bucketName)
Couchbase.Management.Buckets.BucketManager.GetAllBucketsAsync(GetAllBucketsOptions options)

The container seems to be fine since I can connect from the host machine using: http://localhost:8091/

2 - If I try and connect using the management port couchbase://db:8091 it seems to fail while waiting for the cluster to be ready after getting “Orphaned responses observed”

var waitOptions = new WaitUntilReadyOptions().CancellationToken( operationCancelToken );
_logger?.LogInformation( "Waiting for cluster ready." );
await cluster.WaitUntilReadyAsync( notifyInterval, waitOptions ).ConfigureAwait( false );
_logger?.LogInformation( "Cluster is ready." );  // Never gets here

Is there any reason why Couchbase might have issues connecting over a docker network, but would be fine connecting from a host machine to a container?

Use this as a reference - Install Couchbase Server Using Docker | Couchbase Docs

I’m wondering if you have taken care of all the couchbase ports. https://docs.couchbase.com/server/current/install/install-ports.html

SDK Doctor is a good tool for sorting out connectivity. SDK Doctor | Couchbase Docs

For most (all?) SDKs, cluster.connect() doesn’t won’t complain if it cannot connect to the cluster. It takes an actual operation - such as GetAllBucketsAsync - to result in an error. I’m not saying this is the issue - just keep that in mind when trouble-shooting.

The container seems to be fine since I can connect from the host machine using: `http://localhost:8091/

SDK Doctor will give much more info, but for a quick test you can curl to the kv port, "curl http://hostname:11210 " (for ssl https://hostname:11207). It should be able to connect and give an empty response:

% curl http://localhost:11210
curl: (52) Empty reply from server <-- this is expected, it's not http/s

2 - If I try and connect using the management port couchbase://db:8091 i

Don’t do that. It should be using the kv port - 11210 for plain, 11207 for ssl.

Thank you for the suggestion, it points to a problem with my setup. I’m guessing that it is how I’m initializing a default node and bucket. When I set it up manually in the UI I get:

12:48:55.864 INFO ▶ Performing DNS lookup for host `db`
12:48:55.865 INFO ▶ Bootstrap host `db` refers to a server with the address `192.168.16.2`
12:48:55.866 INFO ▶ Attempting to connect to cluster via CCCP
12:48:55.866 INFO ▶ Attempting to fetch config via cccp from `db:11210`
12:48:55.869 INFO ▶ Selected the following network type: default
12:48:55.869 INFO ▶ Identified the following nodes:
12:48:55.869 INFO ▶   [0] db
12:48:55.869 INFO ▶          indexStreamInit:  9103,                 mgmt:  8091,                 n1ql:  8093
12:48:55.869 INFO ▶                     capi:  8092,           indexAdmin:  9100,            indexHttp:  9102
12:48:55.869 INFO ▶       indexStreamCatchup:  9104,     indexStreamMaint:  9105,                   kv: 11210
12:48:55.869 INFO ▶                projector:  9999,                  fts:  8094,              ftsGRPC:  9130
12:48:55.869 INFO ▶                indexScan:  9101
12:48:55.869 INFO ▶ Fetching config from `db:8091`
12:48:55.874 INFO ▶ Failed to retreive cluster information (status code: 401)
12:48:55.876 INFO ▶ Successfully connected to KV service at `db:11210`
12:48:55.880 INFO ▶ Successfully connected to MGMT service at `db:8091`
12:48:55.898 INFO ▶ Successfully connected to CAPI service at `db:8092`
12:48:55.900 INFO ▶ Successfully connected to N1QL service at `db:8093`
12:48:55.902 INFO ▶ Successfully connected to FTS service at `db:8094`
12:48:55.905 INFO ▶ Memd Nop Pinged `db:11210` 10 times, 0 errors, 0ms min, 0ms max, 0ms mean
12:48:55.905 INFO ▶ Diagnostics completed

Originally I was automating this myself, but switched to TestContainers. Unfortunately, I think that’s where the config is going sideways. You can see TestContainers does an extra step of setting up an external network using the loopback IP:

14:57:29.410 INFO ▶ Performing DNS lookup for host `db`
14:57:29.411 INFO ▶ Bootstrap host `db` refers to a server with the address `192.168.160.2`
14:57:29.412 INFO ▶ Attempting to connect to cluster via CCCP
14:57:29.412 INFO ▶ Attempting to fetch config via cccp from `db:11210`
14:57:29.416 WARN ▶ Bootstrap host `db` is not using the canonical node hostname of `192.168.160.2`.  This is not neccessarily an error, but has been known to result in strange and difficult-to-diagnose errors in the future when routing gets changed.
14:57:29.416 INFO ▶ Selected the following network type: external
14:57:29.416 INFO ▶ Identified the following nodes:
14:57:29.416 INFO ▶   [0] 127.0.0.1
14:57:29.416 INFO ▶                   ftsSSL: 54104,                 mgmt:  8091,                   kv: 11210
14:57:29.416 INFO ▶                    kvSSL: 54111,              capiSSL: 54108,              n1qlSSL: 54110
14:57:29.416 INFO ▶                  mgmtSSL: 54103,                 capi:  8092,                 n1ql:  8093
14:57:29.416 INFO ▶                      fts:  8094
14:57:29.416 INFO ▶ Fetching config from `127.0.0.1:8091`
14:57:29.417 INFO ▶ Failed to retreive cluster information (error: Get http://127.0.0.1:8091/pools/default: dial tcp 127.0.0.1:8091: connect: connection refused)
14:57:29.417 ERRO ▶ Failed to connect to KV service at `127.0.0.1:11210` (error: dial tcp 127.0.0.1:11210: connect: connection refused)
14:57:29.417 ERRO ▶ Failed to connect to MGMT service at `127.0.0.1:8091` (error: Get http://127.0.0.1:8091/: dial tcp 127.0.0.1:8091: connect: connection refused)
14:57:29.417 ERRO ▶ Failed to connect to CAPI service at `127.0.0.1:8092` (error: Get http://127.0.0.1:8092/: dial tcp 127.0.0.1:8092: connect: connection refused)
14:57:29.418 ERRO ▶ Failed to connect to N1QL service at `127.0.0.1:8093` (error: Get http://127.0.0.1:8093/: dial tcp 127.0.0.1:8093: connect: connection refused)
14:57:29.418 ERRO ▶ Failed to connect to FTS service at `127.0.0.1:8094` (error: Get http://127.0.0.1:8094/: dial tcp 127.0.0.1:8094: connect: connection refused)
14:57:29.418 WARN ▶ Failed to perform KV connection performance analysis on `127.0.0.1:11210` (error: %!d(string=dial tcp 127.0.0.1:11210: connect: connection refused))
14:57:29.418 INFO ▶ Diagnostics completed

I’ll try to go back to setting up the node/bucket using my own scripts or hacking TestContainers.

That was my issue. I also had to make sure to set my indexes storage mode before I try and create any indexes.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.