Re: Proposal for changes in official Docker image - Mailing list pgadmin-hackers

2018-02-25 20:59 GMT+03:00 Dave Page <dpage@pgadmin.org>:
> Hi
>
> On Sat, Feb 24, 2018 at 9:04 PM, Максим Кольцов <kolmax94@gmail.com> wrote:
>>
>> Hi
>>
>> 2018-02-19 12:13 GMT+03:00 Dave Page <dpage@pgadmin.org>:
>> > Hi
>> >
>> > On Sun, Feb 18, 2018 at 5:41 PM, Максим Кольцов <kolmax94@gmail.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.

> 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.