Acties:
  • 0 Henk 'm!

  • DaanHetEendje
  • Registratie: Maart 2009
  • Laatst online: 22:04
Mars Warrior schreef op vrijdag 10 oktober 2025 @ 11:26:
[...]

Red Hat is goed in het maken van dingen volgens hun eigen manier, die niet altijd compatible zijn met al bestaande applicaties, terwijl ze vaak wel claimen dat het een drop-in replacement is.

Podman is gewoon niet 100% compatible met Docker. En je krijgt garantie tot de voordeur, ondanks service contracten :+

Maar aan de andere kant is expermenteren leuk. De enige reden dat ik weet dat Podman niet compatible is met wat ik/wij gebruiken, is namelijk omdat ik er mee gespeeld heb. Maar wie weet in de toekomst is het een mooi alternatief voor het Docker eco systeem :9~
Op reddit word ik downvoted als de pest als ik benoem dat Podman absoluut geen drop-in replacement voor docker is omdat het allerlei functionaliteit mist. Maar het is gewoon de realiteit.

Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines :)

Acties:
  • 0 Henk 'm!
DaanHetEendje schreef op maandag 13 oktober 2025 @ 13:07:
Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines :)
Maar ondersteund het ook Quadlets? :+

Containers definiëren in een systemd unit file is eigenlijk best wel cool. Waarbij individuele containers dus ook kunnen wachten op specifieke zaken (ook van buiten containers dus). Ik heb nu bv Gatus draaien als "uptime checker", maar na een reboot faalt die op een aantal services die die over een VPN moet bereiken omdat de VPN nog niet up is. Met Quadlets kan ik gewoon een Wants=systemd-networkd-wait-online@wg-mesh + After=systemd-networkd-wait-online@wg-mesh toevoegen en klaar. Deze container start pas nadat deze netwerk interface online is. Met Docker kan ik dat niet. Dan zou ik met het handje een docker run ... in een systemd service moeten plaatsen incl goed uitzoeken hoe om te gaan met zaken als stoppen, bijhouden active state, etc (en uiteraard niet Dockers restart optie gebruiken) zodat ik specifiek die unit de afhankelijkheid kan geven. Want uiteraard kan/wil ik niet de hele Docker daemon de afhankelijkheid van één enkele container geven.
Maar dus ook uberhaupt dat alles veel meer "native" voelt. Een container starten/stoppen kan gewoon met systemctl restart gatus bv. Logging gaat automatisch naar de system logs (journald, en dus doorzoekbaar met bv journalctl -u gatus). Standaard monitoring tools voor systemd nemen dus automatisch ook containers mee (of de service aka container wel active is, logging dan, ...).

Dus nee, ik ben niet getrouwd met Podman of vind het super vet cool omdat het van Red Hat is. Maar Quadlets is wel een feature waar ik de voordelen van in zie en die AFAIK geen enkel alternatief heeft.

Acties:
  • 0 Henk 'm!

  • Shivs
  • Registratie: Januari 2010
  • Niet online
DaanHetEendje schreef op maandag 13 oktober 2025 @ 13:07:
[...]
Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines :)
Hoewel ik snap dat je niet met Podman wilt werken, heb je zeker wel Red Hat meuk op je machines. De kernel wordt mede door Red Hat ontwikkelt, dus je komt er niet echt onderuit ;) (https://insights.linuxfou...project/korg/contributors)

Acties:
  • 0 Henk 'm!
RobertMe schreef op maandag 13 oktober 2025 @ 15:41:
[...]

Maar ondersteund het ook Quadlets? :+

Containers definiëren in een systemd unit file is eigenlijk best wel cool. Waarbij individuele containers dus ook kunnen wachten op specifieke zaken (ook van buiten containers dus). Ik heb nu bv Gatus draaien als "uptime checker", maar na een reboot faalt die op een aantal services die die over een VPN moet bereiken omdat de VPN nog niet up is. Met Quadlets kan ik gewoon een Wants=systemd-networkd-wait-online@wg-mesh + After=systemd-networkd-wait-online@wg-mesh toevoegen en klaar. Deze container start pas nadat deze netwerk interface online is. Met Docker kan ik dat niet. Dan zou ik met het handje een docker run ... in een systemd service moeten plaatsen incl goed uitzoeken hoe om te gaan met zaken als stoppen, bijhouden active state, etc (en uiteraard niet Dockers restart optie gebruiken) zodat ik specifiek die unit de afhankelijkheid kan geven. Want uiteraard kan/wil ik niet de hele Docker daemon de afhankelijkheid van één enkele container geven.
Maar dus ook uberhaupt dat alles veel meer "native" voelt. Een container starten/stoppen kan gewoon met systemctl restart gatus bv. Logging gaat automatisch naar de system logs (journald, en dus doorzoekbaar met bv journalctl -u gatus). Standaard monitoring tools voor systemd nemen dus automatisch ook containers mee (of de service aka container wel active is, logging dan, ...).

Dus nee, ik ben niet getrouwd met Podman of vind het super vet cool omdat het van Red Hat is. Maar Quadlets is wel een feature waar ik de voordelen van in zie en die AFAIK geen enkel alternatief heeft.
Ik heb wel eens een container gedraaid die dat soort zaken kon checken, dus of bijv. VPN/Netwerk op is, en pas DAARNA naar healthy gaat.

Als je dan een depends on doet in de andere container op basis van "healthy", dan kun je via een omweg toch bereiken wat jij wilt.

Het is wel één van de dingen die Podman tracht op te lossen, naast dat ze zich eerder richten op Kubernetes, dan Docker Swarm of Docker Compose.

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs


Acties:
  • 0 Henk 'm!

  • I-Lynx
  • Registratie: April 2008
  • Laatst online: 21:37
I-Lynx schreef op zaterdag 4 oktober 2025 @ 10:33:
Ik heb ondertussen weer wat tijd gehad om te proberen.

De bios instellingen van @Bontje Blauw over genomen.
Dat gaf geen merkbaar verschil.

Daarna alle onderdelen stuk voor stuk eruit gehaald en weer terug geplaatst.
De basis was 24 watt.
Zonder Netwerkkaart: 18 watt.
Zonder Netac SSD: 15 watt
We zijn weer een ruime week verder.
Het systeem draait nu volledig.
De netwerkkaart en Netac SSD zijn eruit. De SSD is vervangen voor een 2e WD Green 512gb SSD die ik nog had liggen.

Zoals in mijn vorige post gemeld komt het idle verbruik met alle apparatuur aan, zonder VM's en Containers in Proxmox rond de 15 watt.

Nu alles VM's en containers draaien is het verbruik toegenomen tot ongeveer 35 watt.
Er draait nu het volgende:
VM: pfSense
VM: Home Assistant
VM: Open Media Vault
CT: Omada controller
CT: Frigate.

De containers heb ik voor zover mogelijk op de E-Cores ingesteld.
Ook Frigate draait op de E-Core's.

Dit is mijn Powertop:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   4.3%        3.3%
                    |                     | POLL        0.0%    0.1 ms  0.0%    0.1 ms
                    |                     | C1_ACPI    17.9%    0.2 ms  3.9%    0.1 ms
C2 (pc2)    0.0%    |                     | C2_ACPI    33.7%    0.4 ms 13.6%    0.6 ms
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    | C3_ACPI    43.8%    1.6 ms 79.0%    5.8 ms
C6 (pc6)    0.0%    | C6 (cc6)    2.7%    |
C7 (pc7)    0.0%    | C7 (cc7)   15.8%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   4.3%        1.2%
                    |                     | POLL        0.1%    0.1 ms  0.1%    0.1 ms
                    |                     | C1_ACPI    20.8%    0.2 ms  4.4%    0.2 ms
                    |                     | C2_ACPI    36.0%    0.4 ms 15.5%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    39.1%    1.5 ms 78.8%    5.6 ms
                    | C6 (cc6)    1.1%    |
                    | C7 (cc7)   10.4%    |
                    |                     |
                    |                     |
                    |                     |

Zelfs met alleen pfSense VM (als ik die uitzet dan hebben we geen internet meer en heb ik ruzie thuis 8) ) blijft bovenstaande het zelfde.

Ik doe dus iets fout.... maar wat...
Het enige wat qua hardware veranderd is, is dat de USB > Serial devices voor Z-Wave, P1 meter en UPS zijn ingeplugd.

Al met al is het totale verbruik van de oude situatie (Chineese router, Synology nas etc) gedaald van 90watt naar 50 watt (server plus PoE Switch).
Dus het is al wel een verbetering maar het kan beter.

Nog een kleine test:
Alleen pfSense en Home Assistant draaien: 30 watt.
Omada controller erbij: 32 watt
OMV erbij: 32 watt
Frigate erbij: 35 watt. Afhankelijk of de camera's beweging detecteren.

We gaan nog wat stoeien met E-Cores.

Acties:
  • 0 Henk 'm!

  • Appesteijn
  • Registratie: Juni 2001
  • Niet online
I-Lynx schreef op maandag 13 oktober 2025 @ 21:37:
[...]

We zijn weer een ruime week verder.
Het systeem draait nu volledig.
De netwerkkaart en Netac SSD zijn eruit. De SSD is vervangen voor een 2e WD Green 512gb SSD die ik nog had liggen.

Zoals in mijn vorige post gemeld komt het idle verbruik met alle apparatuur aan, zonder VM's en Containers in Proxmox rond de 15 watt.

Nu alles VM's en containers draaien is het verbruik toegenomen tot ongeveer 35 watt.
Er draait nu het volgende:
VM: pfSense
VM: Home Assistant
VM: Open Media Vault
CT: Omada controller
CT: Frigate.

De containers heb ik voor zover mogelijk op de E-Cores ingesteld.
Ook Frigate draait op de E-Core's.

Dit is mijn Powertop:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   4.3%        3.3%
                    |                     | POLL        0.0%    0.1 ms  0.0%    0.1 ms
                    |                     | C1_ACPI    17.9%    0.2 ms  3.9%    0.1 ms
C2 (pc2)    0.0%    |                     | C2_ACPI    33.7%    0.4 ms 13.6%    0.6 ms
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    | C3_ACPI    43.8%    1.6 ms 79.0%    5.8 ms
C6 (pc6)    0.0%    | C6 (cc6)    2.7%    |
C7 (pc7)    0.0%    | C7 (cc7)   15.8%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   4.3%        1.2%
                    |                     | POLL        0.1%    0.1 ms  0.1%    0.1 ms
                    |                     | C1_ACPI    20.8%    0.2 ms  4.4%    0.2 ms
                    |                     | C2_ACPI    36.0%    0.4 ms 15.5%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    39.1%    1.5 ms 78.8%    5.6 ms
                    | C6 (cc6)    1.1%    |
                    | C7 (cc7)   10.4%    |
                    |                     |
                    |                     |
                    |                     |

Zelfs met alleen pfSense VM (als ik die uitzet dan hebben we geen internet meer en heb ik ruzie thuis 8) ) blijft bovenstaande het zelfde.

Ik doe dus iets fout.... maar wat...
Het enige wat qua hardware veranderd is, is dat de USB > Serial devices voor Z-Wave, P1 meter en UPS zijn ingeplugd.

Al met al is het totale verbruik van de oude situatie (Chineese router, Synology nas etc) gedaald van 90watt naar 50 watt (server plus PoE Switch).
Dus het is al wel een verbetering maar het kan beter.

Nog een kleine test:
Alleen pfSense en Home Assistant draaien: 30 watt.
Omada controller erbij: 32 watt
OMV erbij: 32 watt
Frigate erbij: 35 watt. Afhankelijk of de camera's beweging detecteren.

We gaan nog wat stoeien met E-Cores.
Toevallig ook vorige week geprobeerd om een vergelijkbare setup met opnsense en Home Assistant met een USB P1 meter en een USB Zigbee eraan in C1 of beter te krijgen. Niet gelukt.

Lang verhaal kort:
De USB devices en het netwerkverkeer zorgden ervoor dat het systeem niet in C1 kwam. P1 meter nog wel vervangen door een Esphome-Wifi versie, maar dat mocht niet baten.
Pagina: 1 ... 116 117 Laatste