为什么 ansible 在第一次尝试 Gitlab 时不做这个任务？

Question

我正在通过gitlab-ci执行一些ansible剧本，我可以看到的是

1. Ansible剧本通过管道成功执行，但它没有产生预期的输出

2. 当我重试gitlab作业时，它会产生我需要的输出。

这是我通过gitlab:执行的众多playbooks之一

1_ca.yaml

---
- hosts: 127.0.0.1
connection: local
tasks:
- name: Create ca-csr.json
become: true
copy:
dest: ca-csr.json
content: '{"CN":"Kubernetes","key":{"algo":"rsa","size":2048},"names":[{"C":"US","L":"Portland","O":"Kubernetes","OU":"CA","ST":"Oregon"}]}'
- name: Create ca-config.json
become: true
copy:
dest: ca-config.json
content: '{"signing":{"default":{"expiry":"8760h"},"profiles":{"kubernetes":{"usages":["signing","key encipherment","server auth","client auth"],"expiry":"8760h"}}}}'
- name: Create the ca.pem & ca-key.pem
# become: true
shell: |
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

基本上，它所做的是它创建了一些我需要的证书。

但在第一次尝试中，即使管道通过，它也不会生成这些证书。当我重新启动(第二次运行同一作业(gitlab中的特定作业时，它会生成这些证书。

为什么会发生这种情况？

这就是我的.gitlab-ci.yaml的样子：

Create-Certificates:
stage: ansible-play-books-create-certs
retry:
max: 2
when:
- always
script:
- echo "Executing ansible playbooks for generating certficates"
- ansible-playbook ./ansible-playbooks/1_ca/1_ca.yaml
- ansible-playbook ./ansible-playbooks/1_ca/2_admin.yaml
- ansible-playbook ./ansible-playbooks/1_ca/3_kubelet.yaml
- ansible-playbook ./ansible-playbooks/1_ca/4_kube-controller.yaml
- ansible-playbook ./ansible-playbooks/1_ca/5_kube-proxy.yaml
- ansible-playbook ./ansible-playbooks/1_ca/6_kube-scheduler.yaml
- ansible-playbook ./ansible-playbooks/1_ca/7_kube-api-server.yaml
- ansible-playbook ./ansible-playbooks/1_ca/8_service-account.yaml
- ansible-playbook ./ansible-playbooks/1_ca/9_distribute-client-server-cert.yaml
# when: delayed
# start_in: 1 minutes
tags:
- banuka-gcp-k8s-hard-way 

PS：这些易解析的剧本是在易解析主机本身执行的，而不是在远程服务器中。因此，我可以登录到ansible主服务器，检查这些文件是否已创建。

Answer 1

在没有最后一个shell模块的情况下运行您的剧本会产生以下输出：

[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
PLAY [127.0.0.1] **************************************************************************************************************************************************************************************************
TASK [Gathering Facts] ********************************************************************************************************************************************************************************************
ok: [127.0.0.1]
TASK [Create ca-csr.json] *****************************************************************************************************************************************************************************************
[WARNING]: File './ca-csr.json' created with default permissions '600'. The previous default was '666'. Specify 'mode' to avoid this warning.
changed: [127.0.0.1]
TASK [Create ca-config.json] **************************************************************************************************************************************************************************************
[WARNING]: File './ca-config.json' created with default permissions '600'. The previous default was '666'. Specify 'mode' to avoid this warning.
changed: [127.0.0.1]
PLAY RECAP ********************************************************************************************************************************************************************************************************
127.0.0.1                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

并检查是否存在：

$ ls ca* -al
-rw------- 1 root root 155 Aug 17 02:48 ca-config.json
-rw------- 1 root root 129 Aug 17 02:48 ca-csr.json

因此，尽管这是一种相当肮脏的剧本写作方式，但它确实有效。为什么它很脏？：

• 您没有使用任何库存
• 本地任务应该使用local_action，而不是connection: local
• 您正在滥用ansible，即多节点配置管理来执行bash脚本任务

因此，总之，你的ansible剧本没有错，或者文件权限(？(没有错，如果它没有运行，你应该更多地关注gitlab ci方向。

你需要提供更多关于Gitlab CI设置的详细信息，但可能stage不正确？