Обсуждение: pgAdmin4 Docker behind load balancer
Hello hackers,
We are currently using the dpage/pgadmin4 image to run a pgAdmin4 web interface behind an AWS application load balancer.
The load balancer is configured to check the health of containers by querying the /login URI and checking if it answers with a 200 HTTP code.
However the app always send a new cookie for this page, storing it into the mounted docker volume.
It is understandable that it is wanted to generate a new session on login, but as load balancers check numerous times a day this URI, it quickly fill and use all of the inodes of the volume as it generate session tokens, and consequently saturate also the inodes of the underlying system.
We are therefore looking for another URI to do our healthcheck that won't generate a new session item.
However it seems that even on statics assets or redirects, the app set the pga4_session cookie.
Is there another way available to do these checks ? Am I missing something ?
Thanks for your advices,
Kind regards.
/Lenain
> On 22 May 2018, at 18:07, Lenain <lenaing@gmail.com> wrote: > > Hello hackers, > > We are currently using the dpage/pgadmin4 image to run a pgAdmin4 web interface behind an AWS application load balancer. > The load balancer is configured to check the health of containers by querying the /login URI and checking if it answerswith a 200 HTTP code. > > However the app always send a new cookie for this page, storing it into the mounted docker volume. > It is understandable that it is wanted to generate a new session on login, but as load balancers check numerous times aday this URI, it quickly fill and use all of the inodes of the volume as it generate session tokens, and consequently saturatealso the inodes of the underlying system. > > We are therefore looking for another URI to do our healthcheck that won't generate a new session item. > However it seems that even on statics assets or redirects, the app set the pga4_session cookie. > > Is there another way available to do these checks ? Am I missing something ? This is the mailinglist for the core postgres database server. While there certainly are lots of people skilled in pgadmin here, you will probably have a better chance of getting help on the pgadmin-support mailinglist: https://www.postgresql.org/list/pgadmin-support/ cheers ./daniel
On Tue, May 22, 2018 at 8:09 PM, Daniel Gustafsson <daniel@yesql.se> wrote:
-- > On 22 May 2018, at 18:07, Lenain <lenaing@gmail.com> wrote:
>
> Hello hackers,
>
> We are currently using the dpage/pgadmin4 image to run a pgAdmin4 web interface behind an AWS application load balancer.
> The load balancer is configured to check the health of containers by querying the /login URI and checking if it answers with a 200 HTTP code.
>
> However the app always send a new cookie for this page, storing it into the mounted docker volume.
> It is understandable that it is wanted to generate a new session on login, but as load balancers check numerous times a day this URI, it quickly fill and use all of the inodes of the volume as it generate session tokens, and consequently saturate also the inodes of the underlying system.
>
> We are therefore looking for another URI to do our healthcheck that won't generate a new session item.
> However it seems that even on statics assets or redirects, the app set the pga4_session cookie.
>
> Is there another way available to do these checks ? Am I missing something ?
This is the mailinglist for the core postgres database server. While there
certainly are lots of people skilled in pgadmin here, you will probably have a
better chance of getting help on the pgadmin-support mailinglist:
https://www.postgresql.org/list/pgadmin-support/
+1
Though to save on traffic, /misc/ping should give you what you need.
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company