Journal L'Écosystème containeurs

Posté par . Licence CC by-sa.
20
24
fév.
2020

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 . Évalué à 4 (+2/-0).

    "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é ?

    Opera le fait depuis 10 ans.

    • [^] # Re: Docker et LXC

      Posté par (page perso) . Évalué à 8 (+7/-0).

      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 (page perso) . Évalué à 5 (+3/-0).

        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 . Évalué à 2 (+0/-0).

          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.

          Opera le fait depuis 10 ans.

          • [^] # Re: Docker et LXC

            Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 18/03/20 à 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 . Évalué à 2 (+1/-0).

              C'est pas une bonne idée. Il est difficile de faire des sauvegardes cohérentes via des volumes docker par exemple.

      • [^] # Re: Docker et LXC

        Posté par . Évalué à 2 (+1/-0). Dernière modification le 25/02/20 à 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 (page perso) . Évalué à 7 (+5/-0).

      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 . Évalué à -10 (+3/-22). Dernière modification le 25/02/20 à 06:41.

    Marrant de faire un journal en 2020 sur les containers sans parler orchestration et kubernetes.

    • [^] # Re: k8s

      Posté par . Évalué à 10 (+10/-2).

      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é !

    • [^] # Re: k8s

      Posté par . Évalué à 10 (+10/-0).

      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 . Évalué à 3 (+2/-0).

    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.

  • # BastilleBSD

    Posté par (page perso) . Évalué à 3 (+1/-0).

    Pour compléter, il faut aussi citer BastilleBSD, qui repose sur les jails de FreeBSD.

    • [^] # Re: BastilleBSD

      Posté par . Évalué à 2 (+1/-0).

      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 . Évalué à 6 (+5/-1).

    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 (page perso) . Évalué à 2 (+0/-0).

      Mais dans un contexte de PROD et d'exploitation :

      Des prods sous Docker c'est pas ce qui manque.

      quand il y a un soucis de performance comment cela se passe ?

      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 . Évalué à 1 (+0/-1).

        Des prods sous Docker c'est pas ce qui manque.

        Je le supposais aussi

        C'est quoi un soucis de performance ?

        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 (page perso) . Évalué à 2 (+0/-0).

          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 …

          Ç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 sysdig par exemple.

        • [^] # Re: Petite question de béotien

          Posté par . Évalué à 1 (+0/-0).

          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 . Évalué à 7 (+6/-0).

          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 . Évalué à 3 (+3/-1). Dernière modification le 25/02/20 à 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 :

      • les cgroups : c'est juste le scheduler de linux depuis pas mal de temps maintenant, il est juste configuré pour avoir des groupes spécifiques
      • chroot : bon ben c'est chroot quoi
      • les namespaces : les namespaces sont juste une façon d'étiqueté des éléments du système pour les grouper et les isoler. Ça créer une indirection (par exemple pour les pid tu as un mapping entre le pid dans un containeur et celui du système), mais c'est quelque chose de bien plus simple que de recréer le sous système linux en question.

      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.

    • [^] # Re: Petite question de béotien

      Posté par . Évalué à 10 (+11/-0).

      "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 . Évalué à 3 (+2/-1).

      Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)

      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 (page perso) . Évalué à 3 (+2/-1).

        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 . Évalué à 1 (+0/-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 . Évalué à 4 (+2/-0).

          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 . Évalué à 2 (+1/-1).

    • [^] # Re: Petite question de béotien

      Posté par (page perso) . Évalué à 5 (+3/-0).

      Bientôt on pourra se passer des sysadmins et c'est une bonne chose

      Alors déjà : non (voir plus bas).

      Ensuite, c'est marrant que tu dises ça, alors que plus loin :

      Mais dans un contexte de PROD et d'exploitation :
      quand il y a un soucis de performance comment cela se passe ?

      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 :

      • monitorer pour détecter les pannes, les ralentissements, les problèmes
      • configurer l'infra de manière à ce que tout puisse tourner correctement, qu'il y ait une petite charge ou une grosse charge, que le produit des développeurs soit nickel ou codé avec les pieds
      • sécuriser
      • sauvegarder
      • faire des plan de reprise d'activité
      • remplacer le matériel défectueux ou en fin de vie (quoique il peut y avoir du personnel dédié à ça dans des grosses boites ou datacenter)

      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 (page perso) . Évalué à 10 (+9/-0).

        quand il y a des soucis de perfs […] c'est soit la faute à l'admin sys […], soit la faute à l'architecte logiciel […], soit la faute au développeur

        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 (page perso) . Évalué à 8 (+6/-0).

      Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)

      […]

      Mais dans un contexte de PROD et d'exploitation :

      quand il y a un soucis de performance comment cela se passe ?

      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 (page perso) . Évalué à 3 (+1/-0).

      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 . Évalué à 10 (+10/-0).

      Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)

      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 . Évalué à 6 (+4/-0).

        je vais faire une réponse globale :

        D'abord merci a tous j'ai appris quelques trucs ou mieux compris d'autres

        • sysdig connaissait pas
        • c'est vrai que docker est plus proche du processus que de l'émulation d'une machine que le comprends mieux
        • les devops existent … c'est pas une légende urbaine :)

        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 (page perso) . Évalué à 10 (+10/-0). Dernière modification le 25/02/20 à 18:14.

          nous aurons (les sysadmins) du travail c'est sur

          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.

          Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Petite question de béotien

            Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 27/02/20 à 01:40.

            Côté dev, on connait le truc, on l'a fait avec Java il y a 20 ans.

            ET IL Y A 60 ANS AVEC JCL :)

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: Petite question de béotien

          Posté par (page perso) . Évalué à 6 (+4/-0).

          les devops existent … c'est pas une légende urbaine :)

          Et c'est donc quoi un devops ?

          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.

          C'est marrant on peut écrire exactement l'inverse.

          • [^] # Re: Petite question de béotien

            Posté par (page perso) . Évalué à 6 (+3/-0).

            Et c'est donc quoi un devops ?

            Un dev biclassé ops ?

            Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Petite question de béotien

            Posté par (page perso) . Évalué à 8 (+5/-0).

            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 . Évalué à 2 (+0/-0).

            C'est marrant on peut écrire exactement l'inverse.

            J'aurais pas dit mieux :)

    • [^] # Re: Petite question de béotien

      Posté par . Évalué à 2 (+1/-0).

      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 …

      C'est exactement pour ça qu'on est pas près de se passer des sysadmins :-)

    • [^] # Re: Petite question de béotien

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Bientôt on pourra se passer des sysadmins et c'est une bonne chose … :)

      Et qui va fabriquer tes boiboites docker ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # rkt - origin

    Posté par (page perso) . Évalué à 2 (+0/-0).

    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.

    C'est plus que ça pour rkt, le projet est mort et archivé : https://github.com/rkt/rkt/issues/4024

    • 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.

    Je 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, docker le daemon qui tourne c'est bien directement basé sur moby.

  • # rootless

    Posté par . Évalué à 4 (+2/-0).

    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 (page perso) . Évalué à 10 (+11/-2). Dernière modification le 25/02/20 à 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 . Évalué à 7 (+9/-3).

      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 . Évalué à 4 (+5/-2).

        consommation énorme d'espace disque (moi qui souriais sur la solution Flatpak…)

        Ç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.

        un fonctionnement opaque pour les 9/10è des utilisateurs

        On peut dire ça d'énormément de choses. Ça n'est pas un argument en soit.

        comment prendre la main sur un composant qui déconne dans le container même ?

        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.

        Non sans troll, il n'y a pas des alternatives ?

        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 ?

        • [^] # Re: Docker...

          Posté par (page perso) . Évalué à 2 (+0/-0).

          aller triturer l'intérieur d'un conteneur quelque soit la techno, c'est assez contre-intuitif

          Ç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.

          Non sans troll, il n'y a pas des alternatives ?

          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 . Évalué à 2 (+2/-1).

            Ben si. LXC par exemple (et son successeur LXD) servent exactement à ça. Et utilisent la même machinerie que Docker côté noyau.
            OK je comprends bien. Mais n'était-ce pas la base de Docker de simplifier cela ? J'ai des programmes avec qui j'ai des images de plus de 2 Go (oui oui, mais il paraît que "Ça consomme ce que tu lui demande de consommer"), soit presque autant qu'un système complet installé ou virtualisé. Peut-on conteneuriser des bibliothèques par exemple déjà installées sur le système ?

            • [^] # Re: Docker...

              Posté par . Évalué à 2 (+1/-0).

              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)

            • [^] # Re: Docker...

              Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 27/02/20 à 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 :

              Peut-on conteneuriser des bibliothèques par exemple déjà installées sur le système ?

              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 (page perso) . Évalué à 3 (+1/-0).

                en s’appuyant sur les CGroups.

                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 (page perso) . Évalué à 1 (+0/-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 . Évalué à 1 (+0/-0).

                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.

                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 (page perso) . Évalué à 2 (+0/-0).

                  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.

                  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 (page perso) . Évalué à 2 (+1/-0).

    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 (page perso) . Évalué à 1 (+2/-3).

      Docker.

      • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

        Posté par (page perso) . Évalué à 3 (+2/-0).

        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 (page perso) . Évalué à 4 (+2/-0).

          Ma préférence pour ça : LXC.

        • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Si par exemple je veux un conteneur "serveur de mail" qui contient un postfix, dovecot et antispam,

          Ç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 :

          • vm (avec des scripts qui te gères tes services, du terraform, ansible ou autre suivant les besoins)
          • docker-compose
          • docker app (ou autre solution compatible CNAB)
          • un orchestrateur

          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 (page perso) . Évalué à 2 (+1/-0).

            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 (page perso) . Évalué à 4 (+2/-0).

              Par contre je veux pouvoir facilement le ou la sauvegarder et transférer vers un autre serveur.

              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 (page perso) . Évalué à 7 (+5/-0).

                Mon avis comme ça c'est que ce que tu cherches à faire ne rentre pas vraiment dans le concept du conteneur.

                Ç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 (page perso) . Évalué à 1 (+0/-1).

                  Ç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

                  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 (page perso) . Évalué à 6 (+5/-0).

                    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 . Évalué à 4 (+3/-0).

              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.

              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 . Évalué à 4 (+3/-0). Dernière modification le 26/02/20 à 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 (page perso) . Évalué à 1 (+0/-0).

        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 . Évalué à 2 (+2/-1). Dernière modification le 27/02/20 à 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 (page perso) . Évalué à 1 (+0/-0).

            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.

            Je veux bien mais je n'ai pas un temps infini, je préfère donc avoir une shortlist d'outils à tester.

            Temps indispensable à prévoir : étudier la politique de backup.

            Je veux pouvoir faire des dumps de mes conteneurs, les stocker dans S3, et pouvoir les restaurer sur un autre système.

            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.

            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 ?

            Ensuite le cloud ça ne veut rien dire c'est un buzzword marketing

            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 . Évalué à 3 (+2/-0).

              Je veux bien mais je n'ai pas un temps infini, je préfère donc avoir une shortlist d'outils à tester.

              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 !

              Je veux pouvoir faire des dumps de mes conteneurs, les stocker dans S3, et pouvoir les restaurer sur un autre système.

              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 ?

              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 ?

              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.

              Quand je parle d'une VM cloud, c'est une VM que je peux démarrer à l'instant où je veux.

              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.

              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.

              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 (page perso) . Évalué à 1 (+0/-0).

                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.

                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.

                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.

                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 . Évalué à 1 (+0/-0).

                  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.

                  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 (page perso) . Évalué à 1 (+0/-0).

                    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 . Évalué à -1 (+1/-3).

                      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 (page perso) . Évalué à 2 (+1/-0).

                        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 . Évalué à 1 (+0/-0). Dernière modification le 27/02/20 à 12:24.

              Je veux pouvoir faire des dumps de mes conteneurs, les stocker dans S3, et pouvoir les restaurer sur un autre système.

              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 :

              • qu'est-ce qui garanti que ma donnée est correct ? Lors d'un crash de ton contenaire est-ce que tu risque de perdre la totalité de tes données et indexes associé ?
              • comment arrête tu un contenaire ?
              • lorsque tu passe d'un endroit à un autre es-tu prêt à arrêter ton service, déplacer le contenaire avec toutes ses données, puis relancer le service ? Et donc avoir une interruption de service plus ou moins conséquente
              • est-ce que tu veut pouvoir lancer plusieurs instance de ton containaire ? si oui comment vont ils partager la donné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 :

              • d'avoir des choses vraiment plus simples à tester que tout ce que j'ai pu voir ailleurs. Je sais ce qui tourne en prod et je peux le reproduire chez moi. Toute la donnée est localisée et triviale a récupérer
              • garder une gestion simple de la donnée : Il n'y a pas besoin d'orchestration pour des bases de données, parce que ça n'a pas de sens de déplacer la donnée ou de tenter d'être élastique.
              • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

                Posté par (page perso) . Évalué à 1 (+0/-0).

                Tu fusionne la donnée et l'exécution ?

                À 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 ?

                qu'est-ce qui garanti que ma donnée est correct ? Lors d'un crash de ton contenaire est-ce que tu risque de perdre la totalité de tes données et indexes associé ?

                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 . Évalué à 2 (+1/-0).

                  Ç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).


                  1. 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 (page perso) . Évalué à 1 (+0/-0).

                    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:

                    1. Créer un fichier temporaire et écrire dedans.
                    2. Appeler fsync() sur le fichier temporaire.
                    3. Renommer le fichier temporaire vers le fichier final.

                    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
                    Si ton système de snapshot n'est pas cohérent (par exemple tu fais un tar ou un rsync), là il faut flusher les tables et mettre un lock en écriture le temps de toute la procédure.

                    • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

                      Posté par . Évalué à 0 (+0/-1).

                      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.

                      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 (page perso) . Évalué à 2 (+1/-0).

                        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 (page perso) . Évalué à 3 (+0/-0).

                        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.

                        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 . Évalué à 1 (+0/-0).

                          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.

                          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 (page perso) . Évalué à 3 (+0/-0).

                            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 . Évalué à 1 (+0/-0).

                        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.

                        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.

                • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

                  Posté par . Évalué à 3 (+1/-0).

                  i 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 ?

                  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 (page perso) . Évalué à 1 (+0/-0).

                    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 (page perso) . Évalué à 4 (+2/-0).

                      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.

  • # Au début était...

    Posté par (page perso) . Évalué à 4 (+3/-0).

    En 2013, l'entreprise Docker se lance et permet de facilement utiliser des containeurs

    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.

    • En 2005, alors que tout le monde ne jure que par les VMs, OpenVZ propose de l'isolation au niveau "système d'exploitation" avec un noyau Linux modifié,
    • En 2006, Linux "upstream" s'intéresse au truc et commence à introduire quelques mécanismes d'isolation (autres que le FS, chroot existe depuis longtemps déjà): les processus, les IPC, etc (je ne me rappelle plus trop dans quel ordre),
    • En 2008, une floppée de scripts arrive pour pouvoir utiliser ces cgroups de manière un peu plus intuitive. Ce ne sont que des scripts et ça s'appelle LXC,
    • (un peu HS mais pour mon plaisir personnel, ça me rappelle des souvenirs) En 2009, le projet Kerrighed utilise les cgroups pour créer des conteneur 'cluster-wide': un cluster Kerrighed se comporte comme une seule machine et votre conteneur Kerrighed peut s'étendre sur tous les CPU/RAM du cluster.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.