containers / buildah Goto Github PK

View Code? Open in Web Editor NEW

7.2K 99.0 766.0 70.1 MB

A tool that facilitates building OCI images.

Home Page: https://buildah.io

License: Apache License 2.0

Go 68.22% Makefile 0.47% Shell 29.84% Roff 0.05% Dockerfile 0.65% Awk 0.02% Nix 0.26% Perl 0.47% Assembly 0.02%

container-image container docker oci containers oci-image podman

buildah's Introduction

Buildah - a tool that facilitates building Open Container Initiative (OCI) container images

The Buildah package provides a command line tool that can be used to

create a working container, either from scratch or using an image as a starting point
create an image, either from a working container or via the instructions in a Dockerfile
images can be built in either the OCI image format or the traditional upstream docker image format
mount a working container's root filesystem for manipulation
unmount a working container's root filesystem
use the updated contents of a container's root filesystem as a filesystem layer to create a new image
delete a working container or an image
rename a local container

Buildah Information for Developers

For blogs, release announcements and more, please checkout the buildah.io website!

Buildah Container Images

Buildah Demos

Changelog

Contributing

Development Plan

Installation notes

Troubleshooting Guide

Tutorials

Buildah and Podman relationship

Buildah and Podman are two complementary open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah here and Podman here. Both, Buildah and Podman are command line tools that work on Open Container Initiative (OCI) images and containers. The two projects differentiate in their specialization.

Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. Buildah’s ultimate goal is to provide a lower-level coreutils interface to build images. The flexibility of building images without Dockerfiles allows for the integration of other scripting languages into the build process. Buildah follows a simple fork-exec model and does not run as a daemon but it is based on a comprehensive API in golang, which can be vendored into other tools.

Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images. For building container images via Dockerfiles, Podman uses Buildah's golang API and can be installed independently from Buildah.

A major difference between Podman and Buildah is their concept of a container. Podman allows users to create "traditional containers" where the intent of these containers is to be long lived. While Buildah containers are really just created to allow content to be added back to the container image. An easy way to think of it is the buildah run command emulates the RUN command in a Dockerfile while the podman run command emulates the docker run command in functionality. Because of this and their underlying storage differences, you can not see Podman containers from within Buildah or vice versa.

In short, Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.

Example

From ./examples/lighttpd.sh:

$ cat > lighttpd.sh <<"EOF"
#!/usr/bin/env bash

set -x

ctr1=$(buildah from "${1:-fedora}")

## Get all updates and install our minimal httpd server
buildah run "$ctr1" -- dnf update -y
buildah run "$ctr1" -- dnf install -y lighttpd

## Include some buildtime annotations
buildah config --annotation "com.example.build.host=$(uname -n)" "$ctr1"

## Run our server and expose the port
buildah config --cmd "/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf" "$ctr1"
buildah config --port 80 "$ctr1"

## Commit this container to an image name
buildah commit "$ctr1" "${2:-$USER/lighttpd}"
EOF

$ chmod +x lighttpd.sh
$ ./lighttpd.sh

Commands

Command	Description
buildah-add(1)	Add the contents of a file, URL, or a directory to the container.
buildah-build(1)	Build an image using instructions from Containerfiles or Dockerfiles.
buildah-commit(1)	Create an image from a working container.
buildah-config(1)	Update image configuration settings.
buildah-containers(1)	List the working containers and their base images.
buildah-copy(1)	Copies the contents of a file, URL, or directory into a container's working directory.
buildah-from(1)	Creates a new working container, either from scratch or using a specified image as a starting point.
buildah-images(1)	List images in local storage.
buildah-info(1)	Display Buildah system information.
buildah-inspect(1)	Inspects the configuration of a container or image.
buildah-mount(1)	Mount the working container's root filesystem.
buildah-pull(1)	Pull an image from the specified location.
buildah-push(1)	Push an image from local storage to elsewhere.
buildah-rename(1)	Rename a local container.
buildah-rm(1)	Removes one or more working containers.
buildah-rmi(1)	Removes one or more images.
buildah-run(1)	Run a command inside of the container.
buildah-tag(1)	Add an additional name to a local image.
buildah-umount(1)	Unmount a working container's root file system.
buildah-unshare(1)	Launch a command in a user namespace with modified ID mappings.
buildah-version(1)	Display the Buildah Version Information

Future goals include:

more CI tests
additional CLI commands (?)

buildah's People

Contributors

Stargazers

Watchers

Forkers

psakar rhatdan mrunalp nalind trishnaguha tomsweeneyredhat jlebon avineshwar j00bar kbsingh mohammedzee1000 umohnani8 14rcole hotelzululima ilackarms baude lsm5 tomastomecek chuanchang getcloudnative ashang-dot-org the-interesting-times-gang gbraad isnuryusuf coolsvap wbrefvem vbatts ravisantoshgudimetla ace-tang honghuac atgreen pombredanne bertinatto bluemutedwisdom devops-ua liangchenye bacongobbler anarcat mairin derekwaynecarr alexxnica kryndex ashcrow artmello sportsbitenews hishikur robertlemke pracplayllc haj mgugino-upstream-stage giuseppe shyukri arvind-sharma jwhonce pawelprazak vrothberg quaid zhouhao3 roujeen major ashleydumaine larhauga jcpowermac syldej andrewrothstein tristancacqueray mheon ipbabble haircommander mtrmac onofresouzadh kylerconway qbui rk-projects th3architect rpjday ghulevishal wking franklinharry karlmutch ehotinger pascalbourdier elijahlynn lookbeat ypu snehring jwendell steveb coderwangke scofields oliviergatsncf nicolaferraro aland-zhang smalldog124 estroz afbjorklund rickring qiwang19 bparees tim-jones-anthropos

buildah's Issues

Spurious SEGVs in buildah commit

This is on RHEL7 using devicemapper, so it may be an unsupported configuration.

# container=$(buildah --storage-driver devicemapper from fedora)
# while [ \! -s /tmp/buildah-crash.log ]; do buildah --storage-driver devicemapper commit $container containers-storage:myimage >/tmp/buildah-crash.log 2>&1;sleep 2;ls -l /tmp/buildah-crash.log;done
[may take a while. Or may fail on third attempt.]

See attached logs.

# uname -a
Linux esm-rhel7-d12-5 3.10.0-687.el7.x86_64 #1 SMP Mon Jun 26 15:34:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# git rev-parse HEAD
d9a77b38fc705be50bf7ff2fbb98a5bfdf1563ff
# rpm -qa|egrep 'golang|skopeo'|sort
golang-1.8.3-1.el7.x86_64
golang-bin-1.8.3-1.el7.x86_64
golang-github-cpuguy83-go-md2man-1.0.4-4.el7.x86_64
golang-src-1.8.3-1.el7.noarch
skopeo-0.1.20-1.1.gite802625.el7.x86_64
skopeo-containers-0.1.20-1.1.gite802625.el7.x86_64

buildah-crash-2.txt
buildah-crash-3.txt

Maybe use openshift/imagebuilder

Maybe use openshift/imagebuilder to handle parsing a dockerfile and letting it drive a multiple-step build process in the CLI.

How buildah identify image in use

The problem may occurred occasionally, it suddenly cannot remove the image redis. It said image is in use by a container, but buildah containers shows no container is running.

[root@fedora buildah]# ./buildah  mount
[root@fedora buildah]# ./buildah  containers
[root@fedora buildah]# ./buildah  images
IMAGE ID     IMAGE NAME
b812babf7f65 docker.io/library/redis:latest
b812babf7f65 docker.io/gouyang/redis:latest
b812babf7f65 docker.io/testing/redis:latest
b812babf7f65 docker.io/foo/redis:latest
5965adf86a6e docker.io/library/nginx:latest
223c6ba7409d docker.io/kubernetes/pause:latest
e236280e3ef7 docker.io/library/redis:alpine
a9a3ca121508 registry.access.redhat.com/rhel7/rhel:latest

[root@fedora buildah]# ./buildah  rmi docker.io/library/redis
error removing image "docker.io/library/redis": image is in use by a container
ERRO[0000] image is in use by a container               
[root@fedora buildah]# ./buildah  rmi b812babf7f65
ERRO[0000] reference "[overlay2@/var/lib/containers/storage]docker.io/library/b812babf7f65:latest" does not resolve to an image ID 
error removing image "b812babf7f65": image is in use by a container
ERRO[0000] image is in use by a container

Reading non-ociv1 image configs is lossy

Right now the tool assumes that image configurations can be decoded as OCI image-spec v1 Image objects. If the source image is anything else, we lose information this way.

buildah build-using-dockerfile not work

$ sudo ./buildah bud .
STEP 1: FROM fedora
STEP 2: RUN dnf -y update && dnf clean all
json: cannot unmarshal array into Go struct field Process.capabilities of type specs.LinuxCapabilities
ERRO[0000] error building: error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DISTTAG=f25docker FGC=f25 FBR=f25] Command:run Args:[dnf -y update && dnf clean all] Flags:[] Attrs:map[] Message:RUN dnf -y update && dnf clean all Original:RUN dnf -y update && dnf clean all}: exit status 1 

$ cat Dockerfile 
FROM fedora

RUN dnf -y update && dnf clean all
RUN dnf -y install nginx && RUN dnf clean all
RUN echo "daemon off" >> /etc/nginx/nginx.conf
RUN echo "nginx on Fedora" > /usr/share/nginx/html/index.html

EXPOSE 80

CMD [ "/usr/sbin/nginx" ]

buildah from image ID not work

[root@fedora buildah]# ./buildah from aa04e7c462d1f94ef011ddfc3d4e04149b1ff8af7da174b52ab38c700bfa46e4
ERRO[0000] error parsing reference to image "aa04e7c462d1f94ef011ddfc3d4e04149b1ff8af7da174b52ab38c700bfa46e4": invalid repository name (aa04e7c462d1f94ef011ddfc3d4e04149b1ff8af7da174b52ab38c700bfa46e4), cannot specify 64-byte hexadecimal strings 
[root@fedora buildah]# ./buildah from aa04e7c462d1
ERRO[0003] error pulling image "aa04e7c462d1": Error initializing image from source docker://aa04e7c462d1:latest: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

buildah bud/from --registry usage

What's the value of --registry should be, the help says prefix to prepend to the image name in order to pull the image (default: "docker://"). In cri-o project, look at crio.conf, there is key/value default_transport = "docker://", docker:// is named as default_transport.

I think the registry means something like docker.io or registry.access.redhat.com. I given a test on it, but it failed the test.

Don't write the registry in Dockerfile, only use rhel7/rhel, it not work.

[root@fedora buildah]# ./buildah bud --registry registry.access.redhat.com .
STEP 1: FROM rhel7/rhel
ERRO[0000] error building: error creating build container: error pulling image "rhel7/rhel": error parsing image name "registry.access.redhat.comrhel7/rhel": Invalid image name "registry.access.redhat.comrhel7/rhel", expected colon-separated transport:reference

Write registry in the Dockerfile, it works.

# ./buildah bud .
STEP 1: FROM registry.access.redhat.com/rhel7/rhel
STEP 2: RUN echo "test pull progress" 
test pull progress

Management of symlinks is messy

We provide options for creating symbolic links to a container's root filesystem as a convenience, but we don't do anything to prevent the location of a particular link from being specified as a link location for multiple containers. In the best case, that means we get EEXIST errors preventing mount operations from succeeding, and it's all downhill from there. We really need to design out how this should work, and that may lead to dropping it.

Potential symlink/directory traversal issue in user ID extraction

Commit b1bb73e (“ Teach "Run" to dig user IDs out of containers”) added the fopenContainerFile function. It does not correctly deal with symbolic links, which could point to something outside of the container root.

Unable to tag the image ID to new image

[root@fedora buildah]# ./buildah images
IMAGE ID     IMAGE NAME
b812babf7f65 docker.io/library/redis:latest
b812babf7f65 docker.io/gouyang/redis:latest
b812babf7f65 docker.io/testing/redis:latest
b812babf7f65 docker.io/foo/redis:latest
5965adf86a6e docker.io/library/nginx:latest
223c6ba7409d docker.io/kubernetes/pause:latest
e236280e3ef7 docker.io/library/redis:alpine
a9a3ca121508 registry.access.redhat.com/rhel7/rhel:latest
8dc56e5fe235 docker.io/library/busybox:latest
f8ca008a9d31 docker.io/library/busybox3:latest
d0a32bc20460 docker.io/library/redis2:latest
9334afa88fd3 
[root@fedora buildah]# ./buildah  tag 9334afa88fd3 gouyang/nginx
ERRO[0000] error finding local image "9334afa88fd3": unable to locate image: image not known

build-using-dockerfile doesn't import the source image's configuration correctly

@TomSweeneyRedHat noticed that build-using-dockerfile doesn't correctly import the configuration from the source image (the RunConfig that we pass in to the imagebuilder Builder is mostly empty), and is also lossy at saving some of the configuration settings which are set in the Dockerfile (we don't import everything from the Builder's ContainerConfig). Fixing this will overlap a bit with #85.

I believe `buildah add CONTAINERID SOURCE DEST` should work.

This would be closer to the syntax of docker build

Rather then
buildah add CONTAINERID SOURCE --dest DEST

Error when running bash inside container

[vagrant@localhost buildah]$ git rev-parse HEAD
2048c74819df152877183be35ab9358ec4fff534
[vagrant@localhost buildah]$ sudo buildah from centos:7
Getting image source signatures
Copying blob sha256:343b0936103607602d236363460c0368a1cad0ef58a534d5a5c2ecd9f8c2f3dd
 67.12 MiB / 67.26 MiB [=======================================================]
Copying config sha256:8140d0c64310d4e290bf3938757837dbb8f806acba0cb3f6a852558074345348
 0 B / 1.79 KiB [--------------------------------------------------------------]
Writing manifest to image destination
Storing signatures
centos-working-container
[vagrant@localhost buildah]$ sudo buildah containers
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
cc12d1d03918 1ac05484924e centos:7   centos-working-container
[vagrant@localhost buildah]$ sudo buildah run cc12d1d03918 /bin/sh
json: cannot unmarshal object into Go value of type []string

README, should be a lot more verbose.

Need to explain how to use.
Short command explanations.
How to contribute...

Add buildah mounts to list all mounted container's filesystem

After buildah mount CONTAINER-NAME-OR-ID, and do some other actions . It's inconvenient to get the mounted container's filesystem again unless to scroll up the screen or do buildah mount CONTAINER-NAME-OR-ID again. Suggest to add buildah mounts to list container name and mounted filesystem.

buildah does not report progress when pulling images

I thought skopeo needed to copy images from, e.g. DockerHub, and make them available before buildah runs, but it turns out that you can just: buildah from centos and it'll pull the image from DockerHub if needed. That's really great from a UX perspective, but it's hard to tell that's what is happening, since there's no progress indication.

Can we add some sort of status information (e.g. pulling image, pulling layers, etc) similar to how docker does it with its build/run commands?

Need to support adding signatures when committing or pushing

Similar in some ways to #96, we need to be able to add signatures to images when writing them.

Usability: include driver name in ErrNotSupported message

Current behavior:

# buildah from sdf
ERRO[0000] driver not supported
driver not supported

It took me a while to figure this out. A possibly more helpful message might be storage driver "overlay" not supported

Volume in the created image has different permissions

buildah version 0.1 (image-spec 1.0.0-rc5, runtime-spec 1.0.0-rc5) from buildah-0.1.0-2.git597d2ab.fc26.x86_64

Dockerfile:

FROM busybox
RUN mkdir /vol && touch /vol/foo
VOLUME /vol
RUN touch /vol/bar
CMD ["cat", "/vol/bar"]

Permissions in the image using docker build are drwxr-xr-x:

$ sudo docker run -ti test/04:dockerapi ls -la /vol
total 8
drwxr-xr-x    2 root     root          4096 Jun 19 18:00 .

Buildah image has drw-------:

$ sudo docker run -ti test/04:buildah ls -la /vol
total 8
drw-------    2 root     root          4096 Jun 19 18:03 .

Need to a mechanism in buildah from to specify a --storage-opt for the new container image.

We want to be able to specify the MAX Size of the image. To prevent people from accidentally pulling in images that are two large or getting screwed up with sparse files.

Builds without a base image don't work

Should be fixed by containers/storage#22, though.

add support to copying files from container

Hi, I'm working on adding support for buildah in Ansible (Container): ansible/ansible#26170

It seems like we may also need to copy files from container to host or another container. How difficult would it be to implement? Do you think that sufficient workaround could be to mount a directory instead?

Delete container got error "identifier is not a layer"

Not sure how it occurred, it should be happened occasionally.

[root@fedora buildah]# ./buildah containers 
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
aaeed31f4ddd b812babf7f65 redis      redis-working-container-2
a27d2cc74487 a37f13666262 testing/nginx nginx-working-container
e840e91f1cc7 a37f13666262 testing/nginx nginx-working-container-2
41addd8528fc a37f13666262 testing/nginx nginx

[root@fedora buildah]# ./buildah delete aaeed31f4ddd
error removing container "redis-working-container-2": error deleting build container: identifier is not a layer
ERRO[0000] error deleting build container: identifier is not a layer

run command: argument parsing is fuzzy

I want to invoke an inline shell script inside the container but unfortunately shell's options are being eaten by buildah:

$ sudo buildah run python-working-container /bin/sh -c 'ls /'
Incorrect Usage: flag provided but not defined: -c

NAME:
   buildah run - Run a command inside of the container

USAGE:
   buildah run [command options] CONTAINER-NAME-OR-ID COMMAND [ARGS [...]]

DESCRIPTION:
   Runs a specified command using the container's root filesystem as a root
   filesystem, using configuration settings inherited from the container's
   image or as specified using previous calls to the config command

OPTIONS:
   --runtime path            path to an alternate runtime (default: "runc")
   --runtime-flag value      add global flags for the container runtime
   --volume value, -v value  bind mount a host location into the container while running the command

ERRO[0000] flag provided but not defined: -c

$ sudo buildah run python-working-container /bin/sh "-c 'ls /'"
Incorrect Usage: flag provided but not defined: -c 'ls /'

...

$ sudo buildah run python-working-container /bin/sh -- -c 'ls /'
/bin/sh: 0: Can't open -c

$ sudo buildah run python-working-container /bin/sh '-c "ls /"'
Incorrect Usage: flag provided but not defined: -c "ls /"

...

buildah rmi tagged images also remove the original image

After buildah tag, the tagged image ID is same with the original image ID, so remove the tagged image also remove the original image, which is not reasonable.

buildah cannot work with truncated containerID

$ sudo ./buildah containers
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
f7c575d24354 fd5230ef7b97 docker.io/library/redis:latest redis-working-container
$ sudo ./buildah mount f7c575d24354
ERRO[0000] error reading build container "f7c575d24354": error reading build container: container not known

mount container name or the long containerID works.

$ sudo ./buildah mount redis-working-container
/var/lib/containers/storage/overlay2/241545a9bb5af26e0b60ba9af4af6900727618f011df2b13e2b0581f17231609/merged
$ sudo ./buildah containers -q
f7c575d2435448b5bb9567bcc33aef1480834f1d9b7ae5ed439dd54ee005ca79
$ sudo ./buildah mount f7c575d2435448b5bb9567bcc33aef1480834f1d9b7ae5ed439dd54ee005ca79
/var/lib/containers/storage/overlay2/241545a9bb5af26e0b60ba9af4af6900727618f011df2b13e2b0581f17231609/merged

Lets add @rh-atomic-bot support so we can enforce tests pass before merging.

@jlebon @cgwalters How can we setup buildah to use rh-atomic-bot?

We should be able to output images in non-OCI formats

We've always produced images that included OCI manifests and configuration data. We should be able to also produce images in a format that can be consumed by dockerd, if only for the sake of being simpler to integrate into other tooling which has historically only produced images in that format.

Add buildah tag like Docker tag

There is no way to tag an existing image to other name, how about to add a command buildah tag to do it?

provide documentation how to use `--runtime-flag` of run command

I literally have no idea what the flags are and how I should specify them. I went on and read source code which didn't help me really:

$ buildah --debug run --runtime-flag=WithoutTerminal -- buildah-container /bin/sh -c '/usr/bin/python && sleep 0'
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] using "/tmp/buildah566769552" to hold bundle data
DEBU[0000] config = {"ociVersion":"1.0.0-rc5","platform":{"os":"linux","arch":"amd64"},"process":{"terminal":true,"consoleSize":{"height":0,"width":0},"user":{"uid":0,"gid":0},"args":["/bin/sh","-c","/usr/bin/python \u0026\u0026 sleep 0"],"env":["PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","TERM=xterm","LANG=C.UTF-8","GPG_KEY=C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF","PYTHON_VERSION=2.7.13","PYTHON_PIP_VERSION=9.0.1"],"cwd":"/","capabilities":{"bounding":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"effective":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"inheritable":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"permitted":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"ambient":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"]},"rlimits":[{"type":"RLIMIT_NOFILE","hard":1024,"soft":1024}]},"root":{"path":"/var/lib/containers/storage/overlay/9b20ff75c09d5a38c2fa4690790b4f972e57655621cade4dddd15d03433a7e40/merged"},"hostname":"e11aa17d2971","mounts":[{"destination":"/proc","type":"proc","source":"proc"},{"destination":"/dev","type":"tmpfs","source":"tmpfs","options":["nosuid","strictatime","mode=755","size=65536k"]},{"destination":"/dev/pts","type":"devpts","source":"devpts","options":["nosuid","noexec","newinstance","ptmxmode=0666","mode=0620","gid=5"]},{"destination":"/dev/shm","type":"tmpfs","source":"shm","options":["nosuid","noexec","nodev","mode=1777","size=65536k"]},{"destination":"/dev/mqueue","type":"mqueue","source":"mqueue","options":["nosuid","noexec","nodev"]},{"destination":"/sys","type":"sysfs","source":"sysfs","options":["nosuid","noexec","nodev","ro"]},{"destination":"/etc/hosts","type":"bind","source":"/etc/hosts","options":["rbind","ro"]},{"destination":"/etc/resolv.conf","type":"bind","source":"/etc/resolv.conf","options":["rbind","ro"]}],"linux":{"resources":{"devices":[{"allow":false,"access":"rwm"}]},"namespaces":[{"type":"pid"},{"type":"ipc"},{"type":"uts"},{"type":"mount"}],"seccomp":{"defaultAction":"SCMP_ACT_ERRNO","architectures":["SCMP_ARCH_X86_64","SCMP_ARCH_X86","SCMP_ARCH_X32"],"syscalls":[{"names":["accept","accept4","access","alarm","bind","brk","capget","capset","chdir","chmod","chown","chown32","clock_getres","clock_gettime","clock_nanosleep","close","connect","copy_file_range","creat","dup","dup2","dup3","epoll_create","epoll_create1","epoll_ctl","epoll_ctl_old","epoll_pwait","epoll_wait","epoll_wait_old","eventfd","eventfd2","execve","execveat","exit","exit_group","faccessat","fadvise64","fadvise64_64","fallocate","fanotify_mark","fchdir","fchmod","fchmodat","fchown","fchown32","fchownat","fcntl","fcntl64","fdatasync","fgetxattr","flistxattr","flock","fork","fremovexattr","fsetxattr","fstat","fstat64","fstatat64","fstatfs","fstatfs64","fsync","ftruncate","ftruncate64","futex","futimesat","getcpu","getcwd","getdents","getdents64","getegid","getegid32","geteuid","geteuid32","getgid","getgid32","getgroups","getgroups32","getitimer","getpeername","getpgid","getpgrp","getpid","getppid","getpriority","getrandom","getresgid","getresgid32","getresuid","getresuid32","getrlimit","get_robust_list","getrusage","getsid","getsockname","getsockopt","get_thread_area","gettid","gettimeofday","getuid","getuid32","getxattr","inotify_add_watch","inotify_init","inotify_init1","inotify_rm_watch","io_cancel","ioctl","io_destroy","io_getevents","ioprio_get","ioprio_set","io_setup","io_submit","ipc","kill","lchown","lchown32","lgetxattr","link","linkat","listen","listxattr","llistxattr","_llseek","lremovexattr","lseek","lsetxattr","lstat","lstat64","madvise","memfd_create","mincore","mkdir","mkdirat","mknod","mknodat","mlock","mlock2","mlockall","mmap","mmap2","mprotect","mq_getsetattr","mq_notify","mq_open","mq_timedreceive","mq_timedsend","mq_unlink","mremap","msgctl","msgget","msgrcv","msgsnd","msync","munlock","munlockall","munmap","nanosleep","newfstatat","_newselect","open","openat","pause","pipe","pipe2","poll","ppoll","prctl","pread64","preadv","prlimit64","pselect6","pwrite64","pwritev","read","readahead","readlink","readlinkat","readv","recv","recvfrom","recvmmsg","recvmsg","remap_file_pages","removexattr","rename","renameat","renameat2","restart_syscall","rmdir","rt_sigaction","rt_sigpending","rt_sigprocmask","rt_sigqueueinfo","rt_sigreturn","rt_sigsuspend","rt_sigtimedwait","rt_tgsigqueueinfo","sched_getaffinity","sched_getattr","sched_getparam","sched_get_priority_max","sched_get_priority_min","sched_getscheduler","sched_rr_get_interval","sched_setaffinity","sched_setattr","sched_setparam","sched_setscheduler","sched_yield","seccomp","select","semctl","semget","semop","semtimedop","send","sendfile","sendfile64","sendmmsg","sendmsg","sendto","setfsgid","setfsgid32","setfsuid","setfsuid32","setgid","setgid32","setgroups","setgroups32","setitimer","setpgid","setpriority","setregid","setregid32","setresgid","setresgid32","setresuid","setresuid32","setreuid","setreuid32","setrlimit","set_robust_list","setsid","setsockopt","set_thread_area","set_tid_address","setuid","setuid32","setxattr","shmat","shmctl","shmdt","shmget","shutdown","sigaltstack","signalfd","signalfd4","sigreturn","socket","socketcall","socketpair","splice","stat","stat64","statfs","statfs64","symlink","symlinkat","sync","sync_file_range","syncfs","sysinfo","syslog","tee","tgkill","time","timer_create","timer_delete","timerfd_create","timerfd_gettime","timerfd_settime","timer_getoverrun","timer_gettime","timer_settime","times","tkill","truncate","truncate64","ugetrlimit","umask","uname","unlink","unlinkat","utime","utimensat","utimes","vfork","vmsplice","wait4","waitid","waitpid","write","writev"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["personality"],"action":"SCMP_ACT_ALLOW","args":[{"index":0,"value":0,"valueTwo":0,"op":"SCMP_CMP_EQ"},{"index":0,"value":8,"valueTwo":0,"op":"SCMP_CMP_EQ"},{"index":0,"value":4294967295,"valueTwo":0,"op":"SCMP_CMP_EQ"}],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["clone"],"action":"SCMP_ACT_ALLOW","args":[{"index":0,"value":2080505856,"valueTwo":0,"op":"SCMP_CMP_MASKED_EQ"}],"comment":""},{"names":["arch_prctl"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["modify_ldt"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""}]}}}
No help topic for 'WithoutTerminal'
DEBU[0000] error running runc [/bin/sh -c /usr/bin/python && sleep 0]: exit status 3
DEBU[0000] error running [/bin/sh -c /usr/bin/python && sleep 0] in container "buildah-container": exit status 3

Need an example rpm specification. Want to be able to install this tool

Could not get container name when remove an image which is in use

[root@fedora buildah]# ./buildah from busybox
busybox-working-container
[root@fedora buildah]# ./buildah rmi busybox
ERRO[0000] Could not remove image "busybox" (must force) - container '\x00' is using its reference image 

[root@fedora buildah]# ./buildah from fedora
fedora-working-container
[root@fedora buildah]# ./buildah rmi fedora
ERRO[0000] Could not remove image "fedora" (must force) - container '\x00' is using its reference image

Use github.com/pkg/errors to add context information to our errors

Right now, our API wraps some errors that it receives in additional context information before handing them back to our callers, but we're not super-consistent about it. Using the https://github.com/pkg/errors package's Wrapf function instead of fmt.Errorf would probably be more helpful for diagnosing problems.

We need man pages for each buildah command

Needs a run command

Ideally we'd have a run command that uses the image configuration to build a configuration that would tell runc to run a specified command inside of the container's root fs.

Need command completions. Bash ones at least.

Refactor into a library

Refactor the existing command line utility into something more reusable that the CLI can wrap instead.

Differences between buildah and containers/build?

Take this as light criticism, but these are two very similar projects, what's the difference between using buildah and acbuild (https://github.com/containers/build) (which is also OCI compliant?). Both are written in Go and look to achieve the same goal 🥇

Needs a run-on-the-host command

In addition to #3, in which we'd like to be able to run commands rooted in the container's root filesystem, we probably want a way to run an arbitrary command from outside as well. Being able to perform shell-like substitution of an environment variable that points to the container's root would be useful.

enable non-root operation

It seems like it ought to be possible to allow buildah to work without root/sudo access. This would enable using it in a lot of places other tools aren't available.

What would it take to enable non-root usage?

Need to figure out how to authenticate to registries

We need to be able to set the DockerAuthConfig in the DestinationCtx in the structure returned by the internal getCopyOptions() function, to support authenticating to registries. We also need to be able to retrieve values to set there, presumably from the same locations that skopeo supports.

Is buildah meant to be Linux only tool?

Given that buildah provides a binary that helps you create containers, and that many developers would use different Operating Systems on their laptop, is buildah targeting to work on multiple architectures, or it's just meant to run on linux?

missing carriage return in output before step 3 in 'buildah from'

buildah bud -t hellofromcontainer .

STEP 1: FROM python
Getting image source signatures
Copying blob
(removed a bunch of lines)
Storing signatures
STEP 2: ADD HelloFromContainer.py /
6.76 KiB / 6.76 KiB [=========================================================]STEP 3: CMD ["python","./HelloFromContainer.py"]
STEP 4: COMMIT

While using HelloFromContainer.py and Dockerfile.HelloFromContainer located here: https://github.com/TomSweeneyRedHat/TomsDockerfiles

How to inspect an image or container

buildah config can modify the configuration values which will be saved to an image, how to inspect these values from an image or a container?

Dockerfile with VOLUME instruction fails to build

buildah version 0.1 (image-spec 1.0.0-rc5, runtime-spec 1.0.0-rc5) from buildah-0.1.0-2.git597d2ab.fc26.x86_64

Dockerfile fails to build:

FROM busybox
RUN echo "a" > /a
VOLUME /b
CMD ["cat", "/a"]

$ buildah --storage-driver overlay2 bud --tag test/03:buildah /home/vrutkovs/src/image-comparison/tests/03
STEP 1: FROM busybox
STEP 2: RUN echo "a" > /a
STEP 3: VOLUME /b
time="2017-06-19T19:40:19+02:00" level=error msg="error building: error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:volume Args:[/b] Flags:[] Attrs:map[] Message:VOLUME /b Original:VOLUME /b}: stat /var/lib/containers/storage/overlay2/cf989ed6334eeb5a90874264c960220306577d7a07d0d0a48ff933d8ff272d7d/merged/b: no such file or directory"

Decide what "from" --mount should return

Normally, "from" prints the new container's name, and "mount" prints the location of the container's root filesystem, which is pretty friendly for scripting. If we tell "from" to also mount the container, though, printing both is not as friendly.

buildah build-using-dockerfile URL not work

$ sudo ./buildah  build-using-dockerfile  -f http://10.66.10.10/pub/Dockerfile
ERRO[0000] no context directory specified, and no dockerfile specified 
$ sudo ./buildah  build-using-dockerfile   http://10.66.10.10/pub/Dockerfile
ERRO[0000] error prepping temporary context directory: Error processing tar file(exit status 1): unexpected EOF

can buildah run in a docker container?

I'd like to use buildah inside a an OpenShift / Kubernetes pod. So I'm testing buildah from inside a docker container however buildah bud and buildah run commands fail with:

ERRO[0000] 'overlay' is not supported over overlay
ERRO[0000] 'overlay' is not supported over overlay
ERRO[0000] backing file system is unsupported for this graph driver
backing file system is unsupported for this graph driver

Should buildah-created containers be visible to runc or other tools?

After starting a build container, I can see container info in buildah containers:

$ buildah containers
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
979899ca9bdd 420ed202baa9 centos:7   centos-working-container
04c1c262f3c3 198b6e31178e debian:sid debian-working-container

I wanted to inspect container metadata, so I tried using skopeo inspect and runc list, but the containers aren't visible to those tools, even after playing with --root parameters. I guess those tools aren't appropriate anyway, as these are containers, not images (yet).

$ sudo runc --root /var/lib/containers/storage list
load container mounts: container "mounts" does not exist
load container overlay2: container "overlay2" does not exist
load container overlay2-containers: container "overlay2-containers" does not exist
load container overlay2-images: container "overlay2-images" does not exist
load container overlay2-layers: container "overlay2-layers" does not exist
load container tmp: container "tmp" does not exist
ID          PID         STATUS      BUNDLE      CREATED
$ sudo runc --root /var/run/containers/storage list
load container overlay2-containers: container "overlay2-containers" does not exist
load container overlay2-layers: container "overlay2-layers" does not exist
ID          PID         STATUS      BUNDLE      CREATED

Maybe some sort of buildah describe command that can dump out current config state of a build container would be useful? Additionally, some way to read configuration info using buildah config could be useful (e.g. if the user runs buildah config ctr1234 --user, it should print the "current" user?)

Jonathan

Needs to support creating multiple layers

Right now, we only generate a single additional layer that holds all of the difference between what we're doing and the source image. We're not strictly limited to doing that, though, and it'd be useful to be able to break up a series of changes that are being made into multiple layers, so that the changes could at least conceivably be shared with other images that build off of the same base image.