GUI vs. CLI.
Le débat éternel.
La dessus, pour créer docker compose je trouve plus rapide car il créé les réseau et tout tout seul alors que avec portainer et les stack il faut le faire avant de lancer la stack, mais portainer permet de relancer et d’accéder au log rapidement.
Maos comme d’hab tout esg tres subjectif
On est d’accord, Portainer c’est du confort, mais quand ça marche pas et que tu dépends de ça pour analyser (parce que pas appris à faire sans)… C’est vachement moins efficace.
1 « J'aime »
Oui c’est clair, je donnais juste mon point de vue de looser non barbu sur docker en ayant essayé les deux hihi
1 « J'aime »
Euh je peux poser une question 
J’ai lu plusieurs fois que le LXC proxmox était parfait pour faire des tests mais pas de la production ! (J’ai oublié les vrais raisons mais il y a des spécialistes ici 
)
J’ai donc mis une VM avec docker et portainer.
En fait j’ai plusieurs VM avec plusieurs docker et plusieurs portainer 
Et là l’agent portainer vient t’aider et faire un peu comme le cluster proxmox tout sous le même UI.
Bon après le must est d’avoir le serveur direct en docker sans passer par proxmox et la VM mais plus simple d’usage pour moi de tout avoir dans proxmox.
Par contre je sépare les choses swag authelia etc c’est à un endroit et zigbee2mqtt zwave Node red ailleurs dans un autre docker.
À tort peut être je ne mélange pas les genres
Voilà juste un partage pour ta réflexion
Sur VM, c’est comme si tu avais un machine physique, un lxc, est comme un docker, il utilise le noyaux de proxmox en faite. Pour info, j’ai toujours eu des problème avec docker dans VM et aucun souci en lxc.
Merci pour toutes ces réponses, le moins qu’on puisse dire c’est qu’il n’y a pas de réponse universelle :).
Je vais donc bien partir sur plusieurs ct lxc, ce qui me permettra en cas de plantage, upgrade, migration… de n’impacter qu’une partie de mon infra. Ca me permettra d’ailleurs d’avoir des ct unprivilegied ou pas (je n’ai pas encore bien saisi les nuances de cela, mais j’ai constaté que nombreux ct ne marchent pas en fonction de cette coche, j’ai notamment eu le cas avec nextcloud, heimdall, organizr…).
Me reste plus qu’a m’organiser d’un point de vue stockage avec les 2 hdd du nuc (idealement il faut que je stocke les configs et datas a un endroit commun, que je backup)
Il me semble que les best practices sont d’avoir un dossier racine commun au volume
Donc si c’est le cas et les bons droits sont bien affecter il n’y aura aucun problème pour créer les volumes pour chaque container depuis portainer
portainer met en visuel ce que vous pouvez avoir en cli avec docker
@jerome6994 Quel et l’intérêt ? Je pense aucun si tu fais un cluster docker sachant que tu as déjà un portainer le même portainer pourrais avoir accès a tous les autres docker « standalone » grace a l’agent et cela indépendant les uns des autres
L’intérêt de la séparation de mes containers dans différents docker ?
Et bien simplement une question de rangement.
Je ne souhaite pas ranger le network avec la domotique que je ne veux pas ranger avec des applications autres.
Ni plus ni moins 
Ha OK je pensais que c’était pour une notion de réseau/cloisonnement au niveau infra/archi
1 « J'aime »
J’avance sur le remaniement de mon install.
Les nouveaux CT dockers sont prêts
portainer avec les portainer agent opérationnel
Par contre je butte encore sur la partie stockage, je m’emmêle le cerveau entre les volumes (qui si j’ai bien compris sont communs « par docker », et sont à gérer sous docker ou portainer), et les mount-points (qui sont sont à gérer sous proxmox directement, et restent liés à un CT LXC, ils ne sont tjrs pas communs).
La cible est bien:
- SSD1 (le principal de 256gb): le core proxmox et les images de CT / isos
- SSD2 (secondaire de 1to): les volumes des VMs/CT, la config, les datas, tout le reste en gros.
Mon souhait est d’avoir a un endroit centralisé (je ne sais pas si il est à créer/gérer depuis proxmox, ou bien a intégrer dans un des CT docker, en l’occurrence ce serais le 01), une arborescence du style:
/stockage-global/docker01-ct1/data/
/stockage-global/docker01-ct1/config/
/stockage-global/docker01-ct2/data/
/stockage-global/docker01-ct2/config/
/stockage-global/docker02-ct1/data/
/stockage-global/docker02-ct1/config/
Et derrière gérer le backupage de ce /stockage-global/ vers mon NAS (piloté par HA, ou pas autre chose d’ailleurs). D’ailleurs idéalement avec un partage smb en plus pour que j’y accède « facilement » depuis mon windows.
Des conseils?
Je ne pense pas que c’est faisable.
Quand on a créé un container LXC ou un VMs dans proxmox, on crée un ou plusieurs disques virtuels.
Ces disques virtuels apparaissent comme un seul fichier dans proxmox et on ne peut pas les lire directement. Encore moins, identifier un /data et un /config.
On peut sauvegarder le fichier vers le NAS comme une entité unique et pas comme une collection de fichiers.
Pour voir les fichiers à l’extérieur des LXC et des VMs, j’installe dans chaque un container samba.
J’ai un répertoire /home/moi. dans lequel je crée ensuite un répertoire par container.
C’est ce répertoire que j’utilise comme volume dans docker.
Ensuite, en partageant via samba, /home/moi je peux voir tous les fichiers depuis mon mac en montant un lecteur réseau.
Je peux ainsi sauvegarder ce répertoire depuis mon NAS (un vieux Synology) qui sait faire des globales et des incrémentales de ce répertoire.
Mais, voir, par exemple les fichers de Home Assistant dans un répertoire sur proxmox dans /storage/lxc1/homeassistant , c’est je le crains sans espoir.
Salut @golfvert
Je ne serai pas aussi catégorique que toi à ce sujet, au moins pour les CT lxc sur un fs en zfs.
Dans ce cas je vois tous mes lxc :
Et je peux « taper » dedans :
Merci du tuyau. Je ne savais pas… mon disque n’est pas en ZFS…
@Herbs
Sur l’HP 800 G4 mini i5 ou i7 il y a deux emplacement B+M et un emplacement A+E on est d’accord.
Pourquoi prendre un B+M plus qu’un A+E ?
Le second B+M pourrait servir à un second disque non ?
Sur le A+E il peut se monter quoi d’autre ?
Tout c’est bien passé avec ceci Get started with the M.2 or Mini PCIe Accelerator | Coral ?
Et ensuite le docker compose de Frigate tu renseignes le device coral et hop ça roule 
Salut @jerome6994
J’ai ce modèle :
HP Elitedesk 800 G4 USFF - Core i5-8500@3.00GHz - 16Go RAM - 512Go SSD
J’ai lu à plusieurs reprises (sans avoir pu le vérifier) que parfois ces ports pouvaient être « bios limited » et n’acceptaient que des cartes wifi.
Bref j’ai joué la sécurité
Oui en effet, mais cette machine est 100% dédiée à HA et à la domotique. J’ai du stockage sur un autre serveur pour des gros volumes et du backup. Donc c’est selon le besoin.
Je me suis limité à la partie « 2a », la partie « 3 » est contenue dans le container.
En gros c’est ça, mais faut aussi monter le gpu du « proc », et bien suivre ce que recommande la doc de frigate.
Après je fais tourner mes ct avec « podman », qui est légèrement différent de docker.
Mais si ça peut te donner une idée, voici mon « podman run » :
podman run -dt --name frigate -v /etc/localtime:/etc/localtime:ro \
-v /ctdata/frigate/config/config.yml:/config/config.yml:ro -v /ctdata/frigate/media:/media/frigate \
--device /dev/dri/renderD128:/dev/dri/renderD128 --shm-size=64m --mount type=tmpfs,target=/tmp/cache,tmpfs-size=1000000000 \
--device /dev/apex_0:/dev/apex_0 --group-add keep-groups -p 5000:5000 -p 8555:8555 -p 8554:8554 \
blakeblackshear/frigate:stable
La partie --device /dev/apex_0:/dev/apex_0 correspond au Coral.
Merci beaucoup pour tes retours qui font cheminer ma reflexion
Bonjour,
J’ai enfin terminé mes « migrations », ça m’a bien pris une semaine ses conneries :).
Les 5 CT LXC sont opérationnels:
J’ai à présent bien séparé chacune de mes BDD (ce n’était pas le cas jusqu’à présent, j’avais par exemple kodi avec nextcloud…)
J’ai un CT Samba par docker, qui me permet d’accéder facilement aux répertoires à backuper de chaque CT:
J’y vois un peu plus clair dans mes dockers :).
Prochaine étape, automatiser le backupage de tout cela. Le mieux est biensur de gérer cela, de façon un minimum centralisée (en dehors de HA j’imagine). Des conseils la dessus? Des outils?
PS (voir HS ): Petit retour d’expérience suite à la migration (au cas ou ça aide/intéresse quelqu’un).
- Je me suis arraché les cheveux avec certains CTs, qui ne tournaient pas correctement en fonction de si j’était sur un CT LXC privileged ou pas, jusqu’a ce que je bascule sur une image de CT LXC « debian de base », au lieu d’une « turnkey ». J’ai beaucoup moins galérer avec l’image de base debian (il faut juste activer le ssh en plus au départ)
- Je me suis aussi arraché les cheveux avec les partages samba, notamment avec nextcloud qui utilise le user www-data. Ca a été beaucoup mieux après avoir fait les partages avec les UID 33 (pour ce CT).
- Petites frayeurs lors de la migration de unifi controller. Impossible d’avoir 2 instances de contrôleur en parallèle, donc on ne peux pas se dire j’installe la nouvelle instance avec tous les devices et je test avant la bascule. Les devices sont « affectés » a un contrôleur, du coup je me demande ce que ça doit être le jour ou un contrôleur lâche pour re gérer son réseau… (les backups seuls semble pas être suffisant du coup)
- Nextcloud m’a aussi donné du fil à re tordre. Pour des raisons que j’ignore l’application « Nextcloud Office » ne fonctionnai plus lorsque j’utilisai un nom de domaine, mais marchait avec l’ip, puis ne fonctionnai plus du tout, puis réinstallation, puis des milliers de tests de config, puis a un moment ça a refonctionné, je n’y touche plus mais je ne sais pas quel était le problème (peut être le vidate du /tmp dans docker).
- Pour NGINX proxy manager dans l’ensemble ça a bien été, juste j’ai du recréer tous mes paramètres à la main (ça va il n’y en a pas des kilomètres), car sous HA c’était stocké sous maria DB, la j’ai laissé de base avec sqlite (ce sera plus simple à backuper). J’aurais biensur pu repasser par une MariaDB.
- J’ai oublié de backuper mon LMS avant de supprimer l’ancienne install, j’ai donc du tout refaire de 0 (paramétrages…)
- J’ai découvert qu’avoir 2 instances de Frigate en même temps avec les mêmes paramètres de caméra posai problème avec MQTT (après réflexion ça semble logique, mais sur le coup j’ai passé quelques temps à me rendre compte du problème). D’ailleurs je constate que la consommation de CPU reste élevée malgré la Coral, je ferai un topic dédié à ce sujet.
Bonne journée, et merci pour votre aide!
Tu parles de ceux du cloud ?
Du cloud key? Je n’ai pas de cloud key, j’avais unifi contrôleur dans une VM, et maintenant dans un CT docker. Mais le fonctionnement est le même normalement.
En fait lors de la migration (et à fortiori d’un restore), il y a 2 fichiers utiles, celui de ton « Site », puis ton « Configuration File ». Une fois que tu fais cela, tu vois bien tes device sous ton nouveau contrôleur (VM, CT, Cloudkey…), mais il ne peuvent pas être « adoptés » directement car ils le sont déjà sur l’ancien contrôleur.
Dans la procédure tu est sensé lancer cette bascule depuis ton ancienne instance, ce que j’ai fait et qui fonctionne bien. Par contre si jamais tu n’as plus accès à cette instance (cloud key morte, VM ou CT supprimé…), alors ça se complique.
De ce que j’ai pu lire (mais heureusement pas eu à tester), en gros soit du reset tes devices (via le bouton physique de reset), puis tu est bon pour les réinstaller et les re paramétrer (de zero j’imagine), soit tu fais l’adoption manuellement en ssh sur tes devices