containers/buildah
1
0
Fork 0
mirror of https://github.com/containers/buildah.git synced 2026-02-05 09:45:38 +01:00
Code Issues Releases Wiki Activity

docs/tutorials: update

Browse Source 
Update tutorials to not expect `buildah run` to do anything if it isn't
given a command to run.  In some cases (including when we need to listen
for incoming connections when we might well not be root) this means we
use `podman run` instead.

Try to avoid using the terms container and image as though they're
interchangeable, which just creates confusion.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
This commit is contained in:
Nalin Dahyabhai
2021-10-04 17:27:02 -04:00
parent 8651267bde
commit 40317d6237
5 changed files with 383 additions and 233 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
docs/tutorials/01-intro.md
View File

@@ -3,20 +3,20 @@
# Buildah Tutorial 1
## Building OCI container images
The purpose of this tutorial is to demonstrate how Buildah can be used to build container images compliant with the [Open Container Initiative](https://www.opencontainers.org/) (OCI) [image specification](https://github.com/opencontainers/image-spec). Images can be built from existing images, from scratch, and using Dockerfiles. OCI images built using the Buildah command line tool (CLI) and the underlying OCI based technologies (e.g. [containers/image](https://github.com/containers/image) and [containers/storage](https://github.com/containers/storage)) are portable and can therefore run in a Docker environment.
The purpose of this tutorial is to demonstrate how Buildah can be used to build container images compliant with the [Open Container Initiative](https://www.opencontainers.org/) (OCI) [image specification](https://github.com/opencontainers/image-spec). Images can be built based on existing images, from scratch, and using Dockerfiles. OCI images built using the Buildah command line tool (CLI) and the underlying OCI based technologies (e.g. [containers/image](https://github.com/containers/image) and [containers/storage](https://github.com/containers/storage)) are portable and can therefore run in a Docker environment.
In brief the `containers/image` project provides mechanisms to copy, push, pull, inspect and sign container images. The `containers/storage` project provides mechanisms for storing filesystem layers, container images, and containers. Buildah is a CLI that takes advantage of these underlying projects and therefore allows you to build, move, and manage container images and containers.
In brief the `containers/image` project provides mechanisms to copy (push, pull), inspect, and sign container images. The `containers/storage` project provides mechanisms for storing filesystem layers, container images, and containers. Buildah is a CLI that takes advantage of these underlying projects and therefore allows you to build, move, and manage container images and containers.
Buildah works on a number of Linux distributions, but is not supported on Windows or Mac platforms at this time. Buildah specializes in building OCI images and [Podman](https://podman.io) specializes in all of the commands and functions that help you to maintain, modify and run OCI images and containers. For more information on the difference between the projects please refer to the [Buildah and Podman relationship](https://github.com/containers/buildah#buildah-and-podman-relationship) section on the main README.md.
Buildah works on a number of Linux distributions, but is not supported on Windows or Mac platforms at this time. Buildah specializes mainly in building OCI images while [Podman](https://podman.io) provides a broader set of commands and functions that help you to maintain, modify and run OCI images and containers. For more information on the difference between the projects please refer to the [Buildah and Podman relationship](https://github.com/containers/buildah#buildah-and-podman-relationship) section on the main README.md.
## Configure and Install Buildah
Note that installation instructions below assume you are running a Linux distro that uses `dnf` as its package manager, and have all prerequisites fulfilled. See Buildah's [installation instructions][buildah-install] for a full list of prerequisites, and the `buildah` installation section in the [official Red Hat documentation][rh-repo-docs] for RHEL-specific instructions.
[buildah-install]:../../install.md
[rh-repo-docs]:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/finding_running_and_building_containers_without_docker
[rh-repo-docs]:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/
First step is to install Buildah. Run as root because you will need to be root for running Buildah commands:
First step is to install Buildah. Run as root because you will need to be root for installing the Buildah package:
$ sudo -s
@@ -34,15 +34,15 @@ After installing Buildah we can see there are no images installed. The `buildah
# buildah images
We can also see that there are also no containers by running:
We can also see that there are also no working containers by running:
# buildah containers
When you build a working container from an existing image, Buildah defaults to appending '-working-container' to the image's name to construct a name for the container. The Buildah CLI conveniently returns the name of the new container. You can take advantage of this by assigning the returned value to a shell variable using standard shell assignment :
When you build a working container from an existing image, Buildah defaults to appending '-working-container' to the image's name to construct a name for the container. The Buildah CLI conveniently returns the name of the new container. You can take advantage of this by assigning the returned value to a shell variable using standard shell assignment:
# container=$(buildah from fedora)
It is not required to assign a shell variable. Running `buildah from fedora` is sufficient. It just helps simplify commands later. To see the name of the container that we stored in the shell variable:
It is not required to assign the container's name to a shell variable. Running `buildah from fedora` is sufficient. It just helps simplify commands later. To see the name of the container that we stored in the shell variable:
# echo $container
@@ -50,7 +50,7 @@ What can we do with this new container? Let's try running bash:
# buildah run $container bash
Notice we get a new shell prompt because we are running a bash shell inside of the container. It should be noted that `buildah run` is primarily intended for helping debug during the build process. A runtime like runc or a container interface like [CRI-O](https://github.com/kubernetes-sigs/cri-o) is more suited for starting containers in production.
Notice we get a new shell prompt because we are running a bash shell inside of the container. It should be noted that `buildah run` is primarily intended for debugging and running commands as part of the build process. A more full-featured engine like Podman or a container runtime interface service like [CRI-O](https://github.com/kubernetes-sigs/cri-o) is more suited for starting containers in production.
Be sure to `exit` out of the container and let's try running something else:
@@ -58,21 +58,21 @@ Be sure to `exit` out of the container and let's try running something else:
Oops. Java is not installed. A message containing something like the following was returned.
container_linux.go:274: starting container process caused "exec: \"java\": executable file not found in $PATH"
runc create failed: unable to start start container process: exec: "java": executable file not found in $PATH
Lets try installing it using:
Let's try installing it inside the container using:
# buildah run $container -- dnf -y install java
The `--` syntax basically tells Buildah: there are no more `buildah run` command options after this point. The options after this point are for inside the containers shell. It is required if the command we specify includes command line options which are not meant for Buildah.
The `--` syntax basically tells Buildah: there are no more `buildah run` command options after this point. The options after this point are for the command that's started inside the container. It is required if the command we specify includes command line options which are not meant for Buildah.
Now running `buildah run $container java` will show that Java has been installed. It will return the standard Java `Usage` output.
## Building a container from scratch
One of the advantages of using `buildah` to build OCI compliant container images is that you can easily build a container image from scratch and therefore exclude unnecessary packages from your image. E.g. most final container images for production probably don't need a package manager like `dnf`.
One of the advantages of using `buildah` to build OCI compliant container images is that you can easily build a container image from scratch and therefore exclude unnecessary packages from your image. Most final container images for production probably don't need a package manager like `dnf`.
Let's build a container from scratch. The special "image" name "scratch" tells Buildah to create an empty container. The container has a small amount of metadata about the container but no real Linux content.
Let's build a container and image from scratch. The special "image" name "scratch" tells Buildah to create an empty container. The container has a small amount of metadata about the container but no real Linux content.
# newcontainer=$(buildah from scratch)
@@ -86,46 +86,46 @@ You should see output similar to the following:
82af3b9a9488 * 3d85fcda5754 docker.io/library/fedora:latest fedora-working-container
ac8fa6be0f0a * scratch working-container
Its container name is working-container by default and it's stored in the `$newcontainer` variable. Notice the image name (IMAGE NAME) is "scratch". This just indicates that there is no real image yet. i.e. It is containers/storage but there is no representation in containers/image. So when we run:
Its container name is working-container by default and it's stored in the `$newcontainer` variable. Notice the image name (IMAGE NAME) is "scratch". This is a special value that indicates that the working container wasn't based on an image. When we run:
# buildah images
We don't see the image listed. There is no corresponding scratch image. It is an empty container.
We don't see the "scratch" image listed. There is no corresponding scratch image. A container based on "scratch" starts from nothing.
So does this container actually do anything? Let's see.
# buildah run $newcontainer bash
Nope. This really is empty. The package installer `dnf` is not even inside this container. It's essentially an empty layer on top of the kernel. So what can be done with that? Thankfully there is a `buildah mount` command.
Nope. This really is empty. The package installer `dnf` is not even inside this container. It's essentially an empty layer on top of the kernel. So what can be done with that? Thankfully there is a `buildah mount` command.
# scratchmnt=$(buildah mount $newcontainer)
Note: If attempting to mount in rootless mode, the command fails. Mounting an image needs to be done in a different mount namespace. Enter the mount namespace by executing the `buildah unshare` command. See buildah-mount(1) man page for more information.
Note: If attempting to mount in rootless mode, the command fails. Mounting a container can only be done in a mount namespace that you own. Create and enter a user namespace and mount namespace by executing the `buildah unshare` command. See buildah-mount(1) man page for more information.
$ buildah unshare
# scratchmnt=$(buildah mount $newcontainer)
By echoing `$scratchmnt` we can see the path for the [overlay image](https://wiki.archlinux.org/index.php/Overlay_filesystem), which gives you a link directly to the root file system of the container.
By echoing `$scratchmnt` we can see the path for the [overlay mount point](https://wiki.archlinux.org/index.php/Overlay_filesystem), which is used as the root file system for the container.
# echo $scratchmnt
/var/lib/containers/storage/overlay/b78d0e11957d15b5d1fe776293bd40a36c28825fb6cf76f407b4d0a95b2a200d/merged
Notice that the overlay image is under `/var/lib/containers/storage` as one would expect. (See above on `containers/storage` or for more information see [containers/storage](https://github.com/containers/storage).)
Notice that the overlay mount point is somewhere under `/var/lib/containers/storage` if you started out as root, and under your home directory's `.local/share/containers/storage` directory if you're in rootless mode. (See above on `containers/storage` or for more information see [containers/storage](https://github.com/containers/storage).)
Now that we have a new empty container we can install or remove software packages or simply copy content into that container. So let's install `bash` and `coreutils` so that we can run bash scripts. This could easily be `nginx` or other packages needed for your container.
**NOTE:** the version in the example below (33) relates to a Fedora version which is the Linux platform this example was run on. If you are using the scratch image, the version you specify must be valid for the host or dnf will throw an error. I.e. If you were to run this on a RHEL platform, you'd need to specify `--releasever 8.1` or similar instead of `--releasever 33`. If you want the container to be a particular Linux platform, change `scratch` in the first line of the example to the platform you want, i.e. `# newcontainer=$(buildah from fedora)`, and then you can specify an appropriate version number for that Linux platform.
**NOTE:** the version in the example below (35) relates to a Fedora version which is the Linux platform this example was run on. If you are running dnf on the host to populate the container, the version you specify must be valid for the host or dnf will throw an error. I.e. If you were to run this on a RHEL platform, you'd need to specify `--releasever 8.1` or similar instead of `--releasever 35`. If you want the container to be a particular Linux platform, change `scratch` in the first line of the example to the platform you want, i.e. `# newcontainer=$(buildah from fedora)`, and then you can specify an appropriate version number for that Linux platform.
# dnf install --installroot $scratchmnt --releasever 33 bash coreutils --setopt install_weak_deps=false -y
# dnf install --installroot $scratchmnt --releasever 35 bash coreutils --setopt install_weak_deps=false -y
Let's try it out (showing the prompt in this example to demonstrate the difference):
# buildah run $newcontainer bash
bash-4.4# cd /usr/bin
bash-4.4# ls
bash-4.4# exit
# buildah run $newcontainer sh
sh-5.1# cd /usr/bin
sh-5.1# ls
sh-5.1# exit
Notice we have a `/usr/bin` directory in the newcontainer's image layer. Let's first copy a simple file from our host into the container. Create a file called runecho.sh which contains the following:
Notice we now have a `/usr/bin` directory in the newcontainer's root file system. Let's first copy a simple file from our host into the container. Create a file called runecho.sh which contains the following:
#!/usr/bin/env bash
for i in `seq 0 9`;
@@ -137,8 +137,7 @@ Change the permissions on the file so that it can be run:
# chmod +x runecho.sh
With `buildah` files can be copied into the new image. We can then use `buildah run` to run that command within the container by specifying the command. We can also configure the image to run the command directly using [Podman](https://github.com/containers/podman) and its `podman run` command. In short the `buildah run` command is equivalent to the "RUN" command in a Dockerfile, whereas `podman run` is equivalent to the `docker run` command. Now let's copy this new command into the container's `/usr/bin` directory and configure the container to run the command when the container is run via podman:
With `buildah` files can be copied into the new container. We can then use `buildah run` to run that command within the container by specifying the command. We can also configure the image we'll create from this container to run the command directly when we run it using [Podman](https://github.com/containers/podman) and its `podman run` command. In short the `buildah run` command is equivalent to the "RUN" command in a Dockerfile (it always needs to be told what to run), whereas `podman run` is equivalent to the `docker run` command (it can look at the image's configuration to see what to run). Now let's copy this new command into the container's `/usr/bin` directory, configure the command to be run when the image is run by `podman`, and create an image from the container's root file system and configuration settings:
# To test with Podman, first install via:
# dnf -y install podman
@@ -146,6 +145,7 @@ With `buildah` files can be copied into the new image. We can then use `buildah
# buildah config --cmd /usr/bin/runecho.sh $newcontainer
# buildah commit $newcontainer newimage
We've got a new image named "newimage". The container is still there because we didn't remove it.
Now run the command in the container with Buildah specifying the command to run in the container:
# buildah run $newcontainer /usr/bin/runecho.sh
@@ -160,9 +160,9 @@ Now run the command in the container with Buildah specifying the command to run
This is a new container from ipbabble [ 8 ]
This is a new container from ipbabble [ 9 ]
Now run the command in the container with Podman (no command required):
Now use Podman to run the command in a new container based on our new image (no command required):
# podman run -t --rm newimage
# podman run --rm newimage
This is a new container from ipbabble [ 0 ]
This is a new container from ipbabble [ 1 ]
This is a new container from ipbabble [ 2 ]
@@ -174,28 +174,28 @@ Now run the command in the container with Podman (no command required):
This is a new container from ipbabble [ 8 ]
This is a new container from ipbabble [ 9 ]
It works! Congratulations, you have built a new OCI container from scratch that uses bash scripting.
It works! Congratulations, you have built a new OCI container image from scratch that uses bash scripting.
Back to Buildah, let's add some more configuration information.
# buildah config --created-by "ipbabble" $newcontainer
# buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora33-bashecho $newcontainer
# buildah config --author "wgh at redhat.com @ipbabble" --label name=fedora35-bashecho $newcontainer
We can inspect the container's metadata using the `inspect` command:
We can inspect the working container's metadata using the `inspect` command:
# buildah inspect $newcontainer
We should probably unmount and commit the image:
We should probably unmount the working container's rootfs. We will need to commit the container again to create an image that includes the two configuration changes we just made:
# buildah unmount $newcontainer
# buildah commit $newcontainer fedora-bashecho
# buildah images
And you can see there is a new image called `fedora-bashecho:latest`. You can inspect the new image using:
And you can see there is a new image called `localhost/fedora-bashecho:latest`. You can inspect the new image using:
# buildah inspect --type=image fedora-bashecho
Later when you want to create a new container or containers from this image, you simply need need to do `buildah from fedora-bashecho`. This will create a new containers based on this image for you.
Later when you want to create a new container or containers from this image, you simply need need to do `buildah from fedora-bashecho`. This will create a new container based on this image for you.
Now that you have the new image you can remove the scratch container called working-container:
@@ -207,18 +207,18 @@ or
## OCI images built using Buildah are portable
Let's test if this new OCI image is really portable to another OCI technology like Docker. First you should install Docker and start it. Notice that Docker requires a daemon process (that's quite big) in order to run any client commands. Buildah has no daemon requirement.
Let's test if this new OCI image is really portable to another container engine like Docker. First you should install Docker and start it. Notice that Docker requires a running daemon process in order to run any client commands. Buildah and Podman have no daemon requirement.
# dnf -y install docker
# systemctl start docker
Let's copy that image from where containers/storage stores it to where the Docker daemon stores its images, so that we can run it using Docker. We can achieve this using `buildah push`. This copies the image to Docker's repository area which is located under `/var/lib/docker`. Docker's repository is managed by the Docker daemon. This needs to be explicitly stated by telling Buildah to push to the Docker repository protocol using `docker-daemon:`.
Let's copy that image from where containers/storage stores it to where the Docker daemon stores its images, so that we can run it using Docker. We can achieve this using `buildah push`. This copies the image to Docker's storage area which is located under `/var/lib/docker`. Docker's storage is managed by the Docker daemon. This needs to be explicitly stated by telling Buildah to push the image to the Docker daemon using `docker-daemon:`.
# buildah push fedora-bashecho docker-daemon:fedora-bashecho:latest
Under the covers, the containers/image library calls into the containers/storage library to read the image's contents, and sends them to the local Docker daemon. This can take a little while. And usually you won't need to do this. If you're using `buildah` you are probably not using Docker. This is just for demo purposes. Let's try it:
Under the covers, the containers/image library calls into the containers/storage library to read the image's contents from where buildah keeps them, and sends them to the local Docker daemon, which writes them to where it keeps them. This can take a little while. And usually you won't need to do this. If you're using `buildah` you are probably not using Docker. This is just for demo purposes. Let's try it:
# docker run fedora-bashecho
# docker run --rm fedora-bashecho
This is a new container from ipbabble [ 0 ]
This is a new container from ipbabble [ 1 ]
This is a new container from ipbabble [ 2 ]
@@ -236,17 +236,17 @@ OCI container images built with `buildah` are completely standard as expected. S
## Using Containerfiles/Dockerfiles with Buildah
What if you have been using Docker for a while and have some existing Dockerfiles. Not a problem. Buildah can build images using a Dockerfile. The `build` command takes a Dockerfile as input and produces an OCI image.
What if you have been using Docker for a while and have some existing Dockerfiles? Not a problem. Buildah can build images using a Dockerfile. The `build` command takes a Dockerfile as input and produces an OCI image.
Find one of your Dockerfiles or create a file called Dockerfile. Use the following example or some variation if you'd like:
# Base on the Fedora
# Base on the most recently released Fedora
FROM fedora:latest
MAINTAINER ipbabble email buildahboy@redhat.com # not a real email
MAINTAINER ipbabble email buildahboy@redhat.com # not a real email
# Update image and install httpd
# Install updates and httpd
RUN echo "Updating all fedora packages"; dnf -y update; dnf -y clean all
RUN echo "Installing httpd"; dnf -y install httpd
RUN echo "Installing httpd"; dnf -y install httpd && dnf -y clean all
# Expose the default httpd port 80
EXPOSE 80
@@ -258,18 +258,17 @@ Now run `buildah build` with the name of the Dockerfile and the name to be given
# buildah build -f Dockerfile -t fedora-httpd .
or, because `buildah build` defaults to Dockerfile (note the period at the end of the example):
or, because `buildah build` defaults to `Dockerfile` and using the current directory as the build context:
# buildah build -t fedora-httpd .
# buildah build -t fedora-httpd
You will see all the steps of the Dockerfile executing. Afterwards `buildah images` will show you the new image. Now we need to create the container using `buildah from` and test it with `buildah run`:
You will see all the steps of the Dockerfile executing. Afterwards `buildah images` will show you the new image. Now we can create a container from the image and test it with `podman run`:
# httpcontainer=$(buildah from fedora-httpd)
# buildah run $httpcontainer /usr/sbin/httpd -DFOREGROUND
# podman run --rm -p 8123:80 fedora-httpd
While that container is running, in another shell run:
# curl localhost
# curl localhost:8123
You will see the standard Apache webpage.

28
docs/tutorials/02-registries-repositories.md
View File

@@ -5,29 +5,29 @@
The purpose of this tutorial is to demonstrate how Buildah can be used to move OCI compliant images in and out of private or public registries.
In the [first tutorial](https://github.com/containers/buildah/blob/main/docs/tutorials/01-intro.md) we built an image from scratch that we called `fedora-bashecho` and we pushed it to a local Docker repository using the `docker-daemon` protocol. We are going to use the same image to push to a private Docker registry.
In the [first tutorial](https://github.com/containers/buildah/blob/main/docs/tutorials/01-intro.md) we built an image from scratch that we called `fedora-bashecho` and we pushed it to a local Docker daemon using the `docker-daemon` protocol. We are going to push the same image to a private container registry.
First we must pull down a registry. As a shortcut we will save the container name that is returned from the `buildah from` command, into a bash variable called `registry`. This is just like we did in Tutorial 1:
# registry=$(buildah from registry)
# registryctr=$(buildah from registry)
It is worth pointing out that the `from` command can also use other protocols beyond the default (and implicitly assumed) order that first looks in local containers-storage (containers-storage:) and then looks in the Docker hub (docker:). For example, if you already had a registry container image in a local Docker registry then you could use the following:
It is worth pointing out that the `from` command can also use other protocols beyond the default (and implicitly assumed) order that first looks in local containers-storage (containers-storage:) and then looks in a container registry (by default, Docker Hub) (docker:). For example, if you already had a registry container image downloaded by a local Docker daemon then you could use the following:
# registry=$(buildah from docker-daemon:registry:latest)
# registryctr=$(buildah from docker-daemon:registry:latest)
Then we need to start the registry. You should start the registry in a separate shell and leave it running there:
# buildah run $registry
# buildah run --net=host $registryctr /entrypoint.sh /etc/docker/registry/config.yml
If you would like to see more details as to what is going on inside the registry, especially if you are having problems with the registry, you can run the registry container in debug mode as follows:
# buildah --log-level=debug run $registry
# buildah --log-level=debug run --net=host $registryctr /entrypoint.sh /etc/docker/registry/config.yml
You can use `--log-level=debug` on any Buildah command.
The registry is running and is waiting for requests to process. Notice that this registry is a Docker registry that we pulled from Docker hub and we are running it for this example using `buildah run`. There is no Docker daemon running at this time.
The registry is running and is waiting for requests to process. Notice that this registry is a Docker registry that we pulled from Docker Hub and we are running it for this example using `buildah run`. There is no Docker daemon running at this time.
Let's push our image to the private registry. By default, Buildah is set up to expect secure connections to a registry. Therefore we will need to turn the TLS verification off using the `--tls-verify` flag. We also need to tell Buildah that the registry is on this local host ( i.e. localhost) and listening on port 5000. Similar to what you'd expect to do on multi-tenant Docker hub, we will explicitly specify that the registry is to store the image under the `ipbabble` repository - so as not to clash with other users' similarly named images.
Let's push our image to the private registry. By default, Buildah is set up to only make secure connections to a registry. Therefore we will need to turn the TLS verification off using the `--tls-verify` flag. We also need to tell Buildah that the registry is on this local host ( i.e. localhost) and listening on port 5000. Similar to what you'd expect to do on multi-tenant Docker Hub, we will explicitly specify that the registry is to store the image under the `ipbabble` repository - so as not to clash with other users' similarly named images.
# buildah push --tls-verify=false fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latest
@@ -52,7 +52,7 @@ Let's push our image to the private registry. By default, Buildah is set up to e
]
}
We can verify that it is still portable with Docker by starting Docker again, as we did in the first tutorial. Then we can pull down the image and starting the container using Docker:
We can verify that it is still portable to Docker by starting Docker again, as we did in the first tutorial. Then we can pull down the image and start the container using Docker:
# systemctl start docker
# docker pull localhost:5000/ipbabble/fedora-bashecho
@@ -63,7 +63,7 @@ We can verify that it is still portable with Docker by starting Docker again, as
Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137
Status: Downloaded newer image for localhost:5000/ipbabble/fedora-bashecho:latest
# docker run localhost:5000/ipbabble/fedora-bashecho
# docker run --rm localhost:5000/ipbabble/fedora-bashecho
This is a new container named ipbabble [ 0 ]
This is a new container named ipbabble [ 1 ]
This is a new container named ipbabble [ 2 ]
@@ -76,7 +76,7 @@ We can verify that it is still portable with Docker by starting Docker again, as
This is a new container named ipbabble [ 9 ]
# systemctl stop docker
Pushing to Docker hub is just as easy. Of course you must have an account with credentials. In this example I'm using a Docker hub API key, which has the form "username:password" (example password has been edited for privacy), that I created with my Docker hub account. I use the `--creds` flag to use my API key. I also specify my local image name `fedora-bashecho` as my image source and I use the `docker` protocol with no host or port so that it will look at the default Docker hub registry:
Pushing to Docker Hub is just as easy. Of course you must have an account with credentials. In this example I'm using a Docker Hub API key, which has the form "username:password" (example password has been edited for privacy), that I created with my Docker Hub account. I use the `--creds` flag to use my API key. I also specify my local image name `fedora-bashecho` as my image source and I use the `docker` protocol with no registry name or port so that it will look at the default port on the default Docker Hub registry:
# buildah push --creds=ipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c fedora-bashecho docker://ipbabble/fedora-bashecho:latest
@@ -101,7 +101,7 @@ And let's inspect that with Skopeo:
]
}
We can use Buildah to pull down the image using the `buildah from` command. But before we do let's clean up our local containers-storage so that we don't have an existing fedora-bashecho - otherwise Buildah will know it already exists and not bother pulling it down.
We can use Buildah to pull down the image using the `buildah from` command. But before we do let's clean up our local containers-storage so that we don't already have a copy of the fedora-bashecho image - otherwise Buildah will know it already exists and not bother pulling it down.
# buildah images
IMAGE ID IMAGE NAME CREATED AT SIZE
@@ -114,7 +114,7 @@ We can use Buildah to pull down the image using the `buildah from` command. But
IMAGE ID IMAGE NAME CREATED AT SIZE
d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB
Okay, so we don't have a fedora-bashecho anymore. Let's pull the image from Docker hub:
Okay, so we don't have a fedora-bashecho image anymore. Let's pull the image from Docker Hub:
# buildah from ipbabble/fedora-bashecho
@@ -129,6 +129,6 @@ Now check that image is in the local containers-storage:
Success!
If you have any suggestions or issues please post them at the [Containers Buildah Issues page](https://github.com/containers/buildah/issues).
If you have any suggestions or issues please post them at the [Buildah Issues page](https://github.com/containers/buildah/issues).
For more information on Buildah and how you might contribute please visit the [Buildah home page on Github](https://github.com/containers/buildah).

40
docs/tutorials/03-on-build.md
View File

@@ -3,17 +3,17 @@
# Buildah Tutorial 3
## Using ONBUILD in Buildah
The purpose of this tutorial is to demonstrate how Buildah can use a Dockerfile with the ONBUILD instruction within it or how the ONBUILD instruction can be used with the `buildah config` command. The ONBUILD instruction stores a command in the meta data of a container image which is then invoked when a secondary container image is created. The image can have multiple ONBUILD instructions. Note: The ONBUILD instructions do not change the content of the image that contain the instructions, only the container images that are created from this image are changed based on the FROM command.
The purpose of this tutorial is to demonstrate how Buildah can use a Dockerfile with the ONBUILD instruction within it or how the ONBUILD instruction can be used with the `buildah config` command. The ONBUILD instruction stores a command in the meta data of a container image which is then invoked when the image is used as a base image. The image can have multiple ONBUILD instructions. Note: The ONBUILD instructions do not change the content of the image that contain the instructions, only the container images that are created from this image are changed based on the FROM command.
Container images that are compliant with the [Open Container Initiative][] (OCI) [image specification][] do not support the ONBUILD instruction. Images that are created by Buildah are OCI compliant by default. Therefore only containers that are created by Buildah that use the Docker format can use the ONBUILD instruction. The OCI format can be overridden in Buildah by specifying the Docker format with the `--format=docker` option or by setting the BUILDAH_FORMAT environment variable to 'docker'. Regardless of the format selected, Buildah is capable of working seamlessly with either OCI or Docker compliant images and containers.
Container images that are compliant with the [Open Container Initiative][] (OCI) [image specification][] do not support the ONBUILD instruction. Images that are created by Buildah are in the OCI format by default. Only container images that are created by Buildah in the Docker format can use the ONBUILD instruction. The OCI format can be overridden in Buildah by specifying the Docker format with the `--format=docker` option or by setting the BUILDAH_FORMAT environment variable to 'docker'. Regardless of the format selected, Buildah is capable of working seamlessly with either OCI or Docker compliant images and containers.
On to the tutorial. The first step is to install Buildah. In short, the `buildah run` command emulates the RUN command that is found in a Dockerfile while the `podman run` command emulates the `docker run` command. For the purpose of this tutorial Buildah's run command will be used. As an aside, Podman is aimed at managing containers, images, and pods while Buildah focuses on the building of containers. For more info on Podman, please go to [GitHub][].
On to the tutorial. The first step is to install Buildah. In short, the `buildah run` command emulates the RUN command that is found in a Dockerfile while the `podman run` command emulates the `docker run` command. For the purpose of this tutorial Buildah's run command will be used. As an aside, Podman is aimed at managing containers, images, and pods while Buildah focuses on the building of container images. For more info on Podman, please go to [Podman's site][].
## Setup
The following assumes installation on Fedora.
Run as root because you will need to be root for running Buildah commands (at the time of this writing work is underway to allow non-root access):
Run as root because you will need to be root for installing the Buildah package:
$ sudo -s
@@ -33,11 +33,11 @@ We can also see that there are also no containers by running:
The two examples that will be shown are relatively simple, but they illustrate how a command or a number of commands can be setup in a master image such that they will be added to a secondary container image that is created from it. This is extremely useful if you need to setup an environment where your containers have 75% of the same content, but need a few individual tweaks. This can be helpful in setting up a environment for maven or java development containers for instance. In this way you can create a single Dockerfile with all the common setup steps as ONBUILD commands and then really minimize the buildah commands or instructions in a second Dockerfile that would be necessary to complete the creation of the container image.
NOTE: In the examples below the option `--format=docker` is used in several places. If you wanted to omit that, you could define the `BUILDAH_FORMAT` and set it to 'docker'. On Fedora that command would be `export BUILDAH_FORMAT docker`.
NOTE: In the examples below the option `--format=docker` is used in several places. If you wanted to omit that, you could define the `BUILDAH_FORMAT` environment variable and set it to 'docker'. On Fedora that command would be `export BUILDAH_FORMAT=docker`.
## ONBUILD in a Dockerfile - Example 1
The first example was provided by Chris Collins (GitHub @clcollins), the idea is a file `/bar` will be created in the secondary container image only, and not in the primary image.
The first example was provided by Chris Collins (GitHub @clcollins), the idea is a file `/bar` will be created in the derived container images only, and not in our original image.
First create two Dockerfiles:
@@ -54,7 +54,7 @@ RUN touch /baz
EOF
```
Now to create the first container and verify that ONBUILD has been set:
Now to create the first container image and verify that ONBUILD has been set:
```
# buildah build --format=docker -f Dockerfile -t onbuild-image .
@@ -62,14 +62,14 @@ Now to create the first container and verify that ONBUILD has been set:
[RUN touch /bar]
```
The second container is now created and the `/bar` file will be created within it:
The second container image is now created and the `/bar` file will be created within it:
```
# buildah build --format=docker -f Dockerfile-2 -t result-image .
STEP 1: FROM onbuild-image
STEP 2: RUN touch /bar # Note /bar created here based on the ONBUILD in Dockerfile
STEP 2: RUN touch /bar # Note /bar is created here based on the ONBUILD in the base image
STEP 3: RUN touch /baz
STEP 4: COMMIT containers-storage:[overlay@/var/lib/containers/storage+/run/containers/storage:overlay.override_kernel_check=true]localhost/result-image:latest
COMMIT result-image
{output edited for brevity}
$ container=$(sudo buildah from result-image:latest)
# buildah run $container ls /bar /foo /baz
@@ -80,7 +80,7 @@ $ container=$(sudo buildah from result-image:latest)
Instead of using a Dockerfile to create the onbuild-image, Buildah allows you to build an image and configure it directly with the same commands that can be found in a Dockerfile. This allows for easy on the fly manipulation of your image. Let's look at the previous example without the use of a Dockerfile when building the primary container image.
First a Fedora container will be created with `buildah from`, then the `/foo` file will be added with `buildah run`. The `buildah config` command will configure ONBUILD to add `/bar` when a container image is created from the primary image, and finally the image will be saved with `buildah commit`.
First a Fedora container will be created with `buildah from`, then the `/foo` file will be added with `buildah run`. The `buildah config` command will configure ONBUILD to add `/bar` when a container image is created from the primary image, and finally the image will be saved with `buildah commit`.
```
# buildah from --format=docker --name onbuild-container fedora:latest
@@ -96,11 +96,11 @@ The onbuild-image has been created, so now create a container from it using the
```
# buildah build --format=docker -f Dockerfile-2 -t result-image .
STEP 1: FROM onbuild-image
STEP 2: RUN touch /bar # Note /bar created here based on the ONBUILD in Dockerfile
STEP 2: RUN touch /bar # Note /bar is created here based on the ONBUILD in the base image
STEP 3: RUN touch /baz
STEP 4: COMMIT containers-storage:[overlay@/var/lib/containers/storage+/run/containers/storage:overlay.override_kernel_check=true]localhost/result-image:latest
COMMIT result-image
{output edited for brevity}
$ container=$(sudo buildah from result-image:latest)
$ container=$(buildah from result-image)
# buildah run $container ls /bar /foo /baz
/bar /baz /foo
```
@@ -116,7 +116,7 @@ result-container
## ONBUILD via `buildah config` - Example 2
For this example the ONBUILD instructions in the primary container image will be used to copy a shell script and then run it in the secondary container image. For the script, we'll make use of the shell script from the [Introduction Tutorial][]. First create a file in the local directory called `runecho.sh` containing the following:
For this example the ONBUILD instructions in the primary container image will be used to copy a shell script and then run it in the secondary container image. For the script, we'll make use of the shell script from the [Introduction Tutorial](01-intro.md). First create a file in the local directory called `runecho.sh` containing the following:
```
#!/usr/bin/env bash
@@ -142,10 +142,10 @@ onbuild-container-2
# buildah commit --format=docker onbuild-container-2 onbuild-image-2
{output edited for brevity}
# buildah inspect --format '{{.Docker.Config.OnBuild}}' onbuild-image-2
[COPY ./runecho.sh /usr/bin/runecho.sh RUN /usr/bin/runecho.sh &> /tmp/runecho.txt]
[COPY ./runecho.sh /usr/bin/runecho.sh RUN /usr/bin/runecho.sh]
```
Now the result container can be created from the primary container image onbuild-image-2. The runecho.sh script will be copied to the containers /usr/bin directory and then run from there when the secondary container image is created.
Now the secondary container can be created from the second primary container image onbuild-image-2. The runecho.sh script will be copied to the container's /usr/bin directory and then run from there when the secondary container is created.
```
# buildah from --format=docker --name result-container-2 onbuild-image-2
@@ -162,7 +162,7 @@ This is a new container pull ipbabble [ 8 ]
This is a new container pull ipbabble [ 9 ]
result-container-2
```
As result-container has the script stored in /usr/bin still and it can be run at anytime.
As result-container-2 has a copy of the script stored in its /usr/bin it can be run at anytime.
```
# buildah run result-container-2 /usr/bin/runecho.sh
@@ -187,7 +187,7 @@ If you have any suggestions or issues please post them at the [Buildah Issues pa
For more information on Buildah and how you might contribute please visit the [Buildah home page on GitHub](https://github.com/containers/buildah).
[GitHub]: https://github.com/containers/podman/
[Podman's site]: https://podman.io/
[image specification]: https://github.com/opencontainers/runtime-spec
[Introduction Tutorial]: 01-intro.md
[Open Container Initiative]: https://www.opencontainers.org/

33
docs/tutorials/04-include-in-your-build-tool.md
View File

@@ -55,11 +55,7 @@ Define the builder options:
```go
builderOpts := buildah.BuilderOptions{
FromImage: "node:12-alpine", // Starting image
Isolation: define.IsolationChroot, // Isolation environment
CommonBuildOpts: &define.CommonBuildOptions{},
ConfigureNetwork: define.NetworkDefault,
SystemContext: &types.SystemContext {},
FromImage: "node:12-alpine", // base image
}
```
@@ -90,7 +86,7 @@ imageRef, err := is.Transport.ParseStoreReference(buildStore, "docker.io/myusern
Now you can run commit the build:
```go
imageId, _, _, err := builder.Commit(context.TODO(), imageRef, define.CommitOptions{})
imageId, _, _, err := builder.Commit(context.TODO(), imageRef, buildah.CommitOptions{})
```
## Rootless mode
@@ -104,7 +100,7 @@ if buildah.InitReexec() {
unshare.MaybeReexecUsingUserNamespace(false)
```
This code ensures that your application is re executed in an isolated environment with root privileges.
This code ensures that your application is re-executed in a user namespace where it has root privileges.
## Complete code
@@ -114,12 +110,11 @@ package main
import (
"context"
"fmt"
"github.com/containers/buildah"
"github.com/containers/buildah/define"
"github.com/containers/storage/pkg/unshare"
is "github.com/containers/image/v5/storage"
"github.com/containers/image/v5/types"
"github.com/containers/storage"
"github.com/containers/storage/pkg/unshare"
)
func main() {
@@ -129,33 +124,27 @@ func main() {
unshare.MaybeReexecUsingUserNamespace(false)
buildStoreOptions, err := storage.DefaultStoreOptions(unshare.IsRootless(), unshare.GetRootlessUID())
if err != nil {
panic(err)
}
buildStore, err := storage.GetStore(buildStoreOptions)
if err != nil {
panic(err)
}
defer buildStore.Shutdown(false)
opts := buildah.BuilderOptions{
builderOpts := buildah.BuilderOptions{
FromImage: "node:12-alpine",
Isolation: define.IsolationChroot,
CommonBuildOpts: &define.CommonBuildOptions{},
ConfigureNetwork: define.NetworkDefault,
SystemContext: &types.SystemContext {},
}
builder, err := buildah.NewBuilder(context.TODO(), buildStore, opts)
builder, err := buildah.NewBuilder(context.TODO(), buildStore, builderOpts)
if err != nil {
panic(err)
}
defer builder.Delete()
err = builder.Add("/home/node/", false, buildah.AddAndCopyOptions{}, "script.js")
if err != nil {
panic(err)
}
@@ -163,12 +152,14 @@ func main() {
builder.SetCmd([]string{"node", "/home/node/script.js"})
imageRef, err := is.Transport.ParseStoreReference(buildStore, "docker.io/myusername/my-image")
if err != nil {
panic(err)
}
imageId, _, _, err := builder.Commit(context.TODO(), imageRef, buildah.CommitOptions{})
if err != nil {
panic(err)
}
fmt.Printf("Image built! %s\n", imageId)
}

412
docs/tutorials/05-openshift-rootless-build.md
View File

@@ -5,9 +5,9 @@
This tutorial will walk you through setting up a container in OpenShift for building images.
The instructions have been tested on OpenShift 4.3.28 with Buildah 1.14.8.
The instructions have been tested on OpenShift 4.9.5 with Buildah 1.23.1.
Note that the VFS volume mounting is used instead of the more performant fuse. But the the latter does not work at the moment.
Note that the VFS is used for storage instead of the more performant fuse-overlayfs or overlayfs. But the the latter do not work at the moment.
### Prepare a new namespace
@@ -33,18 +33,17 @@ You have access to N projects, the list has been suppressed. You can list all pr
Using project "image-build".
$ oc whoami -t | podman login -u $(id -u -n) --password-stdin $REGISTRY_URL
$ oc whoami -t | buildah login -u $(id -u -n) --password-stdin $REGISTRY_URL
Login Succeeded!
````
### Make builder image
This is the image that will host the building. It uses the Buildah stable official image, which is based on Fedora 32.
This is the image that will host the building. It uses the Buildah stable official image, which is based on Fedora 35.
The image starts a python web server. This allows us to interact with the container via the OpenShift console terminal, demonstrating that building an image works.
First create an ImageStream to hold the image:
````console
@@ -65,7 +64,7 @@ If you are making anything for use in the real world, make sure to update it fre
````console
$ cat > Containerfile-buildah <<EOF
FROM quay.io/buildah/stable:v1.14.8
FROM quay.io/buildah/stable:v1.23.1
RUN touch /etc/subgid /etc/subuid \
&& chmod g=u /etc/subgid /etc/subuid /etc/passwd \
@@ -77,7 +76,7 @@ RUN echo "export BUILDAH_ISOLATION=chroot" >> /home/build/.bashrc
# Use VFS since fuse does not work
RUN mkdir -p /home/build/.config/containers \
&& echo "driver=\"vfs\"" > /home/build/.config/containers/storage.conf
&& (echo '[storage]';echo 'driver = "vfs"') > /home/build/.config/containers/storage.conf
USER build
WORKDIR /home/build
@@ -86,8 +85,8 @@ WORKDIR /home/build
CMD ["python3", "-m", "http.server"]
EOF
$ podman build -t $REGISTRY_URL/image-build/buildah -f Containerfile-buildah
STEP 1: FROM quay.io/buildah/stable:v1.14.8
$ buildah build -t $REGISTRY_URL/image-build/buildah -f Containerfile-buildah
STEP 1: FROM quay.io/buildah/stable:v1.23.1
STEP 2: RUN touch /etc/subgid /etc/subuid && chmod g=u /etc/subgid /etc/subuid /etc/passwd && echo build:10000:65536 > /etc/subuid && echo build:10000:65536 > /etc/subgid
--> a25dbbd3824
STEP 3: CMD ["python3", "-m", "http.server"]
@@ -95,7 +94,7 @@ STEP 4: COMMIT default-route-openshift-image-registry.../image-build/buildah
--> 9656f2677e3
9656f2677e3e760e071c93ca7cba116871f5549b28ad8595e9134679db2345fc
$ podman push $REGISTRY_URL/image-build/buildah
$ buildah push $REGISTRY_URL/image-build/buildah
Getting image source signatures
...
Storing signatures
@@ -189,10 +188,11 @@ sh-5.0$ uname -a
Linux buildah-1-8t74l 4.18.0-147.13.2.el8_1.x86_64 #1 SMP Wed May 13 15:19:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sh-5.0$ capsh --print
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot+i
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service=i
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service
Ambient set =
Securebits: 00/0x0/1'b0
Current IAB: cap_chown,cap_dac_override,!cap_dac_read_search,cap_fowner,cap_fsetid,!cap_kill,cap_setgid,cap_setuid,cap_setpcap,!cap_linux_immutable,cap_net_bind_service,!cap_net_broadcast,!cap_net_admin,!cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_chroot,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_write,!cap_audit_control,!cap_setfcap,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf
Securebits: 00/0x0/1'b0 (no-new-privs=0)
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
@@ -200,22 +200,24 @@ Securebits: 00/0x0/1'b0
uid=1000(build)
gid=1000(build)
groups=
Guessed mode: UNCERTAIN (0)
````
This is what the Buildah data should look like:
````console
sh-5.0$ buildah version
Version: 1.14.8
Go Version: go1.14
Version: 1.23.1
Go Version: go1.16.8
Image Spec: 1.0.1-dev
Runtime Spec: 1.0.1-dev
Runtime Spec: 1.0.2-dev
CNI Spec: 0.4.0
libcni Version:
image Version: 5.4.3
libcni Version: v0.8.1
image Version: 5.16.0
Git Commit:
Built: Thu Jan 1 00:00:00 1970
Built: Tue Sep 28 18:26:37 2021
OS/Arch: linux/amd64
BuildPlatform: linux/amd64
sh-5.0$ buildah info
{
@@ -223,17 +225,17 @@ sh-5.0$ buildah info
"CgroupVersion": "v1",
"Distribution": {
"distribution": "fedora",
"version": "32"
"version": "35"
},
"MemTotal": 33726861312,
"MenFree": 20319305728,
"OCIRuntime": "runc",
"OCIRuntime": "crun",
"SwapFree": 0,
"SwapTotal": 0,
"arch": "amd64",
"cpus": 4,
"hostname": "buildah-1-6hvsw",
"kernel": "4.18.0-147.13.2.el8_1.x86_64",
"kernel": "4.18.0-305.19.1.el8_4.x86_64",
"os": "linux",
"rootless": true,
"uptime": "61h 10m 39.3s (Approximately 2.54 days)"
@@ -249,7 +251,7 @@ sh-5.0$ buildah info
"ImageStore": {
"number": 0
},
"RunRoot": "/var/tmp/1000/containers"
"RunRoot": "/var/tmp/containers-user-1000/containers"
}
}
@@ -271,7 +273,7 @@ EOF
sh-5.0$ chmod +x test-script.sh
sh-5.0$ cat > Containerfile.test <<EOF
FROM fedora:33
FROM fedora:35
RUN ls -l /test-script.sh
RUN /test-script.sh "Hello world"
RUN dnf update -y | tee /output/update-output.txt
@@ -285,134 +287,292 @@ And finally build the image, testing that everything works as expected:
````console
sh-5.0$ buildah -v /home/build/output:/output:rw -v /home/build/test-script.sh:/test-script.sh:ro build-using-dockerfile -t myimage -f Containerfile.test
STEP 1: FROM fedora:33
FROM fedora:35
RUN ls -l /test-script.sh
RUN /test-script.sh "Hello world"
RUN dnf update -y | tee /output/update-output.txt
RUN dnf install -y gcc
EOF
sh-5.1$ mkdir output
sh-5.1$ buildah -v /home/build/output:/output:rw -v /home/build/test-script.sh:/test-script.sh:ro build-using-dockerfile -t myimage -f Containerfile.test
STEP 1/5: FROM fedora:35
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:35...
Getting image source signatures
Copying blob 453ed60def9c done
Copying config 71d10e102a done
Copying blob 791199e77b3d done
Copying config 1b52edb081 done
Writing manifest to image destination
Storing signatures
STEP 2: RUN ls -l /test-script.sh
-rwxr-xr-x. 1 root root 34 Jul 8 07:47 /test-script.sh
STEP 3: RUN /test-script.sh "Hello world"
STEP 2/5: RUN ls -l /test-script.sh
-rwxr-xr-x. 1 root root 34 Nov 12 21:20 /test-script.sh
STEP 3/5: RUN /test-script.sh "Hello world"
Args Hello world
total 8
lrwxrwxrwx. 1 root root 7 Jan 28 18:30 bin -> usr/bin
dr-xr-xr-x. 2 root root 6 Jan 28 18:30 boot
drwxr-xr-x. 5 nobody nobody 360 Jul 8 07:39 dev
drwxr-xr-x. 42 root root 4096 Jul 7 09:07 etc
drwxr-xr-x. 2 root root 6 Jan 28 18:30 home
lrwxrwxrwx. 1 root root 7 Jan 28 18:30 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 28 18:30 lib64 -> usr/lib64
drwx------. 2 root root 6 Jul 7 09:06 lost+found
drwxr-xr-x. 2 root root 6 Jan 28 18:30 media
drwxr-xr-x. 2 root root 6 Jan 28 18:30 mnt
drwxr-xr-x. 2 root root 6 Jan 28 18:30 opt
drwxr-xr-x. 2 root root 6 Jul 8 07:46 output
dr-xr-xr-x. 311 nobody nobody 0 Jul 8 07:39 proc
dr-xr-x---. 2 root root 196 Jul 7 09:07 root
drwxr-xr-x. 3 root root 42 Jul 8 07:47 run
lrwxrwxrwx. 1 root root 8 Jan 28 18:30 sbin -> usr/sbin
drwxr-xr-x. 2 root root 6 Jan 28 18:30 srv
dr-xr-xr-x. 13 nobody nobody 0 Jul 5 17:57 sys
-rwxr-xr-x. 1 root root 34 Jul 8 07:47 test-script.sh
drwxrwxrwt. 2 root root 32 Jul 7 09:07 tmp
drwxr-xr-x. 12 root root 144 Jul 7 09:07 usr
drwxr-xr-x. 18 root root 235 Jul 7 09:07 var
STEP 4: RUN dnf update -y | tee /output/update-output.txt
Fedora 33 openh264 (From Cisco) - x86_64 817 B/s | 5.1 kB 00:06
Fedora - Modular Rawhide - Developmental packag 3.0 MB/s | 3.1 MB 00:01
Fedora - Rawhide - Developmental packages for t 19 MB/s | 72 MB 00:03
lrwxrwxrwx. 1 root root 7 Jul 21 23:47 bin -> usr/bin
dr-xr-xr-x. 2 root root 6 Jul 21 23:47 boot
drwxr-xr-x. 5 nobody nobody 360 Nov 12 21:17 dev
drwxr-xr-x. 42 root root 4096 Nov 3 16:38 etc
drwxr-xr-x. 2 root root 6 Jul 21 23:47 home
lrwxrwxrwx. 1 root root 7 Jul 21 23:47 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jul 21 23:47 lib64 -> usr/lib64
drwx------. 2 root root 6 Nov 3 16:37 lost+found
drwxr-xr-x. 2 root root 6 Jul 21 23:47 media
drwxr-xr-x. 2 root root 6 Jul 21 23:47 mnt
drwxr-xr-x. 2 root root 6 Jul 21 23:47 opt
drwxr-xr-x. 2 root root 6 Nov 12 21:21 output
dr-xr-xr-x. 352 nobody nobody 0 Nov 12 21:17 proc
dr-xr-x---. 2 root root 196 Nov 3 16:38 root
drwxr-xr-x. 3 root root 42 Nov 12 21:21 run
lrwxrwxrwx. 1 root root 8 Jul 21 23:47 sbin -> usr/sbin
drwxr-xr-x. 2 root root 6 Jul 21 23:47 srv
dr-xr-xr-x. 13 nobody nobody 0 Nov 12 20:27 sys
-rwxr-xr-x. 1 root root 34 Nov 12 21:20 test-script.sh
drwxrwxrwt. 2 root root 6 Nov 3 16:37 tmp
drwxr-xr-x. 12 root root 144 Nov 3 16:38 usr
drwxr-xr-x. 18 root root 235 Nov 3 16:38 var
STEP 4/5: RUN dnf update -y | tee /output/update-output.txt
Fedora 35 - x86_64 7.1 MB/s | 61 MB 00:08
Fedora 35 openh264 (From Cisco) - x86_64 4.1 kB/s | 2.5 kB 00:00
Fedora Modular 35 - x86_64 3.1 MB/s | 2.6 MB 00:00
Fedora 35 - x86_64 - Updates 5.6 MB/s | 10 MB 00:01
Fedora Modular 35 - x86_64 - Updates 763 kB/s | 712 kB 00:00
Last metadata expiration check: 0:00:01 ago on Fri Nov 12 21:22:21 2021.
Dependencies resolved.
Nothing to do.
Complete!
STEP 5: RUN dnf install -y gcc
Last metadata expiration check: 0:00:30 ago on Wed Jul 8 07:48:12 2020.
Dependencies resolved.
==================================================================================================================================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================================================================================================================================
Installing:
gcc x86_64 10.1.1-2.fc33 rawhide 30 M
Installing dependencies:
binutils x86_64 2.34.0-7.fc33 rawhide 5.4 M
binutils-gold x86_64 2.34.0-7.fc33 rawhide 857 k
cpp x86_64 10.1.1-2.fc33 rawhide 9.3 M
glibc-devel x86_64 2.31.9000-17.fc33 rawhide 1.0 M
glibc-headers-x86 noarch 2.31.9000-17.fc33 rawhide 472 k
isl x86_64 0.16.1-10.fc32 rawhide 872 k
kernel-headers x86_64 5.8.0-0.rc4.git0.1.fc33 rawhide 1.2 M
libmpc x86_64 1.1.0-8.fc32 rawhide 59 k
libxcrypt-devel x86_64 4.4.16-5.fc33 rawhide 31 k
================================================================================
Package Arch Version Repository Size
================================================================================
Upgrading:
glib2 x86_64 2.70.1-1.fc35 updates 2.6 M
glibc x86_64 2.34-8.fc35 updates 2.0 M
glibc-common x86_64 2.34-8.fc35 updates 406 k
glibc-minimal-langpack x86_64 2.34-8.fc35 updates 134 k
gpgme x86_64 1.15.1-6.fc35 updates 206 k
libgpg-error x86_64 1.43-1.fc35 updates 216 k
python3-gpg x86_64 1.15.1-6.fc35 updates 261 k
shadow-utils x86_64 2:4.9-5.fc35 updates 1.1 M
vim-minimal x86_64 2:8.2.3582-1.fc35 updates 706 k
Installing weak dependencies:
glibc-gconv-extra x86_64 2.34-8.fc35 updates 1.6 M
Transaction Summary
==================================================================================================================================================================================================================================================
Install 10 Packages
================================================================================
Install 1 Package
Upgrade 9 Packages
Total download size: 49 M
Installed size: 147 M
Total download size: 9.3 M
Downloading Packages:
(1/10): binutils-gold-2.34.0-7.fc33.x86_64.rpm 3.3 MB/s | 857 kB 00:00
(2/10): binutils-2.34.0-7.fc33.x86_64.rpm 16 MB/s | 5.4 MB 00:00
(3/10): cpp-10.1.1-2.fc33.x86_64.rpm 9.3 MB/s | 9.3 MB 00:01
(4/10): gcc-10.1.1-2.fc33.x86_64.rpm 33 MB/s | 30 MB 00:00
(5/10): glibc-devel-2.31.9000-17.fc33.x86_64.rpm 1.2 MB/s | 1.0 MB 00:00
(6/10): glibc-headers-x86-2.31.9000-17.fc33.noarch.rpm 2.6 MB/s | 472 kB 00:00
(7/10): isl-0.16.1-10.fc32.x86_64.rpm 12 MB/s | 872 kB 00:00
(8/10): kernel-headers-5.8.0-0.rc4.git0.1.fc33.x86_64.rpm 11 MB/s | 1.2 MB 00:00
(9/10): libmpc-1.1.0-8.fc32.x86_64.rpm 534 kB/s | 59 kB 00:00
(10/10): libxcrypt-devel-4.4.16-5.fc33.x86_64.rpm 589 kB/s | 31 kB 00:00
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 35 MB/s | 49 MB 00:01
(1/10): glibc-2.34-8.fc35.x86_64.rpm 5.2 MB/s | 2.0 MB 00:00
(2/10): glibc-gconv-extra-2.34-8.fc35.x86_64.rp 3.9 MB/s | 1.6 MB 00:00
(3/10): glib2-2.70.1-1.fc35.x86_64.rpm 5.7 MB/s | 2.6 MB 00:00
(4/10): glibc-minimal-langpack-2.34-8.fc35.x86_ 2.1 MB/s | 134 kB 00:00
(5/10): glibc-common-2.34-8.fc35.x86_64.rpm 3.9 MB/s | 406 kB 00:00
(6/10): gpgme-1.15.1-6.fc35.x86_64.rpm 4.6 MB/s | 206 kB 00:00
(7/10): libgpg-error-1.43-1.fc35.x86_64.rpm 5.4 MB/s | 216 kB 00:00
(8/10): python3-gpg-1.15.1-6.fc35.x86_64.rpm 5.6 MB/s | 261 kB 00:00
(9/10): shadow-utils-4.9-5.fc35.x86_64.rpm 14 MB/s | 1.1 MB 00:00
(10/10): vim-minimal-8.2.3582-1.fc35.x86_64.rpm 8.2 MB/s | 706 kB 00:00
--------------------------------------------------------------------------------
Total 9.4 MB/s | 9.3 MB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : binutils-gold-2.34.0-7.fc33.x86_64 1/10
Installing : binutils-2.34.0-7.fc33.x86_64 2/10
Running scriptlet: binutils-2.34.0-7.fc33.x86_64 2/10
Installing : libmpc-1.1.0-8.fc32.x86_64 3/10
Installing : cpp-10.1.1-2.fc33.x86_64 4/10
Installing : kernel-headers-5.8.0-0.rc4.git0.1.fc33.x86_64 5/10
Installing : isl-0.16.1-10.fc32.x86_64 6/10
Installing : glibc-headers-x86-2.31.9000-17.fc33.noarch 7/10
Installing : libxcrypt-devel-4.4.16-5.fc33.x86_64 8/10
Installing : glibc-devel-2.31.9000-17.fc33.x86_64 9/10
Installing : gcc-10.1.1-2.fc33.x86_64 10/10
Running scriptlet: gcc-10.1.1-2.fc33.x86_64 10/10
Verifying : binutils-2.34.0-7.fc33.x86_64 1/10
Verifying : binutils-gold-2.34.0-7.fc33.x86_64 2/10
Verifying : cpp-10.1.1-2.fc33.x86_64 3/10
Verifying : gcc-10.1.1-2.fc33.x86_64 4/10
Verifying : glibc-devel-2.31.9000-17.fc33.x86_64 5/10
Verifying : glibc-headers-x86-2.31.9000-17.fc33.noarch 6/10
Verifying : isl-0.16.1-10.fc32.x86_64 7/10
Verifying : kernel-headers-5.8.0-0.rc4.git0.1.fc33.x86_64 8/10
Verifying : libmpc-1.1.0-8.fc32.x86_64 9/10
Verifying : libxcrypt-devel-4.4.16-5.fc33.x86_64 10/10
Preparing : 1/1
Upgrading : glibc-common-2.34-8.fc35.x86_64 1/19
Upgrading : glibc-minimal-langpack-2.34-8.fc35.x86_64 2/19
Running scriptlet: glibc-2.34-8.fc35.x86_64 3/19
Upgrading : glibc-2.34-8.fc35.x86_64 3/19
Running scriptlet: glibc-2.34-8.fc35.x86_64 3/19
Installing : glibc-gconv-extra-2.34-8.fc35.x86_64 4/19
Running scriptlet: glibc-gconv-extra-2.34-8.fc35.x86_64 4/19
Upgrading : libgpg-error-1.43-1.fc35.x86_64 5/19
Upgrading : gpgme-1.15.1-6.fc35.x86_64 6/19
Upgrading : python3-gpg-1.15.1-6.fc35.x86_64 7/19
Upgrading : glib2-2.70.1-1.fc35.x86_64 8/19
Upgrading : shadow-utils-2:4.9-5.fc35.x86_64 9/19
Upgrading : vim-minimal-2:8.2.3582-1.fc35.x86_64 10/19
Cleanup : glib2-2.70.0-5.fc35.x86_64 11/19
Cleanup : shadow-utils-2:4.9-3.fc35.x86_64 12/19
Cleanup : python3-gpg-1.15.1-4.fc35.x86_64 13/19
Cleanup : gpgme-1.15.1-4.fc35.x86_64 14/19
Cleanup : vim-minimal-2:8.2.3568-1.fc35.x86_64 15/19
Cleanup : libgpg-error-1.42-3.fc35.x86_64 16/19
Cleanup : glibc-2.34-7.fc35.x86_64 17/19
Cleanup : glibc-minimal-langpack-2.34-7.fc35.x86_64 18/19
Cleanup : glibc-common-2.34-7.fc35.x86_64 19/19
Running scriptlet: glibc-common-2.34-7.fc35.x86_64 19/19
Verifying : glibc-gconv-extra-2.34-8.fc35.x86_64 1/19
Verifying : glib2-2.70.1-1.fc35.x86_64 2/19
Verifying : glib2-2.70.0-5.fc35.x86_64 3/19
Verifying : glibc-2.34-8.fc35.x86_64 4/19
Verifying : glibc-2.34-7.fc35.x86_64 5/19
Verifying : glibc-common-2.34-8.fc35.x86_64 6/19
Verifying : glibc-common-2.34-7.fc35.x86_64 7/19
Verifying : glibc-minimal-langpack-2.34-8.fc35.x86_64 8/19
Verifying : glibc-minimal-langpack-2.34-7.fc35.x86_64 9/19
Verifying : gpgme-1.15.1-6.fc35.x86_64 10/19
Verifying : gpgme-1.15.1-4.fc35.x86_64 11/19
Verifying : libgpg-error-1.43-1.fc35.x86_64 12/19
Verifying : libgpg-error-1.42-3.fc35.x86_64 13/19
Verifying : python3-gpg-1.15.1-6.fc35.x86_64 14/19
Verifying : python3-gpg-1.15.1-4.fc35.x86_64 15/19
Verifying : shadow-utils-2:4.9-5.fc35.x86_64 16/19
Verifying : shadow-utils-2:4.9-3.fc35.x86_64 17/19
Verifying : vim-minimal-2:8.2.3582-1.fc35.x86_64 18/19
Verifying : vim-minimal-2:8.2.3568-1.fc35.x86_64 19/19
Upgraded:
glib2-2.70.1-1.fc35.x86_64
glibc-2.34-8.fc35.x86_64
glibc-common-2.34-8.fc35.x86_64
glibc-minimal-langpack-2.34-8.fc35.x86_64
gpgme-1.15.1-6.fc35.x86_64
libgpg-error-1.43-1.fc35.x86_64
python3-gpg-1.15.1-6.fc35.x86_64
shadow-utils-2:4.9-5.fc35.x86_64
vim-minimal-2:8.2.3582-1.fc35.x86_64
Installed:
binutils-2.34.0-7.fc33.x86_64 binutils-gold-2.34.0-7.fc33.x86_64 cpp-10.1.1-2.fc33.x86_64 gcc-10.1.1-2.fc33.x86_64 glibc-devel-2.31.9000-17.fc33.x86_64 glibc-headers-x86-2.31.9000-17.fc33.noarch
isl-0.16.1-10.fc32.x86_64 kernel-headers-5.8.0-0.rc4.git0.1.fc33.x86_64 libmpc-1.1.0-8.fc32.x86_64 libxcrypt-devel-4.4.16-5.fc33.x86_64
glibc-gconv-extra-2.34-8.fc35.x86_64
Complete!
STEP 6: COMMIT myimage
STEP 5/5: RUN dnf install -y gcc
Last metadata expiration check: 0:00:10 ago on Fri Nov 12 21:22:21 2021.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
gcc x86_64 11.2.1-1.fc35 fedora 31 M
Installing dependencies:
binutils x86_64 2.37-10.fc35 fedora 6.0 M
binutils-gold x86_64 2.37-10.fc35 fedora 728 k
cpp x86_64 11.2.1-1.fc35 fedora 10 M
elfutils-debuginfod-client x86_64 0.185-5.fc35 fedora 36 k
gc x86_64 8.0.4-6.fc35 fedora 103 k
glibc-devel x86_64 2.34-8.fc35 updates 146 k
glibc-headers-x86 noarch 2.34-8.fc35 updates 544 k
guile22 x86_64 2.2.7-3.fc35 fedora 6.4 M
kernel-headers x86_64 5.14.9-300.fc35 fedora 1.3 M
libmpc x86_64 1.2.1-3.fc35 fedora 62 k
libpkgconf x86_64 1.8.0-1.fc35 fedora 36 k
libtool-ltdl x86_64 2.4.6-42.fc35 fedora 36 k
libxcrypt-devel x86_64 4.4.26-4.fc35 fedora 29 k
make x86_64 1:4.3-6.fc35 fedora 533 k
pkgconf x86_64 1.8.0-1.fc35 fedora 41 k
pkgconf-m4 noarch 1.8.0-1.fc35 fedora 14 k
pkgconf-pkg-config x86_64 1.8.0-1.fc35 fedora 10 k
Transaction Summary
================================================================================
Install 18 Packages
Total download size: 57 M
Installed size: 196 M
Downloading Packages:
(1/18): binutils-gold-2.37-10.fc35.x86_64.rpm 1.4 MB/s | 728 kB 00:00
(2/18): elfutils-debuginfod-client-0.185-5.fc35 565 kB/s | 36 kB 00:00
(3/18): gc-8.0.4-6.fc35.x86_64.rpm 1.4 MB/s | 103 kB 00:00
(4/18): binutils-2.37-10.fc35.x86_64.rpm 6.1 MB/s | 6.0 MB 00:00
(5/18): cpp-11.2.1-1.fc35.x86_64.rpm 9.2 MB/s | 10 MB 00:01
(6/18): kernel-headers-5.14.9-300.fc35.x86_64.r 11 MB/s | 1.3 MB 00:00
(7/18): libmpc-1.2.1-3.fc35.x86_64.rpm 785 kB/s | 62 kB 00:00
(8/18): guile22-2.2.7-3.fc35.x86_64.rpm 16 MB/s | 6.4 MB 00:00
(9/18): libpkgconf-1.8.0-1.fc35.x86_64.rpm 376 kB/s | 36 kB 00:00
(10/18): libtool-ltdl-2.4.6-42.fc35.x86_64.rpm 520 kB/s | 36 kB 00:00
(11/18): libxcrypt-devel-4.4.26-4.fc35.x86_64.r 429 kB/s | 29 kB 00:00
(12/18): pkgconf-1.8.0-1.fc35.x86_64.rpm 471 kB/s | 41 kB 00:00
(13/18): pkgconf-m4-1.8.0-1.fc35.noarch.rpm 148 kB/s | 14 kB 00:00
(14/18): pkgconf-pkg-config-1.8.0-1.fc35.x86_64 143 kB/s | 10 kB 00:00
(15/18): glibc-devel-2.34-8.fc35.x86_64.rpm 518 kB/s | 146 kB 00:00
(16/18): gcc-11.2.1-1.fc35.x86_64.rpm 21 MB/s | 31 MB 00:01
(17/18): make-4.3-6.fc35.x86_64.rpm 702 kB/s | 533 kB 00:00
(18/18): glibc-headers-x86-2.34-8.fc35.noarch.r 2.0 MB/s | 544 kB 00:00
--------------------------------------------------------------------------------
Total 19 MB/s | 57 MB 00:02
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : libmpc-1.2.1-3.fc35.x86_64 1/18
Installing : cpp-11.2.1-1.fc35.x86_64 2/18
Installing : glibc-headers-x86-2.34-8.fc35.noarch 3/18
Installing : pkgconf-m4-1.8.0-1.fc35.noarch 4/18
Installing : libtool-ltdl-2.4.6-42.fc35.x86_64 5/18
Installing : libpkgconf-1.8.0-1.fc35.x86_64 6/18
Installing : pkgconf-1.8.0-1.fc35.x86_64 7/18
Installing : pkgconf-pkg-config-1.8.0-1.fc35.x86_64 8/18
Installing : kernel-headers-5.14.9-300.fc35.x86_64 9/18
Installing : libxcrypt-devel-4.4.26-4.fc35.x86_64 10/18
Installing : glibc-devel-2.34-8.fc35.x86_64 11/18
Installing : gc-8.0.4-6.fc35.x86_64 12/18
Installing : guile22-2.2.7-3.fc35.x86_64 13/18
Installing : make-1:4.3-6.fc35.x86_64 14/18
Installing : elfutils-debuginfod-client-0.185-5.fc35.x86_64 15/18
Installing : binutils-gold-2.37-10.fc35.x86_64 16/18
Installing : binutils-2.37-10.fc35.x86_64 17/18
Running scriptlet: binutils-2.37-10.fc35.x86_64 17/18
Installing : gcc-11.2.1-1.fc35.x86_64 18/18
Running scriptlet: gcc-11.2.1-1.fc35.x86_64 18/18
Verifying : binutils-2.37-10.fc35.x86_64 1/18
Verifying : binutils-gold-2.37-10.fc35.x86_64 2/18
Verifying : cpp-11.2.1-1.fc35.x86_64 3/18
Verifying : elfutils-debuginfod-client-0.185-5.fc35.x86_64 4/18
Verifying : gc-8.0.4-6.fc35.x86_64 5/18
Verifying : gcc-11.2.1-1.fc35.x86_64 6/18
Verifying : guile22-2.2.7-3.fc35.x86_64 7/18
Verifying : kernel-headers-5.14.9-300.fc35.x86_64 8/18
Verifying : libmpc-1.2.1-3.fc35.x86_64 9/18
Verifying : libpkgconf-1.8.0-1.fc35.x86_64 10/18
Verifying : libtool-ltdl-2.4.6-42.fc35.x86_64 11/18
Verifying : libxcrypt-devel-4.4.26-4.fc35.x86_64 12/18
Verifying : make-1:4.3-6.fc35.x86_64 13/18
Verifying : pkgconf-1.8.0-1.fc35.x86_64 14/18
Verifying : pkgconf-m4-1.8.0-1.fc35.noarch 15/18
Verifying : pkgconf-pkg-config-1.8.0-1.fc35.x86_64 16/18
Verifying : glibc-devel-2.34-8.fc35.x86_64 17/18
Verifying : glibc-headers-x86-2.34-8.fc35.noarch 18/18
Installed:
binutils-2.37-10.fc35.x86_64
binutils-gold-2.37-10.fc35.x86_64
cpp-11.2.1-1.fc35.x86_64
elfutils-debuginfod-client-0.185-5.fc35.x86_64
gc-8.0.4-6.fc35.x86_64
gcc-11.2.1-1.fc35.x86_64
glibc-devel-2.34-8.fc35.x86_64
glibc-headers-x86-2.34-8.fc35.noarch
guile22-2.2.7-3.fc35.x86_64
kernel-headers-5.14.9-300.fc35.x86_64
libmpc-1.2.1-3.fc35.x86_64
libpkgconf-1.8.0-1.fc35.x86_64
libtool-ltdl-2.4.6-42.fc35.x86_64
libxcrypt-devel-4.4.26-4.fc35.x86_64
make-1:4.3-6.fc35.x86_64
pkgconf-1.8.0-1.fc35.x86_64
pkgconf-m4-1.8.0-1.fc35.noarch
pkgconf-pkg-config-1.8.0-1.fc35.x86_64
Complete!
COMMIT myimage
Getting image source signatures
Copying blob fd46c60e883a skipped: already exists
Copying blob f3157b126b5d done
Copying config d3a341d4fd done
Copying blob cd62a89550d0 skipped: already exists
Copying blob 0f38b540528b done
Copying config c0458c205e done
Writing manifest to image destination
Storing signatures
--> d3a341d4fd9
d3a341d4fd993fb4ee84f102e5915fe9ab544f4cd72fd9947beec9e745f12302
--> c0458c205e5
Successfully tagged localhost/myimage:latest
c0458c205e533af9be1e5e9e665afb0d491f622a243deac76b4cbd0824bf23f6
sh-5.0$ buildah images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/myimage latest d3a341d4fd99 22 seconds ago 475 MB
registry.fedoraproject.org/fedora 33 71d10e102a30 23 hours ago 191 MB
localhost/myimage latest d3a341d4fd99 22 seconds ago 544 MB
registry.fedoraproject.org/fedora 35 1b52edb08181 23 hours ago 159 MB
sh-5.0$ ls -l output/
total 4
-rw-r--r--. 1 build build 288 Jul 8 07:48 update-output.txt
-rw-r--r--. 1 build build 7186 Nov 12 21:22 update-output.txt
````