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