Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with running Kaniko in own containers #19

Open
syphernl opened this issue Oct 28, 2024 · 0 comments
Open

Problem with running Kaniko in own containers #19

syphernl opened this issue Oct 28, 2024 · 0 comments

Comments

@syphernl
Copy link
Contributor

syphernl commented Oct 28, 2024

While troubleshooting issues with another Semantic-Release plugin I stumbled upon the fact that Kaniko overrides the contents of the container it runs in while building a (multi-stage) container.
Before Kaniko runs there are 189 files in /usr/bin and after the run there are only 153, of which a bunch not included in the first run (but are part of installs done in the Dockerfile that Kaniko is building).

Now it is clear as to why they said that simply adding the Kaniko binary to another container is not recommended.. The docs state

It unpacks directly into its own container root and may overwrite anything already there

Reproduction scenario

  • Create a container with semantic-release + plugins + Kaniko executor + git
  • Before Kaniko executor ran: run git --version. Works, shows version.
  • Build a (multistage) image using this plugin, make sure the last step of the app container is apk del git (or apt-get purge git).
  • After Kaniko executor ran: run git --version. Git cannot be found anymore

Sure you can choose to not remove git explicitly, then it will be part of the container and still work afterwards but this will likely lead to issues if you are building a Debian image with an Alpine base or the other way around. Or same platform but with different versions (e.g. Alpine 3.12 vs 3.20)

Potential fix

In this issue similar problems are discussed and seems that chroot or proot are used as workarounds.
Since the latter requires SYS_PTRACE using chroot is probably a better idea..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant