Running remote Console against Canton running in Docker

I’m trying to run a remote Console against Canton running in Docker with the simple topology, but get an error I don’t understand.

The script to run Canton:

docker run --rm \
   --volume "$PWD/config:/canton/config" \
   --name canton \
   -p 5011:5011 \
   -p 5012:5012 \
   -p 5021:5021 \
   -p 5022:5022 \
   -p 5018:5018 \
   -p 5019:5019 \
   -e POSTGRES_USER=canton \
   -e POSTGRES_PASSWORD=supersafe \
   -e POSTGRES_HOST=host.docker.internal \
   digitalasset-docker.jfrog.io/canton-enterprise daemon \
   -c /canton/config/simple_topology.conf \
   -c /canton/config/postgres.conf \
   --bootstrap /canton/config/simple_ping.canton \
   --log-level-canton=INFO \
   --log-profile=container

The remote config:

canton.remote-participants.participant1 {
admin-api {
    address="0.0.0.0"
    keep-alive-client {
        time="40s"
        timeout="20s"
    }
    port="5012"
}
ledger-api {
    address="0.0.0.0"
    keep-alive-client {
        time="40s"
        timeout="20s"
    }
    port="5011"
}

}

The script to start Console:

/Users/gyorgybalazsi/canton/canton-enterprise-2.8.1/bin/canton \
  -c ./config/remote-participant1.conf
  --log-level-canton=DEBUG

When I issue the command health.status in the Console I get the following message:

@ nodes.remote(0).health.status 
res4: com.digitalasset.canton.health.admin.data.NodeStatus[com.digitalasset.canton.console.InstanceReferenceCommon#Status] = Request failed for participant1. Is the server running? Did you configure the server address as 0.0.0.0? Are you using the right TLS settings? (details logged as DEBUG)
  GrpcServiceUnavailable: UNAVAILABLE/io exception
  Request: com.digitalasset.canton.admin.api.client.commands.StatusAdminCommands$GetStatus@3a744e32
  Causes: Connection reset

The following error gets logged:

2024-02-08 16:09:34,011 [canton-env-ec-23] INFO  c.d.c.a.api.client.GrpcCtlRunner tid:0d93d9b3fb27702848328b8f48a0c7c1 - Request failed for participant1. Is the server running? Did you configure the server address as 0.0.0.0? Are you using the right TLS settings? (details logged as DEBUG)
  GrpcServiceUnavailable: UNAVAILABLE/io exception
  Request: com.digitalasset.canton.admin.api.client.commands.StatusAdminCommands$GetStatus@2e96489b
  Causes: Connection reset
java.net.SocketException: Connection reset
	at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
	at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:254)
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:833)

What am I doing wrong?

Works for me. :frowning:

Is it clear that participant1 has not crashed during startup?

Feel free to post more files (simple_topology.conf, etc.) if you think they might be of more help.

Participant is running perfectly. Conf files are the same as those in the simple topology example in the Canton source code. Will share them later if this is not emough information.

I’m trying to run it on a Mac, what about you? It shouldn’t make a difference but who knows.

Yes, I’m on Mac too.

I find this simple-topology.conf file.

canton {
  participants {
    participant1 {
      storage.type = memory
      admin-api.port = 5012
      ledger-api.port = 5011
    }
    participant2 {
      storage.type = memory
      admin-api.port = 5022
      ledger-api.port = 5021
    }
  }
  domains {
    mydomain {
      storage.type = memory
      public-api.port = 5018
      admin-api.port = 5019
    }
  }
  // enable ledger_api commands for our getting started guide
  features.enable-testing-commands = yes
}

For me, adding the following two lines to the participant1 configuration in the sample-topology.conf file…

admin-api.address = "0.0.0.0"
ledger-api.address = "0.0.0.0"

… avoids the GrpcServiceUnavailable: UNAVAILABLE/io exception.

1 Like

Yes, thanks, in this way it works fine.