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

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?

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.