In the cr.yaml file, the backup agent image is percona/percona-server-mongodb-operator:1.9.0-backup. Where is it built from? I suppose that it’s more or less like this : GitHub - percona/percona-backup-mongodb: Percona Backup for MongoDB. But since you are not using the usually backup tag, there is a difference between the standalone version and the operator version?
1 Like
Hello @vhphan .
Here is the docker file: percona-backup-mongodb/Dockerfile.k8s at main · percona/percona-backup-mongodb · GitHub
Thanks. Also are there any “easy” way to add my self-signed CA cert to the image’s trust store? I have a cert error while trying to do backup-restore due to my s3-compatible storage is internal.
I tried to rebuilt the image with my cert included and it worked. I just wonder if there is an easier way to do so.
Unfortunately no for now. PBM does not support TLS verification skipping.
We have this ticket in our operators’ backlog: [K8SPSMDB-473] Allow to skip TLS verification for backup storage - Percona JIRA
And this in ticket for PBM to add this support: [PBM-680] Skip TLS verification for object storage - Percona JIRA
1 Like
I see. I can always build my own image from the original Percona’s one.
There is a problem to it, that the operator’s version service will detect difference between my backup version and the Percona-recommended one and will automatically switch back to recommended version. Sure I can turn off the SmartUpdate strategy but then I won’t get the update for MongoDB anymore. Any advice? I guess I can build my own version service that mimic Percona’s one, with some modification.
1 Like
Building a version service looks like an overkill. The simplest would be to get a cert from a trusted CA. It can be a free one, like letsencrypt. Is it an option?
1 Like
Yeah, it’s definitely an option. But you know big company, asking to change the cert of a service can be longer than building something of our own.
Thanks for you help, let’s consider this is solved.
1 Like