:strip_exif()/i/1385569950.png?f=thumbmini)
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
Ik citeer je even andersom om eerst mijn opzet hierin wat meer toe te lichten 
.
Neem ik bijvoorbeeld AdGuard home, dan heb ik dus het playbook playbooks/apps/adguard_home.yml.
. Dit werkt niet helemaal zoals ik zou verwachten met import_playbook omdat dan toch de role twee keer wordt uitgevoerd. Mja, 'verwacht' dus, want uiteraard is een playbook altijd afzonderlijk.
Doordat Ansible idempotent is zou ik uiteraard ook altijd all.yml of apps/all.yml kunnen gebruiken. Dit doe ik voornamelijk vanwege het af kunnen kaderen (kom ik zo op) en performance bij het ontwikkelen. Ik wil niet altijd alles of grote gedeeltes deployen. Ik besef me ook dat dit een kwestie van smaak is.
Ik gebruik voor het deployen een eigen fork van deze GitHub action. Die kerel had namelijk check_mode vernaggeld. Dit is alweer een tijdje geleden, dus de action zou wellicht weer kunnen werken.
De hele Ansible setup heb ik in een workflow zitten zodat ik geen oneindige herhaling van code heb. Tegenwoordig is het ook mogelijk om hiervoor workflow_call te gebruiken.
Tot slot heb ik in Renovate een tijdslot gezet voor auto-merges van Docker applicaties.
Nu heb ik namelijk regelmatig 3 - 5 Renovate PR's openstaan, terwijl ik voor digests zelfs al alleen branches gebruik
. Dat houdt elkaar ook nog eens op, want elke keer moeten PR's gesynct worden én wordt er dus opnieuw een Ansible-playbook met check mode uitgevoerd om te testen of het geheel nog werkt.
.Ik gebruik ook tags, maar ik heb aparte playbooks en meta-playbooks.
Neem ik bijvoorbeeld AdGuard home, dan heb ik dus het playbook playbooks/apps/adguard_home.yml.
YAML:
De 'dns' hosts zijn dus mijn primaire en secundaire nodes zoals ik in mijn eerdere post aangaf. Deze playbook gebruik ik ook bij het 'meta-playbook' playbooks/apps/infra.yml:1
2
3
4
5
6
| - name: Deploy AdGuard Home hosts: dns roles: - role: adguard_home tags: [app, dns, infra, adguard, adguard_home] |
YAML:
En dit 'meta-playbook' neem ik toevallig ook weer mee in een ander 'meta-playbook' playbooks/apps/all.yml:1
2
3
4
5
6
7
8
9
10
11
| - name: Deploy AdGuard Home ansible.builtin.import_playbook: adguard_home.yml - name: Deploy ddclient ansible.builtin.import_playbook: ddclient.yml - name: Deploy Beszel ansible.builtin.import_playbook: beszel.yml - name: Deploy Gatus ansible.builtin.import_playbook: gatus.yml |
YAML:
Om tot slot dit 'meta-playbook' nog eenmaal mee te nemen in een ander playbook: playbooks/all.yml om de meta-ception te maximaliseren 1
2
3
4
5
6
7
| - name: Deploy Infra ansible.builtin.import_playbook: infra.yml - name: Deploy Traefik ansible.builtin.import_playbook: traefik.yml # de rest van het playbook is hier niet relevant... |
YAML:
Daarmee heeft elk playbook een eigen functie:1
2
3
4
5
6
7
8
| - name: Setup Hosts ansible.builtin.import_playbook: hosts/all.yml - name: Setup Docker ansible.builtin.import_playbook: docker.yml - name: Install apps ansible.builtin.import_playbook: apps/all.yml |
- playbooks/apps/adguard_home.yml gebruik ik wanneer ik alleen AdGuard Home deploy
- playbooks/apps/infra.yml gebruik ik bij het deployen van de basis infra
- playbooks/apps/all.yml gebruik ik bij het deployen van alle apps (eventueel met een host list) bijvoorbeeld wanneer ik een 'bulk' aan aanpassingen heb gedaan zoals CPU of mem toewijzingen
- playbooks/all.yml gebruik ik bij een verse install
YAML:
Het zou dan ook zomaar kunnen zijn dat de Zigbee2MQTT playbook in dit geval ook Moquitto deployed. Zou kunnen, want dat heb ik momenteel nog niet 1
2
3
4
5
6
7
8
9
10
11
12
| - name: Deploy Mosquitto ansible.builtin.import_playbook: mosquitto.yml - name: Deploy Zigbee2MQTT ansible.builtin.import_playbook: zigbee2mqtt.yml - name: Deploy Home Assistant hosts: home_assistant roles: - role: home_assistant tags: [app, infra, home-assistant, home_assistant] |
. Dit werkt niet helemaal zoals ik zou verwachten met import_playbook omdat dan toch de role twee keer wordt uitgevoerd. Mja, 'verwacht' dus, want uiteraard is een playbook altijd afzonderlijk. Doordat Ansible idempotent is zou ik uiteraard ook altijd all.yml of apps/all.yml kunnen gebruiken. Dit doe ik voornamelijk vanwege het af kunnen kaderen (kom ik zo op) en performance bij het ontwikkelen. Ik wil niet altijd alles of grote gedeeltes deployen. Ik besef me ook dat dit een kwestie van smaak is.
Met bovenstaande dus in het achterhoofd heb ik mijn Forgejo workflow een path-mapping toegewezen. Om dus met AdGuard Home verder te gaan, .forgejo/workflows/adguard_home.yaml:
YAML:
Bij een PR wordt er dus altijd een check_mode uitgevoerd. Je zou uiteraard ook nog een Molecule test kunnen doen. Wanneer het PR uiteindelijk geaccepteerd wordt door Renovate wordt de deploy gedaan.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
| name: Deploy AdGuard Home # yamllint disable-line rule:truthy on: push: branches: - main paths: - roles/adguard_home/** pull_request: types: - opened - reopened - synchronize paths: - roles/adguard_home/** workflow_dispatch: inputs: check_mode: description: "Check mode (dry-run)" default: false required: false type: boolean concurrency: group: ${{ github.repository }} jobs: deploy: name: Deploy AdGuard Home runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: ⤵️ Checkout repository uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6 - name: 🏗️ Setup Python id: setup-python uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6 with: cache: 'pip' cache-dependency-path: 'requirements.txt' - name: 👷 Install Python dependencies if: steps.setup-python.outputs.cache-hit != 'true' shell: bash run: pip install -r requirements.txt - name: 📦 Setup Ansible Galaxy Cache id: ansible-galaxy-cache uses: actions/cache@cdf6c1fa76f9f475f3d7449005a359c84ca0f306 # v5 with: path: | .ansible ~/.ansible key: ${{ runner.os }}-ansible-${{ hashFiles('**/requirements.yml') }} restore-keys: | ${{ runner.os }}-ansible- - name: 🌌 Install Ansible Galaxy dependencies if: steps.ansible-galaxy-cache.outputs.cache-hit != 'true' shell: bash run: ansible-galaxy install -r requirements.yml - name: 🚧 Setup known hosts id: setup-known-hosts shell: bash run: | if [ -z "${KNOWN_HOSTS}" ]; then echo "No known hosts provided, skipping setup." exit 0 fi KNOWN_HOSTS_FILE="/etc/ssh/known_hosts" mkdir -p /etc/ssh/ echo ${KNOWN_HOSTS} > ${KNOWN_HOSTS_FILE} echo "known-hosts-file=$KNOWN_HOSTS_FILE" >> $GITHUB_OUTPUT echo "SSH known hosts setup at: $KNOWN_HOSTS_FILE" env: KNOWN_HOSTS: ${{ vars.KNOWN_HOSTS }} - name: 🔑 Setup Vault password id: setup-vault-pass shell: bash run: | if [ -z "${VAULT_PASS}" ]; then echo "No vault password provided, skipping setup." exit 0 fi echo "::add-mask::${VAULT_PASS}" if [ -z "$VAULT_PASS_DIRECTORY" ]; then VAULT_PASS_FILE="${{ github.workspace }}/.vault_pass" else mkdir -p "$VAULT_PASS_DIRECTORY" VAULT_PASS_FILE="$VAULT_PASS_DIRECTORY/.vault_pass" fi echo "$VAULT_PASS" > $VAULT_PASS_FILE echo "vault-pass-file=$VAULT_PASS_FILE" >> $GITHUB_OUTPUT echo "Vault password file setup at: $VAULT_PASS_FILE" env: VAULT_PASS: ${{ inputs.vault-pass }} VAULT_PASS_DIRECTORY: ${{ inputs.vault-pass-directory }} - name: 🚀 Run Ansible Playbook uses: dawidd6/action-ansible-playbook@v9 with: playbook: playbooks/apps/adguard_home.yml requirements: requirements.yml key: ${{ secrets.DEPLOY_KEY }} vault_password: ${{ secrets.ANSIBLE_VAULT_KEY }} check_mode: >- ${{ inputs.check_mode == true || github.event_name == 'pull_request' }} |
Ik gebruik voor het deployen een eigen fork van deze GitHub action. Die kerel had namelijk check_mode vernaggeld. Dit is alweer een tijdje geleden, dus de action zou wellicht weer kunnen werken.
De hele Ansible setup heb ik in een workflow zitten zodat ik geen oneindige herhaling van code heb. Tegenwoordig is het ook mogelijk om hiervoor workflow_call te gebruiken.
Tot slot heb ik in Renovate een tijdslot gezet voor auto-merges van Docker applicaties.
JSON:
Vandaar dat ik dit de roles dus eigenlijk in een aparte repo zou willen. Dan is het een en ander van nature namelijk afgekaderd in plaats van dat ik dit nog moet configureren. De merges zouden dan ook continue kunnen plaatsvinden met een afgekaderde / tijdstlot merge naar mijn infra-repo 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| { "packageRules": [ "description": "Update Docker dependencies", "matchFileNames": [ "roles/common/**", "roles/docker/**", "roles/dockge/**", "**/compose.yml", "**/compose.yaml", "**/compose.yml.j2", "**/compose.yaml.j2" ], "automergeSchedule": ["* 10-19 * * 1-6"] } } |
Nu heb ik namelijk regelmatig 3 - 5 Renovate PR's openstaan, terwijl ik voor digests zelfs al alleen branches gebruik
. Dat houdt elkaar ook nog eens op, want elke keer moeten PR's gesynct worden én wordt er dus opnieuw een Ansible-playbook met check mode uitgevoerd om te testen of het geheel nog werkt.
/u/21638/crop626ad1243c0f9_cropped.png?f=community)
.
. Maar een role dependency is wederom per playbook, omdat ik meerdere playbooks uitvoer werkt dat dus niet zoals ik hoop dat dat werkt. Ik moet daarbij wel opmerken dat ik het niet heb getest 
. Wel om meerdere roles uit te voeren in twee playbooks en die worden dan dus ook twee keer uitgevoerd. Verder las ik wat online discussies en documentaties waarbij aangegeven wordt dat role deduplication alleen per play plaatsvindt.
.
. 
.
. Misschien is dat wel de noodzaak voor het opsplitsen geweest 
