Proxmox Que choisir pour créer un conteneur AdGuard Home, un Wireguard, un SWAG ? LXC, Debian LXC, Debian VM ?

[EVO]

Je suis d'accord, on install pas Proxmox, pour ensuite installer des trucs directement dessus. C'est juste un nid a probleme

 

[Cram28]

Bonsoir à tous

Évidemment je vois bien l'intérêt d'exploiter les propriétés d'étanchéité de la virtualisation, qui évitent de foirer le système hôte: Un hôte on en a qu'un, on veut qu'il soit sûr et stable.

Mais de vos propos, je déduis que Proxmox n'est pas «juste» un système avec des outils de virtualisation (KVM et LXC) et une interface web pour les exploiter: c'est une distribution complète dédiée, une «appliance» qui vit sa vie indépendamment du système Debian sur laquelle elle s'appuie.
Elle a son noyau déjà, et potentiellement d'autres spécificités de ce que je comprends (comme ne pas laisser cohabiter Docker dont on parle ici): il faut potasser ou la doc ou le code pour les connaître si elles existent.

Bon...
Donc - par rapport à une question que je posais dans un autre post - même l'ajout des paquets Proxmox «par dessus» une installation Debian standard embarque ces spécificités ?

Si c'est le cas, je vais revenir à une distribution standard pour l'hôte (je sais, j'y revient souvent , je cherche un couteau suisse en fait). Je vais lui ajouter «à la main» les fonctionnalités de virtualisation qui m’intéressent (KVM, incus/LXC, docker/podman, systemd-nspawn pourquoi pas...) qui bien sûr fonctionnent ensembles sur n'importe quelle distribution GNU/Linux.

Je me passerais alors de l'IHM Proxmox, qui est pas mal mais dont la valeur ajoutée principale est essentiellement de masquer la ligne de commande, de proposer de belles visu et la facilité des config, réseau notamment... j'exagère un peu .
Ou peut-être utiliser des outils d'admin propres à chaque techno: virt-manager, incus-ui, portainer, etc...

Dans un souci d'optimisation des ressources machines (mon serveur glande quand même pas mal la plupart du temp), c'est un peu embêtant d'avoir ce genre de risques avec de simples ajouts
Même si on peut toujours empiler les virtualisations comme installer Docker dans LXC.

Bref, merci, @+

 

[pierre liths]

Je me passerais alors de l'IHM Proxmox, qui est pas mal mais dont la valeur ajoutée principale est essentiellement de masquer la ligne de commande, de proposer de belles visu et la facilité des config, réseau notamment... j'exagère un peu .

Non tu n'exagères pas, l'intérêt majeur de Proxmox est de se passer des lignes de commandes pour une majeur partie des actions.
Si tu préfères jouer de la ligne de commande et tu sembles très à l'aise avec, alors en effet Proxmox n'est pas l'idéal, il a quand même le mérite de s'installer très facilement et se prête à un apprentissage rapide. Par contre, oui il faut empiler les conteneurs/VM pour utiliser Docker, le couteau suisse n'est pas parfait.
Peut-être peux-tu le créer , je serais preneur en tout cas.

 

[EVO]

Elle a son noyau déjà, et potentiellement d'autres spécificités de ce que je comprends (comme ne pas laisser cohabiter Docker dont on parle ici): il faut potasser ou la doc ou le code pour les connaître si elles existent.

Proxmox cohabite bien avec le reste. C'est une Debian avec un kernel a lui. Cependant, il faut garder en tete que le kernel n'étant pas celui "d'origine" il peux y avoir des incompatibilités, ... Aussi, en général on place proxmox pour ce simplifier la vie. La simplification viens aussi du fait de ne pas sortir des sentiers battus. Plus tu as une configuration "hors de l'utilisation normale", et plus tu t'explose a des bugs possibles, voir il te sera peut etre difficile dans certains cas d'obtenir de l'aide / du support.

 

[MilesTEG]

Bonsoir,
Ayant un peu avancé (pas beaucoup de temps libre, et j’ai aussi Home Assistant à m’occuper) avec la vm Debian Doxker Portainer, je suis en train de préparer le docker-compose de swag que je voudrai transférer sur le nuc.
Portainer est installé, via un compte utilisateur non root appartenant au groupe docker , groupe que j’ai affecté aux dossiers /srv/docker/ et donc autorisé en accès à mon utilisateur non root.
(J’ai juste une bizarrerie qui fait que je n’ai pas besoin du mot de passe root pour faire un sudo -i faut que je vois ça plus tard)

Bon portainer fonctionne bien apparemment.

Bref revenons à swag.
J’utilise un certains nombre de fichiers log sur le Synology, fichiers partagés depuis d’autres conteneurs sur le Synology donc assez facile d’accès.
Mais je n’aurais plus accès à ces fichiers en mettant le reverse proxy sur le nuc…
Ça concernerait entre autre , les logs de :

• Vaultwarden ;
• Gitea ;
• Nextcloud ;
• Calibre-Web ;
• … et plein d’autres encore…

Je n’envisage pas de déplacer tous ces services sur le nuc…
Donc il me faut une solution pour pouvoir continuer à utiliser ces fichiers logs dans swag pour fail2ban et crowdsec …

Quelles sont les solutions simples que vous conseillez ? (J’entends par simple qui ne nécessitent pas des heures de configuration d’un côté comme de l’autre…)

(je me dis qu’il serait peut être souhaitable d’ouvrir un nouveau sujet…)

Merci d’avance

 

[Bambusa29]

Hello @MilesTEG,

Tu peux installer un serveur Rsyslog dans ton container Swag : apt install rsyslog
Puis tu modifie sa config : nano /etc/rsyslog.conf
Tu décommente ces deux blocs ou un seul en adaptant le port d’écoute :

module(load="imudp")
input(type="imudp" port="514")
module(load=“imtcp”)
input(type=“imtcp” port=“514”)

Les log arriveront dans : /var/log/rsyslog
Puis sur tes containers clients tu installe aussi rsyslog et dans la config tu rajoute :

*.* @ip_serveur_rsyslog:514

ou

*.* @@ip_serveur_rsyslog:514

Un seul @ pour du UDP et deux @@ pour du TCP

 

[MilesTEG]

Hello @MilesTEG,

Tu peux installer un serveur Rsyslog dans ton container Swag : apt install rsyslog
Puis tu modifie sa config : nano /etc/rsyslog.conf
Tu décommente ces deux blocs ou un seul en adaptant le port d’écoute :

module(load="imudp")
input(type="imudp" port="514")
module(load=“imtcp”)
input(type=“imtcp” port=“514”)

Les log arriveront dans : /var/log/rsyslog
Puis sur tes containers clients tu installe aussi rsyslog et dans la config tu rajoute :

*.* @ip_serveur_rsyslog:514

ou

*.* @@ip_serveur_rsyslog:514

Un seul @ pour du UDP et deux @@ pour du TCP

Autant pour swag vu que c’est une image Linuxserver je peux installer facilement et de manière pérenne une app à la création du contneneur , autant pour les autres ça ne sera pas serein car des qu’il y aura une maj de l’image je vais perdre le rsyslog et faudra tout refaire et ça ça va être pénible ++.
Sur le Synology je peux accéder aussi fichiers logs car j’ai mis des points de montage pour les conteneurs qui les génèrent.
Du coup , ne serait il pas possible le d’avoir un conteneur rsyslog qui gère les logs que je lui donnes via les fichiers dans les points de montage ? (Dans la section volumes: du docker-compose)
(Ps : je ne connais rien sur rsyslog comment il fonctionne etc…)

 

[Bambusa29]

Si tu dois pouvoir installer un containeur rsyslog, qui fera office de super client (il as en partage tous les logs des autres conteneurs).
C'est ce seul containeur rsyslog qui fera le lien avec le serveur rsyslog sur ton container Swag/portainer/docker.


Dans ta config rsyslog super client tu aura :

mon_log1_partage.*   /point_montage_log1_partage
mon_log2_partage.*   /point_montage_log2_partage
...etc

mon_log1_partage.* @ip_serveur_rsyslog:514
mon_log2_partage.* @ip_serveur_rsyslog:514
mon_log3_partage.info @ip_serveur_rsyslog:514
... etc

 

[MilesTEG]

Si tu dois pouvoir installer un containeur rsyslog, qui fera office de super client (il as en partage tous les logs des autres conteneurs).
C'est ce seul containeur rsyslog qui fera le lien avec le serveur rsyslog sur ton container Swag/portainer/docker.


Dans ta config rsyslog super client tu aura :

mon_log1_partage.*   /point_montage_log1_partage
mon_log2_partage.*   /point_montage_log2_partage
...etc

mon_log1_partage.* @ip_serveur_rsyslog:514
mon_log2_partage.* @ip_serveur_rsyslog:514
mon_log3_partage.info @ip_serveur_rsyslog:514
... etc

Merci
Va falloir que j'investigue pas mal dessus, car la config que tu as donné ne me parle pas du tout

 

[sirillidan77]

Je parlais d’une interface qui permette de faire les mise à jour de tous ces lxc d’un coup via soit un bouton soit une autre appli comme watchtower dans docker : ça vérifie s’il y a une mise à jour et si oui ça l’applique.
À moins de passer par un script ça n’est pas possible. Et encore moins en automatique.

Ps : je me suis fait hier un petit script qui lance des commande de mises à jour des machines Debian et proxmox via ssh . Mais la galère, il a fallut que j’installe sshpass sur mon mac pour passer le mot de passe ssh après avoir demandé une saisie de ce dernier via une demande du script.
Et c’est sans parler que les variables du Shell zsh et certaines apportées par OMZ ne sont pas disponibles… j’ai du ajouter certaines nécessaires à la mise à jour de OMZ et de ses plugins .

Bref c’était bien relou. Et encore une fois pas automatique.

Bonjour ,

Plusieurs personnes vous ont renvoyer vers https://tteck.github.io/Proxmox/
Avez-vous parcouru le lien ? .. une vrais mine de ressources utiles !!

Votre option 3 fonctionne tres bien elle aussi ... que propose tteck pour Docker ?

Docker LXC

Ce script creer un LXC Docker + Portainer et/ou Docker Compose V2
🛈 Si le LXC est créé Privilégié, le script configurera automatiquement le relais USB.
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/docker.sh)"
Paramètres par défaut : 2 Go de RAM - 4 Go de stockage - 2vCPU

Comme option alternative, vous pouvez utiliser Alpine Linux et le package Docker pour créer un conteneur Docker LXC avec un temps de création plus rapide et une utilisation minimale des ressources système.
bash -c "$(wget -qO - https://github.com/tteck/Proxmox/raw/main/ct/alpine-docker.sh)"
Paramètres par défaut : 1 Go de RAM - 2 Go de stockage - 1vCPU
⚠ Exécutez Compose V2 en remplaçant le trait d'union (-) par un espace, en utilisant docker compose, au lieu de docker-compose.
Interface Portainer : (https) IP :9443

Avec des LXC, la gestion des MAJ peut-être centraliser aisément, ci-dessous 3 autres scripts disponibles via tteck scripts

Proxmox VE LXC Filesystem Trim

Ce script maintient les performances du SSD en gérant les blocs inutilisés. Les VM automatisent fstrim, tandis que les conteneurs LXC nécessitent des processus fstrim manuels ou automatisés pour des performances optimales. Celui est conçu pour fonctionner uniquement avec les SSD sur les systèmes de fichiers ext4.
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/fstrim.sh)"

Proxmox VE LXC Cleaner

Ce script fournit des options pour supprimer les journaux et le cache, et repeupler les listes apt pour les systèmes Ubuntu et Debian.
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/clean-lxcs.sh)"

Proxmox VE LXC Updater

Ce script a été créé pour simplifier et accélérer le processus de mise à jour de tous les conteneurs LXC sur diverses distributions Linux, telles que Ubuntu, Debian, Devuan, Alpine Linux, CentOS-Rocky-Alma, Fedora et ArchLinux. Il est conçu pour ignorer automatiquement les modèles et les conteneurs spécifiques lors de la mise à jour, améliorant ainsi sa commodité et sa convivialité.
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/update-lxcs.sh)"

Par ailleur, vous pouvez tout à fait envisager de convertir votre "VM aux petits oignons" en lxc ... (script non testé)

https://github.com/my5t3ry/machine-to-proxmox-lxc-ct-converter

Pour ma part, j'utilise une base "dietpi" sur mes VM/LXC et j'ai pu verifier le bon fonctionnement de la procedure proposé ci-dessous:

https://dietpi.com/blog/?p=2642

Bienvenue sur proxmox

 

[MilesTEG]

Trop de possibilité, tue la possibilité
Je suis parti sur l'option VM Debian + Docker + Portainer.
Pour mon serveur wireguard, ça marche au poil.

Mais pour le reverse proxy, j'ai des soucis avec SWAG, voir le sujet du tuto.