Failure building samples with podman

[abitrolly]

Summary

Building with podman as described here https://buildpacks.io/docs/app-developer-guide/building-on-podman/ doesn't work as expected.

---

Reproduction

Steps

git clone https://github.com/buildpacks/samples
export DOCKER_HOST="unix://$(podman info -f "{{.Host.RemoteSocket.Path}}")" 
podman system service -t 60 & pack build sample-app -p samples/apps/ruby-bundler/ -B cnbs/sample-builder:jammy

Current behavior

...
Copying blob fc454e27c1c6 skipped: already exists  
Copying config 5840b7958b done   | 
Writing manifest to image destination
===> ANALYZING
ERROR: failed to build: executing lifecycle: failed to create 'analyzer' container: Error response from daemon: make cli opts(): making volume mountpoint for volume /var/run/docker.sock: mkdir /var/run/docker.sock: permission denied     

Expected behavior

No errors.

---

Environment

pack info

Pack:
  Version:  0.32.1+git-b14250b.build-5241
  OS/Arch:  linux/amd64

Default Lifecycle Version:  0.17.2

Supported Platform APIs:  0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12

docker info

$ podman version
Client:       Podman Engine
Version:      4.7.2
API Version:  4.7.2
Go Version:   go1.21.1
Built:        Tue Oct 31 17:32:01 2023
OS/Arch:      linux/amd64  

[jjbustamante]

Hi @abitrolly

Did you try this? --docker-host=inherit ?

[abitrolly]

@jjbustamante hi. Yea, I missed the notice. What there is an "if" in "If using a socket connection"? Is it possible to use podman without the socket connection?

The build progresses a bit futher, but still fails.

$ podman system service -t 3600 & pack build sample-app -p samples/apps/ruby-bundler/ -B cnbs/sample-builder:jammy --docker-host=inherit
...
===> BUILDING
WARN[0013] Requested oom_score_adj=0 is lower than the current one, changing to 100 
[builder] Timer: Builder started at 2023-11-30T04:09:55Z
[builder] ---> Ruby Buildpack
[builder] ---> Downloading and extracting Ruby 3.1.3
[builder] cat: /layers/samples_ruby-bundler/bundler.toml: No such file or directory
[builder] ---> Installing gems
[builder] [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path '/layers/samples_ruby-bundler/bundler'`, and stop using this flag
[builder] There was an error while trying to write to `/workspace/.bundle/config`. It is
[builder] likely that you need to grant write permissions for that path.
[builder] Timer: Builder ran for 1m26.009380747s and ended at 2023-11-30T04:11:21Z
[builder] ERROR: failed to build: exit status 23
ERROR: failed to build: executing lifecycle: failed with status code: 51

[jjbustamante]

Interesting, maybe our samples code is broken. Did you try building some other app with a paketo builder maybe?

@jjbustamante hi. Yea, I missed the notice. What there is an "if" in "If using a socket connection"? Is it possible to use podman without the socket connection?

We've being discussing this RFC, you can see the detail here which I think it is want you want. right?

Right now it is not possible to run without the socket connection.

I cc @dvaumoron (he is working in the RFC) and @matejvasek because you are always involved with podman stuffs

[abitrolly]

@jjbustamante building with heroku/builder:22 on another project seemed to work. Although I don't see why pack can not start the podman and do all these things automatically.

[dvaumoron]

I am not sure about what you mean by "start the podman", that can not be part of a container because it is used to manage them. and as an external dependency, that seem worse than relying on Docker whose socket is theorically installed automatically with it. That's why i think the proposition done with my RFC is interesting, it allows pack to became standalone.

[abitrolly]

I am not sure about what you mean by "start the podman"

This command starts podman API service.

podman system service -t 3600 

[dvaumoron]

Sure, but that seem a strange demand, because pack was initally meant to work with Docker, this command in Podman exists to ensure compatibility because Docker was the de facto standard. But which tools pack should support ? And so check if they exists, etc.

[dvaumoron]

What there is an "if" in "If using a socket connection"? Is it possible to use podman without the socket connection?

No, however in some case the lifecycle does not call the socket and rely on other mecanisms (volume mounted in the container running the lifecycle or direct sending of image in distant registry).

[abitrolly]

But which tools pack should support ?

I would vote for https://github.com/GoogleContainerTools/kaniko

[jjbustamante]

@jjbustamante building with heroku/builder:22 on another project seemed to work.

@abitrolly I think we have several issues with the samples applications (we now we need to work on them), but If I am not wrong, pack worked building the application on podman. I will close this issue based on that, feel free to open a ticket on the sample repo.

[abitrolly]

@jjbustamante can you transfer the issue? https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository

[abitrolly]

From the other side I believe some issue should be left open on documentation site too.

[dvaumoron]

I would vote for https://github.com/GoogleContainerTools/kaniko

Why ? It seem able to handle only dockerfile, in my opinion that does not fit the purpose of pack.

[abitrolly]

kaniko is rootless and daemonless. If pack is able to build stuff with kaniko, it will be able to build with any tool.

[dvaumoron]

Podman is rootless and daemonless too, it has a socket mode only to be compatible with tools which rely on the Docker socket. That's why, there is the RFC to include podman as a library to make pack standalone, rootless and daemonless.

However the purpose of Kaniko is to build image from a dockerfile, in a containerised way (as pack, but pack and buildpacks are more flexible). So Kaniko is not meant to run container (it's probably possible to twist it to do so as it containerize things, but that would be weird). Beside that, Podman is meant to manage container, as an equivalent of docker, therefore i believe that Podman is a better choice.