Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eqGIw-0003zl-JH for pgadmin-hackers@arkaria.postgresql.org; Mon, 26 Feb 2018 10:46:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eqGIv-0006E6-ET for pgadmin-hackers@arkaria.postgresql.org; Mon, 26 Feb 2018 10:46:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eqGIv-0006Dx-3d for pgadmin-hackers@lists.postgresql.org; Mon, 26 Feb 2018 10:46:45 +0000 Received: from mail-wr0-x242.google.com ([2a00:1450:400c:c0c::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eqGIm-0006HP-Rp for pgadmin-hackers@lists.postgresql.org; Mon, 26 Feb 2018 10:46:44 +0000 Received: by mail-wr0-x242.google.com with SMTP id n7so20682013wrn.5 for ; Mon, 26 Feb 2018 02:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7KzgypxnQ28E9LaNNZXUtjD5asSYGPb7SkZ4Iw2CyAc=; b=ZtUMquQFg6e8qeG1nb1/Pv2u8EarPX8QseIl3NJHglFHiH722AqIsYiStCQ+NVBBLA j2bqTy/unNvc0KZaIWfM0/U9FaesrEOqO87+VLSoi4iHZ48/1IK3YLZC8/QsZZTcwBu6 lKFiwm93F7qB03FBSQ+W3jJITBwckbP2bebeqXzRZ4AzK9habRq4xtscbCMl6AZYl+nI OxuzoXbiTuon1oWpbfMI3KgONmqsPC1+QpW6Yi0e7ZJXuxn9vbe4z5nOLG4ngWarprBR 1c5mqDX8oCccPdmRy1Emh8hMuthEbjj1+SJuiyM5MShnpASpwg1NVuKcu5jcP1qxHaXx Pq4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7KzgypxnQ28E9LaNNZXUtjD5asSYGPb7SkZ4Iw2CyAc=; b=KbssMkBISzf5XMDIfCfxYLLBwrAu+o0pQY9WURDehWQacdUbABaX+YIjC4aQLA4xWW 06sbPcYeBa2cfkYP9MTD7pzpuKZ2d3gJKrzZcOqs2o4+Dm37YrH3pK6e6RnO/G4AeNhC 3IUbK/t51xzUmg+2Vv3+PfRBQK1E10b84BSkGGDD+ivVF1Els8FC8Q2EL/beCVbVOMhr A52TXC5hbhU+pBxI61PlvEMb6A9jEr4pUkb+Hq/t+fy5tbVW4o+FhPADbKXMQD/kyLOC YwsDTnrRps9llu5Ix5Y24GspqmO1wYgtyQBSiYvxkQ4o7XVgahIc/lLAunLFczcrsqMX JxRw== X-Gm-Message-State: APf1xPC4tNu0YuXNmYGBuxL2fm8D4jVp672vgo1LduC9UaVab/y94DB2 TEx9W6fcefF2IAfey6+RVF7oUEc4ShuIXBi+B6dz+w== X-Google-Smtp-Source: AH8x225VTFu2M1yJJ4HQ9KD2E/VRzGz9MKQnNXmJVaUn0EXi1Lt9bMgGx4sk7R9w19gD1O/O8YWCS39IcqJvA8AR0GE= X-Received: by 10.223.184.230 with SMTP id c35mr8338537wrg.190.1519641994509; Mon, 26 Feb 2018 02:46:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.109.7 with HTTP; Mon, 26 Feb 2018 02:46:33 -0800 (PST) In-Reply-To: References: From: Dave Page Date: Mon, 26 Feb 2018 10:46:33 +0000 Message-ID: Subject: Re: Proposal for changes in official Docker image To: =?UTF-8?B?0JzQsNC60YHQuNC8INCa0L7Qu9GM0YbQvtCy?= Cc: pgadmin-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="f403045fab6c44eb6405661b39f9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --f403045fab6c44eb6405661b39f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 2018-02-25 20:59 GMT+03:00 Dave Page : > > 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 > wrote: > >> > >> Hi > >> > >> 2018-02-19 12:13 GMT+03:00 Dave Page : > >> > 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 > >> > 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 mak= e > >> >> 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 ca= n > > (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. --=20 Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --f403045fab6c44eb6405661b39f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 yesterda= y, 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 deci= ded to make
>> >> my own image. Some of the advantages:
>> >>
>> >> - Use alpine linux instead of centos to greatly reduce im= age size
>> >> (170MB vs 560MB)
>> >> - Use lightweight pure-python HTTP server waitress instea= d 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 instr= uctions.
>> >>
>> >> The Dockerfile is hosted at github:
>> >> https://github.com/maksbotan/pgad= min4_docker
>> >>
>> >> If you find my work useful, I'd love to make a contri= bution with these
>> >> scripts, after some discussion with pgadmin developers an= d further
>> >> improvements.
>> >
>> >
>> > Please feel free to submit patches to the existing code. I ha= ve 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/resource= s/. 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 sh= ould be
>> extracted from the container and served by nginx from a local fold= er.
>> This does not mean we shouldn't keep them in the image -- it&#= 39;s very
>> convenient for localhost usage. I haven't found a way to extra= ct
>> 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 ser= vices
> 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<= br> postgres DB, local or remote.
=C2=A0 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.
=C2=A0 In this mode container should only serve the API, possibly running in several replicas. static files and SSL
=C2=A0 termination should be done by _existing_ nginx or something else
present in that organisation. For that I'd wish
=C2=A0 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 c= ontainer and a VM or whatever). Either way, it adds a lot of complexity for= the user.
=C2=A0

> 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 extra= ction). Those that want a quick and easy SSL solution can do it with one co= ntainer, 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 t= his would be the most flexible and convenient for users.

Thanks, Dave.

--
D= ave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB U= K: http://www.ent= erprisedb.com
The Enterprise PostgreSQL Company
--f403045fab6c44eb6405661b39f9--