à l'époque où j'avais monté ce serveur, docker compose était présenté comme un truc à utilisé uniquement pour les développements. Et vu la simplicité de Swarm (même avec un seul node), j'ai pas eu à changer mes habitudes.
Donc pas besoin de le "configurer" qui est le reproche que tu fais a portainer si j'ai bien compris.
Ça me faisait déjà chier d'avoir une dépendance aussi lourde juste pour gérer le redeploy. Mais ouais, en plus le fait de devoir pré-créer la stack dans portainer m'a incité à chercher une solution plus simple
J’étais tombe notamment sur Gantry qui est specifique a swarm et qui pourrait t’intéresser
Merci !
Pour ma part, j'ai considéré que le coup de la clé SSH avec droits root sur Github était rédhibitoire
tu noteras quand même que dans ma config la clé SSH ne permet que de se connecter à un simple utilisateur qui n'a accès qu'à un sous ensemble de docker.
mais ouais, comme j'ai pas encore configuré docker ou podman en rootless; si quelqu'un choppe la clé, il peut très bien faire docker --context monserveur run -it -v /:/mnt ubuntu et là je suis mort :D
[^] # Re: Joli
Posté par jtremesay (site web personnel) . En réponse au journal Docker swarm et CI, les contextes à la rescousse. Évalué à 4.
à l'époque où j'avais monté ce serveur, docker compose était présenté comme un truc à utilisé uniquement pour les développements. Et vu la simplicité de Swarm (même avec un seul node), j'ai pas eu à changer mes habitudes.
Ça me faisait déjà chier d'avoir une dépendance aussi lourde juste pour gérer le redeploy. Mais ouais, en plus le fait de devoir pré-créer la stack dans portainer m'a incité à chercher une solution plus simple
Merci !
tu noteras quand même que dans ma config la clé SSH ne permet que de se connecter à un simple utilisateur qui n'a accès qu'à un sous ensemble de docker.
mais ouais, comme j'ai pas encore configuré docker ou podman en rootless; si quelqu'un choppe la clé, il peut très bien faire
docker --context monserveur run -it -v /:/mnt ubuntuet là je suis mort :D