VM / Docker / Add ons : comment optimiser ses containers/fiabiliser son install? Best practices?

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 :wink:

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
image

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 :

image

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 :slight_smile:

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é :wink:

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 :wink:

Bonjour,

J’ai enfin terminé mes « migrations », ça m’a bien pris une semaine ses conneries :).

Les 5 CT LXC sont opérationnels:
image

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:
image

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 :slight_smile: ): 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