L'Écosystème containeurs
En 2013, l'entreprise Docker se lance et permet de facilement utiliser des containeurs
LXC, système de virtualisation au niveau OS. Les containeurs permettent d'isoler
et de distribuer des logiciels.
Des outils ont été créé autour des containeurs, permettant de faire grandir cet écosystème, culminant dans la création de système de containeurs concurrent à base de briques open-source. Docker (l'entreprise) à remis au pot commun en créant le projet libre Moby ensembles de briques dont :
* une bibliothèque de composants backend conteneurisés (gestion de volume, du réseau, etc.),
* un framework pour assembler les composants dans une plateforme de conteneurs autonomes et des outils pour construire, tester et déployer des artefacts pour ces assemblages,
* un assemblage de référence, appelé Moby Origin, qui est la base logicielle ouverte pour Docker, ainsi que des exemples de systèmes de conteneurs utilisant différents composants de la bibliothèque Moby ou d'autres projets.
l'Open Container Initiative et la cloud native computing foundation contribuent à cet écosystème. Ils ont produit des spécifications, Runtime Specification (runtime-spec, pour exécuter des containeurs) et Image Specification (image-spec, pour construire des images de containeurs), ainsi que des implémentations de réfèrence (runC pour la runtime-spec).
En alternative à docker pour contruire des images compatibles OCI, on peut se tourner vers buildah, orca-build ou d'autres. Certaines se basent sur des Dockerfile, ou un autre format perso.
Pour exécuter des containeurs, ils y a containerd, CRI-O, rkt (bon celui là est laissé de côté au profit des deux précédent), etc.
Je recommande la présentation "Docker est mort, vive Docker" par Alexis "Horgix" Chotard qui m'a fait m'intéresser aux alternatives actuelles. La présentation ne fait que six minutes, ne vous privez pas.
# Docker et LXC
Posté par Astaoth . Évalué à 4.
"En 2013, l'entreprise Docker se lance et permet de facilement utiliser des containeurs
LXC, système de virtualisation au niveau OS."
Me semblait que Docker et LXC étaient des technos de containers différentes, je me suis trompé ?
Emacs le fait depuis 30 ans.
[^] # Re: Docker et LXC
Posté par chdorb . Évalué à 8.
Au tout début, Docker se basait sur des conteneurs LXC, il me semble qu'il ont juste ajouté leur toolchain; ensuite ils ont très rapidement développé leur propre techno de conteneurs.
[^] # Re: Docker et LXC
Posté par Anonyme . Évalué à 5.
LXC et Docker utilisent tous les deux les espaces de nom et les cgroups. Ce sont en quelque sorte deux interfaces utilisateurs à une même fonctionnalité du noyau Linux.
[^] # Re: Docker et LXC
Posté par Astaoth . Évalué à 2.
Ok, mais la ressemblance actuelle s'arrête là. Docker est stateless là ou LXC est statefull. Chez nous on utilise LXC de la même façon que des VMs, là où Docker sert à déployer des applis uniquement, branchées à une BDD ou un stockage externe.
Emacs le fait depuis 30 ans.
[^] # Re: Docker et LXC
Posté par claudex . Évalué à 3. Dernière modification le 18 mars 2020 à 18:38.
Tu as les volumes docker pour du statefull.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Docker et LXC
Posté par barmic 🦦 . Évalué à 2.
C'est pas une bonne idée. Il est difficile de faire des sauvegardes cohérentes via des volumes docker par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Docker et LXC
Posté par 16aR . Évalué à 2. Dernière modification le 25 février 2020 à 13:52.
C’est ça.
Construire autour de LXC devenait plus dur, et du coup ils ont fait leur propre implémentation en Go plutôt que de manager du LXC depuis Go.
[^] # Re: Docker et LXC
Posté par flan (site web personnel) . Évalué à 7.
Si je ne me trompe pas, Docker utilisait au début des cages LXC, mais maintenant il utilise les mêmes appels système pour arriver à la même chose (isolation via les cgroups, par exemple), mais y accède directement au lieu de passer par LXC.
# k8s
Posté par Jarvis . Évalué à -10. Dernière modification le 25 février 2020 à 06:41.
Marrant de faire un journal en 2020 sur les containers sans parler orchestration et kubernetes.
[^] # Re: k8s
Posté par zurvan . Évalué à 10.
Marrant de faire un commentaire en 2020 pour critiquer ce journal, sans apporter un seul éléments explicatifs au sujet des orchestrateurs et de kubernetes.
Perso je n'y connais rien, donc la vidéo mise en lien dans le journal m'a bien intéressé !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: k8s
Posté par Gart Algar . Évalué à 10.
ah mais oui, mais je ne voulais pas en faire trop. mon but était de parler des containeurs et des alternatives a Docker, pas de comment déployer, gérer etc. même si cela fait bien évidement parti du cycle de vie en 2020. Peut-être un prochain journal, de ta part ou de la mienne
# Et plus encore
Posté par davandg . Évalué à 3.
Il y a des projets qui poussent l'isolation encore plus loin, et qui sont plus ou moins compatible avec les dockerfiles, CRI et/ou OCI.
On peut, par exemple, citer:
- firecracker, le moteur derrière amazon lambda. Ce sont des micro-VM avec un kernel linux modifié pour redirigé certaines requêtes systèmes vers le host.
- gVisior: on pourrait dire qu'ils font des container avec du firejail intégré (donc on peut filtrer les appels au kernel)
- kata container. Dans le même genre que firecracker, mais avec une approche plus orienté "unikernel" (donc les micro-VMs sont plus indépendantes). Ils veulent être le plus compatible possible avec docker.
[^] # Re: Et plus encore
Posté par 16aR . Évalué à 2.
s/gVisior/gVisor/
[^] # Re: Et plus encore
Posté par mathgl . Évalué à 1.
C'est souvent mis en avant dans le cas où on a pas confiance dans ce qu'on fait tourner.
Mais, ça coûte sur les performances.
# BastilleBSD
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Pour compléter, il faut aussi citer BastilleBSD, qui repose sur les jails de FreeBSD.
[^] # Re: BastilleBSD
Posté par Kwiknclean . Évalué à 2.
Je m'attendais à un réel outil d'automatisation mais après un rapide coup d'oeil à la documentation il se trouve que ce n'est encore qu'un énième wrapper aux jails, avec de surcroit une adhérence à ZFS j'ai l'impression, dommage.
Ca n'apporte pas grand chose de plus que ezjail, ou que le très bugué iocage …
# Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 6.
Bonjour mesdames et messieurs,
Contexte :
docker j'ai juste testé et vu qu'avec quelques lignes tapées dans un terminal je pouvais installer automatiquement plein de choses …
Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)
Question :
Pour faire du test ok je peu déployer super vite des infra logicielles (web, traitement, bdd … )
très bien
Mais dans un contexte de PROD et d'exploitation :
quand il y a un soucis de performance comment cela se passe ?
déjà avec les machines virtuelles la patate chaude circule pas mal, et certains problèmes liés à des drivers réseaux peuvent être difficile à cerner, mais la avec les containers cela risque d'être pire
Si quelqu'un pouvait faire part de son expérience, je suis sur que cela serait bénéfique à tous …
[^] # Re: Petite question de béotien
Posté par CrEv (site web personnel) . Évalué à 2.
Des prods sous Docker c'est pas ce qui manque.
C'est quoi un soucis de performance ?
En fait c'est hyper mega vague qu'il est pas vraiment possible de répondre quoi que ce soit.
Et bon c'est pas parce que tu as des conteneurs que tu n'as plus d'ops qui gèrent ta plateforme. Donc oui si tout le monde se refile la patate chaude aujourd'hui, tu peux remplacer tes vms par des conteneurs ou par des binaires que ça ne change absolument rien au problème.
[^] # Re: Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 1.
Je le supposais aussi
Un traitement ou une application qui ont des temps de réponses dégradées
on voit le sablier par exemple, alors que d'habitude non
Pour être plus précis : existe t il quelque chose qui te permette de voir si un container devient fou et bouffe plus de CPU que la normale ou génére des I/O de manière exagérées …
[^] # Re: Petite question de béotien
Posté par CrEv (site web personnel) . Évalué à 2.
Ça reste mega vague.
Si la question est de savoir s'il y a de quoi faire du monitoring de conteneurs, avoir de l'alerting, etc, la réponse est oui.
Sachant que Docker reste, contrairement à une VM, juste de l'isolation autour de processus.
Et après il existe plein d'outils si tu veux inspecter ce qui se passe, dans le genre puissant (mais encore une fois ça reste vague) tu peux jouer avec
sysdigpar exemple.[^] # Re: Petite question de béotien
Posté par Crazy Diver . Évalué à 1.
Je suis tombé il y a peux sur cet article qui pourrait répondre à ta question :
https://www.redhat.com/en/blog/examining-container-performance-rhel-8-pcp-and-pdma-podman
[^] # Re: Petite question de béotien
Posté par 16aR . Évalué à 7.
Je monitore mon serveur mi-pro/mi-perso, docker tourne et gère 50 containers (serveur mail, nextcloud, subsonic, wordpress, hugo, appli web Go perso, gitea, ldap, perkeep, registry docker, etc). J’ai rajouté cAdvisor + prometheus + grafana, et je peux voir ce que chaque container bouffe en terme de CPU/réseau/IO en temps réel. J’avais suivi ce tuto là qui explique bien : https://blog.eleven-labs.com/fr/monitorer-ses-containers-docker/ . En vérité, ça me rajoute 20 lignes dans mon
docker-compose.yml, donc c’est simple. Et tout ça tourne sur une dédibox à 29,99€, donc 4-core + 8Go de ram.Mon problème actuel, c’est le manque d’espace disque, mais ça vient de mon nextcloud qui commence à être gourmand. Parce que JE suis gourmand.
[^] # Re: Petite question de béotien
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 25 février 2020 à 11:36.
De mon expérience (qui vaut ce qu'elle vaut), je n'ai pas vu de différence notable de performance entre un code dans un containeur et en bare metal.
Ce qu'il faut voir c'est qu'il ne s'agit pas d'une indirection au sens que tu as dans une machine virtuelle où tu as des drivers spécifiques qui réimplémentent des appels systèmes en espace utilisateur. Ici il est question de 3 techno :
Tu as des outils d'admins qui peuvent te montrer tout ça (par exemple
ps -o pidns,pid,cmd -A).C'est ce qui fait la simplicité du truc, mais c'est aussi ce qui fait que le niveau d'isolation est loin d'être aussi fiable qu'avec des machines virtuelles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite question de béotien
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
"Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)"
Il faut éviter d'écrire des âneries pareilles, après il y a des décideurs pressés qui le lisent et qui le croient.
[^] # Re: Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 4.
Le disailledeur préssé ne lit pas Linuxfr … ou alors après 01Informatique si il reste du temps avant la prochaine réunion.
[^] # Re: Petite question de béotien
Posté par El Titi . Évalué à 3.
Il faut vivre sur une autre planète pour ne pas réaliser qu'un containeur sans plateforme pour l'orchestration, la sécurité, le monitoring, le service mesh, et j'en passe et des meilleures, on ne va pas très loin.
Bref y'a un truc qu'on appelle dev…ops
[^] # Re: Petite question de béotien
Posté par Anonyme . Évalué à 3.
DevOps ne veut pas dire « un Dev qui fait de l’Ops » et ce n’est pas non plus un titre de poste, c’est une manière d’organiser le travail qui veut rapprocher les équipes de développement et les équipes d’Ops (et qui n’a, à ce que je sache, pas vraiment de définition).
Si tu parle du poste, tu parles probablement de DevOps Engineer (quoi que ça puisse vouloir dire) ou de Site Reliability Engineer (SRE).
[^] # Re: Petite question de béotien
Posté par El Titi . Évalué à 1.
Non, je faisais allusion au fait que le devops se veut une organisation du travail qui vise rapprochement entre dev et ops pour plus d'efficacité, ce qui est une tendance lourde, mais que pour autant le dev n'a pas vocation à se substituer aux ops.
[^] # Re: Petite question de béotien
Posté par El Titi . Évalué à 1.
J'avis oublié les guillemets:
"organisation du travail qui vise rapprochement entre dev et ops pour plus d'efficacité"
[^] # Re: Petite question de béotien
Posté par fasthm . Évalué à 4.
Disons plutôt Site-wide Reliability Global Strategy Manager, ou Global Engineering Failure Mitigation Officer, ça claque quand même plus.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Petite question de béotien
Posté par El Titi . Évalué à 2.
Et sinon si tu es vraiment béotien, voici une petite série de vids qui vont à l'essentiel:
https://www.youtube.com/watch?v=4J_00mQ5BAs
https://www.youtube.com/watch?v=caXHwYC3tq8
https://www.youtube.com/watch?v=NChhdOZV4sY
https://www.youtube.com/watch?v=M6F6GWcGxLQ
https://www.youtube.com/watch?v=RwbIMBSr8o8
https://www.youtube.com/watch?v=ucHwp1jUS2w
Et il y en a pas mal d'autres sur la chaîne
[^] # Re: Petite question de béotien
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Alors déjà : non (voir plus bas).
Ensuite, c'est marrant que tu dises ça, alors que plus loin :
Quand tu as ça, tu fais justement appel… à un admin système.
À moins que tu sois tout seul à tout faire dans ta boite, ce n'est pas aux développeurs de s'occuper de la prod, de s'occuper de l'infra et de ses problèmes. C'est aux admin sys que tu crois qu'ils vont disparaître.
Admin sys est un vrai travail, un vrai métier, qui est utile pour faire en sorte que ce que produisent les développeurs (du code, des services et éventuellement sous forme de conteneurs Docker), soit opérationnel dans la vrai vie (le laptop du dev, ce n'est pas la vrai vie, c.a.d, n'a pas les contraintes d'un environnement de production).
Opérationnel veut dire :
etc etc etc…
Et pour répondre plus précisément à ta question, quand il y a des soucis de perfs, d'abord c'est grâce à l'admin que tu peux savoir d'où ça vient (à moins que toi en tant que dev, tu n'a rien d'autres à foutre que de surveiller et d'analyser les problèmes de prod), et ensuite, c'est soit la faute à l'admin sys (ne dimensionne pas/ne configure pas correctement les machines et les réseaux), soit la faute à l'architecte logiciel (ex: pas de système de cache ou a fait des choix techniques merdiques), soit la faute au développeur qui a codé de la m..de, avec par exemple des empilements de framework à tout va, des milliers de paquets npm, des algo foireux ou encore a utilisé Java [1]
Disclaimer: je suis avant tout un dev, mais aussi admin sys à mes heures perdues, et je n'aurais jamais cette prétention de pouvoir remplacer un vrai admin sys. C'est juste impossible de tenir les 2 rôles correctement dans une boite qui veut grandir.
[1] oui je sais, on n'est pas vendredi. Désolé.
[^] # Re: Petite question de béotien
Posté par Kerro . Évalué à 10.
Soit la faute des décideurs qui ne font pas confiance à leurs subalternes, ou qui ne veulent pas embaucher les bons profils, ou dépenser ce qu'il faut en infra, ou régler les problèmes internes, etc.
J'ai travaillé comme admin sys dans une entreprise de 4 personnes qui fournissait du SaaS aux groupes Carrefour et MédiaPost.
Pour les premiers client, ça tournait sur un serveur dédié chez un hébergeur.
Puis le nombre de clients à doublé. Même serveur. C'est là que je suis arrivé car le patron n'était pas content d'entendre des critiques à propos de lenteurs et de bugs. J'ai amélioré les requêtes SQL (pas le boulot d'un admin sys mais bon), géré les index (idem), ça passait bien.
On est arrivé à avoir la totalité des Carrefours de France. Les chefs de rayons mettaient plus de 10 minutes à avoir le résultat de leurs requêtes. Mon parton n'a pas voulu avoir un second serveur, puisqu'un informaticien a doublé les performances, pourquoi il refuse de le faire à nouveau ? (un génie ce mec, il a inventé l'amélioration exponentielle).
Je suis parti. La boîte a fermé quelques mois plus tard car Carrefour a refait l'application en interne.
C'était vendu 10.000 € annuel par magasin (200 magasins), soit 500.000 € de CA par employé, patron compris (plus ce qui était facturé à MédiaPost, peut-être pas cher).
[^] # Re: Petite question de béotien
Posté par Anonyme . Évalué à 8.
Tu pourra toujours faire une demande aux admin. sys., mais vu ta premier remarque, pour toi ça sera par ticket.
[^] # Re: Petite question de béotien
Posté par flan (site web personnel) . Évalué à 3.
Il y a beaucoup d'outils (comme k8s) qui sont pensés pour surveiller ta plate-forme Docker (un groupe de dockers pensés pour fonctionner ensemble, comme un Docker base de données, un Docker Apache/nginx et un Docker application PHP) et automatiquement activer des Docker supplémentaires quand ta plate-forme est surchargée.
Sur le papier, il n'y a donc pas de problème de performance.
Par contre, ça fonctionne bien avec des applications qui ont été pensées pour.
D'un autre côté, j'ai le sentiment que beaucoup de problèmes de perfs sont liées à des erreurs de développement (le nombre d'applications web que j'ai vu ramer avec quelques dizaines d'utilisateurs simultanés alors qu'il n'y a pas de calcul faramineux derrière…) plus qu'à un réel besoin : tout le monde n'est pas Google/Facebook/…
[^] # Re: Petite question de béotien
Posté par farib . Évalué à 10.
Docker c'est une bénédiction pour les admins, ça rajoute des couches et des couches d'outils et de tools a comprendre, configurer, développer, débogguer, déployer, migrer. Bref, du travail a foison.
[^] # Re: Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 6.
je vais faire une réponse globale :
D'abord merci a tous j'ai appris quelques trucs ou mieux compris d'autres
Et pour clarifier
=> Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)
je disais cela en tant que sysadmin … sinon je me permettrais pas …
mais dans l'informatique de gestion on a toujours quelques guerres de retard, j'en ai encore quelque uns qui font la différence entre cloud et hébergement.
mais bon tant que les devs et autres grosses têtes n'auront pas été upgradé en … bon sens, nous aurons (les sysadmins) du travail c'est sur. (zut c'est pas vendredi désolé … )
Et je posais la question car justement les problemes de perfs, enfin surtout dans mon cas, et certains le confirme d'ailleurs, c'est pour les sysadmins …
[^] # Re: Petite question de béotien
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 25 février 2020 à 18:14.
Avoue que vous avez inventé et promu le compliquai Kubernetes uniquement pour vous donner du boulot !
Côté dev, on connait le truc, on l'a fait avec Java il y a 20 ans.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Petite question de béotien
Posté par Tonton Th (Mastodon) . Évalué à 3. Dernière modification le 27 février 2020 à 01:40.
ET IL Y A 60 ANS AVEC JCL :)[^] # Re: Petite question de béotien
Posté par CrEv (site web personnel) . Évalué à 6.
Et c'est donc quoi un devops ?
C'est marrant on peut écrire exactement l'inverse.
[^] # Re: Petite question de béotien
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Un dev biclassé ops ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Petite question de béotien
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Le devops est une personne sur le chemin du badge scout… pardon du badge IT complet. Il cherche à avoir son badge sysadmin, son badge développeur, son badge sécurité, son badge architecte, son badge testeur, etc., et ensuite il pourra avoir le badge complet IT fullstack (explication pour geeks: les badges sont un peu comme les autocollants que l'on met sur les ordi portables, mais là c'est épinglé sur ta chemis… ton t-shirt).
[^] # Re: Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 2.
J'aurais pas dit mieux :)
[^] # Re: Petite question de béotien
Posté par Kwiknclean . Évalué à 2.
C'est exactement pour ça qu'on est pas près de se passer des sysadmins :-)
[^] # Re: Petite question de béotien
Posté par Tonton Th (Mastodon) . Évalué à 2.
Et qui va fabriquer tes boiboites docker ?
[^] # Re: Petite question de béotien
Posté par Christophe B. (site web personnel) . Évalué à 4. Dernière modification le 28 février 2020 à 09:05.
Un truc qui vient de sortir … skynet je crois
# rkt - origin
Posté par CrEv (site web personnel) . Évalué à 2.
C'est plus que ça pour
rkt, le projet est mort et archivé : https://github.com/rkt/rkt/issues/4024Je sais pas exactement ce qu'est Origin, j'en trouve référence dans l'annonce initiale de moby mais c'est tout. Après c'est juste une histoire de terme,
dockerle daemon qui tourne c'est bien directement basé surmoby.[^] # Re: rkt - origin
Posté par Gart Algar . Évalué à 1.
merci, j'étais resté à l'annonce de l'archivage du projet du point de vue de la cncf
Pour Origin, je pense que c'est pour différencier le projet qui sert de base pour docker, et l'ombrelle générale
# rootless
Posté par Octabrain . Évalué à 4.
J'ai hâte que podman soit packagé et fonctionne bien avec son mode "rootless", qu'on soit plus obligé de se taper du "sudo" à chaque commande docker quand on est dev/utilisateur.
# Docker...
Posté par gnumdk (site web personnel) . Évalué à 10. Dernière modification le 25 février 2020 à 16:35.
Docker, c'est bien le truc qui tourne en root et qui permet à n'importe quel utilisateur ayant un accès pour créer des conteneurs de passer root sur le socle?
Bravo, on arrête pas le progrès…
[^] # Re: Docker...
Posté par AlexTérieur . Évalué à 7.
Il n'y a pas que ça… Ajoutez un bon quintal de difficultés si des bugs apparaissent, saupoudrez sur une consommation énorme d'espace disque (moi qui souriais sur la solution Flatpak…), un fonctionnement opaque pour les 9/10è des utilisateurs (comment prendre la main sur un composant qui déconne dans le container même ? question à 10 balles mais peut-être plus)… Non sans troll, il n'y a pas des alternatives ?
[^] # Re: Docker...
Posté par barmic 🦦 . Évalué à 4.
Ça consomme ce que tu lui demande de consommer, hein ? Tu peut utiliser des images qui font la taille d'une planète, mais non seulement tu n'es pas obligé, mais en plus ce n'est pas du tout le sens de la marche.
On peut dire ça d'énormément de choses. Ça n'est pas un argument en soit.
Tu as des techniques simples pour ça qui te permettent d’exécuter un shell sur ton container et de faire bien ce que tu veux. Mais ce n'est pas du tout la philosophie du truc. Garder des containers immutables permet d'avoir les comportement les plus reproductibles possibles. La possibilité d'en instancier sans difficulté fait que tu n'a pas à réparer à l'arrache un contenaire en cours de route. Ce dont on a besoin c'est de monitoring et de tracing pour savoir ce qu'il se passe à l'intérieur d'un point de vu métier et ça tombe bien l'outillage existe pour ça.
Comprends bien, je ne dis pas que c'est le graal, juste que tes arguments ne tiennent pas vraiment.
Qu'est-ce qui serais la conteneurisation parfaite pour toi ? Parce qu'en soit aller triturer l'intérieur d'un conteneur quelque soit la techno, c'est assez contre-intuitif. Que voudrais-tu comme cloisonnement ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Docker...
Posté par jyes . Évalué à 2.
Ça dépend du rôle du conteneur, si l’on souhaite juste de séparation de processus un peu plus forte qu’avec les droits Unix de base (en gros, avoir des root locaux à des services), pour tester l’installation d’un paquet par exemple, et des règles sympas de gestion du réseau (comme des machines virtuelles mais à coup quasi nul sur les perfs) etc, ce n’est pas contre-intuitif de triturer l’intérieur d’un conteneur. Par contre, ce n’est effectivement pas du tout le créneau de Docker.
Ben si. LXC par exemple (et son successeur LXD) servent exactement à ça. Et utilisent la même machinerie que Docker côté noyau.
[^] # Re: Docker...
Posté par AlexTérieur . Évalué à 2.
[^] # Re: Docker...
Posté par barmic 🦦 . Évalué à 2.
Tu peux créer des containers de plusieurs Eio si tu veux. Si ton image fait 2Gio c'est que la personne qui l'a créé a mis 2Gio de dans. Ils ne viennent pas de nulle part.
Docker ne permet pas de faire de la déduplication avec le système hôte. Par contre entre ses images c'est possible. Une image est construite par layer (chaque modification de l'image crée une layer en plus). Ces layer sont automatiquement réutilisé.
Par exemple si tu par d'une image centos, que tu installe apache, php-fpm et MySQL dessus pour enfin ajouter ton application php. Si tu as d'autres applications php avec le même setup, ils vont presque tout partager. (l'image décrite est dégueulasses, ne faites pas ça chez vous)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Docker...
Posté par jyes . Évalué à 3. Dernière modification le 27 février 2020 à 09:05.
En l’occurence avec LXC, tu peux faire un conteneur qui ne consomme rien en espace de stockage. Tu peux par exemple lancer ton postfix ou ton nginx installé sur ton sysème dans des conteneurs LXC. De tels conteneurs verront donc le même système de fichiers que on système, mais tourneront dans un espace de processus séparé (il ne pourront pas lister ceux qui tournent sur l’hôte), verront une interface réseau séparée (sur laquelle tu appliquer d’autres règles de parefeu que sur le système), etc, en s’appuyant sur les CGroups. Voir la commande « lxc-execute » pour ça.
Bon avec cette utilisation des conteneurs LXC, on s’éloigne déjà beaucoup du conteneur comme outil de pseudo-virtualisation. Ça pour le faire, il faut exécuter un init (plutôt que directement postfix ou nginx) dans le conteneur après lui avoir installé un système minmal complet dans un chroot. Voir la commande « lxc-start » pour ça. Tu peux aussi installer un système minimal, puis nginx et postfix dans deux conteneurs à partir d’instantanés BTRFS et/ou d’UnionFS par rapport au conteneur système minimal. Après, si tu fais tout ça à la main, c’est dommage, car c’est justement à ça que sert Docker, fabriquer des pseudo-machines virtuelles en superposant des briques réutilisables. Évidemment tout n’est pas réutilisé, ça n’a pas la granularité de ton gestionnaire de paquet qui partage la moindre bibliothèque entre tous tes logiciels, mais c’est quand-même l’objectif du truc à la base. Et une fois que c’est facile de fabriquer de telles pseudo-machines virtuelles, autant les rendre immuables et contrôler ainsi parfaitement leur contenu, et pouf, voilà le Docker moderne.
Au final, ce n’est pas étonnant si pour commencer Docker s’appuyait sur LXC, et même maintenant qu’il ne le fait plus Docker et LXC utilisent de toute façon les mêmes possibilités offertes par le noyau Linux. Tu peux refaire du Docker à la main à partir de LXC, mais si à la fin tu as refait tout Docker, autant utiliser Docker directement, ce sera beaucoup plus pratique.
Donc pour répondre à ta question :
Non, car ça n’a pas de sens, un conteneur contient un environnement d’exécution, donc ce n’est pas une bibliothèque qu’on conteneurise mais éventuellement les programmes qui l’utilisent. Si veux conteneuriser, à coût nul, un seul programme, LXC le permet (« lxc-execute »). Si tu veux pseudo-virtualiser tout le système, tu peux avec LXC (« lxc-start ») ou Docker. Si tu veux pseudo-virtualiser des logiciels prêts à l’emploi dans leur conteneur avec une gestion facilitée de la construction de conteneurs immuables et des outils pour administrer tout ça, passe à Docker directement, qui fait tout ça très bien.
[^] # Re: Docker...
Posté par Anonyme . Évalué à 3.
Sur les « espaces de noms ».
Comme j’ai vu cette erreur plusieurs fois dans ce fil, je me permet de corriger : les cgroups isolent les ressources système (CPU, RAM, …), les namespaces isolent les ressources kernel (PID, réseau, point de montage, utilisateurs, …).
[^] # Re: Docker...
Posté par jyes . Évalué à 1.
En l’occurence ils s’appuient sur les espaces de nom et les cgroups. Les ressources système aussi sont isolées/contrôlées pour les conteneurs. Mais merci, la précision est bienvenue.
[^] # Re: Docker...
Posté par AlexTérieur . Évalué à 1.
Ah, des explications claires, merci.
Après je me suis mal exprimé en parlant de "bibliothèques" conteneurisées. Je veux bien sûr parler d'un programme qui doit pouvoir tourner avec ses dépendances en mode "container".
Or dans mes essais, ce n'est pas le cas. J'ai un programme sous Docker qui télécharge toutes ses dépendances, ce qui explique ces 2,6 Go d'occupation disque. OK, les programmeurs n'ont rien optimisé sans doute, mais quand ils s'expliquent, il y a de quoi se poser des questions…
Je n'ai absolument rien contre LXC (c'est une évolution quasi obligatoire, et c'est tant mieux pour toutes les raisons évoquées), mais la manière dont c'est exploité…
[^] # Re: Docker...
Posté par Anonyme . Évalué à 2.
Si ton programme tire 2,6 Go de dépendance avec lui, peut importe ce que tu fais, tu auras toujours 2,6 Go d’utilisé.
# Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 2.
Dans mon esprit Docker et compagnie c'est bien pour gérer du "bétail", aka déployer les conteneurs construits par une équipe de dev par centaines sur des nœuds géographiquement répartis, chaque conteneur contenant idéalement un seul composant d'un système complexe, qu'on peut déplacer et multiplier à l'envi.
Si je veux m'occuper des mes animaux de compagnie (mon serveur de mail et mon serveur web par exemple), quel est la meilleure solution à base de conteneur ? Qui me permette d'avoir des systèmes isolés et faciles à sauvegarder. LXC ? Podman ? Les jails de FreeBSD ?
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Anonyme . Évalué à 1.
Docker.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 3.
Si par exemple je veux un conteneur "serveur de mail" qui contient un postfix, dovecot et antispam, Docker n'a pas l'air d'être la bonne solution puisque son concept est d'avoir une app par conteneur (un "entry point" par conteneur).
Je veux pouvoir faire des conteneurs système, pas un conteneur par application. Est-ce que Docker est fait pour ça ? Je n'en ai pas l'impression.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par jyes . Évalué à 4.
Ma préférence pour ça : LXC.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par CrEv (site web personnel) . Évalué à 4.
Ça existe, c'est une VM :-D
Dans laquelle chaque processus pourra être un conteneur :-)
La question ici c'est pourquoi veux-tu un conteneur "serveur de mail" ? Quel est le but, quel problème tu cherches à résoudre ?
Suivant les problèmes, il existe différentes solutions :
Tu peux mettre tout ça dans un seul conteneur (Docker ou non c'est pas la question) mais je pense pas que ce soit suivre de bonnes pratiques ni que ça corresponde à un problème que les conteneurs cherchent à résoudre.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 2.
En gros je veux avoir quelque chose qui ressemble à une VM, mais sans la surcharge liée à la VM.
Je veux avoir des "pets": je n'ai pas envie d'écrire un script ansible alors que je n'ai qu'une seule VM ou un seul conteneur qui gère mes mails. Par contre je veux pouvoir facilement le ou la sauvegarder et transférer vers un autre serveur.
En gros je veux un séparateur logique (un conteneur) dans lequel je bidouille à l'ancienne. Mais je veux avoir une séparation logique pour résoudre les problèmes de compatibilité: par exemple je veux mettre à jour mon conteneur de mail vers Debian 12 mais garder mon conteneur LDAP sur Debian 9. Tout ça sans la lourdeur de KVM (allocation de mémoire et disque fixe, I/O lentes à cause de VirtIO, etc).
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par CrEv (site web personnel) . Évalué à 4.
Le principe des conteneurs c'est d'être immuable.
Le code et les resources sont dans une image. Tu lance une instance, tu la stop, aucune donnée n'aura été sauvegardée dans l'image. Donc au prochain lancement tu repars de zéro.
Donc le "je sauvegarde et je transfert" bof. Après tu peux évidemment utiliser des volumes, mais bon si c'est pour avoir une image -> une instance de conteneur -> un volume persistant je suis pas certains de voir la valeur.
Mon avis comme ça c'est que ce que tu cherches à faire ne rentre pas vraiment dans le concept du conteneur.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par jyes . Évalué à 7.
Ça dépend ce que tu appelles « conteneur ». Si pour toi conteneur ≡ docker, alors oui, ce n’est pas le concept. Mais si ce qu’on appelle conteneur, c’est juste une manière de cloisonner les services, il n’y aucun raison de se limiter à des conteneurs immuables. On utilise bien des machines virtuelles pour cloisonner aussi, et elles sont rarement immuables (quoique encore une fois rien ne l’interdit).
Avant Docker, il y avait OpenVZ, Vserver puis LXC, tous répondant au besoin exprimé dans le commentaire auquel tu réponds, et on les appelait des conteneurs (par opposition à la virtualisation). Mon journal sur le sujet, à l’occasion de la fin de Vserver et OpenVZ dans Debian date de 2011, donc ces solutions ont eu le temps de disparaître avant même que Docker existe ! L’arrivée de Docker n’a pas fait disparaître ce besoin, elle a juste apporté en plus de nouvelles manières de travailler qui répondent mieux à certains besoins que les conteneurs à l’ancienne.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par CrEv (site web personnel) . Évalué à 1.
J'utilise ce que la majeur partie des gens appellent conteneur aujourd'hui, c'est à dire du Docker, podman ou autres solutions OCI compliant.
Après on peut sortir d'autres définitions, qui sont aussi valables, mais à mon avis mon proches de ce qui est entendu.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 6.
Je pense qu’au sens strictement sémantique le terme conteneur contient tout ce qui permet d’isoler des composants du reste du système. On peut même considérer une machine virtuelle ou chroot comme des conteneurs. La notion d’immutabilité est spécifique à certains types de conteneurs. Une terminologie que je trouve pas mal est de parler de conteneur logiciel (type Docker) ou conteneur système (type LXC). D’où la question, étant donné que je ne veux pas utiliser un conteneur logiciel immuable. Mais je ne veux pas non plus utiliser une machine virtuelle.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 4.
Les jails se backupent sous la forme d'une archive tar.
Ta prod vient de tomber ? Aucun soucis.
Tu prends ton archive tar tu la déplace sur une VM, tu redéploies ta jail en lui donnant une IP et hop service restart (bon j'exclue la conf du host sur la partie firewalling / networking )
La seule contrainte rencontrée pour l'instant et qu'il faut absolument que tu migres 64 <-> 64 bits et au niveau des versions de FreeBSD qui peut le plus peut le moins.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par jyes . Évalué à 4.
Pareil avec les conteneurs LXC sous Linux. Et plutôt que tar pour la sauvegarde, tu peux aussi utiliser des snapshots BTRFS, avec “btrfs send” (ou l’équivalent avec ZFS sur un BSD).
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 2.
J’ai déjà un peu joué avec LXC, je vais aussi essayer les jails. Ces deux là correspondent bien à ce que je veux faire, je me demandais s’il y avait aussi d’autres solutions de ce style.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 4. Dernière modification le 26 février 2020 à 17:38.
Parti pris complet :
Si tu veux quelque chose de solide, fiable, testé dans la durée et production ready quelque chose que tu installeras sur ta machine et ou tu seras tranquille pour des années - ce que l'on recherche lorsqu'on veut hoster ses services - les jails FreeBSD :)
De l'horlogerie.
Ensuite les approches peuvent changer fonction du wrapper et du FS utilisé (UFS / ZFS)
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Justement je lisais un peu sur le sujet, et il m’a semblé qu’il y avait plusieurs outils de gestion des jails (ezjail, iocage, bastille, …) dont certains me semblaient ne plus être maintenus. Je m’inquiète donc de choisir une solution qui ne sera pas forcément maintenue dans le temps. Qu’est-ce que tu recommandes ? Et UFS contre ZFS, lequel correspond à quel besoin ?
Par exemple mettons que je veuille pouvoir facilement exporter une jail de chez moi vers une VM dans le cloud et inversement, plus faire des sauvegardes de mes jails dans S3. Quelle est la meilleure solution à base de jails pour faire ça ?
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 2. Dernière modification le 27 février 2020 à 10:29.
Soyons clair d'entrée :
Il n'y a pas de technos magiques ou miracles.
Ca n'existe pas et ça n'existera jamais.
Il n y a que des technos qui ont été bien implémentées et intégrées et qui sont assez maitrisée pour qu'au moment ou ça déconne tu sois en capacité de vite remettre tout en ordre.
Il vaut mieux 1 000 fois maitriser à 90% une techno qui ne fait qu'une seule chose plutôt que de maitriser à 10% une techno qui fait papa-maman.
C'est d'ailleurs le grand malheur des solutions et des choix technologiques modernes en entreprise et de l'empilement de stack technologiques inutiles non maitrisée.
Sinon ça s'appelle de la bricole !
Donc maquette, test, casse, remonte, maquette, test, casse, remonte … etc jusqu’à temps d'être hyper à l'aise avec la techno : oui ça demande du temps et de l'investissement.
En suite comme à chaque choix d'architecture et de techno tout dépend de l'usage et de "sur quoi ça va tourner".
ZFS pour moi n'apporte rien si tu veux hoster tes services sur une petite machine mono disque, et que la machine en question n'a pas vocation a servir de NAS. Cela va fortement ralentir les dumps et les sauvegardes même sur un SSD.
Les snapshots ne sont réellement utiles que pour disons effectuer une opération sur un conteneur et revenir avant l'opération si ça a merdé, ce qui peut être plutôt pratique.
Mais Rien ne remplace une vraie politique de backup ! avec externalisation.
Ensuite le cloud ça ne veut rien dire c'est un buzzword marketing (tout ça n'est que du disque et des machines qui tournent en datacenter), ce qu'il faut c'est juste externaliser, de mon côté j'envoie mes archives tar vers un conteneur swift openstack chez OVH avec restic ça coûte quedal, mais un scp vers un serveur SFTP hébergé sur al connexion fibre de ton pote, fera aussi bien l'affaire également.
Temps indispensable à prévoir : étudier la politique de backup.
Ensuite le choix du wrapper en fait dépend directement du FS utilisé, Iocage / Ezjail / Iocel nécessite d'utiliser ZFS.
Si toutefois tu veux utilises ZFS iocage semble être un choix opportun car il s'agit de la solution portée par FreeNAS qui bénéfice d'une forte communauté utilisateur, mais il n'est pas exempt de certains bugs assez chiant
Personnellement je suis un aficionados du minimaliste donc pour faire tourner des service je m'oriente vers UFS qui est extrêmement performant sur un SSD ça bombarde, avec ce genre de FS tu pourras faire tourner FreeBSD sur des bécanes ridiculement petite et donc remonter tes services absolument partout, type ARM et consort sans aucun soucis. Comme excellent wrapper UFS il y a qjail ultra simple, ultra ligth, qui fait très bien le boulot ou encore CBSD plus couteau suisse mais très bien maintenu.
Pour finir les jails ne sont pas un mécanisme compliqué, c'est la partie configuration réseau du host qui t'occuperas le plus à mon avis , VNET, Nat, Firewalling .. et cela que tu sois sous linux ou freebsd tu ne pourras y couper. Personnellement j'adore FreeBSD car il suffit simplement de backuper 2/3 fichiers pour intégralement sauvegarder la conf de son host hyperviseur. Sous linux ça se fait aussi j'imagine ….
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Je veux bien mais je n'ai pas un temps infini, je préfère donc avoir une shortlist d'outils à tester.
Je veux pouvoir faire des dumps de mes conteneurs, les stocker dans S3, et pouvoir les restaurer sur un autre système.
Je suppose que comme tu parles de remonter le conteneur sur du ARM (une archi différente) tu ne sauvegardes pas le conteneur en entier pour pouvoir le relancer ailleurs, mais la conf pour pouvoir reconstruire le conteneur c'est bien ça ?
Un buzzword marketing peut-être, mais qui me permet de manger depuis pas mal d'années déjà :-)
Quand je parle d'une VM cloud, c'est une VM que je peux démarrer à l'instant où je veux.
Par exemple pour l'instant j'ai des machines virtuelles EC2 à Dublin. Je veux migrer des services vers des conteneurs, pouvoir les déplacer chez moi, puis ensuite dans une VM en France, après dans une VM aux États-Unis, etc. Tout ça en ayant juste à démarrer une machine quelque part et y exporter le conteneur.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 3.
Et bien tu choisis ta shortlist d'outils et tu testes, maquettes, casses, testes, maquettes casse. Je le répète les solutions magiques ça n'existe pas ! Il faut maîtriser son sujet !
Oui ça ne change absolument rien que ça soit un SFTP ou du S3 … c'est un espace de stockage accessible depuis l'Internet, et tu conserves combien de dump, quelle rotation, chez mamazone ça peut piquer la volumétrie, tous les combien tu dump, par quel script ?
C'est vrai j'ai peut-être dis une bêtise j'suis pas certain que tu puisse migrer de x86 vers ARM je crois que l'hyperviseur va râler. En revanche tu peux prendre ta boite (jail/conteneur LxC) depuis une instance ec2 simple (x86) -> vers une machine chez OVH, Rackspace, ou une VM dans ton garage, sur ton pc de bureau sans aucun soucis.
Effectivement tu peux avoir l'approche je reconstruis ma boite à la volée avec un outil de déploiement type ansible et je récupère ma données stockées ou tu veux (qu'il faut toujours backupé et externaliser ça ne règle pas le soucis ça le déplace), mais effectivement c'est l'usine à gaz pour 2 pauvres services.
Ca aussi ça n'existe pas, c'est ce que je reproche à la magie du "cloud" ça te fait croire que ça tourne partout et nul part, non c'est au chaud dans des datacenters géolocalisés quelque part sur des CPU et des disques bien physiques derrière des routeurs bien réels.
A un moment faut déplacer la data qui se situe physiquement quelque part.
Oui, oui tu peux faire ça avec des jails BSD mais encore faut il être capable de reconstuire rapidement la partie réseau de ton hyperviseur (ce qui n'est pas très compliqué) et maitriser la procédure. aussi simple soit elle.
Mais si tu veux fait tu veux tout, tout de suite sans t'investir dans le projet, ca n'existe pas navré, enfin si pour les commerciaux qui vendent de la bullshit aux clients ça existe certainement.
Si il y a bien une solution pour avoir du mail par exemple, tu paies X euros par mois chez protonmail ou gandi (mail inclu avec l'achat d'un nom de domaine) et tu n'auras rien à faire rien, à t'occuper pas de temps à dépenser, pas d'outils à shortlister juste à sortir la CB (c'est la solution que j'ai retenu pour les mails, c'est franchement casse bonbon à administrer la messagerie )
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Des datacenters oui, mais aussi énormément de logiciel pour rendre tout ça transparent pour les utilisateurs. C'est ça la magie du cloud, c'est du logiciel. Je ne regrette pas l'époque où je devais attendre 3 mois pour avoir un serveur.
L'informatique c'est un outil, il y a des outils plus ou moins simples à utiliser. Choisir le bon outil c'est assez primordial pour être efficace.
Je fais déjà tourner mes services. Je veux les convertir petit à petit vers des conteneurs pour pouvoir les déplacer en fonction des besoins. Je veux en mettre certains chez moi pour économiser les coûts d'hébergement, mais pouvoir les déplacer rapidement chez un hébergeur quand ma freebox tombe en panne ou que je déménage.
Je passe maximum quelques heures par mois à gérer tout ça, et ça marche bien. Je ne suis pas intéressé par jeter tout ça et utiliser un fournisseur tiers à la place.
Par contre je cherche le bon outil pour faire évoluer mon système comme décrit plus haut. Au début j'étais assez enthousiaste pour tester les jails de FreeBSD, mais tes messages semblent indiquer que cela nécessite un investissement en temps conséquent, donc ça me refroidit pas mal.
Je vais commencer par regarder LXC plus en détails, merci pour les infos.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 1.
C'est là ou je diverge, je n'ai pas du tout cette approche. Les outils vont et viennent avec des features plus ou moins intéressantes qui n'apportent pas réellement grand chose de plus sur le fond.
Je pense au contraire, je pense qu'il est plus beaucoup important de maitriser l'outil, le rendement sur le long terme est nettement plus intéressant.
Sinon je ne comprends pas quel est l’intérêt de vouloir faire faire le tour de la terre à ses données … gagner 3 ms sur un ping ?
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Pour l'instant ça tourne dans une VM EC2, maintenant que j'ai la fibre je veux déplacer certains services chez moi temporairement. Je vais bientôt déménager, donc je veux pouvoir déplacer de nouveau le service ailleurs quand je déménage. Aussi je veux facilement pouvoir changer d'hébergeur en fonction des prix.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à -1.
C'est dingue que tu aies monté des services sur une instance EC2 et que tu te poses ce genre de question aussi simple …
Sans aucune offense, ça donne l'impression que tu as monté quelque chose dans un coin à l'arrache, ça a pris de l'importance et désormais et tu sembles un peu perdu sur comment t'en dépatouiller.
Le syndrome de l'entreprise qui s'est fait enfumer par un consultant cloud et qui veut désormais faire de la réversibilité sans savoir comment :D
T'as les menottes AWS ;)
Plus sérieusement, si tout est monté sans conteneur dans ton instance c'est un peu cuit pour exporter faut tout remonter chez toi - à moins qu'AWS veuille bien t'envoyer l'ISO complète de ta VM j'en doute - commence par récupérer tes dump de bases, rync la data de ton montage nextcloud et le reste vers chez toi (ou vers un autre endroit ou tu le désires).
Le reste ça se remonte "facilement".
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 2.
J’ai la prétention de savoir un peu ce que je fais, ça fait 15 ans que j‘héberge ces services. En ce moment c’est dans EC2, avant c’était ailleurs.
Je connais très bien AWS pour des raisons professionnelles, c’est pour ça que je l’utilise.
Ça n’empêche pas de demander des conseils pour tester d’autres approches !
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 27 février 2020 à 12:24.
Tu fusionne la donnée et l'exécution ?
Tu veux pouvoir faire « tout et n'importe quoi », mais les données doivent se déplacer avec. Si tes données se comptent en Mio pourquoi pas, mais dès que tu as des Gio tu va commencer à trouver ça long.
Tu va aussi avoir des questions compliquées :
Personnellement l'approche qui me paraît la plus fiable c'est d'avoir tout l'applicatif en docker avec des instances immuables et donc sans état et gérer la donnée en bare metal.
Cela permet :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
À voir, je cherche la meilleure approche pour moi.
J'héberge quelques services: web, mail, nextcloud, jabber, ldap, etc. Il y a les données, l'exécution (tel binaire qui dépend de telle librairie), mais aussi la configuration.
Ç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.
C'est pour ça que je trouve que ce concept est plus adapté pour des conteneur déployés de nombreuses fois, mais pas pour un conteneur déployé une seule fois (la complexité ajoutée ne vaut pas le coup).
Est-ce qu'il y a une meilleure plus simple d'utiliser Docker sans avoir à redéployer un conteneur pour un changemeet de configuration ?
Justement je cherche une solution qui me permettent de faire des sauvegardes cohérentes. Si j'ai bien compris LXC + btrfs me permettent de faire ça, je fais un snapshot du conteneur, puis je l'exporte.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par barmic 🦦 . É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
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Le job du FS est de conserver sa cohérence. Dans le cas de ton application qui meurt inopinément, en effet ton appli doit gérer la cohérence à son niveau.
Dans ton cas d'une appli qui écrit un simple fichier, une manière de faire est la suivante:
Avec cette méthode, tu ne retrouves pas avec un fichier final à moitié écrit, seul le fichier temporaire peut se retrouver dans cet état. Le fichier final est soit la version précédente (avant le renommage) soit la version après le renommage.
C'est beaucoup plus compliqué avec des bases de données. Une bonne partie de la complexité des gestionnaires de base de données vient de là, comment pouvoir repartir correctement après une coupure de courant.
Il y a plusieurs manières d'écrire sur le disque dans MySQL, plus ou moins sûres et moins ou plus performantes, par exemple innodb_flush_log_at_trx_commit
Il y a des commandes SQL pour rendre ça moins douloureux, mais ça doit pouvoir marcher sans.
En théorie si système de snapshot est cohérent, tu dois pouvoir restaurer ta base de données dans un état cohérent avec un snapshot fait sans précaution particulière, mais tu peux perdre quelques transactions si tu utilises innodb_flush_log_at_trx_commit différent de 1. C'est en gros équivalent à une perte de courant sur ton serveur, qui est cas que ton SGBD doit pouvoir redémarrer depuis.
En pratique il y a des cas où ça ne marche pas en fonction des limitations du SGBD. Par exemple avec MySQL avant la version 8, si tu fais un DDL (modification de la définition d'une table) et que MySQL crashe ou que ton serveur crashe, tu as de fortes chances de ne pas pouvoir relancer la base de donnée.
Pour éviter de perdre certaines transaction et éviter de tomber dans les cas d'où le SGBD ne sait pas redémarrer, il faut flusher les tables sur le disque d'abord avec une requête du type:
FLUSH TABLES WITH READ LOCK
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 0.
EXT4 est également strictement incapable de gérer une coupure de courant brutale sur une écriture de fichier, il n'est pas fait pour ça.
C'est pour cela que l'on trouve des carte RAID avec de la RAM en cache et des batteries pour prévenir les coupure le temps que les IO redescendent proprement sur disque en barre metal.
ZFS sait le faire lui en revanche ainsi que la gestion native du raid (d'ou la hype et à condition d'avoir de la RAM ECC ..)
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 2.
EXT4 est tout à fait capable de gérer une coupure de courant (journalisation, write barrier et tout le toutim). Ce qu'il ne fait pas (mais aucun FS ne fait) est de récupérer magiquement les données sur lesquelles il n'y a pas eu de fsync.
Je ne connais pas bien ZFS, mais je ne vois pas pourquoi ça serait différent à ce niveau là. Pouvoir récupérer les données sur lesquelles il n'y a eu de fsync implique d'écrire de manière synchrone sur le disque en permanence ce qui est ingérable niveau performance sur un disque rotatif.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kerro . Évalué à 3.
La batterie ne permet qu'une seule chose : accélérer les écritures car le contrôleur honore les syncs sans avoir à écrire immédiatement sur le disque.
Ça ne résout donc pas le problème que tu indiques (problème qui n'existe de toutes manières pas, comme l'indique paulez).
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kwiknclean . Évalué à 1.
Non ça c'est la RAM embarquée la batterie évite les coupure électriques brutales justement !
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Kerro . Évalué à 3.
Oui ok, la mémoire plus la batterie.
Je pensais que c'était évident, puisqu'une batterie toute seule ne sert à rien.
Le résultat est le même : la mémoire plus la batterie (plus le contrôleur qui va avec, plus les câbles, plus le bon micrologiciel, etc) ne permettent qu'une seule chose --> accélérer les écritures car le contrôleur honore les syncs sans avoir à écrire immédiatement sur le disque.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par barmic 🦦 . Évalué à 1.
C'est surtout que c'est du RAID. Ça donne un niveau d'indirection qu'ext4 ne maîtrise pas. Je ne sais pas si ext4 est fiable lors de coupure de courant, mais le mettre en concurrence avec zfs/btrfs sur la gestion de RAID n'a pas de sens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par Psychofox (Mastodon) . Évalué à 3.
Non tu n'as pas bien compris.
Si tu fais bien ton image tu rends tes points de configurations gérables par exemple par des variables d'environements ou des arguments en ligne de commande. Si tu as besoin d'un fichier de conf très dense, ça peut être un fichier local ou distant monté dans ton container, ou hébergé ailleurs (repo git par exemple).
L'image tu ne la génère que pour mettre à jours les binaires dedans.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
OK donc dans ce cas je "monte" la configuration dans le docker. Donc je dois faire des backups du point de montage de la configuration et des données séparément. C'est bien un conteneur "applicatif" dans le sens où le conteneur ne se suffit pas à lui-même, il faut lui adjoindre la configuration et les données.
Ici l'intérêt de Docker se limite à isoler la partie applicative, car je sais qu'elle va fonctionner partout, mais ça ne m'aide pas avec le reste.
J'essaie d'imaginer un fonctionnement plus similaire à une VM, où je peux gérer l'application, la configuration et les données d'un seul bloc, comme ça je n'ai qu'une seule chose à sauvegarder.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par jyes . Évalué à 4.
Plus je te lis, plus j’ai l’impression que ce tu veux c’est LXC, mais que ce que tu devrais utiliser c’est Docker. Partager un fichier de conf’ séparé du conteneur t’oblige à déplacer deux données au lieu d’une quand tu veux déménager ton conteneur, mais c’est aussi beaucoup plus propre et beaucoup plus adapté à l’image que tu as en tête de VMs qui peuvent être démarrées et arrêtées à la volée à tout instant.
C’est bizarre de vouloir absolument mettre la configuration dans le conteneur, c’est comme se plaindre que pour installer Vim sur deux machines différentes et qu’il fonctionne pareil, il faut copier le binaire et le dossier ~/.vim/. OK, tout n’est pas exactement au même endroit avec Docker, mais devoir copier ton fichier de création de conteneur et sa conf’ ne semble pas une difficulté insurmontable. Au total, ce ne seront que quelques fichiers à copier. Et le plus dur restera les données, mais d’autres t’ont très bien répondu à ce sujet, et embarquer les données dans une VM que tu veux pouvoir dupliquer, arrêter, démarrer à la volée, ça ne semble vraiment pas le plus pratique.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . Évalué à 1.
Possible en effet, je vais essayer aussi avec Docker pour voir comment je m’en sors. Merci pour les pistes !
# Au début était...
Posté par Jean Parpaillon (site web personnel) . Évalué à 4.
Le "facilement" est important ici mais, pour être complet sur le sujet de l'isolation sous Linux on peut rappeler quelques prémices/fondements de la techno.
chrootexiste depuis longtemps déjà): les processus, les IPC, etc (je ne me rappelle plus trop dans quel ordre),cgroupsde manière un peu plus intuitive. Ce ne sont que des scripts et ça s'appelle LXC,"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.