Add initial version of SimPhoNy Dockerfile. close #69

[mehdisadeghi]

@kitchoi @itziakos Please review this PR. My main purpose for this PR is discussing the provided Dockerfile and its feasibility for having a SimPhoNy pre-loaded image.

[kitchoi]

I would suggest renaming the file to Dockerfile.ubuntu12 something like that (rename it manually or make soft link when use or input etc).

[kitchoi]

hold on. I think it is better to change script than making assume-yes permanent. So far only apt-mayavi-deps target does not have the -y switch. That can be a trivial PR.

[mehdisadeghi]

I would suggest renaming the file to Dockerfile.ubuntu12 something like that (rename it manually or make soft link when use or input etc).

I suggest to delay this one until we have more Dockerfiles. For now, let's keep things simple and use the default convention (I am in learning phase myself).

I think it is better to change script than making assume-yes permanent

I send a tiny PR then!

[kitchoi]

I suggest to delay this one until we have more Dockerfiles. For now, let's keep things simple and use the default convention (I am in learning phase myself).

It is unlikely there would be another layer of scripts that try to explicitly load Dockerfile so it doesn't bother me to keep the name as it is now. :)

As a side note, It would be quicker for docker to load if one does something like this:

docker build -t simphony - < Dockerfile.ubuntu12

instead of

docker build -t simphony .

because docker would try to read the entire directory and look for a Dockerfile

[mehdisadeghi]

It is unlikely there would be another layer of scripts that try to explicitly load Dockerfile

Unless we go for a multi-container microservice-based system which is very unlikely :)

BTW, the most significant improvement that I can think of, is decreasing layers and size of the image, with moving out as many dev tools as possible. Currently the image is close to one gigabyte and takes a long time to build (I would like to add an automated docker hub build).

[kitchoi]

Which dev tools are you referring to? Which components are taking up most of the space?

[mehdisadeghi]

I can think of git itself, plus subversion and other build tools and compilers, but I don't know how much space they do occupy. I think, anything not used at runtime should not be present in final image.

[kitchoi]

Would be interesting to know if that would slim down the image, e.g. does docker cache the results for each command?

[mehdisadeghi]

Which components are taking up most of the space

With a closer look, it is openfoam222 which is taking 436 MB of disk space.

does docker cache the results for each command

each docker RUN command creates a layer on top of the previous RUN. If one creates a 500MB dummy file in first RUN and deletes it in the next RUN, the image would be still 500MB in size.

I meant that we can switch to user after all the deps targets are installed, i.e. after fix-pip

Today I played with the script a lot. I think it might be better to see Dockerfile independent from the makefile. The Makefile is written having an installation on a user machine in mind, Dockerfile should be written toward lightweight containers and automatic installation however.

[kitchoi]

In fact, I would prefer having the Dockerfile dependent on the makefile because that means we have less duplicated commands to maintain. e.g. newer version of openfoam wrapper is going to use openfoam230 or openfoam240 and we will have to change the script accordingly.

This piece is interesting: https://www.ctl.io/developers/blog/post/optimizing-docker-images/

[itziakos]

@mehdisadeghi any news on this PR it would be nice to have these images in the simphony project docker hub organization (https://hub.docker.com/u/simphonyproject/dashboard/)

[mehdisadeghi]

@itziakos I'll revisit this PR, not before M30 though. I'll add it to the simphony docker hub afterwards.

[stefanoborini]

Closing this PR. It is no longer relevant as we use a different approach when it comes to docker (simphony-remote-docker)