Re: Postgresql + containerization possible use case

From: o1bigtenor <o1bigtenor(at)gmail(dot)com>
To: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Postgresql + containerization possible use case
Date: 2021-12-10 14:02:33
Message-ID: CAPpdf59qoRUQa8Dj9u90t4YSUryAV2zX3kX+MiJZfvHOS5Y8QA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Dec 10, 2021 at 6:02 AM Achilleas Mantzios <
achill(at)matrix(dot)gatewaynet(dot)com> wrote:

> On 10/12/21 1:24 μ.μ., o1bigtenor wrote:
>
>
>
> On Fri, Dec 10, 2021 at 3:24 AM Achilleas Mantzios <
> achill(at)matrix(dot)gatewaynet(dot)com> wrote:
>
>> Hi
>> we are running some 140 remote servers (in the 7 seas via satellite
>> connections), and in each one of them we run:
>> - jboss
>> - postgresql
>> - uucp (not as a daemon)
>> - gpsd
>> - samba
>> - and possibly some other services
>>
>> Hardware and software upgrades are very hard since there is no physical
>> access to those servers by trained personnel, and also there is a diversity
>> of software versions.
>>
>> The idea for future upgrades is to containerize certain aspects of the
>> software. The questions are (I am not skilled in docker, only minimal
>> contact with lxd) :
>> - is this a valid use case for containerization?
>> - are there any gotchas around postgersql, the reliability of the system ?
>> - since we are talking about 4+ basic services (pgsqk, jboss, uucp,
>> samba), is docker a good fit or should we be looking into lxd as well?
>> - are there any success stories of other after following a similar path?
>>
>>
> Thanks
>
> My experience with LXD is that upon install you are now on a regular
> update plan that is impossible to change.
>
> Ehhmmm we are running some old versions there already (jboss, pgsql), LXD
> would not differ in this regard.
> What do you mean? that the updates for LXD are huge? short spaced/very
> regular?
> Can you pls elaborate some more on that?
>

Updates seem to happen very very regularly.
That means that the system is often tied up with the updating - - - NOT on
doing the function(s).
If there are any issues with the newest and bestest version - - - - well
you get to deal with not
only a hung system (happened a few times whilst I was trying this out (over
a longer period of
time as well)) but a system that isn't doing what you want it to be doing.
I chose to space the updates out to once a month - - - then followed senior
dev team
suggestions to control that and achieved a system that would not update
anything. To make
things even more interesting it was not possible to even remove snapd and
LXD. I was using
rm -r carefully and there was some error message that I no longer remember.
End result was
that I had to blow the system away and reinstall. I'm not a fan of doing
this nor a need to do
such to remove any program I choose to remove. My experiences told me that
the idea behind
this central management (ubuntu controlled updating and upgrading) was most
likely designed
to facilitate a paid serviced from Canonical which income from would cause
a very nice spike
in value to Canonical benefiting only a very tiny number of hands. The dev
team at LXD was
almost shrill in its defense of the 'we know best' thinking that this
behavior depicted. Somehow
running bleeding edge hasn't ever given me reliability. When it comes to
business - - - well I
want things to work - - - I'm not a programmer geek who is forever trying
to 'improve' something.
My existence is not validated by the umpteen hundred versions of my
software available out
there. My existence is better validated by what I can get done - - - - and
not necessarily what
someone else says I have to do right now (even in the middle of the
night!!!).
Does that help?

> This means that your very expensive data connection will be preempted for
> updates at the whim of the
> canonical crew. Suggest not using such (most using such on wireless
> connections seem to have found
> the resultant issues less than wonderful - - cost (on the data connection)
> being #1 and the inability to achieve
> solid reliability crowding it for #2).
>
> Crew has their own paid service. Business connection is for business not
> crew.
> What I am interested is, could docker be of any use in the above scenario?
> Containerization in general?
>

Know nothing about Docker and as a result of my foray into containerization
- - - - well - - - - I'm not a
fan at present. Much more likely to do something like set up a
RaspberryPi and then use that to do things
and if more is needed well - - - I'm considering micro-controllers linked
into SoCs (not necessarily RaspberryPi
but similar) and then possible one central perhaps full size server - - -
but then that server would be busy.
I also am using test systems for any level of system so I'm experimenting
on testing systems and things
don't move to the 'real work horses' until I'm happy that things are stable
and do what I want them to do.
Doesn't necessarily make for cheap but it has upped reliability and reduced
stress (when a primary use
system gets borked - - - whatever the reason - - - - life isn't fun until
its fixed - - - right?).

> The guys (admins/mgmt) here seem to be dead set on docker, but I have to
> guarantee some basic data safety requirements.
>

The 'book' says everything is wonderful - - - - if it were me - - - no
guarantees until 'I' am sure.
If they want it - - - - and want you to guarantee it - - - - I wouldn't
touch it myself!! (That's my opinion and
worth all of what you paid for it. I have pile of software installed on my
main use system - - - I'm looking
for good stuff that works and far too much stuff in the programming world
is hype and not function!!)

Regards

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2021-12-10 16:01:20 Re: Postgresql + containerization possible use case
Previous Message Achilleas Mantzios 2021-12-10 12:01:43 Re: Postgresql + containerization possible use case