containers / buildah

A tool that facilitates building OCI images.
https://buildah.io
Apache License 2.0
7.44k stars 785 forks source link

buildah-from initializes network with CNI, but buildah-run does not #3597

Closed jawnsy closed 3 years ago

jawnsy commented 3 years ago

Description

buildah only seems to initialize the CNI plugin when buildah from is used, not buildah run. This means that, if you start a build container with no networking (--network=none), trying to add it during the run command fails. The documentation in cni-examples implies that buildah run should configure networking:

When buildah's buildah run command is used, or when buildah build needs to handle a RUN instruction, the processes which buildah starts are run in their own network namespace unless the --network=host option is used.

Steps to reproduce the issue:

  1. Create a build with networking disabled
  2. Run a step with --network=private

Describe the results you received:

Running a build using the default settings yields a correctly-configured network interface:

$ buildah from fedora
fedora-working-container
$ buildah run fedora-working-container dnf install -y -q iproute

Installed:
  iproute-5.10.0-2.fc34.x86_64             iproute-tc-5.10.0-2.fc34.x86_64      iptables-libs-1.8.7-8.fc34.x86_64              
  libibverbs-37.0-1.fc34.x86_64            libmnl-1.0.4-13.fc34.x86_64          libnetfilter_conntrack-1.0.8-2.fc34.x86_64     
  libnfnetlink-1.0.1-19.fc34.x86_64        libnl3-3.5.0-6.fc34.x86_64           libpcap-14:1.10.1-1.fc34.x86_64                
  linux-atm-libs-2.5.1-28.fc34.x86_64      psmisc-23.4-1.fc34.x86_64           

$ buildah run fedora-working-container ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether da:c8:6c:0b:3e:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::d8c8:6cff:fe0b:3eb3/64 scope link tentative 
       valid_lft forever preferred_lft forever

However, starting a build with --network=none and then adding --network=private in the run step yields different behavior (note that I have to install the iproute package with the host network namespace):

$ buildah from --network=none fedora
fedora-working-container
$ buildah run --network=host fedora-working-container dnf install -y -q iproute 

Installed:
  iproute-5.10.0-2.fc34.x86_64             iproute-tc-5.10.0-2.fc34.x86_64      iptables-libs-1.8.7-8.fc34.x86_64              
  libibverbs-37.0-1.fc34.x86_64            libmnl-1.0.4-13.fc34.x86_64          libnetfilter_conntrack-1.0.8-2.fc34.x86_64     
  libnfnetlink-1.0.1-19.fc34.x86_64        libnl3-3.5.0-6.fc34.x86_64           libpcap-14:1.10.1-1.fc34.x86_64                
  linux-atm-libs-2.5.1-28.fc34.x86_64      psmisc-23.4-1.fc34.x86_64           

$ buildah run --network=private fedora-working-container ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

Describe the results you expected:

I expected the behavior of running buildah from --network=private fedora and buildah from --network=none fedora followed by buildah run --network=private fedora-working-container to be the same; that buildah-run initializes networking.

Output of rpm -q buildah or apt list buildah:

$ apt list buildah
Listing... Done
buildah/testing,now 1.22.3+ds1-2 amd64 [installed]
buildah/testing 1.22.3+ds1-2 i386

Output of buildah version:

$ buildah version
Version:         1.22.3
Go Version:      go1.15.15
Image Spec:      1.0.1
Runtime Spec:    1.0.2-dev
CNI Spec:        0.4.0
libcni Version:  
image Version:   5.15.2
Git Commit:      
Built:           Wed Dec 31 16:00:00 1969
OS/Arch:         linux/amd64

Output of podman version if reporting a podman build issue:

n/a

*Output of `cat /etc/release`:**

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Output of uname -a:

$ uname -a
Linux pattern 5.14.0-2-amd64 #1 SMP Debian 5.14.9-2 (2021-10-03) x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

$ cat /etc/containers/storage.conf
cat: /etc/containers/storage.conf: No such file or directory
rhatdan commented 3 years ago

Interested in opening a PR to fix?

rhatdan commented 3 years ago

@flouthoc PTAL

jawnsy commented 3 years ago

Sure! I can use some guidance though since I'm not familiar with this code :smile:

flouthoc commented 3 years ago

@jawnsy Its a small patch above PR should fix this :)