WIP:docker: use alpine flavor of postgres image

[leonklingele]

Image size reduced by over 68%, from 230MB down to 72.4MB.
Additionally, this seems to free around 2GB of intermediary images.

[leonklingele]

No database upgrade happened on my end and everything works fine after migrating to the new image, but please test this more carefully.

[leonklingele]

Can someone already running a Docker cluster please test this change (make sure to backup your postgres database first). I noticed this strange behavior on one of my instances (might be unrelated to this change though):

@omarroth any idea on what might cause this?

[omarroth]

My only guess would be that duplicate videos are being inserted into the database. Would you mind checking that videos has id set as a primary key? Something like:

invidious=# \d+ videos
...
Indexes:
    "videos_pkey" PRIMARY KEY, btree (id)
    "videos_id_idx" UNIQUE, btree (id)

[leonklingele]

Unfortunately, I have removed the "broken" database since and this never happened again.

postgres was logging lots of ERROR:  duplicate key value violates unique constraint "videos_pkey" messages:

2019-08-10 12:54:47.961 UTC [549] ERROR:  duplicate key value violates unique constraint "videos_pkey"
2019-08-10 12:54:47.961 UTC [549] DETAIL:  Key (id)=(REDACTED) already exists.
2019-08-10 12:54:47.961 UTC [549] STATEMENT:  UPDATE videos SET (info,updated,title,views,likes,dislikes,wilson_score,published,description,language,author,ucid,allowed_regions,is_family_friendly,genre,genre_url,license,sub_count_text,author_thumbnail)= (($2),($3),($4),($5),($6),($7),($8),($9),($10),($11),($12),($13),($14),($15),($16),($17),($18),($19),($20)) WHERE id = $1

How can an UPDATE even result in duplicate keys if the keyed-field is not touched?

[omarroth]

How can an UPDATE even result in duplicate keys if the keyed-field is not touched?

If there were already duplicates in the database, then an UPDATE would be performing an operation on multiple rows. I'm not sure how that would happen though, since if that constraint were dropped it shouldn't be able to be created again with duplicates still in the DB.

[omarroth]

Is this still WIP? From some quick testing it LGTM.

[leonklingele]

I'm still not sure / haven't tried to reproduce whether this change is responsible for spoiling the database as described in #687 (comment).

Anyone, feel free to test this with a backup of your instance.

[SISheogorath]

Be careful with postgres and the alpine base image. I had to learn the hard way that the debian based vs the alpine based images are not data-compatible.

docker-library/postgres#276

This can be solved by dumping and re-importing the db but this needs to be documented in upgrade instructions

[leonklingele]

Rebased & updated to postgres:10-alpine.

The upgrade was working fine for me this time, all data was transferred successfully..
@omarroth do you have a heavy database at hand to ensure an upgrade works there too?

[doc75]

On a fresh install, just changing the docker-compsoe.yml file from:

postgres:
    image: postgres:10

to:

postgres:
    image: postgres:10-alpine

is working fine.

Is there a real need to have code modification to support alpine version of postgres ?
It might be needed only for existing instance who want to migrate (not sure I have not tested this use-case)

[Perflyst]

We don't build our own postgres image anymore. The postgres image can be adjusted in docker-compose.yml on initial deployment. Changing this for everyone who uses the compose file is not such a good idea as it could lead to data corruption.

[github-actions]

This pull request has been automatically locked since there has not been any activity in it in the last 30 days. If you want to tell us about needed or wanted changes or if problems related to this code are discovered, feel free to open an issue or a new pull request.