MIME-Version: 1.0
In-Reply-To: 
 <CA+OCxozb_ZPzw68zZmWNbGsNazhnQss+48n1MVkjS-xaELTXEg@mail.gmail.com>
References: 
 <CAB_Kkxw66uKr8B7yaurTpR_aOt-i+o+cEtvNHD4pBHtWANKsNQ@mail.gmail.com>
 <CA+OCxozUV33WchaAZX3miWG2446bQzNJQxtgc6SmmAieNBfQTA@mail.gmail.com>
 <CAB_KkxxEoQOR9qA5gfC9U27hA1J06tywfkDEcaiWmaCZSLHMQA@mail.gmail.com>
 <CA+OCxox+2hFzb-n3X8ozE-53iR80W2HYWMKTmU=xEbuLBvLrFQ@mail.gmail.com>
 <CAB_KkxytgS+rv17wgLxS5wePLL8YXXj9LqBCE4VgghfU5gQkFA@mail.gmail.com>
 <CA+OCxozb_ZPzw68zZmWNbGsNazhnQss+48n1MVkjS-xaELTXEg@mail.gmail.com>
From: =?UTF-8?B?0JzQsNC60YHQuNC8INCa0L7Qu9GM0YbQvtCy?= <kolmax94@gmail.com>
Date: Fri, 16 Mar 2018 23:52:02 +0300
Message-ID: 
 <CAB_Kkxyekd22aG-Y38EDMWL1woO3v4aiiZ3T432=fjGOB89gtQ@mail.gmail.com>
Subject: Re: Proposal for changes in official Docker image
To: Dave Page <dpage@pgadmin.org>
Cc: pgadmin-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

2018-02-26 13:46 GMT+03:00 Dave Page <dpage@pgadmin.org>:
> Hi
>
> On Mon, Feb 26, 2018 at 10:09 AM, =D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC =
=D0=9A=D0=BE=D0=BB=D1=8C=D1=86=D0=BE=D0=B2 <kolmax94@gmail.com> wrote:
>>
>> 2018-02-25 20:59 GMT+03:00 Dave Page <dpage@pgadmin.org>:
>> > Hi
>> >
>> > On Sat, Feb 24, 2018 at 9:04 PM, =D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC =
=D0=9A=D0=BE=D0=BB=D1=8C=D1=86=D0=BE=D0=B2 <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, =D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=
=BC =D0=9A=D0=BE=D0=BB=D1=8C=D1=86=D0=BE=D0=B2 <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 ma=
ke
>> >> >> 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 heav=
y
>> >> >> 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, sen=
d
>> > 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 ca=
n
>> >> 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 c=
an
>> > (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 min=
d.
>>
>> 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 an=
d 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 figur=
e
> 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.

I've switched to Gunicorn, adding SSL support. It has the same
interface as the original container: PGADMIN_ENABLE_TLS,
/certs/server.key and /certs/server.cert.
I also incorporated building of sphinx manual in Dockerfile, so now
the image should be complete.

I noticed that I can't use gunicorn forking worker with pgadmin4, this
is probably caused by session implementation, but I'm not sure. You
can investigate this by using e.g. `-w 4` in entrypoint.sh, otherwise
it's working fine with single-process threaded worker.

I will make my work into a patch and send it to the mail list soon.
Meanwhile, it'd be great if you tested the updated image at
https://hub.docker.com/r/maksbotan/pgadmin4/

> Thanks, Dave.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company