search

geosolutions-it / geonode-generic

Generic Geonode-project based app, to be used with docker/rancher
https://waffle.io/geosolutions-it/geonode-generic
3 stars 6 forks source link

Docker containers referenced in docker-compose should have explicit versions #33

Closed timlinux closed 6 years ago

timlinux commented 6 years ago

I am just wondering about the possibility of adopting semver or similar for your docker image tags. If I deploy today and the composition works or behaves in a specific way, my expectation is that it should do so tomorrow too. However using e.g. 

image: geosolutionsit/geonode-generic:master

gives me no guarantee that this will be the case - maybe tomorrow an image with a bug gets pushed to master and then I have a non-deployable configuration. Perhaps you could tag the dependent images to specific versions e.g.

image: geosolutionsit/geonode-generic:2.8.0

Perhaps with a build suffix if needed e.g.

image: geosolutionsit/geonode-generic:2.8.0-b1

and reference that in your docker-compose rather. Then increment the rancher file version when a new tested combination of containers provide a known good configuration.

There are other strategies one could follow e.g. like in QGIS server images I publish:

kartoza/qgis-server:LTR
kartoza/qgis-server:2.18
kartoza/qgis-server:2.18.20

Which are all aliases of each other. Then on the next bug fix release these become aliases to each other:

kartoza/qgis-server:LTR
kartoza/qgis-server:2.18
kartoza/qgis-server:2.18.21

That way in your rancher file you can reference the granularity you want and always have a roll-back position if you need it.

giohappy commented 6 years ago

Hi @timlinux yes, we considered semver but in this phase we prefered to keep the link to (our) master because we wanted to pull all the latest new things we put there. Consider that we are using our own GeoNode as a "buffer", because we don't wanted to be strictly dependent on upstream merges timeline. I know it's a dangereous practice (risk to fork) but we are doing our best to maintain a diligent internal policy :)

Anyway I agree with you. We could create different branches and point to them from corresponding Docker Hub tags.

What's your opinion @randomorder and @cezio ?

timlinux commented 6 years ago

Hi @giohappy. Yeah I am not so concerned with using semver or shallow forking of Geonode - even just having some sequential numbering scheme would be ok so that I can create a configuration that is guaranteed to work. Thanks!

giohappy commented 6 years ago

Well, I think that having geonode-generic branches following GeoNode semver would the best. It's just a metter of adapting the docker-compose template and tagging the branch on Docker Hub.

giohappy commented 6 years ago

@timlinux to say the truth, geonode-generic makes sense only if it's backed by current master, because it relies on UI customization, various enhancements to monitoring autoconfiguration, etc. So, as you suggest, I would only tag the geonode-generic image with progressive semver. I can wait further feedbacks from you before tagging 1.0

timlinux commented 6 years ago

So, as you suggest, I would only tag the geonode-generic image with progressive semver. I can wait further feedbacks from you before tagging 1.0

:+1: For this thanks