当Ansible在对主机运行播放时遇到问题时,它会将主机名输出到用户主目录中以'.retry'结尾的文件中.这些通常不使用,只是导致混乱,有没有办法将它们关闭或放在不同的目录？

我正在尝试使用我在 Dockerfile 中指定的 centOs 上的 yum 下载 java。拉取 centOs 映像后，运行崩溃并抛出此错误！？还要提一下，我的服务器实例是AWS EC2！

Step 2/9 : RUN yum install java -y
 ---> Running in 39fc233aa965
CentOS Linux 8 - AppStream                      184  B/s |  38  B     00:00
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
The command '/bin/sh -c yum install java -y' returned a non-zero code: 1

我正在将我们的基础设施交换成terraform.实际管理terraform文件和状态的最佳实践是什么？我意识到它的基础设施是代码,我会将我的.tf文件提交到git中,但我也提交了tfstate吗？它应该驻留在S3这样的地方吗？我最终希望CI能够管理所有这些,但这已经非常紧张,需要我找出文件的移动部分.

我真的只是想看看那里的人们是如何在生产中使用这种类型的东西的

//,我意识到它还在运行之前删除了一个包含正在运行的Vagrant框的文件夹.

我现在如何从Vagrant(全局状态)中删除它？

我已经删除了Virtualbox VM.

我无法停止、删除或终止我的 docker 容器。下面给出的命令及其各自的错误消息：

1. docker stop <container-id>
2. docker kill <container-id>
3. docker rm <container-id>

我明白了

1. Error response from daemon: cannot stop container: <container-id>: tried to kill container, but did not receive an exit event
2. Error response from daemon: cannot kill container: <container-id>: tried to kill container, but did not receive an exit event
3. Error response from daemon: You cannot remove a running container <container-id>. Stop the container before attempting removal or force remove

如果我用 sudo 为所有内容添加前缀，则会出现相同的错误消息；如果我使用 …

我一直在使用K8S ConfigMap和Secret来管理我们的属性.我的设计非常简单,它将属性文件保存在git仓库中,并使用构建服务器(如Thoughtworks GO)将它们自动部署为我的k8s集群中的ConfigMaps或Secrets(在选择条件下).

目前,我发现我不得不总是删除现有的ConfigMap和Secret并创建新的更新,如下所示:

1. kubectl delete configmap foo

2. kubectl create configmap foo --from-file foo.properties

有没有一种简单的方法可以使一步更有效,而且比删除当前更有效？我现在正在做的可能会破坏使用这些配置映射的容器,如果它尝试在删除旧的configmap并且尚未创建新的configmap时挂载.

提前致谢.

关于是否将.tfstate文件提交到Git 的问题,我有点疑惑.该Terraform文档状态:

Terraform terraform.tfstate默认情况下也会将一些状态放入文件中.这个状态文件非常重要; 它将各种资源元数据映射到实际资源ID,以便Terraform知道它正在管理什么.必须保存此文件并将其分发给可能运行Terraform的任何人.我们建议简单地将其置于版本控制中,因为它通常不会太大.

另一方面,现在,使用Terraform时对最佳实践的接受和赞成回答如下:

Terraform配置可用于在不同的基础架构上配置多个盒子,每个盒子可以具有不同的状态.由于它也可以由多个人运行,因此该状态应该位于集中位置(如S3),而不是 git.

(原作者的重点,而不是我)

谁是对的,如果是的话,为什么？

最近我在看Ansible,并希望在项目中使用它.还有另一个工具Rundeck可以用来做各种操作工作.我对这两种工具都没有经验,这是我目前对它们的理解:

类似的观点

• 这两个工具都是无代理的,并使用SSH在远程服务器上执行命令

• Rundeck的主要概念是Node,与Ansible的库存相同,关键思想是定义/管理/分组目标服务器

• Rundeck可以在选定的节点上执行ad-hoc命令,Ansible也可以非常方便地执行此操作.
• Rundeck可以定义工作流并在选定的节点上执行,这可以通过编写playbook来使用Ansible完成
• Rundeck可以与Jenkins等CI工具集成进行部署工作,我们也可以定义一个Jenkins作业来运行ansible-playbook来进行部署工作

不同点

• Rundeck有Job的概念,Ansible没有

• Rundeck有Job Scheduler,Ansible只能通过Jenkins或Cron任务等其他工具实现这一点

• 默认情况下,Rundeck免费提供Web UI,但您必须支付Ansible Tower的费用

似乎Ansible和Rundeck都可用于执行配置/管理/部署工作,可能以不同的方式.所以我的问题是:

• 这两种补充工具是否设计用于不同目的？如果它们是补充工具,为什么Ansibl只与Chef/Puppet/Slat等工具相比而不与Rundeck相比？如果他们不是为什么他们有这么多相似的功能？
• 我们已经在使用Jenkins for CI,构建一个Continuous-Delivery管道,哪个工具(Ansible/Rundeck)更适合用于部署？
• 如果它们可以一起使用,那么最佳做法是什么？

非常感谢任何建议和经验分享.

太长了；博士

如何$BUILD_VERSION在 Gitlab CI 中不同管道的作业之间传递数据（例如变量）？

所以（就我而言）：

Pipeline 1 on push ect.            Pipeline 2 after merge\n\n    `building` job ...                `deploying` job\n          \xe2\x94\x82                                \xe2\x96\xb2\n          \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80 $BUILD_VERSION \xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x98\n

背景

考虑以下示例（完整内容yml如下）：

Pipeline 1 on push ect.            Pipeline 2 after merge\n\n    `building` job ...                `deploying` job\n          \xe2\x94\x82                                \xe2\x96\xb2\n          \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80 $BUILD_VERSION \xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x80\xe2\x94\x98\n

我有两个阶段，登台和部署。暂存阶段building的工作构建应用程序并创建一个“审查应用程序”（为了简单起见，没有单独的构建阶段）。然后，部署中的作业会上传新应用程序。deploying

                      *staging* stage (pipeline 1)        *deploy* …