Exercise 1.8 - Introduction to using buildah, podman and skopeo to work on containers

The Red Hat Universal base image (UBI) is a convenient starting point for creating containers. It offers official RHEL bits for building container images, but offers more freedom in how they are used and distributed. There are three versions of it, standard, minimal and runtimes. For this workshop we will use the standard image.

To build an application container from the base image, we will create a working container with buildah. A working container is a temporary container used as the target for buildah commands.

Verify that your pull request for the container image completed. Using the buildah command will display and allow you to verify what container images your user has access to.

The UBI standard variant is very complete, including tools like yum and systemd. You can install httpd via yum in the container using the buildah run subcommand:

This subcommand acts like the RUN directive in an OCIFile (also known as a ContainerFile or DockerFile). Since the yum command includes a switch, we need to use the -- syntax to tell buildah run there are no buildah options to look for past this point.

Once the packages are installed in the working container, place a one-line home page we can use to check that our container works properly.

Instead of using init scripts, the webserver will be started directly when the container is started. In order to keep the container running while the webserver is up, the foreground flag is added or the container would end as soon as it goes into the background. To set httpd to start when the container is run, modify the metadata with the buildah config subcommand.

The above option to buildah config is equivalent to the CMD directive in an OCIFile (ContainerFile, DockerFile)

To get access to the web server, http port 80 needs to be opened

Once the contents of the working container are complete, and the metadata has been updated, save the working container as the target application image using buildah commit. During the container customization process, you can choose how often you want to save your customizations in order to test each modification that has been completed. In this case we are saving both the installation of apache, a simple home page and the directive to start the httpd service:

In this example, each previous buildah subcommand results in a separate layer, much like building using an OCIFile. Note that we have named our save point as httpd. You can change this to any label that will reflect what changes you have made at that given save point.

In the previous steps we used buildah to pull down a new image and customize that image. The last step of Section 3 had us commit the changes to the container and name it httpd. Using the podman command, we can view what containers are available to start and run.

Podman and buildah use the same local image storage locations, which lets us immediately run our new image without specifying the location of the container or system on which the container will run. Note we are using the name httpd that we created in our previous section. As mentioned previously, you can launch, test, and then stop the container as you make each individual change. This can be used for general application testing or debugging of a change made to the container during customization with buildah.

the container’s port 80 is at this point bound to port 8080 so it could be started by a non-root user.

Now, we can check the status of the application container using podman. Note you can also see the forwarded ports:

Further, you can view the container’s processes with the following:

Now, we can test retrieval of our example home page:

Before we get started, we need to disable Fapolicyd (the File Access Policy Daemon) for this exercise. You enabled this during the mitigation steps in Exercise 1.7. Fapolicyd will prevent the container based application from starting.

First let’s use skopeo to inspect the image.

First export the image from ec2-user’s image store into an archive file. Skopeo can export containers into either docker archive or OCI archive if we want to put the container into a file. Using the OCI archive format:

Import the archive into the system image store

The container should now be visible in the system image store

Before using this container image in a system service, let’s check it for CVEs. Since RHEL 8.2, the oscap-podman utility has been included for scanning container images. Let’s see how this works!

To finish this section, let’s integrate our new container into systemd so you can have it start at boot time and otherwise manage it using systemd. Before getting started, ensure that the webserver started in the openSCAP section is not running:

First prepare the container by creating it using our new image and configuring it to expose port 80. This container will be named "web".

Next generate the systemd configuration file. The default filename is container-<name>.service

This will create a systemd configuration file in the current working directory. Inspect the configuration file:

Finally move this service file into systemd configation and start the service:

Confirm that the container is started and it’s port 80 is connected to the host’s port 80.

Verify that the webserver is running

If you’ve built and tested a container with podman, and are happy with the results, you can very easily share that container with OpenShift.

Take a look at the file to see what’s in it. If you were in an OpenShift project, you could then import this file with:

This is an example of a single container export, but you can export complete pods as well.

If a container will no longer be used, you can remove it from the system using podman rm. In the command below, we use a bit of bash scripting to return the CONTAINER ID of the last container that was running as it is unique to each container image.

The output of this removal is the full CONTAINER ID which was removed from the system.

×

Workshop Details

Domain
Workshop
Student ID

Student ID 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

Domain rhnaps.io redhatgov.io az.redhatgov.io redhat-fierce.io fiercesw.network rhtps.io openshiftworkshop.com redhatpsmwsa.com open.redhat.com opentlc.com aroapp.io danclark.io

Workshop

Enter Default

Workshop Details

Domain
Workshop
Student ID