[GeoNode-devel] Docker Strategy Chat
olivier.dalang at gmail.com
Wed Sep 5 18:49:31 PDT 2018
Hi all !
Some time has passed since we last discussed deployment with Docker. I'm
still willing to work on officially supporting docker deployment for
To move forward on the docker deployment, I suggest a two phase strategy.
1/ copy over the SPCgeonode repo to the geonode organization (more or less
as is) and document that deployment method as an official one l (but in
beta state). We'd need to find a good name for it - suggestions welcome.
2/ work on making the SPCgeonode setup and the setup in the main repo
converge, with the end goal of removing the docker deployment repo
altogether and have everything in the main repo, using the same
docker-compose, with a docker-compose.deploy.yml that adds deployment
specific elements (https, backups)
1/ could happen very soon (maybe even before next release), while 2/ would
take more time, as it requires to go carefully through both implementations
and take the best of both.
I think this would accommodate both the goal of having a ready deployment
method soon, and the final goal of having the deployment method use the
same docker images than dev, without being disruptive for users currently
relying on the docker images.
The reason why I think we must do it in 2 steps is that IMO, while good for
development, the current setup in the main repo still requires significant
work until it's usable as a base for deployment (docker images are too
heavy, split across many repos, images not properly versioned,
non-production ready elements such as static files being served by django,
no ci, etc.). That's not mentioning the additional steps needed for a
deployment meeting basic good practice requirements (https, backups...).
I would definitely be able to support the work on this as part of my
current activities. I also believe it meets a high demand from the
community (this is more or less my only serious contribution to Geonode, so
that I take my election in PSC a clear sign of that demand).
Francesco, would that 2 steps strategy be OK as you were keen to have the
spcgeonode setup reuse as much as possible existing docker setups ?
Let me know what you think. Let's discuss this, and if needed vote during
next PSC (though if we reach consensus before that it's even better).
On Fri, Apr 20, 2018 at 1:40 AM, Ariel Nunez <ariel at terranodo.io> wrote:
> I suscribe to the vision of geonode as a library and that a
> geonode-project should be a simple django project that does not import
> anything from geonode.settings. The reason for this is that geonode becomes
> a starting point and what people start to build are their own projects.
> I hope at some point in the near future we deprecate geonode.settings at
> all and instead let an ecosystem of different starter projects built on the
> same docker base images flourish.
> On Thu, Apr 19, 2018 at 5:52 AM Olivier Dalang <olivier.dalang at gmail.com>
>> Hello all !
>> Thank you all for the great discussion !! I very much appreciated how
>> much you all took into account my inputs and I felt part of the discussion
>> despite being deeply asleep :-) Thank you very much for the recording
>> Cristiano !
>> I think there are two different needs that were discussed, the need for
>> stable docker images (typically for providers to build their custom stacks
>> on reliable/secure images), and the need for a supported deployment through
>> docker-compose (typically for smaller users without skills/ressources to do
>> a proper deployment on their own).
>> So far I focused only on the docker-compose for deployment (as it's the
>> case we need to support here).
>> But I agree having those stable images would be great too. I think that
>> even if the needs are different, in the end they may very well align in one
>> setup, where the docker-compose setup for production could even serve as an
>> integration test of the individual docker files.
>> It's not completely clear to me what the scope of those images would be.
>> I think at the very least, they would include all dependencies (system and
>> Would they also include build steps (instead of pulling external builds
>> from builds.geonode.org) ? (may be good in terms of build stability and
>> make it easier to contribute, also with multistage dockerfiles it's quite
>> easy to keep images lightweight despite having the whole build process in
>> Would they be though as final images (that you use as is, just by
>> configuring env vars), or base images (that are supposed to serve as base
>> to user's custom dockerfiles in a composition) ?
>> Also it will be hard to find the sweet spot between too little
>> opinionated (it would become a pain to configure and loose stability) and
>> too much (you wouldn't be able to use it anymore in a custom stack).
>> I had another thought about docker-compose that I don't think was raised
>> : with the current geonode-project approach, there will be some
>> duplication, because there is already another docker-compose file in
>> Geonode's main repo (for development and testing of geonode itself - which
>> is obviously also needed).
>> Could it be that the docker-compose setup for deployment is built on top
>> of the docker-compose for development ? In the end, the geonode repo
>> already contains a django project. It's just a matter of being able to
>> override the settings. I'm not sure if this would end up being overly
>> complicated for nothing, or if it would be a win because of increased
>> similarity between dev setup and deployment setup. Going that way would be
>> a step towards a continuous delivery model (a big incentive for devs to
>> upstream their features). I also believe that with Alessio's recent
>> commits for UI customization, around 50% of the use cases for
>> geonode-project just vanished (thanks for that great feature :-) ).
>> I also agree with Tim on the idea of supporting both the QGIS and
>> Geoserver backends. I'm not familiar enough with the differences that
>> implies so far to tell how much work that would be.
>> And about the smaller scale technical questions :
>> - Containers restarting VS. wait-for-postgres.sh : I have no strong
>> opinion about that. It's true that it would look a little bit more elegant
>> at first startup, but it also adds a little bit of complexity in the
>> entrypoint, and we must make sure we don't create artificial blockages
>> (e.g. waiting for geoserver would be a bad idea, as we should be able to
>> start even if geoserver is down).
>> - Additional requirements (pip) : I'll try to make a PR to upstream those
>> fixes including some other to make pip install more stable, as discussed
>> here : https://github.com/GeoNode/geonode/issues/3227
>> - About the more minimal docker-compose (without letsencrypt and other
>> optional components), so far I use docker-compose up nginx django
>> geoserver postgres for that purpose, but we could indeed also use
>> docker-compose overrides to achieve similar result. I would vote for the
>> option that looks the most clear in the command line.
>> I'll continue to push my setup a bit further anyway (to 2.8) and agree
>> with idea of another talk at some point.
>> Thanks again!
>> On Thu, Apr 19, 2018 at 2:45 AM, Cristiano Giovando <giovand at gmail.com>
>>> Thanks to everyone who joined the docker chat today - here's the
>>> recording in case you missed it:
>>> Please share any feedback here or directly in the GNIP:
>>> Looking forward to a successful and coordinated approach! ;)
>>> On Tue, Apr 17, 2018 at 9:44 PM, Cristiano Giovando <giovand at gmail.com>
>>> > Hey all,
>>> > Following some good conversations around the topic at the summit and
>>> > recent GNIP by Olivier, we're planning a call tomorrow at 15:00 CEST /
>>> > UTC to chat about a common strategy. We're inviting anything who's
>>> > interested to join.
>>> > Here's the GNIP for reference:
>>> > https://github.com/GeoNode/geonode/issues/3707
>>> > Meeting link:
>>> > Join by phone
>>> > 1-650-479-3207 Call-in toll number (US/Canada)
>>> > Access code: 733 296 941
>>> > Global call-in numbers:
>>> > See you tomorrow!
>>> > Cristiano
>>> geonode-devel mailing list
>>> geonode-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geonode-devel