Closed Belphemur closed 3 months ago
Does this remove functionality for others i.e pg_dump 16 doesn't support Postgres 12 or something
@modem7 another thing where the s6 setup would shine dude
@modem7 another thing where the s6 setup would shine dude
grantbevis We can certainly investigate a custom startup section where people can add their own packages/scripts or something, or simplify it and have a ENV var which people can add their own values which are then installed during container startup if it's populated.
This would then reduce/eliminate bugs and changes that affect a majority of people just for (potential) edge cases.
pgclient lib are always backward compatible with older server. Or that has been my experience in the past, since you need to use some of those tools when doing database migration from major versions to other major version (like 15 -> 16).
@grantbevis by the way, the current image is packet with PG Client 15.4 and does work for any lower version. (Just do psql --version
if you want to check).
About the image itself, it would be great to remake it from linuxserver base, they have a great alpine one with proper user management etc ... (it does use S6) https://github.com/linuxserver/docker-baseimage-alpine
Hello,
pg_dump 16.1 is available in alpine 3.19.
So I suggest to rebase the Dockerfile to 3.11-alpine3.19 (from python:3.11.5-alpine3.18 currently) or better directly use python:3.11-alpine or python:3-alpine
https://hub.docker.com/_/python 3.11.7-alpine3.19, 3.11-alpine3.19, 3.11.7-alpine, 3.11-alpine -or- 3.12.1-alpine3.19, 3.12-alpine3.19, 3-alpine3.19, alpine3.19, 3.12.1-alpine, 3.12-alpine, 3-alpine, alpine
diff --git a/Dockerfile b/Dockerfile
index 39bf473..8717dcc 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,5 +1,5 @@
# syntax = docker/dockerfile:latest
-FROM python:3.11.5-alpine3.18
+FROM python:3.11-alpine
LABEL maintainer='github.com/borgmatic-collective'
VOLUME /mnt/source
VOLUME /mnt/borg-repository
@@ -22,12 +22,13 @@ RUN apk add --update --no-cache \
mariadb-client \
mariadb-connector-c \
mongodb-tools \
- openssl1.1-compat \
+ openssl \
postgresql-client \
sqlite \
sshfs \
supercronic \
tzdata \
+ && apk upgrade --update --no-cache \
&& rm -rf \
/var/cache/apk/* \
/.cache
Hello,
pg_dump 16.1 is available in alpine 3.19.
So I suggest to rebase the Dockerfile to 3.11-alpine3.19 (from python:3.11.5-alpine3.18 currently) or better directly use python:3.11-alpine or python:3-alpine
I'm just testing python:3.11.7-alpine3.19
now for viability.
We can't use 3.12 currently as there are issues with building the wheel files, and I'm not overly comfortable tagging major versions instead of minor.
python:3.11.7-alpine3.19
fails build as there are packages missing in the Alpine repos (like openssl1.1-compat
).
https://gitlab.alpinelinux.org/alpine/aports/-/issues/15575 https://drone.modem7.com/modem7/docker-borgmatic/251/1/3
python:3.11.7-alpine3.18
seems to work, however. I'm doing a backup now to see how it goes.
FYI The above patch works for me and I am able to backup both Postgres 16 (postgres:16-bookworm) and MariaDB 11 (mariadb:11). In terms of security, it would be nice to add "apk upgrade --update --no-cache" in order to apply security updates to Alpine if they are not yet included in python docker image.
What's wrong with using alpine 3.19 with openssl instead of openssl1.1-compat? https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
so I think python:3.11-alpine3.19 or python:3.11-alpine can be a good fit no?
I made backups overnight, including files, postgres 16, mariadb, etc. without any problems.
What's wrong with using alpine 3.19 with openssl instead of openssl1.1-compat? https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
so I think python:3.11-alpine3.19 or python:3.11-alpine can be a good fit no?
I made backups overnight, including files, postgres 16, mariadb, etc. without any problems.
Sorry for taking so long to reply, work was slammed.
After doing some extra testing, I concur. We can use openssl instead of compat.
I propose the following:
Use python:3.11.7-alpine3.19
as the image.
Use openssl
instead of openssl1.1-compat
.
@jejbq @grantbevis @Belphemur
I'd be happy to review and approve with those changes in place if you can update/recreate the PR.
@modem7 requested changes are done :)
is there a way I can use this right away? currently my databases are not being backed up, which isn't great.
is there a way I can use this right away? currently my databases are not being backed up, which isn't great.
You can build your own image and utilise the dockerfile present.
Over the weekend I'll see what I can do to expedite either this or a slightly new direction I'd like to go which will still achieve the same thing.
Thank you for the reply. I have this deployed on Unraid, so it's not straightforward to build images for use there, ideally I'd point to a public Docker repo using a specific tag. I suppose I can set that up myself tomorrow by building on my main pc and pushing to Dockerhub using my own repo.
well would you look at that, I've done it, and it works. nice.
value to put in unraid repo field: jibbsisme/borgmatic-pg16:v2
image on dockerhub: https://hub.docker.com/r/jibbsisme/borgmatic-pg16
quick and dirty how I did this, for anyone who wants to without trusting my image:
set up dockerhub:
docker login
build and push:
docker build -t "jibbsisme/borgmatic-pg16:v2" .
(replace jibbsisme
with your username and borgmatic-pg16
with your repo name)docker push jibbsisme/borgmatic-pg16:v2
(same replacements as above)
For now, the client for 16 is only available in edge. This is needed if the user is dumping databases from a postgres 16 server.
Without this, the pg_dump will fail.
This is only temporary until alpine add the 16 client to main