Ça m'arrive souvent d'avoir un léger problème que je peux régler en modifiant la configuration d'un service.
Si j'ai bien compris dans le modèle Docker, je dois modifier la configuration utilisée pour générer l'image, régénérer l'image, relancer le conteneur avec la nouvelle image. C'est beaucoup trop lourd pour moi, surtout que souvent je dois modifier plusieurs fois la configuration avant de trouver ce qui convient le mieux.
Faut voir ce que tu entends par lourd, mais reconstruire une image en changeant les fichiers de configuration, c'est de l'ordre de la demi-seconde. Je n'irais pas jusqu'à parler de lourd.
Tu peut aussi pour ta période de balbutiement binder ta conf de l'hôte vers le container.
Une fois que tu as ta conf qui va bien, tu créer ton image final et tu lui fais faire le tour de la Terre aussi souvent que tu le souhaite.
Si j'ai bien compris LXC + btrfs me permettent de faire ça, je fais un snapshot du conteneur, puis je l'exporte.
Non, un bon FS va te permettre de maintenir la cohérence de tes fichiers, mais il y a un niveau application1 qui ne peut pas être géré par le FS. Dans des cas simples ça fait l'affaire (tu récupère des mails, tu les stocke en maildir si tu n'a aucun indexe sur tes mails) dans un paquet d'autres cas ça ne marchera pas aussi bien (et selon la qualité de l'appli soit elle crash, soit elle ne récupère que ce qu'elle peut). C'est pour ça qu'il existe des bases des bases de données (au sens large) qui vont permettre de fournir à l'application un modèle de cohérence de plus haut niveau (par exemple au travers des transactions SQL).
un exemple simple, c'est tu écris un fichier json sur ton disque. Ton appli se prend un SIGKILL entre les 2 yeux. Le FS te garanti que la suite d'octet que tu lui a demandé d'écrire et correctement écrite (écrite et dans l'ordre), mais il est incapable de savoir si ton fichier était totalement écris. ↩
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par barmic 🦦 . En réponse au journal L'Écosystème containeurs. Évalué à 2.
Faut voir ce que tu entends par lourd, mais reconstruire une image en changeant les fichiers de configuration, c'est de l'ordre de la demi-seconde. Je n'irais pas jusqu'à parler de lourd.
Tu peut aussi pour ta période de balbutiement binder ta conf de l'hôte vers le container.
Une fois que tu as ta conf qui va bien, tu créer ton image final et tu lui fais faire le tour de la Terre aussi souvent que tu le souhaite.
Non, un bon FS va te permettre de maintenir la cohérence de tes fichiers, mais il y a un niveau application1 qui ne peut pas être géré par le FS. Dans des cas simples ça fait l'affaire (tu récupère des mails, tu les stocke en maildir si tu n'a aucun indexe sur tes mails) dans un paquet d'autres cas ça ne marchera pas aussi bien (et selon la qualité de l'appli soit elle crash, soit elle ne récupère que ce qu'elle peut). C'est pour ça qu'il existe des bases des bases de données (au sens large) qui vont permettre de fournir à l'application un modèle de cohérence de plus haut niveau (par exemple au travers des transactions SQL).
un exemple simple, c'est tu écris un fichier json sur ton disque. Ton appli se prend un SIGKILL entre les 2 yeux. Le FS te garanti que la suite d'octet que tu lui a demandé d'écrire et correctement écrite (écrite et dans l'ordre), mais il est incapable de savoir si ton fichier était totalement écris. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll