jmeter 脚本排除_对Buildah脚本进行故障排除

jmeter 脚本排除

作为十几岁的父亲和软件工程师，我大部分时间都在处理问题。无论问题是大还是小，很多时候您都无法直接查看问题原因。相反，您需要退后一步，调查情况存在的环境。我最近意识到了这一点，当时有一位介绍容器技术的同事（包括Buildah和Podman等容器管理器）要求我帮助解决他打算在几天后的会议上演示的演示脚本问题。

该脚本过去曾经有用，但现在不起作用了，他处于紧要关头。这是一个演示脚本，它使用Buildah创建基于Fedora 28的容器并在其中安装NGINX HTTPD服务器。然后，它使用Podman运行容器并启动NGINX服务器。最后，脚本执行快速curl命令以拉出index.html文件，以证明服务器已启动并响应。所有这些命令在设置和测试期间均有效，但是现在curl失败了。（顺便说一句，如果您想了解Buildah或运行演示，请看一下我同事的完整脚本，因为它非常有用。）

我与Podman小组的成员进行了交谈，他们无法重现此问题，因此我认为这可能是Buildah中的问题。我们进行了一连串的调试和检查配置代码，以确保正确设置了端口，正确提取了映像并保存了所有内容。全部检查了。先前的演示过程均已成功完成：NGINX服务器将按预期提供index.html。这很奇怪，而且最近对Buildah代码的更改都不会破坏任何这些。

在会议开始的最后期限临近之前，我开始进行研究，将脚本缩小为以下内容。

cat ~/tom_nginx.sh

        #!/bin/bash

# docker-compatibility-demo.sh # author : demodude # Assumptions install buildah, podman & docker # Do NOT start the docker deamon # Set some of the variables below

demoimg=dockercompatibilitydemo quayuser=ipbabble myname="Demo King" distro=fedora distrorelease=28 pkgmgr=dnf # switch to yum if using yum

#Setting up some colors for helping read the demo output bold=$(tput bold) red=$(tput setaf 1) green=$(tput setaf 2) yellow=$(tput setaf 3) blue=$(tput setaf 4) cyan=$(tput setaf 6) reset=$(tput sgr0)

echo -e "Using ${green}GREEN${reset} to introduce Buildah steps" echo -e "Using ${yellow}YELLOW${reset} to introduce code" echo -e "Using ${blue}BLUE${reset} to introduce Podman steps" echo -e "Using ${cyan}CYAN${reset} to introduce bash commands" echo -e "Using ${red}RED${reset} to introduce Docker commands"

echo -e "Building an image called ${demoimg}"

set -x newcontainer=$(buildah from ${distro}) buildah run $newcontainer -- ${pkgmgr} -y update && ${pkgmgr} -y clean all buildah run $newcontainer -- ${pkgmgr} -y install nginx && ${pkgmgr} -y clean all buildah run $newcontainer bash -c 'echo "daemon off;" >> /etc/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 name=$demoimg $newcontainer buildah inspect $newcontainer buildah commit $newcontainer $demoimg buildah images containernum=$(podman run -d -p 80:80 $demoimg) curl localhost # Failed podman ps podman stop $containernum podman rm $containernum

`脚本在做什么`

从set -x部分开始，您可以看到脚本使用buildah from创建了一个新的Fedora容器。接下来的四个步骤使用buildah run在容器中进行一些配置：前两个步骤使用DNF软件包管理器进行更新，安装NGINX并清理所有内容。第三步和第四步准备NGINX运行-第三步设置/etc/nginx/nginx.conf文件并daemon off ，第四步中的run命令创建要显示的index.html文件。

buildah config的三个buildah config命令在容器内做了一些内务处理。他们设置了端口80，将入口点设置为NGINX，并在新容器中修改了created-by ， author和label字段。此时，容器已设置为运行NGINX，并且buildah inspect命令使您可以遍历容器的字段和关联的元数据以验证所有内容。

该脚本使用Podman来运行容器和NGINX服务器。 Podman是一个新的开源实用程序，用于处理Linux容器和Kubernetes容器，它模仿Docker命令行的许多功能，但不需要Docker的守护进程。为了使Podman运行该容器，必须首先将其另存为映像-这是buildah commit行正在执行的操作。

最后， podman run线启动容器，并且-由于我们使用入口点配置端口和设置端口的方式，NGINX服务器启动并可以使用。总是很高兴地说服务器正在“运行”，但是证明能够与服务器交互。因此，脚本执行了一个简单的curl localhost ; 如果工作正常，index.html应包含：

 nginx on OCI Fedora image, built using Buildah

但是，距离下一个演示仅几个小时，它发送回：

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

现在，那不是很好。

诊断问题

我在开发虚拟机（VM）上反复遇到问题。我添加了调试语句，但仍然没有找到任何东西。奇怪的是，我发现，如果我换成podman与docker在脚本，一切工作就好了。我对开发VM并不总是很友善，因此我建立了一个新VM并安装了所有新鲜，干净的东西。

脚本在那里也失败了，所以并不是我的开发VM本身表现不佳。在思考问题时，我多次运行了脚本，希望从输出中获得任何线索。我的下一个想法是进入容器并在其中环顾四周。我注释掉了stop和rm行，并使用以下命令重新运行了脚本：

 podman exec --tty 129d4d33169f /bin/bash

其中129d4d33169f是来自podman ps命令的容器的CONTAINER ID值。我在容器内运行curl localhost ，瞧！我从index.html收到了正确的输出。然后，我退出了该容器，并从运行该容器的主机上再次尝试了curl命令，这一次它起作用了。

终于，大理石头上的光亮了。在过去的测试中，我一直在使用Apache HTTPD服务器，并尝试从另一个会话连接到该服务器。在那些测试中，如果我执行得太快，服务器将拒绝我。

可以这么简单吗？

事实证明，就是这么简单。我们在podman run和curl localhost命令之间添加了sleep 3线，一切都按预期工作。似乎正在发生的是podman run命令正在非常快速地启动容器和NGINX服务器并返回命令行。如果您不等待几秒钟，则NGINX服务器没有时间启动和开始接受连接请求。

问题确实是工程师要解决的问题，答案通常不在代码本身中。在查看问题时，最好退后一点，不要过于关注位和字节。

本文的早期版本最初出现在ProjectAtomic.io博客上。

翻译自: https://opensource.com/article/18/6/buildah-troubleshooting

jmeter 脚本排除