Integration of two images

General
1

Hi,

As a new commer, I would like to know about integration of two images.
I have a flask app that would be parent image. That would use another image that contains geo libraries such as gdal, proj, geos.

How can I construct this structure. Dockerfile or any other way?

I will appreciate if you guide me.

regards

2

Docker images donā€™t combine like that. An image only has one parent image, and thereā€™s no provision to merge the filesystems of two images.

Your question is a little unclear to me, so Iā€™ll suggest two paths that sound like what youā€™re saying:

You can build your own ā€œbase imageā€ that has the upstream python:3 with the GIS libraries you need added in; then install your actual application on an image based on that.

python:3 --> my_python_gis --> my_flask_app

You could split your application into a ā€œfront endā€, which has your existing Flask application, and a ā€œback endā€, which has the GIS libraries. Youā€™d need to write a second application in the ā€œback endā€ container (a second Flask app would be fine) and then connect to it from the ā€œfront endā€ container (e.g., using the requests library). If the set of calls into the ā€œback endā€ application was pretty stable, you could iteratively develop the ā€œfront endā€ application and redeploy only that as it changed.

          -> my_front_end
         /          |
        /           |
python:3         (HTTP)
        \           |
         \          v
          -> my_back_end
2 Likes
3

Thank you,
I was just planning to use flask to serve gis - maps that require gdal as a library.
I have flask and gdal images separately. I had thought to combine them.

I will work the way you have suggested.

1 Like
4

I agree with @dmaze although itā€™s fair to say there isnā€™t a right or wrong way to do this. Docker attracts a lot of commentary for solution designs that favour the decomposition of larger applications into micro-services and on the whole that can be a successful pattern. So in your example your would likely split the backend and front end functionality into separate containers, and you might even go further than that depending on other implementation details which you have not shared. For example you might have a caching layer, a messaging layer, some external APIs that get called and so on. All of those are candidates as micro-services. Of course the value proposition here is that it is (in some ways) easier to scale independent components, it creates a more loosely coupled but coherent design (so its easier to swap out individual parts) and managing the life-cycle of the micro-services also potentially gives rise to less breaking change, or at least reduces its blast radius. OTOH, highly distributed apps can be MUCH harder to reason about when things go wrong and can bring into play temporal dependencies, race conditions and other complex considerations. For that reason, some still prefer to use docker more as a packaging and distribution format for self contained apps (some might call this a monolith but that suggests that itā€™s wrong, and IMO it isnā€™t, itā€™s just a design choice). Your idea of ā€˜combiningā€™ the functionality would likely turn into a Dockerfile that implements a multi-stage build.

HtH

Fraser.

1 Like