Reprise du message précédent :

 
C'est une APPS installée via TrueNAS, via docker donc. Mais le reste, c'est de la magie gérée par TrueNAS
 
TrueNAS crée automatiquement les volumes nécessaires pour Komodo

 
Je retrouve mes stacks dans /mnt/.ix-apps/app_mounts/komodo/periphery_root/stacks et c'est la qu'il faut ses git clone/pull
 
Pour le cas spécial d'Harbor, j'ai juste rajouté le volume contenant le docker-compose.yaml dans le container periphery et dans la gui, lors de la création de la stack, j'ai choisi files on server et indiqué le chemin
 
Tu peux choisir le nom du fichier yaml.
 

 
Tu cliques sur le + Filepath et tu choisis ton docker-compose.yaml
 
Je n'ai pas cherché si c'était possible de configuer ça par défaut

Hmmm, je ne sais pas si mon installation est si différente de la tienne...
J'ai un serveur "Superviseur" sur lequel j'ai mis le Core et un Periphery, tout en docker
Sur un autre serveur, client, j'ai mis que le PERIPHERY.
 
Mais quoique je fasse, le déploiement d'une stack via mon dépôt gitea ne fonctionne pas :

Dans Info, je vois bien le contenu des fichiers docker-compose.yaml et compose.env que j'ai paramétré :

 
 
Mais pas moyen de faire le déploiement...
 
Voilà la configuration de la stack :

 
Je précise que le dépôt configuré sur le superviseur fonctionne très bien :

 
 
As-tu une idée de comment je peux faire pour déployer une stack à partir du dépôt gitea ?

Bizarre ton no such file or directory
 
Quand tu vas dans ton container periphery sur ton client, le répertoire que tu as mis dans RUN DIRECTORY existe bien ?

Non je ne crois pas …
Le dossier que j’ai mis dans RUN DIRECTORY est présent dans le core serveur dans le dossier du repository configuré dans la partie repos de komodo.
Je viens de vérifier dans le conteneur et c’est ici :
/repo-cache/mon-gitea.ndd.tld/user-gitea-docker-compose/main/latest/_LXC-254-Docker-Frigate-Nextcloud/donetick
 
Dans le periphery du client je ne retrouve pas les fichier du repos mais ça ça semble normal non ?
Puisque le dossier du repos est sur le core serveur.
 
 

Je dis peut être des conneries mais c’est le periphery sur ton «client » qui va créer le container sur le « client », donc peut être qu’il veut faire le git clone avant le docker compose up.
 
Et sans le répertoire il n’y arrive pas d’où le message  
 
Mais je me trompe peut être je le répète. Je n’utilise pas Komodo avec un periphery remote

Je trouverais ça logique mais comment lui faire faire le clone ?
 
Mais d’après ce qui est présent sur l’interface, je pense que c’est le core server qui va créer ce qu’il faut sur le periphery remote …
Je m’arrache les cheveux  

Je viens de tester et chez moi tout fonctionne

• J'ai installé periphery dans un container sur un second ordi faisant tourner docker

    Niveau conf, j'ai pris https://github.com/moghtech/komodo/ [...] mpose.yaml et j'ai changé
       * PERIPHERY_ROOT_DIRECTORY
       * PERIPHERY_PASSKEYS
       * le volume pour utiliser le même chemin que PERIPHERY_ROOT_DIRECTORY

• Je l'ai ajouté dans Komodo en tant que nouveau serveur
• J'ai dupliqué une stack d'un container simple (inadyn) se trouvant dans mon git et je l'ai fait pointer sur le nouveau server
• J'ai déployé la conf
• Le container a démarré sans problème

Je ne sais pas pourquoi ça ne fonctionne pas chez toi, tu vas devoir tout reprendre étape par étape

 
Jusque là c’est comme moi    
 

Là il faudrait que tu partages les chemins d’accès car moi j’ai moi aussi modifié ces variables    
 

Moi aussi  
 

 
Tu dupliques la stack depuis ton git comment ?
Tu l’as fait pointer sur le nouveau serveur comment ?
 

Si je crée une stack local depuis mon superviseur vers le client distant (une autre machine sur le lan, comme toi) la stack se déploie bien.
Mais la même stack depuis le dépôt git ne fonctionne pas je ne peux pas la déployer (voir les messages précédents)
 
En tout cas je te remercie de ta patience et de ton aide.
 
Ps : mes conteneurs komodo sont déployer via un utilisateur non root, comme tous les autres que je déploient via la ligne de commande.

 
Sur le serveur distant, j'ai créé un FS ZFS dédié pour periphery que j'ai monté dans /data/volumes/docker/komodo-periphery
Et dans le compose.yaml, j'ai mis
 

Quand je dis que j'ai dupliqué la stack, c'est dans komodo, pour éviter de tout refaire
Tu vas sur ta stack et haut à droite il y a un bouton copy.
Ca te crée une nouvelle stack identique avec le nom que tu as spécifié.
Tu vas ensuite dans ta nouvelle stack, puis dans config
La tu as une liste déroulante Server. J'ai choisi le server distant et j'ai déployé
 

 
Moi c'est une installation de base de docker et dockerd tourne en root que ce soit sur TrueNAS ou le LXC distant

Est ce qu'il y a des pros de docker bake dans la salle ?
 
J'ai un peu de mal à comprendre, ou du moins comment bien faire.
 
J'ai un Dockerfile multi-stage
 
base : apt install.....
 
builder : pip installl....
 
app : copy from builder
 
 
Dans ma conf bake, est ce que je dois pousser dans ma registry les images base/builder en plus de app ?
Est ce qu'un cache-from avec l'image final du précédent build app ne suffit pas ?
 
Car j'ai l'impression que niveau cache, il me recréé une "image" à chaque fois, et je vais me retrouver avec pas mal de stockage dans la registry (et oui j'ai aussi un delete auto, mais quand même)
 
 

 
 
Je ne suis pas sur de bien faire au final, même si au final un nouveau build va bien utiliser le cache et je passe de 20min a même pas 2 minutes

Bon,  je m'en suis sorti
 
1er Build 20 minutes, et on passe a 2 minutes avec le cache ^^

Salut    
Cross post avec le sujet debian  
 
 
Quelqu’un  utilise-il docker dans un LXC Proxmox, sous debian 13 ?
Car les maj de docker ci-dessous casse plein de chose :

 
ça casse la gestion du réseau, et les conteneurs ne peuvent plus démarrer, ni être créer...
J'ai passé plus d'une heure à tenter de résoudre le problème...
 
L'erreur que j'avais :

 
Avec diverses choses tenté, j'avais encore une autre erreur :

 
J’ai finalement fini par restaurer une sauvegarde de ce lxc.
Je précise que dans ce lxc j’ai plusieurs contenues docker dont swag (mon reverse proxy), AdGuard home , crowdsec , Audiobookshelf, des outils pour Plex dont Tautulli, Vaultwarden et quelques autres.
 
Après la maj docker plus aucun conteneur ne se lançait ni ne voulait se créer avec les erreurs mentionnées précédemment.
 
Si quelqu’un avait une solution je serais preneur    
En attendant je vais laisser ces maj de côté .
Chetgpt ou perplexity n’ont pas réussi à m’aider plus que ça … donc j’ai restauré une sauvegarde.
Et je pense que je vais migrer mes conteneurs dans un VM, enfin tous ceux qui ne nécessitent pas l’accès à l’igpu comme Immich et Frigate.

Tu n'es pas seul
 
https://www.reddit.com/r/selfhosted [...] s_morning/
 
A priori un bug dans la dernière version de containerd
 

https://github.com/opencontainers/runc/issues/4968

J'ai pas tout lu parce que je ne suis pas concerné, mais t'es pas un cas à part.

Perso je pige pas trop l'intérêt de faire du docker dans du LXC (double conteneurisation, forcément ça augmente les risques qu'un truc pète au niveau réseau ou droits), mais j'ai pas de besoin de passthrough de devices

 
Mon lxc est privileged.
C’est pour faire du iGPU passthrough que j’utilise un lxc.
 
En tout cas merci pour les infos ça me rassure que je ne soit pas le seul   mais punaise c’est un bug hyper gênant…    
 
Bref je vais revoir ma structure de conteneurs : je vais passer mes conteneurs qui ne nécessitent pas l’igpu.
Et je conserverai un lxc dédié à Immich et Frigate en docker pour le passthrough igpu.

Attention à Docker 29 (sorti il y a 2 jours), ça casse des trucs comme Traefik, Watchtower, etc.
 
Une solution temporaire est d'ajouter cette variable dans l'unité systemd Docker :
 

C’est ce dont je parlais juste au-dessus ? Ou c’est nouveau encore ?
 
Cette variable d’environnement doit être mise où ? Dans le compose des conteneurs ?
 
En tout cas j’ai eu le problème avec mon lxc Proxmox dédié à docker… pas avec la VM docker que j’ai à côté.

Faut lire hein il a tout dit  

Oh my ! J’avais raté la petite info    
My bad    
 
Merci  

Ha la gueulle, je pensais qu'une VM ne serait pas touchée... mais sisi, j'ai fait un apt upgrade XD
Et bah ça n'a pas loupé, Portianer tout cassé... j'accède bien à l'UI, mais impossible de lancer le noeud...
Je peux créer, recrééer un conteneur, mais rien n'y fait.
J'ai restauré ma VM    
(purée, que c'est terriblement pratique proxmox pour ça !!!)
 
En fait on a deux séries de MAJ problématiques :
Celle de containerd qui casse des choses pour les LXC
et
celle docker 29 casse en effet plein de trucs : Watchtower, Portainer ...

 
on n'est pas gâté XD
Je vais attendre avant de refaire des MAJ XD

Y'a encore des sysadmin qui mettent leurs stacks à jour sans attendre quelques semaines (sauf correction d'une faille critique)
 
Vous faites ça aussi à la COGIP, sur la prod, un vendredi en fin de journée avant de partir en congés aussi ?

Je ne suis pas sysadmin    
C’est juste mon passe temps et aussi pour faire tourner des services intéressants.
 
Si personne n’essuyait les plâtres au début , tout le monde les subirait ensuite    
 
Bref…
 
Et soit dit en passant , la maj de containerd contient un fix d’une faille critique exploitée(je n’ai pas de détail…) et j’espère que je ne suis pas une cible  

Je dirais pas que c’est Docker 29 qui est problématique, c’est plutôt que certaines applis comme Traefik / Portainer utilisaient une très vieille version de l’API.
 
https://www.docker.com/blog/docker-engine-version-29/
 

Si t'as pas le détail, comment peux-tu dire que c'est une faille critique ? Et surtout est-ce que ça l'est dans TON contexte à toi ?
Parce que sur containerd, en général ça se limite à des failles locales, donc accessibles uniquement à des gens qui ont accès à l'OS de ta machine (ça réduit en général beaucoup la criticité des failles, et l'urgence à les corriger).

Je l’ai lu sur l’une page qui parlait des soucis rencontrés , voir sur GH sur l’issue créé pour ça …
 
Mais je ne sais pas si je suis vraiment touché dans mon contexte où moi seul ai accès aux machines .

Ha un fix temporaire le temps que nos apps docker veulllent bien se mettre à jour    
Merci  

Je confirme que la création d'un fichier /etc/docker/daemon.json contenant :

{
  "min-api-version": "1.24"
}

permet de faire tourner watchtower avec docker 29.

Traefik a été mis à jour en version 2.11 / 3.6 pour corriger ce soucis de version d’API.

Ha ça bouge    
Y a plus qu’à attendre que les autres bougent aussi  

Est-ce qu’il y a ici des utilisateurs de Nginx Proxy Manager et Crowdsec ?
Je n’arrive pas à configurer Crowdsec sur une Debian 13 (VM Proxmox)…