Is it a good practice to run the command from one docker container on another container?

Viewed 184

Is it a good practice to run the command from one docker container on another container?

I have test docker and need to run java -jar commands to run the application on another docker.

docker_1:
 - tests

docket_2:
  - app1.jar
  - app2.jar

"tests" should run "app1.jar" and "app2.jar".

How can docker_1 ssh to docker_2 and run java commands?

Is it a good practice or overhead of communicating does not worth it?

1 Answers

This is not a good practice. It's technically tricky to set up, and it adds a dependency on Docker to your application (you wouldn't do this in a non-Docker development environment). If you use docker exec for this, that in effect requires unrestricted root-level permission on the host.

Trying to use ssh as a transport requires setting up credentials somewhere, which is tricky (you really should not write a plaintext root password in a Dockerfile or anywhere else). To get the server end to run you need to either run multiple processes in a container (also tricky) or make sshd be the main container process (not clear how Docker is beneficial here).

You will almost always want to communicate between containers using some sort of network API. In this setup you might run three containers, one each for the two applications and one for the test client. The two application containers would run long-running HTTP servers (maybe they're based on Tomcat or Spring Boot) and then the test container would make HTTP calls into one or both of them.

Occasionally it will make sense for a program in a container to directly run another program. This most often happens when it's a prebuilt short-running command-line tool that specifically acts on local files; building the HTTP facade would probably be more effort than the rest of the project. In these cases the support program needs to be in the same image as the calling code, including whatever language runtime or shared libraries it needs.

Related