Re: Postgresql + containerization possible use case - Mailing list pgsql-general
| From | o1bigtenor |
|---|---|
| Subject | Re: Postgresql + containerization possible use case |
| Date | |
| Msg-id | CAPpdf59qoRUQa8Dj9u90t4YSUryAV2zX3kX+MiJZfvHOS5Y8QA@mail.gmail.com Whole thread Raw |
| In response to | Re: Postgresql + containerization possible use case (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
| Responses |
Re: Postgresql + containerization possible use case
(Achilleas Mantzios <achill@matrix.gatewaynet.com>)
|
| List | pgsql-general |
On Fri, Dec 10, 2021 at 6:02 AM Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
On 10/12/21 1:24 μ.μ., o1bigtenor wrote:ThanksOn Fri, Dec 10, 2021 at 3:24 AM Achilleas Mantzios <achill@matrix.gatewaynet.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?Ehhmmm we are running some old versions there already (jboss, pgsql), LXD would not differ in this regard.My experience with LXD is that upon install you are now on a regular update plan that is impossible to change.
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?
Crew has their own paid service. Business connection is for business not crew.This means that your very expensive data connection will be preempted for updates at the whim of thecanonical crew. Suggest not using such (most using such on wireless connections seem to have foundthe resultant issues less than wonderful - - cost (on the data connection) being #1 and the inability to achievesolid reliability crowding it for #2).
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
pgsql-general by date: