:strip_exif()/i/1385569950.png?f=thumbmini)
/u/21638/crop626ad1243c0f9_cropped.png?f=community)
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Dit heb ik dus ook::
@blackd Altijd interessant. Molecule staat ook nog steeds ergens op een lijstje. Tegelijkertijd heb ik er nog geen noodzaak voor gehad. Dus ben wel benieuwd hoe jij dat doet
.
Ik gebruik nu alweer een tijdje een Ansible anti-patroon om mijn Docker Compose applicaties uit te rollen. Namelijk een 'common' role. Ik ben er zelf ook geen fan van, maar de alternatieven zijn een git submodule.
code:
en die gebruik ik in mijn docker compose roles als volgt (dockge als voorbeeld):1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| docker_compose_base
├── defaults
│ └── main.yml
├── tasks
│ ├── build.yml
│ ├── chown_dataset.yml
│ ├── copy.yml
│ ├── create_dataset.yml
│ ├── delete.yml
│ ├── delete_app.yml
│ ├── delete_dataset.yml
│ ├── down.yml
│ └── up.yml
└── vars
└── main.yml |
YAML:
De copy.yml gebruikt ansible.builtin.template om templates/compose.yml en templates/.env.j2 te plaatsen in de project directory.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| --- - name: Copy tasks ansible.builtin.import_role: name: docker_compose_base tasks_from: copy vars: docker_compose_base__stack_base_dir: "{{ dockge__stack_base_dir }}" # place custom docker compose project setup here - name: Docker Compose Up ansible.builtin.import_role: name: docker_compose_base tasks_from: up vars: docker_compose_base__stack_base_dir: "{{ dockge__stack_base_dir }}" |
De up.yml doet een docker compose up in de project directory.
Ik had al verklapt dat ik molecule collections tests had gebruikt. Qua structuur ziet dat er zo uit:
code:
Het staat ook uitgelegd in de docs maar eerst wordt het scenario default/create.yml playbook uitgevoerd, daarna per scenario de converge, verify en cleanup, vervolgens scenario default/destroy.yml.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| extensions
└── molecule
├── config.yml
├── default
│ ├── create.yml
│ ├── destroy.yml
│ ├── molecule.yml
│ └── tasks
│ ├── assert-container.yml
│ ├── create-fail.yml
│ └── set-permissions.yml
├── dockge
│ ├── cleanup.yml
│ ├── converge.yml
│ ├── molecule.yml
│ └── verify.yml
[snip]
└── uptime_kuma_v2
[snip] |
De belangrijkste config hiervoor is extensions/molecule/config.yml.
Hier is dus het test_sequence scenario expliciet gemaakt. Zelf gebruik ik alleen converge, verify, cleanup.
De shared_state=true zorgt ervoor dat default/create.yml als eerste (voor alle andere scenario's) wordt uitgevoerd, en default/destroy.yml als laatste (na alle andere scenario's) wordt uitgevoerd.
Om dit te laten werken, moest ik wel een galaxy.yml in mijn root project folder aanmaken (via ansible-creator
init collection <namespace>.<collection>). Zie deze documentatie.
Dan heb ik het default scenario als volgt:
default/create.yml:
YAML:
default/destroy.yml: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
| --- - name: Create hosts: localhost connection: local gather_facts: false tasks: - name: Create dind-network community.docker.docker_network: name: dind-network state: present - name: Create dind-daemon container community.docker.docker_container: name: my-dind-daemon image: docker:dind docker_host: unix:///var/run/docker.sock state: started command: ["--data-root", "/var/lib/docker"] privileged: true env: DOCKER_TLS_CERTDIR: "" networks: - name: dind-network aliases: - docker - name: Create a container community.docker.docker_container: name: "{{ item }}" image: "{{ hostvars[item].image }}" docker_host: unix:///var/run/docker.sock state: started command: sleep 1d log_driver: json-file networks: - name: dind-network env: DOCKER_HOST: "tcp://docker:2375" register: result loop: "{{ groups['molecule'] }}" - name: Fail if container is not running when: > item.container.State.ExitCode != 0 or not item.container.State.Running ansible.builtin.include_tasks: file: tasks/create-fail.yml loop: "{{ result.results }}" loop_control: label: "{{ item.container.Name }}" - name: Prepare hosts: molecule gather_facts: true pre_tasks: [ hier alle voorwaarden waaraan de test-resource moet voldoen, in mijn geval een bepaalde uid/gid ] roles: [ hier alle voorwaarden van roles (in mijn geval galaxy roles) die geinstalleerd moeten staan, vóór testuitvoer ] post_tasks: [ hier alle voorwaarden die afhankelijk zijn van de roles, in mijn geval een shared docker netwerk voor traefik ] |
YAML:
Je ziet dat ik een inventory heb met een molecule test resource, deze wordt in config.yml geconfigureerd en ziet er als volgt uit: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
| --- - name: Destroy molecule containers hosts: molecule gather_facts: false tasks: - name: Stop and remove molecule container delegate_to: localhost community.docker.docker_container: name: "{{ inventory_hostname }}" state: absent auto_remove: true docker_host: unix:///var/run/docker.sock - name: Stop and remove dind container delegate_to: localhost community.docker.docker_container: name: my-dind-daemon state: absent auto_remove: true docker_host: unix:///var/run/docker.sock - name: Destroy networks delegate_to: localhost community.docker.docker_network: name: "{{ item }}" state: absent docker_host: unix:///var/run/docker.sock loop: - [ mijn traefik netwerk ] - dind-network |
extensions/molecule/inventory.yml:
YAML:
Tot zover alle 'scaffolding' en je moet een beetje door de DinD heen kijken om het te begrijpen. 1
2
3
4
5
6
7
8
9
10
| --- all: children: molecule: hosts: molecule-debian12: image: geerlingguy/docker-debian12-ansible ansible_connection: community.docker.docker vars: [ evt noodzakelijke host vars ] |
Dan duiken we nu in één scenario, van dockge, daar doe ik eerst de converge (role toepassen), daarna verify (controleren op gewenste resultaat), cleanup (opruimen).
Om dat uberhaupt te laten werken, moet er een molecule.yml aanwezig zijn, die leeg is:
extensions/molecule/dockge/molecule.yml:
YAML:
Molecule zoekt gewoon naar de glob extensions/molecule/*/molecule.yml1
|
Dan de converge stap, het toepassen van de role op de test resource:
extensions/molecule/dockge/converge.yml:
YAML:
Je ziet dat DOCKER_HOST verwijst naar de DinD container (my-dind-container heeft een alias docker op het dind-network).1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| --- # Purpose: bring the instance to the desired state by running the role under test. # Molecule calls this playbook with `molecule converge`. - name: Converge hosts: molecule gather_facts: false # Disable if your role does not rely on facts # Set Docker host to communicate with the Docker daemon inside the DinD container environment: DOCKER_HOST: tcp://docker:2375/ tasks: - name: Apply role under test ansible.builtin.include_role: name: <namespace>.<collection>.dockge |
Onderwater worden de roles in mijn collection als dependency geinstalleerd bij het uitvoeren van Molecule, vandaar de include_role met volledige galaxy namespace (uit galaxy.yml). Hierdoor zijn ingewikkelde relatieve paden niet nodig.
Dan de verify stap om te controleren of alles goed is gegaan:
extensions/molecule/dockge/verify.yml:
YAML:
Ik heb hier een reusable task van gemaakt die ik in alle scenario's hergebruik.1
2
3
4
5
6
7
8
9
10
11
12
13
14
| --- # Purpose: assert that the instance really ended up in the expected state. # Molecule calls this playbook with `molecule verify`. - name: Verify hosts: molecule gather_facts: false # Quicker, if you do not need facts tasks: - name: Assert container running ansible.builtin.include_tasks: file: ../default/tasks/assert-container.yml loop: - dockge-dockge-1 |
extensions/molecule/default/tasks/assert-container.yml:
YAML:
Je ziet dat ik controleer of de state van de container juist is, maar je kan natuurlijk ook andere zaken controleren.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
| --- - name: Exit if item not provided ansible.builtin.assert: that: - item is defined fail_msg: > Error running assert container task Variable {{ item }} should be provided in a loop, but is not present. - name: Obtain container info community.docker.docker_container_info: name: "{{ item }}" register: container_info - name: Assert container exists ansible.builtin.assert: that: - container_info.container is not none fail_msg: Container {{ item }} is not running - name: Assert container is running correctly ansible.builtin.assert: that: - container_info.container.State.Running == true - container_info.container.State.ExitCode == 0 - container_info.container.State.Restarting == false fail_msg: "The container {{ item }} is not running as expected." success_msg: "The container {{ item }} is running as expected." |
Alleen al voor het testen van templates zou molecule best een goede tool zijn.
Dan de cleanup playbook, die haalt de container down en gooit de files weer weg.
Heb weer DOCKER_HOST laten verwijzen naar DinD container.
extensions/molecule/dockge/cleanup.yml:
YAML:
Als ik nu molecule test uitvoer in mijn project root, worden alle tests uitgevoerd.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
| --- - name: Cleanup hosts: molecule gather_facts: false vars: compose_project_dir: "{{ dockge__stack_base_dir | default('/opt/stacks/dockge') }}" # Set Docker host to communicate with the Docker daemon inside the DinD container environment: DOCKER_HOST: tcp://docker:2375/ tasks: - name: Check if compose_project_dir exists ansible.builtin.stat: path: "{{ compose_project_dir }}" register: compose_dir_stat - name: Docker compose down become: true community.docker.docker_compose_v2: project_src: "{{ compose_project_dir }}" state: absent when: compose_dir_stat.stat.exists - name: Remove folder ansible.builtin.file: path: "{{ compose_project_dir }}" state: absent become: true |
Met -s kan ik één (of meerdere) scenario's uitvoeren.
In mijn CI check ik met een script welke files in /roles/ worden gewijzigd en als er een overeenkomstige folder in extensions/molecule is, trap ik die met molecule -s af.
Ik heb nog niet voor alle roles een scenario, maar wel voor alle docker compose projects op mijn TrueNAS machine.
Wat nog wel lastig was is omgaan met volumes (gemount op docker host), deze komen ook in de DinD container terecht.
Mijn docker compose projects draaien op TrueNAS en per applicatie maak ik een dataset aan. Ik heb dus een reusable task in docker_compose_base om deze datasets aan te maken. Deze stap sla ik over bij het uitvoeren van Molecule tests (met de tag "notest") maar om de permissies wel goed te hebben tijdens de tests, voer ik pre_tasks uit in de converge playbook om permissies goed te zetten. Hieronder de reusable task die met docker_container_exec wat magic uitvoert in de DinD container.
extensions/molecule/default/tasks/set-permissions.yml:
YAML:
Al met al was het best een klus om dit allemaal werkend te krijgen, maar als je één simpel scenario op een gegeven moment werkend hebt, volgt de rest daarna vrij snel. Ik ben begonnen met simpele compose projecten zonder docker volume mounts, daarna de complexere projecten met volume mounts opgepakt. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| --- - name: Exit if item not provided ansible.builtin.assert: that: - item is defined - item_uid is defined - item_gid is defined fail_msg: > Error running set permissions task. Check if all required variables are set correctly. Variable {{ item }} should be provided in a loop. Variables {{ item_uid }} and {{ item_gid }} should be defined. - name: Set permissions inside my-dind-daemon container delegate_to: localhost community.docker.docker_container_exec: container: my-dind-daemon command: > sh -c "mkdir -p {{ item }} && chown -R {{ item_uid }}:{{ item_gid }} {{ item }} && chmod -R 775 {{ item }}" docker_host: unix:///var/run/docker.sock |
Voor Traefik heb ik nog op het lijstje om met Let's Encrypt staging te gaan werken of met een stub wat betreft de certificaten. Ook zou ik daar de Cloudflare tunnel willen 'stubben' o.i.d.
Zo is er altijd ruimte voor verbetering
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
/u/78932/Jewel3GoT.png?f=community)
:strip_icc():strip_exif()/u/101588/crop69cbc8124478f_cropped.jpg?f=community)
@blackd Thanks voor de enorm uitgebreide post 
Ik heb er nu even doorheen gelezen, maar dit zet ik zeker op mijn lijstje om op een later moment op te gaan pakken 
.
Ik vind het wel enorm leuk om te zien dat onze Docker + Ansible aanpak enorm veel overeenkomsten heeft.
Ik heb momenteel mijn structuur zo opgezet, met als voorbeeld mijn 'common' role.
Elke set met tasks begint bij mij overigens hetzelfde:
De assertions gebruik ik puur en alleen om geen oneindige herhaling van code / configuratie te hebben. Een paar voorbeelden:
assert/docker.networks.yml
.
Verder doe ik in de compose/up.yml nog wel een verwijdering van niet-Compose bestanden afhankelijk van wat er is gedeployed. En een validatie van Compose voor de Compose up:
Ik heb er nu even doorheen gelezen, maar dit zet ik zeker op mijn lijstje om op een later moment op te gaan pakken .Ik vind het wel enorm leuk om te zien dat onze Docker + Ansible aanpak enorm veel overeenkomsten heeft
.Ik heb momenteel mijn structuur zo opgezet, met als voorbeeld mijn 'common' role.
code:
De defaults zijn wat defaults voor o.a. Docker, de vars hebben voornamelijk 'interne' variabelen en statische strings die ik hergebruik, bijvoorbeeld:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| group_vars/
host_vars/
playbooks/
roles/
└── common/
├── defaults/
│ └── main.yml
├── tasks/
│ ├── assert/
│ │ ├── devices.yml
│ │ ├── docker.networks.yml
│ │ ├── docker.proxy.yml
│ │ ├── docker.resources.yml
│ │ ├── docker.volumes.yml
│ │ └── storage.yml
│ └── compose/
│ ├── up.yml
│ ├── down.yml
│ └── remove.yml
└── vars/
└── main.yml |
YAML:
En tot slot heb ik mijn tasks opgesplitst in momenteel twee categorieën: assertions en Compose.1
2
3
4
5
6
7
8
| _parent_role: "{{ ansible_parent_role_names | last }}" _compose_filename: 'compose.yaml' _compose_env_filename: ".env" _is_unraid: >- {{ 'slackware' in (ansible_facts['distribution'] | lower) and 'unraid' in (ansible_facts['kernel'] | lower) }} |
Elke set met tasks begint bij mij overigens hetzelfde:
YAML:
Het is namelijk niet de bedoeling dat deze tasks op zichzelf gebruikt worden.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| - name: Assert role isn't invoked directly ansible.builtin.assert: that: - ansible_parent_role_names is defined - ansible_parent_role_names is iterable and ansible_parent_role_names is not string - ansible_parent_role_names | default([]) | length > 0 - _parent_role is defined - _parent_role is string - _parent_role | length > 0 fail_msg: >- The 'common' role is an internal utility role and should not be invoked directly. tags: - always |
De assertions gebruik ik puur en alleen om geen oneindige herhaling van code / configuratie te hebben. Een paar voorbeelden:
assert/docker.networks.yml
YAML:
assert/docker.resources.yml1
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
| - name: "{{ _parent_role }} : Assert Docker networks are provided" ansible.builtin.assert: that: - docker_networks is defined - docker_networks is iterable and docker_networks is not string - docker_networks | length > 0 fail_msg: No, an invalid or an empty `docker_networks` list was provided. - name: "{{ _parent_role }} : Assert Docker volumes have the correct format" ansible.builtin.assert: that: - item is defined - item is mapping - item.name is defined - item.name is string - item.name | length > 0 and item.name | length <= 64 - (item.ipv4_address | default()) is defined - (item.ipv4_address | default(none)) is none or item.ipv4_address is ansible.utils.ipv4_address - (item.ipv6_address | default()) is defined - (item.ipv6_address | default(none)) is none or item.ipv6_address is ansible.utils.ipv6_address - (item.driver_opts | default()) is defined - (item.driver_opts | default(none)) is none or item.driver_opts is mapping fail_msg: >- The provided Docker networks mapping has an incorrect format. A `name` attribute is required per network. An optional IPv4 address and/or an optional IPv6 address can be provided. As well as a `driver_opts` mapping. loop: "{{ docker_networks }}" - name: "{{ _parent_role }} : Test if provided Docker network exists" community.docker.docker_network_info: name: "{{ item.name }}" register: _docker_network_info_output failed_when: not _docker_network_info_output.exists loop: "{{ docker_networks }}" |
YAML:
Niet bepaald rocket science voor mensen bekend met Ansible, maar het zorgt er bij mij voor dat ik in rollen deze controles op een wat bondigere manier kan afwikkelen. Een voorbeeld uit mijn Home Assistant role.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| - name: "{{ _parent_role }} : Assert Docker resource constraints are provided" ansible.builtin.assert: that: - docker_services is defined - docker_services is iterable and docker_services is not string fail_msg: No or an invalid `docker_services` list was provided. - name: "{{ _parent_role }} : Assert Docker resource constraints" ansible.builtin.assert: that: - item.cpu_limit is defined - item.cpu_limit is number - item.cpu_limit <= (ansible_facts['processor_vcpus'] | int) - item.cpuset is defined - item.cpuset is none or item.cpuset is string - item.mem_limit is defined - item.mem_limit is number - item.mem_limit <= (ansible_facts['memtotal_mb'] | int) - item.mem_reservation is defined - item.mem_reservation is number - item.mem_reservation <= item.mem_limit fail_msg: One or more provided resource constraints has errors loop: "{{ docker_services }}" when: docker_services | length > 0 |
YAML:
En hierna kan ik dan (eventueel) nog specifieke role-configuratie controleren. Bijvoorbeeld de juiste waardes van configuratie variabelen.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
| - name: Assert storage configuration ansible.builtin.include_role: name: common tasks_from: assert/storage.yml vars: application_dir: "{{ home_assistant_dir }}" application_user: "{{ home_assistant_user }}" application_group: "{{ home_assistant_group }}" - name: Assert Docker configuration ansible.builtin.include_role: name: common tasks_from: assert/docker.resources.yml vars: docker_services: - cpu_limit: "{{ home_assistant_cpu_limit }}" cpuset: "{{ home_assistant_cpuset }}" mem_limit: "{{ home_assistant_mem_limit }}" mem_reservation: "{{ home_assistant_mem_reservation }}" - name: Assert Reverse proxy configuration ansible.builtin.include_role: name: common tasks_from: assert/docker.proxy.yml vars: docker_ingress_network: "{{ home_assistant_ingress_network }}" traefik_domain: "{{ home_assistant_domain }}" - name: Assert Docker networks ansible.builtin.include_role: name: common tasks_from: assert/docker.networks.yml vars: docker_networks: "{{ home_assistant_networks }}" when: home_assistant_networks | length > 0 |
Doe jij dat dus dynamisch? Want nu geef ik bij elke role de bestanden mee...
YAML:
Is niets mis mee, maar ik zou dat eigenlijk dynamisch willen... Als ik er nu, zo diep in mijn hoofd hè, over nadenk is dat waarschijnlijk ook triviaal 1
2
3
4
5
6
7
| - name: Docker Compose Up ansible.builtin.include_role: name: common tasks_from: compose/up.yml vars: compose_template: "templates/compose.yaml.j2" compose_env_template: "templates/.env.j2" |
. Verder doe ik in de compose/up.yml nog wel een verwijdering van niet-Compose bestanden afhankelijk van wat er is gedeployed. En een validatie van Compose voor de Compose up:
YAML:
Die validate zou je eigenlijk bij een template willen, maar dat heb ik niet werkend gekregen. Ik weet niet helemaal meer waarom, omdat dit alweer een tijdje geleden is.
1
2
3
4
5
6
7
8
| - name: "{{ _parent_role }} : Validate Docker Compose" ansible.builtin.command: cmd: docker compose config chdir: "{{ _compose_directory.path }}" register: _docker_compose_config_output ignore_errors: "{{ ansible_check_mode }}" failed_when: _docker_compose_config_output.rc != 0 changed_when: false |
Goed om te horen, zeker leuk dat we veel overeenkomsten hebben en van de verschillen kunnen we denk ik alleen maar leren:
@blackd Thanks voor de enorm uitgebreide post
Ik vind het wel enorm leuk om te zien dat onze Docker + Ansible aanpak enorm veel overeenkomsten heeft
.Wat bedoel je met dynamisch? Mijn compose.yml is geen Jinja template als je dat bedoelt. Mijn compose file is gewoon uitgeschreven en bevat hooguit variabelen die gevoed worden uit de .env file.
Ik gebruik wel de template module van Ansible zodat de bestanden bij elkaar staan, maar eigenlijk is het onnodige overhead. Maar het maakt wel dat ik dclint over mijn compose files halen, wat ik dus ook doe in pre-commit en CI. Jij had al eerder aangegeven dat je op verschillende hosts wat configuratie en templating nodig had dus dat is bij jou wellicht wel wat lastiger.
De compose up task gaat er vanuit dat de role die hem aanroept een templates/compose.yml en templates/.env.j2 heeft. Netter zou zijn om de bestandsnamen door te geven zoals jij doet.
Mocht ik een keer een andere naam hanteren, dan gaat het fout. Aan de andere kant, ik heb hiervoor een role_template die de compose file genereert, dus daarmee is het risico op verkeerde bestandsnamen kleiner.
Wat dat betreft heb jij je tasks veel beter afgekaderd en ingeperkt dat ze niet misbruikt kunnen worden en fail-fast zijn. Daar kan ik nog wat van leren
. Bedankt voor jouw tips en voorbeelden hiervoor .
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Precies. Dat vind ik echt heel waardevol:
[...]
Goed om te horen, zeker leuk dat we veel overeenkomsten hebben en van de verschillen kunnen we denk ik alleen maar leren
. Alhoewel ik misschien veel zend, neem ik alle informatie tegelijkertijd ook in me op .Ah juist. Dan valt bij mij het spreekwoordelijke kwartje
.Ik gebruik inderdaad veel templating. In mijn vorige post sprak ik bijvoorbeeld over home_assistant_networks en die template ik dan ook in mijn Compose (snippet):
Django/Jinja:
In de host configuratie geef ik het volgende mee: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
| services: home-assistant: container_name: ${COMPOSE_PROJECT_NAME} image: ghcr.io/home-assistant/home-assistant:2026.3.1@sha256:0e091dfce3068339c3e1d14382e6c34141e05cd589a1972ebd4d9a8e6b5d8969 restart: on-failure:10 networks: ingress: priority: 10 {% if home_assistant_networks | length > 0 %} {% for network in home_assistant_networks %} {{ network.name }}: {% if network.ipv4_address is defined %} ipv4_address: {{ network.ipv4_address }} {% endif %} {% if network.ipv6_address is defined %} ipv6_address: {{ network.ipv6_address }} {% endif %} {% if network.driver_opts is defined and network.driver_opts is not none %} driver_opts: {{ network.driver_opts | to_nice_yaml | indent(10) }} {% endif %} {% endfor %} {% endif %} networks: ingress: name: {{ swarm_overlay_network }} external: true {% for network in home_assistant_networks %} {{ network.name }}: name: {{ network.name }} external: true {% endfor %} |
YAML:
Ik noem dit specifieke voorbeeld omdat dit een coole Docker constructie is die ik (nog) niet veel ben tegengekomen. In dit geval configureer ik namelijk specifieke IPv6 configuratie in de service in Compose zodat Thread vanuit de Home Assistant container werkt zonder dat host networking nodig is 1
2
3
4
5
6
| home_assistant_networks: - name: "{{ iot_network }}" ipv4_address: "192.168.24.100" ipv6_address: "{{ ipv6_prefix }}:24:100::100" driver_opts: com.docker.network.endpoint.sysctls: net.ipv6.conf.IFNAME.accept_ra=1,net.ipv6.conf.IFNAME.accept_ra_rt_info_max_plen=64,net.ipv6.conf.IFNAME.forwarding=0 |
. Eenzelfde constructie heb ik ook voor ESPHome.Dit zou je natuurlijk ook vast kunnen zetten in Compose en daar is niets mis mee. Tegelijkertijd is dit niet de enige plek of situatie waar ik zoiets doe. Ik doe dit ook bij ESPHome om dezelfde reden. Maar bij Plex kan ik op deze manier tamelijk eenvoudig een netwerk toevoegen voor een HDHomerun apparaat, bijvoorbeeld voor xTeve of vergelijkbare software.
Ook template ik bijv. Traefik labels met de naam van de Compose stack, dus:
code:
Waarmee ik dus wederom tamelijk eenvoudig een secundaire instantie van dezelfde software kan deployen zonder dat deze elkaar in de weg zitten 1
2
3
4
5
6
7
8
9
10
11
| {{ ansible_managed | comment }}
name: {{ compose_stack_name }}
services:
home-assistant:
container_name: ${COMPOSE_PROJECT_NAME}
labels:
traefik.enable: true
traefik.http.routers.{{ compose_stack_name }}.rule: "Host(`{{ home_assistant_domain }}`)"
traefik.http.services.{{ compose_stack_name }}.loadbalancer.server.port: 8123 |
.Bij mij is het templaten dus ook organisch gegroeid, maar inmiddels een groot onderdeel van mijn Compose setup.
Goed dat je me hier nogmaals aan herinnerd
. dclint staat ook nog steeds ergens op een lijstje.Mja, ik wilde met 'defaults' werken, maar dat was niet heel erg evident. Daar wil ik ook nog een keer naar kijken maar heeft geen prio.
Geen probleemWat dat betreft heb jij je tasks veel beter afgekaderd en ingeperkt dat ze niet misbruikt kunnen worden en fail-fast zijn. Daar kan ik nog wat van leren
, jij ook bedankt. Fail fast vind ik enorm belangrijk. Dat is misschien ook wel een van de kernwaarde van hoe ik werk. Op die manier zit ik namelijk nog in de materie en kan ik direct zien hoe, wat en waar het eventueel misgaat. In plaats van dat het al gedeployed is of bij een update kapot vliegt 
.Het testen van bijv. storage of devices doe ik wel al langer en is inmiddels automatisme. Fails komen weinig voor, maar als ze voortkomen is het vaak enorm belangrijk. Bijvoorbeeld als er een Zigbee / Z-Wave / Thread dongle mist. Dat wil ik liever op voorhand weten en het controleren kost niets.
In sommige gevallen - maar lang nog niet overal
- test ik ook op de bereikbaarheid van diensten. Bij mijn Frigate role ben ik daar enorm blij mee YAML:
Of de controle dat de reverse proxy na het deployen ook echt online komt1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| - name: Assert Frigate MQTT configuration ansible.builtin.assert: that: - frigate_mqtt is defined - frigate_mqtt is mapping - frigate_mqtt.enabled is defined - frigate_mqtt.enabled is boolean - frigate_mqtt.enabled and frigate_mqtt.host is defined - frigate_mqtt.enabled and frigate_mqtt.host is string - (frigate_mqtt.port | default(1883)) is defined - (frigate_mqtt.port | default(1883)) is number - (frigate_mqtt.user is defined and frigate_mqtt.password is not none) or (frigate_mqtt.user is not defined) fail_msg: The provided Frigate MQTT configuration has errors - name: Ensure that the provided MQTT server is reachable ansible.builtin.wait_for: host: "{{ frigate_mqtt.host }}" port: "{{ frigate_mqtt.port | default(1883) }}" timeout: 60 msg: Could not reach the provided MQTT server when: frigate_mqtt.enabled |
YAML:
Dat heeft me al de nodige hoofdpijn bespaard 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
| post_tasks: - name: Ensure Traefik is reachable from localhost ansible.builtin.uri: url: "https://{{ traefik_dashboard_domain }}/ping" return_content: false validate_certs: true status_code: [200] register: traefik_output until: traefik_output is defined and traefik_output.status == 200 delay: 5 retries: 24 delegate_to: localhost tags: [always] - name: Ensure Traefik is reachable through reverse proxy from target node ansible.builtin.uri: url: "https://{{ traefik_dashboard_domain }}/ping" return_content: true validate_certs: true status_code: [200] register: traefik_output until: traefik_output is defined and traefik_output.status == 200 delay: 5 retries: 24 tags: [always] |
.
Hier stip je een belangrijk verschil aan tussen onze setups: jij deployt de roles naar meerdere hosts of zelfs meerdere keren per host, waardoor je bepaalde verschillen kwijt wil kunnen in je roles, dan is templating een prima oplossing.
In mijn setup heb ik alleen traefik dubbel uitgevoerd (voor intern en extern verkeer) en dat zijn (nog) twee aparte compose projecten. Bij de externe variant deploy ik ook cloudflared, bij de interne niet.
Hier ben ik dus een andere weg in geslagen en heb ik een template compose role gemaakt:
code:
Ietswat uitleg bij deze structuur:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| role_template
├── _templates [1]
│ ├── .env.j2.j2 [3]
│ └── compose.yaml.j2
├── defaults
│ └── main.yml
├── molecule_scenario [2]
│ ├── cleanup.yml.j2
│ ├── converge.yml.j2
│ ├── molecule.yml.j2
│ └── verify.yml.j2
├── tasks
│ └── main.yml.j2
└── vars
└── main.yml.j2 |
[1] deze folder heb ik bewust _templates genoemd omdat de ansible-galaxy role init --role-skeleton deze anders niet meepakt. In de Taskfile.yml hernoem ik deze folder naar templates
[2] deze molecule_scenario hoort niet binnen de role maar binnen extensions/molecule/ en deze verplaats ik ook in mijn Taskfile.yml.
[3] Ja ja, ik template een template
.Hier heb ik dus ook variabelen als compose project name, maar ik pas ze niet runtime toe zoals jij.
compose.yaml.j2:
Django/Jinja:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| name: {{ init_docker_compose_project_name }} services: service-1: image: hub/image:version container_name: {{ init_docker_compose_project_name }} volumes: [... snip ...] labels: traefik.enable: true traefik.docker.network: traefik-net traefik.http.routers.{{ init_docker_compose_project_name }}.rule: Host(`{{ init_docker_compose_project_name }}.domain.tld`) traefik.http.routers.{{ init_docker_compose_project_name }}.entrypoints: websecure traefik.http.routers.{{ init_docker_compose_project_name }}.tls.certresolver: cfdns traefik.http.services.{{ init_docker_compose_project_name }}.loadbalancer.server.port: 8080 |
Ik hou daar ook van maar ik heb dat principe nog niet overal toegepast. Door deze discussie leer ik dat ik daar nog e.e.a. kan verbeteren.Geen probleem
Dat kan ik me heel goed voorstellen.In sommige gevallen - maar lang nog niet overal
Of de controle dat de reverse proxy na het deployen ook echt online komt
Dat heeft me al de nodige hoofdpijn bespaard
Momenteel monitor ik mijn docker containers en web services met Uptime Kuma en als iets omvalt wordt ik daar binnen een paar minuten van op de hoogte gebracht.
Mijn Renovate PR's merge ik (o.b.v. release notes) en deze zijn dan al in Molecule getest.
Nightly wordt mijn omgeving geupgrade met een playbook, die voer ik eerst uit in check mode, daarna apply ik de configuratie.
Maar het is helemaal tof als je de state van de service in het playbook al kan controleren.
Je kan zelfs zover gaan dat je een automatische rollback implementeert. Dat heb ik voor mijn twee RPI's gedaan met PiHole. Ik heb een playbook hiervoor met serial: 1 dus de hosts worden om de beurt geupgraded. Eerst haal ik keepalived down zodat de andere master wordt, daarna update ik de software.
Ik maak eerst een backup van de 'running config', plaats de nieuwe compose file, kijk of deze 'up' komt en lukt dat niet, plaats ik de 'running config' terug en breng die up. Dit werkt met een block en rescue sectie in de tasks.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Mja. Maar beperkt. Traefik of eigenlijk traefik-kop staat op al mijn hosts en hetzelfde geldt voor Beszel (agent). En AdGuard Home staat ook op meerdere hosts.
Waar ik het vooral handig voor vindt is het kunnen schuiven van applicaties. Wederom geen dagelijkse kost. Laatst heb ik bijvoorbeeld Beszel Hub van mijn hoofdmachine verplaatst naar mijn Pi. Die Pi had eigenlijk alleen de verantwoordelijkheid over een DS18B20 sensor waarmee ik mijn boiler aanstuur. Beszel Hub verplaatsten was zo gepiept en de data had ik met het handje even overgezet. Immers ga ik geen Ansible spullen inrichten voor een eenmalige scp.
Achteraf gezien bleek de Pi net teveel latency en te weinig pk's te hebben om Beszel naar tevredenheid te draaien. Vervolgens heb ik daarom besloten om Beszel Hub van de Pi naar mijn secundaire machine te verplaatsen. Niet meer naar mijn primaire host omdat ik niet wil dat dergelijke monitoring omvalt bij problemen daar. Wederom was dit zo gepiept met ~5 minuten downtime.
Dan vind ik het templating toch wel lekker, aangezien dit voor een groot gedeelte in de Compose yaml wordt geconfigureerd.
Ik bedoel daarmee vooral te zeggen dat ik jouw setup niet afkeur of slecht vind, maar dat ik uiteindelijk echt wel voordelen zie in het templaten. Ook met betrekking tot resource constraints.
Yes. Dit snap ik. Dit had ik eerst ook zo
. Alleen gebeurde het me regelmatig dat ik nieuwe functies of bugfixes in role implementaties doorvoerde maar niet meer 'backportte' naar de template. Ik heb daar de discipline niet voor.Interessant
. Ik wil dus niets nightly doen . Alle updates gaan bij mij op tijden dat ik wakker ben of kan reageren om maar niet wakker te hoeven worden met een kapotte omgeving.Bij het aanmaken van de PR door Renovate worden automatisch de geraakte role(s) in check mode gerunt door Forgejo runner. Wanneer deze checks slagen en de PR gemerged wordt, wordt er direct gedeployed. Wel met uitzonderingen. Home Assistant en verwante applicaties deploy ik bijvoorbeeld handmatig. Wederom heb ik geen zin in een spontaan kapotte Zigbee2MQTT. Hetzelfde geldt voor major's of sommige minor's.
Zoiets wil ik nog doen met Traefik en/of Mosquitto. Alleen vind ik het de investering vooralsnog niet waard. Daarmee bedoel ik vooral dat ik er al meermaals aan begonnen ben, maar uiteindelijk nooit afmaak omdat er voor mijn thuissituatie te weinig voordelen zijn. Behalve het 'baller'-effect
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
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.
@alex3305 interessante aanpak, zo had ik er nog niet over nagedacht. Feitelijk maak je voor alle laagste niveau apps een playbook en installeer je daar ook je dependencies.
Ik neem aan dat je deze opzet ook kent?
Als je de dependencies op role niveau definieert, zouden ze maar 1x uitgevoerd moeten worden.
En mag ik concluderen uit je post dat je hiermee eigenlijk voor elke app een eigen workflow hebt?
Klinkt als een mooie feature voor mijn role template
.
Ik heb nu maar 1 workflow die altijd het grote playbook uitvoert. Dat duurt 15 min, dat was ik zat, vandaar dat ik naar een nightly release ben overgestapt.
Ik neem aan dat je deze opzet ook kent?
Als je de dependencies op role niveau definieert, zouden ze maar 1x uitgevoerd moeten worden.
En mag ik concluderen uit je post dat je hiermee eigenlijk voor elke app een eigen workflow hebt?
Klinkt als een mooie feature voor mijn role template
.Ik heb nu maar 1 workflow die altijd het grote playbook uitvoert. Dat duurt 15 min, dat was ik zat, vandaar dat ik naar een nightly release ben overgestapt.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Ja, heel kort door de bocht wel ja
.Zeker. Sterker nog, die pagina had ik open toen ik mijn post schreef
. 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.Daarnaast vind ik dat bijvoorbeeld Mosquitto of Zigbee2MQTT geen echte dependency is van Home Assistant. En misschien is dat niet helemaal waar voor een tool zoals Zigbee2MQTT, maar wel voor Mosquitto. De MQTT broker gebruik ik immers ook op andere plekken. En ook krijg je dan een beetje 'vreemde' afhankelijkheden. Is DNS (AdGuard Home) bijvoorbeeld ergens afhankelijk van? Of monitoring en logging? Maar ja, als ik ze niet heb dan werkt het ook niet. Of in een extremer geval is Traefik met Crowdsec bij mij afhankelijk van het Vaultwarden (logging) pad. Is dan Vaultwarden een afhankelijkheid van Traefik? Eigenlijk wel... Maar dat voelt niet zo goed
.Collecties zouden hier de uitkomst bieden, maar daarbij zijn afhankelijkheden op andere rollen of collecties alleen mogelijk als deze in de centrale Ansible Galaxy repository staan. En dat wil ik niet
. Ik zit hier dus een beetje tussen wal en schip
.Kort door de bocht wel. Er zijn uiteraard uitzonderingen. Home Assistant is zo'n uitzondering waarbij die wel alle afhankelijkheden include, maar geen op zichzelf staand playbook heeft.En mag ik concluderen uit je post dat je hiermee eigenlijk voor elke app een eigen workflow hebt?
Klinkt als een mooie feature voor mijn role template
Ik haal het volgens mij niet in 15 minuten
. Misschien is dat wel de noodzaak voor het opsplitsen geweest 
Nee, dat was mijn vorige werk. Daar deden we volledige cloud inrichtingen met Ansible. Daar zaten we ook ruim over de 100 rollen heen. Dan is een volledige play - ook per host - niet meer praktisch. Ik heb het dan ook over een Ansible setup van ruim 12 jaar oud.
Dit patroon zie je overigens ook al bij de grotere setups van bijv. Red Hat zelf. Dus heel vreemd is het niet.
Ik heb wel op die manier dependencies opgegeven, zo heb ik een dockerproxy role toegevoegd aan mijn setup en alles wat iets met het docker socket nodig heeft, heeft als dependency de dockerproxy role.:
Zeker. Sterker nog, die pagina had ik open toen ik mijn post schreef
Dat werkt inderdaad binnen een playbook prima, want dat is hoe ik het nu heb ingericht.
Op mijn TrueNAS machine heb ik een jailmaker jail, waar ik alle docker compose projecten naar deploy.
Daarvoor heb ik één playbook truenas_apps.yml waarin alle docker compose projecten als roles staan, ieder met een eigen tag.
Dat HomeAssistant een dependency heeft op Zigbee2MQTT vind ik wel wat voor te zeggen, ook dat Zigbee2MQTT een broker nodig heeft, vind ik een goede dependency. Maar het maakt ook wel uit wanneer je de dependency nodig hebt, al bij het opstarten of pas bij het configureren van de applicaties.Daarnaast vind ik dat bijvoorbeeld Mosquitto of Zigbee2MQTT geen echte dependency is van Home Assistant. En misschien is dat niet helemaal waar voor een tool zoals Zigbee2MQTT, maar wel voor Mosquitto. De MQTT broker gebruik ik immers ook op andere plekken. En ook krijg je dan een beetje 'vreemde' afhankelijkheden. Is DNS (AdGuard Home) bijvoorbeeld ergens afhankelijk van? Of monitoring en logging? Maar ja, als ik ze niet heb dan werkt het ook niet. Of in een extremer geval is Traefik met Crowdsec bij mij afhankelijk van het Vaultwarden (logging) pad. Is dan Vaultwarden een afhankelijkheid van Traefik? Eigenlijk wel... Maar dat voelt niet zo goed
Een DNS server heb je nodig, dat klopt. Maar dat kun je ook op een andere manier afdwingen, nl: volgorde in je playbooks, zoals je dat bij Docker ook gedaan hebt.
Ik heb een vergelijkbaar playbook voor docker met een groep in mijn inventory en daar kan ik opgeven op welke hosts ik docker geïnstalleerd wil hebben.
Maar hoe pas jij jouw patroon toe bij apps die je op meerdere machines deployed?
Want ik kan me voorstellen dat als je Traefik op meerdere hosts deployed, dat je workflow file triggert op roles/traefik/* maar als je dan meerdere playbooks (aanname) moet aanroepen heb je eigenlijk de link tussen host en app op twee plekken liggen: in je playbooks én je workflow.
Of heb je één playbook per app en dan in die playbooks geconfigureerd op welke host (of groep) je de zaken deployed?
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Fair enough. Alleen was ik 1 detail nog vergeten
. Zigbee2MQTT draait mijn niet op mijn primaire machine. En Mosquitto niet op mijn secundaire machine . Dit is in dit geval wel nodig, althans zo lees ik de documentatie.In principe is er één 'hoofd' playbook per gedeployde dienst. Dus voor Traefik, die op al mijn Docker hosts draait, wordt dus gedeployed naar de groep docker vanuit hetzelfde playbook. Idem voor Docker en Docker Compose. Beszel draait op alle hosts, maar daarbij configureer ik in de host_vars welke variant ik deploy.
Om nog even bij Home Assistant terug te komen, deze wordt gedeployed op meerdere hosts vanuit één hoofd playbook, namelijk:
- home_assistant
- mqtt
- thread
- zigbee
- zwave
Volgens mij zijn er geen machine/container afhankelijkheden als je ze als losse containers draait. Mogelijk wel als je de HA integratie gebruikt. Bij mij gaat het prima over machines/servers heen.:
[...]
Fair enough. Alleen was ik 1 detail nog vergeten
HA praat met mosquitto op server/poort niveau, Z2M idem.
Ja
... Dat was niet de context van mijn post hè.Het gaat erover als je als dependency markeert in een meta/main.yml in Ansible zoals @blackd bedoelde en zoals hier beschreven in de Ansible documentatie dat deze niet over meerdere target hosts uit de inventory heengaat.
Ik wil dus de Mosquitto container via mijn Mosquitto role op mijn mqtt host uit de inventory parkeren, maar Zigbee2MQTT moet op de zigbee host én tot slot moet Home Assistant op de home_assistant host. Ansible heeft in principe geen kennis of context of deze hosts daadwerkelijk verschillend of gelijk zijn. Maar volgens mij gaat dat niet met role dependencies, wat volgens de documentatie ook semenatisch meer prerequisites zijn.
Volgens mij is er wel een uitzondering mogelijk hierop met delegate_to.
In mijn base role kan ik een directory maken op mijn TrueNAS machine. Dat doe ik in principe eerst op de TrueNAS host als zfs dataset, daarna in de TrueNAS jail.
De zfs dataset task draai ik met delegate to op de nas host, de role zelf gaat in de jail.
Oh ja en de jail mag niet met de nas praten dus ik gebruik een jump host.
Maar met een playbook is veel netter imho want met delegate to fixeer je de host in de role zelf.
Ik had al zo'n vermoeden:
Fair enough. Alleen was ik 1 detail nog vergeten
.Ik ga deze aanpak ook een keer proberen en kijken of het mij bevalt.
De templates in compose files ontkom ik denk ik ook niet aan. Ik heb meer duplicatie dan ik dacht (*Arr stack in uhd en 4k).
De gescheiden paden voor config e.d lukt nog wel, maar de traefik labels wordt lastig zonder templates vrees ik.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Yes. Daar had ik ook nog aan gedacht, maar een delegate_to zonder eerst een setup / gather_facts vind ik niet transparant en onverwacht. Daar blijf ik als het even kan dus ook van weg. Tijdens het opzetten van bijv. Swarm werkt een dergelijke constructie wel goed. Dan wil je bijv. alleen tasks uitvoeren op (de eerste) Swarm manager(s).
Ook dat nog. Nu zijn mijn rollen juist op zichzelf staand van de inventory en plays.
Ik heb er uiteindelijk echt geen enkele moeite meer mee, omdat het dus gemeengoed is. Het was ook al iets waar ik eerder al genoeg ervaring mee had.
Zoals ik eerder in deze post al aangaf wil ik ook nog een keer gaan kijken naar includes / lookups van templates om vaste stukken uit de compose te templaten. Ik heb bijvoorbeeld Unraid labels die overal hetzelfde zijn met wat kleine verschillen. Aan de andere kant werkt dit voor mij en is het duidelijk en transparant. Daarmee bedoel ik dat ik na een half jaar ook nog weet wat er staat. Soms is meer dus beter en de noodzaak nu niet zo hoog
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Dat is gewoon een skill issue
... Nee hoor, dat is een flauwe grap 
. Wat ik al zei, ik ben al meer dan een decennium bezig met Ansible en Jinja. En zelfs Jinja in Jinja of Go templates in Jinja. Dan wordt zoiets na al die jaren ook vanzelfsprekend. Ik zeg ook altijd dat Ansible een leercurve heeft van minimaal 6 maanden tot 1 jaar. Waarbij ik al zeer regelmatig na 1 maand de feedback terug heb gekregen dat ik uit mijn nek klets en Ansible veel makkelijker is. Ja, totdat je tegen een 'vaag' probleem aanloopt en een oplossing uit zich lijkt. Wat dat betreft is het dan "easy to learn, hard to master". En dan leer ik ook nog wekelijks bij.Maar om jouw vraag te beantwoorden; waarom template je het niet gewoon? Bij Jinja2 syntax fouten krijg je toch een foutmelding van Ansible, ook in check mode. Daarna valideer ik de uitgeschreven template met Compose zoals ik in mijn eerdere post liet zien.
Ik zou nog wat extra stappen kunnen toevoegen door bijvoorbeeld met een lookup plugin de yaml terug in te laden in Ansible en wat simpele assertions te doen. Bijvoorbeeld dat er services zijn. Alleen vind ik dat veel extra moeite en tijd met waarschijnlijk weinig concreet resultaat.
Dat zou ook nog kunnen, maar aangezien ik (nog) geen Molecule heb is dat bij mij niet van toepassing.
Tijdens mijn vorige werk werd voor Docker applicaties de template weggeschreven naar een /tmp/, gevalideerd en daarna gekopieerd naar de juiste directory. Dat werkt in tegenstelling tot mijn aanpak ook in check mode.
Nee, ik bedoel lookup templates.
Ik wil geen gesplitste Compose configuratie, daar heb ik immers Ansible voor. Die moet de juiste puzzelstukjes als geheel naar de target host zetten. En of dat dan lokaal in 1 stukje of 200 stukjes zit kan me een spreekwoordelijke worst wezen. Ik vind gesplitste Compose namelijk ondoorzichtig. Daarbij komt nog dat software zoals Dockge of Portainer daar niet of niet goed mee om kan gaan.
Klinkt als een mooie stap
. Zoiets doe ik dan vaak in een PR / feature branch om even te kijken hoe het mij bevalt. Het kan dan ook best zijn dat ik alles nog maar eens terugbouw omdat het dus niet bevalt .
Daar ga ik ook wel naar toe bewegen vermoed ik, eerst de apps als losse playbooks apart deploybaar maken en dan kan ik daarna de duplicatie in rollen wegwerken door de compose files dynamischer te maken met templating en d.m.v. variabelen sturen hoe de role meerdere keren gedeployed kan worden.
Het gaat mij om de controle niet alleen om de Jinja2 syntax van het template, maar ook om het resultaat van de compose file na templating.
Ik zie nu dat ansible.builtin.template ook een validate parameter heeft en dat deze een tmp locatie gebruikt. Je zou daar ook docker compose config in kunnen doen, toch?
Heb jij die bewust niet gebruikt en 'm als aparte stap opgenomen?
Het leek mij ook onoverzichtelijk maar al speurende door de docs kwam ik deze opties tegen. Het ging toen met name om hoe ik in de test-uitvoer bepaalde zaken anders moest doen of over moest slaan. Denk aan een stub CA voor Let's encrypt + Traefik bij het uitvoeren van Molecule.
Ik vind persoonlijk één compose file ook veel overzichtelijker dan allemaal losse stukjes, dus daarover zijn we het eens
.Ja, dat is ook mijn aanpak.Klinkt als een mooie stap
[ Voor 3% gewijzigd door blackd op 15-03-2026 15:06 ]
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Zo heb ik het ook gedaan
. Ik wil ook nog blijven benadrukken dat mijn eigen setup ook al ruim 6 jaar oud is . Rome is ook niet in één dag gebouwd.Mij ook
. De Jinja2 syntax geloof ik wel.Zeker zou dat kunnen en het is dus inderdaad een bewuste keuze om daar een aparte stap van te maken. Althans 'bewuste' keuze. Want als je de documentatie leest kom je er direct achter waarom dat niet gaat:
En het docker compose config commando accepteert geen input path.quote: Ansible
Volgens de docs moet je dan kijken naar handling complex validation. Dat lijkt op hoe ik het doe muv de rescue en always blokken. Dat heb ik door luiheid simpelweg niet geïmplementeerd. Wederom weer iets voor op het lijstje
.Ik denk dat we het over heel veel zaken eens zijnIk vind persoonlijk één compose file ook veel overzichtelijker dan allemaal losse stukjes, dus daarover zijn we het eens
. Alleen hebben we op sommige punten een smaakverschil. Ik vind het ook super interessant om te lezen hoe jij (en anderen hier) hun Docker en bijbehorende CI omgevingen aanpakken. Ik vind het ook echt leuk om te zien dat je zoveel balletjes opgooit. Het nadeel is alleen dat ik die balletjes voor een groot deel zelf ook al had gevonden . Gelukkig veranderd er nog weleens wat en vind ik het periodiek heroverwegen een goed idee
YAML:
werkt hier perfect 1
2
3
4
5
6
7
| ansible.builtin.template: src: "compose.yaml" dest: ".." owner: ".." group: ".." mode: ".." validate: "docker compose -f %s config" |
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
👀 Hier inmiddels ook:
[...]YAML:werkt hier perfect
. Thanks @blackd Toch niet helemaal. Dit werkt niet lekker met verplichte .env bestanden. Ik ga er een combinatie van maken
.
[ Voor 14% gewijzigd door alex3305 op 15-03-2026 16:26 ]
@alex3305 Helaas, liep ik er ook tegenaan, gelukkig wezen mijn Molecule tests me hier ook op .
Het lukte mij niet om met de --env-file de reeds geplaatste .env file mee te nemen in de validatie.
Daarnaast wil je beide files rollbacken wanneer er iets mis gaat.
Dan maar een extra stap opnemen zoals jij, dit wordt vaker toegepast zo te zien.
.Het lukte mij niet om met de --env-file de reeds geplaatste .env file mee te nemen in de validatie.
Daarnaast wil je beide files rollbacken wanneer er iets mis gaat.
Dan maar een extra stap opnemen zoals jij, dit wordt vaker toegepast zo te zien.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
@blackd Ik zie dat ik hier een 'copy-paste' fout had gemaakt 
. Excuses daarvoor. Ik hergebruik workflows met een interne action, dus ik kan niet zomaar een hele workflow hier neerzetten, want dan mist er een groot stuk context.
Het linten gebeurd bij mij per commit, dus:
Bij mij werkt dit volgens mij wel zoals ik verwacht. Althans ik kan mij zo niet herinneren dat ik gek gedrag heb opgemerkt...
. Excuses daarvoor. Ik hergebruik workflows met een interne action, dus ik kan niet zomaar een hele workflow hier neerzetten, want dan mist er een groot stuk context.Het linten gebeurd bij mij per commit, dus:
YAML:
maar de deploys gaan per workflow:1
2
3
| concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true |
YAML:
Ik zag net toevallig in de documentatie ook wel een andere leuke constructie die ik eens ga uitproberen:1
2
| concurrency: group: ${{ github.workflow }} |
YAML:
Omdat mijn 'niet'-main deploys namelijk altijd een check mode zijn, zou dit dus een mooie toevoeging zijn.1
2
3
| concurrency: group: ${{ github.workflow }} cancel-in-progress: ${{ !contains(github.ref, 'main')}} |
Bij mij werkt dit volgens mij wel zoals ik verwacht. Althans ik kan mij zo niet herinneren dat ik gek gedrag heb opgemerkt...
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
@blackd Ja precies . Dan zou je zelfs nog de test als conditional kunnen opnemen, bijvoorbeeld:
. Dan zou je zelfs nog de test als conditional kunnen opnemen, bijvoorbeeld:YAML:
Dan hoef je dat ook niet elke keer als parameter mee te geven, maar wordt het standaard toch gedaan.
1
2
3
4
5
6
7
8
9
10
11
12
13
| on: workflow_call: inputs: run_test: description: "Run Molecule Test(s)" default: true required: false type: boolean jobs: test: name: Molecule if: inputs.run_test == true || inputs.check_mode == true |
Volgens mij kom ik dan in de knoei met mijn job > check, die needs: [test] ?:
@blackd Ja precies
Dan hoef je dat ook niet elke keer als parameter mee te geven, maar wordt het standaard toch gedaan.
Let op dat die /** glob geen dotfiles matched, dus een change in je .env wordt niet opgepakt.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
@blackd Goede vragen
Alhoewel ik best het e.e.a. strak heb ingericht is er bij mij ook nog ruimte voor verbetering. Met andere woorden, ik heb dat nu niet. Ik heb dat eigenlijk ook niet helemaal nodig. In ieder geval niet met mijn workflow. In principe doe ik na het wijzigen van mijn group_vars of host_vars sowieso een deploy vanaf mijn lokale workstation. Enerzijds om het te testen en direct problemen op te lossen, anderzijds omdat ik snel resultaat wil. Wijzigingen in de vars worden dus door middel van het fail fast principe snel getest.
Tegelijkertijd heb ik ook mijn vars voor een heel groot gedeelte opgesplitst per role. Simpelweg omdat ik veel liever met veel kleine bestanden werk dan met 1 grote. Want...
Ik heb het hier vaker op Tweakers verteld, maar ik ben slechtziend en heb een zichtvermogen van circa 20%. Mijn letters zijn dus ietsjes groter dan ehh gemiddeld. Om een indicatie te geven hierbij een screenshot van een gemiddeld VS Code window waarbij ik de 80 karakterlimiet heb aangewezen met een rode pijl
/f/image/fiJ0JVklSNU8OrkNoGmzQZGk.png?f=fotoalbum_large)
Dit venster neemt 75% van mijn 32" display in beslag. Een display waar ik een 25-30 centimeter vanaf zit. Verticaal passen er zo'n 40 regels op mijn scherm voordat het ophoudt. Mijn truc is overigens om code aan de structuur te herkennen en simpelweg te onthouden waar alles staat. Ik kan daardoor bijna blind (hurdur) door code heen navigeren.
Ik ben dus bijna verplicht om veel kleine bestanden te gebruiken. Sterker nog, van Traefik heb ik zelfs twee vars bestanden in mijn group_vars, één met de configuratie en de andere met de dynamische reverse proxy configuratie. In mijn group_vars heb ik daarbij de variabelen die nodig zijn voor het geheel, dus domeinnaam, middleware configuratie, ingress netwerk, etc. En in de host_vars staan alleen variabelen die nodig zijn voor die host.
Bij een check (en deployment, want dat is bij mij hetzelfde) doe ik sowieso een deploy van het playbook. In sommige gevallen de applicatie zelf, maar in andere gevallen de complete stack. Dat is een beetje afhankelijk van de applicatie en wat ik prettig vind. Ik heb dan wat Shields in mijn README die ik kan checken wat de status is en eventueel Gatus voor status. Het feest gaat sowieso niet door bij een probleem in het playbook, inclusief validatie problemen.
Ook Renovate rolt het hele playbook uit bij een versie upgrade, maar altijd in check mode in de PR. Als een check mode niet slaagt wordt het PR niet gemerged. Klaar, uit. Ik vind dat veilig genoeg.
Eigenlijk heb ik de afgelopen jaar of jaren nog geen een echte probleem deployment gehad. Behalve dan door mijn eigen gepruts. Vaak door haastigheid. Ik voel dus niet de noodzaak om dit proces nog strakker in te richten. En al helemaal niet als ik zie hoeveel runs ik heb gedaan in de afgelopen ~2 jaar:
/f/image/8KlmEVfgKNTd5n50eKzV2ymK.png?f=fotoalbum_large)
Niet om te pochen, maar dit gaat dus om ~1000 runs per maand of gemiddeld zo'n 30 per dag. Als er dan niet echt iets misgaat vind ik het wel best.
Alhoewel ik best het e.e.a. strak heb ingericht is er bij mij ook nog ruimte voor verbetering. Met andere woorden, ik heb dat nu niet. Ik heb dat eigenlijk ook niet helemaal nodig. In ieder geval niet met mijn workflow. In principe doe ik na het wijzigen van mijn group_vars of host_vars sowieso een deploy vanaf mijn lokale workstation. Enerzijds om het te testen en direct problemen op te lossen, anderzijds omdat ik snel resultaat wil
. Wijzigingen in de vars worden dus door middel van het fail fast principe snel getest.Tegelijkertijd heb ik ook mijn vars voor een heel groot gedeelte opgesplitst per role. Simpelweg omdat ik veel liever met veel kleine bestanden werk dan met 1 grote. Want...
Ik heb het hier vaker op Tweakers verteld, maar ik ben slechtziend en heb een zichtvermogen van circa 20%. Mijn letters zijn dus ietsjes groter dan ehh gemiddeld
. Om een indicatie te geven hierbij een screenshot van een gemiddeld VS Code window waarbij ik de 80 karakterlimiet heb aangewezen met een rode pijl:strip_exif()/f/image/fiJ0JVklSNU8OrkNoGmzQZGk.png?f=user_large)
Dit venster neemt 75% van mijn 32" display in beslag. Een display waar ik een 25-30 centimeter vanaf zit
. Verticaal passen er zo'n 40 regels op mijn scherm voordat het ophoudt. Mijn truc is overigens om code aan de structuur te herkennen en simpelweg te onthouden waar alles staat. Ik kan daardoor bijna blind (hurdur) door code heen navigeren.Ik ben dus bijna verplicht om veel kleine bestanden te gebruiken. Sterker nog, van Traefik heb ik zelfs twee vars bestanden in mijn group_vars, één met de configuratie en de andere met de dynamische reverse proxy configuratie. In mijn group_vars heb ik daarbij de variabelen die nodig zijn voor het geheel, dus domeinnaam, middleware configuratie, ingress netwerk, etc. En in de host_vars staan alleen variabelen die nodig zijn voor die host.
Bij een check (en deployment, want dat is bij mij hetzelfde) doe ik sowieso een deploy van het playbook. In sommige gevallen de applicatie zelf, maar in andere gevallen de complete stack. Dat is een beetje afhankelijk van de applicatie en wat ik prettig vind. Ik heb dan wat Shields in mijn README die ik kan checken wat de status is en eventueel Gatus voor status. Het feest gaat sowieso niet door bij een probleem in het playbook, inclusief validatie problemen.
Ook Renovate rolt het hele playbook uit bij een versie upgrade, maar altijd in check mode in de PR. Als een check mode niet slaagt wordt het PR niet gemerged. Klaar, uit. Ik vind dat veilig genoeg.
Eigenlijk heb ik de afgelopen jaar of jaren nog geen een echte probleem deployment gehad. Behalve dan door mijn eigen gepruts. Vaak door haastigheid
. Ik voel dus niet de noodzaak om dit proces nog strakker in te richten. En al helemaal niet als ik zie hoeveel runs ik heb gedaan in de afgelopen ~2 jaar::strip_exif()/f/image/8KlmEVfgKNTd5n50eKzV2ymK.png?f=user_large)
Niet om te pochen, maar dit gaat dus om ~1000 runs per maand of gemiddeld zo'n 30 per dag. Als er dan niet echt iets misgaat vind ik het wel best.
Met mijn vragen probeer ik te ondekken hoe jouw workflow is ingericht:
@blackd Goede vragen
Alhoewel ik best het e.e.a. strak heb ingericht is er bij mij ook nog ruimte voor verbetering. Met andere woorden, ik heb dat nu niet. Ik heb dat eigenlijk ook niet helemaal nodig. In ieder geval niet met mijn workflow. In principe doe ik na het wijzigen van mijn group_vars of host_vars sowieso een deploy vanaf mijn lokale workstation. Enerzijds om het te testen en direct problemen op te lossen, anderzijds omdat ik snel resultaat wil
. We hebben weer een overeenkomst te pakken, mijn workflow voor grote wijzigingen of nieuwe roles is ook dat ik dit op mijn laptop ontwikkel en (uiteindelijk) ga uittesten op de omgeving. Met molecule heb ik daar nog een test resource bij die ik eerder kan gebruiken. De --diff parameter is daarbij heel handig om direct bij converge te zien wat je output is (bijv. de output van een template task).
extensions/molecule/config.yml
YAML:
Conclusie is volgens mij dat jij jouw deploy-<app>.yml workflows primair hebt bedoeld voor gebruik van Renovate. Check jij hier dan nog op in de workflow, bijv. met een label in de PR? Ik laat Renovate een label plaatsen, daarmee zijn die PR's herkenbaar.1
2
3
4
5
6
7
8
9
10
| --- ansible: executor: args: ansible_playbook: - --diff - --force-handlers - --inventory=${MOLECULE_SCENARIO_DIRECTORY}/../inventory.yml env: [.snip.] |
Los van jouw beperking in zichtvermogen vind ik het zelf ook prettig om met kleine overzichtelijke eenheden te werken. Dus ik wil ook toewerken naar een config file per role.
Ik zou daar wat meer op willen in zoomen, want in jouw screenshot staan variabelen die bedoeld zijn voor de role beszel en in de tree explorer staat er een voor de role adguard_home.
Ik had die op group_vars niveau verwacht.
Ik heb het nu zo ingericht:
code:
waarbij ik de inventory.yml file heb:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| production ├── group_vars │ ├── all │ │ ├── main.yml │ │ ├── secrets.yml │ │ └── vault.yml │ ├── truenas_apps │ │ ├── authentik.yml [..snip..] │ │ └── uptime_kuma.yml │ └── truenas_host │ └── jailmaker.yml ├── host_vars │ ├── docker.yml │ ├── localhost.yml │ └── nas.yml └── inventory.yml |
YAML:
Op mijn 'docker' host draai ik alle docker compose roles.1
2
3
4
5
6
7
8
9
10
11
12
| truenas_host: hosts: nas: truenas_apps: hosts: docker: truenas_shared: children: truenas_hosts: truenas_apps: |
Ik heb dus een indirectie via een group:
docker (=host, met een IP adres, dit is een jail op de TrueNAS machine) > truenas_apps (=group)
Alle playbooks apply ik op de group, niet op de host.
Als gevolg hiervan heb ik alle role variabelen in de truenas_apps group een eigen file gegeven met de role variabelen.
In host_vars staan echt alleen host specifieke variabelen:
inventory/production/host_vars/nas.yml:
YAML:
Ik vraag me af of mijn indirectie zin heeft of dat het ook simpeler kan. Want zo te zien heb jij alle role variabelen op host_var niveau geplaatst. Klopt dat of heb ik het mis?1
2
3
4
5
| ansible_host: [..] ansible_user: [..] ansible_password: "{{ secrets.truenas_admin_password }}" ansible_become_password: "{{ secrets.truenas_admin_password }}" ansible_ssh_common_args: '[ jump host ]' |
Daarnaast vraag ik me af, ik heb compose stacks die ik 2x uitrol, dat zijn nu twee roles, maar die wil/kan ik generaliseren naar één role. Bijv. traefik en traefik_external. Die hebben allebei een aparte folder voor het compose project. Ik ontkom er niet aan om de variabele die de folder naam stuurt, in het playbook te specificeren:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| --- - name: Deploy traefik hosts: truenas_apps roles: - role: traefik vars: traefik__stack_name: traefik traefik__external: false - role: traefik vars: traefik__stack_name: traefik-external traefik__external: true [ andere variabelen die anders zijn, zoals poorten, labels ... ] |
Met 'het playbook' bedoel je jouw meta playbooks/all.yml en dat gebruik je op jouw lokale machine?
Of heb je hier ook een check/deploy workflow voor in CI?
Want wanneer je klaar bent met lokaal ontwikkelen wil je wel de lint, test, check en deploy ook uitvoeren en testen of je checkin compleet is. Hoe maak je dan het onderscheid tussen de overige deploy workflows die voor Renovate gebruikt worden?
Wat bedoel je met een versie upgrade? Bedoel je hiermee dependencies zoals ansible-core, python, collections en external-roles?
Ik zie de volgende stromen aan changes in mijn repo voorbij komen:
- Docker image upgrades, getriggerd door Renovate, onderdeel van een role.
- Package updates (docker-ce, apt packages, dat soort dingen), getriggerd door Renovate, onderdeel van een (externe) role.
- Core updates (ansible-core, python, roles, collections), onderdeel van mijn execution environment, getriggerd door Renovate vanuit mijn andere repo.
- Development updates (pre-commit, ansible-lint, renovate-cli, ...), getriggerd door Renovate, onderdeel van andere files in mijn repo (pre-commit-config.yml, etc.).
- Renovate reconfigure
- Workflow aanpassingen
- Feature/Fix PR's, getriggerd door mijzelf, aanpassingen in al het bovenstaande mogelijk.
Flow 1 heb ik nu met de deploy-<role>.yml workflows wel goed ingericht, maar de overige flows wil ik nog kijken of ik dat wat strakker kan inrichten.
Ik de laatste tijd eigenlijk ook niet, maar ik kom van Semaphore UI, daarna Woodpecker CI en nu Github Actions. Ik heb de afgelopen tijd wel e.e.a. aan wijzigingen doorgevoerd om sneller feedback te krijgen door meer te linten en testen. Ik ben afgestapt van Semaphore UI vanwege de inflexibiliteit van de run omgeving (de container waar je playbook draait) en de keuzes die ik toen had gemaakt (bitwarden integratie) wat heel lastig op te zetten was. Woodpecker CI was daar al wat beter in, maar toen ging ik ook Github Actions gebruiken en dan is de wisselwerking niet te doen (bijv. check mode afhankelijk van een job test). Daarom helemaal over naar Github Actions. Tot nu toe gaat dat goed, maar de job moet niet te groot zijn. Ik heb de eerste 'out of disk space' al gehad bij een Molecule test met alle scenario's.
Ik gebruik nu dus Github Actions, deels de Github runners en deels lokaal. Als ik een grote refactoring doe, kom ik makkelijk aan de 2000 minuten/maand (=limiet). Ik heb vorige maand ook 900 jobs gedraaid, 1600min en dan doe ik niks geks.
Mijn initial commit van deze repo was Dec 2024. Ik ben ergens in Jun 2024 met Ansible gestart, dat was om Pi-Hole in een HA cluster te draaien. Mijn job is wel in de IT maar als software engineer, dus ik doe dit puur voor de hobby.
Is het al tijd voor een 'Ansible Automation' topic
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Yes. En ik krijg inzicht in hoe jij het doet:
Met mijn vragen probeer ik te ondekken hoe jouw workflow is ingericht
. Tegelijkertijd is het ook niet verkeerd om hier kritisch over te blijven denken. Dank daarvoor.Primair is misschien niet het juiste woord. Primair is het voor alle deployment, maar als ik iets in mijn vars verander dan test ik dat wel eerst met een deployment vanuit mijn lokale host voordat ik dat vanuit CI uitrol. Aangezien een CI deploy bij mij altijd wordt uitgevoerd bij een commit naar main, wordt dus de deployment dus altijd idempotent herhaald.
Ik plaats zeker labels
. Ik heb een eigen label sync action gebouwd zodat ik labels in een yaml bestand kan managen. Op het moment dat ik deze yaml wijzig, worden de labels geüpdatet. Vanuit Renovate voeg ik dan de juiste labels bij PR's toe::strip_exif()/f/image/8t1hhHfCXP6MTJrY7Jg9RBsL.png?f=user_large)
In principe krijgen Renovate PR's altijd de labels CI en maintenance.
Dat heb je mis
.De connection parameters zoals ansible_user, ansible_host, etc. heb ik in mijn inventory opgenomen.
In mijn group_vars staan variabelen die voor heel de groep gelden. De meeste van mijn applicaties zijn Docker applicaties dus de meeste van mijn group_vars bevinden zich bij mij in de docker group. Wellicht dat ik dat nog een keer splits. Pak ik dan home_assistant.yml in mijn docker group_vars, dan heb ik daarin bijvoorbeeld het domein en netwerk staan waarin de Home Assistant applicatie zich bevindt.
In de host_vars van mijn primaire host heb ik ook een home_assistant.yml waarin ik o.a. de cpuset configureer Dit is namelijk host afhankelijk. Op de secundaire host heb ik ook een home_assistant.yml waar ik mijn Zigbee en Z-Wave adapter heb ingesteld. Wederom is dit host afhankelijk. Dit zou je ook in een eigen yml kunnen doen.
Ik heb geen rollen die ik twee keer naar dezelfde host uitrol. Als ik dat wel heb, pas ik inderdaad de variabelen van 1 role aan.
Nee, het playbook van de applicatie die ik aan heb gepast. Het all playbook gebruik ik nauwelijks.
Niet? Dat is gewoon dezelfde workflow. Ik gebruik wel een pre-commit hook voordat ik alles commit.
Ook. Maar ik bedoel hiermee de applicatie uit Docker Compose.
Ik zie dat toch net anders. Ik heb 1 flow per Compose applicatie of stack. Op het moment dat er een stack aangepast wordt, wordt deze in check mode uitgevoerd en uiteindelijk deployed. Alle andere tooling die daaronder zit komt automatisch mee en wil ik dus niet apart testen. Met andere woorden: dat geloof ik wel. Omdat ik toch fail fast gebruik zie ik problemen snel genoeg.
En mocht er toch een onderdeel problemen geven, dan wordt de applicatie niet deployed. Enerzijds omdat waarschijnlijk eerder in het proces het probleem al ontstaat, anderzijds omdat de check mode dan sowieso faalt en het PR niet wordt gemerged.
Ook wil ik alles zsm deployen, wederom vanwege4 fail fast, maar ook omdat Ansible idempotent hoort te zijn. Zijn er dus constant changes, dan gaat er waarschijnlijk iets anders mis.
Eerder iets over CI / homelab / selfhostingIs het al tijd voor een 'Ansible Automation' topic
.
@alex3305 Thanks voor je reactie, je zet me aan het denken m.b.t. de workflow strategie.
Ik denk dat ik dit alles even moet laten bezinken en verder moet gaan met de playbooks gaan opknippen met de juiste path mapping en de juiste roles applyen.
Want het risico wat ik zie met opknippen en niet het main.yml playbook te gebruiken is dat je iets mist met je checkins en niet uitrolt, zodat je omgeving niet (compleet) in de desired state is. Maar misschien is dat een gevoel wat nu ontstaat door dit opknippen en dat er straks niks meer aan de hand is.
Daarnaast zit ik nog te puzzelen (in mijn hoofd) hoe ik bepaalde generieke (externe) rollen goed moet organiseren en laten triggeren door Renovate. Bijv. voor docker gebruik ik geerlingguy.docker en daarmee kan ik de docker-ce version configureren. Dat is nu een group variable, dus dan moet het docker-ce playbook daarop triggeren. Vandaar mijn vragen over host_vars en group_vars.
Ik denk dat ik dit alles even moet laten bezinken en verder moet gaan met de playbooks gaan opknippen met de juiste path mapping en de juiste roles applyen.
Want het risico wat ik zie met opknippen en niet het main.yml playbook te gebruiken is dat je iets mist met je checkins en niet uitrolt, zodat je omgeving niet (compleet) in de desired state is. Maar misschien is dat een gevoel wat nu ontstaat door dit opknippen en dat er straks niks meer aan de hand is.
Daarnaast zit ik nog te puzzelen (in mijn hoofd) hoe ik bepaalde generieke (externe) rollen goed moet organiseren en laten triggeren door Renovate. Bijv. voor docker gebruik ik geerlingguy.docker en daarmee kan ik de docker-ce version configureren. Dat is nu een group variable, dus dan moet het docker-ce playbook daarop triggeren. Vandaar mijn vragen over host_vars en group_vars.
Al eens naar een merge-queue gekeken? Ik zag dat Github het wel ondersteunt, maar alleen voor betalende klanten of openbare repo's. Voor Forejo staat een feature request open zag ik.:
Nu heb ik namelijk regelmatig 3 - 5 Renovate PR's openstaan, terwijl ik voor digests zelfs al alleen branches gebruik
[ Voor 30% gewijzigd door blackd op 18-03-2026 12:49 ]
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
@blackd Je hebt gelijk dat het gebruik van opgeknipte playbooks risico's met zich meebrengt. Wat mij betreft is dat een trade-off tussen snelheid (development velocity) en mogelijke instabiliteit of eigenlijk beter gezegd een 'incomplete' omgeving. Ik besef me op dat moment ook dat mijn meta-playbooks uiteindelijk allemaal gebruik maken van de applicatie playbooks. De kans dat ik dus iets mis bij het uitrollen acht ik daarmee dus minimaal, immers vinden die vaak genoeg plaats.
Toen ik Ansible gebruikte op grotere omgevingen en met klanten rolde we ook vaak alleen specifieke veranderingen en/of klantapplicaties uit. En dan periodiek alles. Wat mij betreft is dat een prima verhouding, maar dat is natuurlijk een kwestie van smaak. Net zoals met veel aspecten die ik hier neerpen. Het is bijvoorbeeld ook niet verkeerd om klein te beginnen en uit te bouwen. Of een andere opzet dan de mijne te hebben. Ik vind dit fijn, jij misschien niet. Prima, toch? Ik vind het vooral belangrijk om een open blik te houden naar de opzet en mening van anderen. Daar kun je alleen maar van leren.. Dat soort dingen zou ik in een 'group_vars/docker/all.yml' zetten en daarop laten triggeren. Of wellicht 'group_vars/docker/version.yml'. Die kun je dan direct door Renovate met een yaml comment laten bijhouden. Zo'n extra file voelt misschien gaar, maar tegelijkertijd is het wel heel erg duidelijk. Immers heb ik ook een python-version bestand in mijn repo.. Ik heb er enorm veel schik in om alles zelf te hosten. Dat probeer ik dus zover als het kan. GitHub is prima, maar ik vind bijv. Copilot enorm ruk. Ook omdat ik niet alles in de cloud wil hebben...
Wat dat betreft is zo ongeveer het enige wat ik nog echt mis is een mailserver. Laatst wel naar Docker mailserver gekeken, maar ik wilde het eigenlijk achter Traefik hebben en dat ging niet. Misschien dat ik binnenkort nog eens een poging waag.
Toen ik Ansible gebruikte op grotere omgevingen en met klanten rolde we ook vaak alleen specifieke veranderingen en/of klantapplicaties uit. En dan periodiek alles. Wat mij betreft is dat een prima verhouding, maar dat is natuurlijk een kwestie van smaak. Net zoals met veel aspecten die ik hier neerpen. Het is bijvoorbeeld ook niet verkeerd om klein te beginnen en uit te bouwen. Of een andere opzet dan de mijne te hebben. Ik vind dit fijn, jij misschien niet. Prima, toch? Ik vind het vooral belangrijk om een open blik te houden naar de opzet en mening van anderen. Daar kun je alleen maar van leren
.Oh ja. Grappig genoeg heb ik die role dus zelf gebouwd en is die vrijwel gelijk aan die van geerlingguy
. Dat soort dingen zou ik in een 'group_vars/docker/all.yml' zetten en daarop laten triggeren. Of wellicht 'group_vars/docker/version.yml'. Die kun je dan direct door Renovate met een yaml comment laten bijhouden. Zo'n extra file voelt misschien gaar, maar tegelijkertijd is het wel heel erg duidelijk. Immers heb ik ook een python-version bestand in mijn repo.Goed idee, maar ik gebruik bijna geen GitHub. En aangezien het dus nog niet in Forgejo zit, gebruik ik het sowieso niet
. Ik heb er enorm veel schik in om alles zelf te hosten. Dat probeer ik dus zover als het kan. GitHub is prima, maar ik vind bijv. Copilot enorm ruk. Ook omdat ik niet alles in de cloud wil hebben... Wat dat betreft is zo ongeveer het enige wat ik nog echt mis is een mailserver. Laatst wel naar Docker mailserver gekeken, maar ik wilde het eigenlijk achter Traefik hebben en dat ging niet. Misschien dat ik binnenkort nog eens een poging waag.
Periodiek het hele playbook runnen zou een goed compromis zijn.
Ik zag ergens anders dat jij periodiek een release doet van je codebase.
Op dit moment doe ik een nightly release en dan apply ik de gehele omgeving. Dat zou ik nog steeds kunnen doen, maar misschien wat minder vaak (wekelijks bijv.).
Helemaal eens, daarom geef ik ook aan dat het misschien bij mij nog een kwestie van gewenning is.Ik vind dit fijn, jij misschien niet. Prima, toch? Ik vind het vooral belangrijk om een open blik te houden naar de opzet en mening van anderen. Daar kun je alleen maar van leren
Mijn repo is aan het groeien, ik loop al langer met de gedachtes om e.e.a. sneller te maken. Maar hoe, dat wist ik niet. Jouw aanpak met deploy per role lijkt tot nu toe een mooie oplossing en ik heb de grootste wijzigingen in mijn playbook al doorgevoerd.
Daarnaast heb ik tot nu toe bijna alles zelf geleerd wat betreft Ansible, deze discussies voeren versnelt het leerproces, dus dat vind ik erg tof!
.Hele goede suggestie, ik was al die richting op aan het bewegen. Ik heb al een group 'pkg_docker' met de hosts waarop docker draait dus een group_vars/pkg_docker/docker_version.yml vind ik een mooie, ik moet nog e.e.a. centraliseren maar de workflow voelt zo heel logisch:Oh ja. Grappig genoeg heb ik die role dus zelf gebouwd en is die vrijwel gelijk aan die van geerlingguy
YAML:
Een renovate yaml comment had ik al voor elkaar gekregen, de docker-version string had ik al in een group var, het ging alleen om de naamgeving van de file en hoe daarop te triggeren.1
2
3
4
5
6
7
8
9
10
11
12
13
14
| name: Docker-ce on: push: branches: - main paths: - 'inventories/production/group_vars/*/docker_version.yml' pull_request: types: - opened - synchronize - reopened paths: - 'inventories/production/group_vars/*/docker_version.yml' |
Het ging mij meer om het principe van een merge queue, misschien is het ook wel op een andere manier te bereiken, weet ik niet.Goed idee, maar ik gebruik bijna geen GitHub. En aangezien het dus nog niet in Forgejo zit, gebruik ik het sowieso niet
Ik vind self-hosting ook heel gaaf, maar kies er wel voor bepaalde zaken bewust buiten de deur te houden.
Mijn resources op mijn server zijn beperkt (TrueNAS Scale draait op een HP Microserver Gen10 met 16GB ram en dat laatste is een behoorlijke bottleneck).
Daarentegen is GitHub niet mijn favoriete plek om mijn broncode op te slaan. Ik had al een GitHub account ver voor de overname van Microsoft. Liever gebruik ik een EU privacyvriendelijk alternatief. Self-hosting vind ik nog wat spannend: als mijn server of docker host down is, kan ik ook niet meer bij de broncode. Het omgekeerde is natuurlijk ook waar als GitHub besluit mijn account te closen
. Maar wat me ook nog tegenhoudt is dat ik bij Woodpecker CI (wat draaide op mijn docker host) een kip-ei probleem had. Als het Playbook mijn docker-ce package ging upgraden, stopte Woodpecker CI dus ook en hield mijn Playbook ermee op. Mijn GitHub Local Runner draait op een eigen Container op mijn TrueNAS. Dan zou ik een extra Container oid moeten hebben met een git server.
Hoe doe heb jij dat ingericht?
Persoonlijk ga ik daar niet (meer) aan beginnen en is e-mail een goed voorbeeld waarvoor ik liever een privacyvriendelijk, EU-hosted alternatief zoek en daar graag voor betaal. In een ver verleden MDaemon op Windows gedraaid maar tegenwoordig pas ik daarvoor.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Yes. Ik doe een weekly release.
:strip_exif()/f/image/qJ0iNHcXnpmSQKLzlgfwdNaM.png?f=user_large)
Die wordt op zondag / maandag automatisch aangemaakt, of anders op de volgende dag mocht die gemist zijn om de een of andere reden.
Verder zijn mijn release notes niets meer dan een opsomming van commits:
Members only:
Deze release doe ik voornamelijk om bij te kunnen houden waar er iets is gebeurd of eventueel misgaat. In principe zit alles in commit logs, maar ik vind dit mij net wat meer inzicht geven.
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
Daarnaast heb ik tot nu toe bijna alles zelf geleerd wat betreft Ansible, deze discussies voeren versnelt het leerproces, dus dat vind ik erg tof!
SameMisschien flauw, maar waarom pkg_docker? Een eigenschap van de host is toch docker of containers en niet de package containers? Ik heb ook een group dns (of dns_server) bijvoorbeeld, die zou ik ook AdGuard Home kunnen noemen of pkg_adguardhome of container_adguardhome, maar dat vind ik niet beschrijvend genoeg en misschien ook niet helemaal de waarheid als het dns servers zijn, want het zou ook Pi-Hole kunnen zijn.
Wat ik daarmee vooral bedoel te zeggen is dat ik dus een bewust onderscheid maak ik naamgeving en merk in rollen. Immers zijn dat de pakketten die AdGuard Home of Pi-Hole installeren én de functionele groepen in de inventory. Bijvoorbeeld dns of dns_server. Waarbij dns bij mij beschrijvend genoeg is. Omdat alle machines al een dns client hebben en dat dus niet apart benoemd hoeft te worden.
Docker is in mijn geval vergelijkbaar met Luxaflex, wat eigenlijk gewoon lamellen zijn
. Onder water zal het me roesten welke container technologie er draait, als ik maar zeker weet dat wanneer ik een container deploy deze daadwerkelijk opstart. Zo heb ik dus ook de groepen ci en git. Maar ook zigbee, thread en zwave. Dan kies ik er namelijk bewust voor om een host met een compatibel dongle in de juiste groep te zetten.Ik bedoelde het niet vervelend. Het concept is me bekend en zou prachtig zijn, maar ja, als het er niet in zit kan ik het ook niet gebruiken
.Ik heb jaren met een J4105 gespeeld en later ook een J1800 in een NAS. Ik weet hoe het is om met beperkte riemen te roeien
. Forgejo en Gitea zijn gelukkig heel lichtgewicht. Het kan geen kwaad om een push of pull mirror te hebben. En laat die functionaliteit nou standaard in beide pakketten zitten . Dan hoef je nog geen CI te gebruiken.Mja same. Ik heb niet zoveel tegen Microsoft, maar ik vind Copilot / AI die mijn code analyseert en daar gratis mee leert geen heel prettig gevoel.
Codeberg
of GitLab zijn dan goede alternatieven.Dan moet je zorgen dat je server of Docker niet down isSelf-hosting vind ik nog wat spannend: als mijn server of docker host down is, kan ik ook niet meer bij de broncode. Het omgekeerde is natuurlijk ook waar als GitHub besluit mijn account te closen
. Duidelijk een skill issue 
. Nee joh, slap geouwehoer.Ik maak met Kopia incrementele, versleutelde, de-duplicerende backups van mijn data en daar kan ik, zo heb ik inmiddels geleerd, goed op vertrouwen. Ik maak periodiek ook koude kopieën en de data schrijf ik weg naar een remote server en een Drive. Daarnaast heb ik uiteraard een kopie van mijn Git repo op mijn workstation. Kwijtraken zal mij dus niet bijster snel overkomen. En herstel heb ik al meermaals uitgetest.
Dat is bij mij ook nog een heikel punt. Ik heb daar wel over nagedacht en kwam tot een paar oplossingen:
- Uitvoeren vanaf mijn workstation
- Host A Host B laten updaten en daarna vice-versa
- Tijdelijk een extra container opzetten, de build afbreken, starten in de tijdelijke container en weer weggooien
- Permanent een container laten draaien voor updates
Hier hetzelfde qua release notes.
Maar doe jij dan ook die periodieke uitrol?
Sorry voor je relaas en ik snap je helemaal, maar ik had al een host genaamd docker en wilde geen name collisions.
Dat is best interessant, dat ga ik eens onderzoeken.Ik heb jaren met een J4105 gespeeld en later ook een J1800 in een NAS. Ik weet hoe het is om met beperkte riemen te roeien
Hier moet ik nog wat mee, dat is ook de reden dat ik geen Immich draai maar een dienst afneem.
Ik zou ook paperless willen draaien, maar dan moet ik wel de backup strategie strak in orde hebben.
Ik had Woodpecker op een gegeven moment uit de playbook gehaald met tags en die update ik vanaf mijn pc. Dat ging goed. Maar docker is een ander verhaal.
De Github runner update zichzelf. In de container draait verder niet zoveel.
Dus op dit moment houd ik die container buiten schot wat betreft de playbooks.
Misschien is ansible-pull ook nog een alternatief?
Door met een scheduled task op de machine zelf het playbook uit te voeren.
Ik heb het verder nog niet gebruikt, dus misschien sla ik de plank compleet mis.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Nee, nog niet. Dat is 's nachts en ik doe geen uitrollen 's nachts.
Wederom is dit iets wat ik op mijn lijstje heb staan, maar gewoon nog geen noodzaak voor heb gehad of niet aan ben toegekomen.
Maak je niet druk
. Ik ben tijdens mijn studie en later tijdens mijn werk doodverveeld met functional en non-functional requirements. Blijkbaar heeft het toch indruk gemaakt . Inmiddels is het een concept waar ik wat strakker aan vast houd. Het helpt dan ook als ik ergens van dienst wissel. Mijn vrouw of ik hoeven dan bijvoorbeeld geen nieuwe / andere URL te onthouden voor zoiets als de router, want dat is gewoon 'router.domein.nl' en niet 'asus.domein.nl' of 'unifi.domein.nl'.Immich en Paperless zijn twee van mijn meest gebruikte diensten
. Kopia is op zichzelf niet bijster complex om op te zetten of te beheren. Het is ook niet super fancy of zo. Van Docker applicaties neem ik over het algemeen ook gewoon snapshots mee, behalve van databases ivm WAL. Die gooi ik dan in een .kopiaignore. Van de databases maak ik overigens een dump en die neem ik dan wel mee in de backup.Ah, dat was even niet binnengekomen
. Ja, niet dus ...Zag ik laatst ook langskomen. Neem ik ook nog even mee. Dit zou mij ook nog helpen voor wat andere zaken waar ik evt. een Ansible task of play wil uitvoeren zonder dat ik direct allemaal rechten hoef toe te kennen
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Ik heb een andere backup strategie, namelijk dat TrueNAS verantwoordelijk is voor het backuppen van de data naar twee online storage providers (ook dat is nog US based en staat nog op mijn lijstje, maar goed, kan niet alles tegelijk
).Backup van mijn data op TrueNAS is dus wel geregeld, maar voor mijn docker apps nog niet. Kopia is voor mij niet perse nodig want op zich ben ik tevreden met de replicatie die in TrueNAS is ingebouwd.
Per Docker compose project heb ik grofweg de volgende structuur:
- Een folder waarin het compose project staat waar docker compose up gedaan wordt
- Een folder (met verschillende subfolders) waar alle data leeft, dit splits ik op per compose project per service, dus bijv.
code:
Wil ik een backup van authentik data, dan zou ik die authentik folder dus helemaal kunnen repliceren zodat deze wordt meegenomen in de backup van TrueNAS.1
2
3
| ..../authentik/redis/data ..../authentik/postgresql/data ..../authentik/server/media |
Maar voor de database, zoals je zelf al schetst, is dat wat uitdagender want dan moet je een db dump hebben en die meenemen in de backup.
Hoe pak jij dit aan?
Een mogelijke aanpak die ik had bedacht is om een backup playbook of task te maken die voor elke postgresql db een dump maakt. Of omgekeerd, eigenlijk zou ik per app een backup task willen hebben en dan voor alle apps de backup task willen runnen.
Veel apps hebben geen database en zijn eenvoudig te backuppen (ZFS snapshot zou voldoende zijn), maar ik heb er een paar met een eigen database. Sommige apps hebben ook een backup / export functie, denk aan de unifi controller. Dus eigenlijk wil ik dat per app afhandelen.
De stappen zijn hier beschreven met gebruik van de postgres_db Ansible module. Dat zou dan voor één app werken, dat wil ik dan doortrekken naar meerdere apps.
Of is dit bij jou onderdeel van een Kopia action?
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
@blackd Goede vraag, daar ben ik toevallig de afgelopen week mee bezig geweest .
Momenteel draai ik vanuit Unraid's crontab een script om een database dump te maken. Bijvoorbeeld:
Eerder in dit topic heeft @Mars Warrior aangegeven dat hij een DB Backup container gebruikt en die richting wilde ik eigenlijk ook op. Echter ben ik de afgelopen week met Ofelia bezig geweest.
Ofelia is een relatief simpele task scheduler die gebruik maakt van Docker labels. Omdat het simpel is kost het ook weinig resources. Tegelijkertijd wil ik ook niet veel functies, behalve taken. Maar bovenstaande wordt dan dus:.
.Momenteel draai ik vanuit Unraid's crontab een script om een database dump te maken. Bijvoorbeeld:
Bash:
Dat gaat periodiek en dat gaat dus ook periodiek met de Kopia backup mee. Waarom niet vanuit Kopia zelf? Omdat Kopia dan rechten zou moeten hebben in de containers of op de host. Dat is niet iets wat ik wil.1
2
3
4
5
| # MariaDB docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql' # PostgreSQL docker exec -i paperless-ngx-database sh -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/paperless-ngx/database.sql |
Eerder in dit topic heeft @Mars Warrior aangegeven dat hij een DB Backup container gebruikt en die richting wilde ik eigenlijk ook op. Echter ben ik de afgelopen week met Ofelia bezig geweest.
Ofelia is een relatief simpele task scheduler die gebruik maakt van Docker labels. Omdat het simpel is kost het ook weinig resources. Tegelijkertijd wil ik ook niet veel functies, behalve taken. Maar bovenstaande wordt dan dus:
YAML:
Nu heb ik dit nog niet getest, maar andere tasks zoals het syncen van mijn backups en een andere database dump waarmee ik test lijken vooralsnog prima te werken 1
2
3
4
5
6
| services: mariadb: labels: ofelia.enabled: true ofelia.job-exec.home-assistant-database-dump.schedule: "35 */4 * * *" ofelia.job-exec.home-assistant-database-dump.command: "sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'" |
.
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
Excuses, ik besef me nu dat ik daar een klein beetje te summier was
.Het commando wordt inderdaad uitgevoerd in de Docker container en de dump wordt in dezelfde directory geplaatst als de database files van MariaDB of PostgreSQL. Alhoewel dat normaliter niet helemaal gewenst is, vind ik dat wel het meest praktisch. Een extra mount zou ook nog kunnen als je wat meer scheiding zou wensen.
Ik regel dan met een .kopiaignore dat de raw database bestanden niet meegenomen worden. Bijvoorbeeld bij Home Assistant:
code:
Toevallig heb ik deze setup nog niet geactiveerd voor Home Assistant, maar wel bij mijn Outline wiki en daar ziet er dat in Kopia dan zou uit:1
2
3
4
5
6
7
| config/*.log config/*.log* config/tmp_core_entity database/* database/** !database/dump.sql |
:strip_exif()/f/image/ZFLqZPHjmnBQxvmU67IvNkHm.png?f=user_large)
9000Wp o/w SolarEdge SE6K - Panasonic 5kW bi-bloc - gasloos sinds 17-7-2023
:strip_exif()/u/8422/waarschuwing.gif?f=community)
/u/298857/crop6471d9676d431.png?f=community)
:strip_icc():strip_exif()/u/476420/crop5623d9ad036cf_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/94045/crop66c1b4250e8a2_cropped.jpg?f=community)
Ik merkte in mijn CrowdSec-setup wederom dat domme gedoe dat vpatches niet tot een decision leiden omdat CrowdSec dat pas doet als een IP-adres verschillende vpatches raakt. Reden: voorkomen van false positives als een gebruiker 'per ongeluk' een vpatch raakt.
Tuurlijk. Die gaat 'per ongeluk' toegang tot een .env file oid vragen
Oftewel: duizenden onnodige Alerts...
Werd dus tijd voor een aangepaste profiles.yaml...
En hoppa, weg met die idiote onnodige rode Alert blokken
/f/image/NNOCTZqM82VuWnKIIQWODVae.png?f=fotoalbum_large)
Nu blijf ik waarschijnlijk ook weer netjes binnen de 500 alerts per maand voor het gratis account
Verder ga ik nog wat experimenteren met mTLS. Sommige apps ondersteunen dit, dus zou ik nog wat minder alerts binnenkrijgen omdat zo'n bot al helemaal geen verbinding meer kan opbouwen…
Moet wel zeggen dat adoptie traag is. Bitwarden doet er al een jaar over om het in de iOS-app te bouwen, laat staan in de Windows-app. Moeilijk hoor die paar regels code om een certificaat mee te geven. Echt heel moeilijk, en het past elke keer net niet binnen het release window
Self-hosting heeft natuurlijk niet zo veel prioriteit als de eigen stack.
Tuurlijk. Die gaat 'per ongeluk' toegang tot een .env file oid vragen
Oftewel: duizenden onnodige Alerts...
Werd dus tijd voor een aangepaste profiles.yaml...
YAML:
.1
2
3
4
5
6
7
| name: force_vpatch_ban filters: - Alert.GetScenario() == "crowdsecurity/appsec-vpatch" decisions: - type: ban duration: 4h on_success: break |
En hoppa, weg met die idiote onnodige rode Alert blokken
:strip_exif()/f/image/NNOCTZqM82VuWnKIIQWODVae.png?f=user_large)
Nu blijf ik waarschijnlijk ook weer netjes binnen de 500 alerts per maand voor het gratis account
Verder ga ik nog wat experimenteren met mTLS. Sommige apps ondersteunen dit, dus zou ik nog wat minder alerts binnenkrijgen omdat zo'n bot al helemaal geen verbinding meer kan opbouwen…
Moet wel zeggen dat adoptie traag is. Bitwarden doet er al een jaar over om het in de iOS-app te bouwen, laat staan in de Windows-app. Moeilijk hoor die paar regels code om een certificaat mee te geven. Echt heel moeilijk, en het past elke keer net niet binnen het release window
Self-hosting heeft natuurlijk niet zo veel prioriteit als de eigen stack.
Material 3 Thema's | Swiss Army Knife card | Flex Horseshoe Card
:strip_icc():strip_exif()/u/465602/crop59bbd5b6caf7a_cropped.jpeg?f=community)
Ik blijf gewoon bij Windows omdat ik er ook andere dingen bij heb. Ik wil Docker Desktop weg hebben omdat ik ondertussen wel weet dat er weinig extra bij komt kijken en ik heb het idee dat DD steeds meer verbruikt terwijl er eigenlijk weinig bij is gekomen.
Tuurlijk is een linux variant beter in het opzicht van Docker, maar op dit moment nog geen reden voor mij om over te stappen.
Daarnaast ook gewoon deze hardware nog. Is redelijk zuinig en nog prima voor ons gebruik. Nou ja, mijn gebruik haha.
Zodra docker goed draait en in gebruik is, kan ik altijd kijken naar een upgrade. Maar voor nu qua prijzen niet echt nuttig om die stap te maken.
/edit:
Ik heb nu net Docker Desktop verwijderd... Here goes nothing!
Moet toch ergens beginnen. Ben benieuwd wat het geheugen verbruik gaat doen nadat WSL2 ingesteld is met Docker.Verwijderen van DD zorgt ook voor het verwijderen van de VM met Docker erin. Ging er niet vanuit, maar had wel een backup van wat ik echt met alles erbij terug wilde hebben.
[ Voor 10% gewijzigd door Arunia op 16-06-2026 11:18 ]
@Wienen Voor zover zal het bij mij nooit een hele grote omgeving worden. Wel is me opgevallen dat het sinds een half jaar ontzettend veel verbruikt. Mits dat het gedeelte was hoor.
Qua installeren met tutorials is het niet heel erg makkelijk.
Enige wat ik zoek is WSL2, Docker en Docker-Compose met dezelfde uitkomst als middels Docker Desktop.
Alleen om één of andere reden loop je toch tegen vage problemen aan.
Docker hello-world doet het in ieder geval. Alleen nu Portainer dan nog wat ik dan het liefste via docker-compose doe, maar wellicht moet ik daar gewoon vanaf stappen.
Zodra portainer erop staat, kan ik kijken of ik daar bij kom en of het naar buiten toe in het netwerk zelf ook werkt.
Enige voordeel is dat DD dit wel automagisch doet voor je. Genoeg mensen die het zonder DD willen, maar om één of andere reden is iedere uitleg weer anders. Wellicht toch dat iedereen het anders doet.
Maar, het lijkt erop dat Portainer nu wel geinstalleerd is. Volgende stap is automatisch laten starten bij een herstart van Windows. Zelfde probleem met Docker Desktop, maar ook dat is opgelost. Startte hiervoor eerst Windows en dan een batch bestand welke Windows weer locked. >_>
Qua installeren met tutorials is het niet heel erg makkelijk.
Enige wat ik zoek is WSL2, Docker en Docker-Compose met dezelfde uitkomst als middels Docker Desktop.
Alleen om één of andere reden loop je toch tegen vage problemen aan.
Docker hello-world doet het in ieder geval. Alleen nu Portainer dan nog wat ik dan het liefste via docker-compose doe, maar wellicht moet ik daar gewoon vanaf stappen.
Zodra portainer erop staat, kan ik kijken of ik daar bij kom en of het naar buiten toe in het netwerk zelf ook werkt.
Enige voordeel is dat DD dit wel automagisch doet voor je. Genoeg mensen die het zonder DD willen, maar om één of andere reden is iedere uitleg weer anders. Wellicht toch dat iedereen het anders doet.
Maar, het lijkt erop dat Portainer nu wel geinstalleerd is. Volgende stap is automatisch laten starten bij een herstart van Windows. Zelfde probleem met Docker Desktop, maar ook dat is opgelost. Startte hiervoor eerst Windows en dan een batch bestand welke Windows weer locked. >_>
[ Voor 13% gewijzigd door Arunia op 16-06-2026 17:19 ]
Om nog even terug te komen op een onderwerp van denk ik 6 maanden geleden
Op het werk heeft men een server bijeengesprokkeld. Die is dus gratis vanuit de boekhouding gezien, maar heeft wel een 24 core Xeon, 256GB RAM, en over het 10/40GBit netwerk SSD storage
Dus dat is geregeld. Nu ging het tig maanden geleden over het inrichten van deze server. Hij draait op Proxmox + PBS. Ik ga daar 2 VMs maken:
Ik neig nu sterk naar:
Erbij:
Als ik meer controle wil hebben is Komodo ook een perfect alternatief. Die kan het bouwen van eigen containers en backuppen van databases ook overnemen. Is dat ook meteen verzorgd en hoef ik ook daar verder niks extra's voor te regelen.
Komodo kan ook met SOPS werken zodat alle .env files ook on the fly tijdens deployment gedecrypt worden. Een VScode plugin doet dat ook met decrypt/encrypt, dus dan kunnen er ook geen wachtwoorden en andere sleutels in git/forgejo komen.
Rathole zou ik dan daarbij als container kunnen gebruiken om een tunnel / bridge op te zetten, zodat ik nog zelf wel lekker met SSH en een browser (socks5) overal bij kan komen, zonder dat poort 22 open moet staan. Daar houden ze niet zo van...
Op het werk heeft men een server bijeengesprokkeld. Die is dus gratis vanuit de boekhouding gezien, maar heeft wel een 24 core Xeon, 256GB RAM, en over het 10/40GBit netwerk SSD storage
Dus dat is geregeld. Nu ging het tig maanden geleden over het inrichten van deze server. Hij draait op Proxmox + PBS. Ik ga daar 2 VMs maken:
- een VM voor GitOps
- een VM voor productie
Ik neig nu sterk naar:
- Forgejo + runner
- Renovate
- Portainer BE (gratis voor 3 nodes) met Edge Agent op de productie node. Die kan vanuit Git een compose file met alles wat daarbij hoort halen en deployen. Klaar
- Mogelijk wat extra's per container om wat scripting en testen uit te voeren in plaats van de standaard image entry, en die dan aanroepen. Ben ik van alles af. Ook geen gezeur meer met depends_on bij reboot van server.
Erbij:
Als ik meer controle wil hebben is Komodo ook een perfect alternatief. Die kan het bouwen van eigen containers en backuppen van databases ook overnemen. Is dat ook meteen verzorgd en hoef ik ook daar verder niks extra's voor te regelen.
Komodo kan ook met SOPS werken zodat alle .env files ook on the fly tijdens deployment gedecrypt worden. Een VScode plugin doet dat ook met decrypt/encrypt, dus dan kunnen er ook geen wachtwoorden en andere sleutels in git/forgejo komen.
Rathole zou ik dan daarbij als container kunnen gebruiken om een tunnel / bridge op te zetten, zodat ik nog zelf wel lekker met SSH en een browser (socks5) overal bij kan komen, zonder dat poort 22 open moet staan. Daar houden ze niet zo van...
[ Voor 24% gewijzigd door Mars Warrior op 17-06-2026 09:08 ]
Material 3 Thema's | Swiss Army Knife card | Flex Horseshoe Card
Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld
Haha, soms post ik gewoon inderdaad ter info. Dat niet altijd alles van een leien dakje gaat.:
[...]
Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld
Maar het lijkt nu wel te werken, ook na een Windows herstart komt bijvoorbeeld Portainer weer op. Dus, Mijn WSL2 start automatisch en daarin Docker ook. Kostte wat moeite om de juiste uitleg te vinden.
Nu nog wat dingen fixen en het liefste had ik eigenlijk bepaalde mappen op Windows beschikbaar gehad, maar het is wat het is. Denk ook gewoon gewenning. Ik weet hoe het werkt en kan straks ook bepaalde media mappen beschikbaar maken.
Op dit moment heb ik het maximum geheugen gebruik op net geen 1100MB staan in .wslconfig.
De kans is zeer groot dat dat nog best veel is, maar dan zou er heel veel geheugen standaard in gebruik zijn. Dat is iets wat ik wel raar vind.
Qua containers heb ik Portainer, Mealie en Rustdesk draaien. Daar komen er nog wel meer bij, maar ik moet even uit zien te vogelen of ik het geheugen gebruik van de containers kan zien. Dit bedenk ik me aan de hand van je bericht natuurlijk, dus nog niet gezocht hierop.
Heb al even gekeken en het lijkt nog ruim onder de 1100MB te zitten. Mealie verbruikt wel verreweg het meeste.
Ben nu Dozzle aan het instellen om zo grafische inzicht te krijgen.
:strip_exif()/f/image/rhiYShnRIwE8QuJgLbAreGSb.png?f=user_large)
[ Voor 22% gewijzigd door Arunia op 03-07-2026 09:38 ]
:strip_exif()/f/image/l9nZngfT8sB2jqR0zI6oVs8m.png?f=user_large)
Ik heb hier al eens meer naar gekeken en lijkt ook niet alsof WSL2 en docker het probleem is, maar kom er ook niet achter wat nu precies zoveel verbruikt. Er zijn wat losse programma's die draaien. Deze wil ik langzaamaan verplaatsen naar Docker. Twijfel nog over Plex, maar wellicht die ook.
Crashplan, WSL, Zulu verbruiken wel het meeste. Waarom Edge erbij staat is mij een raadsel. Ja, die heb ik soms open voor uitleg en dergelijke, maar nu was deze afgesloten.
Los van elkaar lijkt het allemaal niet zo heel veel, maar opgeteld loopt het wel hard op denk ik.
Maar met 16GB aan ram zou ik toch wel voldoende moeten hebben. Hiervoor had ik 8GB enkele DIMM en eigenlijk geen problemen. Alles is wel standaard geupdate.
Verkijk je je misschien op wat er voor cache en andere "gebruik geheugen als beschikbaar" taken gebruikt wordt? Ik heb eenzelfde soort actieve taken lijst die niet optelt tot mijn totale geheugengebruik.....
:strip_exif()/f/image/bM83GkAHSsaJicm2lsv19bK6.png?f=user_large)
:strip_exif()/f/image/dpjcTfNc8ed1Yww8cuvWEfTo.png?f=user_large)
Dit heb ik zeg maar. Jij hebt ruim meer geheugen dan dat ik heb en qua in gebruik zitten we op hetzelfde. Alleen ik heb minder totaal geheugen.
@3DDude Ik zie heel veel Java er tussen staan qua 160.000KB per onderdeel als werkset en allemaal rond de 200.000KB als Toegewezen. Kan van alles zijn natuurlijk, maar als er 20 staan is het weinig, dan telt het wel op. Dus daar moet ik verder in gaan duiken. Alhoewel ze allemaal grijs zijn en af en toe opspringen naar zwart. Geen idee wat het verder betekent, maar ook daar zal ik eens naar kijken. Ik maar overigens gebruik van Zulu Java.
WSL lijkt toegewezen op 1.118.660KB en werkset is 360KB. Die zou ik omlaag kunnen gooien, maar dan moet ik daar goed op letten dat deze niet vol loopt en ik dat niet door heb.
:strip_exif()/f/image/kVHmYCWIKf4N5A2RFAzm6aUj.png?f=user_large)
Als ik kijk naar harde fouten, dan is dat bij memory compression vooral, maar loopt ook niet op andere vlakken hard omhoog. Maar met het geheugen wat vrij hoog ligt, is het geheugen op dit moment niet echt toereikend.
@DjoeC Ik denk inderdaad dat het ook niet aan WSL2 of Docker ligt.
WSL lijkt toegewezen op 1.118.660KB en werkset is 360KB. Die zou ik omlaag kunnen gooien, maar dan moet ik daar goed op letten dat deze niet vol loopt en ik dat niet door heb.
Als ik kijk naar harde fouten, dan is dat bij memory compression vooral, maar loopt ook niet op andere vlakken hard omhoog. Maar met het geheugen wat vrij hoog ligt, is het geheugen op dit moment niet echt toereikend.
@DjoeC Ik denk inderdaad dat het ook niet aan WSL2 of Docker ligt.
[ Voor 3% gewijzigd door Arunia op 03-07-2026 16:22 ]
Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.
Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM
Material 3 Thema's | Swiss Army Knife card | Flex Horseshoe Card
Haha dan hebben we de boosdoener wellicht gevonden:
[...]
Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.
Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM
Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?
Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.
@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest
), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.
Gebruik je het voor Windows of voor Linux? Ik gebruik Backblaze Personal met onbeperkte data. De agent werkt alleen onder Windows en dus heb ik wat ingericht om de relevante Linux meuk naar een Windows disk te backuppen. Momenteel > 20TB bij hen staan, in Amsterdam. In 2024 USD 229,- betaald voor 2 jaar (incl BTW). Zal dit jaar wel een paar tientjes meer worden maar ik kan er geen schijf voor kopen. 1e backup duurde wel een dikke week, nu blijft ie op de achtergrond prima bij. Maar, er zijn een paar grotere backup topics hier in het forum.:
@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.
Aanvulling: Als je bij Backblaze eem vinkje zet bewaren ze "alle" file versies gedurende 1 jaar. Een aantal files zijn excluded maar mijn backups niet. Die bewaar ik dus een tijdje lokaal, daarna mag BB het voor mij doen. Dat scheelt bij volume backups (Acronis backup van C+D schijf) best een hoop lokale opslag.
[ Voor 8% gewijzigd door DjoeC op 04-07-2026 15:32 ]
Dat heeft te maken met een stukje historie. Voorheen kon je met CrashPlan gratis naar een andere server back-uppen. Dus een Remote back-up. Dan hebben ze dat uitgesloopt en moest je gaan betalen. Dat was in het begin behoorlijk goedkoop. Ik meen iets van € 60 terwijl ik iets van 10 terabyte had als back-up.:
[...]
Haha dan hebben we de boosdoener wellicht gevonden
Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?
Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.
Daarna is CP allerlei beperkingen in gaan voeren. En het is inderdaad zo traag als dikke stront. En het kost inderdaad veel ram geheugen. Maar mijn 128 GB ram stamt nog uit de tijd dat je daar € 300 voor betaalde 🫣
Dus ik zit wel naar een alternatief te kijken, maar dat heeft absoluut geen haast.
Material 3 Thema's | Swiss Army Knife card | Flex Horseshoe Card
:strip_icc():strip_exif()/u/149142/jfk2_60.jpg?f=community)
:strip_icc():strip_exif()/u/144633/crop643e593ea432f_cropped.jpg?f=community)