CODEWITHSUNDEEP
dockerdocker-composedockerfile
RC1
RC1

Reputation: 55

How to access an app installed in a Docker container from another Docker container?

I have a Python server app running in a Python:alpine container. The server app makes use of different biological pipelines such as BLAST or Bowtie and others (all applications on their own without networking functionality).

Would it be better to install the third-party software in the Python:alpine container of the server app, or to have separate containers for each app? I think the second one would make more sense.

However, if I now have 3+ containers with my server app, BLAST, Bowtie, etc., how do I access these third-party apps from my server app?

Another advantage of having multiple containers would be that images exist on Docker hub for all the apps my server app requires.

To be clear, it is not about sharing data between containers (e.g. volumes, binds), but to make direct calls to apps in other containers.

Upvotes: 1

Views: 753

Answers (1)

ErikMD
ErikMD

Reputation: 14743

@DazWilkin's answer only focused on the last part of @RC1's question (how to make dockerized services available from the host on a specific port).

RESTful WS

The first part is linked to a general, implicit hypothesis when it comes to "dockerizing" applications: every "back-end" is expected to provide its services via RESTful Web Services, a.k.a. Web APIs.

To sum up, the "front-end" container will rely on the "back-ends" containers by using some dedicated HTTP requests (e.g., HTTP GET or HTTP POST… with a specific payload if need be).

A helper tool

So, how to make this "dockerization" possible, if you split your application in several containers?

You need to ensure that each of these "back-end" containers are HTTP-aware; so either you can find official Docker Hub images that provide this out-of-the-box, or you may want to do this task (dockerizing the CLI-based dependencies of your application) yourself, relying for example on this project:

https://github.com/proycon/clam

Quickly turn command-line applications into RESTful webservices with a web-application front-end. You provide a specification of your command line application, its input, output and parameters, and CLAM wraps around your application to form a fully fledged RESTful webservice.

Final remarks

All in all, is this strategy (splitting your CLI back-ends in several containers) really necessary?

The general answer is: yes, it can be a very good strategy in general, but not necessarily in your particular situation for each CLI back-end you use, so you may need to weigh the pros and cons, e.g.:

  • Pro (maintainability): each image/container (version and configuration) can be updated independently of the other images/containers;
  • Con (maintainability): it induces more bookkeeping to dockerize and maintain each image;
  • Pro (availability): if the computations done by a service are costly, they can be distributed among several copies of the same service;
  • Con (availability): an HTTP request to another container is slower, and less "robust" that a mere CLI system call within a single container;
  • etc.

Upvotes: 1

Related Questions