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

"podman build -f Dockerfile build-root" is broken when using podman-remote #13293

Closed
Romain-Geissler-1A opened this issue Feb 19, 2022 · 7 comments · Fixed by #13531
Closed
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@Romain-Geissler-1A
Copy link
Contributor

Romain-Geissler-1A commented Feb 19, 2022

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

In unusual scenarios where you specify a specific Dockerfile path using "-f" in parent folder, the build works when using "podman local" but fails with "podman-remote". One would expect that it works with podman-remote too.

Steps to reproduce the issue:

  1. Start one podman container that will act as our "remote" podman machine:

$ podman run --name podman-remote --detach --rm --privileged --user podman -v /run/user/1000/podman quay.io/podman/upstream podman system service -t 0 unix:///run/user/1000/podman/podman.sock

  1. Start a podman container that will act as our "client" podman machine:

$ podman run -t -i --privileged --rm --volumes-from podman-remote quay.io/podman/upstream

  1. Inside the client container, create a file system tree like this:
[root@b1ee3f387429 /]# mkdir reproduce-bug
[root@b1ee3f387429 /]# cd reproduce-bug/
[root@b1ee3f387429 reproduce-bug]# echo "FROM fedora" > Dockerfile
[root@b1ee3f387429 reproduce-bug]# mkdir build-root
  1. Try building with "podman local", it works fine:
[root@b1ee3f387429 reproduce-bug]# podman build -f Dockerfile build-root
STEP 1/1: FROM fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob c6183d119aa8 done
Copying config e417cd49a8 done
Writing manifest to image destination
Storing signatures
COMMIT
--> e417cd49a84
e417cd49a84e1749071c516c4f0013ea62113cb5adc98a8504a63a04bfd43479
  1. Try building with "podman-remote", it's broken (because the dockerfile is NOT inside the "build-root" tree):
[root@b1ee3f387429 reproduce-bug]# podman --remote --url unix:///run/user/1000/podman/podman.sock build -f Dockerfile build-root
Error: stat /var/tmp/libpod_builder404755107/build/reproduce-bug/Dockerfile: no such file or directory
  1. Note that moving the Dockerfile into the build root makes it work (ie replacing "build-root" by "."):
[root@b1ee3f387429 reproduce-bug]# podman --remote --url unix:///run/user/1000/podman/podman.sock build -f Dockerfile .
STEP 1/1: FROM fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob sha256:c6183d119aa8953fe2cb6351e8fb4aeeb770f86c1aef3d534f7e02f5e2861321
Copying blob sha256:c6183d119aa8953fe2cb6351e8fb4aeeb770f86c1aef3d534f7e02f5e2861321
Copying config sha256:e417cd49a84e1749071c516c4f0013ea62113cb5adc98a8504a63a04bfd43479
Writing manifest to image destination
Storing signatures
COMMIT
--> e417cd49a84
e417cd49a84e1749071c516c4f0013ea62113cb5adc98a8504a63a04bfd43479

Describe the results you received:

podman build -f Dockerfile build-root works:

  • when run locally
  • when run remotely using a local unix socket bound to a podman server running on the same machine
  • is failing when using a unix socket bound to a podman server running on another machine (in this example, another container on the same machine).

Describe the results you expected:

podman build -f Dockerfile build-root shall work no matter if podman is running locally or remotely.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

[root@b1ee3f387429 reproduce-bug]# podman version
Client:       Podman Engine
Version:      4.0.0-dev
API Version:  4.0.0-dev
Go Version:   go1.16.14
Git Commit:   a88ea2c68b1ef01077a53b1c568b85667dcbc1e2
Built:        Fri Feb 18 08:07:27 2022
OS/Arch:      linux/amd64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes (this bug report was made using explicitly quay.io/podman/upstream

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 19, 2022
@cdoern
Copy link
Contributor

cdoern commented Feb 22, 2022

This could be due to the relative build path changes we made right before 4.0 I will look at this.

@cdoern cdoern self-assigned this Feb 22, 2022
@gbritton
Copy link

gbritton commented Mar 14, 2022

I think I'm seeing something very similar to this using podman-3.4.4-1.fc35.x86_64.

[gbritton@terps server]$ pwd
/var/home/gbritton/server
[gbritton@terps server]$ ls -a
.  ..  Dockerfile
[gbritton@terps server]$ cat Dockerfile
FROM server-dockerfile
[gbritton@terps server]$ podman system service --time 0
[gbritton@terps client]$ pwd
/var/home/gbritton/client
[gbritton@terps client]$ ls -a
.  ..  Dockerfile
[gbritton@terps client]$ cat Dockerfile
FROM client-dockerfile
[gbritton@terps client]$ podman --remote build - <Dockerfile
STEP 1/1: FROM server-dockerfile
Error: error creating build container: short-name resolution enforced but cannot prompt without a TTY

It looks like it's reading the Dockerfile from the cwd of the server here, not the file passed in via stdin on the client.
If i remove the Dockerfile from the server directory, it uses the client file:

[gbritton@terps client]$ rm ../server/Dockerfile
[gbritton@terps client]$ podman --remote build - <Dockerfile
STEP 1/1: FROM client-dockerfile
Error: error creating build container: short-name resolution enforced but cannot prompt without a TTY

I worked around this issue using this systemd dropin:

[gbritton@terps ~]$ cat ~/.config/systemd/user/podman.service.d/working_dir.conf
[Service]
WorkingDirectory=/

@cdoern
Copy link
Contributor

cdoern commented Mar 14, 2022

Thanks @gbritton I will look at both of these issues today.

@cdoern
Copy link
Contributor

cdoern commented Mar 15, 2022

@baude is this how context dirs are supposed to work? I thought podman build -f Containerfile context/dir should look for Containerfile within context/dir and otherwise fail?

@cdoern
Copy link
Contributor

cdoern commented Mar 15, 2022

yeah I think, looking at the code the local context dir gets ignored since we -f Containerfile. As for the remote example, if you actually look at the output @Romain-Geissler-1A the error is not checking in build-root but in reproduce-bug. I was able to reproduce locally in your scenario so I will look for a workaround for this use case (different machines). Did not think of this when fixing the issue, thanks for bringing it up.

cdoern pushed a commit to cdoern/podman that referenced this issue Mar 22, 2022
podman build fails on remote build when using a relative context directory.
This is because the context dir was not being added to the tar, so when remote
the compat build function would not be able to stat the contextDir.

resolves containers#13293

Signed-off-by: cdoern <[email protected]>
mheon pushed a commit to mheon/libpod that referenced this issue Mar 30, 2022
podman build fails on remote build when using a relative context directory.
This is because the context dir was not being added to the tar, so when remote
the compat build function would not be able to stat the contextDir.

resolves containers#13293

Signed-off-by: cdoern <[email protected]>
@Raniz85
Copy link

Raniz85 commented Apr 13, 2023

This issue still seems present in 4.4.4

Local:

podman build -f ./Dockerfile context
STEP 1/2: FROM docker.io/debian:bullseye
STEP 2/2: COPY test /test
COMMIT
--> 233a1ccae76
233a1ccae76506fa52815f8d8b9e9b04df270168057d7b0d70fd55e3439c1679

Server:

$ podman run -p 2375:2375 --rm quay.io/podman/stable podman system service -t 0 tcp://:2375

Client:

$ podman --remote --url tcp://localhost:2375 build -f ./Dockerfile context
Error: stat /var/tmp/libpod_builder561937789/build/home/raniz/src/podman-remote-test/Dockerfile: no such file or directory

Info:

Client:       Podman Engine
Version:      4.4.4
API Version:  4.4.4
Go Version:   go1.20.2
Git Commit:   c8223435f49a860c8ac4281a85db39232745a7cb-dirty
Built:        Tue Mar 28 15:21:36 2023
OS/Arch:      linux/amd64

Server:       Podman Engine
Version:      4.4.4
API Version:  4.4.4
Go Version:   go1.19.7
Built:        Mon Apr  3 13:31:25 2023
OS/Arch:      linux/amd64

Here's a script for repeatable reproduction:

#!/usr/bin/env bash

target=$(mktemp -d)
mkdir -p ${target}

cat <<EOF >${target}/Containerfile
FROM quay.io/fedora/fedora:latest

COPY test /test
EOF

mkdir -p ${target}/context
touch ${target}/context/test

# Start podman service
podman run --rm -d --name podman-service -p 2375:2375 quay.io/podman/stable:latest podman system service tcp://:2375

# Build
podman run --rm --name podman-remote --network host -v ${target}:/build quay.io/podman/stable:latest podman --remote --url tcp://localhost:2375 build -f /build/Containerfile /build/context

podman rm -f podman-service podman-remote
rm -rf "${target}"

@Raniz85
Copy link

Raniz85 commented May 4, 2023

@cdoern Any thoughts?

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Aug 25, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants