refactor: adjust bpfd container runtime detection

[ejose19]

Fixes #1592

Description

Applies genuinetools/bpfd#19, which improves detection of container runtime based on mechanism used by systemd.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes unit tests
• Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.

Release Notes

Describe any changes here so maintainer can include it in the release notes, or delete this block.

- improve container detection

[Silvanoc]

I hope you are aware of the fact that this approach won't work if running from a container image not generated with Docker...

The file being used to detect the container runtime in reality only identifies the tool used to generate the container image. If I use a Docker engine to run a container image generated with buildah, that file will be missing. Still my workload is running in a Docker container.

What's even worse: if I use a container image generated with Docker, extract the rootfs and use it with chroot, Kaniko will believe to be running from a Docker container!

[ejose19]

@Silvanoc Yes, and I agree with all your points on #1592 (comment), would be better if docker applied the podman approach so detection wouldn't be so flaky. However, as long the changes doesn't require that much effort, we can apply the upstream workarounds so users doesn't encounter these errors.

What's even worse: if I use a container image generated with Docker, extract the rootfs and use it with chroot, Kaniko will believe to be running from a Docker container!

That doesn't seem like an usual case at all, and if you intend to run kaniko here, then it wouldn't be much different than having to use --force

[MyIgel]

After the latest version bump this change got reverted as the upstream mr did not got merged -> would it be possible to reapply it to release a new kaniko version @tejal29?

[imjasonh]

After the latest version bump this change got reverted as the upstream mr did not got merged -> would it be possible to reapply it to release a new kaniko version @tejal29?

Oh nice. Could you send a PR to add a replace in the go.mod so we get this change?

[skorpy2009]

Hey @imjasonh @priyawadhwa @dlorenc

I have the same problem and looked at the code. The use of this package seams to be only for this one very simple use case. Most of the package functionality seems not being used and we get an unmaintained (12/2018 last release(v0.0.1)) 3rd party hell which could be a few lines to detect the residency in a container and implementing it in kaniko should be less trouble in long term.
Any opinion before a PR is being opened?

Best
skorpy

[imjasonh]

+1 to using what we need, and dropping a seemingly-unmaintained dependency. Thanks for looking into it!

[MyIgel]

@imjasonh I added the code in #1996 as a PR which seems to be the better maintainable option, would that be a possible solution?