Re: Proposal for changes in official Docker image

Hi

On Sat, Feb 24, 2018 at 9:04 PM, Максим Кольцов <kolmax94(at)gmail(dot)com> wrote:

> Hi
>
> 2018-02-19 12:13 GMT+03:00 Dave Page <dpage(at)pgadmin(dot)org>:
> > Hi
> >
> > On Sun, Feb 18, 2018 at 5:41 PM, Максим Кольцов <kolmax94(at)gmail(dot)com>
> wrote:
> >>
> >> Hi!
> >>
> >> I accidentially sent this email to pgsql-hackers yesterday, sorry!
> >>
> >> First of all, thanks for the great app :)
> >>
> >> I started using PgAdmin with docker image (dpage/pgadmin4) a few weeks
> >> ago, however I thought that it had some issues, so I decided to make
> >> my own image. Some of the advantages:
> >>
> >> - Use alpine linux instead of centos to greatly reduce image size
> >> (170MB vs 560MB)
> >> - Use lightweight pure-python HTTP server waitress instead of heavy
> >> apache/mod_wsgi
> >> - Use python 3.6
> >>
> >> You can test the image at https://hub.docker.com/r/maksbotan/pgadmin4/
> >> Readme contains more detailed explanation and usage instructions.
> >>
> >> The Dockerfile is hosted at github:
> >> https://github.com/maksbotan/pgadmin4_docker
> >>
> >> If you find my work useful, I'd love to make a contribution with these
> >> scripts, after some discussion with pgadmin developers and further
> >> improvements.
> >
> >
> > Please feel free to submit patches to the existing code. I have no
> objection
> > to the any of the alternate design decisions you've made (in principal),
> > except for the intentional lack of SSL support.
> >
> > Thanks, Dave.
>
> I updated my image to simplify installing of Python packages. I
> decided I do not need a separate build step after all.
> Can you point me at documentation on submitting patches to pgadmin?
>

There are some docs on the git repo and mailing list at
https://www.pgadmin.org/development/resources/. To submit a patch, send an
email to the hackers list describing the patch and attaching the "git diff"
formatted patch file.

>
> What are your points in including SSL support into container? This can
> be done by using, for example, gunicorn instead of waitress,
> but I believe that this should be handled by reverse-proxy, like
> nginx, in production environment. In non-production environment, i.e.
> on developer's localhost, you do not need SSL at all.
>
> By the way, in my opinion, on production there is one more task to be
> handled by reverse-proxy - static files. By that I mean that all
> static, not-changing files accessible at '/static/' URL should be
> extracted from the container and served by nginx from a local folder.
> This does not mean we shouldn't keep them in the image -- it's very
> convenient for localhost usage. I haven't found a way to extract
> all Flask's static files yet.

Well that additional complexity is a very good reason why using two
containers for this is overkill. Having two containers to run pgAdmin makes
things unnecessarily complex in my opinion, especially given that it can
(and is in the current container) achieved with the simple addition of a
config snippet for Apache and mod_ssl. The current trend for micro services
can easily be taken too far - we should keep the KISS principle in mind.

Another reason for including SSL support, is that users have asked for it.

Regards, Dave.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company