Reprise du message précédent :

LVM, j'avais (mal?) compris qu'il fallait formater le disque et qu'il faisait une sorte d'énorme partition dans son format.  
Donc que ce passe t'il si un disque grille ? Il arrive a fonctionner avec 4 disques sur 6 ?  
 

C'est la solution, que j'ai retenu pour l'instant mais je trouve que cela fait un poils fouillis.  
J'espérais trouver un truc un peu magique.  
 
 

Je vais me renseigner  
 
merci pour les réponses en tout cas.

Unraid, j'ai du mal a comprendre la proposition.  
C'est un OS complet et payant.  
Sur la papier, il est carrément sexy. Mais quel avantage par rapport à une débian + KVM ? Le passtrought est mieux intégré ?  
Il gère par défaut l'aggrégation de disque. Ce ne serait pas du mergefs déguiser ?  

Ce n'est pas vraiment ça. Enfin si, d'un point de vue très bas niveau on peut voir les choses comme ça, mais ce n'est pas une partition au sens filesystem. Il faut comprendre que LVM c'est une couche d'abstraction entre les disques physiques et les partitions au sens filesystem.

En gros le process c'est :
- tu définis ton disque physique comme un physical volume (PV) pour le mettre à disposition de LVM
- tu regroupes tes physical volumes dans des volume group (VG), par exemple dans ton cas tu pourrais avoir un VG qui contient ton/tes SSD et un autre qui contient tes disques
- tu peux ensuite créer tes logical volumes (LV) qui porteront tes partitions/FS, en choisissant dans quel VG tu mets chaque LV. Chaque LV peut être simple, mirrored (équivalent du RAID 1 sur un ou même plusieurs disques), ou striped (équivalent de RAID0 sur un ou plusieurs disques).
- enfin, tu peux créer tes partitions (ext4 ou autre) dans tes LV (souvent une partition par LV parce que c'est le plus logique, mais rien n'empêche d'en avoir plusieurs, ça ne regarde pas LVM)

Un LV peut être étendu après sa création (il faut ensuite étendre la partition qu'il contient), ça se fait à chaud en quelques instants.
On peut aussi transformer un LV simple en LV mirrored à chaud (là bien sûr il faut un certain temps pour que les données soient dupliquées, mais le FS reste utilisable pendant ce temps).
Chaque LV peut aussi être backupé à chaud dans un fichier avec un simple dd.

J'veux faire le même projet : https://dnhkng.github.io/posts/hopper/

Unraid a un système propre avec une parité en temps réel ce qui veut dire qu'a chaque modification la parité est mise a jour, contrairement a mergeFS ou c'est toi qui dit quand tu veux la mettre a jour (j'ai du mal a comprendre ce principe et ce que tu perds quand tu as modifié plein de truc )
Après tu as la gestion de cache sur un SSD que tu vas attribué ou non a chaque partage que le "mover" va transférer selon un planning sur le disque.
 
Enfin l'os est payant, il ne fait surement pas forcément plus qu'une configuration poussé d'un debian/ubuntu mais tout ce que tu demandes est déjà de base dans une interface sympa donc de mon point de vue la licence vaut le temps que tu économisera en prise de tête. (mais tu fais comme tu veux ^^, perso mon choix a été vite fait)

Pour la puissance ça me parait pas "si chère" non ?

Clairement, le mec a pu se faire pour 9K une config à 88K, un banger, par contre il a dû mettre fortement la main à la pâte et vu les détails ça n'est clairement pas à la portée de tout le monde...

Après ça aurait aussi pu être un scam (mais bon, il avait déjà une rig de 4x 4090 donc pas trop dans le besoin, surtout pour prendre le risque de payer 9K pour un projet risqué)

J'entends ce que tu dit et la présentation est clairement sexy. Mais a l'instant T, si je dois mettre 1€ dans le truc c'est pour avoir de la souplesse sur l'espace disque.
Là je crains d'aimer le concept et de finir bloqué bêtement sur une connerie dans 6 mois.

 
ça me chaufferait bien
 

 
Je vois pas trop sur quoi tu peux être bloqué mais bon ^^, j'ai tout en docker, j'ai des VM et j'ai aucun souci ^^ Après tu fais comme tu veux
J'ai plus de 40 container docker (Domotique, serveur de jeux, etc ..), des VMS, 5 disques (dont un de parité) et 2 SSD en cache en ZFS miroir, j'avais même mis un routeur logiciel en VM sans aucun souci.
 
Edit : a ce jour je ne connais pas de personne ayant migré sur Unraid ayant fait machine arrière ^^

Clairement, si un jour je me remotive pour un NAS (actuellement en multi-cloud) ça sera avec unraid !

Fouillis ? Pourquoi donc ? C'est fondé sur fusefs qui est rock solide. Il y a de nombreuses solutions fondées sur ce FS, tu n'as pas à t'inquiéter. Perso, je trouve justement que ça ne manque pas de magie au contraire  

Unraid est payant et je ne serais pas surpris que ce soit fusefs derrière  

Moi  
Mais pour d'autres raisons : j'ai profité du BF l'année dernière pour me payer une licence et je me suis rendu compte après coup que unraid n'acceptait pas des disques déjà remplis de données ie il est impératif de formater les disques pour qu'ils soient utilisables. C'était un no-go absolu pour moi...

Ce n'est plus le cas depuis la 7.2

On peut même mixe NTFS, zfs, xfs dans le même array j'ai vu ça

hello
 
Avec ces solutions (unraid et/ou LVM) : comment est ce que vous savez, quand vous posez un fichier, sur quel disque physique il se trouve ?
Si vous perdez un disque (panne matérielle), comment est ce que vous savez quel sera l'impact ?
Et si vous prenez un disque et que vous le branchez ailleurs, vous voyez quoi de l'autre coté ?
 

 
Si t’as bien fait les choses, normalement l’impact n’est que pécunier et temporel car t’as fait une sauvegarde.  

 
non mais quand tu fais un LVM sur plusieurs disques, c'est plus ou moins équivalent à un raid 0 / JBOD ?
Donc si un disque lâche, tu perds tout ?
 
Je suis d'accord avec la sauvegarde, mais on ne sauvegarde pas forcément tout (notamment les films de vacances et d'autres vidéos qui prennent beaucoup de place...).
 

 
Tu sais dans quelle partition est ton fichier, tu sais dans quel LV tu as créé ta partition, tu sais dans quel VG tu as créé ton LV, et tu sais quel(s) PV (aka disques physiques) font partie de ton VG.
Tu peux utiliser la commande "pvdisplay -m" pour voir comment l'espace de chaque PV est attribué. Ça te dira qu'au début du PV il y a tel LV, ensuite tel autre LV, ensuite telle copie d'un LV mirrored, ensuite tel bout de tel LV qui ne tenait pas en entier sur ce PV, etc.
Ou pour le voir d'un point de vue LV : "lvs -a -o +devices" listera tes LV et te dira de quels PV ils dépendent.
 

 
Tous les LV non redondés portés au moins en partie sur le disque/PV concerné seront perdus. Rien de contre-intuitif à ce niveau.
 

 
Je n'ai pas essayé mais j'imagine qu'on peut faire un pvscan et qu'on retrouvera ce qui peut être récupéré, ie les LV dont l'information est entièrement contenue sur le disque en question (que ce soit des LV en mode linear qui étaient uniquement sur ce PV, ou des LV en mode mirrored dont une des copies était sur ce PV).

Non, c'est une décision que tu prends LV par LV.
LV en mode linear => équivalent du JBOD
LV en mode mirrored => équivalent du RAID 1 (tu peux choisir le nombre de copies que tu veux, ce n'est pas limité à deux)
LV en mode stripped => équivalent du RAID 0

Par exemple chez moi j'ai un VG de deux disques, et dessus j'ai aussi bien un LV stripped (espace temporaire qui me sert pour certains scripts) que plusieurs LV mirrored (où je stocke mes données importantes, BDD...).

Tu choisis le mode à la création du LV, mais tu peux ensuite convertir à chaud un LV d'un mode vers l'autre.

Oh !  
Il va me falloir tester à nouveau tout cela alors  

Merci pour l'info

Merci pour tous ces avis.
Pour l'instant j'ai fait le radin et tout réinstaller (c'était nécessaire)  
Finalement, j'ai mis merge fs. Et effectivement c'est exactement ce que je voulais. Cela fonctionne parfaitement et comme attendu.
J'ai pas encore fini de remonter tous les conteneurs mais la config est tellement plus simple.

Hello à tous.
Question aux utilisateurs de Docker, qu'elle est votre architecture de dossiers ?

De mon côté c'est actuellement construit de cette façon :

docker
├── appdata #data des différents services
│   ├── service1
│   └── service2
│
├── compose
│   ├── service1
│   │   ├── .env #variables spécifiques au     service
│   │   └── compose.yml
│   │
│   └── service2
│       ├── .env
│       └── compose.yml
│
└── .env #variables globales (TZ, DOMAINNAME, PUID, PGID,...)

Ça fonctionne, mais je trouve que ça n'est pas très optimisé d'avoir ces 2 fichiers .env à charger lors d'un lancement d'un containers (ou alors je m'y prends mal) et ça me bloque dans l'automatisation des pull et up des containers via Renovate (mais encore une fois, je suis peut-être le facteur limitant)

Si par service tu parles d'un ensemble de conteneur liés ou d'un seul indépendant alors on a pareil.
Maintenant pour simplifier, j'ai mis portainer. Il gère tout seul tout ça.
Je fait des stack de truc qui vont ensemble.
exemple :
osrm + postgresql
Nextcloud + redis + postgresql
Jellyfin + arr + jellyseer + ...
Treafik
Openvpn
Etc...

Dokploy c'est mieux (CI/CD natif et création de certificats LE auto)
 
Portainer a des avantages (je l'utilise depuis des années mais je dois reconnaître que j'ai plus rien déployé dessus depuis que j'ai découvert Dokploy ), comme une gestion plus fine des ressources (images, réseaux, volumes) et ses outils de monitoring un peu plus détaillés, et aussi un passif important, il disparaitra pas mais sinon je vois pas bien l'intérêt de rester dessus, surtout qu'on peut faire des clusters easy sur Dokploy (avec Swarm), et gratuitement vu que c'est open source... Leur business model c'est de proposer un service d'infogérance pour un prix dérisoire (4e par instance et par mois)...

Et tu as aussi un fichier .env qui contient toutes les variables communes à tous les containers et un fichier .env spécifiques à chaque service ?

Plus ou moins la même question.
Dokploy sait redéployer un container quand un fichier .env est à récupérer un dossier en amont ?

Actuellement je n'ai pas trouvé d'autres moyen que de lancer manuellement cette commande :
docker compose --env-file /home/mediacenter/docker/compose/.env -f /home/mediacenter/docker/compose/overseer/compose.yml up -d
J'aimerai bien mettre en place une solution CI/CD avec approbation manuelle des maj et déploiement automatique après approbation mais jusqu'à présent je n'ai pas réussi à mettre quelque chose de fiable en place

Chais pas vous mais moi j'ai la même logique sauf que j'ai pas de .env racine, chaque service est un docker compose, j'en suis à 60 conteneurs et ça tourne propre.

Mais c'est ma config@home, j'ai pas besoin d'industrialiser.

Le concept de dokploy est sympa ça me rappelle un peu le concept de HiveOS de mémoire pour le minage je crois.
 
J'aurais juste voulu un truc similaire avec gestion centralisé équivalente mais qui puisse être hébergé en local afin de faire du monitoring (mais on dépasse le @home la )

Je pense que je vais virer le env racine. Ça n'apporte pas énormément de simplicité étant donné que je dois avoir seulement une dizaine de variables qui sont enregistrées dedans.

Et ça devrait faciliter la gestion des containers par des solutions comme Portainer, Arcane, Dockploy,...

Alors moi je ne l'utilise qu'avec mes repo GitHub et le redeploy est trigger au moindre changement de fichier (hors .md), après être passé par le CI de GitHub Actions...

Pour le .env (qui n'est pas sur mes repos, si ce n'est un .env.example), il le prend automatiquement si l'onglet "Environment" est valorisé. Il n'est pas censé bouger mais quand c'est le cas je le modifie via GUI et je (re)deploy tout simplement.

Sinon, l'intérêt du CI/CD c'est d'avoir des tests qui valident le déploiement. Au début (quand j'ai commencé à faire du dev), j'avais un docker-compose.yml et un docker-compose.prod.yml et je testais tout en local avant de commit et de deploy. Maintenant j'écris des tests unitaires systématiquement et je bosse dans la branche dev avant de merge dans le main et d'exécuter tous mes tests qui s'ils sont validés déclenchent le deploy via Dokploy du coup zéro stress (sous réserve que les tests soient bons)...

Ce ne sont peut-être pas les usages mais n'étant pas dev de métier j'essaie de m'inspirer de ce que je lis... Et sinon, concernant les tests, je demande pas à un LLM de m'en générer le plus possible mais plutôt de se concentrer sur peu de tests (typiquement moins de 15) mais qui correspondent à la réalité et présentent un réel intérêt. Depuis que je procède ainsi je n'ai plus un seul fail...

 
En fait je suis dans le même cas que Dafunky. 1 compose par stack. Parfois pour un seul conteneur parfois pour plusieurs selon les besoins.
Et un .env par stack. Pas de global.
Ca tourne bien sans soucis.  
C'est un truc pour la maison après. Pour du taf, j'aurais surement un environnement test et un autre de prod.
Avec des tests auto et tout le touin touin.
Mais en vrai, vu que je bricole régulièrement dessus pour rigoler, je maj à la main en 2/3 clic.
A voir si j'automatise cela. Mais je ne suis pas sur que cela soit toujours un super plan pour mon contexte.
Hors serveur de jeu qui rendent obligatoire la monté en version, pour le reste. en général, on ne meurt pas de ne pas avoir le dernier ajout de la +0.1

Ça dépend de la raison de l'update, si c'est pour corriger une faille de secu c'est risqué de pas la faire...

Bon, j'ai chopé un kit cm B460 + un 10100 et 16gb ddr4 pour moins de 100€.
 
J'hésite à essayer de trouver un 10500T quand même...
Le 10100 se revend entre 20 et 50€, et les 10500T, on les trouve vers 50€.
 
Pour une carte sfp+ 2 ports + raidz1 ou 2 6*4To, et des liens iscsi.
 
Je sais même pas quelle distrib prendre au final, car j'aimerais réussir à gérer les liens iscsi facilement (Au moins 1, peut-être 2 ou 3 en plus)
 
Truenas parait monstrueux juste pour ça... je ne pense pas du tout faire de vm/docker sur cette machine

icsci c'est du basique qui marche sur un peu n'importe quelle distro classique, non ? J'avais fait un test vite fait sous Debian il y a plusieurs années, je n'avais pas rencontré de problème particulier.

Tout à fait.
Mais je n'ai plus envie de les gérer en ligne de commande si tu préfères ^^
C'est là où je trouve Truenas sympa sur la gestion de ces liens

Il y a des modèles à la mode/juste-marche/pas cher pour ?
 
- une carte PCIe Ethernet 2.5Gb (à foutre dans un proxmox)
- switch 2.5Gb

Moi sur le topic Proxmox :

C'est toujours stable et performant

Pas de SR-IOV sur les chips grands publics (type i225-v / i226-v) chez Intel.
Il faut payer plus cher et aller vers les modèles "serveurs".

Ça va pas répondre exactement à ta question mais après un passage sur du 2.5gbps pas concluant, dont j'ai tiré l'enseignement que le 2.5gbps n'a pas vraiment été suivi dans le monde pro, je suis passé sur du 10gbps mellanox + plusieurs switch hybrides 10gbps / 2.5gbps qui pullulent pas cher sur Aliexpress. Ma station de travail est en 10gbps, les autres appareils sont en 2.5gbps, les switchs sont en 10gbps entre eux

Si ça t'intéresse cherche mellanox et mon pseudo. Il y avait un battle intel vs mellanox pour de la carte refurbish pro-grade pas cher , j'ai choisi mellanox car 2x moins cher et consomme 2x moins de watts.

20 mois que ça tourne rock stable.

Quel est le problème sur le suivi par les pros comme tu dis? Point de vue logiciel/drivers tu veux dire? Ou matos? Parce que chez Unifi par exemple il y a bien tout une pelletée de 2.5G, mais c'est que du semi pro peut être dans ta classification ?

De mémoire, j'ai pas su trouver de la carte PCI express 2.5gb avec des drivers sérieux.
Et quand j'ai acheté une carte avec un chipset connu , je me suis trouvé avec des plantages aléatoires au bout de x semaines de fonctionnement. En regardant la cause et les mises à jour j'ai compris que c'était du matos prévu pour motherboard retail.
Ça m'a gonflé -> 10gbps.

Ouais en même temps y'a tellement de carte-mère grand public avec du 2.5G maintenant que ça s'est démocratisé y compris chez les chinois le 10G c'est quand même encore beaucoup du pro

Ça devrait s'accélérer avec le nouveau chip 10G realtek qui a un prix cible à approx 10 $, ça rend le 10G accessible aux fabricants de CM:
https://www.tomshardware.com/networ [...] -this-year