【发布时间】:2017-09-11 19:15:20
【问题描述】:
我正在构建一个 Jenkins 作业以在 AWS EC2 实例上构建 docker 容器,这是一个给出错误的 Jenkins 脚本示例:
#!/bin/bash -e
# Not giving the IP here but I guess you can understand
HOST = Some IP address of EC2 instance in AWS
# Current Project workspace
# Download source code and create a tar and then SCP it in to AWS EC2
# So my Code is copied in to AWS EC2 instance now ...
# Now do the SSH and run the script on AWS EC2 instance
ssh -o StrictHostKeyChecking=no -i MySecrets.pem ec2-user@$HOST \
"tar xvf pc.tar && \
cd my_project_source_code && \
docker stop $(docker ps -a -q) && \
docker rmi $(docker images -a -q) && \
sh -c 'nohup docker-compose kill > /dev/null 2>&1 &' && \
docker-compose build --no-cache && \
sh -c 'nohup docker-compose up > /dev/null 2>&1 &' "
当我在 Jenkins 中构建此作业时,它在输出控制台上失败并出现以下错误:
“docker stop”至少需要 1 个参数。见'码头工人停止 --帮助'。
用法:docker stop [OPTIONS] CONTAINER [CONTAINER...]
停止一个或多个正在运行的容器构建步骤标记为“执行外壳” 构建失败
所以我的问题是我的 bash 脚本有什么问题?
单独说明:
当我在 CLI 上 ssh 进入 EC2 时,我能够运行 docker stop $(docker ps -a -q)。但是,当在 Jenkins 作业 bash shell 脚本中运行相同的命令时,它不会将其识别为有效脚本。我在这里做错了什么?这似乎是我对如何在 Jenkins Job 的 bash shell 脚本中运行此命令的一些误解,但我并不完全确定。
【问题讨论】:
-
将它放在双引号中会使命令替换在本地运行,而不是在远程端。
-
顺便说一句——为什么是
sh -c?所有这些都已经在 shell 中运行了;为什么要调用另一个? -
另外,假设后台进程和脚本中后续步骤之间的顺序通常是个坏主意。您没有合理的基础可以相信
docker-compose kill将在docker-compose build之前可靠且一致地生效,特别是当您将sh和nohup等额外命令循环到前者的启动过程中时。 -
另外,使用全大写
HOST作为变量名是个坏主意。请参阅pubs.opengroup.org/onlinepubs/9699919799/basedefs/…——全大写名称用于对 shell 和 OS 有意义的变量,而带有小写字符的名称保留给应用程序使用。 -
...也就是说:
docker-compose kill >/dev/null 2>&1 </dev/null & disown -h "$!"做了 nohup 所做的一切,没有外部依赖,也没有愚蠢的nohup.out默认值。
标签: linux bash docker jenkins jenkins-cli