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 脚本 排除