Reprise du message précédent :

A priori un problème avec l'accélaration matérielle (AMD).
Bizarre.

Du coup j'en ai profité pour installer: Pulse, Uptime Kuma, et LoggiFly

https://www.virtualizationhowto.com [...] e-3-tools/

Voilà voilà, je vais surveiller tout ça.
J'ai aussi commencé à utiliser github pour suivre un peu plus proprement mes configs et les updates que j'applique.
Histoire de savoir comment je casse tout parfois

A priori c'est un bug connu de frigate.
Le container ne se stop pas correctement dans certaines conditions (combo coral / amd proc / je ne sais plus quoi d'autre).
 
Du coup ça fait planter mon host docker complètement.
 
Va falloir penser à isoler frigate pour ne pas tout crasher

J'ai pensé à la même chose.
Lui faire un LXC rien que pour lui.

Chatgpt me dit de repasser frigate sur l'autre serveur:

On your AMD 680M, VAAPI can be finicky for 24/7 CCTV. The most stable route in homelabs is to run Frigate on your Intel i3-12100 node and use Quick Sync

Je vais sûrement faire ça
(je venais de faire l'inverse il y a 2 semaines mais trop instable )

Si ça peut en inspirer certains, j'ai fait quelques updates sur mon setup.
 
J'avais 3 serveurs dans mon homelab, avec 3 LXC portainers CE.
Je les ai passés sur portainer Business Edition (gratuit jusqu'à 3 nodes).
 
Tout se gère maintenant depuis une interface, plus pratique.
J'ai aussi créé un github privé et updaté tous mes stacks dessus.
 
Maintenant quand je veux changer quelque chose, j'ai une instance Claude Code qui retravaille les compose, les push sur github et redéploie mes containers.
 
Dingue comme ça simplifie la gestion de tout ça !
 
Voilà    
 
/noob

Je veux bien des précisions sur la partie Claude    
 
Perso j’ai abandonné Portainer au Profit de Arcane beaucoup plus sympa esthétiquement  

Tu installes Claude code (donc la version qui s'utilise dans le terminal).
 
Ensuite tu vas avoir un dossier homelab par exemple:
 
homelab/serveur1/LXC101 - Docker 1/frigate/compose.yml
homelab/serveur2/LX105 - Docker 2/immich/compose.yml
homelab/serveur2/LX105 - Docker 2/jellyfin/compose.yml
 
etc.
 
Tu ouvres ton terminal dans le dossier racine, et tu demandes à claude de regarder tout ce qu'il y a dedans. Tu lui demandes de résumer ton serveur dans un fichier Claude.md (où tu vas pouvoir ajouter tous les autres services / ip / etc).
 
Si ta connexion à tous tes serveurs se fait par ssh avec une clé, claude pourra lui même faire l'inventaire de ton LAN automatiquement, te créer l'arborescence de tous tes services qui tournent sur docker (ou autre), updated des fichiers configs directement, débugger tout ce qui plante, faire un audit sécurité, etc.
 
Donc après par exemple, tu vas lui dire:
 
Je veux déployer une deuxième instance de pi-hole sur serveur 2.
 
Et il travaille tout seul

Intéressant ça  mais flippant... je ne suis pas sûr de vouloir laisser l'accès à mon Gitea perso à une IA, et encore moins la laisser déployer seule mes conteneurs XD
Et comment gères-tu les .env ? ils sont dans ton dépôt ou dans un autre non accessible à Claude ?

Tu peux valider chaque step si tu préfères
Et effectivement, les .env sont dans un autre répertoire.

Salut,
J'ai définitivement adopté Arcane pour gérer me conteneurs docker.
Et je suis en train de me demander si je ne vais pas utiliser le système de mise à jour des conteneurs qui est intégré à Arcane, plutôt que Watchtower...
 
Avez vous des avis là dessus ?

Je suis en train de tester Arcane, pour le moment ça a l'air pas mal du tout mais j'ai un problème sur les permissions.
Mes projets sont dans /opt/docker et le propriétaire est root, Arcane semble fonctionner avec l'utilisateur 1000 donc il n'a pas les droits sur /opt/docker.
Tu gères ça comment de ton côté ?  

Je n’ai pas de problème de permissions avec mon utilisateur non root (je ne fais pas de rootless) juste j’ai mis l’utilisateur non root dans le groupe docker et je mets user-non-root:docker comme permissions.  
Demain je te donnerais mon docker compose pour que tu vois ce que je fais

Merci

Hello, des utilisateurs de Crowdsec ici ? Vous gérez quelles collections une fois en place, directement par le socket docker ou vous allez analyser les fichiers de log de chaque container ? Merci

Alors j'ai pris un peu au pif :

• TOR Blocklist
• Firehol BotScout list
• Firehol greensnow.co list
• CrowdSec Community Blocklist  (qui je crois est gratos).

Par analyse du fichier de logs du reverse proxy (traefik).
Avant crowdsec j'ai 2 autres middlewares configurés sur traefik : geoblock et rate limit.

Si tu l'as pas déjà je conseille https://github.com/TheDuffman85/crowdsec-web-ui pour gérer en selfhosted les altertes/décisions.

Merci, pour geoblock du coup tu filtres par pays pour ne laisser passer que la France ?

 
Oui, avec https://github.com/david-garcia-garcia/traefik-geoblock même si j'avoue avoir un résultat mitigé.  
En tout logique si ça fonctionnait bien je ne devrais pas avoir d'ip nord américaine dans les logs de crowdsec puisque j'ai banni les us et le canada, mais j'en retrouve quand même.
C'est peut etre l'IP DB qui est moisie.

Merci, je vais rester sur Crowdsec et rate limit que j'avais déjà, je vais regarder un peu les collections disponibles. J'ai déjà repéré Traefik et Authelia, à tester

Ça va dépendre de ce que tu as sur la machine ou il y a CS.
Si tout est dedans et que toutes ont un log parsable, et que CS a une collection pour : boom tu passes les log à CS.
Sinon faut laisser les logs du reverse proxy à cs.
Ou alors tu peux aussi mettre un agent cs sur une autre machine .

Ha purée mais c’est top ça comme outils !
Faut que j’installe ça    
 
Sinon en mode gratuit on ne peut mettre que 3 blocklists dans CS…
 

En ce qui me concerne oui .
 

C’est possible.
Perso j’utilise maxmind qui est pas mal, mais parfois il y a des faux négatifs…
Mais c’est assez rare.
J’ai deux points de geoblockage : mon routeur Brume3 avec geoip-shell et mon reverse proxy NPmplus.

Merci, CS est en Docker sur ma machine dédiée à Docker et qui ne fait que du Docker. Je peux donc lui passer le socket Docker via le proxy et il ira récupérer les logs si besoin. C'est ma seule machine ouverte sur l'extérieur (quoi que j'ai une VM avec Wireguard aussi, je vais peut-être voir pour l'intégrer dans Docker)
 

Ah oui heureusement que tu as cité, j'avais loupé l'info, merci hot22shot j'ai connecté la console Cloud mais bon si je peux avoir quelque chose de local
 

Je vais regarder cette histoire de geolock aussi, merci

 
Je suis passé par pas mal de conf et d'outils différents (npm, authelia, authentik), en ce moment j'utilise traefik, tinyauth et pocket-id, pour du homelab c'est parfait pour gérer l'authentification par passkey (configurée dans mon proton pass).

Tinyauth est mieux qu'Authelia ?

 
Oui, enfin en ce qui me concerne je trouve ça plus simple. Le dév de tinyauth a spécifiquement fait son soft pour le homelab.
Ultra facile à intégrer à traefik en tant que middleware, ça te permet de mettre de l'auth devant des containers qui en sont dépourvus.
Et ça supporte l'oidc et ldap pour les containers qui l'acceptent.
 
Authelia j'avais trouvé ça limité à l'époque, ce qui m'avait fait migré sur Authentik (une usine à gaz pour un homelab) puis enfin sur tinyauth.

A tester à l'occasion mais je trouve Authelia plutôt bien fait de mon côté

Ha intéressant !
Moi qui suit en train de trouver Authentik ultra complexe... Je l'ai installé, mais je galère à comprendre comment ça fonctionne... trop d'éléments...
Faut que je regarde tinyauth :-)

Tu peux faire du TOTP ou Yubikey aussi avec Tinyauth ?

 
Alors TOTP c'est inclus : Tinyauth has built-in support for TOTP, enabling the use of authenticator apps to generate 2FA codes for logging in. (https://tinyauth.app/docs/guides/totp/)
Mais pas yubikey.
 
Perso j'ai ajouté pocket-id pour gérer les passkey et une connexion oauth avec google (restreinte à quelques emails bien sur).

Merci je le garde en alternative si Authelia me rend fou

Tant que j'y suis, vous utilisez quoi pour le backup de votre installation Docker ? S'il gère les BDD c'est un plus sinon je ferai du dump avant le backup. Merci

Snapshot bourrin de tout le dossier contenant les projets.

C'est une méthode mais je ne suis pas sûr de pouvoir faire ça et je préfèrerai avoir un truc propre

Salut !
 
J'installe et découvre Docker aujourd'hui pour la première fois.
J'ai regardé quelques tutos pour piger le principe.
 
La première image que je vais installer en local sera Kuma. Je vais ensuite voir pour prendre un VPS avec IP dédiée et y transférer Kuma puis y installer d'autres services.
 
J'ai quelques questions. Une fois le conteneur en route, prenons mon exemple de Kuma :
 - Comment est exposée cette machine sur internet ? à nue ? Faut-il installer un firewall ?
Ou je dis une énorme bêtise puisque ce n'est pas une machine qui tourne dedans, mais juste l'appli ?
Donc c'est juste le port du serveur web qui fait tourner Kuma qui sera ouvert ?
 
 - J'imagine qu'il y a aussi un serveur SSH par défaut qui y tourne ?
 
 - Serait-il possible de ne pas ouvrir de port côté internet? (pour y accéder via VPN, voir ci-dessous)
 
 - Est-il possible d'installer dans le conteneur Kuma un client Zerotier pour le connecter à mon "réseau privé" dans lequel tourne toutes mes machines (Home Assistant, serveur Windows avec BlueIris et d'autres services, nos PC, nos téléphones et tablettes Android, etc.)
 

Elle est exposé via un NAT entre ta machine et le conteneur (qui a sa propre IP interne), ou tu peux mapper directement sur la machine (mode host).
Y a d'autres modes, mais on va se contenter des trucs de base vu tes questions
 
Y a que les ports que tu auras explicitement ouverts qui seront accessible (de ton réseau donc, pas d'internet).
Pas besoin d'utiliser un firewall (enfin pas au niveau de Docker).
Y aura pas de SSH non, ou alors l'image est mal foutue
Tu pourras très bien y accéder en VPN (puisque exposé en local), pas besoin d'ouvrir sur Internet si t'en as pas envie (et si tu le fais ce sera explicitement depuis ton routeur, c'est pas Docker qui va le faire tout seul).
Pour zerotier j'ai pas de réponse, je connais pas bien, mais tu ne pourras pas l'installer dans ton image (un conteneur n'exécute qu'un service, donc à moins que Kuma l'embarque, faudra résoudre ton besoin d'une autre façon)

Attention il évoque aussi la possibilité d’héberger ça sur un VPS… donc la sécurité va entrer en compte et pas qu’un peu… firewall, VPN etc  

Ah oui j'avais pas vu cette info.
Si la machine a une IP publique faudra faire attention à l'exposition des ports, en effet

" mais on va se contenter des trucs de base vu tes questions "
J'utilise la virtualisation dépuis début 2000 (VirtualPC / Vmware) et j'étais responsable info pendant 15 ans, donc, tu peux y aller

Je n'ai juste pas encore totalement vu/compris la façon dont fonctionnent ces conteneurs.
Ca m'intéresse, donc si tu veux refaire ta réponse en prenant en compte que ce sera en ligne sur un VPS, je suis preneur

EDIT : et à la maison, je ne peux pas ouvrir de port, j'ai un routeur 4G qui n'a pas d'IP publique (d'où un réseau privé via ZeroTier qui connecte toutes nos machines, qui en plus  permet de ne pas exposer le moindre service sur le net ).

Pour chaque conteneur, tu choisis les ports qu'il expose. Il recevra le trafic entrant de la machine sur ce port. Rien d'autre depuis l'extérieur.
Pour la machine hôte, le container est le service exposé sur le port choisi.
 
Seule exception, le mode host, où le container a la même exposition que la machine hôte.

Donc comme je disais, par défaut, les réseaux sont en mode bridge (un bridge interne default, si tu utilise docker compose il crééra par défaut un bridge par "stack" ).
Ensuite tu peux exposer ton service en exposant ses ports (à la création du conteneur), auquel cas ça créé une règle de NAT entre l'interface réseau de la machine hote, et l'ip interne au bridge du conteneur.
Donc dans ton cas faut faire gaffe puisque ton hote sera sur une IP publique.

Le second mode, c'est le mode host, où ton conteneur accède aux interface de ta machine (plus simple, parfois nécessaire pour certains softs un peu mal fichus... mais un peu limite en terme de maïtrise/sécurité).

Ensuite, y a des drivers qui permettent de faire des choses un peu plus poussés, typiquement pour du mesh multi-host.

Et enfin y a un mode où tu peux utiliser des interfaces réseau virtuelles (ipvlan/macvlan/tap) pour bricoler un peu plus de choses derrières aux petits oignons pour des cas plus particuliers/problématiques (mais du coup ce sera moins user-friendly, faudra mettre les mains dans le camboui, mais rien d'insurmontable si t'as fait de la virtu/sysadmin).

Après comme dit je ne sais pas trop comment fonctionne zerotier.
Possible qu'il te faille le lancer sur ta machine hôte, et que cela monte une interface virtuelle qui te permet d'accéder au réseau VPN, et dans ce cas tu pourras à la création de ton conteneur préciser que le NAT doit être fait entre cette interface là (et pas la publique) et ton conteneur.

docker run .... -p 10.0.0.1:80:80 ton_image:vXYZ

Ici 10.0.0.1 est ton IP dans le VPN, 80 le port sur lequel tu exposes le services et le second 80 le port cible dans le conteneur.

Attention, si tu fait juste -p 80 ou -p 80:80, ça NATera sur toutes interfaces de ta machine, donc potentiellement l'IP publique

Bref, dans ton cas ce sera bien quand même de gérer le firewall sur ton VPS pour être sûr de n'exposer à l'extérieur que ce que tu souhaites.

Super, c'est parfaitement clair.
Merci beaucoup à vous deux
 
J'ai hâte d'avoir un peu de temps pour jouer avec tous ça.