0

I am running a java service in docker which is basically a socket server. I am able to run this using docker container and able publish and expose the port on the host machine and able to connect using client. All okay so far.

This java service is single threaded and needs to be that way. So to be able to serve multiple requests concurrently, I need to be able to scale this - by spawning multiple docker containers on the fly to run on different ports

I am thinking of writing a “listener” which will receive the requests from clients, spawn a docker container with the java service on a random port, share the ip and port to the client and from that point onwards, client will directly connect with the docker based java service. So basically write a broker to handle this using docker SDK. Does this approach sound correct ? is there any other better way of handling this ?

Thanks

Edits

What I need is "Scale on demand" - one new instance per client request. Not like scaling for load balancing or high availability. So I need to be able to share the IP and port for the newly spawned docker container to the client and client can thereafter directly connect with the container.

Edit #2

I set up Kubernetes and deployed a dummy java socket service on it. I have two nodes both with a public ip. I confirmed that I am able to connect to the server socket in both ways (1) by connecting to the load balancer of the service on the required host port (2) by connecting to the public ip of both the nodes on the random port acquired by the container and mapped to the required host port

This means that if I write a script on start-up of the container to post the container(node) ip and the random port it has acquired, to some external entity like MongoDB or something similar, my broaker can then share that with the client program to start communicating directly.

Does that sound doable?

Abhay Chaware
  • 333
  • 4
  • 14
  • I don't believe there's any other way to do this. You need some kind of a broker which will spawn a new container when one's requested. – Mike Doe Mar 19 '18 at 08:06
  • Thanks Michael .. That's what my initial thought was, but i want to rule out possibility of using a mature solution like kubernetes or swarm ( with some configuration ) like @yamenk suggested below. – Abhay Chaware Mar 19 '18 at 11:14

1 Answers1

0

You are simply reinventing the wheel. There are already available tools to achieve what you want.

Natively for Docker there is Docker swarm. It is the native container orchestration framework for Docker containers. Container instances in Docker swarm are load balanced by default.

You just specify the number of replicas you want of a container and requests coming in will be load balanced among all the instances in the swarm.

A client shouldn't know what the IP of the container is. A client only knows the host machine IP/DNS and the port on which the container is listening. The client requests to this host will then be load balanced in a round-robin fashion.

yamenk
  • 46,736
  • 10
  • 93
  • 87
  • Thanks for your response @yamenk. I have read about SWARM but i am not sure if it can handle these requirements - 1) maintain one-to-one session with each client ( as these are stateful interactions for more then few minutes ) 2) Open and maintain persistent TCP socket connection between client and container 3) We will need to go beyond one host machine since there can be hundreds of active sessions at any point of time – Abhay Chaware Mar 19 '18 at 10:18
  • and 4) number of containers is dynamic - it should automatically launch new container if existing capacity is 'reached' , e.g. if all the containers are "in use" – Abhay Chaware Mar 19 '18 at 10:24
  • @AbhayChaware For 4, I suggest that you consider kubernetes. It has an autoscaling feature. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ Again, I don't recommed that you build any custom things. Both kubernetes and docker swarm are very mature projects with a huge community of developers. If your end goa;l is scalability, both of these projects have scalability as a core feature. – yamenk Mar 19 '18 at 10:29
  • Sure. I 'll be more than happy to reuse mature products like Kubernetes and Swarm. From your experience with Kubernetes, will it help solve my requirements #1, #2 and #3 as well? – Abhay Chaware Mar 19 '18 at 10:32
  • I don't believe he fully understood your question Abhay. You should rephrase your question since you don't want to `scale` per se, but run `on-demand`. – Mike Doe Mar 19 '18 at 11:31