Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

docker images hierarchy management

In one scenario where my IT team deploys many apps via docker. We have our own docker images, with others from the internet registry.

One (base) image could be an Operating System image, while another could be a runtime framework (for java, ruby, etc...), and still another could be some specific tools (such as git, some libs). Then, finally, we have images of our apps.

This means our container hierarchy looks like:

  1. app FROM tools and (ADD . /app)
  2. tools FROM framework
  3. framework FROM OS
  4. OS is the base container

Each container has its own Dockerfile.

Then if we need to create another app2, we can re-use our framework container. ok.

But if app3 comes along, using a similar frameworks2 container with little differences from framework, then we end up with another image framework2.

This makes it very hard to control versions of the apps with version image and its bases.

Finally, I chose only one Dockerfile. APP from OS and it makes everything and it Dockerfile is versioning with app.

Anyone have other ideas?

like image 778
Montells Avatar asked Nov 09 '22 23:11

Montells


1 Answers

We use docker most like yours, but we did not build every apps to a image.

We have one base os image, and many framework image such as php52, php53, Python2.7, nodejs and so on.

And try our best to make each framework image contain all dependents which our developers needs of his dev language.

When developer need active an app, he only need push his code to our git and start the containers from the framework image of his dev language. Because before we use docker, we have use kvm for a long time, and have collect almost all dependents what our developers needed and package in different kvm image. So we did that in docker and they only need to focus on their code.

I think build every app to an image is too heave and hardly do version control. If you build some base framework image and when they need update dependents you can only update you base framework image ,and restart a container from a new image is more quickly than traditional virtualization such as kvm. Even though this may cause images to large , but I thing it is better than have too many images and hard to control them.

My English is not good, I hope I have explan my idea exactly and do some help.

like image 170
tinytub Avatar answered Dec 14 '22 12:12

tinytub