Troubleshooting a Buildah script | Opensource.com

As each a father of youngsters and a software program engineer, I spend most of my time coping with issues. Whether the issue is massive or small, many instances you possibly can’t discover the reason for a difficulty by trying immediately at it. Instead, it’s essential to step again and examine the surroundings the place the state of affairs exists. I noticed this just lately, when a colleague who presents on container applied sciences, together with container managers like Buildah and Podman, requested me for assist fixing an issue with a demo script he was planning to indicate at a convention only some days later.

The script had labored up to now however wasn’t working now, and he was in a pinch. It’s a demo script that creates a Fedora 28-based container using Buildah and installs the NGINX HTTPD server inside it. Then it makes use of Podman to run the container and kick off the NGINX server. Finally, the script does a fast curl command to drag the index.html file to show the server is up and responsive. All these instructions had labored throughout setup and testing, however now the curl was failing. (By the way in which, if you wish to find out about Buildah or run a demo, check out my colleague’s full script, as it’s a nice one to make use of.)

I talked to the parents on the Podman staff, and so they weren’t in a position to reproduce the problem, so I believed it is likely to be an issue in Buildah. We did a flurry of debugging and checking within the config code to ensure the ports had been being arrange correctly, the picture was getting pulled appropriately, and all the things was saved. It all checked out. Prior run-throughs of the demo had all accomplished efficiently: the NGINX server would serve up the index.html as anticipated. That was odd, and no current modifications to the Buildah code had been prone to upset any of that.

With the deadline earlier than the convention ticking away, I started investigating by shrinking the script all the way down to the next.

cat ~/tom_nginx.sh

#!/bin/bash
# docker-compatibility-demo.sh
# writer : demodude
# Assumptions set up buildah, podman & docker
# Do NOT begin the docker deamon
# Set among the variables under
demoimg=dockercompatibilitydemo
quayuser=ipbabble
myname="Demo King"
distro=fedora
distrorelease=28
pkgmgr=dnf # swap to yum if utilizing yum
#Setting up some colours for serving to learn the demo output
daring=$(tput daring)
purple=$(tput setaf 1)
inexperienced=$(tput setaf 2)
yellow=$(tput setaf three)
blue=$(tput setaf four)
cyan=$(tput setaf 6)
reset=$(tput sgr0)
echo -e "Using $GREEN$reset to introduce Buildah steps"
echo -e "Using $yellowYELLOW$reset to introduce code"
echo -e "Using $blueBLUE$reset to introduce Podman steps"
echo -e "Using $cyanCYAN$reset to introduce bash commands"
echo -e "Using $redRED$reset to introduce Docker commands"
echo -e "Building an image called $demoimg"
set -x
newcontainer=$(buildah from $distro)
buildah run $newcontainer -- $ -y replace && $ -y clear all
buildah run $newcontainer -- $ -y set up nginx && $ -y clear all
buildah run $newcontainer bash -c 'echo "daemon off;" >> /and many others/nginx/nginx.conf'
buildah run $newcontainer bash -c 'echo "nginx on OCI Fedora image, built using Buildah" > /usr/share/nginx/html/index.html'
buildah config --port 80 --entrypoint /usr/sbin/nginx $newcontainer
buildah config --created-by "$quayuser" $newcontainer
buildah config --author "$myname" --label identify=$demoimg $newcontainer
buildah examine $newcontainer
buildah commit $newcontainer $demoimg
buildah photographs
containernum=$(podman run -d -p 80:80 $demoimg)
curl localhost # Failed
podman ps
podman cease $containernum
podman rm $containernum

What the script is doing

Beginning within the set -x part, you possibly can see the script creates a brand new Fedora container utilizing buildah from. The subsequent 4 steps use buildah run to do some configurations within the container: the primary two use the DNF software program package deal supervisor to do an replace, set up NGINX, and clear all the things up; the third and fourth steps put together NGINX to run—the third units up the /and many others/nginx/nginx.conf file and units daemon off, and the run command within the fourth step creates the index.html file to be displayed.

The three buildah config instructions that folllow do some housekeeping throughout the container. They arrange port 80, set the entry level to NGINX, and contact up the created-by, writer, and label fields within the new container. At this level, the container is about as much as run NGINX, and the buildah examine command permits you to stroll by means of the container’s fields and related metadata to confirm all of that.

This script makes use of Podman to run the container and the NGINX server. Podman is a brand new, open supply utility for working with Linux containers and Kubernetes pods that emulates many options of the Docker command line however would not require a daemon as Docker does. For Podman to run the container, it should first be saved as a picture—that is what the buildah commit line is doing.

Finally, the podman run line begins up the container and—because of the approach we configured it with the entry level and organising the ports—the NGINX server begins and is on the market to be used. It’s at all times good to say the server is “running,” however the proof is having the ability to work together with the server. So, the script executes a easy curl localhost; if it is working, index.html ought to include:

nginx on OCI Fedora picture, constructed utilizing Buildah

However, with solely hours earlier than the following demo, it as a substitute despatched again:

curl: (7) Failed to hook up with jappa.cos.redhat.com port 80: Connection refused

Now, that is not good.

Diagnosing the issue

I used to be repeatedly having the issue on my growth digital machine (VM). I added debugging statements and nonetheless did not discover something. Strangely, I discovered if I changed podman with docker within the script, all the things labored simply wonderful. I am not at all times very sort to my growth VM, so I arrange a brand new VM and put in all the things good and contemporary and clear.

The script failed there as effectively, so it wasn’t that my growth VM was behaving badly by itself. I ran the script a number of instances whereas I used to be pondering issues by means of, hoping to select up any clue from the output. My subsequent thought was to get into the container and go searching in there. I commented out the cease and rm traces and re-ran the script utilizing:

podman exec --tty 129d4d33169f /bin/bash

the place 129d4d33169f was the CONTAINER ID worth from the podman ps command for the container. I ran curl localhost there throughout the container and voilà! I obtained the proper output from index.html. I then exited the container and tried the curl command once more from the host operating the container, and this time it labored.

Finally, gentle dawned on marblehead. In previous testing, I might been taking part in with an Apache HTTPD server and making an attempt to hook up with it from one other session. In these checks, if I went too fast, the server would reject me.

Could it’s that straightforward?

As it seems, it was that straightforward. We added a sleep three line between the podman run and the curl localhost instructions, and all the things labored as anticipated. What appeared to be occurring was the podman run command was beginning up the container and the NGINX server extraordinarily rapidly and returning to the command line. If you do not wait a number of seconds, the NGINX server would not have time to start out up and begin accepting connection requests.

In our testing with Docker, this wasn’t the case. I did not dig into it deeply, however my assumption is the time Docker spends speaking to the Docker daemon provides the NGINX server sufficient time to come back up totally. This is what makes Buildah and Podman very helpful and highly effective: no daemon, much less overhead. But it’s essential to take that under consideration for demos!

Problems are certainly what engineers resolve, and oftentimes the reply is just not within the code itself. When issues, it is good to step again a bit of bit and never get too targeted on the bits and the bytes.

An earlier model of this text initially appeared on the ProjectAtomic.io weblog.