chore: add podman support to Makefile

[iTrooz]

Thank you for contributing to Velero!

Please add a summary of your change

This PR adds support for using the "podman" CLI executable instead of docker
I did 2 things:

• replaced the docker CLI invocations with the $(DOCKER) variable, defined at the top of the file
  - removed the -u $$(id -u):$$(id -g) of your docker run shell creation. I'm not sure if it was useful before, but my tests work fine without it.

I tested my changes on Linux, with both podman and docker, on targets local, test and update

Does your change fix a particular issue?

No

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file (make new-changelog) or comment /kind changelog-not-required on this PR.
• Updated the corresponding documentation in site/content/docs/main.

[iTrooz]

/kind changelog-not-required

[kaovilai]

Just noting that docker cli via podman compatibility works in this repo with its buildx. Do not require docker desktop license
https://podman-desktop.io/docs/migrating-from-docker/managing-docker-compatibility

[iTrooz]

Ok, I figured out why -u $$(id -u):$$(id -g) was useful with docker

Turns out docker does not use UID mapping by default, so files owned by e.g. 1000 on the host will still be owned by 1000 in the container, so you need -u and -g to have the correct user ID.
Podman, on the other hand, will map the host UID running the command to 0 by default (source)

In order to make both podman and docker work, I restored the user switch, and added the option --userns=keep-id to podman, which maps the host UID to itself in the container.
This normally has security implications, but since these containers are used to build the app and not run it in a production context, this has no negative effects.

I tested make ci locally with this change, it should work fine now

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.89%. Comparing base (c29ed91) to head (212f7c7).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9363   +/-   ##
=======================================
  Coverage   59.89%   59.89%           
=======================================
  Files         383      383           
  Lines       34949    34949           
=======================================
  Hits        20934    20934           
  Misses      12470    12470           
  Partials     1545     1545           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[blackpiglet]

It's better to use another word instead of DOCKER.
Essentially, podman is different from docker.
Using DOCKER is misleading.

[kaovilai]

Image tool, Container or builder should work

[iTrooz]

I initially named it DOCKER because that command had to be compatible with the Docker CLI interface, but okay I'll make the change

[blackpiglet]

I'm uncertain about this place.
Does podman support multiple platform builds the same way as docker?

[blackpiglet]

I found something here.
It seems docker and podman work differently.
how to build multi-architeture container images

[kaovilai]

Some commands are the same some are not.

[iTrooz]

Hum, the podman CLI does not seem to be fully equivalent to docker's, after all
Here are a few differences I've noted so far (I don't think there will be much else):

• buildx commands (create/rm) do not exist. I'll need to check why you need to use them, rather than "just" doing a build
• --provenance=false does not exist
• --output=type=docker is misinterpreted as "output the image into a folder named "type=docker""

These problems all arise on the container task. Other tasks (local, test, update) already work fine (I'll need to test again with these breakages in mind)

As for platform builds, it seems podman supports the same --platform flag as docker, so I don't think it should cause a problem

All in all, this PR will be a little more complicated than just adding a variable and calling it a day. As such, I'd understand if you preferred to close it instead. If not, I am still ready to work on this in the next few days

[kaovilai]

Here's the main quirk you should be aware of.

containers/podman#27211