Re: Proposal for changes in official Docker image

Hi

On Mon, Feb 26, 2018 at 10:09 AM, Максим Кольцов <kolmax94(at)gmail(dot)com> wrote:

> 2018-02-25 20:59 GMT+03:00 Dave Page <dpage(at)pgadmin(dot)org>:
> > 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.
>
> I did not mean to run two containers. I mean that pgadmin image, as I
> picture it, may serve two purposes:
>
> - localhost deployment on developer's machine to ease interaction with
> postgres DB, local or remote.
> In this mode container serves it's own static files and is
> accessible via plain HTTP
> - Deployment in enterprise production environment, for many users,
> possibly accessible from the Internet.
> In this mode container should only serve the API, possibly running
> in several replicas. static files and SSL
> termination should be done by _existing_ nginx or something else
> present in that organisation. For that I'd wish
> to have a way to extract static files from the container for
> deployment, but not changing anything in the image.
>

As I see it, that does essentially mean two containers (or 1 container and
a VM or whatever). Either way, it adds a lot of complexity for the user.

>
> > Another reason for including SSL support, is that users have asked for
> it.
>
> In my humble opinion, if users want SSL support in application
> container, they are doing something wrong and are
> asking for troubles. But I respect this choice and I'm ready to allow
> for it. I'll integrate gunicorn server in the image, which
> supports SSL.

Doing it that way gives them both options (well, we'd still need to figure
out the static file extraction). Those that want a quick and easy SSL
solution can do it with one container, those running on localhost can use
plain HTTP, and those who want an external reverse proxy to add SSL would
also have that option. I think this would be the most flexible and
convenient for users.

Thanks, Dave.

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

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